On 15 March 2016 at 04:32, Nick Coghlan wrote:
> On 15 March 2016 at 10:49, Martin Panter wrote:
>> One more idea I am considering is to decouple the makefile rules from
>> the main build. So to update the generated files you would have to run
>> a separate command like “make graminit” or “make f
On 15 March 2016 at 10:49, Martin Panter wrote:
> One more idea I am considering is to decouple the makefile rules from
> the main build. So to update the generated files you would have to run
> a separate command like “make graminit” or “make frozen”. The normal
> build would never regenerate the
I have no vested interest in this, other than the continuing work we have
done to make Jython compatible with OpenSSL's model, warts and all.
But the fact that BoringSSL cleans up the OpenSSL API (
https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md), at the
cost of possible backwards b
On 14 March 2016 at 13:26, R. David Murray wrote:
> On Mon, 14 Mar 2016 03:04:08 -, "Gregory P. Smith"
> wrote:
>> On Sun, Mar 13, 2016 at 7:41 PM Martin Panter wrote:
>> > Include/graminit.h
>> > Python/graminit.c
>> > Python/importlib.h
>> > Python/importlib_external.h
>> >
>> > A questio
On Mon, Mar 14, 2016 at 4:56 PM Nathaniel Smith wrote:
> Should people outside google pay attention to boringssl? The first
> thing it says on the website is:
>
> "Although BoringSSL is an open source project, it is not intended for
> general use, as OpenSSL is. We don’t recommend that third part
Should people outside google pay attention to boringssl? The first
thing it says on the website is:
"Although BoringSSL is an open source project, it is not intended for
general use, as OpenSSL is. We don’t recommend that third parties
depend upon it. Doing so is likely to be frustrating because t
Don't forget BoringSSL.
On Wed, Mar 9, 2016 at 9:30 AM Michael Felt wrote:
> Can look at it. There has been a lot of discussion, iirc, between OpenSSL
> and LibreSSL re: version identification.
> Thx for the reference.
>
>
> On 08-Mar-16 14:55, Hasan Diwan wrote:
>
>
> On 8 March 2016 at 00:49,
2016-02-12 14:31 GMT+01:00 M.-A. Lemburg :
>>> If your program has bugs, you can use a debug build of Python 3.5 to
>>> detect misusage of the API.
>
> Yes, but people don't necessarily do this, e.g. I have
> for a very long time ignored debug builds completely
> and when I started to try them, I f
2016-03-09 18:54 GMT+01:00 Brett Cannon :
>>> https://docs.python.org/dev/c-api/memory.html#c.PyMem_SetupDebugHooks
>>
>> The main advantage of this variable is that you don't have to
>> recompile Python in debug mode to benefit of these checks.
>
> I just wanted to say this all sounds awesome! Tha
On 03/14/2016 05:34 PM, Xavier de Gaye wrote:
> Changeset c2a53aa27cad [1] was commited in issue 22359 [2] to remove incorrect
> uses of recursive make. The changeset added executable binaries as
> prerequisites to the existing rules (Python/importlib.h and $(GRAMMAR_H)).
> This broke cross-compi
On 03/14/2016 02:26 PM, R. David Murray wrote:
>
> The repo-timestamp problem is addressed by the 'make touch' target.
>
> And yes, checking in these platform-independent artifacts is very
> intentional: less to build, fewer external dependencies in the build
> process...you don't need to *have* p
On Mon, 14 Mar 2016 03:04:08 -, "Gregory P. Smith" wrote:
> On Sun, Mar 13, 2016 at 7:41 PM Martin Panter wrote:
>
> > On 13 March 2016 at 01:13, Russell Keith-Magee
> > wrote:
> > > The patches that I've uploaded to Issue23670 [1] show a full
> > cross-platform
> > > [1] http://bugs.python
On 14 March 2016 at 13:04, Gregory P. Smith wrote:
> They should not be regenerated every build, if they are, that seems like a
> bug in the makefile to me (or else the timestamp checks that make does vs
> how your code checkout happened). Having them checked in is convenient for
> cross builds a
13 matches
Mail list logo
