shelle's c# shells
linux kernel vga= modes

Here’s how to get a list of available modes for your hardware, at least in Debian and likely others. It requires the hwinfo package.

hwinfo --framebuffer

hardware: VMware virtual machine
os: Debian “wheezy” as of 2012-04-21
kernel: Debian linux kernel 3.2.0-2 system

Hopefully this will save someone some time:

02: None 00.0: 11001 VESA Framebuffer
  [Created at bios.464]
  Hardware Class: framebuffer
  Model: "VMware virtual machine"
  Vendor: "VMware, Inc"
  Device: "VMware virtual machine"
  SubVendor: "V M ware, Inc. VBE support 2.0"
  Revision: "2.0"
  Memory Size: 32 MB
  Memory Range: 0xd0000000-0xd1ffffff (rw)
  Mode 0x0300: 640x400 (+640), 8 bits
  Mode 0x0301: 640x480 (+640), 8 bits
  Mode 0x0303: 800x600 (+800), 8 bits
  Mode 0x0305: 1024x768 (+1024), 8 bits
  Mode 0x0307: 1280x1024 (+1280), 8 bits
  Mode 0x030e: 320x200 (+640), 16 bits
  Mode 0x0311: 640x480 (+1280), 16 bits
  Mode 0x0314: 800x600 (+1600), 16 bits
  Mode 0x0317: 1024x768 (+2048), 16 bits
  Mode 0x031a: 1280x1024 (+2560), 16 bits
  Mode 0x0320: 320x200 (+320), 8 bits
  Mode 0x0321: 320x400 (+320), 8 bits
  Mode 0x0322: 640x400 (+640), 8 bits
  Mode 0x0323: 640x480 (+640), 8 bits
  Mode 0x0324: 800x600 (+800), 8 bits
  Mode 0x0325: 1024x768 (+1024), 8 bits
  Mode 0x0326: 1152x864 (+1152), 8 bits
  Mode 0x0327: 1280x960 (+1280), 8 bits
  Mode 0x0328: 1280x1024 (+1280), 8 bits
  Mode 0x0329: 1400x1050 (+1408), 8 bits
  Mode 0x032a: 1600x1200 (+1600), 8 bits
  Mode 0x032b: 1792x1344 (+1792), 8 bits
  Mode 0x032c: 1856x1392 (+1856), 8 bits
  Mode 0x032d: 1920x1440 (+1920), 8 bits
  Mode 0x032e: 320x200 (+640), 16 bits
  Mode 0x032f: 320x400 (+640), 16 bits
  Mode 0x0330: 640x400 (+1280), 16 bits
  Mode 0x0331: 640x480 (+1280), 16 bits
  Mode 0x0332: 800x600 (+1600), 16 bits
  Mode 0x0333: 1024x768 (+2048), 16 bits
  Mode 0x0334: 1152x864 (+2304), 16 bits
  Mode 0x0335: 1280x960 (+2560), 16 bits
  Mode 0x0336: 1280x1024 (+2560), 16 bits
  Mode 0x0337: 1400x1050 (+2816), 16 bits
  Mode 0x0338: 1600x1200 (+3200), 16 bits
  Mode 0x0339: 1792x1344 (+3584), 16 bits
  Mode 0x033a: 1856x1392 (+3712), 16 bits
  Mode 0x033b: 1920x1440 (+3840), 16 bits
  Mode 0x033c: 320x200 (+1280), 24 bits
  Mode 0x033d: 320x400 (+1280), 24 bits
  Mode 0x033e: 640x400 (+2560), 24 bits
  Mode 0x033f: 640x480 (+2560), 24 bits
  Mode 0x0340: 800x600 (+3200), 24 bits
  Mode 0x0341: 1024x768 (+4096), 24 bits
  Mode 0x0342: 1152x864 (+4608), 24 bits
  Mode 0x0343: 1280x960 (+5120), 24 bits
  Mode 0x0344: 1280x1024 (+5120), 24 bits
  Mode 0x0345: 1400x1050 (+5600), 24 bits
  Mode 0x0346: 1600x1200 (+6400), 24 bits
  Mode 0x0347: 1792x1344 (+7168), 24 bits
  Mode 0x0348: 1856x1392 (+7424), 24 bits
  Mode 0x0349: 1920x1440 (+7680), 24 bits
  Mode 0x034a: 1366x768 (+1376), 8 bits
  Mode 0x034b: 1366x768 (+2752), 16 bits
  Mode 0x034c: 1366x768 (+5472), 24 bits
  Mode 0x034d: 1680x1050 (+1696), 8 bits
  Mode 0x034e: 1680x1050 (+3360), 16 bits
  Mode 0x034f: 1680x1050 (+6720), 24 bits
  Mode 0x0350: 1920x1200 (+1920), 8 bits
  Mode 0x0351: 1920x1200 (+3840), 16 bits
  Mode 0x0352: 1920x1200 (+7680), 24 bits
  Mode 0x0353: 2048x1536 (+2048), 8 bits
  Mode 0x0354: 2048x1536 (+4096), 16 bits
  Mode 0x0355: 2048x1536 (+8192), 24 bits
  Mode 0x0356: 320x240 (+320), 8 bits
  Mode 0x0357: 320x240 (+640), 16 bits
  Mode 0x0358: 320x240 (+1280), 24 bits
  Mode 0x0359: 400x300 (+416), 8 bits
  Mode 0x035a: 400x300 (+800), 16 bits
  Mode 0x035b: 400x300 (+1600), 24 bits
  Mode 0x035c: 512x384 (+512), 8 bits
  Mode 0x035d: 512x384 (+1024), 16 bits
  Mode 0x035e: 512x384 (+2048), 24 bits
  Mode 0x035f: 854x480 (+864), 8 bits
  Mode 0x0360: 854x480 (+1728), 16 bits
  Mode 0x0361: 854x480 (+3424), 24 bits
  Mode 0x0362: 1280x720 (+1280), 8 bits
  Mode 0x0363: 1280x720 (+2560), 16 bits
  Mode 0x0364: 1280x720 (+5120), 24 bits
  Mode 0x0365: 1920x1080 (+1920), 8 bits
  Mode 0x0366: 1920x1080 (+3840), 16 bits
  Mode 0x0367: 1920x1080 (+7680), 24 bits
  Mode 0x0368: 1280x800 (+1280), 8 bits
  Mode 0x0369: 1280x800 (+2560), 16 bits
  Mode 0x036a: 1280x800 (+5120), 24 bits
  Mode 0x036b: 1440x900 (+1440), 8 bits
  Mode 0x036c: 1440x900 (+2880), 16 bits
  Mode 0x036d: 1440x900 (+5760), 24 bits
  Mode 0x036e: 720x480 (+736), 8 bits
  Mode 0x036f: 720x480 (+1440), 16 bits
  Mode 0x0370: 720x480 (+2880), 24 bits
  Mode 0x0371: 720x576 (+736), 8 bits
  Mode 0x0372: 720x576 (+1440), 16 bits
  Mode 0x0373: 720x576 (+2880), 24 bits
  Mode 0x0374: 800x480 (+800), 8 bits
  Mode 0x0375: 800x480 (+1600), 16 bits
  Mode 0x0376: 800x480 (+3200), 24 bits
  Mode 0x0377: 1280x768 (+1280), 8 bits
  Mode 0x0378: 1280x768 (+2560), 16 bits
  Mode 0x0379: 1280x768 (+5120), 24 bits
  Config Status: cfg=new, avail=yes, need=no, active=unknown

