Re: Storage in Gecko

[Gervase Markham]

On 06/05/13 20:12, David Dahl wrote:
> That is unfortunate. The Kyoto-* tools are FAST and easy to use. I
> wonder if the author would be willing to issue Mozilla a license that
> is compatible with MPL?

That would be the functional equivalent of relicensing under the MPL,
which is a weaker copyleft than he is using. Given that they have
thought about their licensing hard enough to have a FLOSS linking
exception etc. etc., I suspect that would not go down well. But if you
want the licensing team to look into it, file a bug :-)

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

* About the "XML is evil, MathML is XML so MathML is evil" syllogism.

I don't think it makes sense in general to say that something is good or bad 
without mentioning for what purpose. I actually agree with Joshua that XML is a 
good format to work with for a computer engineer. There are very good libraries 
and tools to handle it and things like XML namespaces that are painful on the 
Web become very important for these tools. roc is right that the "catastrophic 
fail" is certainly not good for a Web model. Note however that most of the Web 
sites are automatically generated by server side programs and I often see 
MYSQL, PHP, CGI etc failures without hearing anyone saying they should come 
back to static pages. The HTML5 parsing rules allow to get concision and 
error-tolerance when you want to quickly write pages but this "tag-soup" 
approach also brings confusion in general and is just useless for programming. 
The inclusion of MathML inside HTML5 removed the XML burden that prevented 
people to use it on the Web or in emails where the default content 
 is text/html. Actually the syntactic difference has never been a problem for 
MathJax or WYSIWYG tools (working on a DOM-like tree) or for authoring tools 
like LaTeXML (that generates XML from LaTeX and then only uses XSLT stylesheets 
at the final step to convert to EPUB, XHTML or HTML5). Perhaps one of the best 
argument against the XML-haters is that Henri Sivonen's HTML5 validator is 
itself heavily based on XML tools like RELAX NG schemas or Java XML-related 
libraries.

* About the "MathML is too specialized".

Obviously I agree with what has been said before about math being in particular 
position. I personally see mathematical writing as language by itself and so 
not having it in the browsers is just like not supporting Arabic or Asian 
scripts (BTW MathML was implemented in Gecko a long time before HTML ruby). 
Just to add one point: mathematical expressions are also very often mixed with 
other content like text or diagrams and it makes sense to have 
HTML+SVG+MathML+CSS well integrated together.

* About the "TeX is already the universally adopted standard" and " TeX is very 
friendly to manual writing".

