Gregory Szorc wrote:
Up until now, the focus has been on making Makefile.in's themselves
generic and data-driven. We would use pymake's API to parse, load, and
extract data from Makefile.in's to construct the build definition. In
the long run, we'd realize that using make files for data
On Fri, Aug 17, 2012 at 1:48 PM, romaxa rom...@gmail.com wrote:
Hi,
Recently I have been working on B2G port to mobile Linux which would be
widget toolkit-independent (qt/gtk/cocoa/etc).
Some time ago Chris Lord did work on a widget toolkit independent
backend that had a similar focus[1].
Chris Hofmann schrieb:
Yeah, this is not for the other browser vendors or users, but is mostly
a benefit for web developers that want to count on certain behaviors to
work across browsers effectively and reliably every release of every
browser.
And as web developers write websites for users,
Ehsan Akhgari schrieb:
I suggest that the best place to develop this would be on
mozilla-central, especially since most of the work involved would
probably not be part of the build of any Tier 1 platform.
I agree on the m-c part, but given that a lot of the Linux world is
looking at maybe
On 22/08/2012 5:58 p.m., Mike Hommey wrote:
+1 for Lua - it seems perfect for this. For #1, I find it far easier
to read (and write) than Gyp, when it comes to things like
conditionals. For #8, we could just ship the entire runtime in the
tree for Tier 1 platforms (its small enough!), then its
Gregory Szorc schrieb:
We could go the route of GYP and shoehorn conditionals into a static
document (JSON) [3].
JSON is a good format for data for the most part, but IMHO we *really*
want comments in those files, and unfortunately JSON doesn't have those
and therefore probably must be
On Thu, Aug 23, 2012 at 01:07:34AM +1200, Blair McBride wrote:
On 22/08/2012 5:58 p.m., Mike Hommey wrote:
+1 for Lua - it seems perfect for this. For #1, I find it far easier
to read (and write) than Gyp, when it comes to things like
conditionals. For #8, we could just ship the entire runtime
On 12-08-22 12:43 PM, Jeff Hammel wrote:
TL;DR - python if we want/need a full language, JSON if we can get away
with POD
I think JSON is the wrong choice here. It will not satisfy the need for
conditionals, which causes us to invent terrible hacks inside the JSON
like we had to do with the
On 22/8/12 17:35, Ehsan Akhgari wrote:
I just landed the patches in bug 579517 which switch all of the code in
mozilla-central and comm-central [1] to use the standard integer types
as opposed to NSPR integer types. Here's what this means to you:
* If you're a developer, this will most likely
Jeff Hammel wrote:
While a bit of an unfair example, our buildbot-configs fall into this
category.
IMO not unfair at all.
(p.s. to stay on topic, +1 to all else you said)
~Justin Wood (Callek)
___
dev-platform mailing list
On 08/22/2012 12:29 PM, Gregory Szorc wrote:
Switching to something else also has another advantage: the
opportunity for a clean slate. I'm hoping we'll use the opportunity to
scrape away 10+ years of cruft.
I support the sentiment, though this reasoning always makes me cautious,
as it
On 08/22/12 04:38 PM, Gregory Szorc wrote:
Let's think of what can be done to secure/limit Python. Disabling import
has already been mentioned. That's a start.
I think it's worth noting that even if you *do* limit what you can do
through some technical means, you still have the option to change
On Wed, Aug 22, 2012 at 3:38 PM, Gregory Szorc g...@mozilla.com wrote:
Let's think of what can be done to secure/limit Python. Disabling import
has already been mentioned. That's a start.
What about the ast module [1]? I /think/ it could be used to ensure parsed
code conforms to whatever we
bholley and I have a script for doing this in git. With thanks to
glandium for telling us how to do it:
0. Fetch the prtypes change, and merge it into your local master branch.
1. Let your git checkout be directory |src|.
2. Save the script at the end of this message as src/../convert.sh.
3.
On Thu, Aug 23, 2012 at 8:40 AM, Ben Hearsum bhear...@mozilla.com wrote:
On 08/22/12 04:38 PM, Gregory Szorc wrote:
Let's think of what can be done to secure/limit Python. Disabling import
has already been mentioned. That's a start.
I think it's worth noting that even if you *do* limit
15 matches
Mail list logo
