Prototurb that fabulous Code of yours

tree-grep "^my*" code.prt | v-sed s/old/new/ | commit-to -m "Change old to new" code.prt

in tree-grep, ^ means the beginning of a list representing a node in the tree

v-sed = keeps version data, and stores the changes in the default work branch,

commit-to = commits the work-branch

Nothing new to deliver, just having this protoplasmic brain that produces some ectoplastic thoughts eg. just alien ideas to make our thoughts phone home. And you, those spooky cryptic comments i have is nothing to get scare about, it's all about creativity and the fun it represent.

I've not been lazy, but I'm searching for the toolbox and the format of how I would like to do development. It has for the 6 past months actually been a constant flux of creativity and I learned a lot. I hope that I can start to get ready to knit together at least prototypes so that others can share the fun.

Let's recycle the proto stuff, I mention leo,git,python and Lisp in the previous post and prototyped a little about the git,lisp and python association in the beginning, what about leo, the leo maintainer arguments that when developing and fixing a Bug It is nice to collect the bit's that are associated with the Bug and work on it in that environment. Now, you might disslike that method but it does something interesting, it documents very effectively the Bug without doing any comments at all and will probably help the next person fixing the Bugs that the referred bugfix will introduce. I'm not eating this dogfood though but I can imagine it beeing useful so I included it.

The problems with associations of cause is that you don't transmit what you see and it's not exact, but It do let people think for themselves and the intention is of cause to be overrun with better ideas or arguments.

And to be exact all this is free thoughts about what our environment would look like if there was a imposed structure on our files and what that structure might bring and look like

Let's think, some mentioned gnu screen together with git and file systems, cool. I associate gnu screen with a state that you can hook into, work (with/in) that state, and than log out. This interpreted in a datastructure could be that you are working for example with different branches of the datastructure in different screen sessions, e.g. what you do in one screen session should not interfere with what you do in another screen session until you do a merge if that is what you wan't. if you do not merge but quits a GC perhaps needs to kick in and clean the stuff up.

It all boils down, in the end, to one thing, A Smile )