Again, people have already said that this is not true, at least not outside 
academia (I personally use TeX too as an input method but don't want to impose 
that to other people and I'm open to use other methods like handwritting 
recognition in the future). One of the most popular question on the MathJax 
list is of course "is there a WYSIWYG math editor?" Many people also like the 
ASCII-like syntax: (x^2 + y_1)/2. For example MathJax supports that syntax, 
Daniel Glazman has a plugins for BlueGriffon & Thunderbird and this is commonly 
used in Computer algebra systems. Some people say (cf jqMath or MathEL) that 
with tools to replace the traditional keyboard, entering Unicode characters 
becomes easy and so they generalize to a Unicode-based simple syntax where you 
write the actual symbol rather than commands like \Leftrightarrow. Even modern 
LaTeX environments support Unicode. Finally, people are also interested in 
handwritting recognition (see e.g. https://www.youtube.com/watch?v
 =26opB8DRf3c or http://webdemo.visionobjects.com/portal.html). 

* About the "TeX can be nearly trivially read aloud".

This is an assumption but the reallity is that math accessibility tools would 
need a parsing into an abstract representation at some point anyway. Just 
reading the plain text source naively is not enough for the two use cases I 
mentioned. There are already MathML-based tools showing that it is possible to 
use MathML.

* About "MathML never saw much traction outside of Mozilla"

If you are only talking about browser vendors then that's true. But Web users 
have requested MathML support for a long time (remember that the Web was 
created at the CERN for research purpose) and has been implemented in Gecko and 
Webkit by volunteers. MathJax is yet another community effort to bring math on 
the Web and was initially presented to me by Robert Miner as a "transition 
technology" towards MathML in browsers. At the last W3C workshop on ebook, 
everybody complained about the lack of MathML support in layout engines (Gecko 
being excluded de facto for now) and this leads to serious discussions inside 
the MathJax consortium about how we could help implementing MathML in browsers 
(hopefully the MathJax team will be able to say more about that later). Other 
people also indicate other domain where MathML is now used. BTW, you probably 
don't care either about that argument, but MathML is part of the OpenDocument 
OASIS/ISO/IEC standard used in OpenOffice and other office s
 oftware suite.

[digression: Mozilla people keep saying that competition is good. That was 
certainly true when Mozilla was fighting against Internet Explorer predominance 
and stagnation in Web innovation. But to be honest, it seems that what's 
happening now is that Googl

Re: We should drop MathML

[Mihai Sucan]

Hello everyone!

This thread has raised my attention and I would like to share my 
opinions, maybe as a "school child" who used mathematical software for 
WYSIWYG editing (not only reading!), as the primary way of editing any 
math, as a primary/fundamental tool for computer-aided learning. I was 
(un)lucky enough to be forced by my situation to learn using *only* 
computers in the late 1990s and early 2000s. That experience has taught 
me the importance of WYSIWYG editing for HTML and maths.


I feel it's not easy to me to reply to this thread - seeing other people 
who are technical experts that I admire have already replied, providing 
proper arguments for their reasoning. Please excuse my, perhaps, less 
formal, less backed-by-arguments reply.


This thread shows that there's some misunderstanding on the performance, 
styling and editing requirements for math. I can say that I spent months 
trying software to find the best one fitting my requirements. It wasn't 
easy.


I haven't seen good (La)TeX WYSIWYG editors, but lately I haven't tried 
any such software - now I write LaTeX manually. Still, in the early 
2000s I did see and use one WYSIWYG editor that was really good: 
Wolfram's Mathematica. It had fast rendering, good set of keyboard 
editing shortcuts allowing fast input in WYSIWYG mode. Really good math 
WYSIWYG editing is very much possible.


Performance matters not only for the initial document rendering. When 
you do WYSIWYG editing performance characteristics matter in a lot more 
subtle ways. When you are editing big equations, or some really big 
document updates need to happen as close as possible to instant. I have 
tested software like MathCAD and Maple that did not seem slow at all 
when loading documents. Editing math, however, proved to be quite slow. 
Very good editing is *not* about "click and point" - this was one of the 
biggest failures of MathCAD's UI: it encouraged the click-and-point 
editing which meant you had to switch between the keyboard and the mouse 
all the time. Word 97 (before Word 2007) forced you to manually switch 
between the equation editor and the normal editor, which was a huge 
problem, and so on.


Styling is really important when you collaborate with others and you 
need to highlight relevant parts of the math output. I am surprised this 
is even put up as discussion.


Similarly I am surprised that the need for WISYWG editing for math is 
being discussed. I am being subjective here: I believe that mathematics 
should be first-class citizen on the web. Mathematics is a fundamental 
domain of study in all schools, in all forms of education throughout the 
world. Mathematics is the basis for many other fields, see physics, 
computer science and others.


Back in those days when I was writing math homeworks with Mathematica I 
was very glad and I appreciated a lot that people write software that 
can benefit my niche needs, it was invaluable for me. It made possible 
things that were not possible. Microsoft's Word was not even close to 
being as usable as Wolfram's software. Word 2007 has, indeed, improved 
math editing a *lot*, today it's certainly usable.


Microsoft's work on improving math editing in Word shows there's a real 
demand for math in documents. I don't see why we would believe otherwise 
about the web. We should not need to include half-baked* JS libs to 
render math in a document.


* I'm not claiming that MathJax is half-baked - I am simply pointing out 
that once people have the choice of which JS lib to use for math 
rendering they may (and will) fail to pick the best one.


I do not care about the technology here - MathML or TeX. What I care 
about is for the web browsers to meet the technical demands for 
producing really good math rendering and editors. I want this not for 
the academics, not for professors who can write TeX documents. I want 
this for school children who cannot write math on paper, who are blind, 
or who have other physical disabilities. Manually writing LaTeX does not 
"cut it" at early stages, when children learn maths. Such tools are 
invaluable for them.


At the moment, removing MathML support from Gecko would make it harder 
for web app developers to create (really) good software for math 
editing. It may certainly have its problems, but its benefits are 
greater. Before MathML is removed people should look into defining the 
requirements, the APIs needed to be implemented in the browser such that 
JS-based math rendering can be equally fast and versatile (eg. styling). 
Font metrics stuff is, I believe, only a part of the problem that makes 
JS-based math rendering slower than native. After requirements are 
defined, those things should be implemented. After that, yes, remove MathML.


Back in the days when I was testing math software, I was also testing 
MathML rendering in Gecko - it was slower than in specialized software. 
I don't know how it is today, but keep in mind that native software like 
Maple and

Re: We should drop MathML

[Benjamin Smedberg]

On 5/6/2013 7:20 PM, Robert O'Callahan wrote:

Hopefully Web Components will provide a good solution to let authors extend
the browser with support for vocabularies that can be rendered via a
straightforward decomposition to HTML or MathML or SVG.

I think the layout requirements of MathML are too onerous for MathML to be
reduced to HTML or SVG that way.
I'd like understand more about this. I have been hoping that one of the 
best use cases for web components is to implement these kinds of 
domain-specific languages. I greatly fear that we're accidentally 
pushing the web from declarative markup to a model where everything is 
controlled with script: in the process, we are going to lose some of the 
core benefits of the web: pervasive hyperlinking, save-as and 
view-source, and . I tend to think that web components are a great way 
to abstract away the presentation of new declarative languages.


Without knowing a lot about it, it seems that SVG and HTML contain all 
of the primitives necessary for a web components script to implement the 
visual MathML presentation. Perhaps I'm not completely aware of the 
problems, though. Does MathML need to participate in inline reflow in a 
way that requires direct support from the layout engine?




While diagrams such as chemical formulae, flowcharts or electronics
schematics can be compiled to SVG, the layout step is very much nontrivial
and I don't think Web Components is enough for that. Web Components plus
some JS to do the layout is probably satisfactory.

Unless I misunderstand web components, they are primarily blobs of 
script, and I'm really hoping they will be able to implement arbitrary 
new markup languages. I think there's a lot more that we can add to 
components, especially for nonvisual presentations (better 
implementation of accessibility and audio presentations seem like 
near-term goals).


That still leaves us with future decisions about whether we should build 
any of these markup languages into the browser. It seems clear from epub 
that there is a demand for declarative math markup, and whether we build 
that using web components or directly into our layout engine, it should 
be a core markup language of the web.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Simplify async code-flows and unify unit tests

[Mike de Boer]

TLDR; in bug 867742 I requested to adopt two JS modules, Async.jsm and 
AsyncTest.jsm, in mozilla-central/toolkit/modules. The whole story can be read 
below as well as at https://gist.github.com/mikedeboer/5495405. I posted about 
this subject before on firefox-dev: 
https://mail.mozilla.org/pipermail/firefox-dev/2013-April/thread.html#268

...
The thing I always do when I encounter a large code base, is roam though it and 
make a mental map of the structure; the good parts and ones that would benefit 
from some TLC. A part I noticed did not yet receive the amount of attention it 
deserves are unit tests and asynchronous code handling. I'll be blunt about it, 
here's what I did: I ported the async NodeJS library to a Mozilla-style module 
and on top of that I built a unit testing library, inspired by Mocha (among 
others). I can imagine that the fellas I just mentioned don't make you recall 
anything, so here are two links:

https://github.com/caolan/async
https://github.com/visionmedia/mocha
First of all, the Github numbers will show you that they are crazy popular 
NodeJS libraries. And well-documented. And well-written. And awesome.

Here's the thing I ended up with: https://github.com/mikedeboer/mozAsync The 
lib folder therein contains two files:

Async.jsm - the port of the async library
AsyncTest.jsm - the unit testing library The test folder contains the unit 
tests (erm, duh) and also serve as great examples of how to use the two modules!
Ok, example time! I really like this one from the async module:

// Sorts a list by the results of running each value through an async iterator.
Async.sortBy(["file1", "file2", "file3"], function(file, callback){
  fs.stat(file, function(err, stats){
callback(err, stats.mtime);
  });
}, function(err, results){
  // results is now the original array of files sorted by
  // modified date
});
Note: this one uses a NodeJS API, but you can mentally replace that with an 
async MozFile one.

I've told some of you before that I'm not a big fan of Promise libraries (if 
not, please read the 10 reasons to NOT use a Promise library: 
https://gist.github.com/mikedeboer/5305020). However, this library is not meant 
to replace them, but to augment the ecosystem with another option. There are 
many developers out there that feel uneasy about using Promises as long as 
they're not a first-class primitive in SpiderMonkey. If that's you, you can use 
this: a minimalistic, functional utility library.

What about them unit tests?

Design goal: create a simple, minimalistic framework that provides a clear, 
unified API to create unit tests that is as easy to use for sync code flows as 
for async ones. Rationale: unit tests are 'hot' code. They are modified as 
often - perhaps even more - as functionality it covers changes, especially in 
TDD environments. They serve as documentation for the code they cover. When 
tests fail, they usually don't on 'your computer', but somewhere else, like on 
the build infrastructure. When that happens, someone will open the unit test 
and try to understand what is going on. In all these cases it is hugely 
beneficial to a) know that most of the unit tests are written in the same 
structure and b) are structured in such a way that they're easy to read by 
someone other than you.

This is an example of a minimal test:

AsyncTest([
{
  name: "Minimal Test",
  reporter: "tap",
  tests: {
"it should execute this test": function(next) {
  Assert.equal(typeof next, "function", "'next' should be a callback 
function");
  next();
},

"! it should NOT execute this test": function(next) {
  Assert.ok(false, "BAM!");
  next();
},

"it should be aware of the correct context": function() {
  Assert.ok(this["it should execute this test"], "The function ought to be 
accessible");
}
  }
}
]);
There are a couple of interesting things going on here:

You can pass an Array of test suites or just one Object
Suites can have names
Tests can be described freely
It mixes fine with ANY assertion style (Mochi or XPCShell)
Prefix a test with ! to exclude it from the suite. This is something that is 
practically useful when doing TDD.
Prefix a test with > to only run that test and ignore the others. It is meant 
to signal out a test case and run only that specific one. This is something 
that is practically useful when doing TDD.
If the test is sync, you can forget about the next function (callback) 
completely - the library takes care of it; you can even mix async and non-async 
tests
You can choose the style of reporting by setting the reporter property to dot 
or tap. The reporters progress and spec are under development. More information 
about what 'TAP' is can be found at: http://testanything.org
But more importantly, there are several things that usually need to happen 
before a test can be run, like opening a tab, load a page and wait for it to 
load, etc. AsyncTest unifies scenarios like this in the following way:

Each s

determining release channel from javascript?

[Byron Jones]

howdy,

we'd like to extend bugzilla.mozilla.org to log which channel the 
reporter's version of firefox is using; however i can't figure out if 
this information is available to javascript.


i initially thought about using browser/config/version/version.txt based 
on the version in the user-agent, however this reflects the current 
default channel, and not necessarily the channel the user's application 
is using.  for example if someone downloads aurora just before the 
trains leave, and doesn't upgrade before filing a bug, we'd incorrectly 
think they are using beta.


i'm interested in either the value of app.update.channel, or the value 
passed to configure via --enable-update-channel.


is this currently available to javascript?  if so, how?  if not, do you 
think a request to expose it would be successful?



thanks
--
byron - irc:glob - bugzilla.mozilla.org team -

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

> Does MathML need to participate in inline reflow in a way that requires 
> direct support from the layout engine?

I don't know if that answers your question but one important thing that is 
currently lacking in Gecko's MathML implementation is line breaking. This is 
true for Web pages but I suspect this will become even more important with 
mobile devices. I use many long inline formulas in my blog and this is handled 
as I would like by Gecko. A very important use case is large tables enumerating 
mathematical properties and thus containing formulas (you can find some on 
Wikipedia like pages on Fourier transforms, integral/derivatives, probability 
laws, usual function properties and I also used such tables in the appendices 
of my two master thesis in CS and math). Currently, the line breaking is 
disable by default in MathJax as that slows down the layout algorithm even 
more. And of course that does not work for formulas inside table cells since 
MathJax has no knowledge of CSS intrinsic widths.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

On Tuesday, May 7, 2013 4:11:22 PM UTC+2, fred...@mathjax.org wrote:
> I use many long inline formulas in my blog and this is handled as I would 
> like by Gecko. 

sorry I meant this is *not* handled
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: determining release channel from javascript?

[Benjamin Smedberg]

On 5/7/2013 9:55 AM, Byron Jones wrote:


i initially thought about using browser/config/version/version.txt 
based on the version in the user-agent, however this reflects the 
current default channel, and not necessarily the channel the user's 
application is using.  for example if someone downloads aurora just 
before the trains leave, and doesn't upgrade before filing a bug, we'd 
incorrectly think they are using beta.


It is possible to deduce this information given just the version from 
navigator.userAgent and the value of navigator.buildid. Unfortunately as 
far as I know there is currently not an API to make this easy. Maybe 
somebody from releng can correct me if I'm wrong: currently I mostly go 
looking through the dated build directories: e.g. currently my buildid 
is "20130504030913" so I go to 
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/05/ and grep 
for 2013-05-04-03-09-13 which shows me that this is a mozilla-entral build.


Unfortunately the beta/release builds are not in this directory, they 
are separate so you have to use a different heuristic ;-)


i'm interested in either the value of app.update.channel, or the value 
passed to configure via --enable-update-channel.


is this currently available to javascript?  if so, how?  if not, do 
you think a request to expose it would be successful?

I do not think that we would want to expose this information to the web.

--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Simplify async code-flows and unify unit tests

[Tetsuharu OHZEKI]

For only making tests codes (mochitest), I think it's good that we
introduce the way to write async test uniformly.

However, I seem we need consider about it for some reason.

1. We have already task.jsm modules in our source tree. It's promises
based design and it has been used in our code. the difference of
styles will causes some problem and it's not good for project. Even if
we need to mix some different paradigms for async code, we separate  a
paradigm per each modules.

2. We may need to consider DOM Future
http://dom.spec.whatwg.org/#futures and the discussions on es-discuss
about introducing Future pattern to ECMAScript standards. This is the
tide which we cannot ignore about. If ECMAScript or DOM Standard adopt
them as formal standards, its design pattern will be main stream and
following it will be benefits.

2013/5/7 Mike de Boer :
> TLDR; in bug 867742 I requested to adopt two JS modules, Async.jsm and 
> AsyncTest.jsm, in mozilla-central/toolkit/modules. The whole story can be 
> read below as well as at https://gist.github.com/mikedeboer/5495405. I posted 
> about this subject before on firefox-dev: 
> https://mail.mozilla.org/pipermail/firefox-dev/2013-April/thread.html#268
>
> ...
> The thing I always do when I encounter a large code base, is roam though it 
> and make a mental map of the structure; the good parts and ones that would 
> benefit from some TLC. A part I noticed did not yet receive the amount of 
> attention it deserves are unit tests and asynchronous code handling. I'll be 
> blunt about it, here's what I did: I ported the async NodeJS library to a 
> Mozilla-style module and on top of that I built a unit testing library, 
> inspired by Mocha (among others). I can imagine that the fellas I just 
> mentioned don't make you recall anything, so here are two links:
>
> https://github.com/caolan/async
> https://github.com/visionmedia/mocha
> First of all, the Github numbers will show you that they are crazy popular 
> NodeJS libraries. And well-documented. And well-written. And awesome.
>
> Here's the thing I ended up with: https://github.com/mikedeboer/mozAsync The 
> lib folder therein contains two files:
>
> Async.jsm - the port of the async library
> AsyncTest.jsm - the unit testing library The test folder contains the unit 
> tests (erm, duh) and also serve as great examples of how to use the two 
> modules!
> Ok, example time! I really like this one from the async module:
>
> // Sorts a list by the results of running each value through an async 
> iterator.
> Async.sortBy(["file1", "file2", "file3"], function(file, callback){
>   fs.stat(file, function(err, stats){
> callback(err, stats.mtime);
>   });
> }, function(err, results){
>   // results is now the original array of files sorted by
>   // modified date
> });
> Note: this one uses a NodeJS API, but you can mentally replace that with an 
> async MozFile one.
>
> I've told some of you before that I'm not a big fan of Promise libraries (if 
> not, please read the 10 reasons to NOT use a Promise library: 
> https://gist.github.com/mikedeboer/5305020). However, this library is not 
> meant to replace them, but to augment the ecosystem with another option. 
> There are many developers out there that feel uneasy about using Promises as 
> long as they're not a first-class primitive in SpiderMonkey. If that's you, 
> you can use this: a minimalistic, functional utility library.
>
> What about them unit tests?
>
> Design goal: create a simple, minimalistic framework that provides a clear, 
> unified API to create unit tests that is as easy to use for sync code flows 
> as for async ones. Rationale: unit tests are 'hot' code. They are modified as 
> often - perhaps even more - as functionality it covers changes, especially in 
> TDD environments. They serve as documentation for the code they cover. When 
> tests fail, they usually don't on 'your computer', but somewhere else, like 
> on the build infrastructure. When that happens, someone will open the unit 
> test and try to understand what is going on. In all these cases it is hugely 
> beneficial to a) know that most of the unit tests are written in the same 
> structure and b) are structured in such a way that they're easy to read by 
> someone other than you.
>
> This is an example of a minimal test:
>
> AsyncTest([
> {
>   name: "Minimal Test",
>   reporter: "tap",
>   tests: {
> "it should execute this test": function(next) {
>   Assert.equal(typeof next, "function", "'next' should be a callback 
> function");
>   next();
> },
>
> "! it should NOT execute this test": function(next) {
>   Assert.ok(false, "BAM!");
>   next();
> },
>
> "it should be aware of the correct context": function() {
>   Assert.ok(this["it should execute this test"], "The function ought to 
> be accessible");
> }
>   }
> }
> ]);
> There are a couple of interesting things going on here:
>
> You can pass an Array of test suites or just one Object
> Su

Test harness preferences moved out of build/automation.py.in to testing/profiles/prefs_general.js

[Andrew Halberstadt]

As part of a broader automation refactor, we are consolidating all of 
the test harness preferences in one place. Storing them as a string in a 
python file is less than ideal, so as a first step the preferences in 
automation.py.in have been moved to testing/profiles/prefs_general.js [1].


Note that only mochitest, leaktest and profileserver used these prefs. 
Reftest and xpcshell have their own prefs in separate locations which 
will also be moving in the future.


Consolidating preferences into files will allow us to be more flexible 
with which preferences get used by which harness / build configurations. 
It will also make it easier to find for people unfamiliar with the 
various harnesses.


Thanks,
Andrew

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=830430
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Robert O'Callahan]

On Tue, May 7, 2013 at 6:46 AM, Benjamin Smedberg wrote:

> On 5/6/2013 7:20 PM, Robert O'Callahan wrote:
>
>> Hopefully Web Components will provide a good solution to let authors
>> extend
>> the browser with support for vocabularies that can be rendered via a
>> straightforward decomposition to HTML or MathML or SVG.
>>
>> I think the layout requirements of MathML are too onerous for MathML to be
>> reduced to HTML or SVG that way.
>>
> I'd like understand more about this. I have been hoping that one of the
> best use cases for web components is to implement these kinds of
> domain-specific languages. I greatly fear that we're accidentally pushing
> the web from declarative markup to a model where everything is controlled
> with script: in the process, we are going to lose some of the core benefits
> of the web: pervasive hyperlinking, save-as and view-source, and . I tend
> to think that web components are a great way to abstract away the
> presentation of new declarative languages.
>
> Without knowing a lot about it, it seems that SVG and HTML contain all of
> the primitives necessary for a web components script to implement the
> visual MathML presentation. Perhaps I'm not completely aware of the
> problems, though. Does MathML need to participate in inline reflow in a way
> that requires direct support from the layout engine?


Ideally, yes, although it currently doesn't in Gecko.

Good math layout requires specialized layout primitives that we don't have
in regular CSS. I'm thinking of features like stretchy characters (e.g.
integrals that grow based on the size of the enclosed formula), stretchy
overbars and underbars of various kinds, and careful placement of the
degree next to a radical symbol.

Keep in mind that without script, the kind of transformations you can apply
with Web Components are similar to XBL, and that's pretty limited.

I'll repeat what I said before: going from a domain-specific data model,
such as XML describing an electronic circuit, to a good rendering, is an
incredibly complex process. It's unclear it can even be automated at all,
let alone automated without script.

Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Storage in Gecko

[Marco Bonardo]

On 06/05/2013 18:41, David Dahl wrote:> KyotoCabinet might make a good 
backend for a new storage API:


http://fallabs.com/kyotocabinet/

There is also a companion indexing engine: http://fallabs.com/kyototycoon/

Regards,

David


SQLite4 implements something very similar (log-structured merge 
database) and, so far, is reported being faster or on-par with KyotoCabinet.
It's also already compatible with our license and we are already working 
with them, that means we basically have a red carpet for using it.
Though, as previously expressed, a database implementation is only a 
possible part of the solution, not the solution.


-m
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: determining release channel from javascript?

[Chris Peterson]

On 5/7/13 6:55 AM, Byron Jones wrote:

we'd like to extend bugzilla.mozilla.org to log which channel the
reporter's version of firefox is using; however i can't figure out if
this information is available to javascript.

i initially thought about using browser/config/version/version.txt based
on the version in the user-agent, however this reflects the current
default channel, and not necessarily the channel the user's application
is using.  for example if someone downloads aurora just before the
trains leave, and doesn't upgrade before filing a bug, we'd incorrectly
think they are using beta.

i'm interested in either the value of app.update.channel, or the value
passed to configure via --enable-update-channel.

is this currently available to javascript?  if so, how?  if not, do you
think a request to expose it would be successful?


You can at least determine whether the user is running Beta/Release or 
Nightly/Aurora from navigator.userAgent. The "Gecko" version is the 
build date (e.g. "Gecko/20130507") for Nightly and Aurora, but frozen at 
"Gecko/20100101" for Beta and Release.



chris p.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[d . p . carlisle]

On Sunday, 5 May 2013 16:38:39 UTC+1, Benoit Jacob  wrote:
> Hi,
> 
> 
> 
> Summary: MathML is a vestigial remnant of the XML-everything era, and we
> 
> should drop it.
> 

As can be seen in the integration into HTML(5) nothing in MathML requires an 
XML surface syntax.

> 
> 
> ***
> 
> 
> 
> 1. Reasons why I believe that MathML never was a good idea. Summary:
> 
> over-specialized and uniformly inferior to the pre-existing,
> 
> well-established standard, TeX.

TeX is designed for a situation in which the author has full control over
fonts and page size. It is not designed at all for a web-like scenario, in 
particular TeX has no support for linebreaking of displayed mathematics
which is particularly important with small screens etc. Also of course classic 
TeX has no support for Unicode fonts. There are Unicode variants (luatex and 
xetex) and experimental support for Unicode math fonts (unicode-math fonts) but 
all these are relatively unstable development software and hardly 
well-established standards.

> 
> 
> 
>1.1. MathML is too specialized: we should be reluctant to have a
> 
> separate spec for every kind of specialized typography. What if musicians
> 
> wanted their own MusicML too?
> 
> 

Mathematics plays a central role as part of the _textual_ vocabulary of 
scientific and educational literature. Music is of course important but musical 
notation does not have to interact with textual paragraphs in the same way.
> 
>1.2. MathML reinvents the wheel, poorly. A suitable subset of TeX (not
> 
> the entirety of TeX, as that is a huge, single-implementation technology
> 
> that reputedly only Knuth ever fully understood) was the right choice all
> 
> along, because:

It does not re-invent TeX: it is different.
> 
> 
> 
>   1.2.1. TeX is already the universally adopted standard --- and
> 
> already was long before MathML was invented. Check for yourself on
> 
> http://arxiv.org/ , where most new math papers are uploaded --- pick any
> 
> article, then "other" formats, then "Source": you can then download TeX
> 
> sources for almost every article.


TeX is the standard in some fields for _author submission_ although even in 
scientific fields other formats notably Word are surprisingly (perhaps) common. 
Also other than self-publishing mechanisms such as arxiv many scientific 
journals do _not_ use TeX for publishing and even if they accept tex input they 
convert in house to xml/mathml workflows (thus mathml is a more natural 
publishing format)
> 
> 
> 
>   1.2.2. TeX is very friendly to manual writing, being concise and
> 
> close to natural notation, with limited overhead (some backslashes and
> 
> curly braces), while MathML is as tedious to handwrite as any other
> 
> XML-based format. An example is worked out at
> 
> http://en.wikipedia.org/wiki/MathML#Example_and_comparison_to_other_formats,
> 
> where the solution to the quadratic equation is one line of TeX versus
> 
> 30
> 
> lines of MathML!
> 
> 

Probably true but not very relevant. HTML is more verbose than wiki syntax for 
the same reasons.

> 
>   1.2.3. An important corollary of being very close to natural notation
> 
> is that TeX can be nearly trivially "read aloud". That means that it offers
> 
> a particularly easy accessibility story. No matter what mechanism is used
> 
> to graphically display equations, providing the TeX source (similarly to
> 
> images alt text) would allow anyone to quickly read it themselves without
> 
> any kind of software support; and screen reading software could properly
> 
> read equations with minimal TeX-specific support code. For example, TeX
> 
> code such as "\int_0^1 x^2 dx" can be readily understood by any human with
> 
> basic TeX exposure (which is nearly 100% of mathematicians) and can be
> 
> easily handled by any screen reader that knows that \int should be read as
> 
> "integral" and that immediately after it, _ and ^ should be read as "from"
> 
> and "to" respectively.
> 
> 

The accessibility implementations of MathML (notably MathPlayer) rather refute 
the suggestions that it is easier to get accessible renderings from Tex. rather 
the reverse is true.
> 
> ***
> 
> 
> 
> 2. Reasons why even if MathML had ever been a decent idea, now would be the
> 
> right time to drop it. Summary: never really got traction, and the same
> 
> rendering can now be achieved without MathML support.
> 
> 

MathML is a standard part of ODF (OpenOffice etc) it is supported in clipboard 
in Word and the rest of the MS Office suite. It is a standard part of epub3. It 
is supported in many typesetting systems used by journals. It is supported on 
import/export in maple and mathematca, just to name a few. In contrast TeX is 
notoriously difficult to process by anything other than TeX: 
latex2html/tex4ht/latexml do a remarkable job but are inherently fragile and 
incomplete. 
> 
>2.1. MathML never saw much traction outside of Mozilla, despite having
> 
> been around for a decade. WebKi

Re: We should drop MathML

[Benjamin Smedberg]

On 5/7/2013 1:42 PM, Robert O'Callahan wrote:

Keep in mind that without script, the kind of transformations you can apply
with Web Components are similar to XBL, and that's pretty limited.
Yes, I'm definitely not talking about a non-script implementation of any 
of these. I'm presuming a fully scripted webcomponents impl (i.e. 
MathJAX but hidden behind webcomponents isolation).


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Marcio Galli]