(Thanks to for the original info.)

my last free license

       shelley's copyheart un-license
   wheresoever be a waiver possible to do
    i release this product with my love
      to every one of you
       ♥ 2011, shelley butterfly
           my little requests
1. pass this on freely to those who need it
2. put this unlicense where others can see it
   when using this software or derivatives
   even if you claim copyright over the rest
3. leave this world a little better than you
   found it
4. remember to strive for happiness, to have
   fun, and to do your best to help others
   do the same
5. never 
   forget that 
   all it may 
   take to 
   is the 
   beat of 
   a butter-
                 i support
   see 'license/waiver.htm' for the Creative 
Commons CC0 declaration of waiver of copyright 

Update: Windows 8 Developer Preview ♡ :)

Okay, well, I’m sure everyone is as excited about this as I am. ;) 

I am installing using a 30-day evaluation of VMware Workstation ; I see some people have been getting an apic error on start, but I was able to get this at least installing on Workstation 8.0 by using “Other (64-bit)” instead of choosing one of the Windows variants as my guest OS. The stricken material actually did not work; but, apparently I was just unable to read: by choosing “Windows 7 x64" there was no further problem installing!

Here’s a shot of the settings I am using; I imagine you could even get this working in the player, although I have not tried.

Settings Page 1

Settings Page 2


Up and running!

