On May 19, 5:05 am, jer...@martinfamily.freeserve.co.uk wrote:
> Thanks for explaining a few things to me. So it would seem that
> replacing the GIL with something which allows better scalability of
> multi-threaded applications, would be very complicated. The paper by
> Jesse Nolle which I referen
On Apr 17, 9:59 am, SpreadTooThin wrote:
> You know this is just insane. I'd be satisfied with a CRC16 or
> something in the situation i'm in.
> I have two large files, one local and one remote. Transferring every
> byte across the internet to be sure that the two files are identical
> is just n
On Apr 17, 9:59 am, norseman wrote:
> The more complicated the math the harder it is to keep a higher form of
> math from checking (or improperly displacing) a lower one. Which, of
> course, breaks the rules. Commonly called improper thinking. A number
> of math teasers make use of that.
Of cou
On Apr 17, 5:30 am, Tim Wintle wrote:
> On Thu, 2009-04-16 at 21:44 -0700, Adam Olsen wrote:
> > The Wayback Machine has 150 billion pages, so 2**37. Google's index
> > is a bit larger at over a trillion pages, so 2**40. A little closer
> > than I'd like, but th
On Apr 16, 4:27 pm, "Rhodri James"
wrote:
> On Thu, 16 Apr 2009 10:44:06 +0100, Adam Olsen wrote:
> > On Apr 16, 3:16 am, Nigel Rantor wrote:
> >> Okay, before I tell you about the empirical, real-world evidence I have
> >> could you please accept that hashe
On Apr 16, 11:15 am, SpreadTooThin wrote:
> And yes he is right CRCs hashing all have a probability of saying that
> the files are identical when in fact they are not.
Here's the bottom line. It is either:
A) Several hundred years of mathematics and cryptography are wrong.
The birthday problem
On Apr 16, 8:59 am, Grant Edwards wrote:
> On 2009-04-16, Adam Olsen wrote:
> > I'm afraid you will need to back up your claims with real files.
> > Although MD5 is a smaller, older hash (128 bits, so you only need
> > 2**64 files to find collisions),
>
> You don&
On Apr 16, 3:16 am, Nigel Rantor wrote:
> Adam Olsen wrote:
> > On Apr 15, 12:56 pm, Nigel Rantor wrote:
> >> Adam Olsen wrote:
> >>> The chance of *accidentally* producing a collision, although
> >>> technically possible, is so extraordinarily rare that
On Apr 15, 12:56 pm, Nigel Rantor wrote:
> Adam Olsen wrote:
> > The chance of *accidentally* producing a collision, although
> > technically possible, is so extraordinarily rare that it's completely
> > overshadowed by the risk of a hardware or software failure produci
On Apr 15, 11:04 am, Nigel Rantor wrote:
> The fact that two md5 hashes are equal does not mean that the sources
> they were generated from are equal. To do that you must still perform a
> byte-by-byte comparison which is much less work for the processor than
> generating an md5 or sha hash.
>
> I
On Apr 13, 8:39 pm, Grant Edwards wrote:
> On 2009-04-13, Peter Otten <__pete...@web.de> wrote:
>
> > But there's a cache. A change of file contents may go
> > undetected as long as the file stats don't change:
>
> Good point. You can fool it if you force the stats to their
> old values after you
On Apr 8, 8:09 am, George Sakkis wrote:
> On Apr 7, 3:18 pm, Adam Olsen wrote:
>
> > On Apr 6, 3:02 pm, George Sakkis wrote:
>
> > > For example, it is common for a function f(x) to expect x to be simply
> > > iterable, without caring of its exact type. Is it
On Apr 6, 3:02 pm, George Sakkis wrote:
> For example, it is common for a function f(x) to expect x to be simply
> iterable, without caring of its exact type. Is it ok though for f to
> return a list for some types/values of x, a tuple for others and a
> generator for everything else (assuming it'
On Feb 27, 9:55 am, Falcolas wrote:
> If order did matter, and the list itself couldn't be stored in memory,
> I would personally do some sort of hash of each item (or something as
> simple as first 5 bytes, last 5 bytes and length), keeping a reference
> to which item the hash belongs, sort and i
On Feb 23, 7:18 pm, bvdp wrote:
> Gabriel Genellina wrote:
> > En Mon, 23 Feb 2009 23:31:20 -0200, bvdp escribió:
> >> Gabriel Genellina wrote:
> >>> En Mon, 23 Feb 2009 22:46:34 -0200, bvdp escribió:
> Chris Rebert wrote:
> > On Mon, Feb 23, 2009 at 4:26 PM, bvdp wrote:
>
> > [pro
On Feb 21, 10:48 am, a...@pythoncraft.com (Aahz) wrote:
> In article <499f397c.7030...@v.loewis.de>,
>
> =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= wrote:
> >> Yes, I know that. But every concrete representation of a unicode string
> >> has to have an encoding associated with it, including unic
, or more blocks of shared memory created more easily. On the other
> hand, the creation of shared memory blocks shouldn't be a high-use operation
> in a program that has sufficient number crunching to do to be able to
> consume multiple cores/CPUs.
>
>> Or use safethread. It impose
e copies of shared
> bytecode, likely, and maybe also a compilation performance savings. So it
> sounds like a win, but it is a win that can deferred for initial simplicity,
> to prove the concept is or is not workable.
>
> A monitor allows a single thread to run at a time; that is the same
> situation as the present GIL. I guess I don't fully understand your model.
To use your terminology, each monitor is a context. Each thread
operates in a different monitor. As you say, most C functions are
already thread-safe (reentrant). All I need to do is avoid letting
multiple threads modify a single mutable object (such as a list) at a
time, which I do by containing it within a single monitor (context).
--
Adam Olsen, aka Rhamphoryncus
--
http://mail.python.org/mailman/listinfo/python-list
other types (int, list, etc) need only __cmp__.
Code which uses <= to compare sets would be assumed to want subset
operations. Generic containers should use cmp() exclusively.
[1] http://mail.python.org/pipermail/python-3000/2007-October/011072.html
--
Adam Olsen, aka Rhamphoryncus
--
http://mail.python.org/mailman/listinfo/python-list
my question: does somebody have a globals benchmark that shows a
really significant slowdown vs local variables?
--
Adam Olsen, aka Rhamphoryncus
--
http://mail.python.org/mailman/listinfo/python-list
. That could be fixed
with with a before/after check of ma_mask.
And if you're *really* feeling paranoid you could add reference
counting to ma_table. I doubt anybody cares quite that much though.
;)
--
Adam Olsen, aka Rhamphoryncus
--
http://mail.python.org/mailman/listinfo/python-list
conditions I outlined, letting the attack succeed.
So there you have it: if you're using a dict with custom classes (or
anything other than str) across multiple threads, and without locking
it, it's possible (though presumably extremely rare) for a lookup to
fail even through the key wa
is forcing you to use characters above 0x". This is a
strawman. Unicode goes beyond 0x because real languages need it.
Software should not break just because the user speaks a different
language than the programmer.
Thoughts, from all you readers out there? For/against? If there
t is that a small audience is not going to draw enough
attention to get the effort it requires. I agree absolutely that the
material it contains is important. That's why I feel it should be
merged with the other documents, to ensure that it really does get
maintained.
--
Adam Olsen, aka Rhamp
e of time when the target audience is
perhaps a few dozen people. Make it useful for everybody and it'll be
worth maintaining.
--
Adam Olsen, aka Rhamphoryncus
--
http://mail.python.org/mailman/listinfo/python-list
25 matches
Mail list logo