> I'm coming late to this thread but I have to say that the misunderstanding 
> present in the original post is huge. The author can take refuge in that he's 
> made a common category mistake. MathML is a computer representation for math, 
> TeX is a human input language.
>
> MathML was never intended to be typed by humans so it is no wonder that you 
> find it a bad experience. TeX is a poor computer representation which is one 
> reason why MathML was invented.
>
> It is reasonable to have a discussion of the relative merits of entering math 
> by typing TeX vs point-and-click editing of math (ie, direct manipulation 
> editing). I am biased toward the latter but I can understand the feelings of 
> those whose hands know TeX really well.
> In short, both MathML and TeX have good reasons to exist and don't compete 
> with each other in their primary categories.

I am also late in this thread, and I incline to this point and I see
the original author frustration as a valid discussion — not sure under
this one.

But I wanted to present another problem which is in a way of the same
nature (has also a degree of separation). It's the development of
tableless grids against HTML.

Consider the case, table A, which a developer can think of:

4 columns:
abcd
ebfd

To to this in HTML, the developer has to make a "container DIV" with 4
main column cells in it, think c1,c2,c3,c4. And which c1=rows a,e;
c2=row b; c3=rows cf; c4=row d;

It's easier to type something like the following:

4,abcdebfd

But this won't change the reality, the end product of this is:



