Better smart-linking through class construction
Singletons, global services, and initialization. Most Delphi folks (myself included) don’t really think about the impact of these things on how much code is being linked into their application. How many of you have your own stable of utility functions scattered throughout some number of units? You rely on these things everyday and would tend to feel naked without them. Even when you bang out that little test or utility app, those units are the first thing that goes into your uses clause. Have you ever stopped to think what impact they may be having the size of your little app? Long time Turbo Pascal and Delphi programmers have always taken for granted the smart-linker and its ability to ensure that only the code that was "touched" is what is actually linked into your final application. However, there are a lot of things we unwittingly do that can undermine the linker’s "smartness." Try this little experiment; create a new console application, add all your favorite utility units to the uses clause and compile, making sure building with packages is off. Now look at the size of your resulting executable. OMG! It does nothing, yet it is > xxxxK! Let’s look at something we’re working on to help you (and us) out.
As was mentioned at Delphi Live! several weeks ago, we’re currently working on adding what we’re calling "Mouse/Touch Gesture support" to VCL. This will eventually evolve into full multi-touch as the OS services and hardware becomes available. Initially we’ve been building our own "gesturing engine" and adding it throughout the VCL. From the outset, we knew that baking this support into the core of VCL was going to be key to its acceptance. At the same time we also know that there are many of you that don’t need or want all that extra code slathered throughout core VCL. We also wanted to make sure this new gesturing support was "pluggable" at many levels. I’m not going to cover details about how this whole subsystem works, but simply want to use it as an example of something else we’re looking at adding to the Delphi language.
Traditionally, if you had some set of classes that required some kind of global initialization or a class that was a singleton, you would place this startup code into the unit initialization section. Unfortunately, this has the side effect of dragging into the resulting binary all code and data that is directly and indirectly touched by the initialization code. Simply "using" the unit will drag in the code. Sometimes that is what you want, but what if all you wanted to do was use some other class or call some disconnected utility function within that unit? You have to pay the size and startup performance costs associated with initializing classes and data that you never even use in your own code.
Over the years, there are some "tricks" we’ve all played to try to get around this. The most common is in the case of singletons, where we "hide" the singleton instance behind a global function that will initialize the instance when it is first called. The problem is that everyplace you use the singleton, you incur a function call. Other tricks include injecting into each public method of an object, code that calls a helper method that does the global initialization. This also has the side-effect of incurring this call for each method. The interesting thing is that the compiler already has mechanisms in place to figure whether or not you’re "touching" a given class or not. Why not just trigger on that and call an initialization method, if and only if that class is referenced someplace in code your. This really means whether or not the reference graph can trace all the way back to the main program block.
Enter class constructors. We’re talking native Delphi here. Delphi for .NET and Delphi Prism have had class constructors all along since that is a concept that is baked into the .NET Common Language Runtime (CLR). However, there has never been the equivalent concept in Delphi for Win32. We’re looking at fixing that. What if the following simple singleton pattern were possible?
unit SingletonUnit; interface type TSingleton = class private class var FSingle: TSingleton; class constructor Create; public procedure DoSomething; class property Instance: TSingleton read FSingle; end; implementation class constructor TSingleton.Create; begin FSingle := TSingleton.Create; end; procedure TSingleton.DoSomething; begin end; end.
Now you can simply access the singleton by TSingleton.Instance.DoSomething; Because of the class constructor, the compiler will ensure that it is called long before you actually call "DoSomething" on the Instance class property. The astute among you have probably already spotted the hole in the above case. There’s a memory leak now. How is the FSingle field destroyed? This is where the non-garbage-collected world of native Delphi has to do a little more work. The class destructor is how this will be handled.
private class var FSingle: TSingleton; class constructor Create; class destructor Destroy; public ... class destructor TSingleton.Destroy; begin FSingle.Free; end;
Now let’s look a little at how this all works. Class constructors (or type initializers) differ from instance constructors in that it is execute before any methods can be called or instances of the class constructed. The only rule is that it needs to run before anything else. How long before is largely irrelevant. Unlike class constructors in .NET, you cannot explicitly call them in Delphi Win32. For Delphi Win32, class constructors are called in a manner similar to unit initialization. The difference is that the compiler treats them as a "weak reference." The class constructor is only explicitly called if other code references the class. Class constructors are called prior to the unit initialization getting called for the unit in which the class with the class constructor resides. If one class constructor references another class with a class constructor in the same unit, the compiler attempts to order the constructor calls such that deepest reference is called first. Beware of cycles! If you have several classes with class constructors within the same unit and they all refer to one-another, the ordering may be indeterminate and you may end up with strange results or even crashes. So be careful before you decide to add them to that huge morass of spaghetti code you inherited from your predecessor. For class destructors, they are called in the exact reverse order of the class constructors and are called after a given unit’s finalization section is executed.
Back to the gesture engine. How does this all relate? When you drop a TGestureManager component onto a form, the designer/code manager adds an instance field of type TGesureManager to the designed form class. There is also a reference to the unit in which that component is declared added to the uses clause. The mere addition of the unit to the uses clause isn’t what causes the gesture engine to be initialized, it is the component reference on the form itself that does this. If you removed the component from the form and the reference is deleted and left the uses clause reference, all that would be linked in would be a stub initialization/finalization from the given unit.
I’m already seeing several places throughout the Delphi RTL and VCL that would benefit from this. What if you wanted to use function from SysUtils, but did not want to incur the extra weight of full exception support? We may add a class constructor to the base Exception class that hook up the proper functions in System. There are probably many more places in the RTL and VCL that could be refactored in this manner. Of course we need to be cognizant of the fact that going too far may introduce strange ordering differences and could make some things behave badly or radically different. While this isn’t some kind of magical "incredible shrinking machine," it is another tool that can be easily leveraged as we are adding and improving the VCL libraries. We will be able to add significant functionality without grossly impacting the minimum core set of code.
Share This | Email this page to a friend
Posted by Allen Bauer on May 29th, 2009 under CodeGear, ednfront | 13 Comments »Yes, Virginia, there is a Delphi MacOSX and Linux project…
I guess the proverbial cat is now out of the bag. As was shown in the Delphi/C++Builder roadmap at Delphi Live!, Project X has been under way for a while now. So now you know some of the reason why things have been rather quiet here since I could not really talk about what I’m working on. The good news is that we now have a returning top-shelf engineer working on the compiler. This person was heavily involved with the original Delphi on Linux project, so there is a lot of institutional knowledge that he’s able to bring to the table. Things are going to be done
Another noteworthy item is that the information in the roadmap was more about future technology rather than specific releases. In fact, for the first time in nearly as long as I can remember, we literally have several parallel efforts going on. Unlike the previous Delphi on Linux era where the teams were bounced back and forth between the Windows and Linux projects, we’re keeping a smaller, more focused team engaged on "future" work with minimal distractions. Of course the "next" product release will always engage the majority of the team, but having several "background threads" of development adds a truly exciting dynamic to the team.
So if you’re at all interested in some tidbits of information about the technology behind Project X and some interesting insight into a lot of the really low-level bit-twiddley aspects of the Delphi compiler and how it integrates with a new platform (and even an "old" platform like Linux) you really must check out Eli Boling’s new blog. In fact, he’s already starting posting some pretty gnarly stuff about some of the more goofy aspects of the Mac OS. Oh, and if you know the definitive answer to this question on Stack Overflow, please post it there.
So strap in, hang on, it’s going to be an interesting ride :-).
Share This | Email this page to a friend
Posted by Allen Bauer on May 20th, 2009 under CodeGear | 28 Comments »Delphi Live! Here I Come
As always, I’m just now completing the slides and demos for my Delphi Live! talk. That is about par for the course… So bright and early tomorrow morning, I’ll be driving past my normal exit and heading on over the Santa Cruz Mountains to downtown San Jose. Hopefully traffic will allow me to get there in plenty of time to get to the Opening Keynote on time. I’ve been following some of the Twitter traffic for the pre-conference sessions. So far it looks like the response has been very positive. Tomorrow evening is the "Bea^H^H^HMeet the Team" session and hope to meet many of the attendees. If you’re coming to Delphi Live!… see ya there!
Share This | Email this page to a friend
Posted by Allen Bauer on May 13th, 2009 under CodeGear | Comment now »Product Leadership Team, Research, Weaver, Delphi Live! - Oh my!
First of all I must apologize profusely for the dearth of posts here over the last few months. OK, "dearth" in this case would unfortunately, be an overstatement since the last thing I posted here was right after the Microsoft Professional Developers Conference. While I do have explanations for this silence, I don’t view them as excuses. Excuses are something that one does to deflect responsibility and blame off themselves. So I make no excuses and take full responsibility for the decided lack of posting I’ve done over the last few months. Certainly, some of the reasons for remaining silent here can be attributed to major distractions and that I could not talk about the stuff I’ve been working on. Other reasons are far less interesting and boil down to pure laziness and lack of motivation on my part. The good new is I now do have some stuff to talk about and the motivation to do has finally come back 
Let’s get started… again.
Product Leadership Team
Last fall, Embarcadero formed a special team that meets periodically to discuss all kinds of things about the products, their direction, markets, technology, etc… Another charter for this team is to identify technologies and market trends and to think of ways we can either leverage, drive and or otherwise participate in any of these emerging trends or markets. Or not. Deciding to not pursue a market or trend is just as valid of an outcome as deciding to do something. I’m able to be involved with this team that includes our CTO, James Pitts and our VP of Products, Michael Swindell, and at times Wayne Williams, the EMBT CEO. There are also a couple of other very senior engineers on this team with whom we can really do deep dives into technology and ideas.
Late last year, the PLT commissioned some research and even some preliminary development on some new product directions. Myself and a couple of other senior engineers have been off feverishly toiling away at this. It is this work I’ve been doing over the last few months that I’ve been unable to really talk about. There are two main reasons for remaining silent. First of all, as with any research project, it could be cancelled or shelved at any time. We don’t want to talk too much about something that, while exciting, may never come to fruition. Secondly, what I talk about early into the research may have zero or nearly zero bearing on the final outcome. The good news is that it is very likely that some sneak peaks will be coming at the Delphi Live! conference in San Jose, CA. So, if you haven’t signed up yet, now is the time.
Weaver
Hopefully by now you’ve heard about the next major RAD Studio release, code-named Weaver. You can even apply to field-test this new version here. If you want to see what coming in the next release and feel you have some valuable feedback, make your case and apply to participate by clicking on the above link (posting a comment here won’t work). Again, if you’re coming to Delphi Live! there is certain to be some information and demos with Weaver.
Delphi Live!
In case you haven’t guessed, a common theme throughout this post is to stress the importance of attending the first face-to-face Delphi and C++Builder centric conference and the first major conference with Delphi content in over 4 years since the last Borland Conference. I will be there doing a talk on a lot of the newer designer features that have been introduced over the last 4 or 5 Delphi releases. I’ll cover things like guidelines, property filters, and maybe even some new stuff coming in Weaver. I’ll also be helping out with the Product Address and any "What’s Cooking in the Labs?" discussions. There will also be a meet-the-team session where you can come meet nearly the entire RAD Studio development team and get your chance to corner one of us to discuss your favorite product feature or even the lack thereof :-). I’ll see you all there!
Share This | Email this page to a friend
Posted by Allen Bauer on May 1st, 2009 under CodeGear | 5 Comments »That which is old is new again
Last week at PDC, I was able to make it to the repeat session of Anders Hejlsberg’s talk on the future of C#. A talk by Anders is always interesting and enjoyable. He showed some really interesting things; but the most intriguing thing was the new "dynamic" keyword. Anders demonstrated several interesting uses for this "newfangled" gizmo, such as interoperating with JavaScript code. Hmm… I think I demonstrated something just like that over a year ago with Delphi. In that demonstration I showed how you could get JavaScript to access Delphi components dynamically. The reverse could just as easily have been done by using a Variant along with the very old (like Delphi 3 old) notion of dynamic variant dispatching. Any variant can be treated like an object in that you can simply start calling any old method or accessing any old property without even having a declaration for what that property is. For instance for many years you’ve been able to do this:
procedure TForm1.Button1Click(Sender: TObject);
var
Doc, Word: Variant;
begin
Word := CreateOleObject('Word.Application');
Doc := Word.Documents.Add();
Doc.Content.InsertAfter('This is some sample Text');
Word.ActiveWindow.Visible := True;
end;
Just add ComObj to your uses list and you can now paste that code into a button click, and you’re automating MS Word. The Delphi Variant type (or the more COM/OLE specific OleVariant) support this dynamically typed, dynamic invocation.
I had a chance to meet with Anders for a few moments out in the "Big Room" and I mentioned that the whole "dynamic" thing looked remarkably like the old Variant dispatching stuff. He chuckled and mentioned that the C# model allows for doing different kinds of dispatching and not just COM IDispatch… Hmm… I smiled and reminded him that Delphi does as well. I explained that since Delphi initially introduced the Variant dispatching in D3, we’ve added support for custom variant types. We now support all kinds kind of dynamic dispatching by creating your own custom variant type by descending from TInvokableVariantType over in the Variants unit. He paused a moment, chucked again, and explained that really none of these concepts are new, we’re just all learning how to reconcile the strongly-type world with the dynamically typed world of JavaScript, Python, and Ruby. Using the above notion of a TInvokeableVariantType, you could create a custom variant type that allows you to directly call and manipulate… oh… say… some RESTful service. It would be interesting to be able to do this:
procedure TForm1.Button1Click(Sender: TObject);
var
I: Integer;
Twitter, Timeline: Variant;
begin
Twitter := OpenXMLRESTConnection('http://twitter.com/statuses');
Timeline := Twitter.public_timeline();
//for I := VarArrayLowBound(Timeline.statuses, 0) to VarArrayHighBound(Timeline.statuses, 0) do
for I := 0 to Timeline.statuses.count - 1 do // This is far better and easier to use.
begin
Memo1.Lines.Add(Format('User: %s; Message: %s', [Timeline.statuses[I].user.name, Timeline.statuses[I].text]));
Memo1.Lines.Add('');
end;
end;
The above code is purely conjecture on my part, but I can certainly envision such an easy to use, dynamic mechanism to accessing RESTful services.
So, we’ve appeared to have, yet again, come full circle. That which was old is now new again. Hmm… maybe some of those old codgers back in the 70s, 80s, and 90s were on to something? I just hope we’re not merely repeating history, but rather building on it and recognizing that there are only a few new ideas under the sun… knowledge and ideas are not silos unto themselves, but rather built on top of that which has come before. So maybe you could go back even further? Even with the invention of the the first widely used "programable" devices (the programmable fabric loom head) by Jacquard, many of the concepts and ideas of modern computing today can be easily traced back to 1801 and the great pioneers and thinkers of the day.
You can read about the Twitter API here and see how the above code snippet could easily be mapped to it. To see the XML response just navigate here: http://twitter.com/statuses/public_timeline.xml.
Share This | Email this page to a friend
Posted by Allen Bauer on November 7th, 2008 under CodeGear | 4 Comments »PDC - In a few bullet points
Last week I was at PDC 2008 in Los Angeles. It really felt like a huge BorCon. The "geek quotient" was very high :-). There were several high-level themes that permeated the whole conference:
- Windows Azure - "The Cloud." Cloud computing with high-level tooling and initial support for managed code. Will eventually support native code. Meh :-/
- Parallel Computing - "No magic bullet" - As a reminder, Moore’s Law is about transistor density not clock speed, folks! Moore’s Law is still going strong, only now it is about cramming more cores into the same space. Until the heat/power problem is solved, clock speeds will continue to stall. Now the focus is on doing more things an once. The "free lunch" is over. With the new interest in parallelism and multi-core, classic imperative programming models don’t lend themselves to automatic parallelism. In other words, we’re a long way from that magic compiler switch called, "make my program parallel and faster." Thus there is a keen interest in data immutability and functional languages (F#, Haskell, ML, Caml, OCaml, etc..) and adding functional programming constructs to existing imperative languages (LINQ, PLINQ). The former is nice for greenfield projects or for portions of an application, but the latter is most likely going to the route taken by the mainstream languages. Consider that the forthcoming C++0x is introducing Lambda expressions, C# has LINQ & PLINQ, and even Delphi is moving in that direction with Prism and Delphi native (LINQ in Prism, anon methods in native).
- Windows 7 - Pay no attention to the Vista in the corner… Look at Windows 7! Admittedly, it does look nice. They’ve done a lot of homework and are working very hard to "fix" the usability issues with Vista. The Driver Model is remaining largely unchanged from Vista so all the investment in getting good Vista drivers up an going can be preserved. They seemed to hint that much of the perceived "instabilities" of Vista (aside from the usability issues) were due to the extensive reworking of a lot of the driver model, most notably the Video driver model and DX10. A lot of the hardware vendors were just not ready at launch with solid driver support. Apparently, it’s getting better and by the time Win7 is released, the hardware vendors will have ironed out those problems. When will it be released? The statements made were "3 years from the general availability of Vista" which puts it into the last half of 2010. I suspect the move back to a version number from years (98, 2000) or names (XP, Vista) is a way of "starting fresh" and shedding some of the negative baggage that is Vista.
- Multi-Touch - Windows 7 will support multi-touch out of the box. They also had a whole bunch of Surface PCs. It is interesting to note that the Surface PC is all vision based using a camera placed underneath the rear projected display, while all the Windows 7 APIs are based on the more traditional touch screen technologies (resistive, capacitive, etc…) WPF will eventually have some "unifying" APIs that will map those two APIs to a common WPF layer. This is not until .NET 4.0, which is apparently after Windows 7 since they keep talking about Windows 7 shipping with .NET 3.5 SP1. No word on native Surface APIs. Windows 7 touch support is all native at the lower level and even has some really nice intrinsic support for "manipulators" and "inertia."
Then there was the big Embarcadero/CodeGear announcement of Delphi Prism. Now that we’ve gone public with information about Prism and Embarcadero’s relationship with RemObjects, I can certainly talk about how I was able to spend time with some of the guys from RO. They’re booth was setup right next to the Embarcadero booth. I ended up staying the same hotel as the RO guys, so I spent a good amount of time getting to know them better. I met Carlo Kok, the Delphi Prism compiler engineer, for the first time. I certainly enjoyed hanging out with marc hoffman, Mike Oriss, and Carlo Kok. We will be spending a lot of time looking at ways we can not only leverage each other’s work, but also work together on advancing the Delphi Object Pascal language in ways that make sense for each market and platform.
Overall, there was a lot of really good information. I didn’t come away feeling like there was any kind of overall "buzz" around any particular topic. If I had to pick one "buzz-worthy" item, it would have to be the whole Azure thing and the "cloud."
One personally interesting item was that they gave out a little Freescale USB "badge" sensor board to demonstrate the both the unified sensor API coming in Windows 7, but also the new user level driver model. This little technology demonstrator has a ColdFire V1 microcontroller, which is a MC68000 derivative CPU, with lots of built-in I/O ports, timers, USB port, SCI, I2C, A/D converters and 128K flash Memory and 64K of ram. The board had a 3-axis accelerometer, ambient light sensor, 8 proximity touch switches, Lithium-Ion rechargeable coin cell and charger circuit. It came with all the drivers, on board firmware, trial versions of the C/C++ compiler for the CPU, and the Windows 7 driver code and some demo applications. They said it would only work with Windows 7. Hogwash, I say! It’s just a USB HID (Human Interface Device), and well, guess what? Within the extensive JEDI-VCL library is an HID component. There was also enough documentation to describe the 64-byte data packets that the board sends out with information about the accelerometer, light sensor and 8 proximity switches that I was able to write a little Delphi application to read and interpret the raw data stream. Sure, it’s using the raw data streams from the device without the nicely unified Sensor API from Windows 7. I played with it over the weekend and got it all working on my Windows XP Dell D820 laptop.
Share This | Email this page to a friend
Posted by Allen Bauer on November 3rd, 2008 under CodeGear | 1 Comment »At PDC
Just a quick little note that I’m at the PDC conference. I’ll be at the multicore/concurrent programming pre-con session. If that’s where you’ll be as well, be sure to say hi.
Share This | Email this page to a friend
Posted by Allen Bauer on October 26th, 2008 under CodeGear | 2 Comments »Value Capture vs. Variable Capture
Anonymous methods (aka. Closures) capture the variables from the outer scope that are referenced within the body of the method itself. This is the intended behavior as it serves to extend the lifetime of the variable to match that of the anonymous method itself. This should not be confused with capturing the value of a variable. In my previous posts, A Sink Programming and More A Sink Kronos Programming, I demonstrated a technique for asynchronously dispatching an anonymous method from a background thread into the main UI thread. I also mentioned how there was a potential race-condition on the SR local variable. The simple, yet not very scalable, way of eliminating this race was to pause the loop by calling EndInvoke() prior to accessing SR again (in the FindNext() call). This time, I’m going to show a technique for capturing the value of the SR.Name field and not the whole SR variable. This will eliminate the race on the SR variable because the anonymous method body will no longer need to access it.
Value capturing is a little more manual, but through the use of generic methods and a corresponding generic class, we only need to create this code once. The idea is to add an overloaded BeginInvoke() method that takes an extra parameter, which will be the value we want to capture and pass along to the anonymous method. Here’s the new BeginInvoke method:
TControlHelper = class helper for TControl
...
function BeginInvoke<T1>(const AProc: TProc<T1>; const Param: T1): IASyncResult; overload;
...
end;
This overload is different from the BeginInvoke<TResult> version since the AProc parameter takes a procedure reference instead of a function reference. As you can see, the procedure reference (can be an anonymous method), AProc, is defined as taking a single parameter of type T1. There is also an extra parameter which is where we’ll pass in the value we want to capture. Behind the scenes we’ll need to save off this value some place so when the procedure is called, that value can be passed along. For this, we’ll create another descendant of the TBaseAsyncResult class, only this time it is a generic class because we need to have a field of type T1:
TAsyncProcedureResult<T1> = class sealed (TBaseAsyncResult)
private
FAsyncProcedure: TProc<T1>;
FParam: T1;
protected
procedure AsyncDispatch; override;
constructor Create(const AAsyncProcedure: TProc<T1>; const Param: T1);
end;
As before, we override the AsyncDispatch abstract virtual method and add a constructor that takes the procedure reference and the value. The body of BeginInvoke<T1>() looks like this:
function TControlHelper.BeginInvoke<T1>(const AProc: TProc<T1>; const Param: T1): IASyncResult; begin Result := TAsyncProcedureResult<T1>.Create(AProc, Param).Invoke; end;
Now let’s change the background thread code to take advantage of this:
procedure TBeginInvokeTestForm.TSearchThread.Execute;
var
SR: TSearchRec;
SH: Integer;
AR: IAsyncResult;
begin
if not Terminated then
begin
AR := FForm.ListBox1.BeginInvoke<string>(TFunc<string>(function: string
begin
Result := FForm.Edit1.Text;
end));
FFolder := FForm.ListBox1.EndInvoke<string>(AR);
SH := FindFirst(IncludeTrailingPathDelimiter(FFolder) + '*.*', faAnyFile, SR);
while (SH = 0) and not Terminated do
begin
//Sleep(10); // this makes the background thread go a little slower.
AR := FForm.ListBox1.BeginInvoke<string>(TProc<string>(procedure (SRName: string)
begin
if not Terminated then
FForm.ListBox1.Items.Add(SRName);
end),
SR.Name); // Pass the value of SR.Name on through.
// FForm.ListBox1.EndInvoke(AR); { this call can be safely removed since SR isn't
touched inside the anonymous method body}
SH := FindNext(SR);
end;
end;
end;
Now the the loop in this thread will execute as quickly as it can to dispatch asynchronous calls to the main UI thread regardless of how fast they can be consumed. This same technique can be applied to the "TFunc" version by adding more BeginInvoke() overloads. It can also be extended to allow more than one extra parameter so you can capture and pass long many values. In the above case, it only specifically captured just the string that is the name of the file. It could have also captured the value of the whole SR structure.
What about exceptions? What if an exception were raised while the anonymous method were executing? It would still get caught and propagated back to the specific IAsyncResult instance but because EndInvoke() isn’t being called it is lost in the ether. It is also "bad form" to forgo the call to EndInvoke() as there may be some other internal cleanup that needs to happen. A simple way to deal with this is to store the IAsyncResult instances in a local TList<IAsyncResult> list. Then once the loop is done, iterate through the list, calling EndInvoke() on each one. This may still be less than ideal because you cannot cancel subsequent invocations of the anonymous method which may just stack up a whole plethora of exceptions. In this instance, aside from the exception problem, it is ok to defer or not call EndInvoke(). In other cases this may not be true, such as using this technique for overlapped IO.
Share This | Email this page to a friend
Posted by Allen Bauer on October 15th, 2008 under CodeGear | 1 Comment »CodeRage III - PDC - Delphi Programming
- Be sure to mark your calendar for the upcoming CodeRage virtual conference. Apparently the abstract submissions are coming in fast and furious, so if you would like to present, make sure you contact Anders Ohlsson.
- There are several folks in the Delphi community planning on taking advantage of the whole Open Space or UnSessions thing at PDC this year. Since I’ll be there this year, let me know if you’re planning an UnSession and what it’ll be about; I may show up. Also, if there is some kind of Delphi/C++Builder related UnSession you’d like to see, let me know too and it may happen.
- Delphi Programming - Just doing my part.
- I just realized that I have written nearly 450 posts in the 5 years I’ve been doing this whole blog thing. I hope I haven’t wasted too much of your time if you’ve been following along.
Share This | Email this page to a friend
Posted by Allen Bauer on October 10th, 2008 under CodeGear | 1 Comment »Some newsworthy items
- In case you’ve missed it, while at the SDN conference in the Netherlands, Nick Hodges has dropped some information about Delphi Prism, the next release of Delphi on the .NET platform hosted inside the Visual Studio Shell. Dr. Bob, Marco Cantu and Tim Anderson, have all commented on it. I guess this isn’t an "official" announcement as that will happen later this month at the Microsoft PDC.
- Speaking of the Microsoft PDC, I’ll be there. If you’re planning on going and would like to meet, let me know.
- We’ve been reworking our beta-test process using a new solution from Centercode.
- If you’d like to get in on the Delphi Prism fun and try out the new Centercode portal at the same time, you can apply to be a beta tester here.
- The Scotts Valley High School Falcons, SCCAL co-champions, beat reigning CCS champion, the Santa Cruz High School Cardinals under the Friday night lights in both teams’ league opener, October 3rd, 2008. Scotts Valley is now 1-0 in league play, 4-1 overall. Why does this matter? My son is a starting lineman for the Scotts Valley Falcons :-). Next Saturday, October 11th, Scotts Valley travels to Harbor High School to meet up with the Pirates on their home turf. Game at 2pm, PDT.
Share This | Email this page to a friend
Posted by Allen Bauer on October 6th, 2008 under CodeGear | 5 Comments »