Recital implements SQL-92 and most of the SQL-99 standard for SQL, but also provides lower level navigational data access for performing high transaction throughput. It is the choice of the application developer whether to use SQL, navigational data access, or a combination of both depending upon the type of application being developed.
Found a nice subversion plugin for finder on the MAC.
The goal of the SCPlugin project is to integrate Subversion into the Mac OS X Finder.
The goal of the SCPlugin project is to integrate Subversion into the Mac OS X Finder.
- Support for Subversion.
- Access to commonly used source control operations via contextual menu [screenshot]
- Dynamic icon badging for files under version control. Shows the status of your files visually. [ screenshot ]
Tagged under
In this article Barry Mavin, CEO and Chief Software Architect for Recital debunks the myths and misrepresentations surrounding XBase and explains how Recital, an enterprise-class XBase platform, has overcome all the shortfalls and weaknesses of early XBase implementations.
In an interesting article at Linux Magazine, Sam Ockman discusses the origin of the term "Open Source". Check it out here.
When the node is clicked set editable to false. Set editable to true in the double-click event handler.
// the click event handler
private function onclick_sourcetree(e:Event):void {
yourTree.editable = false;
}
// the doubleclick event handler
private function ondoubleclick_sourcetree(e:Event):void {
yourTree.editable = true;
yourTree.editedItemPosition = {columnIndex:0, rowIndex:sourceTree.selectedIndex};
}
Recital is a dynamic programming language particularly suited to the development of database applications. While Recital still supports standard procedural programming, new extensions to the language give you the power and flexibility of object-oriented programming. Object-oriented design and object-oriented programming represent a change in focus from standard procedural programming. This short primer will give you a good understanding of how to program object-oriented Recital.
Key features of the Recital scripting language include:
What are the key feature of the Recital database?
- High performance database application scripting language
- Modern object-oriented language features
- Easy to learn, easy to use
- Fast, just-in-time compiled
- Develop desktop or web applications
- Cross-platform support
- Extensive built-in functions
- Superb built-in SQL command integration
- Navigational data access for the most demanding applications
A number of people have complained about data loss after a system crash when using Ext4. A bug report was logged. According to multiple posts by a developer of Ext4, Theodore Tso, this is due to differences in approach to security and performance issues between the two file systems.
Ext3 commits writes to disk within approximately 5 seconds - Ext4 can take from 40-150 seconds. In addition, if a system is using Ext3 and crashes before the commit takes place you will still have the previous contents of a file where under Ext4 the file will be empty. Theodore Tso feels that this is a failure at the application level and that the file system is behaving as designed and as specified by the POSIX spec (which apparently does not specify what is supposed to happen when a system is not shut down cleanly). His solution to the issue is to suggest proper use of fsync() and lists various scenarios/examples in post 54 of the bug report (linked above). In addition he wrote a patch that recognize the rename() situation mentioned in his post 54 yet retains the normal Ext4 behaviors and performance in the majority of cases. Also a more "proper" solution has been provided which allows the behavior of Ext3 to be retained under Ext4 by mounting it with alloc_on_commit.
A somewhat related topic is the use of on-board caching by hard drives. This behavior can be modified on most drives by using hdparm.
Ext3 commits writes to disk within approximately 5 seconds - Ext4 can take from 40-150 seconds. In addition, if a system is using Ext3 and crashes before the commit takes place you will still have the previous contents of a file where under Ext4 the file will be empty. Theodore Tso feels that this is a failure at the application level and that the file system is behaving as designed and as specified by the POSIX spec (which apparently does not specify what is supposed to happen when a system is not shut down cleanly). His solution to the issue is to suggest proper use of fsync() and lists various scenarios/examples in post 54 of the bug report (linked above). In addition he wrote a patch that recognize the rename() situation mentioned in his post 54 yet retains the normal Ext4 behaviors and performance in the majority of cases. Also a more "proper" solution has been provided which allows the behavior of Ext3 to be retained under Ext4 by mounting it with alloc_on_commit.
A somewhat related topic is the use of on-board caching by hard drives. This behavior can be modified on most drives by using hdparm.
System Requirements:
- Minimum memory: 4MB
- Minimum Diskspace: ~20MB