Which, can be , as many pointed: styled, channeled to accessibility
observers, manipulated, annotated — all of of that with a greater
level of compatibility as developers understand.

But then, right now, what we have are:

a) Toolkits using JS to do things like 4,abcdebfd [1]

  a.1) For example, http://labs.telasocial.com/grid-layout/

b) Specs do to similar things:

   b.1) http://dev.w3.org/csswg/css-template/#grid-shorthand

The above example, which refers to grid rearrangement, is a different
things I know. But I think it has similar points to this discussion:
shorthands that applies to HTML elements (or other elements) are good
things to developers.

m
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[pault]

A bit more on the TeX part of this argument. Over a decade ago my company 
polled publishers that accept submissions from authors of content containing 
math. Although not a scientific poll, the results were overwhelming. 
Approximately 85% of all submissions were in MS Word format with equations 
written using its Equation Editor (my company's product at the time, licensed 
to Microsoft).

It has been pointed out already here but let me emphasize that most math is not 
done by mathematicians. All K12 students must learn math so there's a huge 
industry to serve them. Half the departments at a typical university use math 
in their teaching (not just science and engineering but anything with 
statistics and business, economics). Mathematicians are a tiny fraction of the 
whole. I guarantee you that virtually all K-12 teachers have never heard of TeX.

