We've been working on some very cool things here at ro, one of which is:

What's shown here is a Silverlight 2.0 beta2 object inside Internet Explorer that fetches data using a LINQ query to a DA server using RO using DA-SQL (more on that will follow in a blog posting from Marc) fetched and sent back to the server, all running asynchronously. The grid used is the excellent AgDataGrid from DevExpress.

New in the next DA/RO for .NET will be running requests asynchronously, this will make it possible to run a RO or DA request non-blocking and get a threaded callback once the data (or exception) is ready, this will even work with DA/LINQ. Another new feature is Silverlight support in RO and DA, and DA-SQL which will be covered in the following blog posts.

For those unfamiliar with MVC, MVC stands for Model View Controller. It's a way of separating the logic (controller), from the gui (view), and the data (model). The model contains all data needed by the view, the view shows it, and if an action occurs, passes the action to the controller, which does the logic, and updates the model again, so the view can be refreshed. The advantage of this is that, even though it ends up with more code, the code is a lot more readable, as the code needed for the gui isn't mixed up with the logic needed for validation and the data isn't in the view, but separated from the view, which just has a copy, it's also a lot easier to reuse code to write a new view (for example, a web interface and a windows forms interface on the same data) as it's not so tightly bound together.

Recently I've been looking at MVC frameworks for ASP.NET to improve code quality and ease of adding features. I have looked at both MonoRail and the MVC extensions for ASP.NET. And decided that even though it's beta, the official MVC extensions for ASP.NET is the way to go.

The ASP.NET MVC extensions come with templates for C# and VB, and although we are going to provide templates for it in Chrome, we can't do that till it's finalized; these extensions change quite a bit between releases. But the project is fairly simple, it's a Web Application Project, a standalone Class Library with a ProjectTypeGuid for ASP.NET, output directory for both profiles set to Bin/. Copying the web.config file, and using the same directory structure. The MVC logic uses a directory structure like:

• Content (Folder containing anything you want to provide directly to the user, like css and images)
  
  • Site.css (Default Css style for the project)
• Controllers (Folder containing the source code for the controllers)
  
  • HomeController.pas
• Model (Data classes for the project)
• View (directory containing all the views)
  
  • Home (view for the "Home" controller)
    
    • Index.aspx (asp.net page for the "Index" action)
    • Index.aspx.pas (code behind for the index action; descends from System.Web.Mvc.ViewPage)
    • About.aspx (asp.net page for the "About" action)
    • About.aspx.pas (code behind for the about action; descends from System.Web.Mvc.ViewPage)
  • Shared (view for the master page)
    
    • Site.Master (master page for the project)
    • Site.Master.Pas (code behind class for the master page, descends from System.Web.Mvc.ViewMasterPage)
