Archives

Archives / 2004 / January
  • AI and Machines

    Wesner Moise has some interesting thoughts on AI and Machines. He thinks that computers are still some way of from reaching the computing capacity of the human brain.

    I looked at an AI book a few days ago that estimated that the neural capacity of the human brain (by multiplying the number of neurons by each speed of each individual one) was equivalent to a CPU speed of 10^17, which would require a few decades for computers to catch up to, if Moore's law maintains its current rate. Of course, computers can potentially be more efficient than humans at utilizing its processing speed, so they would never need to reach that level of power.

    Computers in there current form may not achieve this goal but computers are going to need to change in a very big way before the goal can be reached, CAM based memory (as it can be shrank down more and more) may be the answer to neron like organisation. However its not until all the questions reguarding the human brain have been answered that it can be simulated (for example questions reguarding how brainchemicals effect nerons etc). Indeed the neron is one part of the brain but it has many, many parts and many, many questions are yet to be answered.

    I agree with Wesner that it would great to see more API's for AI, I have seen a few for Neural Nets and GA's but nothing native (as a side thought it would be interesting to develop routines that sit within a host, for example a VM or the OS its self).  I also agree that GC is vital to AI function, however if we can understand how its done in bilogy then will a computer act in the same way and indeed will GC be required (for example GC may happen with memory its self, a key part of the OS or the hardwired into the mother board maybe). Memory requirements would be a huge requirement, with advances in disk technology we can start squeezing more and more onto disk. Maybe data storeage could be split (and indeed many key parts of the AI system) accross computers, why have 1 processor or hardisk when the internet gives you 100,000. There again if we can understand biology and how the brain stores information (and indeed how we manage to link and recall that data) then the device required could be very different to what we have right now.

    Read more...

  • Items of interest pt1

    Head down busy coding lately so a quick summary of whats new

    • Joel has some great short Rotor JIT notes, will be great to see what Rotor info Joel posts.
    • Another Rotor staffer Michal has some posts on Rotor code annotations, would be great to see the Rotor code base covered in this manner as some sort of resource (book maybe?).

    Read more...

  • Mono Develop, Nick Bradbury interview

    Ben has been hard at work on Mono Develop, nice to see this project developing.

    John also has link to an interview with Nick Bradbury. Nick is the creator of Homesite, TopStyle and FeedDemon (interesting debate within the comments). Scoble mentions Nick writes his apps in Delphi, would be interesting to know what Nick thinks of the .NET features in Delphi 9 and how hard/easy it would be to run his apps on Kylix?

    Read more...

  • Xen bridging relational, hierachical data and the CLR

    Micrososoft watch has an interesting article on a new Microsoft "programming language" codenamed Xen. Some confusion  in terms of implementation if this is a programming language, this site indicates its an extension to C# while this site states its

    I am currently working on language and type-system support for bridging the worlds of object-oriented (CLR), relational (SQL), and hierarchical (XML) data

    Its known that the X# work is going into the CLR so I suspect that Xen will be an extension of both the CLR and C#/VB.NET compilers (the CLR providing the services and IL op codes to make this work for other compilers). Would be nice to see the current state of thinking with this project, maybe on the Rotor code base?

    Dare has some notes on a presentation on Xen, this paper is also worth a read.

    Read more...

  • Sam Gentile interview

    Just in case you missed it, go and check out Sam sharing his thoughts on XP, COM Interop and the CLR. I enjoyed listening to his thoughts and any serious CLR coder should check it out. Of Sams thoughts on the CLR, I agree with "Its the runtime stupid" and the best single resource for learning the CLR is the code, Rotor. Some thoughts on Rotor and Mono, P.Net was not mentioned but like Mono its an open source CLR implementation.

    Read more...

  • New CLR Blogger, Rotor/SemiWorks and Mono

    Welcome new CLR/Rotor blogger Michal Cierniak. His introduction post contains a referance to SemiWorks, curious as to what that may be a google search came up with this mail. Its both interesting and great news that Microsoft are running a project to integrate research into Rotor, what would be really great would be to see what the research is, papers etc (just a thought but sscli.net would be a great place for this).

    On a related note Miguel has some news on Mono's First University Project with researchers working on the Regular Expression compiler, I am sure this work will be useful to Cesar.

    Read more...

  • Books for CLR coders pt2

    Cesar asks what books are great for learning the CLR? In an earlier post I listed some of my fave CLR books, of that list its really down to what approach a programmer wants to take with the CLR as to which they buy (although I recommend that every CLR wonk buys them all). In Cesars case he wants to understand the CLR in depth, for this I recommend Essential .NET Volume 1, Appiled Microsoft .NET Framework Programming and Common Language Infrastructure Annotated Standard.

    Read more...

  • Flex beta 2 is close

    Macromedia's Flex product reaches its next milestone soon with the release of beta 2, Christophe has some details including that this release will include 500 more testers and will include Flash Remoting . I am hoping to test on this release (but maybe it will be the next ?) so I don't know the answers to the following, maybe they have already been answered? I know Flex already has SOAP support however does it have support for other formats and can these be added? At the moment the product is for the JVM so can it support RMI, IIOP etc? When the product reaches the CLR will it support .NET Remoting or maybe Indigo? If these formats are not native here is hoping it has its own API for this kind of thing.

    Read more...

  • Creating a build system (NAnt,NUnit, Draco)

    On a recent project I was tasked with creating a build system to replace building .net soloutions manually. The system must make use of VSS and must allow for integration with NUnit, NAnt a FxCop. I am still in the middle of this but what I have ended up with is something simlar to Brian's soloution.

    • Port VS soloution files to NAnt, after trying several tools (including NAnts own Slingshot app) I finally settled on using Gordon Weakliems soloution (XSLT and NAnt). I had to hack the resulting build files to work with 1.0 of .NET Framework and to not make the build directories absolute. This works a treat but I will have more hacking to do so that these changes are worked into Gordons soloution and I can run it all automaticlly.
    • Setup NAnt, this is easy enough, download, unzip, add to the system path. Done.
    • Setup a Continuous integration system, Hippo.NET and CruiseControl.NET and Draco.NET all refused to work at first. The key seemed to be with permissions, running the Draco service on an account with a higher set of permissions solved the problem. However Hippo.NET and CruiseControl.NET had further issues that I did'nt have time to resolved.

    What is next is to tweak the system (some thinking out loud here :)

    • Script in the NUnit tests
    • Script in the FxCop tests, need to look at possible NAnt tasks for that

    CruiseControl has a great system of combining NAnt/NUnit info into its reporting, not sure how I can do this with Draco but there are reporting systems to plug into NAnt for that.

    Read more...

  • Mono as a research tool

    Miguel has interesting info on universities using Mono as research tool, he knows of a few examples of some universities choosing Mono as its JIT engine is more advanced than the one provided with Rotor. That said it has been said that Rotor may include the full JIT code (that is included in the commerical MS CLR) so things could balance out. Looks like Miguel has some hired hands to work on the JIT code, not ready yet but maybe next time ;-)

    I do agree that Mono needs more documentation, the more that is done the more it will be used for research and development. Its important that such documentation (and indeed research results where possible) is made available to everyone that is interested in researching Mono from private persons to universities.

    Read more...

  • 2001 explained

    Kubricks great film explained, been doing a lot of reading of late about space, time, quantum theory and superstrings so this is rather timely for me, the flash is of a great standard and makes great use of sound.

    Read more...

  • Rotor and Linux pt4

    Happy 2004 to you all, time to kick off the new year with some news on one of the things that will be keeping me busy this year, porting Rotor. I have been talking with folk like Robert and Eric on where to take the project and whats involved and so a roap map is forming. Largely it consists of moving the C++ files to support a format that the GCC compiler can use. Simple as it sounds Rotor has a lot of source code, and moving the code will be slow and careful process. Other than that there are some bigger issues, Rotor has a certain OS requirements, 2 of these are threading and signals. Signals are from the kernel and so are largely the same across all the distros. Threading however is provided as an additional libary and largely changes across distros. Rotor has a bigger requirement than the standard functions that pthreads provide and only certain distro threading implementations will support it (and indeed the way this provided changes yet again across distros), this equates to patching the Rotor port for each distro to get around this. One of the points I will fix for this is that the port will target a certain GCC version, a target distro will need to ensure that that version is met to run the code. Lastly I will port this code from scratch and not use the existing Linux ports, I want to start with a clean sheet.

    Read more...