I am now moving to rmathew.blogspot.com for blogging. I find Advogato a bit painful to use for blogging. I also do not want to be restricted to only talking about hacking on Free Software.
(Originally posted on Advogato.)
Showing posts with label advogato diary. Show all posts
Showing posts with label advogato diary. Show all posts
2006-05-31
2006-05-17
Google and Maths
"Fuzzy Maths", an article on Google in the latest edition of The Economist, contains this interesting bit:
Their famous recruitment campaign and their very name further reinforce the impression of their obsession with Mathematics.
(Originally posted on Advogato.)
Google constantly leaves numerical puns and riddles for those who care to look in the right places. When it filed the regulatory documents for its stockmarket listing in 2004, it said that it planned to raise $2,718,281,828, which is $e billion to the nearest dollar. A year later, it filed again to sell another batch of shares -- precisely 14,159,265, which represents the first eight digits after the decimal in the number pi (3.14159265).
Their famous recruitment campaign and their very name further reinforce the impression of their obsession with Mathematics.
(Originally posted on Advogato.)
Labels:
advogato diary,
fun
2006-05-10
Peer to Patent
The US Patents and Trademarks Office will soon try out Peer to Patent as a pilot project. This is great news. It is really important for silly patents to get rejected upfront than be granted and then used to bully everyone into either paying up an extortion fee or engaging in costly lawsuits. Unfortunately, there is still the problem of lots of such silly patents having already been granted and used for corporate "defence funds" (an equivalent of the "Mutual Assured Destruction" strategy) or towards unscrupulous ends.
The Economist has a nice set of balanced articles on patents and other IP-related topics.
(Originally posted on Advogato.)
The Economist has a nice set of balanced articles on patents and other IP-related topics.
(Originally posted on Advogato.)
Labels:
advogato diary
Security: The 3 As and the 3 Rs
(I am just collecting my thoughts here; I do not require anything like this right away.)
A useful framework for security should provide:
The authentication framework should be able to able to plug into various authentication mechanisms (OS-based, LDAP-based, etc.), be flexible enough to accept various types of credentials (username/password, PKI certificate, etc.) and reliably establish the "Identity" of the user.
The authorisation framework should allow the specification of:
Role-based authorisation allows for the maximum flexibility compared to the direct checking of the Rights of the given Identity. An Identity could be associated with multiple Roles. Realms establish domains of privileges - for example, a person has administrator privileges on his desktop PC but is just an ordinary user on the LAN. Rights could be positively stated ("Allow Foo") or negatively stated ("Disallow Bar"). Authorisation could be inclusive (at least one Role associated with the Identity has the Right) or exclusive (no Role associated with the Identity should be denied the Right). I personally favour positively stated Rights and inclusive authorisation.
The auditing framework would be used for non-repudiation, so it should have integrity (only the auditing framework could have written out a given audit record) and an almost transactional association with the respective action (record an action if and only if it was actually done).
Of course, in real "enterprise" software we end up with various degrees of compromise on each of these aspects.
(Originally posted on Advogato.)
A useful framework for security should provide:
- Authentication - verifying that the user is indeed who he claims to be.
- Authorisation - verifying that the user is indeed allowed to do what he wants to do.
- Auditing - recording the attempt to do the intended action, its outcome and whether the action was indeed done.
The authentication framework should be able to able to plug into various authentication mechanisms (OS-based, LDAP-based, etc.), be flexible enough to accept various types of credentials (username/password, PKI certificate, etc.) and reliably establish the "Identity" of the user.
The authorisation framework should allow the specification of:
- Rights - what is allowed.
- Roles - who is allowed to do it.
- Realms - where are they allowed to do it.
Role-based authorisation allows for the maximum flexibility compared to the direct checking of the Rights of the given Identity. An Identity could be associated with multiple Roles. Realms establish domains of privileges - for example, a person has administrator privileges on his desktop PC but is just an ordinary user on the LAN. Rights could be positively stated ("Allow Foo") or negatively stated ("Disallow Bar"). Authorisation could be inclusive (at least one Role associated with the Identity has the Right) or exclusive (no Role associated with the Identity should be denied the Right). I personally favour positively stated Rights and inclusive authorisation.
The auditing framework would be used for non-repudiation, so it should have integrity (only the auditing framework could have written out a given audit record) and an almost transactional association with the respective action (record an action if and only if it was actually done).
Of course, in real "enterprise" software we end up with various degrees of compromise on each of these aspects.
(Originally posted on Advogato.)
Labels:
advogato diary,
gyaan,
programming
2006-05-05
Faster Logging
When you have an application that must log information (for auditing, debugging, etc.) but still run as fast as possible, it is rather wasteful to always dump fully-formatted human-readable trace records. It's far better to dump a short binary record indicating the message identifier, parameters for the message (if any), timestamp, process/thread identifier, etc. that can be processed later for human consumption using a separate "trace formatter" tool. This way you save on processing time and disc space but make it slightly inconvenient to view the log files.
On UNIX-like systems, utmp and wtmp records are created and processed this way. I have also seen this kind of logging in IBM's AIX operating system and its CICS transaction processing monitor. Why then do several modern "high-performance" applications still insist on using the slower and more bloated method?
(Originally posted on Advogato.)
On UNIX-like systems, utmp and wtmp records are created and processed this way. I have also seen this kind of logging in IBM's AIX operating system and its CICS transaction processing monitor. Why then do several modern "high-performance" applications still insist on using the slower and more bloated method?
(Originally posted on Advogato.)
Labels:
advogato diary,
gyaan,
programming
2006-05-02
Planet GCC
There is now a Planet GCC aggregating the feeds from Planet Classpath and the blogs of a bunch of GCC hackers. If you know of a blog of a GCC hacker that is not directly or indirectly aggregated here, please let Dan know. Thanks to Dan for this initiative.
(Originally posted on Advogato.)
(Originally posted on Advogato.)
Labels:
advogato diary,
blogging,
gcc
2006-04-27
Worse than the DMCA
The Intellectual Property Protection Act (IPPA) looks even worse than the DMCA. If you are a US citizen, please do what you can to campaign against this threat to your fair-use rights.
The irritating thing about such laws is that they affect even non-US citizens, since other countries do not want to be seen as harbouring or encouraging "intellectual property thieves" and usually play along with whatever the US comes up with (except for the EU in some notable cases). Even more irritating for us non-US citizens is the apparent willingness of the US lawmakers to please corporates and various lobbyist groups in creating sometimes extremely draconian or irrational laws to the detriment of the fundamental rights of its own citizens (and the US citizens do not seem to mind all this very much). The appalling thing is that the magic word "terrorism" is used as a blanket weapon to silence killjoys who dare to question such travesties.
The proposed PERFORM Act is another example of what I am talking about.
(Originally posted on Advogato.)
The irritating thing about such laws is that they affect even non-US citizens, since other countries do not want to be seen as harbouring or encouraging "intellectual property thieves" and usually play along with whatever the US comes up with (except for the EU in some notable cases). Even more irritating for us non-US citizens is the apparent willingness of the US lawmakers to please corporates and various lobbyist groups in creating sometimes extremely draconian or irrational laws to the detriment of the fundamental rights of its own citizens (and the US citizens do not seem to mind all this very much). The appalling thing is that the magic word "terrorism" is used as a blanket weapon to silence killjoys who dare to question such travesties.
The proposed PERFORM Act is another example of what I am talking about.
(Originally posted on Advogato.)
Labels:
advogato diary
2006-04-26
Website Maintenance
I am now using GNU Make and GNU m4 to maintain my website. The main advantages of these tools over others were that I was already familiar with them and they were readily available on the platforms I work on. Some of the things that are now easily possible with the new setup:
I use the --prefix-builtins option of m4 (just to be a bit safer) and had to use different quote characters in some places because it was getting a bit confused with embedded apostrophes in JavaScript method calls and commas in normal text.
(Originally posted on Advogato.)
- Having a common header and footer for all the pages. They need to be edited just once and all affected pages are automatically regenerated. I can now add/delete sections of my website at will and the common site-navigation menu in all pages is updated automatically. This has already proved quite useful as I deleted the "Links" section of the website.
- Allowing a page to specify its section ("Articles", "Books", etc.), the location of the root folder with respect to its own location and the title for the page. This lets the common header and footer correctly specify the location to images, scripts, stylesheets, etc., generate the correct page title and highlight the appropriate section in the common site-navigation menu.
- Automatically updating the "Last Updated" date in a page footer based on when the page was actually updated, instead of having to manually remember to change that text every time I edit the page.
- Automatically generating a "news entry" such that its title and body are linked together appropriately for my particular expandable/collapsible sections implementation.
I use the --prefix-builtins option of m4 (just to be a bit safer) and had to use different quote characters in some places because it was getting a bit confused with embedded apostrophes in JavaScript method calls and commas in normal text.
(Originally posted on Advogato.)
Labels:
advogato diary,
gyaan,
web site
2006-04-21
2006-04-20
HTML/CSS/JavaScript: Duh!
dorward: Thanks again for your comments. I don't know why it didn't occur to me to use GCC itself as a pre-processor. Some of the simple things I tried out worked well with GCC. I haven't checked out The Dolt yet.
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:
where hideHiddenDivs() is defined as:
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.
(Originally posted on Advogato.)
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.
(Originally posted on Advogato.)
Labels:
advogato diary,
web site
2006-04-19
HTML/CSS/JavaScript
Ankh, dorward: Thanks for your comments. For a sloth like me, it's not easy to once again overhaul the entire site to make it XHTML - I'll let it remain at HTML 4.01 for the time being. By the way dorward, I did not know until very recently that unlike XML, things like "<br/>" are not valid HTML elements. I used to insert "<br/>", "<p/>", "<hr/>", etc. liberally throughout my pages mistakenly thinking it's the "right" thing to do.
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:
My implementation works right now under #1.
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:
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. ;-)
(Originally posted on Advogato.)
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:
- JavaScript enabled, Stylesheets enabled
- JavaScript disabled, Stylesheets enabled
- JavaScript enabled, Stylesheets disabled
- JavaScript disabled, Stylesheets disabled
My implementation works right now under #1.
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. ;-)
(Originally posted on Advogato.)
Labels:
advogato diary,
help needed,
web site
2006-04-17
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.
(Originally posted on Advogato.)
(Originally posted on Advogato.)
Labels:
advogato diary,
gcc,
help needed
Website Redesign
After a long procrastination, I have finally updated my website to be more standards-compliant, better looking and somewhat easier to navigate. I wanted to shift completely over to XHTML but that has its problems besides lack of support in Internet Explorer. I have therefore settled for HTML 4.01 Strict. Every page on my website should now validate with the W3C validator. To enhance the looks of the site, I am using a variant of the Sinorca 2.0 design created by haran and provided by OSWD. I stumbled upon OSWD while admiring the recent makeover of Tom's site (which uses the Blue Haze design also created by haran).
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.
(Originally posted on Advogato.)
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.
(Originally posted on Advogato.)
Labels:
advogato diary,
web site
2006-04-07
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.
(Originally posted on Advogato.)
(Originally posted on Advogato.)
Labels:
advogato diary,
gcc,
gcj
ZINC
ZINC is a variant of the game of Core War in which programmes (called "warriors") fight each other in a battle to control a virtual computer. The programmes are written in a simple language called Redcode and run inside an emulator known as Memory Array Redcode Simulator (MARS). ZINC implements a simpler and more symmetric dialect of the Redcode language than the current International Core War Society (ICWS) standard known as ICWS-94.
To get a feel for ZINC and Redcode, look at the following simple warrior:
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.
(Originally posted on Advogato.)
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.
(Originally posted on Advogato.)
Labels:
advogato diary,
core-war,
fun,
programming,
zinc
2006-04-03
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.
(Originally posted on Advogato.)
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.
(Originally posted on Advogato.)
Labels:
advogato diary,
compilers,
gcc
ECJ for GCJ: Still in limbo
It has been almost a month since Tom formally proposed integrating ECJ in GCJ to the GCC Steering Committee (SC). There has been no word from the SC yet on this request. However, the SC did ask the GCC developers to avoid gratuitously including source code from external projects in GCC. One consequence of this for GCJ was the removal of fastjar from the GCC source tree. I'm not sure if the SC's decision was coincidental or in fact a result of deliberations triggered by Tom's request.
(Originally posted on Advogato.)
(Originally posted on Advogato.)
Labels:
advogato diary,
gcc,
gcj
2006-03-28
Tatjana van Vark
Tatjana van Vark looks like an amazing Dutch inventor and machinist. Just look at her works and you'll know what I mean. My favourites were the oscilloscope that she created when she was just 14 years old and an Enigma-like "Coding Machine". I just wish they had put up some more information about the devices than just the pictures. Another of those humbling experiences for yours truly.
(Originally posted on Advogato.)
(Originally posted on Advogato.)
Labels:
advogato diary,
fun
2006-03-27
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 Jose Antonio Ortega Ruiz in particular.
(Originally posted on Advogato.)
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 Jose Antonio Ortega Ruiz in particular.
(Originally posted on Advogato.)
Labels:
advogato diary,
blogging,
fun,
programming
Subscribe to:
Comments (Atom)