Ok, with that dead horse beaten let me turn to MathML.

It was mentioned that MathML lacks open source tools to work with it. I believe 
one of the main reasons for this is the lack of browser support for MathML. It 
is ironic that most STEM publishers' internal workflows are based on XML and 
MathML for math but they can't deliver it to browsers. MathJax changes that of 
course which is why we now see the overwhelming interest in MathJax and its 
ability to render MathML.

It would be truly ironic if MathJax success killed MathML. MathJax does a truly 
heroic job of formatting mathematics. It is amazing to me that a JavaScript 
library can do so well. That said, it is a stand-in for true MathML support. It 
lacks access to fonts and character metrics as well as layout information. The 
fact that it works so well is due to the brilliance of Davide Cervone and the 
rest of the MathJax team and not because it is the right way to render MathML 
in a browser. That it is not truly integrated into the browser results in all 
sorts of struggles. As witness, see all the postings in its forums from people 
who run into trouble creating dynamic web pages containing math. They get into 
all sorts of tangles involving DOM changes, rendering, event processing order, 
etc.

Those of us that work in MathML and equation editing constantly run into the 
misconception that an equation rendering is more like an image than text. I 
think this is due to the fact that many document processing systems through 
history have had to handle math as an image because they don't support math 
directly. Mathematics is really just a fancy text format. Think subscripts and 
superscripts on steroids. Some chemistry notations fit into this mold as well 
but music and some of the other things mentioned in this thread are not. There 
is one easy way to tell if a notation is fancy text. Do books include the 
notation inline in paragraphs or not. Even with a block (or display) equation 
it flows with the text.

