jy[B]log

I just read the blog post of Mike Connor, Firefox's lead engineer. And I'm depressed.

This is now official, the successor to Nvu is BlueGriffon™.

Daniel has already done a lot of work on it, but we are not ready yet to release a first public version. However, you can take a look at our svn repository for the source code.

Of course, I will work on this project :

• I will develop some patches on Gecko to improve the editor. I began with a big revamp of the serializer, so XHTML will be much better serialized
• I will work on the web front-end : software update, web tools, etc..

My new prototype of a relaxng parser/validator in javascript is finished :-). It passes all tests !

(Previous status).

I will make other tests with my own tests suite, and I will begin to develop the C++ version.

My new RelaxNG parser is almost finished. I still have to implement the checking of string sequence restrictions. I didn't really work on the validator it self.

Here is the current status of tests.

(Previous status).

Mozilla developers improve day after day Javascript. It's a good thing to improve a language. But I think those who made this improvements in Mozilla should stop smoking the carpet right now.

Improvements in javascript 1.6 (Firefox 1.5) were good, although I'm not a fan to pass a callback function to each array function. I would prefer to have a real support of array with for each statement like the foreach statement in PHP instead of to have this for each statement which return not only elements of the array, but all all the properties of the array object. However E4X was a good improvement in Javascript 1.6.

They began to do crazy things with javascript 1.7 (Firefox 2).

Generators can be useful, but conceptually, it begins to introduce some things that can be disruptive for a "normal" web developer (you know, one of these thousand of thousand web developers who made millions of web site). And it is difficult in a complex function to distinguish a normal function from a generator because the difference is only the use of this small keyword yield.

Iterator is a good thing, but I don't know why we should catch an exception to know when the iterator stops. That sucks. (Interface like PHP iterators is better IMHO).

The goal of array comprehensions is to make easy initialization of array. It would be a good thing if the syntax didn't sucks too.

var ten_squares = [i * i for (i in range(0, 10))];
var evens = [i for (i in range(0, 21)) if (i % 2 == 0)];

Sorry but it is unreadable. Good luck for those who will maintain such code. Look at this example pointed by John that we can do in Javascript 1.8 (Firefox 3):

dict([s, [u for (u in unitlist) if (u.contains(s))]] for (s in squares))

I think this is a good example of unmaintainable code. No specific keywords, no really separators. I'm sure it will be a nightmare for maintainers.

In his post, John Resig shows other things like this horrible "expression closures" feature. I don't see any advantage to write function(x) x * x instead of function(x) { return x * x; }. It is less comprehensive, less readable.

I think only nerds will play with this "features", and "normal" developers and geeks will continue to use javascript 1.5. There is an evidence : in all javascript file of Firefox 3 and other Mozilla products in the trunk, i don't find any use of let, yield or other features of Javascript 1.7.

Glazou gave me only one advantage of this new features : web/XUL developers won't have to use JS obfuscators...

I worked hard on the prototype of my new validator. The architecture of the RelaxNg parser is nearly finished, and it uses the sax parser of Mozilla. I'm happy of this new architecture because it's cleaner, I don't have to use ugly hacks to do some things since it is less complex...

Here are current results of my "UnitTest'O'Meter" showed in a little app I made to launch James Clark's test suite (little xulrunner application based on the RelaxNG Validator Extension for Etna) :-)

update: sorry, there aren't 286 documents to test, but 529. I updated the table.

The web nowadays is not only distant html sites, it is also rich internet applications. We can consider desktop applications as rich internet applications because more and more of this desktop applications are based on web services, are linked intimately to the web, to the internet. And then more and more technologies allow to merge the web and the desktop. So in the future, Firefox will represent only a part of the purpose of the web. So I think the development of a platform for Rich Desktop Application follow the goal of Mozilla Fundation : maintaining the choice and the innovation on the Internet.

And because XulRunner is a great platform for this kind of application, and because the new web shouldn't fall only into the hand of Microsoft (through Silverlight,Xaml...) and Adobe (through Apollo, Flex...), Mozilla should invest more on XulRunner. So, as Daniel said:

Mozilla, please, turn XULRunner into a Mozilla product !

Between two customer projects, I'm working on Etna. The future version, Etna 0.4, will be based on Gecko 1.9/Xulrunner 1.9. Each day, I synchronize the source code of Etna with the Mozilla trunk. Here are some bug fixes and improvements since few months:

• Almost all the regression bugs which appeared during the gecko 1.9 port, are fixed. This port is a hard work because
  1. The source code of Etna 0.3.1 is based on Gecko 1.7. Many things have changed between Gecko 1.7 and 1.9. Last year I produced an experimental version based on Gecko 1.8/XulRunner 1.8, but I decided to migrate to gecko 1.9, because of all big changes in the Mozilla trunk.
  2. the DOM implementation of Gecko 1.9 has improved and it respects now the DOM Level 3 specification. So I had to find and modify all code which use old behaviors of the DOM Level 2 implementation. For example, see bug 140, bug 141..
  3. the build strategy has changed in gecko 1.9 : I tried to build my components as external components, not into the new big library "libxul". But my code uses too many internal API of Gecko, and it seems that the libxul exports less and less internal API. However, I had to change many things (headers, makefile options etc..) to build my components into the libxul (and when you see that the documentation about the build system is closed to nothingness or is deprecated..).
  4. Fortunately, the source code of the mozilla editor (libeditor) have not been improved very much (just bug fixes, improvements about accessibility, or IME), so I didn't have much work on parts related to this libeditor.
• I fixed other bugs on the RelaxNG parser, the validator and the UI :
  • bug 146 : the validation of time datatype was wrong
  • bug 155 : problem during the namespace setting on a new document
  • bug 151 : there wasn't dialog when we closed the window and the document was modified.

Now the gecko 1.9 port is almost finished, I will try to fix old bugs before doing improvements into the UI or the API. I think the 0.4 version will be only a maintenance release with few improvements and of course a better rendering engine (gecko 1.9). The 0.5 version will have new editing features and a better validator. For example, I plan to use the new sax parser API of gecko to read relaxNG schema, instead of loading a DOM : so the relaxNG parser will be faster and will use less memory. And finally, the 0.6 version will have many improvements on the user interface.

No date for all this release. I will publish a zip of my current source code.

I will try also to publish such post more often :-).

This is a very first version of Etna, based on Xulrunner 1.8.0.1 sources. For the moment, only the chrome works. I haven' t built the validator or others of my components, and my patch on the libeditor, to add the xml version of nsEditor, is not applied. But i hacked some file of the mozilla build system (configure.in, allmakefiles.sh etc.) and i think i have done a clean job on it now (compared to my previous work with gecko 1.7 sources). So now i can set in my mozconfig file :

mk_add_options MOZ_CO_PROJECT=etna
ac_add_options --enable-application=etna

(well, etna is not in the mozilla repository, so perhaps the first line is useless, i'm not sure..). And there is now this flag :

 ac_add_options --enable-xml-editor

So the build will contain the xml version of the libeditor. It is enabled by default for Etna, and this could be used for other projects :-)

In order to test the internal validator of Etna with the docbook schema, i would like to find many docbook files (normal or huge, but not some little examples). Please tell me if you have got such files or if you know where to find some Thanks.