On Wed, Aug 22, 2012 at 1:36 AM, Gregory Szorc wrote:
> Up until now, the focus has been on making Makefile.in's themselves generic
> and data-driven [1]. 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 real
On 08/22/2012 11:19 PM, Mike Hommey wrote:
On Wed, Aug 22, 2012 at 01:38:22PM -0700, Gregory Szorc wrote:
On 8/22/12 1:00 PM, Ben Hearsum wrote:
On 08/22/12 12:43 PM, Jeff Hammel wrote:
If we do go with python, it would be nice to keep the configuration
files as much configuration as possible.
On Wed, Aug 22, 2012 at 01:38:22PM -0700, Gregory Szorc wrote:
> On 8/22/12 1:00 PM, Ben Hearsum wrote:
> >On 08/22/12 12:43 PM, Jeff Hammel wrote:
> >>If we do go with python, it would be nice to keep the configuration
> >>files as much configuration as possible. The reason I question having
> >>
On Wed, Aug 22, 2012 at 04:12:30PM -0700, Justin Lebar wrote:
> 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|.
So...
Data-only formats such as JSON are too weak -- no comments, no conditionals.
Full languages (e.g. Python, Lua) are too powerful, which means it's
too tempting to use the full language features.
Should you invent something new? If it's just lists, maps, comments
and conditionals, that shou
On Thu, Aug 23, 2012 at 8:40 AM, Ben Hearsum 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 what you can do
>
What is going to happen to PRTime? Is that going away too?
Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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. F
On Wed, Aug 22, 2012 at 3: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.
>
> What about the ast module [1]? I /think/ it could be used to ensure parsed
> code conforms to whatever we allow. e.g.
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 chang
On 8/22/12 1:00 PM, Ben Hearsum wrote:
On 08/22/12 12:43 PM, Jeff Hammel wrote:
If we do go with python, it would be nice to keep the configuration
files as much configuration as possible. The reason I question having
any "full" language as a configuration language is that in practice I
see a l
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 oft
On 08/22/12 12:43 PM, Jeff Hammel wrote:
> If we do go with python, it would be nice to keep the configuration
> files as much configuration as possible. The reason I question having
> any "full" language as a configuration language is that in practice I
> see a lot of logic creep in to "configura
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
dev-platform@lists.mozilla
On 8/22/12 2:02 AM, Neil wrote:
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 u
On 12-08-22 3:18 PM, Jonathan Kew wrote:
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 y
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 b
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 08/22/2012 06:50 AM, Benjamin Smedberg wrote:
On 8/21/2012 7:36 PM, Gregory Szorc wrote:
On the other end of the spectrum, we could have the build manifest
files be Python "scripts." This solves a lot of problems around
needing functionality in the manifest files. But, it would be a
pot
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 bitrot your patches. You
can use this
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 ent
On 8/21/2012 7:36 PM, Gregory Szorc wrote:
On the other end of the spectrum, we could have the build manifest
files be Python "scripts." This solves a lot of problems around
needing functionality in the manifest files. But, it would be a
potential foot gun. See requirement #7.
I don't think
Hi,
Am 17.08.2012 20:03, schrieb romaxa:
> Some people already expressed interest in working with me on this so
> I'm trying to figure out what is the best place to park the code we
> are going to work on.
>
> Would it make sense to land initial build/run configuration support
> into mozilla-cent
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 thrown
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
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 gett
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, th
On Fri, Aug 17, 2012 at 1:48 PM, romaxa 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]. His work was t
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 defini
29 matches
Mail list logo