• Default.aspx (dummy page to redir to the action page)
• Global.asax (application initialization)
• Global.asax.pas (application initialization; sets up the mapping from /Controller/Action to the actual controller and view

As a project to play with this new framework I decided to tackle the long-standing issue for a web interface for our bug databases (we use a combination of MantisBT and a custom application using Data Abstract). We already had a simple login-da service for these databases, so the only thing needed was the actual web interface for it. Writing something using MVC takes practice, but it's not hard; using a Remote Data Adapter to grab the data from the server; storing it in a List<ListingItem> to pass to the view for the issue index. Another model was used for the per-issue listing. The view was kept as simple as possible, to just show the data.

Combining the power of ASP.NET, MVC, Chrome and Data Abstract, writing a web interface for the bugdb was a simple task. The web gui still needs some finishing touches to make it look good, but the coding is done, so the new bug db gui should be available soon.

Recently we decided that, due to lack of updates on our current version control system and issues with it that didn't seem to ever get fixed, to move to Subversion. Subversion, as most will know is an open source version control system.

We had considered moving to subversion several times before, but never wanted to switch because of the hassle, the inability to move the history and lack of several features we really need in a client. Last year or so I had found .NET bindings for Subversion (part of the Anhk SVN VS.NET plugin), which I wrote a simple svn client based on top of. Besides that, I wrote a program that could enumerate the revision info from the old system into a database, and import them into SVN. A year later I sent Marc the code I had for the client and he finished it, into what now is Floss (see for more info on Floss.).

The moving wasn't easy. First of all, our old system used per-file revisions, but SVN did several files in a single revision, so what we had to do in the importer is find checkins that belong to eachother, in person, time and checkin comment and group them into a single group. Then change the SVN revision date and svn author so it had the proper date information, and then check the files in. The next step was to find where the old system branched it, and look through the labels for a hint at which version it was branched, as a branch wasn't named, we used a label on the non-branched revision that came after the branch with a "base label" for the new version. This way we could find out the branch was 1 version below the base label. After that we had to create tags for the most important labels into the tags directory.

Tricky as it was, after several test runs we managed to import the old repository into Subversion, so from today on, we'll be using Subversion only. It was an interesting experience to do all this, but nonetheless well worth it. We'll be working on Floss, expanding the things we need from a Subversion client, and we'll be all getting used to Subversion for the coming weeks but, we did it, we're ready for the future.

A conditional exception handler is an on e: ... do block in an exception handler that has a where condition. This allows you to only catch an exception when all your conditions apply to it. Although we've had this feature since the first version of Chrome, it's not a very well known.

/// <summary>Reads data from a socket. Returns 0 when the socket was disconnected or reset by peer </summary>
class method Utilities.ReadData(Sock: Socket; Data: array of Byte): Integer;
begin
  try
    Result := Sock.Receive(Data, 0, Data.Length, SocketFlags.None);
  except
    on e: SocketException where e.ErrorCode = 10054 do 
      Result := 0; // Reset by peer
  end;
end;

Above block reads data from a socket, but it catches the "Reset by peer" exception, and returns 0, like it's a regular disconnect.

Last week we've started looking into MonoDevelop integration for Chrome. MonoDevelop is an open source GTK based IDE for Linux. It has support for GTK# form design, C#, VB.NET and other languages and comes with a rich plugin model. MonoDevelop support for Chrome is planned for the V3 "Oxygene" release. with some help I've managed to get syntax highlighting, compiling and the compiler options working:

Yesterday I finished the article about XML-RPC in RemObject SDK (which can be found here).

XML-RPC is a Remote Procedure Call specification based on XML, similar to SOAP, but written to be as simple as possible, while still allowing for more complex data structures. As it is simple and easy to use, there are now many implementations for just about any programming language including C, Perl, PHP, Java, Javascript , Python, Delphi and .NET (the latter two are supported by the RemObjects SDK).

The cool new thing in V5 is a Service Builder code generation plug-in that creates .inc files to use from PHP. As XML-RPC doesn't have any metadata like WSDL has for a SOAP service, the declarations for using XML-RPC services have to be provided. To do this manually, the xmlrpcmsg for every call and the xmlrpcval for every parameter would need to be added by hand, making it much easier to make mistakes.

Check out the article for more info

When we started working on the Super HTTP Channel for Delphi, we soon realized that none of the TCP/IP socket wrappers we currently use were a good idea for the server part of the channel, as Indy, Synapse and BPDX all use one thread per connection - which would amount to 2 thread per client and wouldn't scale very well.

What we had to do is write our own socket wrapper that would work 100% async, like the .NET code does, and still would scale properly. Our new socket class uses Begin/End pairs for every method that would be blocking and accept a callback as a parameter for when the data was available, the connection accepted or the socket was ready to send data. The actual implementation uses the portable "select" call on 64 sockets at once, keeping the thread usage down quite a lot. On top of that we wrote our own simple Http server class, using only async callbacks.

We didn't tie the Super HTTP Channel to this socket implementation, however, instead we wrote an abstract implementation and a subclass that implements it based on the async IP code. So it's always possible to implement it on top of alternative HTTP server implementations.

We're considering the async socket and http layer to be the first step towards an "Internet Pack for Delphi" - although will be treating is a part of the RemObjects SDK, for now.

One of the new features of RemObjects SDK for Delphi and .NET in version 5 will be the Super HTTP Channel. This channel is a variation on the regular HTTP channel but supports two way traffic like the Super TCP Channel. Because it uses HTTP, it works through HTTP proxies and strict firewalls, it does however cause slightly more traffic than the TCP version.

The new HTTP Channel allows you to send multiple requests without having to use multiple HTTP channels. It also makes it possible to send an event from the server to the client without having to explicitly poll for it. It works by using two connections at once, one for sending, the other for receiving.

As side-effect of the implementation for .NET, we have introduced a new "normal" HTTP server component in Internet Pack: AsyncHTTPServer. The Async HTTP Server uses Windows built in IO Completion Ports to handle requests, which uses less threads than the traditional blocking sockets model. Besides the Internet Pack based server, we also have an ASP.NET "Handler" and an http.sys async implementation.

I spend some time with WPF this week and came up with a Quicksort demo for Chrome that uses WPF. The video can be found at:

http://remobjects.com/devcenter/videos/

And the sample itself can be downloaded too (It's at the end of the video). To run it yourself you need Chrome 1.5, the WPF runtime (.NET 3.0) and optionally the Orcas plugin for VS2005 (to open the XAML in VS2005).

I came across an interesting issue with Windows dll loading/unloading capabilities. The issue is that Windows does not return from an EndThread/ExitThread/TerminateThread when DllMain is running until it's done. This causes some interesting issues with the Delphi TThread class, which waits for the thread to be terminated to free it, so when a thread is freed from the finalization section of a unit in a dll, it will indefinitely wait. It's not possible to use FreeOnTerminate instead and keep it running. This would leave the thread running in address space that doesn't exist anymore.

There is no real workaround except changing the source code of TThread to stop waiting just before it reaches the ThreadProc's EndThread or writing your own TThread class. In writing a solution for use in the RemObjects SDK we had several problems. Obviously we couldn't change the Classes unit on every Delphi installation the ROSDK was installed. Another problem was that we support Delphi 6 and that doesn't expose a static Synchronize method, so the class had to descend from TThread. We had to do, what I consider one of the worst hacks but it looked like it was the only way. We reintroduced WaitFor, implemented it so it would return right before the thread was calling ExitThread, using a Windows event. After that we introduced a method to wait for it to finish and free it so it mimicked the existing behavior of the TThread destructor.

Seems like ModelMaker Tools is giving away free licenses. A great way to try Code Explorer with Chrome.

Due to the amount of spam we get these days on blogs we had to switch to a new blog engine: b2evolution So far so great.

A problem I met before I started working on Chrome was circular references. A circular reference in Pascal happens when both units use the other one in its interface section.




The above example wouldn't compile in regular Pascal and the classes would have to be put in a single file to make it work.

In Pascal, the files contain interface and implementation sections. In the interface you declare types, functions, constants that are accessible from outside the file and in the implementation section you declare the implementation of these classes and methods. Generally Pascal compilers are single pass, referring to processing the file once before creating the output. Chrome, However, uses multiple passes over the interface section.

When we talk about a multipass compiler, we generally think about a slow c++ compiler, but multipass doesn't have to be slow. Chrome doesn't use header files like c++ does, instead it uses fast readable .Net assemblies as libraries.

When compiling, Chrome first reads the interface sections of all files, then goes over them as needed to resolve all types. This gives us advantages over other Pascal implementations.

It makes it possible to spread a namespace over multiple files. Because types are resolved after they are read, there are no dependency errors between the different files. All files are compiled at once.

Also it's possible to put a single class in each file without having any circular reference problems between the files.

We just released the free command line compiler beta of RemObjects Chrome. Take a look at the announcement.

After some confusion on IRC on the differences between classes and valuetypes (D8: records)
a valuetype in C# is a lot like a class, except that it a few differences:

• It always decents from System.ValueType directly
• It's always sealed (no other structure can decend from it)
• Constructors, though possible are not called when you use them (speed reasons) unless explicitly called

The other difference, and also the most important one is the way it's stored. Structures are stored where you define them, which is different from classes because they are stored as a pointer and have to be created on the heap with the new operator. A reason to use structures instead of classes is usually speed, creating an array of structures is a single allocation for all items at once, when using classes, it's an allocation for the pointers, and for each item a seperate allocation for the class itself. One downside to valuetypes is that you can 't create subclasses and overriding methods is limited to the ones defined in System.ValueType and System.Object.

After last years Buffy finale came Angel this year. Though the season was kinda disapointing with a few deaths that really showed they were making an end to it, the last few eps were good. What I didn't like was the "Circle of the Black Thorn" which was rushed through in the last few episodes. I was very disapointed that no-one from the Buffy series showed up for the final last fight and that not everybody survives the open ending. With some luck there might be a movie in a few years.