Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

master

manual-ready.mdwn

[[!tag /projects/idan]] [[!tag /news]] [[!meta title=“Initial Idan Manual is Ready”]] [[!meta updated=“2015-03-24”]]

For a few weeks, I’ve been working on Idan’s [[/projects/idan/tutorial]] and [[/projects/idan/manual]]. Finally, the manual is more-or-less complete.

I like to remind myself the big picture, especially since there’s nothing else to do that for me (the project is in an early stage). So here it is.

I know, I know. I told these stories several times already. But who knows, maybe these memories floating in my head will interest someone. If you want just the current state of things, skip to the end.

Before the Wiki

A few years ago, I was working on tools for managing to-do lists, tasks and projects using the computer. I felt I needed tools smarter than a text file, and the existing tools I tried somehow lacked things I wanted. And they used very specific file formats incompatible with each other.

The initial plan was a GUI application called Sylva. I started writing it in C++ using the C++ binding of GTK+, called gtkmm. It was fun for a while and I felt I was making progress. I hacked the tree widget and drag-and-drop, resulting with a basic widget for the task and tag dependency hierarchies, and wrote some models and controllers for the underlying logic. The code should be somewhere in the [[!rel4sub git]] repositories. I hope.

The problem with Sylva was - if I remember correctly - that GUI apps take more time to develop, and need extra code for importing and exporting to other formats and applications. I also felt that while developing the GUI, I needed something else, simpler. This is how the idea of a language, a text-based format for describing tasks, was born. It wasn’t the first time, of course. Many programs already did that. But for some reason, I wanted to do it myself too. I don’t remember exactly, but I think the reason was that existing formats were too simple, and I wanted to somehow get all the advanced features and keep the format easy to use at the same time.

Later at some point, I realized there was nothing specific to tasks about my problems with them. The concept or hierarchies and directed graphs and dependencies and generic data models could be applied to everything. I discovered RDF and semantic desktop. The task description language then changed to a general purpose language.

Since I didn’t understand RDF well, and I didn’t have much background about information science or computer science or math or the popular technologies, the language was actually quite far away from useful and general-purpose. I moved to other projects and left the plans and designs and examples as-is, in a CherryTree document. It should be available in this wiki somewhere, probably through the FTP underlay.

In the Pseudo-Wiki

One day I opened a pseudo wiki. A folder hierarchy with text files. I began to work there on a semantic desktop system, and one of the things I wanted to have was a set of computer languages. Some low level, some high level. I didn’t have specific ideas, but I knew I’d need them eventually. So I made space under the Razom project.

Finally, with understanding of RDF and the Turtle format, I worked in parallel on the information model ([[/projects/Smaoin]]) and on a revised language. I understood all the problems I had with the first designs, and they were now going in a new direction. But the plans weren’t organized well. Just some notes and ideas and syntax forms to consider.

With Ikiwiki

When I started this wiki, I migrated those files here, and for some time I didn’t touch them much. The plans were waiting for me to finish other things and go back to the information language.

On the 13th of January, at least according to git log - a bit more than 2 months ago - the language project, [[/projects/Idan]], got its own new project page. I went over the old plans and started writing new ones. Since a language is a tool for people, I decided to start with the people’s side of it - the user’s tutorial. Through ideas and examples, I’d find problems and improve the syntax.

At this point I had much more math background and an understanding of how parsing works. So things were clearer and I was excited about the new high pace of the work, at least compared to my usual.

While writing a tutorial, I realized that had to make a choice in each section, between writing in a style friendly to new learners, and a style which provides a good general-purpose desciption. The second one was preferred for a tutorial, but wasn’t a good reference to be used as a basis for the grammar definition. I stopped working on it, and moved to writing the manual, which is a more technical definition.

Recent Work

Most of the work on the manual involved copying parts of the tutorial into it, reorganizing them and adding new syntax forms. Few days ago I finished going over the entire tutorial, which marked the end of the major part of the work on it. What followed was a series of small changes and additions, which still continue to come. Due to these tiny changes, the manual can’t yet be marked as stable and released for safe use.

But anyway, not much will change from now on. At least I believe so. The language is now stabilizing.

I also started working on some Idan documents, but this won’t be the new direction. The next step is to write a grammar definition, which is right now incomplete, and then work on the parser. Maybe also on the tutorial. Actually, there are some specific open issues waiting to be solved.

Being able to manipulate Idan documents programatically is far from enough. Applications need to be able to query the contents too, and insert new content in smart convenient ways. Even basic queries can be enough for now. With these two parts in place - querying and modification - it will become possible to write applications that share data and have a shared vocabulary. That, when I get there, will be the first more-or-less useful achievement of this whole project.

Applications can already use RDF of course, but in practice they don’t. They hardly share. Rel4tion will change that.

[[!meta author=“fr33domlover”]]

[See repo JSON]