progress on Phonebook1

Yesterday we "got out". Went shopping for houseplants, actually. Came back with 8 attractive houseplants, several about 3' high. Cost: RS400, including roundtrip cab fare. (Under $10.00)

I also managed some good progress on the Phonebook example. Got the code roughed out, anyway.

Global temperature will rise by 20F

Again from today's "The Times of India":

London: Greenhouse gas emissions could cause global temperatures to rise by up to 11 degrees Celsius, according to first results from the world's largest climate modelling experiment. Reuters

Relations1 example converted now based on DataSets

Once I wrote the mks (make sibling) operation on the WellKnown capability, everything just fell into place. The Relations1 example has now been upgraded.

Next: Phonebook1. And should phone numbers be well known? should they be in the same data set? Perhaps we should have a heirarchy of datasets?

3rd eye grown from pinal gland

In today's "The Times of India": Rajasthan scientest produce 3-eyed frog.

Apparently the pinal gland tissue was transplanted from another tadpole and vitamin-A was added to the growth medium. The resulting 3rd eye was "normal in every respect".

High today of 28.2C (83F), and its still January!

Python 2.3.5 vs 2.4--twisted issues

I'll note that Twisted Matrix is not yet providing windows downloads for Python 2.4, and I'll confess that I am not currently subscribe to the twisted mail lists. So I hesitate to move to Python 2.4.

I also see that Python has a 2.3.5 candidate release and should have a final 2.3.5 release soon. This being a bug-fix-only release, my inclination then is to move CompStrm development to Python 2.3.5 rather than 2.4 for now.

progress on moving relations1 to datasets

I've renamed the findWellKnown command to fi, making it consistent with the cri command. Another useful command, mki, creates an item in the dataset if there is not already an item by the same name. Note that these are all commands on the DataSet capability.

Now the problem I face is that I am at a data item (i.e. a well known file) and I need to create another (sibling) file. I want to infer both the directory and the dataset from the current dataitem, and create another such item by a new name if there is no item by that name in the same dataset. So now I need more smarts on the WellKnown capability.

So conversion of the Relations1 example is going slowly. But hopefully this process will yield a number of usefull TKI commands.

I took today (Thursday) off from programming (except for this and the previous post) and will likely also take off Friday. Then back to it this weekend.

security and integrity issues for .dmp files

There is a lot that needs to be done before we can safely share .dmp files.

First, any attempt to change a parent directory or file name is both unsupported AND a security violation. Similarly, adding a parent directory or file name when a file already has one is unsupported, a security violation AND a type violation. (These are simple properties, not sets.)

As previously covered, deleting a parent directory or file name should result in the file being deleted--including any local values and references not included in the .dmp file!

But we also should apply type checking. And in so doing, we can exclude consequental changes from .dmp files while inferring them when doing a load/restore.

The short of it is that we need to move .dmp file processing from the TKS level up to the TKCS level. This is a major effort, but needs to be done before we do too much file sharing.

findWellKnown

Bangalore, I have been told many times, has a very nice climate. And folks here are supprised when I say that I need an AC for our appartment. But winter here must be about over--high for today is 30.8C (87F) with a relative humidity of 45%.

Now I've finally written the script I've been needing to proceed on Relations1: findWellKnown. This script is attached to the DataSet capability. It takes one argument: a well known name. It returns match, which is set to the path of a WellKnown file with that name and which is in the current DataSet. (It ignores duplicates.)

Low-level integration of types from diverse sources

Another holiday here (Wednesday) in India. Perhaps I can finally make some progress on the Relations1 example.

It seems such a long slow path sometimes. My "immediate" goal is implementing containers (DataSets) for managing diverse types of WellKnown items via a web interface, i.e. a Wiki that supports more than just Wiki Pages.

What takes time, of course, are changes--even small changes--in direction. I had been contemplating something like DataSets for some time, but my initial implementation was application data dump files. I feel strongly that an application (a use) should be able to draw on types from any number of implementations (applications).

Of course, the real key here is abstracting out the data management capabilities (DataSet and WellKnown) from various applications/implementations. This is what will allow the intermixing of diverse types from different software sources at a moderately low-level of granularity. And this is what keeps me plugging.

hasValue command

Got the tki command, hasValue, working:

Execute the first argument if the file/property/value tuple is present.

Four required arguments: command, file, property, value.
If the value is a pathname, it must begin with '@'.

Alternately, when the file is a dictionary, a key can be given in placeof the property. (In this case, the '@' is ignored if present--the valueis always a pathname.)

Creates, house cleaning, hasValue command

Didn't do too much on CompStrm today (Sunday). But I did manage to add two nice commands:

crwk on a WellKnownDirectory creates a file in the directory and assigns both a unique file name and a user-assigned well known name.

cri on a DataSet creates an item (a well known file) using crwk and then adds that file to the data set.

We reorganized the hall today (think living/dining area). I got to arrange my books. And we did the weekly shopping. Now the dining table (such as it is) is close to the phone outlet, making it easier to go online.

I've realized that I still need a bit more capability before I can convert the Relations1 and Phonebook1 examples. I need to be able to test for the presense of a file/property/value tupil. Got this in the TKCS API (hasValue), I just need the equivalent in TKI script. Of course, the hard part is figuring out exactly what you need...

A directory of directories of WellKnown files

A bit of reorganizing today.

Data is the root dataset. It is in directory /WellKnownDirectories/DataSets.

This allows for the creation of a new descriptor for directories (like DataSets and ToDo1), and consequently the attachment of new capabilities. And I've done so.

WellKnown files have mostly randomly generated names. So doing a dir command in a directory of wellknown files is not helpful. A new command, sh, then is helpful for listing the well known names in the selection list. Another command, sh on a dataset, works similarly, listing the well known names of the dataset items in the selection list.

The new xset command is working, and I've updated the ToDo1 web page. But I still need to work on Relations1 and Phonebook1. Perhaps tomorrow.

online!

Our phone is now fully functional. ;-)
That includes international calls and internet access.
(Yes, I'm using it now.)
Feels like old home week.

Just noticed--AirTel offers a DSL connection with fixed IP addresses and 512kbps for RS2495 (about US$60/month). A bit expensive for my current needs, but it is nice to know its there.

a home phone number

After two weeks (an unusual delay), we finally have a home telephone, though we have not yet added international calling. (Likely we can receive international calls.)

The number is 80-5123-7829.
(When calling from the US, dial 011-91 first: 011 for international calls and 91 for India.)

the xset proposal

I confirmed this morning that it would be trivial to create a variation of setvar (the set command) which uses the symbol table of the parent TKI rather than the current TKI. This would be a new command, xset.

The xset command would allow a script to change variables in the envoking TKI. And I think that's just what I need when reworking the examples to use datasets.

todo vs relations examples

Converting the ToDo1 example was trivial. I just made stuff a WellKnown item in the Data DataSet.

Then I started diving into Relations1 and, Oh Boy! This is a fun one! The problem is that I need to test for the presense of a WellKnown for a given name within a DataSet. This is an intersection search and I haven't done one before.

Generalizing the search, for file A, look at the list of values it has for property X. Which files in that list have a property Y with a value of B?

Now, do I implement a high-speed version of this search? It is only one of many possible searches. Alternatively, I can make TKI powerfull enough to be able to implement the search as a script.

For now I'm thinking it makes more sense to extend TKI. Its easier and gives greater flexibility. Go for speed only when you need it, as it often brings added complexity.

having fun in the mornings with CompStrm

I've started a new habit--get up early and work on CompStrm before breakfast. It is a quiet time, and it seems to work for me.

I've now defined the WellKnown and DataSet capabilities, the WellKnownName and DataSetItem properties, as described in eariler blogs.

I've also defined the DATASET descriptor on the /DataSets directory. Its capabilities are Base, File, Managable, Lead, WellKnown and DataSet. I've also created the /DataSets/Data file, to serve as the root of the tree of DataSets.

I see the Data file as the container of all data, exclusive of type (descriptor) data. It will hold various datasets, each being a container for one or more types of data.

The next thing, of course, is to convert the examples so that they put their data in a dataset and to use WellKnownName in place of a file name. (Using a UUID in place of a file name.)

Part of the intent of all this is to promote sharing. Another part of the intent is to make it easier to put a web interface on everything. But one very important aspect is being able to put more than one data type in the same dataset.

Of course, making all this usable should be interesting.

starting work on CompStrm again

We just had a 3-day weekend here in India and I took advantage of it to start working on CompStrm again. But please do not expect the same pace of development as before--I've got a full-time job now. ;-) Now that I've started again, I hope to do a little each day.

This weekend I dropped all references to realm and role, as well as creating a data migration path. But I figure there is no rush to release, as I have not yet added any new capabilities. Also I still lack a phone connection, so there is no way for me to connect my machine to the internet.

our furnature has arrived

We moved into our new appartment a few days ago and yesterday our furnature and things arrived. Needless to say, everything is upside down right now. And it is all very dusty.

So far I haven't done much at Sun except a little reading. Buy with my personal life coming together (we still need a gas hookup before we can do any cooking!), I am very much looking forward to doing a lot more reading and playing with Sun technologies.

CompStrm, regretfully, is still on the back burner.