Re: FW: Removal of language features
On 7/26/17 at 3:18 PM, brendan.e...@gmail.com (Brendan Eich) wrote: If you are concerned about JS pedagogy or marketing, the solution already practiced is to subset. Just as when teaching English or another evolved, irregularity-ridden living language. The real problem with bloat is reading code, not writing it. However, if a reader can easily look up a nearly abandoned, but still supported, construct to find out what it does and what footguns it includes, that situation is probably better than having some unmaintained web site fail when a new version of a browser comes out that no longer supports that construct. YMMV - Bill - Bill Frantz| Re: Hardware Management Modes: | Periwinkle (408)356-8506 | If there's a mode, there's a | 16345 Englewood Ave www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On 8/27/15 at 11:51 PM, niloy.monda...@gmail.com (Niloy Mondal) wrote: x ** y ** z is easier to read/write than x.pow(y.pow(z)) As a language guru, you know which operation will be performed first. As Joe programmer, I don't and I would need to write it as x ** (y ** z). With some operations, like +, the order doesn't matter and x + y + z is not confusing. Cheers - Bill --- Bill Frantz|We used to quip that password is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.pwpconsult.com | learned anything about security? -- Bruce Schneier ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)
While I am also concerned with the problem of ever-expanding languages because the larger they grow, the harder they are to learn, and the harder it is to read someone else's code which uses unfamiliar features, there are other issues that are equally important. I find the most unappreciated feature of a language is the list of things it can't do. For a bit of background, my first program was written in machine language, and after struggling with it, the instructor introduced the class to a wonderful tool: assembler language. Sufficient to say, I know about languages with built in footguns. The advantage of having a language that doesn't allow certain things is that you don't have to worry about them when you are debugging or reviewing a program. Memory safety is high on the list of useful features which JS has. Another very valuable feature is the ability to limit what a piece of code can do before you invoke it. In the JS arena, this kind of limitation allows web sites which give their users security assurances to run arbitrary JS provided by advertisers. ES2015 has a number of features to support this usage, but because of the need to not break the web, they are a bit delicate to use. It would be good to include a list of the things you can't do in the language specification so failures in this area are clearly bugs in either the implementation or the specification. I would suggest for JS that this list include the things required for confining a piece of JS code running within a larger environment, like a web page to keep it from doing all the things the web page can do. Cheers - Bill --- Bill Frantz| Ham radio contesting is a| Periwinkle (408)356-8506 | contact sport. | 16345 Englewood Ave www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Supporting feature tests directly
On 3/26/15 at 8:51 AM, get...@gmail.com (Kyle Simpson) wrote: As I mentioned near the beginning of this thread, `Reflect.parse(..)` would generally suit the proposed use-case, except it does a lot of extra work (creating and returning a tree -- a value that then I'd be throwing away creating unnecessary GC) that feature testing itself doesn't need. It's unclear that `Reflect.parse(..)` would provide any additional performance gains over the current `eval` / `Function` approach, and could even be potentially worse. I don't see a real need for high performance in these tests. AFAICS, they occur once, probably at load time. A smart JS implementation might even parse the Reflect.parse() string at the same time it is parsing the main set of JS code. As such, the extra overhead for CPU and GC will probably be swamped by the communication CPU and transmission times. Not using eval makes it more likely that you will be able to perform the tests in safe subsets of JS. Cheers - Bill --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Early error on '0' followed by '8' or '9' in numeric literals does not seem to be web-compatible
On 8/5/14 at 8:05 AM, erig...@google.com (Mark S. Miller) wrote: Because of compatibility constraints, JS history can generally proceed only in an additive manner, which means a steady degradation of quality along the simplicity dimension. An opt-in mode switch is the only way to escape that dynamic. Strict mode is the only one we've got, and the only one we're likely to have in the foreseeable future. Strict mode should not accept octal literals. Regarding sloppy mode, it continues to exist only for the sake of legacy compat, so adding more crap to it for better web compat is the right tradeoff -- as long as the crap stays quarantined within sloppy mode. On Tue, Aug 5, 2014 at 7:56 AM, Mathias Bynens math...@qiwi.be wrote: ... In section 11.8.3 (Numeric Literals), the definition for `DecimalIntegerLiteral` should somehow be tweaked to match that of `DecimalDigits`, with the exception that if the first digit is `0` and all other digits are octal digits (0-7) it must be treated as a legacy octal literal. So this horrible footgun, changing the value of a constant changes its radix, is only lurking in sloppy mode. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterator current/prev value
On 3/23/14 at 11:24 AM, bren...@mozilla.org (Brendan Eich) wrote: Marcus Stade wrote: This is assuming that the `current` or `prev` property is indeed implemented by the engine and not user land, as that indeed both carries implementation cost and the risk out running out of sync. Is there any way other than generator functions to implement iterators? Are any ol' object with a function called `next` an iterator? Any old object. It's a structural or duck-typed protocol. We won't therefore be adding complexity, which is also bad on its own. KISS wins here. More elaborate protocols for harder or let's say rarer cases are fine and not part of the mandatory minimum. It seems it should be easy for any user or library to introduce in generalized intermediate object which implements the `current` or 'prev' property, so it doesn't need to be in the language. Cheers - Bill --- Bill Frantz| Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Source maps (was: Multiline Strings)
On 3/14/14 at 3:02 PM, fitz...@gmail.com (Nick Fitzgerald) wrote: I feel very strongly that users debugging their sources that were compiled to js should be able to set watch expressions and conditional breakpoints in their source language. My experience with debuggers says the while the vast majority of the time you want to be able to debug it in the language you wrote, sometimes you want to debug it in the language it broke in. Being able to look at the lower level language can clear up misconceptions about what a higher level construct means. It can also reveal compiler bugs. It should also be recognized that all compiled programs break in machine language. :-) Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Symbol.keyFor
In KeyKOS we used the word name. We had another meaning for the word key and wanted to avoid confusion. Cheers - Bill On 12/22/13 at 9:57 PM, a...@rauschma.de (Axel Rauschmayer) wrote: Offhand, ID instead of key, but that is awfully generic. It may make sense to invent a new term. On Dec 22, 2013, at 6:53 , Mark S. Miller erig...@google.com wrote: Suggestions? On Sat, Dec 21, 2013 at 9:48 PM, Axel Rauschmayer a...@rauschma.de wrote: One problem with that method name: it overloads the term “key”. At the moment, property keys are either strings or symbols. If a symbol can also have a key, I’d find that confusing. Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM --- Bill Frantz| I wish there was a knob on the TV to turn up the 408-356-8506 | intelligence. There's a knob called brightness, but www.pwpconsult.com | it doesn't work. -- Gallagher ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not private symbols?
On 7/31/13 at 8:35 AM, bren...@mozilla.com (Brendan Eich) wrote: uuidgen implementations have used MAC addresses in the past, which I believe led to a public collision. In 1998 we (Electric Communities) discovered that people using AOL software to access the internet were all assigned the same MAC address. Using timing of UI events is much better. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
On 6/13/13 at 12:24 PM, oli...@apple.com (Oliver Hunt) wrote: I believe that the spec should mandate a stable sort, but i'm not sure just how far we can go in trying to standardize exact behavior of the sort without tying implementations to a single implementation for all time. One possibility which will allow implementations to include a more performant sort is to specify two sorts: sort - which is stable unstablestort - which is either an alias for sort or is a faster unstable sort. Cheers - Bill --- Bill Frantz|Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges - Mark Miller www.pwpconsult.com | ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array#sort() implementations not interoperable
On 6/13/13 at 3:53 PM, feli...@gmail.com (felix) wrote: Always-unstable is trivial... Not really. Doing it with a test case that has only one record is hard. It is also hard if the test case has all different records (according to the sort field(s). BTW _ I think having only one sort which is stable is a good solution if performance of sort is not a burning concern. Cheers - Bill --- Bill Frantz| Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On 5/1/13 at 5:43 PM, fra...@pwpconsult.com (Bill Frantz) wrote: On 5/1/13 at 1:37 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: Ah, I'm not proposing that we augment the base Future class with cancellation properties. I explicitly used the term subtype in the quoted bit above. *Some* of Ron's suggestions were to augment the base Future class, but not all of them, and several other people pushed back on that. I think that covers the issue. Cheers - Bill Upon further reflection, I think the point about premature standardization stands. Also, a pure inheritance model -- which is implied by subclassing -- may be the wrong model. If one wants to include POLA in one's programming style, one will probably want to separate the authority to access the resulting value from the authority to abort the computation. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
[General comments here, specifics inline.] My experiences with promises is as an E programmer. When they are used pervasively in an application the graph can get as messy as the reference graph of an object oriented program. For languages with objects and references, garbage collection became the generally accepted way of cleaning up the mess (c.f. C++). For promises, breaking the promise allows the graph to be cleaned up. On 4/30/13 at 11:04 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: Every future is cancellable already. If you hand out your resolver, anyone with it can preempt you and (prematurely?) fulfill the promise, before your intended code-path finishes. There are only two small differences between normal promises and ones that are explicitly cancellable: This comment seems to be the essence of the issue. You can hold the resolver at the edge of a abortable computation. When you decide to abort the computation, perhaps because one or more consumers have indicated they are no longer interested in the results, you can use the resolver to resolve the promise as broken. That broken promise will filter up through all computations which depend on it's value, allowing them to proceed knowing that the value will not be produced. 1. Some promises are holding onto resources (locks, network connections, cpu time) which will be disposed of when they're finished. I think this statement is wrong. Promises don't hold resources. They are a placeholder for a value to be provided later. Perhaps the computation which may provide the value at some future time holds a resource, or the computation which will consume the value when it is resolved holds a resource (generally a poor programming practice), but the promise itself doesn't hold resources. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On 5/1/13 at 11:13 AM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: I think you're making this far too complicated. It's much simpler than this: 1. XHR is a very reasonable API to Future-ize. 2. XHRs are cancellable. 3. Ergo, we should have a cancellable Future subtype. Why make it more complex than necessary. While a XHR implementation may wish to add a cancel operation, JS is a broader language than just the web. There are use cases that don't need cancel and they should not have to pay the costs of the additional communication paths that cancel will require. With a simple promise, others can build objects which use the promise as an internal component and provide cancel or other useful operations. Leaving the implementations of these other operations to libraries will allow experimentation to proceed standardization. Cheers - Bill --- Bill Frantz| Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Future cancellation
On 5/1/13 at 1:37 PM, jackalm...@gmail.com (Tab Atkins Jr.) wrote: Ah, I'm not proposing that we augment the base Future class with cancellation properties. I explicitly used the term subtype in the quoted bit above. *Some* of Ron's suggestions were to augment the base Future class, but not all of them, and several other people pushed back on that. I think that covers the issue. Cheers - Bill --- Bill Frantz| Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Promises in E (was Re: A Challenge Problem for Promise Designers)
Let me take a crack at describing E's support for promises. E has two modes for sending a message to an object. There is the immediate send and the eventual send. If the Object is an unresolved promise the immediate send will trap. (A promise can be forced to resolve using the when construct.) If the program uses eventual sends, then unresolved promises act like any other value. This allows operations such as: Object A on machine 1 Object B on machine 2 A sends to B getting back object C also hosted on machine 2 A sends to C getting back a final result. The way this is implemented is that when A sends to B, a promise for the result C is constructed. When A sends to C, that promise is used for the send and a promise for the final result is constructed. The message to C is sent without waiting for the response from the message to B, eliminating one round trip communication delay. If A needs to use the final result in an immediate operation, it will wait for the final result promise to be resolved using the when construct. Cheers - Bill --- Bill Frantz| I like the farmers' market | Periwinkle (408)356-8506 | because I can get fruits and | 16345 Englewood Ave www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises in E (was Re: A Challenge Problem for Promise Designers)
Thanks for making these issues clearer to me Mark. I am beginning to get some idea of the problems that JS promises face given that they must have an object-like appearance. I like the fact that in E, promises just work and I think of Joule as a language where every value is a promise and computation will take place when the data is ready. Cheers - Bill On 4/26/13 at 9:43 AM, erig...@google.com (Mark S. Miller) wrote: Hi Bill, I think I know what you mean by these terms, and what I think you mean is correct ;). But given the history of promises and futures, you make two unfortunate and confusing terminology choices: forced and wait. Instead, E promises, like all JS promises, are inherently non-blocking. The when (aka then) doesn't force or wait or block, it registers the callback[s] to be called in a later turn of the event loop sometime after the promise they are registered on is fulfilled or broken (aka fulfilled or rejected). The when immediately returns a promise for what the invoked callback will return. In all these ways, E promises are like modern JS promises. None of this however addresses the prior question about E promises. E promises were inspired by Joule Channels and Xanadu promises, both of which were at least as influenced by Concurrent Prolog logic variables as they were by previous promise/future systems[1]. As with logic variables, once an E promise is fulfilled with a value, it is that value, i.e., it is not observably different from that value. The E equality tests will judge it to be identical to its fulfillment. In Actor or Smalltalk terms, one could say it becomes that value. This was viable in E for reasons not available in JS, and so a JS promise fulfilled with a value remains distinct from the value itself. The formalism that originally inspired modern JS promises is thus the logic variables of concurrent logic programming; so the similarity of the resulting abstractions in some ways to monads surprised me. The reason this works in E is indeed touched on by your email -- an unresolved (aka pending) E promise is a kind of reference, not a kind of object, and so does not have its own methods. Using . on a pending E promise is an error. Using - (aka !) on an E promise invokes the object it is a promise for, rather than invoking the promise itself[2]. when is something one does to a promise, not something one asks a promise to do. It is the extreme form of the featurelessness that Kevin raises. [1] See Chapter 23 of http://erights.org/talks/thesis/markm-thesis.pdf From Objects to Actors and Back Again [2] Not quite true. There are three eventual messages that are a visible part of the promise infrastructure: __whenMoreResolved, __whenBroken, and __reactToLostClient. The first two are understood by the promises. The last is emitted by promises on partition. But none of these are part of the normal use experience -- hence the two initial underbars in their names. JS promises achieve the needs these serve by other means. On Fri, Apr 26, 2013 at 6:03 AM, Bill Frantz fra...@pwpconsult.com wrote: Let me take a crack at describing E's support for promises. E has two modes for sending a message to an object. There is the immediate send and the eventual send. If the Object is an unresolved promise the immediate send will trap. (A promise can be forced to resolve using the when construct.) If the program uses eventual sends, then unresolved promises act like any other value. This allows operations such as: Object A on machine 1 Object B on machine 2 A sends to B getting back object C also hosted on machine 2 A sends to C getting back a final result. The way this is implemented is that when A sends to B, a promise for the result C is constructed. When A sends to C, that promise is used for the send and a promise for the final result is constructed. The message to C is sent without waiting for the response from the message to B, eliminating one round trip communication delay. If A needs to use the final result in an immediate operation, it will wait for the final result promise to be resolved using the when construct. Cheers - Bill --**--** --- Bill Frantz| I like the farmers' market | Periwinkle (408)356-8506 | because I can get fruits and | 16345 Englewood Ave www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032 --- Bill Frantz| I wish there was a knob on the TV to turn up the 408-356-8506 | intelligence. There's a knob called brightness, but www.pwpconsult.com | it doesn't work. -- Gallagher ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On 4/1/13 at 5:40 AM, sa...@ccs.neu.edu (Sam Tobin-Hochstadt) wrote: Using `.dispose()` is manual management of the allocation and deallocation of object. Manual memory management is fundamentally non-modular -- you can't encapsulate it in a library, and it requires describing memory management behavior in all your function specifications, the way that C libraries do. It's certainly possible to write large, complex apps in C. But that's not evidence that we should bring those practices to JS. There are a bunch of different reasons for wanting to dispose an object in memory. With the malloc/free system from C, you usually dispose objects to recover their backing memory for future use. The C version is not memory safe. If you are paying for the memory, you may be willing to break things to be able to stop paying. There may be some other reasons for causing an object to stop working and as a side effect recover most of its memory. A proxy can provide this service for JS, along with a number of other techniques all of which will be memory safe. For short-lived programs, you can ignore memory disposal if the system running them will free the memory when they exit. This technique is memory safe and even works with mismanagement of references in a garbage collected systems. Having a system which supports just exiting and recovering memory is valuable for ad-hoc programming environments. It might also be valuable for ads running in long-lived web pages. Possibly some of the safe JS execution environments provide this service for the programs they mediate. Memory safety is one really good reason to choose JS over C. Cheers - Bill --- Bill Frantz| The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself. - FDR | 16345 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a future caller alternative ?
It should be pointed out that KeyKOS resume keys could, like
proper tail-call optimization, eliminate the ability to walk
the stack to determine the caller. In KeyKOS, the process had
direct control over usage of the resume key. It could pass it to
an object is was calling in place or creating a resume key to
itself with a normal call. This loss of ability to walk the
stack is much like tail-call optimization of:
function a(args) {
... some calculation
return b(otherargs);
}
Where the optimization passes the address of a's caller as the
return address for b and b can't see a's activation record on
the stack.
Cheers - Bill
On 3/9/13 at 6:57 PM, erig...@google.com (Mark S. Miller) wrote:
Another way to view the phrase debugging API is properly stratified
privileged reflection API. Indeed, the famous Mirrors paper used JPDA as
an example of a properly stratified reflection system. The key thing about
debugging APIs is they get the privilege separation right -- because they
must. A well designed mirror system or mirror-like system could as well. I
have discussed this repeatedly with the co-authors of that paper -- Dave
Ungar and Gilad Bracha (cc'ed) -- and IIRC they enthusiastically agree. The
KeyKOS operating system had an operation for rights-amplifying a start
key or resume key to a domain key. In our terms, a start key is like a
closure reference and a domain key is like a reference to the reified
lexical environment captured by that closure, i.e., a mirror on the state
of that closure. A resume key is like a continuation, so reflecting on
resume keys -- if you have the privileges needed to do so -- enables one to
effectively walk back the stack of outstanding IPC requests. The logic by
which KeyKOS (and its descendants EROS, CapROS, GuardOS, Coyotos) managed
the right-to-reflect could be a good starting point for doing likewise with
language-based mirrors.
---
Bill Frantz| Concurrency is hard. 12 out | Periwinkle
(408)356-8506 | 10 programmers get it wrong. | 16345
Englewood Ave
www.pwpconsult.com |- Jeff Frantz | Los Gatos,
CA 95032
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: What is the status of Weak References?
On 3/2/13 at 3:47 AM, bruan...@gmail.com (David Bruant) wrote: I won't say it's absolutely better than WeakRefs and it may not apply to the data binding case (?), but it's an interesting pattern to keep in mind. Speaking from ignorance here. One advantage of the resubscribe for every event pattern is that if the events are generated in one process -- an animation process is the example used here -- and a message is sent to the observer in another process, and the observer is slow, the natural outcome will be to drop frames instead of queue up a lot of messages pertaining to events that no longer need to be processed. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: excluding features from sloppy mode
On 12/27/12 at 11:36 PM, bren...@mozilla.com (Brendan Eich) wrote: To find the governing use strict; in a large program or (real bugs bit ES5 here) concatenation is not easy. I would want syntax coloring here. Perhaps a light blue background for strict mode and a light pink one for sloppy. Then the letters could continue to be colored as the editor/IDE wishes. YMMV. Cheers - Bill --- Bill Frantz| If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: (Map|Set|WeakMap)#set() returns `this` ?
On 12/5/12 at 1:50 AM, jussi.kallioko...@gmail.com (Jussi Kalliokoski) wrote: I personally think returning `this` in absence of any meaningful value (and chaining in general) is a bad pattern. /lurk I have to agree with Jussi here. Whenever I consider chaining using the returned values from the various things called, my programming paranoia hair stands on end. Let me try to explain: Whenever I program, I try to trust as little code as possible. With chaining, there are two possibilities for getting the wrong answer in the returned value: * I or someone else wrote it, but screwed up, * Someone hostile wrote it and is trying to trip me up. If there is a language construct that allows chaining -- like the Pascal with construct -- then I am only trusting the language*, not other fragments of programs. If I depend on things I call returning the correct this, then I am depending on them and my dependency set is a lot larger. A larger dependency set makes me nervous. Cheers - Bill * For the really paranoid, minimizing the parts of the language depended on is important. Not all JS implementations behave the same way in the corner cases. lurk --- Bill Frantz|Security, like correctness, is| Periwinkle (408)356-8506 |not an add-on feature. - Attr-| 16345 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum| Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `free` operator
There are a few older systems which have had features that are a bit like those people are describing for the free operator. Let me describe two of them. OS/360 and the PL/I language had the idea of subpools. Many small objects could be allocated in a subpool, and all freed with one call, a high performance way of freeing storage. Neither of these systems actually NULLed existing pointers, so it was easy to make programming errors. The KeyKOS (aka Gnosis) [1,2] depended on explicit freeing of objects for storage reclamation. As an OS, object lifetimes ranged from milliseconds to years. The reason of having an explicit free was to allow an accounting entity paying for storage to stop paying, regardless of whether others were using that storage. When the free call returned, all references to the storage were changed to null. The experience in KeyKOS was that after an object had been shared for a few months, the effects of freeing it could not be predicted easily. This made it hard to decide to free an object. A combination of garbage collection and explicit free might have worked well, but was never implemented. The naive program, using a freed object would crash. These crashes can be caught by a keeper object which can clean up and report failure to callers. [1] http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/Gnosis/ [2] http://cap-lore.com/CapTheory/KK/Kernel/ Cheers - Bill --- Bill Frantz| I wish there was a knob on the TV to turn up the 408-356-8506 | intelligence. There's a knob called brightness, but www.pwpconsult.com | it doesn't work. -- Gallagher ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On 9/27/12 at 9:41, al...@wirfs-brock.com (Allen Wirfs-Brock) wrote: A big part of of my job is specifying what stupid code does. This job is a vital job if you want a completely specified language. (BTW - I know of no completely specified languages, or other computer system components for that matter, but the closer the specification comes to being complete, the better). Congratulations to Allen on the job he is doing for Javascript. Cheers - Bill --- Bill Frantz| Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: global object in strict mode
On 8/24/12 at 10:46, kris.ko...@cixar.com (Kris Kowal) wrote: On Fri, Aug 24, 2012 at 10:41 AM, Brendan Eich bren...@mozilla.org wrote: I'm not sure what the problem is -- I read the old thread, and noticed the solution: var global = Function(return this)(); This is good for any code mode, strict or non-strict. Does CSP ban Function as well as eval? CSP does forbid the Function constructor, by the edict “Code will not be created from strings”. http://www.w3.org/TR/CSP/ Section 4.2 “If unsafe-eval is not allowed…” Of course you can't do this. One can always write an interpreter in Javascript and interpret any string as code. What you can do is keep interpretation from using forbidden features by preventing them from being used by the interpreter, and therefore any language it is interpreting. You can not easily prevent such features from being used by strings being eval-ed. Cheers - Bill --- Bill Frantz| If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrows and a proposed softCall
On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote: A function is free to _document_ it as part of its contract, though. Contracts are much more useful if they are enforced by the system, the language and runtime in this case. Cheers - BIll --- Bill Frantz|Security, like correctness, is| Periwinkle (408)356-8506 |not an add-on feature. - Attr-| 16345 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum| Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Digraphs *and* Unicode pretty-glyphs, for arrows, triangle, etc.
On 4/4/12 at 23:54, ecmascr...@norbertlindenberg.com (Norbert Lindenberg) wrote: Besides typing, legibility is critical: ⇒, ≥, ≤ are clearly improvements over their ASCII counterparts, but ≠ and ≢ are too hard to tell apart. One thing that concerns me with using the extended Unicode set is that I will need to shift to a larger font size to make out the extended characters. I don't know whether that will result in more or less of the program text in a fixed size window, but if it is less, then having those characters in the source will not improve program readability. Cheers - Bill --- Bill Frantz|After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it? -- Marcus Ranum ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On 2/19/12 at 21:45, al...@wirfs-brock.com (Allen Wirfs-Brock) wrote: I really don't think any Unicode semantics should be build into the basic string representation. We need to decide on a max element size and Unicode motivates 21 bits, but it could be 32-bits. Personally, I've lived through enough address space exhaustion episodes in my career be skeptical of small values like 2^21 being good enough for the long term. Can we future-proof any limit an implementation may chose by saying that all characters whose code point is too large for a particular implementation must be replaced by an invalid character code point (which fits into the implementation's representation size) on input? An implementation which chooses 21 bits as the size will become obsolete when Unicode characters that need 22 bits are defined. However it will still work with characters that fit in 21 bits, and will do something rational with ones that do not. Users who need characters in the over 21 bit set will be encouraged to upgrade. Cheers - Bill --- Bill Frantz| If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On 2/13/12 at 16:03, waldron.r...@gmail.com (Rick Waldron) wrote: Forget Date, typeof null, etc. JavaScript's biggest problem is devs that don't test their code. IMHO, things started going to the dogs in the mid-1970s when IBM decided to manage bugs instead of fixing them. It't been downhill ever since. :-) Cheers - Bill --- Bill Frantz|After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it? -- Marcus Ranum ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Lecture on Dart at Stanford
On 10/29/11 at 14:59, bren...@mozilla.com (Brendan Eich) wrote: Dart is not perfect either but it hangs together slightly better. It's not to my taste, and I don't see it replacing JS by acclamation, but again: can we improve ES6 classes by reflecting on what's good in it? There will be a lecture on Dart this coming Wednesday at Stanford. Here is the announcement: Stanford EE Computer Systems Colloquium 4:15PM, Wednesday, Nov 2, 2011 Skilling Auditorium, Stanford Campus http://ee380.stanford.edu[1] Topic:A Walk on the Dart Side: A Quick Tour of Dart Speaker: Gilad Bracha Google USA About the talk: Dart is a pure object-oriented, dynamically typed language with actor based concurrency. We'll take a quick tour of the Dart programming language, focusing on its more unusual features, such as optional typing and built-in factory support. Slides: There is no downloadable version of the slides for this talk available at this time. About the speaker: Gilad Bracha is the creator of the Newspeak programming language and a software engineer at Google. Previously, he was a VP at SAP Labs, a Distinguished Engineer at Cadence, and a Computational Theologist and Distinguished Engineer at Sun. He is co-author of the Java Language Specification, and a researcher in the area of object-oriented programming languages. Prior to joining Sun, he worked on Strongtalk, the Animorphic Smalltalk System. He received his B.Sc in Mathematics and Computer Science from Ben Gurion University in Israel and a Ph.D. in Computer Science from the University of Utah. Contact information: Gilad Bracha Google Embedded Links: [ 1 ]http://ee380.stanford.edu ABOUT THE COLLOQUIUM: See the Colloquium website, http://ee380.stanford.edu, for scheduled speakers, FAQ, and additional information. Stanford and SCPD students can enroll in EE380 for one unit of credit. Anyone is welcome to attend; talks are webcast live and archived for on-demand viewing over the web. WHERE IN THE WORLD IS SKILLING AUDITORIUM: The Colloquium meets in Skilling Auditorium on the Stanford Campus. A map to help you find Skilling Auditorium and parking can be found at http://ee380.stanford.edu/Skilling-Map.png. Parking in most lots is free and unrestricted after 4PM. MAILING LIST INFORMATION: This announcement is sent to multiple mailing lists. If you are signed up on our private EE380 list you can remove yourself using the widget at the upper left hand corner of the Colloquium web page. Other lists have other management protocols. --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
General language standards guidence
On 9/30/11 at 11:01, rnyst...@google.com (Bob Nystrom) wrote: On Fri, Sep 30, 2011 at 10:56 AM, Brendan Eich bren...@mozilla.com wrote: It's future-proof. Rather do less and get it right than over-reach and regret the stuff that we got wrong. Ah, that makes sense. From C.A.R.Hoare's 1980 ACM Turing Award Lecture: When any new language design project is nearing completion, there is always a mad rush to get new features added before standardization. The rush is mad indeed, because it leads into a trap from which there is no escape. A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later. Cheers - Bill --- Bill Frantz| OAuth - It's the best that | Periwinkle (408)356-8506 | the wrong way of doing things| 16345 Englewood Ave www.pwpconsult.com | can provide. - Mike Stay | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
I am always amused by the continuing demands for more performance. The only real advantage of performance as a major metric is that it is relatively easy to measure. If performance is your number one goal, then the only languages you should consider are assembler and machine language. :-) On the other hand, if you like safety, security, maintainability, understandability etc., then recognize that these features have associated costs. On 9/13/11 at 7:48, bren...@mozilla.com (Brendan Eich) wrote: On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote: * A big problem is predictability, it is a black art to get the best performance out of contemporary JS VMs. This is the big one in my book. Optimization faults happen. But can we iterate till flat? A set of rules a developer interested in performance can use would be helpful. Particularly if they applied to more than one implementation. :-) * The massive complexity that comes with implementing all this affects stability. This one I'm less sympathetic to, since we won't get rid of untyped JS up front. A sunk cost fallacy? If we could make a clean break (ahem), sure. Otherwise this cost must be paid. We could get better stability with simpler, less performant VMs. Some users might prefer the increased stability and security such a VM would offer. Cheers - Bill --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __doc__ for functions, classes, objects etc.
On 8/23/11 at 9:54, bren...@mozilla.com (Brendan Eich) wrote: 2. Before function, a la javadoc comments, or first thing in body, a la the prologue directive idea? I have found it difficult to read a Java program from top to bottom because the javadoc comments proceed the function/method header. I want to see what the compiler reads first and then read the human commentary about what it means. With the way Java is set up, I have to jump around in the source instead of reading from top to bottom. Cheers - Bill --- Bill Frantz| Snow shuts down federal | Periwinkle (408)356-8506 | government, life goes on.| 16345 Englewood Ave www.pwpconsult.com | - Associated press 2/9/2010 | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array generation
On 7/11/11 at 15:09, lior...@gmail.com (liorean) wrote: On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote: Another common and useful fusion of two traversals that's in many Schemes is map-filter or filter-map: a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i)) if (res !== void 0)] I rather arbitrarily chose to accept both null and undefined here as way to say no element -- a reasonable alternative would be to accept *only* undefined as no element. The way I think of it is that in analogy to NaN being the Numbers that represent no number, null is the Object that represents no object, in other words a reasonable value to store to tell just that. The undefined value is by analogy the value that represents no value, so is the only value that should be a no element. The way I think of it is that NaN can be produced if an algorithm blows up numerically. If that happens, and the result gets stored in the array, I don't want to confuse those values with the placeholder for purposely omitted value value. Cheers - Bill --- Bill Frantz|Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges - Mark Miller www.periwinkle.com | ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Summary: prototypes as classes
On 6/30/11 at 17:46, rfo...@gmail.com (Irakli Gozalishvili) wrote: I think that whole constructors as classes business in JS is confusing for everyone coming to JS, and they only understand it after understanding confusing constructor- prototype relationship. I don't know about others, but I need to have a mental model of what is going on in order to feel comfortable using a language/API/library. I didn't really feel comfortable with the ADD instruction until I understood how addition was implemented at the circuit level. I didn't feel comfortable with C++ classes until I understood the basic layout of an instance. I think is a matter of believing I can avoid stepping on any landmines that may be lying about. I have a prejudice that the model should match the reality, but I accept that an optimizer may do something completely different if it still implements the model. Simple is nice, but accurate is more important. Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Feedback and criticism wanted: DOMCrypt API proposal
[Sorry for the delay. I'm at Reed Collage and the internet service I've glommed onto doesn't let me contact my SMTP server, so I can't send email, only receive it.] On 6/6/11 at 13:00, bren...@mozilla.com (Brendan Eich) wrote: On Jun 6, 2011, at 9:51 AM, David Dahl wrote: On 6/6/11 at 11:00,fra...@pwpconsult.com (Bill Frantz) wrote: On 6/1/11 at 16:01, dd...@mozilla.com (David Dahl) wrote: The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this: Is an asynchronous interface the best choice. I thought one of the great reliability advantages of Javascript was its single-thread, synchronous nature. Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just don't want any additional main thread I/O happening. To say more: JS is single-threaded, but that means you can lock up a main thread and starve UI. Browsers use multiple threads and processes these days, but the rule still applies. Scripts run to completion and must pass continuations manually by callback functions if they need to run after some indefinite delay, or even after a just-too-long computation or local i/o operation. Thanks Brendan. That explanation answers my question and, assuming the continuations can't run at the same time as the main program, satisfies my implied objection. Cheers - Bill --- Bill Frantz| OAuth - It's the best that | Periwinkle (408)356-8506 | the wrong way of doing things| 16345 Englewood Ave www.pwpconsult.com | can provide. - Mike Stay | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [whatwg] Cryptographically strong random numbers
On 2/22/11 at 1:36 PM, bren...@mozilla.com (Brendan Eich) wrote: However, Math.random is a source of bugs as Amit Klein has shown, and these can't all be fixed by using a better non-CS PRNG underneath Math.random and still decimating to an IEEE double in [0, 1]. The use-cases Klein explored need both a CS-PRNG and more bits, IIRC. Security experts should correct amateur-me if I'm mistaken. I'll see if the security expert hat fits. :-) The random() function in many languages has a useful property which is incompatible with security. By setting its seed, you can get deterministic execution of a Monte Carlo algorithm. IANAJSE, but I didn't see a way to set the seed of Math.random(), so the ECMAScript/Javascript version lacks this useful property. But, having both a repeatable random function and a secure random function in a language is certainly reasonable. Cheers - Bill --- Bill Frantz|The nice thing about standards| Periwinkle (408)356-8506 |is there are so many to choose| 16345 Englewood Ave www.pwpconsult.com |from. - Andrew Tannenbaum | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [whatwg] Cryptographically strong random numbers
On 2/22/11 at 3:39 PM, bren...@mozilla.com (Brendan Eich) wrote: The API issue as Erik put it is this: do we need an array of bytes/shorts/ints, potentially a lot of random values; or would the fractional bits of a single IEEE 64-bit double precision result be good enough. When doing crypto, mostly what you want is bit banging. For example, if you are implementing theRC4/ARC4 key schedule (From: http://en.wikipedia.org/wiki/Rc4) you are coding: for i from 0 to 255 S[i] := i endfor j := 0 for i from 0 to 255 j := (j + S[i] + key[i mod keylength]) mod 256 swap values of S[i] and S[j] endfor The AES process is similar (from: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard): High-level description of the algorithm 1. KeyExpansion—round keys are derived from the cipher key using Rijndael's key schedule 2. Initial Round 1. AddRoundKey—each byte of the state is combined with the round key using bitwise xor 3. Rounds 1. SubBytes—a non-linear substitution step where each byte is replaced with another according to a lookup table. 2. ShiftRows—a transposition step where each row of the state is shifted cyclically a certain number of steps. 3. MixColumns—a mixing operation which operates on the columns of the state, combining the four bytes in each column. 4. AddRoundKey 4. Final Round (no MixColumns) 1. SubBytes 2. ShiftRows 3. AddRoundKey I always think of these operations as shifting and masking, but I'm really an Assembler/OS guy who likes being close to the hardware. :-) Other uses will be packaging it into network messages, as in SSL/TLS key generation. Are there other, non-crypto uses for secure random numbers? The question for the Javascript experts is, what form will make implementing this kind of code easiest? Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [whatwg] Cryptographically strong random numbers
On 2/14/11 at 2:46 PM, sha...@google.com (Shabsi Walfish) wrote: This depends on what you consider to be the basic use case. Generating long-lived cryptographic keys absolutely requires high quality entropy... if you are only generating short-lived authenticators (that are not used for encryption) then you could get away with weaker entropy. You will get the most mileage out of this feature if it can be used to generate encryption keys, or long-lived signing keys. [Greetings to old friends and new. And I hope I've properly subscribed to all the right lists...] I have a big problem with concepts such as using up entropy, and high quality entropy is needed. I belong to the school that says, If I have 160 unguessable bits and can keep them secret, I can stretch them and remain secure for ever. Now there are some issues with this statement: * I don't really trust my stretching algorithms, based on secure hashes, to not leak some tiny fraction of the unguessable bits. * Keeping any secret is difficult. * Getting unguessable bits is a hard problem. * 160 may be too small. Because of these issues, modern secure random number generators add batches of new unguessable bits from time to time. This line of thinking leads me to say that /dev/urandom, and its Windows cousin, is good enough for any practical use. Ensuring that the seed for /dev/urandom is indeed unguessable is a problem for the OS, not the language run-time. For ECMAscript/Javascript or whatever this group calls the language, I suggest: (1) Build a routine that returns /dev/urandom data to the caller. Implement this routine fairly quickly. (2) At a more leisurely pace, build a crypto API and implement it in the language. After the usability bugs are worked out of the API, standardize it. If more performance is needed, perhaps a platform dependent issue, build higher speed implementations of the standard. [Historically, a number of crypto-based APIs have failed because developers could not figure out how to use them. Getting the usability right is probably the hardest part of designing the API. Cheers - Bill --- Bill Frantz|The nice thing about standards| Periwinkle (408)356-8506 |is there are so many to choose| 16345 Englewood Ave www.pwpconsult.com |from. - Andrew Tannenbaum | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [whatwg] Cryptographically strong random numbers
[wha...@lists.whatwg.org removed from cc list because I'm not on it and MarkM suggested dropping it.] On 2/14/11 at 4:20 PM, sha...@google.com (Shabsi Walfish) wrote: Hmm... if there is a guarantee that /dev/urandom was successfully seeded at some point in the past, then I'm happy with it. Is there such a guarantee? I don't see that documented anywhere, and I'm not sure how it would be provided. Since /dev/urandom never blocks, I'm assuming it will return something based mostly on weak entropy sources (like system time and/or or a very small number of real bits of entropy) in the event that the system hasn't really had a chance to seed the pool yet. I can live with not reliably refreshing the pool, but its pretty scary if you think about what happens when a user boots their phone up for the first time, etc. and there is just no entropy there yet. While I think this question is a bit outside the language area, as an OS person, it falls directly in my lap, so please indulge me while I pontificate. Getting unguessable bits into a deterministic system like a computer is very platform dependent. Disk timing, variable because of air turbulence on the platters, has been a popular source. However now many systems have solid state disks. This dependency means we are at the mercy of the system builders. I don't know that there are any guarantees. Consider the environments: Servers pcs phones/tablets (others?) I think the worst case is servers. They live in a temperature controlled room, and the only I/O they have is a network connection and a disk farm. With some luck, the server operator will have a source of unguessable bits included on a crypto board or on one of the manufacture's support chips. Otherwise there's timings on the disk and network I/O. A number of the CPU chips have cycle counter which can provide high resolution timing for interrupts etc. Pcs (lower case because I mean it generically) have a number of good sources involved with UI events, microphones etc. There is time between boot and first application launch to gather mouse movements, ambient sound etc. Phones/tablets have a wonderful set of resources: radio noise, compass direction, GPS location tracking, microphone input, camera input, etc. They should be able to get enough unguessable bits within a few seconds, certainly by the time they've established network connectivity. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
