Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Antsan]

Some time ago I had this idea of an editor where one can write up a Specification in the form of a MindMap, then add nodes onto the nodes containing the specification, containing the code corresponding to that part of the specification and finally (*cough* yes, like that ever would happen) add documentation in the same manner.
I started planning and went on planning and started several attempts at getting my plans into actual running code and well, now is the time that I've got the first quick version of the basic structure in Common Lisp (developed on SBCL in SLIME).
http://code.google.com/p/mindmade/source/browse/
This is, where you can find the source tree.
I am posting this to get some constructive criticism, on the basic idea and of course on my source code so far. Suggestions and questions are very much welcome. You can comment my source code directly on the site linked above, if I sat up everything all right.

Here is a short explanation of what's in the sources right now:

Spoiler (click to show/hide)

Any folder contains exactly 2 files: One for a chunk of functionality (ending in .lisp) and one as a system definition for asdf (ending in .asd).
"edges" and "node" contain class definitions for, well, edges and nodes.
Edges should have a type and a weight and of course they are an edge between two nodes - the source and the target. Edges can be bi-directional or uni-directional. Type and weight are there for later processing a mindmap made with MindMaDE into something usable (such as actual source code organized in a source tree or the current documentation).
Nodes have a name (used as an unique address in a certain context) and a node-type, which should be used for later processing.

"session" unfortunately contains a lot of code that I don't know how to organize elsewise.
Basically any modification of the structure of documents, nodes and fields (the places, where the actual data sit) is done here.
The basic idea is, that all documents, nodes and fields sit in a hierarchical structure, accessible by addresses, which are just lists of names. A list of one name designates a document, two names designate a node and three names designate a field, where the front parts of an address refer to the document/node that is the parent of the node/field designated by that address. (foo bar baz) as an address designates the field baz in the node bar in document foo.
Also one can define document types, which are a collection of node types that are usable in a document of that type. Node types are collections of field types to whom actual lisp type designators should be assigned to determine, what kind of data can be stored in a field with the same field type in a node with the corresponding node type in a document with the corresponding document type.

The organization of the two hierarchies (the type tree and the document tree) is done in the so called symbol-array, which is defined in the folder "symbol-array". The name is not really correct, as this type of symbol array does not have a fixed dimension and does not really address by symbols but by objects that are eq.

[Virex]

I don't know how much help it'd be to you at this point, because you seem to be rather far in development already, but in On Lisp, the author describes a way to make a hash table out of closures, which skips over the whole step of separately defining edges and nodes. An edge reduces to a function call (although in your case this may not be applicable because of the need of weighted edges). On the other hand, switching from classes to closures may enable you to shift the behavior of nodes and edges to their respective files, which would clean up the sessions code.
Also, is there any reason the .asd files differ in name from the .lisp files?


Some other criticism:
I haven't looked deeply into the function's guts, but in output-doc-defs you're setf-ing the node-defs to a list that is something appended to node-defs. To me it feels like it'd be better to use collect there (in case that results in the wrong order you can always nreverse the list)
find-keyword's name feels misleading, because if you don't find the keyword you make a new one. Ensure-keyword would be a better name.

[Antsan]

I don't know how much help it'd be to you at this point, because you seem to be rather far in development already, but in On Lisp, the author describes a way to make a hash table out of closures, which skips over the whole step of separately defining edges and nodes. An edge reduces to a function call (although in your case this may not be applicable because of the need of weighted edges). On the other hand, switching from classes to closures may enable you to shift the behavior of nodes and edges to their respective files, which would clean up the sessions code.

Thanks, I'll take a look at it. Cleaning up sessions code would be great.

Also, is there any reason the .asd files differ in name from the .lisp files?

I wanna keep the file names short, so I don't name my lisp-files with the mindmade prefix (well, it's still mindnet currently, but that's gonna be changed soon) while ASDF requires the asd-files to be named the same as the system they define. I cannot just name those systems "edge" and "node", because that doesn't feel right.

I haven't looked deeply into the function's guts, but in output-doc-defs you're setf-ing the node-defs to a list that is something appended to node-defs. To me it feels like it'd be better to use collect there (in case that results in the wrong order you can always nreverse the list)

collect won't work as I need to add 2 elements to the list in any step, but append (as a loop keyword) will. I just didn't know it existed before.

find-keyword's name feels misleading, because if you don't find the keyword you make a new one. Ensure-keyword would be a better name.

That makes a lot of sense.

Thank you very much!

[Virex]

You're right, they're .ASD files. I thought they were .FASL files, hence my confusion. Which brings me to another question: You're defining a separate system for each component, but to me it seems like the whole of mindmade should be one single system incorporating each of those files, unless there is a specific reason to use separate systems?

[Antsan]

No real reason there, just my inability in using ASDF properly. I guess I will have to get this right before continuing.
symbol-array is an exception, though, as it is not only useful in mindmade.

[Antsan]

It's been a little bit of time and since the last post I rewrote the whole thing to be a bit more... well defined. Nodes, edges and documents are now neatly separated and I removed the dependency on symbol-array - it was a bad idea in the first place to restrict documents, nodes and fields all to be in the same structure. Different documents can share nodes and edge-sets (see below) now, although I don't really think that the latter is really useful.
Edges are now represented in edge-sets. Edge-sets have an edge-type that determines whether all edges are bi- or unidirectional and is used in converting maps into whatever you want to convert them to. Edge-sets contain a set (a data structure provided by fset) of all edges of a certain type in a document. Unidirectional edges are represented by a cons of the source node and the target node, bidirectional edges are represented by a set containing the two nodes connected by the edge.
The structural part of the editor is done now - documents, nodes and edges are defined.
Functions for adding nodes and edges to a document in a controlled manner i still missing.
Documentation strings are missing.
There is no UI available (of course you can use everything by hand in a Common Lisp REPL).
I am currently working on the functions and classes for writing scripts that convert maps. Currently converting a single node is possible.

I would be very happy about comments and of course any other form of contribution.

[Virex]

I haven't found any glaring problems in the code at a first glance. Is there anything specific you'd like help with?

[Antsan]

I'm a bit tired right now, so not everything I write might make all that much sense.

I could use very much help getting all those documentation strings done. Most likely it would be even worse for someone else, but going through the undocumented functions and asking for important details would be very much appreciated. I guess that would have to be done elsewhere and at another time. If you think you could find time for that write a PM.

Furthermore I would like to know on which Common Lisp environments this runs and on which platforms. I am programming on Linux and SBCL. It would be very nice to know whether my code actually runs elsewhere, too.

A UI is needed. I thought of using McClim and I'll have to learn that, but I would like to focus on the inner workings first. Hacking something together so more people would be willing to try out the editor would be nice.

Then there is the issue of scope - although it's not so very important to me, as I'm not dependent on the success of what I am doing here, there is some quite developed competition (Leo, org-mode/babel). So far MindMaDE's supposed strength should be the scripts to convert mindmaps into any imaginable format.
Currently I am going for the following: Any script is invoked on a single node, converts and registers the node (so it won't convert the same node more than once). It combines the data from converting the node from calling scripts on all nodes reachable in one step. What script is called is dependent on the edge type leading to the node and the node type. I need to know whether this approach sounds reasonable and what additional functionality might be considered useful.

Currently converting a node and filtering reachable nodes by weight, edge type and node type is implemented.
Converting a node is done via the stuff in field-collector.lisp. First there is the class FIELD-COLLECTOR, that describes how a field is combined with the collection of previously converted fields. CALL-FIELD-COLLECTOR actually converts a node via the information of FIELD-COLLECTOR. I made sure that fields are always collected in the order specified when making the field collector and since any field is present only once in any node there is no ambiguity with that.
Next is collecting nodes. This consists (with the framework as I currently have it in mind) of two steps:
1. Collect the data from the reachable nodes.
2. Combine those data with the data collected from the source node.
The first part works just like the field collector, with a field collector specified for any desired combination of edge types, edge weights and node types. As there can be multiple target nodes there has to be an option for the user to specify and ordering relation.
The second part could be defined directly in a SCRIPT class, so that this defines how source node data and target node collection are combined.
Note, that collecting nodes and fields currently has the full power of Common Lisp, so you can write to files, compile stuff and do all kinds of other fancy things but this also means that you have to learn Common Lisp before you can write scripts to export your maps.
I don't see any problems with that concept, but I might miss something. Any obvious or less obvious holes? An easier solution? What convenience functions might be helpful?

Oh, and also: Thanks for your help, it is very much appreciated.

[Antsan]

I've got a little problem with style:
There are three mindmade type types *cough*: edge-type, node-type and document-type. An edge/node/document is right now created via a function of the following form:
INSTANCIATE-*-TYPE name *-type
where the star is replaced with what you want to create.
What this actually does is to make an instance of the appropriate class and initialize the type slot of the created object with the given *-type object. A function that does that normally is called
MAKE-*

Now I am not sure whether I should rename those functions again to adhere to the MAKE-* convention or I should leave them in their current form.
The current naming scheme hides the fact, that those mindmade types are not actually types but objects. As far as I know this is a good thing, as making instances of types feels much more natural then making an object which has a reference to an object doing all the bookkeeping of what is allowed and what isn't.
The standard naming scheme is, well, a standard and I am not sure whether the reasons listed above really justify straying from that.