[chromium-dev] Re: Issue Fixed status
I have followed up and/or closed the above issues as appropriate. I expect Glen will update the status for http://crbug.com/5354 as soon as he has committed the patch. On Jul 8, 8:31 pm, Thiago Farina thiago.far...@gmail.com wrote: Hi dhhwai, http://crbug.com/661http://crbug.com/5288 For this particulary issue, I've submitted the patch to Glen, so I'm waiting for he commit to me.http://crbug.com/5354 The flicker event in this issue still occuring, but the menu closes on second click.http://crbug.com/6242 These are the issues that I can remember now. On Jul 8, 5:03 pm, dhhwai d...@chromium.org wrote: Issue 7863 is fixed now. We can ask the fix committers to review the status of other unfixed issues. Do you have the issue numbers of other such issues? You can list them individually like: http://crbug.com/N On Jul 8, 7:45 am, Thiago Farina thiago.far...@gmail.com wrote: I noticed that the Issue 7863, that me and jcampan, we fixed, are available until now. I saw there are some other Issues are with the status: Available, but already well fixed. So some issues are being fixed but are not being updated in the Issue List. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Flying blind
I did a WebKit DEPs roll tonight to pick up the next stage of V8Proxy cleanup and promptly lost the ability to see the buildbot: blockquote Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /buildbot/waterfall/. Reason: Error reading from remote server /blockquote There's not really much I can do except cross my fingers and hope it went well. If there are problems building the generated bindings, the bot probably just needs a clobber. Many apologies if I left a mess... Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Flying blind
I can see the buildbot intermittenly now, and it looks like Windows needs a clobber. Unfortunately, I don't see a way to do that on the buildbot page... :( On Thu, Jul 9, 2009 at 1:24 AM, Adam Barthaba...@chromium.org wrote: I did a WebKit DEPs roll tonight to pick up the next stage of V8Proxy cleanup and promptly lost the ability to see the buildbot: blockquote Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /buildbot/waterfall/. Reason: Error reading from remote server /blockquote There's not really much I can do except cross my fingers and hope it went well. If there are problems building the generated bindings, the bot probably just needs a clobber. Many apologies if I left a mess... Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Flying blind
I clobbered the WebKit FYI builds. Looks like someone else beat me to the main windows builds. On Thu, Jul 9, 2009 at 1:35 AM, Adam Barth aba...@chromium.org wrote: I can see the buildbot intermittenly now, and it looks like Windows needs a clobber. Unfortunately, I don't see a way to do that on the buildbot page... :( On Thu, Jul 9, 2009 at 1:24 AM, Adam Barthaba...@chromium.org wrote: I did a WebKit DEPs roll tonight to pick up the next stage of V8Proxy cleanup and promptly lost the ability to see the buildbot: blockquote Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /buildbot/waterfall/. Reason: Error reading from remote server /blockquote There's not really much I can do except cross my fingers and hope it went well. If there are problems building the generated bindings, the bot probably just needs a clobber. Many apologies if I left a mess... Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-checkins] r20238 - trunk/tools/buildbot/config/master.chromium.fyi
linux2 there is the platform, as in linux with kernel 2.*.
import sys
print sys.platform
linux2
Nicolas
On Thu, Jul 9, 2009 at 12:34 AM, PhistucK phist...@gmail.com wrote:
Should this not be changed also? m_webkit_linux_v8_latest =
chromium_factory.ChromiumFactory('src/build',
'linux2')
(I also marked it in the changes below)
☆PhistucK
On Thu, Jul 9, 2009 at 06:24, nsylv...@chromium.org wrote:
Author: nsylv...@chromium.org
Date: Wed Jul 8 20:24:38 2009
New Revision: 20238
Log:
Rename linux2 to chromeos, and add a new slave for marshall's chromium
embedded project.
Review URL: http://codereview.chromium.org/155268
Modified:
trunk/tools/buildbot/config/master.chromium.fyi/master.cfg
Modified: trunk/tools/buildbot/config/master.chromium.fyi/master.cfg
==
--- trunk/tools/buildbot/config/master.chromium.fyi/master.cfg (original)
+++ trunk/tools/buildbot/config/master.chromium.fyi/master.cfg Wed Jul 8
20:24:38 2009
@@ -164,12 +164,13 @@
'Webkit Linux (valgrind)',
'Webkit Linux (valgrind layout)',
'Linux Builder (Toolkit dbg)',
- 'Linux Builder (linux2)',
+ 'Linux Builder (ChromeOS)',
'XP Coverage (dbg)',
'Mac Coverage (dbg)',
'Linux Coverage (dbg)',
'Google Chrome XP',
'Google Chrome Linux',
+'Chromium Embedded',
])
# Scheduler to trigger when v8 bleeding edge is updated.'
@@ -222,6 +223,7 @@
m_webkit_mac_v8_latest = chromium_factory.ChromiumFactory('src/build',
'darwin')
* m_webkit_linux_v8_latest = chromium_factory.**
ChromiumFactory('src/build',
'linux2')*
+m_win_cef = chromium_factory.ChromiumFactory('src/cef', 'win32')
# The identifier of the factory is the build configuration. If two
factories
# are using the same build configuration, they should have the same
identifier.
@@ -387,12 +389,12 @@
tests=[],
properties={'gclient_env': { 'GYP_DEFINES':'toolkit_views=1'}})
-f_chromium_rel_linux_linux2 = m_linux.ChromiumFactory(
-'chromium-rel-linux-linux2',
+f_chromium_rel_linux_chromeos = m_linux.ChromiumFactory(
+'chromium-rel-linux-chromeos',
tests=[],
options=['chrome'],
properties={'archive_build': True,
-'gclient_env': { 'GYP_DEFINES':'linux2=1
branding=Chrome'}})
+'gclient_env': { 'GYP_DEFINES':'chromeos=1
branding=Chrome'}})
f_google_chrome_rel_xp = m_win.ChromiumFactory(
'google-chrome-rel-xp',
@@ -410,6 +412,9 @@
tests=['ui', 'unit'],
properties={'gclient_env': { 'GYP_DEFINES' : branding=Chrome}})
+f_chromium_rel_xp_cef = m_win_cef.CEFFactory(
+'chromium-rel-cef', tests=[])
+
#
# BUILDER DEFINITIONS
@@ -603,10 +608,10 @@
'category': '4linux|builders_compile',
}
-b_chromium_rel_linux_linux2 = {'name': 'Linux Builder (linux2)',
+b_chromium_rel_linux_chromeos = {'name': 'Linux Builder (ChromeOS)',
'slavename': 'codf189',
- 'builddir': 'chromium-rel-linux-linux2',
- 'factory': f_chromium_rel_linux_linux2,
+ 'builddir': 'chromium-rel-linux-chromeos',
+ 'factory': f_chromium_rel_linux_chromeos,
'category': '4linux|builders_compile',
}
@@ -622,6 +627,11 @@
'factory': f_google_chrome_rel_linux,
}
+b_chromium_rel_xp_cef = {'name': 'Chromium Embedded',
+ 'slavename': 'codf205',
+ 'builddir': 'chromium-rel-xp-cef',
+ 'factory': f_chromium_rel_xp_cef,
+}
c['builders'] = [
b_google_chrome_rel_xp,
@@ -650,10 +660,11 @@
b_webkit_dbg_linux_valgrind,
b_webkit_dbg_linux_valgrind_layout,
b_chromium_dbg_linux_toolkit,
- b_chromium_rel_linux_linux2,
+ b_chromium_rel_linux_chromeos,
b_coverage_dbg_mac,
b_coverage_dbg_linux,
b_coverage_dbg_xp,
+ b_chromium_rel_xp_cef,
]
### STATUS TARGETS
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Using Chromium Source Code?
Thanks for the link of terms, and for your confirmation. From what I can see in the terms, Chromium is primarily covered by the BSD and LGPL licences, so I can't see a problem there. I guess my primary concern is with copyright if I am reworking the Chromium browser part of the project to meet my own needs. On 8 July, 03:43, Evan Martin e...@chromium.org wrote: On Tue, Jul 7, 2009 at 2:59 PM, Kruncherleaha...@gmail.com wrote: I would like to use the Chromium source code as the basis to a custom documentation viewer. The following outlines what I would like to do with the source: - Add sidebar panels to left/right of each Chromium window. - Remove unwanted features from drop-down menu buttons on main tool strip. - Remove Inspector and the various web developer and debugging tools from interface. - Replace search functionality with custom search functionality in URI address bar. - Add a custom scheme name my-scheme:something/a/b/c.html - Adjust About dialog box to reflect title of product with logo and product artwork. - Change colour scheme of the browser. Whilst the application will still be able to access the webpages from the Internet, it will be used primarily for viewing offline content. I have a couple of questions: 1. Would this be compatible with the associated open source license? 2. Could the product be distributed as a part of a commercial package? http://code.google.com/chromium/terms.htmldescribes the licenses of the code. In general, the answer to both of your questions is yes -- applications like yours are part of our intent in releasing the code -- but you should definitely check with a lawyer before making a commercial release, and I am not a lawyer. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Using Chromium Source Code?
Not really, the open source Chrome is Chromium for a reason, so you could use it.As far as I know, there are no closed copyrights for the Chromium logo or name. (Could be mistaking, though.) ☆PhistucK On Thu, Jul 9, 2009 at 16:46, Kruncher leaha...@gmail.com wrote: Thanks for the link of terms, and for your confirmation. From what I can see in the terms, Chromium is primarily covered by the BSD and LGPL licences, so I can't see a problem there. I guess my primary concern is with copyright if I am reworking the Chromium browser part of the project to meet my own needs. On 8 July, 03:43, Evan Martin e...@chromium.org wrote: On Tue, Jul 7, 2009 at 2:59 PM, Kruncherleaha...@gmail.com wrote: I would like to use the Chromium source code as the basis to a custom documentation viewer. The following outlines what I would like to do with the source: - Add sidebar panels to left/right of each Chromium window. - Remove unwanted features from drop-down menu buttons on main tool strip. - Remove Inspector and the various web developer and debugging tools from interface. - Replace search functionality with custom search functionality in URI address bar. - Add a custom scheme name my-scheme:something/a/b/c.html - Adjust About dialog box to reflect title of product with logo and product artwork. - Change colour scheme of the browser. Whilst the application will still be able to access the webpages from the Internet, it will be used primarily for viewing offline content. I have a couple of questions: 1. Would this be compatible with the associated open source license? 2. Could the product be distributed as a part of a commercial package? http://code.google.com/chromium/terms.htmldescribes the licenses of the code. In general, the answer to both of your questions is yes -- applications like yours are part of our intent in releasing the code -- but you should definitely check with a lawyer before making a commercial release, and I am not a lawyer. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Using Chromium Source Code?
Well, the Chromium _source code_ is open source. But my guess is I don't think you can use the Chromium name nor logo in any personally distributed software. Besides, I don't expect that you will since you want to make your own commercial software package. On Jul 9, 6:56 am, PhistucK phist...@gmail.com wrote: Not really, the open source Chrome is Chromium for a reason, so you could use it.As far as I know, there are no closed copyrights for the Chromium logo or name. (Could be mistaking, though.) ☆PhistucK On Thu, Jul 9, 2009 at 16:46, Kruncher leaha...@gmail.com wrote: Thanks for the link of terms, and for your confirmation. From what I can see in the terms, Chromium is primarily covered by the BSD and LGPL licences, so I can't see a problem there. I guess my primary concern is with copyright if I am reworking the Chromium browser part of the project to meet my own needs. On 8 July, 03:43, Evan Martin e...@chromium.org wrote: On Tue, Jul 7, 2009 at 2:59 PM, Kruncherleaha...@gmail.com wrote: I would like to use the Chromium source code as the basis to a custom documentation viewer. The following outlines what I would like to do with the source: - Add sidebar panels to left/right of each Chromium window. - Remove unwanted features from drop-down menu buttons on main tool strip. - Remove Inspector and the various web developer and debugging tools from interface. - Replace search functionality with custom search functionality in URI address bar. - Add a custom scheme name my-scheme:something/a/b/c.html - Adjust About dialog box to reflect title of product with logo and product artwork. - Change colour scheme of the browser. Whilst the application will still be able to access the webpages from the Internet, it will be used primarily for viewing offline content. I have a couple of questions: 1. Would this be compatible with the associated open source license? 2. Could the product be distributed as a part of a commercial package? http://code.google.com/chromium/terms.htmldescribesthe licenses of the code. In general, the answer to both of your questions is yes -- applications like yours are part of our intent in releasing the code -- but you should definitely check with a lawyer before making a commercial release, and I am not a lawyer. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Flying blind
Thanks Jeremy. Adam On Thu, Jul 9, 2009 at 1:50 AM, Jeremy Orlowjor...@chromium.org wrote: I clobbered the WebKit FYI builds. Looks like someone else beat me to the main windows builds. On Thu, Jul 9, 2009 at 1:35 AM, Adam Barth aba...@chromium.org wrote: I can see the buildbot intermittenly now, and it looks like Windows needs a clobber. Unfortunately, I don't see a way to do that on the buildbot page... :( On Thu, Jul 9, 2009 at 1:24 AM, Adam Barthaba...@chromium.org wrote: I did a WebKit DEPs roll tonight to pick up the next stage of V8Proxy cleanup and promptly lost the ability to see the buildbot: blockquote Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /buildbot/waterfall/. Reason: Error reading from remote server /blockquote There's not really much I can do except cross my fingers and hope it went well. If there are problems building the generated bindings, the bot probably just needs a clobber. Many apologies if I left a mess... Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Hard coded
What would be the best place to put dialog message strings, chromium_strings or generated_resources.grd? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
Jay's on the ball and has updated http://crbug.com/15833 On Jul 9, 7:43 am, Thiago Farina thiago.far...@gmail.com wrote: Thanks dhhwai! I found another one. This issue was committed, but the status is assigned, so I'm not sure if it has to be marked as fixed:http://crbug.com/15833 On Jul 9, 3:52 am, dhhwai d...@chromium.org wrote: I have followed up and/or closed the above issues as appropriate. I expect Glen will update the status forhttp://crbug.com/5354assoon as he has committed the patch. On Jul 8, 8:31 pm, Thiago Farina thiago.far...@gmail.com wrote: Hi dhhwai, http://crbug.com/661http://crbug.com/5288 For this particulary issue, I've submitted the patch to Glen, so I'm waiting for he commit to me.http://crbug.com/5354 The flicker event in this issue still occuring, but the menu closes on second click.http://crbug.com/6242 These are the issues that I can remember now. On Jul 8, 5:03 pm, dhhwai d...@chromium.org wrote: Issue 7863 is fixed now. We can ask the fix committers to review the status of other unfixed issues. Do you have the issue numbers of other such issues? You can list them individually like: http://crbug.com/N On Jul 8, 7:45 am, Thiago Farina thiago.far...@gmail.com wrote: I noticed that the Issue 7863, that me and jcampan, we fixed, are available until now. I saw there are some other Issues are with the status: Available, but already well fixed. So some issues are being fixed but are not being updated in the Issue List. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
I think there is another issue: http://crbug.com/3215 On Jul 9, 1:27 pm, dhhwai d...@chromium.org wrote: Jay's on the ball and has updatedhttp://crbug.com/15833 On Jul 9, 7:43 am, Thiago Farina thiago.far...@gmail.com wrote: Thanks dhhwai! I found another one. This issue was committed, but the status is assigned, so I'm not sure if it has to be marked as fixed:http://crbug.com/15833 On Jul 9, 3:52 am, dhhwai d...@chromium.org wrote: I have followed up and/or closed the above issues as appropriate. I expect Glen will update the status forhttp://crbug.com/5354assoon as he has committed the patch. On Jul 8, 8:31 pm, Thiago Farina thiago.far...@gmail.com wrote: Hi dhhwai, http://crbug.com/661http://crbug.com/5288 For this particulary issue, I've submitted the patch to Glen, so I'm waiting for he commit to me.http://crbug.com/5354 The flicker event in this issue still occuring, but the menu closes on second click.http://crbug.com/6242 These are the issues that I can remember now. On Jul 8, 5:03 pm, dhhwai d...@chromium.org wrote: Issue 7863 is fixed now. We can ask the fix committers to review the status of other unfixed issues. Do you have the issue numbers of other such issues? You can list them individually like: http://crbug.com/N On Jul 8, 7:45 am, Thiago Farina thiago.far...@gmail.com wrote: I noticed that the Issue 7863, that me and jcampan, we fixed, are available until now. I saw there are some other Issues are with the status: Available, but already well fixed. So some issues are being fixed but are not being updated in the Issue List. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
Thiago, I believe a better approach is replying back on that issue tracker instead of in dev mailing list. The owner of the bug will receive an email if you reply stating if it has been fixed. -- Mohamed Mansour On Thu, Jul 9, 2009 at 1:03 PM, Thiago Farina thiago.far...@gmail.comwrote: I think there is another issue: http://crbug.com/3215 On Jul 9, 1:27 pm, dhhwai d...@chromium.org wrote: Jay's on the ball and has updatedhttp://crbug.com/15833 On Jul 9, 7:43 am, Thiago Farina thiago.far...@gmail.com wrote: Thanks dhhwai! I found another one. This issue was committed, but the status is assigned, so I'm not sure if it has to be marked as fixed:http://crbug.com/15833 On Jul 9, 3:52 am, dhhwai d...@chromium.org wrote: I have followed up and/or closed the above issues as appropriate. I expect Glen will update the status forhttp://crbug.com/5354assoon as he has committed the patch. On Jul 8, 8:31 pm, Thiago Farina thiago.far...@gmail.com wrote: Hi dhhwai, http://crbug.com/661http://crbug.com/5288 For this particulary issue, I've submitted the patch to Glen, so I'm waiting for he commit to me.http://crbug.com/5354 The flicker event in this issue still occuring, but the menu closes on second click.http://crbug.com/6242 These are the issues that I can remember now. On Jul 8, 5:03 pm, dhhwai d...@chromium.org wrote: Issue 7863 is fixed now. We can ask the fix committers to review the status of other unfixed issues. Do you have the issue numbers of other such issues? You can list them individually like: http://crbug.com/N On Jul 8, 7:45 am, Thiago Farina thiago.far...@gmail.com wrote: I noticed that the Issue 7863, that me and jcampan, we fixed, are available until now. I saw there are some other Issues are with the status: Available, but already well fixed. So some issues are being fixed but are not being updated in the Issue List. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
I reproduced the steps in this issue, but the next and previous buttons worked as expected, in version 2.0.172.33. http://crbug.com/6054 On Jul 9, 2:03 pm, Thiago Farina thiago.far...@gmail.com wrote: I think there is another issue:http://crbug.com/3215 On Jul 9, 1:27 pm, dhhwai d...@chromium.org wrote: Jay's on the ball and has updatedhttp://crbug.com/15833 On Jul 9, 7:43 am, Thiago Farina thiago.far...@gmail.com wrote: Thanks dhhwai! I found another one. This issue was committed, but the status is assigned, so I'm not sure if it has to be marked as fixed:http://crbug.com/15833 On Jul 9, 3:52 am, dhhwai d...@chromium.org wrote: I have followed up and/or closed the above issues as appropriate. I expect Glen will update the status forhttp://crbug.com/5354assoon as he has committed the patch. On Jul 8, 8:31 pm, Thiago Farina thiago.far...@gmail.com wrote: Hi dhhwai, http://crbug.com/661http://crbug.com/5288 For this particulary issue, I've submitted the patch to Glen, so I'm waiting for he commit to me.http://crbug.com/5354 The flicker event in this issue still occuring, but the menu closes on second click.http://crbug.com/6242 These are the issues that I can remember now. On Jul 8, 5:03 pm, dhhwai d...@chromium.org wrote: Issue 7863 is fixed now. We can ask the fix committers to review the status of other unfixed issues. Do you have the issue numbers of other such issues? You can list them individually like: http://crbug.com/N On Jul 8, 7:45 am, Thiago Farina thiago.far...@gmail.com wrote: I noticed that the Issue 7863, that me and jcampan, we fixed, are available until now. I saw there are some other Issues are with the status: Available, but already well fixed. So some issues are being fixed but are not being updated in the Issue List. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
On Thu, Jul 9, 2009 at 10:39 AM, Thiago Farina thiago.far...@gmail.comwrote: I reproduced the steps in this issue, but the next and previous buttons worked as expected, in version 2.0.172.33. http://crbug.com/6054 Please, stop mailing chromium-dev about individual bugs and just post comments (if they are useful) in the bugs themselves. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
Sorry I already deleted. On Jul 9, 2:42 pm, Peter Kasting pkast...@google.com wrote: On Thu, Jul 9, 2009 at 10:39 AM, Thiago Farina thiago.far...@gmail.comwrote: I reproduced the steps in this issue, but the next and previous buttons worked as expected, in version 2.0.172.33. http://crbug.com/6054 Please, stop mailing chromium-dev about individual bugs and just post comments (if they are useful) in the bugs themselves. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] span and Javascript
Hello everybody,
I am using Chromium on Linux (build 20134).
Nearly everything works for me (including Flash), but I've recently
written a page that works like a charm in Firefox but not in Chromium.
The page is at http://www.linuxclubradio.tk/picostreamer/?setlang=en
The matter is that every 5 seconds the script launch a function that
contains this:
status = document.getElementById(ainfo[0]+-status); // ainfo[0] =
linuxclubradio
if (status.innerHTML != ainfo[2])
{
window.location.reload();
}
and, a little under, of course:
span id=linuxclubradio-status
the javascript reloads the page if the AJAX request found that the
status of one of the webradios has changed.
The matter is that the page continues to reload!
Doing some debugging I found out that status is declared and it is
an HTML object, but status.innerHTML is undefined!
I repeat: on FF everything works!
Thanks for answers
Alessandro
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
Peter some times the issues hasn't an owner, so in this cases I can't simply answer in the issue. Like this: http://crbug.com/3078 On Jul 9, 2:43 pm, Thiago Farina thiago.far...@gmail.com wrote: Sorry I already deleted. On Jul 9, 2:42 pm, Peter Kasting pkast...@google.com wrote: On Thu, Jul 9, 2009 at 10:39 AM, Thiago Farina thiago.far...@gmail.comwrote: I reproduced the steps in this issue, but the next and previous buttons worked as expected, in version 2.0.172.33. http://crbug.com/6054 Please, stop mailing chromium-dev about individual bugs and just post comments (if they are useful) in the bugs themselves. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
On Thu, Jul 9, 2009 at 11:21 AM, Thiago Farina thiago.far...@gmail.comwrote: Peter some times the issues hasn't an owner, so in this cases I can't simply answer in the issue. Like this: http://crbug.com/3078 It doesn't matter whether the issue has an owner. Eventually we will triage and note your comments. Mailing this list is sort of like trying to force us to triage the bug _now_, which is inefficient. Just let the various bug triagers get to your comments when they get to them. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue Fixed status
So in the next cases, I will only comment in the issue, and wait for some answer. On Jul 9, 3:25 pm, Peter Kasting pkast...@google.com wrote: On Thu, Jul 9, 2009 at 11:21 AM, Thiago Farina thiago.far...@gmail.comwrote: Peter some times the issues hasn't an owner, so in this cases I can't simply answer in the issue. Like this:http://crbug.com/3078 It doesn't matter whether the issue has an owner. Eventually we will triage and note your comments. Mailing this list is sort of like trying to force us to triage the bug _now_, which is inefficient. Just let the various bug triagers get to your comments when they get to them. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] help with gyp?
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 known at the time gyp runs, but which should actually be substituted during the compile when the .in version of the script is processed and written to the output directory. (This is only for the Linux port.) It looks like the !() feature will only run a command when gyp runs, not when the build system later runs, so using that would mean that changes to the .in file would not be taken up unless gyp is rerun. For files that don't need this processing, I could use the copies facility in gyp, but I can't figure out how to tell it to process the file (e.g. with sed -e 's/@@FOO@@/(FOO)/g' or something) when the build system runs. Anyone know how to do this? Thanks, --Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: help with gyp?
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 known at the time gyp runs, but which should actually be substituted during the compile when the .in version of the script is processed and written to the output directory. (This is only for the Linux port.) It looks like the !() feature will only run a command when gyp runs, not when the build system later runs, so using that would mean that changes to the .in file would not be taken up unless gyp is rerun. For files that don't need this processing, I could use the copies facility in gyp, but I can't figure out how to tell it to process the file (e.g. with sed -e 's/@@FOO@@/(FOO)/g' or something) when the build system runs. Anyone know how to do this? Thanks, --Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: help with gyp?
Sounds like you're looking for an 'actions' or 'rules'.Look at src/webkit/webkit.gyp or src/chrome/chrome.gyp On Thu, Jul 9, 2009 at 11:12 AM, Mike Mammarella m...@chromium.org 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 known at the time gyp runs, but which should actually be substituted during the compile when the .in version of the script is processed and written to the output directory. (This is only for the Linux port.) It looks like the !() feature will only run a command when gyp runs, not when the build system later runs, so using that would mean that changes to the .in file would not be taken up unless gyp is rerun. For files that don't need this processing, I could use the copies facility in gyp, but I can't figure out how to tell it to process the file (e.g. with sed -e 's/@@FOO@@/(FOO)/g' or something) when the build system runs. Anyone know how to do this? Thanks, --Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Teams
On Wed, Jul 8, 2009 at 9:01 PM, Thiago Farina thiago.far...@gmail.comwrote: because the firefox has this feature, many users from firefox will want this too in chrome. This is rarely a reason we justify feature additions (I have no idea which feature you're working on). In general, for both this issue and most other questions you've been asking on chromium-dev, you should try to get an answer first on irc.freenode.net#chromium, since that should get you faster responses, and fall back to email if no one replies there. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: span and Javascript
It seems like status is a reserved word (so it does not give you the
HTMLObject you wanted, but something internal that cannot be reached), try
to use some other name.
☆PhistucK
On Thu, Jul 9, 2009 at 09:37, Alessandro rinaldi.al...@gmail.com wrote:
Hello everybody,
I am using Chromium on Linux (build 20134).
Nearly everything works for me (including Flash), but I've recently
written a page that works like a charm in Firefox but not in Chromium.
The page is at http://www.linuxclubradio.tk/picostreamer/?setlang=en
The matter is that every 5 seconds the script launch a function that
contains this:
status = document.getElementById(ainfo[0]+-status); // ainfo[0] =
linuxclubradio
if (status.innerHTML != ainfo[2])
{
window.location.reload();
}
and, a little under, of course:
span id=linuxclubradio-status
the javascript reloads the page if the AJAX request found that the
status of one of the webradios has changed.
The matter is that the page continues to reload!
Doing some debugging I found out that status is declared and it is
an HTML object, but status.innerHTML is undefined!
I repeat: on FF everything works!
Thanks for answers
Alessandro
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Buildbot Mac compiles are now being assisted by Linux
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 Mac compilations. I've been running this same setup locally for a couple of months and don't anticipate any problems, but if you notice anything suspicious, please let me know. I'll be monitoring the builds to make sure that everything's going smoothly. (Yes, this is distcc pump mode. We've actually been using pump mode on the Macs for about a month, but they were only distributing to other Macs.) Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Context::GetEntered v GetCalling v GetCurrent
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things from a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope. Or am
I missing some subtlety here?
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective differences)?
The descriptions are kind of terse, and I'm afraid I'm missing some of the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the top of
the stack, but clearly that's not true :)
-atw
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.-1 on using
the same syntax (or at least the same directives) as JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %% %%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span jscontent=url
http://www.some.com/.. http://www.some.com/./span
/div
In the above the i18n_download span is intended to be a localized string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and* a
page composition value within a select directive. The jst replacements that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an obvious
suggestion is just to add another virtual JST directive called (i18n for
example), that behaves exactly like jscontent, but additionally removes the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span jscontent=url
http://www.some.com/.. http://www.some.com/./span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span jscontent=url
http://www.some.com/..http://www.some.com/
./span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Context::GetEntered v GetCalling v GetCurrent
On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things from a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope. Or am
I missing some subtlety here?
dynamicGlobalObject() is almost never the right choice. The correct
result for the image constructor is based on the window that
originally holds the image constructor. The assert above should fail,
but the result JSC computes is still wrong.
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective differences)?
GetEntered() ~ dynamicGlobalObject
GetCalling() ~ lexicalGlobalObject
GetCurrent() ~ *concept doesn't exist in JSC*
The descriptions are kind of terse, and I'm afraid I'm missing some of the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the top of
the stack, but clearly that's not true :)
These things are easier to understand by example. You can contact me
directly and we can go through some examples.
In any case, we should have this discussion on webkit-dev because it
affects the webkit.org repository.
Adam
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Context::GetEntered v GetCalling v GetCurrent
For an example of what this means, you can look at
v8/test/cctest/test-api.cc and look for GetCallingContext.
-- Mads
On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Agera...@chromium.org wrote:
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute. GetEntered() returns the last context
that you entered using the API. When you call JavaScript functions,
the JavaScript engine enters the context in which that function was
defined. When calling functions across frames, this context will be
different from the context that you entered through the API.
GetCurrent will always give you the context of the currently executing
function (the context in which the currently executing function was
declared). GetCalling will get you the context of the function that
called the function you are currently executing.
Cheers, -- Mads
On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things from a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope. Or am
I missing some subtlety here?
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective differences)?
The descriptions are kind of terse, and I'm afraid I'm missing some of the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the top of
the stack, but clearly that's not true :)
-atw
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Context::GetEntered v GetCalling v GetCurrent
I have a proposal for a rename of these functions. GetCurrent() and
GetEntered() make sense when you understand the underlying V8
mechanism, but I think that the concept of a stack of contexts is more
readily understandable to some random engineer walking in off the
street.
What if we renamed these things to eg:
GetTopContext(); // Returns the top v8 context from the stack, eg the
context of the currently executing code
GetBottomContext() // Returns the bottom v8 context from the stack,
eg the context where execution entered v8
- a
On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Agera...@chromium.org wrote:
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute. GetEntered() returns the last context
that you entered using the API. When you call JavaScript functions,
the JavaScript engine enters the context in which that function was
defined. When calling functions across frames, this context will be
different from the context that you entered through the API.
GetCurrent will always give you the context of the currently executing
function (the context in which the currently executing function was
declared). GetCalling will get you the context of the function that
called the function you are currently executing.
Cheers, -- Mads
On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things from a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope. Or am
I missing some subtlety here?
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective differences)?
The descriptions are kind of terse, and I'm afraid I'm missing some of the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the top of
the stack, but clearly that's not true :)
-atw
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Context::GetEntered v GetCalling v GetCurrent
I support this. It look me a while to get my mind wrapped around
this, especially when reading JSC / V8 bindings code side-by-side.
Aligning with the JSC names would be even better.
Adam
On Thu, Jul 9, 2009 at 1:39 PM, Aaron Boodmana...@chromium.org wrote:
I have a proposal for a rename of these functions. GetCurrent() and
GetEntered() make sense when you understand the underlying V8
mechanism, but I think that the concept of a stack of contexts is more
readily understandable to some random engineer walking in off the
street.
What if we renamed these things to eg:
GetTopContext(); // Returns the top v8 context from the stack, eg the
context of the currently executing code
GetBottomContext() // Returns the bottom v8 context from the stack,
eg the context where execution entered v8
- a
On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Agera...@chromium.org wrote:
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute. GetEntered() returns the last context
that you entered using the API. When you call JavaScript functions,
the JavaScript engine enters the context in which that function was
defined. When calling functions across frames, this context will be
different from the context that you entered through the API.
GetCurrent will always give you the context of the currently executing
function (the context in which the currently executing function was
declared). GetCalling will get you the context of the function that
called the function you are currently executing.
Cheers, -- Mads
On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things from a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope. Or am
I missing some subtlety here?
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective differences)?
The descriptions are kind of terse, and I'm afraid I'm missing some of the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the top of
the stack, but clearly that's not true :)
-atw
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
2009/7/9 Rafael Weinstein rafa...@chromium.org However, because some of our existing pages use JSTemplate both for injecting strings and for doing dynamic composition, the jst directives can colide. Consider the following: div jsselect=items span jscontent=i18n_downloadDownload: /span span jscontent=url http://www.some.com/.. http://www.some.com/./span /div In the above the i18n_download span is intended to be a localized string, and the url is a part of dynamic composition of the based on run-time state. The problem with this is that it contains a i18n string replacement *and* a page composition value within a select directive. The jst replacements that take place during i18n injection and dynamic composition are going to collide. The above code will most likely result in the Download text being replaced by either or null. Arv's patch doesn't have these problems. It uses a different set of directives for localization templating. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Context::GetEntered v GetCalling v GetCurrent
To me dynamic and lexical makes no sense, so I don't think we should
go there. Since you 'enter' a context through the API and you alway
have a current context when executing code, I find the current
terminology consistent with what is going on and consistent with the
naming in the rest of the API. If we are to change the names, we need
to make sure to keep the names consistent and meaningful.
-- Mads
On Thu, Jul 9, 2009 at 1:43 PM, Adam Barthaba...@chromium.org wrote:
I support this. It look me a while to get my mind wrapped around
this, especially when reading JSC / V8 bindings code side-by-side.
Aligning with the JSC names would be even better.
Adam
On Thu, Jul 9, 2009 at 1:39 PM, Aaron Boodmana...@chromium.org wrote:
I have a proposal for a rename of these functions. GetCurrent() and
GetEntered() make sense when you understand the underlying V8
mechanism, but I think that the concept of a stack of contexts is more
readily understandable to some random engineer walking in off the
street.
What if we renamed these things to eg:
GetTopContext(); // Returns the top v8 context from the stack, eg the
context of the currently executing code
GetBottomContext() // Returns the bottom v8 context from the stack,
eg the context where execution entered v8
- a
On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Agera...@chromium.org wrote:
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute. GetEntered() returns the last context
that you entered using the API. When you call JavaScript functions,
the JavaScript engine enters the context in which that function was
defined. When calling functions across frames, this context will be
different from the context that you entered through the API.
GetCurrent will always give you the context of the currently executing
function (the context in which the currently executing function was
declared). GetCalling will get you the context of the function that
called the function you are currently executing.
Cheers, -- Mads
On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread
use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things from
a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit
currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect
that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope. Or
am
I missing some subtlety here?
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective
differences)?
The descriptions are kind of terse, and I'm afraid I'm missing some of the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for
example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the top
of
the stack, but clearly that's not true :)
-atw
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
I'm pursuing the js solution since it buys a performance boost in the
short term. It uses l10n-values and l10n-content which are almost
identical to jsvalues and jscontent except that it does not allow
arbitrary expressions.
I expect to send out a finished CL today.
2009/7/9 Rafael Weinstein rafa...@chromium.org:
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.
-1 on using the same syntax (or at least the same directives) as JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %% %%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
In the above the i18n_download span is intended to be a localized string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and* a
page composition value within a select directive. The jst replacements that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an obvious
suggestion is just to add another virtual JST directive called (i18n for
example), that behaves exactly like jscontent, but additionally removes the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span
jscontent=url http://www.some.com/.../span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--
erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Context::GetEntered v GetCalling v GetCurrent
It could be that the current names make sense if you work on v8, but
don't if you work on a browser. Perhaps this naming scheme could be
chromium-specific?
- a
On Thu, Jul 9, 2009 at 1:50 PM, Mads Sig Agera...@chromium.org wrote:
To me dynamic and lexical makes no sense, so I don't think we should
go there. Since you 'enter' a context through the API and you alway
have a current context when executing code, I find the current
terminology consistent with what is going on and consistent with the
naming in the rest of the API. If we are to change the names, we need
to make sure to keep the names consistent and meaningful.
-- Mads
On Thu, Jul 9, 2009 at 1:43 PM, Adam Barthaba...@chromium.org wrote:
I support this. It look me a while to get my mind wrapped around
this, especially when reading JSC / V8 bindings code side-by-side.
Aligning with the JSC names would be even better.
Adam
On Thu, Jul 9, 2009 at 1:39 PM, Aaron Boodmana...@chromium.org wrote:
I have a proposal for a rename of these functions. GetCurrent() and
GetEntered() make sense when you understand the underlying V8
mechanism, but I think that the concept of a stack of contexts is more
readily understandable to some random engineer walking in off the
street.
What if we renamed these things to eg:
GetTopContext(); // Returns the top v8 context from the stack, eg the
context of the currently executing code
GetBottomContext() // Returns the bottom v8 context from the stack,
eg the context where execution entered v8
- a
On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Agera...@chromium.org wrote:
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute. GetEntered() returns the last context
that you entered using the API. When you call JavaScript functions,
the JavaScript engine enters the context in which that function was
defined. When calling functions across frames, this context will be
different from the context that you entered through the API.
GetCurrent will always give you the context of the currently executing
function (the context in which the currently executing function was
declared). GetCalling will get you the context of the function that
called the function you are currently executing.
Cheers, -- Mads
On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread
use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things
from a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit
currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect
that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope. Or
am
I missing some subtlety here?
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective
differences)?
The descriptions are kind of terse, and I'm afraid I'm missing some of the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for
example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the top
of
the stack, but clearly that's not true :)
-atw
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
Fwd: [chromium-dev] Re: Context::GetEntered v GetCalling v GetCurrent
We already have an abstraction layer around these calls. We can
change names in V8Proxy / whatever these functions end up after
V8Proxy dissolves.
Adam
On Thu, Jul 9, 2009 at 1:55 PM, Aaron Boodmana...@chromium.org wrote:
It could be that the current names make sense if you work on v8, but
don't if you work on a browser. Perhaps this naming scheme could be
chromium-specific?
- a
On Thu, Jul 9, 2009 at 1:50 PM, Mads Sig Agera...@chromium.org wrote:
To me dynamic and lexical makes no sense, so I don't think we should
go there. Since you 'enter' a context through the API and you alway
have a current context when executing code, I find the current
terminology consistent with what is going on and consistent with the
naming in the rest of the API. If we are to change the names, we need
to make sure to keep the names consistent and meaningful.
-- Mads
On Thu, Jul 9, 2009 at 1:43 PM, Adam Barthaba...@chromium.org wrote:
I support this. It look me a while to get my mind wrapped around
this, especially when reading JSC / V8 bindings code side-by-side.
Aligning with the JSC names would be even better.
Adam
On Thu, Jul 9, 2009 at 1:39 PM, Aaron Boodmana...@chromium.org wrote:
I have a proposal for a rename of these functions. GetCurrent() and
GetEntered() make sense when you understand the underlying V8
mechanism, but I think that the concept of a stack of contexts is more
readily understandable to some random engineer walking in off the
street.
What if we renamed these things to eg:
GetTopContext(); // Returns the top v8 context from the stack, eg the
context of the currently executing code
GetBottomContext() // Returns the bottom v8 context from the stack,
eg the context where execution entered v8
- a
On Thu, Jul 9, 2009 at 1:34 PM, Mads Sig Agera...@chromium.org wrote:
Drew,
quick answer: When you use V8 you have to enter a context before
giving V8 some code to execute. GetEntered() returns the last context
that you entered using the API. When you call JavaScript functions,
the JavaScript engine enters the context in which that function was
defined. When calling functions across frames, this context will be
different from the context that you entered through the API.
GetCurrent will always give you the context of the currently executing
function (the context in which the currently executing function was
declared). GetCalling will get you the context of the function that
called the function you are currently executing.
Cheers, -- Mads
On Thu, Jul 9, 2009 at 1:04 PM, Drew Wilsonatwil...@chromium.org wrote:
Hi all,
I've been poking around quite a bit recently in the WebKit JS
bindings/constructor code, trying to make some sense of their widespread
use
of the lexicalGlobalObject() - basically, it seems like looking at the
lexicalGlobalObject() is seldom what they actually want, because it means
that if you call between frames you unexpectedly start pulling things
from a
different context.
As a very simple example (bear with me, I'll get to the chrome-specific
question in a second) - imagine that you have a page containing a child
frame. In the parent page, you define this:
function getImage() {
return new Image();
}
...now down in your child frame, you have code that does this:
var image1 = new Image();
var image2 = parent.window.getImage();
assert(image1.__proto__ == image2.__proto__); // Fails in WebKit
currently,
because the Image constructor lookup uses the lexicalGlobalObject.
JSC defines dynamicGlobalObject() and lexicalGlobalObject() - I suspect
that
they generally want to be using dynamicGlobalObject instead of
lexicalGlobalObject when trying to access something from global scope.
Or am
I missing some subtlety here?
That brings me to my Chromium/V8 question - there are 3 context-grabbing
functions in V8: GetEntered(), GetCalling(), GetCurrent(). When is it
appropriate to use one over the others (what are the effective
differences)?
The descriptions are kind of terse, and I'm afraid I'm missing some of
the
subtleties between the context of the calling JavaScript code vs The
context on the top of the stack vs The last entered context (for
example,
I would have naively thought that the calling JavaScript code's context
would *inherently* be the last entered one, and hence would be on the
top of
the stack, but clearly that's not true :)
-atw
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Clobber time?
I am landing a GRD change. You may need to clobber. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Clobber time?
Please just make a whitespace change to the grd. - a On Thu, Jul 9, 2009 at 2:11 PM, Elliot Glaysher (Chromium)e...@chromium.org wrote: I am landing a GRD change. You may need to clobber. -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: A suggestion to Drastically improve build times,
On Wed, Jul 8, 2009 at 10:50 AM, Evan Martine...@chromium.org wrote: On Wed, Jul 8, 2009 at 10:46 AM, nakroyoav.zilberb...@gmail.com wrote: the reason i think one from chrome is the best is because these changes could affect MAC and UNIX as well Regarding incremental linking: I don't believe it exists on Linux, but gold is quite fast. My links take around ~5s, though I have a very fast machine. M-A asked about these numbers and revealed I was lying. Debug builds take 8 seconds to link, while release is between 1 and 2 seconds. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
Fantastic. I'll look forward to using it.
On Thu, Jul 9, 2009 at 1:52 PM, Erik Arvidsson a...@chromium.org wrote:
I'm pursuing the js solution since it buys a performance boost in the
short term. It uses l10n-values and l10n-content which are almost
identical to jsvalues and jscontent except that it does not allow
arbitrary expressions.
I expect to send out a finished CL today.
2009/7/9 Rafael Weinstein rafa...@chromium.org:
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.
-1 on using the same syntax (or at least the same directives) as
JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments
programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %%
%%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I
realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives
can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
In the above the i18n_download span is intended to be a localized
string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and*
a
page composition value within a select directive. The jst replacements
that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text
being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few
humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an
obvious
suggestion is just to add another virtual JST directive called (i18n
for
example), that behaves exactly like jscontent, but additionally removes
the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span
jscontent=url http://www.some.com/.../span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n
support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much
simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code
between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--
erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Chromium HTML 5 Integration using avcodec.dlls
Hi, I periodically have issues loading the avcodec.dll. I have build the avcodec.dll that contains the following H.264 exports: (I did have to disable mmx which I am not sure why as of yet) 461 1CC 00174100 ff_h264_decode_nal 462 1CD 0018AD20 ff_h264_decode_picture_parameter_set 463 1CE 001742F0 ff_h264_decode_rbsp_trailing 464 1CF 00189280 ff_h264_decode_sei 465 1D0 00189F90 ff_h264_decode_seq_parameter_set 466 1D1 00194D40 ff_h264_find_frame_end 467 1D2 0018C150 ff_h264_free_context 468 1D3 00190270 ff_h264_idct8_add4_c 469 1D4 0018FA60 ff_h264_idct8_add_c = _pred4x4_down_left_rv40_nodown_c 470 1D5 0018FE40 ff_h264_idct8_dc_add_c 471 1D6 0018FEA0 ff_h264_idct_add16_c 472 1D7 00190090 ff_h264_idct_add16intra_c 473 1D8 00190310 ff_h264_idct_add8_c 474 1D9 0018F690 ff_h264_idct_add_c 475 1DA 0018FDE0 ff_h264_idct_dc_add_c 476 1DB 0018F7E0 ff_h264_lowres_idct_add_c 477 1DC 0018F930 ff_h264_lowres_idct_put_c 478 1DD 0052C620 ff_h264_lps_range 479 1DE 0052C8A0 ff_h264_lps_state 480 1DF 0052C520 ff_h264_mlps_state 481 1E0 0052C820 ff_h264_mps_state 482 1E1 002C30A0 ff_h264_norm_shift 483 1E2 00194AA0 ff_h264_pred_init which I think are the correct exports you would need for the decode. However when I go to the YouTube link provided to test the HTML 5 integration of video I see, You must have an HTML5 capable browser. (http://www.youtube.com/html5#) I have the appropriate dll's I believe in the Chrome.exe directory but now it doesn't seem to load the dll stepping through as far as I can in the debugger. Any help would be appreciated. Thanks in advance, Rich --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium HTML 5 Integration using avcodec.dlls
Before we jump into debugging, where did you get your FFmpeg source code? The version and building instructions we use are documented here: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/mingw/ Andrew On Thu, Jul 9, 2009 at 3:17 PM, richard winterton rrwinter...@gmail.comwrote: Hi, I periodically have issues loading the avcodec.dll. I have build the avcodec.dll that contains the following H.264 exports: (I did have to disable mmx which I am not sure why as of yet) 461 1CC 00174100 ff_h264_decode_nal 462 1CD 0018AD20 ff_h264_decode_picture_parameter_set 463 1CE 001742F0 ff_h264_decode_rbsp_trailing 464 1CF 00189280 ff_h264_decode_sei 465 1D0 00189F90 ff_h264_decode_seq_parameter_set 466 1D1 00194D40 ff_h264_find_frame_end 467 1D2 0018C150 ff_h264_free_context 468 1D3 00190270 ff_h264_idct8_add4_c 469 1D4 0018FA60 ff_h264_idct8_add_c = _pred4x4_down_left_rv40_nodown_c 470 1D5 0018FE40 ff_h264_idct8_dc_add_c 471 1D6 0018FEA0 ff_h264_idct_add16_c 472 1D7 00190090 ff_h264_idct_add16intra_c 473 1D8 00190310 ff_h264_idct_add8_c 474 1D9 0018F690 ff_h264_idct_add_c 475 1DA 0018FDE0 ff_h264_idct_dc_add_c 476 1DB 0018F7E0 ff_h264_lowres_idct_add_c 477 1DC 0018F930 ff_h264_lowres_idct_put_c 478 1DD 0052C620 ff_h264_lps_range 479 1DE 0052C8A0 ff_h264_lps_state 480 1DF 0052C520 ff_h264_mlps_state 481 1E0 0052C820 ff_h264_mps_state 482 1E1 002C30A0 ff_h264_norm_shift 483 1E2 00194AA0 ff_h264_pred_init which I think are the correct exports you would need for the decode. However when I go to the YouTube link provided to test the HTML 5 integration of video I see, You must have an HTML5 capable browser. (http://www.youtube.com/html5#) I have the appropriate dll's I believe in the Chrome.exe directory but now it doesn't seem to load the dll stepping through as far as I can in the debugger. Any help would be appreciated. Thanks in advance, Rich --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium HTML 5 Integration using avcodec.dlls
Also make sure the filename is correct, it is avcodec-52.dll. Alpha 2009/7/9 Andrew Scherkus scher...@chromium.org Before we jump into debugging, where did you get your FFmpeg source code? The version and building instructions we use are documented here: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/mingw/ Andrew On Thu, Jul 9, 2009 at 3:17 PM, richard winterton rrwinter...@gmail.comwrote: Hi, I periodically have issues loading the avcodec.dll. I have build the avcodec.dll that contains the following H.264 exports: (I did have to disable mmx which I am not sure why as of yet) 461 1CC 00174100 ff_h264_decode_nal 462 1CD 0018AD20 ff_h264_decode_picture_parameter_set 463 1CE 001742F0 ff_h264_decode_rbsp_trailing 464 1CF 00189280 ff_h264_decode_sei 465 1D0 00189F90 ff_h264_decode_seq_parameter_set 466 1D1 00194D40 ff_h264_find_frame_end 467 1D2 0018C150 ff_h264_free_context 468 1D3 00190270 ff_h264_idct8_add4_c 469 1D4 0018FA60 ff_h264_idct8_add_c = _pred4x4_down_left_rv40_nodown_c 470 1D5 0018FE40 ff_h264_idct8_dc_add_c 471 1D6 0018FEA0 ff_h264_idct_add16_c 472 1D7 00190090 ff_h264_idct_add16intra_c 473 1D8 00190310 ff_h264_idct_add8_c 474 1D9 0018F690 ff_h264_idct_add_c 475 1DA 0018FDE0 ff_h264_idct_dc_add_c 476 1DB 0018F7E0 ff_h264_lowres_idct_add_c 477 1DC 0018F930 ff_h264_lowres_idct_put_c 478 1DD 0052C620 ff_h264_lps_range 479 1DE 0052C8A0 ff_h264_lps_state 480 1DF 0052C520 ff_h264_mlps_state 481 1E0 0052C820 ff_h264_mps_state 482 1E1 002C30A0 ff_h264_norm_shift 483 1E2 00194AA0 ff_h264_pred_init which I think are the correct exports you would need for the decode. However when I go to the YouTube link provided to test the HTML 5 integration of video I see, You must have an HTML5 capable browser. (http://www.youtube.com/html5#) I have the appropriate dll's I believe in the Chrome.exe directory but now it doesn't seem to load the dll stepping through as far as I can in the debugger. Any help would be appreciated. Thanks in advance, Rich --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium HTML 5 Integration using avcodec.dlls
I will try rebuilding the ffmpeg dll's from scratch after downloading the code again. Perhaps setting a asm int 3's inside of avcodec dll to see if I can see what is going on. Thanks for the help. -- Rich From: richard winterton rrwinter...@gmail.com Date: Thu, Jul 9, 2009 at 5:14 PM Subject: Re: [chromium-dev] Re: Chromium HTML 5 Integration using avcodec.dlls Yes the name of the dll is avcodec-52.dll as you suggested. But one think I did notice is that the build left the other dependent dll's unlabeled such as the avutil-.dll There isn't a version tag from the build that I have. I got the source from the suggested site but perhaps I left out a step or the the ./configure parameters weren't right and the version isn't set up correctly. (as meantioned I did a disabling of mmx to get it to compile). I will rebuild ffmpeg and see if I get the versioning and test the instructions you have set up again. So not to waste alot of your time do you know why the version information didn't get placed in the util dll? If I rename the avutil-.dll to avutil-52.dll Chromium complains it can't find avutil-.dll so I know the avcodec-52.dll is being loaded. Thanks for your help, Rich On Thu, Jul 9, 2009 at 4:22 PM, Alpha Lamhc...@chromium.org wrote: Also make sure the filename is correct, it is avcodec-52.dll. Alpha 2009/7/9 Andrew Scherkus scher...@chromium.org Before we jump into debugging, where did you get your FFmpeg source code? The version and building instructions we use are documented here: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/mingw/ Andrew On Thu, Jul 9, 2009 at 3:17 PM, richard winterton rrwinter...@gmail.com wrote: Hi, I periodically have issues loading the avcodec.dll. I have build the avcodec.dll that contains the following H.264 exports: (I did have to disable mmx which I am not sure why as of yet) 461 1CC 00174100 ff_h264_decode_nal 462 1CD 0018AD20 ff_h264_decode_picture_parameter_set 463 1CE 001742F0 ff_h264_decode_rbsp_trailing 464 1CF 00189280 ff_h264_decode_sei 465 1D0 00189F90 ff_h264_decode_seq_parameter_set 466 1D1 00194D40 ff_h264_find_frame_end 467 1D2 0018C150 ff_h264_free_context 468 1D3 00190270 ff_h264_idct8_add4_c 469 1D4 0018FA60 ff_h264_idct8_add_c = _pred4x4_down_left_rv40_nodown_c 470 1D5 0018FE40 ff_h264_idct8_dc_add_c 471 1D6 0018FEA0 ff_h264_idct_add16_c 472 1D7 00190090 ff_h264_idct_add16intra_c 473 1D8 00190310 ff_h264_idct_add8_c 474 1D9 0018F690 ff_h264_idct_add_c 475 1DA 0018FDE0 ff_h264_idct_dc_add_c 476 1DB 0018F7E0 ff_h264_lowres_idct_add_c 477 1DC 0018F930 ff_h264_lowres_idct_put_c 478 1DD 0052C620 ff_h264_lps_range 479 1DE 0052C8A0 ff_h264_lps_state 480 1DF 0052C520 ff_h264_mlps_state 481 1E0 0052C820 ff_h264_mps_state 482 1E1 002C30A0 ff_h264_norm_shift 483 1E2 00194AA0 ff_h264_pred_init which I think are the correct exports you would need for the decode. However when I go to the YouTube link provided to test the HTML 5 integration of video I see, You must have an HTML5 capable browser. (http://www.youtube.com/html5#) I have the appropriate dll's I believe in the Chrome.exe directory but now it doesn't seem to load the dll stepping through as far as I can in the debugger. Any help would be appreciated. Thanks in advance, Rich --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: span and Javascript
On Jul 9, 2009, at 11:44 AM, PhistucK wrote: It seems like status is a reserved word (so it does not give you the HTMLObject you wanted, but something internal that cannot be reached), try to use some other name. Try declaring it with var on first usage and see if that helps. (You have a bunch of other variables you're not declaring either.) FWIW, this page has the same problem in Safari too; so it's not related to the JS interpreter, but to the DOM. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Does those VC output matter?
Hi, I manage to build debug version of 3.0.190.2 on WinXP with VS2005. After I hit F5 to run Chrome, VS output a couple of lines about dlls loaded and followed by lines below: ... 'chrome.exe': Loaded 'C:\WINDOWS\system32\imm32.dll', No symbols loaded. 'chrome.exe': Loaded 'C:\WINDOWS\system32\lpk.dll', No symbols loaded. 'chrome.exe': Loaded 'C:\WINDOWS\system32\usp10.dll', No symbols loaded ... The thread 'Chrome_IOThread' (0x100c0) has exited with code 0 (0x0). The thread 'Chrome_FileThread' (0x1277c) has exited with code 0 (0x0). [76960:73860:8609:WARNING:notification_service.cc(128)] 1 notification observer(s) leaked of notification type 87 [76960:73860:8609:WARNING:notification_service.cc(128)] 1 notification observer(s) leaked of notification type 90 The thread 'BrokerEventThread' (0x12d38) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x12568) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x12c98) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1154c) has exited with code 0 (0x0). The program '[76960] chrome.exe: Native' has exited with code 0 (0x0). It reads several threads exited and some notifications leaked. I don't know what those line of messages mean. Although I Chrome still works well to browse web pages, are there internal errors within Chrome? -- Hua --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Meeting Notes From 2/9/2009 Now Posted!
Is it possible to continue posting these? external developers have requested it. -- Evan Stade On Wed, Feb 11, 2009 at 10:18 AM, Peter Kastingpkast...@google.com wrote: On Tue, Feb 10, 2009 at 6:19 PM, Glenn Wilson gwil...@chromium.org wrote: Meeting notes from February 9, 2009 are now posted on the Chromium developer documentation: http://sites.google.com/a/chromium.org/dev/developers/meeting-notes#02092009 Please contact me if you have any questions, and enjoy! It might be nice to post these on a blog somewhere, primarily so they can be grabbed via RSS; various Mozilla meeting notes are posted this way. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Meeting Notes From 2/9/2009 Now Posted!
We stopped posting because (a) the notes seemed not to be very useful out of context and (b) removing any Google-specific info, though it was minimal, was pretty labor intensive. I think it may be more productive to try to keep some public roadmaps and tasklists updated. Ian is working on creating an OWP roadmap that will be updated weekly with the status of the main areas of work. If that works out, perhaps we can do the same for other areas of the project. It seems like that would be more helpful and also more practical. Does that seem like it would meet the needs of the external developers? I want to make sure contributors have the info they need to be productive, but I don't want to create unnecessary work. Brian On Thu, Jul 9, 2009 at 8:10 PM, Evan Stade est...@chromium.org wrote: Is it possible to continue posting these? external developers have requested it. -- Evan Stade On Wed, Feb 11, 2009 at 10:18 AM, Peter Kastingpkast...@google.com wrote: On Tue, Feb 10, 2009 at 6:19 PM, Glenn Wilson gwil...@chromium.org wrote: Meeting notes from February 9, 2009 are now posted on the Chromium developer documentation: http://sites.google.com/a/chromium.org/dev/developers/meeting-notes#02092009 Please contact me if you have any questions, and enjoy! It might be nice to post these on a blog somewhere, primarily so they can be grabbed via RSS; various Mozilla meeting notes are posted this way. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