It was stated that Mozilla's two main competitors don't support MathML. While 
that is literally true, Internet Explorer has had the benefit of MathML display 
via my company's MathPlayer plug in for years. When we introduced it, Microsoft 
added some APIs specifically to allow us to do a better job integrating its 
rendering into the surrounding text. Most screen readers interface with 
MathPlayer to make math accessible to people with various disabilities.

Please don't turn your backs on MathML just as it is coming into its own. 
MathJax is a good stand-in for missing MathML support but it is does not 
eliminate the need for native support. Instead, it makes its absence all the 
more glaring and the need to fix the problem all the more urgent.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Trevor Saunders]

On Mon, May 06, 2013 at 07:13:04AM -0700, fred.w...@mathjax.org wrote:
> - For blind people or other visual disabilities, speech synthesizer must 
> follow the MathSpeak rules. Simply reading the text "normally", e.g. of a 
> LaTeX or ASCII source, is ambiguous.

I'd argue that any machine parsable format can't be ambiguous by virtue
of the fact machines parse it.  However in any case AtkText /
IAccessibleText / the mac accessible protocol thing all expect the text
for an object to be a string so whatever format the web uses screen
readers will be handling a serialized format.

> - For people with reading disabilities (dyslexia etc), you need to 
> synchronize highlight of equation parts / reading of equation parts.