So, there ya go, that’s all there was to it. :) I’ll try to update things as they go!

chelle ♡

Sorry I haven’t had time to do much with Tutorial C#; I will definitely be getting back to that as soon as I have an opportunity.  In the meantime, here’s my answer to a question on StackOverflow about getting data from one place to another (or many others) where I cover basic data source setup and usage and how to use a dispatcher that can help keep all but a small part of your model in the dark as to where data is going to or coming from. :)  ♡

Here I answer a question about cleaning up some code; along the way learning a lot about VB and trying to shine a bit of what I’ve learned about .NET via C# onto the VB scene.  

A Streamlined User Interface Development Process or “ideal interface? Ideal Interface? How About YOUDeal Interface?”

A Streamlined User Interface Development Process
"ideal interface? Ideal Interface? How About YOUDeal Interface?"

yet another TL;DR answer, with extra TL-y goodness!
(refactored from to only include generic process)

Well, I think the rule and best practice (IMO, not claiming any sort of official sanction to the statement.) can’t be defined any better than: take the solution which gets the final interface as close to the ideal (“ideal” being what would best satisfy the customer’s needs and wants [*not* necessarily equal to what they think they want, and anyway what they want will change over time!]) interface as is possible while comfortably working within our constraints.

So, the ideal interface can best be determined by eliciting the needs of the Customer, through a process similar to this:

 * try to get a good idea of what the customer will do with the product, and why (have them step you through how they would typically use it in the course of their day)

 * get the initial customer desires and wants, however detailed or vague

 * come up with mockups (good) or active prototypes (better) of one or more options that meet their needs as you’ve determined based on the information gathered from the customer

 * take the customer feedback (far better if generated interactively in the previous step) and incorporate that into a consolidated mockup/prototype.

 * once again get feedback, preferably interactively with the customer, to refine the idea

Repeat the refine/feedback process throughout your development; it’s best that you get to a point as quickly as possible to provide a functional working prototype, since customers actually working with the application will be far better at eliciting issues than mockups or semi-working active prototypes.

The process as described and elucidated here is a lot of text, but keep in mind that I am providing an abstract process, and once you narrow it down based on your actual needs, any particular implementation is likely simple. 


Interface development will tend to be constrained on two main axes:

 * Customer Access: How much access you going to have to the customer while working on the project. 

 * Project Constraints: Things affecting how much you can actually accomplish: some of the more important ones in this case are Time, Manpower, and Platform Constraints, each of which will limit how many different possibilities can be evaluated.

Customer Access

 * The amount of access you have will range from full access whenever you want, to no access at all.

 * In the process, there is a refine/feedback loop which requires access to the customer to provide feedback on changes that are made to the design from the very beginning through beta testing to finalize the UI.

 * Depending on the complexity of the application, your iteration time will vary, but the lower your iteration time, the closer you can approximate the ideal UI. 

 * The ideal process will require customer interaction at every iteration in order to determine the desired refinements in the next. 

 * This factor is, however, orthogonal to the rest of the development concerns, and lack of access is dealt with by simply using a proxy customer

     * For iterations in which you have full access to the customer, there is no need to proxy.

     * For iterations in which you have no access to the customer, you will need to choose a proxy to completely take over the role of customer.

     * For iterations in which you may have only partial access to the customer (e.g. if you are only able to send a set of mockups and get written responses) you will use a proxy as much as is necessary to determine the set of refinements for the next iteration.

 * I assume this is fairly obvious but: the closer the proxy customer is to being able to understand things like the real customer, the closer you will be able to come to the ideal. 

     * If you choose a proxy that doesn’t understand things like the customer and doesn’t use the interface like the customer would, then they will probably lead the design away from the idea instead of towards it.

     * In the case that you can not find an appropriate proxy customer for an iteration, you are far better off freezing the interface design for that iteration and either working on other known issues, or simply dedicating your efforts towards something else. Even if it seems that you aren’t making progress, you actually are making relative progress to the negative progress you would make by trying to update the design to match something further away from the ideal.

Project Constraints

So, now that we have come up with a way to ensure customer access throughout the development process; that leaves how to deal with the Project Constraints.

It is not likely that you will ever have enough resources and time to do everything you want, and it is also unlikely (more likely, but still unlikely) that you will have so few resources and so little time that you can only pray to your chosen Goddess, God, or other deity that you will be able to hack it all together in time.  But I think a good way to find a strategy for dealing with the Project Constraints is by looking at what the ‘natural’ strategy would be for the extremes.

