Hi,
Can't we add a captcha to the registration
form of the trac to block SPAM bots?
br,
Ossy
Andras Becsi írta:
Hi,
Could someone who has the needed credentials ban
willetta...@yahoo.com
carstrow...@yahoo.com
tonygua...@gmail.com
mtjohnwo...@gmail.com
lindahom...@gmail.com
from trac
Hi,
On 18 September 2012 13:47, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
Hi,
Can't we add a captcha to the registration
form of the trac to block SPAM bots?
Would be good because spamming seems to escalate lately.
Some more addresses that regularly submitted spam links in recent months:
The spam filter plugin had not been installed on the new hardware, but I just
installed it, so the spamming should be better now. You can add new addresses
or patterns to the BadContent wiki page for any new spam. Previously I had kept
all of the Mac OS Forge BadContent lists in sync, but with
I was noticing today that http://www.webkit.org/ is quite old and out
of date. What xenon built 6 years ago, has stood up remarkably well,
but it may be time for a refresh.
(It also has no high-dpi support.)
I'm aware that I have the ability to change it. But I'm also inviting
others to do so:
On Sep 18, 2012, at 7:04 PM, Eric Seidel e...@webkit.org wrote:
I was noticing today that http://www.webkit.org/ is quite old and out
of date. What xenon built 6 years ago, has stood up remarkably well,
but it may be time for a refresh.
(It also has no high-dpi support.)
I'm aware that I
My preference would simply be to improve the Clang static analyser - it's free,
open source, etc.
I periodically run that analyzer on JSC, but apparently their ToT code has many
improvements over stable.
--Oliver
On Sep 17, 2012, at 9:20 PM, Brent Fulgham wrote:
Hi Gang,
On Sep 17, 2012,
Background: some of the storage systems use SerializedScriptValue to
persist structured-clonable objects (
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but the serialisation
is intentionally forwards compatible.
--Oliver
On Sep 18, 2012, at 12:36 PM, Adam Barth
What exactly are you trying to test here? The internal serialisation format
isn't exposed anywhere (nor should it be).
By definition newer formats won't be backwards compatible, or are you trying to
ensure that newer deserialisers will be able to continue to deserialise old
content?
--Oliver
Where do you test that property?
Adam
On Tue, Sep 18, 2012 at 12:43 PM, Oliver Hunt oli...@apple.com wrote:
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but
Sorry I totally left out the I expose this through Internals - and adam
has explained the rationale
On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt oli...@apple.com wrote:
What exactly are you trying to test here? The internal serialisation
format isn't exposed anywhere (nor should it be).
By
Hi,
I am working on a bad case that encoding detector doesn't recognize it.
So I created a bug, https://bugs.webkit.org/show_bug.cgi?id=97054, then try
to make a layout(regression) test case.
However, enabling encoding detector by javaScript manipulation seems not
feasible since encoding
Hi,
I just started working with webkit (specificially JSC) and am trying to
learn the codebase. I hope someone can bear with me enough to help me with
some questions:
1. I notice there are at least two implementations of hash tables in
JavaScriptCore/runtime, in Lookup.h and
Hi Stephen.
1. I notice there are at least two implementations of hash tables in
JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if
either, is used in, say, the normal case of accessing the properties of a DOM
element, like window.location, etc.? And assuming it's
On Wed, Sep 19, 2012 at 1:12 AM, Geoffrey Garen gga...@apple.com wrote:
Hi Stephen.
1. I notice there are at least two implementations of hash tables in
JavaScriptCore/runtime, in Lookup.h and PropertyMapHashTable.h. Which, if
either, is used in, say, the normal case of accessing the
Thanks! So is PropertyMapHashTable for properties that have been defined by
the user, or is it not that simple?
Yes.
Apologies. Basically, does the implementation of object property access in
the JIT codebase also use strings which have been made unique identifiers in
the same way as in
17 matches
Mail list logo