this should actually work quiet naturally in my proposal since we can
tell API consumers that the bounds of characters in the serialized text
are those for the formatted text shown on screen.  That doesn't quiet
work for  { / } / ^ etc, but we can just give them a size of zero or
something, and that should probably be fine.

> In both cases, you must know a bit more about the mathematical structure e.g. 
> to have a DOM. It's not clear how to do that with plain text. It's just 
> absurd to believe that putting TeX source inside the alt text of an  
> makes the formula accessible. It might works for very simple equations like 
> x+2 but in general you'll have to do some parsing into an abstract 
> representation if you want to read/highlight it correctly. With MathML you 
> already have a standard representation and there already exist tools to work 
> with that language.

nobody is suggesting images with alt text.

 In the cases above which you discussed and Braille which you didn't the
 medium is fundimentally serial, so I'm not sure I buy that you need a
 tree.

Trev

> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[pault]

I think Fred's point here was that the literal text in the MathML or LaTeX is 
not what a blind person wants to hear. The whole point of math as a 2-D 
notation is that the relative position of the parts of the equation carry 
meaning. This is unlike normal text which almost always carries its whole 
message in its words and punctuation.

On Tuesday, May 7, 2013 1:59:17 PM UTC-7, Trevor Saunders wrote:
> On Mon, May 06, 2013 at 07:13:04AM -0700, fred.wang... wrote:
> 
> > - For blind people or other visual disabilities, speech synthesizer must 
> > follow the MathSpeak rules. Simply reading the text "normally", e.g. of a 
> > LaTeX or ASCII source, is ambiguous.
> 
> 
> 
> I'd argue that any machine parsable format can't be ambiguous by virtue
> 
> of the fact machines parse it.  However in any case AtkText /
> 
> IAccessibleText / the mac accessible protocol thing all expect the text
> 
> for an object to be a string so whatever format the web uses screen
> 
> readers will be handling a serialized format.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[fred . wang]

> I'd argue that any machine parsable format can't be ambiguous by virtue
> of the fact machines parse it.  However in any case AtkText /
> IAccessibleText / the mac accessible protocol thing all expect the text
> for an object to be a string so whatever format the web uses screen
> readers will be handling a serialized format.
> 

Sorry I was not clear here. Concretely, if "{x+1}/2" is read "x plus one over 
2", it's ambiguous since that could also mean "x + 1/2".  Blind people have 
standard rules to clarify reading of mathematical expressions and screen 
readers must follow these rules. That's not necessarily the order people 
usually read a formula. And reading "opening brace x plus closing brace slash 
two" is not what they want either. So at some point, someone will have to parse 
and understand the mathematical structure. That's essentially what MathPlayer 
and a MathJax extension prototype do from the MathML tree. I guess at the end 
they will send text strings to the reader anyway.

> > - For people with reading disabilities (dyslexia etc), you need to 
> > synchronize highlight of equation parts / reading of equation parts.
> this should actually work quiet naturally in my proposal since we can
> tell API consumers that the bounds of characters in the serialized text
> are those for the formatted text shown on screen.  That doesn't quiet
> work for  { / } / ^ etc, but we can just give them a size of zero or
> something, and that should probably be fine.

It seems that you are oversimplifying the issue here. First people proposing an 
alternative syntax will still need to define a mapping from the text source to 
the visual 2D representation if you want to know which part to highlight. For 
MathML it's the normal mapping from DOM to the rendering tree in Gecko but it's 
not clear what Benoit wants to use instead since without further info it seems 
that the DOM will just have a text node. Next, what you suggest seem to only 
work for variable names and it's not clear how you'll read e.g. operators or 
square roots. IIRC, to read a fraction the tools I mention highlight the 
numerator when they read it, then the whole fraction's bounding box when they 
read the "over", then the denominator when they read it. Or perhaps they 
highlight the whole fraction before, I don't remember exactly but the point is 
that it's not limited to text. I admit that I don't know the details but there 
are other similar sync rules between highlight and reading
 . Also, I hope you realize that mathematical layout is much more complex than 
just fractions and scripts so I don't think one can just say "I guess that will 
work" for such a nontrivial problem.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[pault]