**Case 1** - *aka:”Superman reversed time, do you think that would work?.”*

You may find yourself in this situation due to being very tight on one or more of the various Project Constraints, but as we’ll see, they can be viewed as very much the same issue when it comes to how to handle the development.

 * ***Looming Deadline***: Unfortunately, things are taking longer than planned, or your bid on the project was too low, or you lost resources, or you had a crash and lost weeks of work, or you were stalled by another project, and the amount of time you have left is, at best, barely sufficient to finish based on current (hopefully improved) estimates.

 * ***Hard Platform***: It turns out your ability to develop for the platform was overestimated, because the platform you are using is harder to develop for than expected, or the machine it is going to run on is much slower than you thought, or once you got to a certain level of complexity you touched the edge of a resource constraint, or found that the framework you were using started to turn into mush at the complexity level of your application.

 * ***Insufficient Resources***: Somehow, you were not allocated the number of people you needed, or you could only afford two developer licenses for four developers, or you had a small bus number and you had developers come down with mono (not to be confused with a developer having Mono which might actually be a good thing.)  For whatever reason you don’t have enough manpower or other resources to do what you need to do.

This is a good idea of the different possibilities, it isn’t comprehensive by any means, but the important thing to recognize isn’t their differences anyway, it’s what they all have in common. The differences may affect your mitigation of the problem, but at root they all are ***Schedule Issues***. In other words, all the problems that you can do something about at heart are going to involve mitigating the schedule issues; de-scoping the work to be done, speeding up the process, getting new people, etc. 

To be fair, there can be an special-case issue with ***Hard Platform***, which is that it may not be possible at all to implement a certain desired interface or other feature. However, the only possible mitigation in that case will be a de-scope, and there’s really no need to cover that here. The more likely case is that it just turns out to be a lot harder to implement a feature than expected, in which case we’re back to the main line; the schedule did not have enough time allocated for that feature.

**Case 2** - *aka:”Hey did we remember to divide our estimates by eight and costs by 100 before we got this schedule approved?”*

So, this case is not complex like the first. Yet. You have no significant constraints. You have far more time than you need, plenty of resources, and a platform that has no bugs and does everything almost without effort. And you have little green pigs flying around the office bringing everyone whatever they need throughout the 5 hour workday. (oink oink)

There are a few dangers here, but they all lead us back to **Case 1**. The dangers are:

 * ***Goldplating*** Without harsh deadlines, developers put their noses down and strive for perfection in everything they do. Every option is tried, every product evaluated, every algorithm timed, and the developers doing their best to respect the newly incremented and elevated “Eleventh Law of the Duke of Greenspun”—by implementing an ad hoc, unspecified, completely broken, megaslow, and appropriately helpful and worshipful version of at least three quarters of Common Lisp that was programmed to help create the “Nine Missing Laws” that weren’t…. Well, you get the picture.

 * ***Wrong Order*** Because there is so much time to do everything, few of the developers are going to want to do the hard things like: well, talk to the customer to get feedback on the interface mockups, or create the mockups in the first place, or revise anything once they do have the feedback. You know, really, do any design work on the interface at all. Instead they will pick the “cool” stuff.  Or the “quick” stuff. Or the “easy” stuff. Or, y’know, they’ll go to look up something on wikipedia and end up with a tree of subjects for which they will have needed to actual implementing a custom tree structure *in their own brain*. (Ha ha, only serious!) <br/>And all of a sudden there will come a time that everyone gets this sinking feeling in the pit of their stomach because, well, the only stuff left now is the hard stuff, and drudgery, and worst of all you’ll be trying to tack on the interface work at the very end, without time to properly iterate with the customer, or any reasonable proxy customer, because things just *have* to get done.  Well, my friend, welcome back to **Case 1**. 

Again, there are other issues, but they will all bring things back to where we started.  


So, we detailed the cases in order to determine the best strategy not just to enjoy a little bit of nervous laughter with each other as we recognized that we are all just sliding toward **Case 1**. (Seriously, maybe if we could a flux capacitor?)

So let’s look again at the steps and see what we’ll do and try to come up with a way that lets us customize them based on where we are on the scale between the extremes.

**Initial Phase** 

 * try to get a good idea of what the customer will do with the product, and why (have them step you through how they would typically use it in the course of the day)

 * get the initial customer desires and wants, however detailed or vague

 * come up with mockups (good) or active prototypes (better) of one or more options that meet their needs as you’ve determined based on the information gathered from the customer

