A bus painted by a painter who was "inspired" by the Firefox logo.
QEMU USENIX Paper
Fabrice's USENIX QEMU paper is now freely available.
[ Home | Articles | Account | People | Projects | FAQ ]
QEMU USENIX Paper
Fabrice's USENIX QEMU paper is now freely available.
As for condition #2 ("JavaScript disabled, Stylesheets enabled") mentioned in my previous post on this topic, I have found a better solution to the distracting "peek-a-boo" effect inherent in my previous solution. In the HEAD of the page, I have now put:
<script type="text/javascript"><!--
hideHiddenDivs( );
// --></script>
where hideHiddenDivs() is defined as:
function hideHiddenDivs( )
{
if( document.getElementById)
{
document.write(
'<style type="text/css"> div.hidden { display: none; } </style>');
}
}
I could have put this scriptlet inline, but there seems to be a problem with the parser of the W3C validator tool which complains about a "</style>" that does not end a STYLE element.A rant: I don't know much of HTML/CSS/JavaScript, but I really wish for the ability to "#include" files (for example, for page headers and footers) and to define macros (for example, to generate a news item's headline and content elements linked to each other). I know these can be overcome by using JavaScript and document.write(), but that's a kludge. I also know that these can be achieved on the server, but I do not want to depend on it - I keep moving my website from one (free) provider to another and I also like it to behave exactly the same way when accessed from my local filesystem as from a remote server. Note that we already have inclusion mechanisms for external stylesheets, scripts, etc. so this is not something too difficult to provide.
Now on to something that I hope you HTML/CSS/JavaScript gurus can help me with: I'm trying to implement a handy expandable/collapsible news entries mechanism for my website somewhat similar to what is explained in this article. I have already implemented most of what I want and it can be seen in action on my site, but it's not "right". In particular, I want this system to behave properly whether JavaScript is enabled or not and whether stylesheets are enabled or not, that is, under the following conditions:
For doing #2, I make the stylesheet actually declare "hidden" elements as visible, but then use JavaScript attached to the "onload" event of the page to turn them invisible - if the user doesn't have JavaScript enabled, he still gets to see all the content properly. Note that I cannot use the alternative suggested in the article I have linked to; that is, something like:
<noscript>
<style type="text/css">
.hidden { display: block; }
</style>
</noscript>
does not work since the W3C validator rejects it - NOSCRIPT cannot occur inside HEAD, but STYLE can only occur inside HEAD. The downside of my approach is that there is a short but noticeable and sometimes distracting phase under both IE and Firefox, where the browser loads and renders the full page and then hides the hidden sections. Isn't there a better way of achieving this while still remaining strictly valid?
#3 poses a slight problem in that I wish that even the "togglers" do not appear if stylesheets are disabled. I was thinking of iterating through the stylesheets defined for the document in the DOM and check if all of them are disabled and omit emitting the togglers if they are. Is there a better way of doing this?
#4 is automatically taken care of by the "solution" to #2, since only JavaScript is used to emit the togglers. The user still gets to see the entire contents.
Perhaps I'm just wasting my time as #2 and #3 are unlikely to happen with real visitors to my pages - #1 is what almost all human visitors are likely to have and #4 is what almost all search engine bots are likely to have. This impractical fussing might explain why I have not become a manager. ;-)
While I was at it, I renamed the folders and files that had names like "phartz", "philez", etc. - these names had looked "kewl" half a decade ago, but now look rather juvenile. This results in some of the links posted elsewhere becoming invalid and I apologise to anyone affected by this change. I have also implemented support for simple expandable and collapsible sections so that some of the pages do not appear intimidatingly verbose.
Right now the website is mostly an exercise in vanity. I need to add content that is actually useful so that someone other than googlebot finds the website interesting.
GCC and Google Summer of Code 2006
GCC is looking for students interested in working in Google's Summer of Code on a project helping GCC.
To get a feel for ZINC and Redcode, look at the following simple warrior:
; Bomb every fourth cell in the core with a "DAT #0".
org start
target:
dat #0
start:
add #4, $target
mov #0, @target
jmp $start
Redcode looks very similar to the assembly language of many modern microprocessors. A DAT #0 instruction indicates the number 0 stored as the datum at that location in memory. This instruction is itself encoded as 0 and is not executable - an attempt to execute this instruction leads to the death of a warrior. So the warrior shown above (called "Dwarf", a classic Core War warrior) bombs every fourth location in the core in the hopes of fatally wounding an opponent. Note that Core War only supports relative addressing and @ represents indirect addressing (the location pointed to contains a pointer to the final location). More details, including a tutorial for beginners, are available in the ZINC User Manual as well as on sites like www.koth.org and www.corewar.info. There is also an active USENET newsgroup rec.games.corewar for Core War enthusiasts.
ZINC is currently at version 0.1 and is Free Software released under the GNU General Public Licence (GPL).
By the way, I expect to receive a lot of flame for my decision to not recognise TAB characters as whitespace in the Redcode dialect implemented by ZINC.
GCJ
I seemed to be in my elements on the GCJ list this week, provoking a thread on the lack of good support in GCJ for Windows and eliciting a reply from the GCC Steering Committee on the status of the proposal to integrate ECJ into GCJ.
More Front Ends in GCC
One of the great advantages of structuring a compiler such that the front-end, the middle-end and the back-end are relatively independent is that if you write M front-ends and have N back-ends, you get M*N compilers "for free" assuming you have a good enough intermediate representation in the middle-end. This idea was discussed as far back as the 1950s and UNCOL was an ambitious effort towards this goal. GCC is a stellar example of such a compiler - it supports C, C++, Java, Ada, etc. "out-of-the-box" and can target a whole bunch of platforms. You implement a language front-end for GCC and you immediately have a compiler for that language for a whole lot of platforms; you implement a target back-end for GCC and you immediately have compilers for several languages for that platform. Of course, this is grossly oversimplified, since you have to usually port the language runtime to a platform too or since your language might strain the GCC intermediate representation or expose latent bugs in the middle-end making the effort rather difficult. But the overall idea still remains valid.
The GNU Pascal Compiler (GPC) guys recently proposed an integration of GPC with GCC (in the same source repository, but on a different branch - weird). Some day, the GCC Scheme Compiler (GSC) guys, the PL/I for GCC guys, etc. might also want to integrate their front-ends with GCC. Having more front-ends in the GCC source tree itself means that middle-end changes do not inadvertently break these front-ends, latent middle-end bugs and unwarranted assumptions are exposed, general GCC enhancements are automatically applied, etc. So it's a good thing for GCC, in a way.
However, I personally think it is not a good idea. The GCC mainline is already quite bloated with a number of languages and runtimes and building all of the languages and their runtime libraries (thank you Sun for regularly increasing the bloat in the "standard" Java runtime with every release of the JDK) takes quite a while even on a decent system. Having more languages and their runtimes within GCC will only exacerbate this issue. I personally also feel (though I have no real practical experience in this area) that it does not let the optimisers make assumptions that they can use to perform stronger optimisations. A recurring problem in this area is the folding of constants, where languages like Java specify a bit too much with respect to what can be folded and how it should be folded.
On a slightly different note, the GSC guys have also created a "Hello World" front-end for GCC that shows you how to build a front-end for GCC for your favourite language.
On an entirely different note, I have ended up writing 3,000 lines of text in the user manual of a 4,000 line programme (both rough "wc -l" figures)! Either the manual is unnecessarily verbose or the programme is too complex.
Texinfo proved very simple to learn and produces fairly good looking HTML and PDF files (although some people prefer texi2html to "makeinfo --html" for HTML output). It can also output DocBook XML files, though I don't know how good the output is since I don't know the DocBook system yet. I am very happy with the tool so far. I haven't learnt a whole lot of Texinfo yet, but since when has that stopped me from making a fool of myself?
There are still some warts that I see with the Texinfo system though:
These rants aside, I am still sticking with Texinfo for the documentation for my little projects, though for "paper-like" stuff, I'm going to prefer LaTeX.
Miscellaneous
Steve Yegge is now on Blogger for those of you who can't seem to have enough of his rants.
Ranjit Madampath pointed me to a rather hilarious entry on Frameworks in the Joel on Software discussion group.
Planet Scheme used to be available as planet-scheme.yi.org, but it seems to be dead now. I used to like reading the aggregated weblogs of a lot of smart Scheme hackers, the weblog of José Antonio Ortega Ruiz in particular.
Miscellaneous
Firefox leads to a breakup. I don't know whether I should feel sorry for the bloke who was dumped or the lady who had to change her email address possibly after being bombarded with tonnes of silly emails. I do know that I found this bug report rather funny.
As I had feared, I performed miserably in the qualifying round of the Google Code Jam India 2006. Good luck to the people who moved on to the next round.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!