This is just a spot to keep miscellaneous links. It also shows you what a geek I am.
Monday, July 10, 2006
From Wikipedia, the free encyclopedia
Jump to: navigation, search
For multi-threaded programming, see Thread (computer science).
In computer science, the term threaded code refers to an implementation technique for programming languages that produces very compact code. Threading is a form of code consisting entirely of subroutine calls, written without the subroutine call instruction, and processed by an interpreter, which jumps to each successive subroutine in turn.
Threaded code is used in the Forth and early versions of the B programming languages, as well as many implementations of FORTRAN, BASIC, COBOL and other languages for small minicomputers.
The benefits of extremely compact code, in some cases, come at the expense of slower execution speed. However, in other cases there is a synergistic effect -- sometimes threaded code is smaller and faster than non-threaded code. In systems with virtual memory (where memory is simulated with a mechanical disk drive), threaded code may be hundreds of times faster than a less-compact design that does not fit in the available physical memory, because disk drives tend to be roughly a thousand times slower than random-access memory (RAM)."
Sunday, April 16, 2006
From Lambda the Ultimate:
E Thesis: Robust Composition
Mark S. Miller's PhD thesis on Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control is now online.
E rates as a (very) important language for anyone interested in ideas of messaging, distribution and security. The nice thing about a thesis (such as this one and Joe Armstrong's) is that it gives a nice historical account of the related work and influences.When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference.
Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain.
And from Joe Armstrong SICS home page: "Programming reliable systems (Ph.D. thesis)
making reliable systems in the presence of software errors.
Here are some ideas on how to make reliable systems that function even in the presence of software errors. This thesis describes the thinking behind Erlang, Concurrency Oriented Programing, UBF and building reliable systems from communicating components."
From Erlang:
Related links:
Wednesday, February 15, 2006
Salamander is a .NET decompiler that converts executable files (.EXE or .DLL) from Intermediate Language (IL) binary format to high-level source codes, such as C#, managed C++, Visual Basic.NET, etc. For more than 8,000 classes that have been tested, Salamander always produces equivalent and recompilable codes that are remarkably close to the original source codes.
you can try it online here
Another very interesting decomplier is Ankarino, a very powerful command line tool which is provided as an open source utility, so you can get under the covers and see how it works.
give it a whirl here"
http://groups.google.com/groups?hl=en&threadm=eWoEy3V8BHA.1380%40tkmsftngp03"
Thursday, February 09, 2006
Some great suggestions from this article!
"Debugging Asynchronous Applications?
Posted by Cliff on Wednesday February 08, @08:20PM
from the mind-your-breakpoints dept.
Communications Programming
duncan bayne asks: 'I'm attempting to debug a complicated telephony application, written in C#, that's almost entirely event driven. This is the first time I've debugged a large asynchronous application that isn't a GUI, and I'm curious to know what advice the Slashdot crowd has to share - have you any recommended tools, best practices, or common pitfalls to avoid?'"
I'm not sure if you are 2.0 yet, but if you are, start by taking a look at VS2005. In the debug department, enhancements include better JIT debugging, stepping into XML/Web services from a client, and state-driven object inspection. Object Test Bench (OTB) is a simple object-level test utility. You create instances of your objects, invoke methods, and evaluate results... to shorten the task of coding, debugging and re-coding. I'm not sure about telephony specifically, but WSE/WS* SOAP layers can be hard to manuever through in a debugger, yet VS2005 does it quite nicely via WSDL.
One other suggestion... "event bus" apps like you describe are good candidates for capturing as much runtime data as possible, so make sure you adjust your build parameters and do as much of that as possible, especially in problem assemblies. Oh, and don't forget to build nUnits. Sounds like you're walking into some prewritten code, but the effort might be worthwhile.
Tuesday, February 07, 2006
A new release of Shriram Krishnamurthi's programming languages book is available."
Scheme, Haskell, Prolog. He implements a lot of this crap in the book.
Friday, February 03, 2006
On this site you'll find some quick links to several sites about .NET, ASP.NET, upcoming technologies etc as well as links to my own articles and other projects I'm participating in.
I hope you enjoy your visit on my site! Also check out my technical blog which is updated far more regularly than this website :-).
Author: Bart De Smet, MVP on Visual C#
Thursday, February 02, 2006
There was Microsoft's Intentional Programming which does something along the line of what you want though less ambitious. SCID is a similar thing that was thought up earlier.
By Derek Elkins at Thu, 01/26/2006 - 18:59 | login or register to post comments
Re: SCID
SCID looks neat, thanks for the link! (Although, at least at first blush it reads like a hyper IDE vs. something which can transmogrify between horribly different languages.)
By raould at Thu, 01/26/2006 - 21:24 | login or register to post comments
Not automated but...
It can't really be automated at this point, but there are efforts being done for more language interoperability. .Net is one of the examples, and a lot of people are now reusing the JVM in order to be 'Java compatible'.
However for both of theses you need to target either an high level language (by generating Java or C# sources) or directly the VM bytecode (JVM or CLR). That's why I wrote NekoVM which defines an easy-to-target intermediate language and provide the VM and the libraries to run it.
It should greatly ease the language compiler implementation by providing a common runtime. And if you write a Neko -> Your language converter, you will be able to reverse the process, and translate other languages targeting Neko back into yours."
Thursday, January 26, 2006
I know there was C? topic before. But the discussion really had more to do with Xen (XML, DB integration) than the Polyphonic C# concurrency part. I'm an Erlang newbie myself, but I already can see that asynchronous communication is the common thread to both languages and this approach is going to be big - can be used from embedded system to biz process orchestration.
Looking at the Santa Claus sample, C? code seems to be quite compact and the syntax extension to C# is minimal. However process/thread creation is implicit, and it seems to be a little more difficult to reason. I would imagine a solution in Erlang clearer, but maybe longer.
Any thoughts/pointers on the pros and cons of different concurrency approaches? We really should have a 'great concurrency shootout'."
MochiKit is a highly documented and well tested, suite of JavaScript libraries that will help you get shit done, fast. We took all the good ideas we could find from our Python, Objective-C, etc. experience and adapted it to the crazy world of JavaScript.
Reliable
MochiKit has HUNDREDS of tests. We build real applications with this thing. So even though development can move fast, we make sure to get tests written. This also makes platform compatibility issues much easier to detect and resolve than the 'guess and check' style of quality assurance seen in some of the other libraries out there. It's not broken.
Documented
You're unlikely to find any JavaScript code with better documentation than MochiKit. We make a point to maintain 100% documentation coverage for all of MochiKit at all times. You don't have to fumble around reading our source code or leafing through examples to find out how something works.
Evolutionary
MochiKit can adapt to anything you throw at it. It makes no assumptions about how your code needs to act, and it has hooks (by way of the the adapter registries) that makes sure that you can define your own comparisons, programmer representations, iterators, or DOM node coercion for any object in any way you wish. We'll gladly serve you all the Kool-Aid you want, but we're not goi"
This seems like a nice summary of various approaches, and provides an interesting prespective on prototype based languages in general and on Javascript in particular. Some of the libraries mentioned were discussed here before.
It is tempting to compare this to various documents trying to show 'how to add objects to Scheme/Haskell/etc.' The solutions are rather similar..."
Wednesday, January 25, 2006
Posted by ScuttleMonkey on Wednesday January 25, @08:56AM
from the focus-on-the-problem dept.
An anonymous reader writes 'Content management specialist Seth Gottlieb has written an easy to understand how-to on selecting an open source CMS. Gottlieb is also responsible for the whitepaper 'Content Management Problems and Open Source Solutions' which summarizes 15 open source projects and distinguishes between open source CMS and proprietary software selection.'"
Tuesday, January 24, 2006
(Reflections on a Mythic Beast Who's Quite Remarkable, at Least.)
I NEVER saw a Purple Cow;
I never hope to See One;
But I can Tell you, Anyhow,
I'd rather See than Be One. "
Monday, January 23, 2006
Sunday, January 22, 2006
Thursday, January 19, 2006
The power and simplicity of GParted on a biz-card sized LiveCD.
The CD aims to be fast, small in size, and use minimal resources
to get that disk partitioned the way you want it. GParted LiveCD is based on Slackware Linux and uses Xfree86's Xvesa, the lightweight Fluxbox window manager, and the lastest 2.6 Linux Kernel.
Being up to date is important! GParted LiveCD will be updated along side the GParted source releases and have minor releases when bugs are fixed or new filesystem tools become available.
GParted LiveCD runs on most x86 machines with a PII or better and a Vesa 2.0 compatible video card."
Wednesday, January 18, 2006
I was involved in an eternal debate again. This time I was very much convinced that it was going to be an easy one as it is one of my favorite topic. DataSets Vs Custom Entities. I can already see few eyebrows raised. J I know most of the times the answer is ‘It depends”. The job was cut out for me as I had to defend an Architecture which was using Custom Entities as data carriers. I am glad that I had to defend custom entities as that’s my personal preference as well. I probably won’t go into the complete details of my defending points. Probably, I shall write another post which will include all the points to consider before deciding upon the right data carrier for any application."
Are these Microsoft guys? In any case, Siram Krishnan (previous post) mentions Roshan James as being an inspiration to him. Roshan James has some really cool Scheme posts.
Confluence
Over the last few days, there has been one thought running in my head - 'All roads lead to Lisp'. I've tried to get it out of my head but like a tune from the radio, it has firmly lodged itself into my head and refuses to let go. Why this state? Call it a confluence of several items. In particular, these 3.
- Joel Spolsky goes off and writes one of his best articles ever called 'The Perils of Java Schools' which talks about the perils of not learning Lisp. As someone who has been playing catch-up with functional programming since I wasn't taught Lisp at college, I definitely agree. I forwarded that article to some senior folks internally - which in turn lead to some interesting conversations
- I've been working on a prototype of something at work - where I started off the usual imperative programming style. Realizing that this wasn't going to scale, I rewrote it in functional style making full use of C#'s anonymous delegates and iterators. When I had to make a major change, it was *so much* easier to add in extra functionality since I was just passing closures around.
- After 2 hectic work-filled weeks, I took advantage of a long weekend to curl up with a book which has been called the best book on programming ever - Peter Norvig's Paradigms of Artificial Intelligence Progra"