*Case 2 Strategy*: So, the closer you are to **Case 2**, the more time you will have for this phase.  However, do not take this as a reason to spend more time than is warranted. At most you will want to schedule adequate time to come up with active (but at this point not necessarily working) prototypes of the bulk of the possibly desired interfaces. Ideally you will come up with at least two options for each different feature.  It’s not necessary to have everything integrated as a whole here, although it would be nice.  Just allocate a reasonable amount of time and get what you can in that timeframe. Also, by doing active prototypes here, you will be doing some early vetting to make sure you didn’t inadvertently end up with a case of **Hard Platform**, and if you did, it will be early enough int the process to adjust the schedule.  

*Case 1 Strategy*: Strategy The closer you are to **Case 1**, the less time you will have for this phase.  It’s important to be as efficient as possible here.  Instead of doing working prototypes, do simple slide mockups, or just draw them on paper, design them on a form designer, whatever it takes to do it quickly and with a minimum of fuss.  

Now, if you have only partial access to the actual customer, go ahead and get whatever feedback you can and have whatever interaction you can. Then with either customer or proxy customer (ideally more than one person) actually walk yourself through the mockups or active prototypes.  If you have mockups, print the slides out on paper so you can press buttons and use pencils to mark up your layout and make notes on what seems to work and what-not. Make sure you find out here, if you hadn’t decided already, whether you are going to need more than one level of interface.

**Iteration Phase**

It’s time to iterate again!  As you repeat this process you will come closer and closer to the ideal solution.  Whoa, Deja Vu.

(Fade In) If I had ever been here before on another time around the wheel I would probably know just how to deal. (We have all been here before. (repeat lots)) (Fade Out)

 * take the customer feedback (far better if generated interactively in the previous step) and incorporate that into a consolidated mockup/prototype.

 * once again get feedback, preferably interactively with the customer, to refine the idea

This is actually basically the same step as the previous one, except these iterations will likely be smaller and smaller as you approach the ideal solution. Everything is the same, except the goal is (this isn’t necessarily the number of iterations, there may be more than one for each stage, or there may be combined stages, depending on the scope of the project): (mockups/active prototypes)->(working prototype of app interface)->(working prototype of app)->(alpha)->(beta)->(party!).

And that’s it! You created an interface that is as close to the ideal interface as the constraints allowed. (As opposed to a “Star Trek” interface. Hey does anyone know what this unlabeled red blinking button does? Hmm, or is it an indicator. Oh, nevermind, someone was just playing aroundwith their phaser set to ‘cat’). 

Your customer is happy, you were successful, and you’ll be ready to take on the next job. Pat yourself on the back and have a beverage!


    [1]: <>

    [2]: <> “Do the Simplest Thing That Could Possibly Work”

definitely interesting

so i finally decided to go ahead and implement set at least temporarily just using a backing SortedSet.  this should work OK although i’m not sure if it’s permanent.

but, here’s one issue: i want to support both (a) doing things, say, from a REPL or script (b) directly coding up in C#.  for (a) we will need to support late binding on types whereas for (b) we want to be able to specify directly in code. these are distinctly different modes of operation and i’m afraid i am stuck getting clever with reflection to prevent having to implement everything twice, or to take the likely performance hit if i tried to implement things with, say, boxing. fortunately it was easy enough to find this blog post that shows how to create generics via reflection at runtime.

here’s another: OAOO (yeah, yeah, DRY) suggests that we don’t want each attribute to have to carry around its definition, or each tuple to carry its whole header.  so i’m trying to figure out a way to link all the ones in common to a common definition.  i think it’s as easy as linking together a DomainType (user type class) that will include base type(s), possible representation(s), and raw value into an attribute, then attributes into headings, and storing them in one place. that will be interesting as well to try to do efficiently; how do we store raw value? maybe derived types? object? not sure yet.

we want to also be able to codegen for case (b) above to get the equivalent of a typed DataSet.  i’m actually toying with the idea of implementing things with backing DataSet/DataTable/DataRow temporarily to get the interfaces down and to write tests (for instance DataSet supports constraints etc.).

also i’m trying to figure out how the operations are going to work; somehow we need something flexible enough to allow for both syntactic and semantic optimizations, taking into account constraints and order of operation and the like, of course without ever assuming the backing store implementation.  also it would ideally to be able to allow something to figure out a good physical representation based on the backing store, base structure, etc. 

so all in all it’s pretty good brainfood; hopefully can get back to it this evening. :)

all my love


oh, as a bonus i used some of the code contract functionality to assure that when we have one of our Sets (that’s using the backing set) and someone calls an operation that takes another set, that it actually is a set or derived class.  will show that code here if anyone is interested; oh and i guess i’m going to go ahead and push this over to sourceforge if you want to see the lame hardly started code in all it’s (non-)glory.


by the way, if anyone has any ideas for a better .CSS for doing a code blog on tumblr, please let me know what they are!

the spike

okay, well, this is a large enough project i think we need to consider an initial spike that may or may not be kept around, but should be our first foray into what tutorial c# is going to look like. the goal here is to come up with some foundational items that will allow us to start building some useful functionality without worrying too much about whether it’s the “right” way.

so, here’s my basic design concept:

instead of using strings with D-style definitions in them for our relations, i am going to try to come up with a way of defining things in code.  example of the D-style syntax: (adapted with some added verbosity from “Database in Depth” by C. J. Date)… also, let’s try to get away from the CAPS! :D



(we’ll need to have some primitive types but i would prefer to build them up as much as possible rather than have a plethora of primitives)

i used “STRING” here instead of “CHAR” although i may change my mind later

it’s worth mentioning here the concept of a specially defined type of SUPPLIERID (or whatever the ID of the table is going to be). this is due to the fact that a supplier ID, whether GUID, integer, string, or what-have-you, is NOT the same kind of thing as, say, a part ID, or a customer ID.  now, you might have some concept of a customer that is also a supplier, however this can be handled without conflating different type IDs, for instance, by having a master table of entities, each with their own ID, and then relating those things to their customer ID and supplier ID.  this is the standard Date example, i am mostly just intending it as an illustration

anyway so, we’ll need a way of having user-defined or otherwise implicitly defined types to provide type-safety of IDs and the like.  

spike classes, initial concept

// the whole (logical) database
public class Database;

// the “table” concept
public class Relation;

// generally pronounced like “couple” but “toople” if you must :D
// “row”
public class Tuple;

// domain definitions
public class UserType;

// the definition of attributes in a tuple or relation (“columns”)
public class Heading;

// the set of Tuples within a Relation
public class Body; 

now, i’m not exactly sure how these are going to flesh out at this point, i’m going to spend a bit of time writing code to try to get a feel for what i want.  we’ll need to keep in mind the ability to do LINQ on them, as well as deal with standard relational calculus/algebra operators.  i feel like somewhere we’re going to need some generic types but i’m not sure if it will be at this level of abstraction.

i’m going to try to keep these things in mind while i flesh things out: the need to be able to be abstracted away from the actual storage mechanisms, how everything will be queryable/etc., how suitable things will be for interoperating with the standard LINQ stuff, how easy it is to define the tables without resorting to strings, and really pretty much everything i’ve mentioned so far.

once i have more of an idea, i will post some sample code, and depending on how well it went i may either push the code into the hg project on SourceForge, or i may just throw it all away.

oh, and despite my objections to the string-based initializations, i will still likely use that to bootstrap, and also because it will be functionality we want to allow for the easy serialization/deserialization of databases, either for backup/revision control, or for people who want to use external tools to create their databases.  (the reason i want to avoid dependence on this is to enable the use of tutorial C# as a natural backing store for more than just external databases!) 

wish me luck! 

a few more thoughts
  • ideally we would like to support some sort of relation inheritance; it is glossed over in the available “D” language descriptions, but mentioned as an extension of the functionality provided in TTM
  • the DataSet/DataTable/DataRow classes are in many ways very conducive to doing relational setups, although there are performance issues especially with large datasets.  however, i think we would like to capture the flavor of these objects as they are very powerful and allow constraints, keying, etc. with a minimum of effort.  
  • in addition, the typed DataSet generator is an extremely useful tool and may be something that could address the static typing i mentioned in the first post
  • this is a huge undertaking and i’m not even sure where it’s going at this point, so i think i am going to take the tack of finding at least two clients of the code.  first, of course, is the xUnit.NET test code, for which i intend to try to follow the guidance from the xUnit Patterns website.  in addition i think it will be useful to consider, at first, and eventually implement, a consumer of these classes.
  • oh, one complaint i remember about Dataphor (BTW, Dataphor/D is more than just the database it’s also a programming language, did i mention that?  nevermind that now… :D) is that we were forced to go through a lot of pain if we wanted to make changes to an existing database.  it’s very important that we minimize this kind of pain, which is one thing that would be a big discouragement from using it as an everyday datastore