Math accessibility is a surprisingly complex subject. How math should be read 
is dependent on the mathematical or scientific context in which the math is 
embedded, the educational level of the user, and their familiarity with the 
accessibility technology itself. In our grant work with the Educational Testing 
Service (ETS) we found out that a literal reading of a mathematical expression 
in a test question can give away the answer even when the graphical rendering 
doesn't. 

BTW, all this work is done with math expressed in MathML. It could use MathML 
structures obtained from MathJax but this means that the screen reader can't 
use MSAA (or equivalent) to get an IAccessible interface from a DOM node. As 
far as I know, there is no mechanism that allows JavaScript code to implement 
IAccessible.

Even with MathML implemented natively in browsers, it seems like accessibility 
mechanisms still need some work. While the HTML5 effort is busy adding access 
to device features (phone, camera, GPS, touch) for us in web apps, there has 
been no effort to do something similar for screen readers and for accessibility 
support in general. Screen reader vendors are currently being cut out of the 
mobile market as device makers are playing the old proprietary "that 
functionality is part of the OS" game.

I guess I am going a bit far afield here. My hope was to show that there is a 
lot happening with MathML technology. It is not time to pull the plug but 
properly support it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Simplify async code-flows and unify unit tests

[Mark Hammond]

On 7/05/2013 11:49 PM, Mike de Boer wrote:

TLDR; in bug 867742 I requested to adopt two JS modules, Async.jsm
and AsyncTest.jsm, in mozilla-central/toolkit/modules. The whole
story can be read below as well as at
https://gist.github.com/mikedeboer/5495405. I posted about this
subject before on firefox-dev:
https://mail.mozilla.org/pipermail/firefox-dev/2013-April/thread.html#268


I don't see the advantage to this, even after re-reading that thread. 
It seems like the biggest advantage is that it addresses *your* aversion 
to using promises while ignoring the fact that promises and Task.jsm are 
being used fairly extensively in our tests (and more and more in the 
production code).  To my mind, this alone makes your claim:


| most of the unit tests are written in the same structure and b) are
| structured in such a way that they're easy to read by someone other
| than you.

somewhat suspect - unless you are also proposing to remove promises from 
the existing tests?  Combine this with the non-obvious features such as 
magic prefixes for the test descriptions and I'm concerned this would 
make the cognitive overhead of understanding our tests worse rather than 
better.


While I appreciate the sentiment and would always encourage discussions 
which aim to make things better, I see more potential downsides than 
upsides in this proposal.


Just-my-2c ly,

Mark
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Simplify async code-flows and unify unit tests

[Joshua Cranmer 🐧]

On 5/7/2013 8:49 AM, Mike de Boer wrote:

I've told some of you before that I'm not a big fan of Promise libraries (if 
not, please read the 10 reasons to NOT use a Promise library: 
https://gist.github.com/mikedeboer/5305020).


For what it's worth, I am very unpersuaded by your argumentation. 
Rebutting your reasons:
1. Promises aren't meant to solve the async problem. In effect, they 
take code which would be written in a continuation passing style and 
rewrite that into a more natural serial chaining.

2. I'll grant you this, but this is a casualty of CPS code in general.
3. I don't understand your complaint here, and this may be because I'm 
trying to compare promises with similar use cases and you are not.
4. This is no more a problem than CPS code in general has. Actually, 
promises helps this by being able to propagate an exception to the last 
rejection handler. In effect, it brings back the notion that a careful 
API consumer can fix the problem of a careless API author.
5. This is true for general code on the web. This is not true for 
Mozilla code, where we have a single promises implementation.
6. Ditto. This also strikes me as "I didn't write this, therefore it 
sucks" syndrome.
7. It has been my experience that the environment of testing is often 
such a diverse field that everything breaks down into ad-hoc algorithms. 
Look through all of the xpcshell tests in comm-central to see what I mean.
8. Again, this strikes me as "I didn't write this, therefore it sucks." 
See also below.
9. All API tends to be inherently viral. It's hard to mix sync and async 
code, for example. At some level, most code is basically a glorified way 
to move data from one API to another.
10. Paraphrasing, this is "Promises are bad because they force you to 
write the promises model" (with an implicit "and that model is bad"). 
It's hard not to take this as "Promises are bad because I hate promises"


It's also interesting to note that your points 5, 6, and 8 are slippery 
slope arguments. Change a few words:


1. C++ implementations differ a LOT from each other, most often in the
   area of semantics. This makes it so that you may know one
   implementation, but can not use another.
2. The most-often used C++ implementations are not easy to contribute
   to. It isn't bug free (no software is). If you encounter one, the
   code is complex enough, so you'd have to wait until a more active or
   seasoned developer may be able to fix it.
3. in general - and more towards an opinion: you shouldn't use a helper
   library that you wouldn't be able to write yourself upon first
   glance. It might help you at first, but not in the long run.

Therefore, we should write all of our code in native machine code 
because we can't rely on C++ implementations, right? (There is a very 
long history of having to work around buggy compilers in our code, and 
probably many more problems have been uncovered in trying to build 
portable C/C++ code than you have seen between all promise libraries).




You can pass an Array of test suites or just one Object
Suites can have names
Tests can be described freely
It mixes fine with ANY assertion style (Mochi or XPCShell)
Prefix a test with ! to exclude it from the suite. This is something that is 
practically useful when doing TDD.
Prefix a test with > to only run that test and ignore the others. It is meant 
to signal out a test case and run only that specific one. This is something that 
is practically useful when doing TDD.
If the test is sync, you can forget about the next function (callback) 
completely - the library takes care of it; you can even mix async and non-async 
tests


Forgive me for saying this, but it sounds like using this test suite is 
a lot more painful for not using it. The tests that I need to write tend 
to come in two categories. Either they're a series of functions which 
run for an asynchronous amount of time, which yields tests like 
, 
or they are running essentially the same code on a large body of test 
inputs, like 
 
(large is relative--the rest of those tests are sitting in patches 
awaiting review). The former uses a common test framework for 
comm-central 
(), 
while the latter is an example of one my many ad-hoc test frameworks.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform