He he! Perhaps NooRanch is NooVictorian ....
(I know, bad, bad pun)
Wednesday, November 28, 2007
What's this?
An HTML list that came out of GeekWeaver, when I called this recursive function :
on a chunk of OPML.
That's pretty much how it's going to look, folks.
::rec defines the recursive block (or function)
.<ul> creates the UL tag
:for x,, #__
is creating a loop through all the anonymous (unlabelled) children of the tree which is being passed to the call. (This list is represented by the symbol __)
Note that I'm trying to keep GeekWeaver as functional as possible so there's no real "assignment". x is scoped so that it only exists inside the block of the for-loop, it's bound once before the block is evaluated, but can't be updated after that.
${x/=}
This is the new way of accessing variables. x is actually bound to a sub-tree (Almost everything in GeekWeaver is a sub-tree, except a couple of weird cases like __ which is a list.)
Although a simple $x still works if you want the whole of a tree flattened into a string, ${} expressions give you a way to pull data from a single path in the tree. In this case we're just getting the text content of the root node of x.
But it's also possible to write stuff like this : ${company/employees/__3/name} which means from the symbol "company" get the labelled child "employees" from which get the non-labelled 3rd child, from which get the child labelled "name".
:hasChild, like :for, is a build-in function. If the tree in x has any children, it evaluates the body of the :hasChild tree. If not, it returns nothing. This tests for our "base-case" when we've hit a leaf of the tree we're recursing through.
The final line :
:rec ++ #x__
is the one which I've been struggling with for the last three months, ever since I started trying to figure out how to support recursion. I'm still not 100% happy with the solution I've come up with, but it's getting there.
:rec is calling the recursive block again. And obviously I need to pass the children of x as arguments. However the way the function is written, it is working on the anonymous children (inside the default variable __)
How am I going to get the children of x into the __ variable inside the next call of :rec? That's what ++ does. Not sure what I'm going to call this, I may call it a "pivot" although that may confuse as much as help. It captures something of the idea that I need to swing the anonymous children of x (#x__) around so that they can go into the next call of :rec as though they were children of the calling node
Like I say, don't know if I like this name or the ++ symbol being used for it. So consider both as provisional for now.
OK, I'm too tired to make the build with this stuff working tonight. I'll try to get a build together in the next couple of days, but meanwhile, if this looks interesting to you and you can't contain yourself, send me an email (interstarATgmail.com), say hello and I'll see what I can do.
- 1
- 2
- 21
- 211
- 22
- 21
- 3
- 4
- 41
- 42
- 43
- 431
- 4311
- 431
- 5
An HTML list that came out of GeekWeaver, when I called this recursive function :
::rec
.<ul>
:for x,, #__
.<li>
${x/=}
:hasChild x
:rec ++ #x__
on a chunk of OPML.
That's pretty much how it's going to look, folks.
::rec defines the recursive block (or function)
.<ul> creates the UL tag
:for x,, #__
is creating a loop through all the anonymous (unlabelled) children of the tree which is being passed to the call. (This list is represented by the symbol __)
Note that I'm trying to keep GeekWeaver as functional as possible so there's no real "assignment". x is scoped so that it only exists inside the block of the for-loop, it's bound once before the block is evaluated, but can't be updated after that.
${x/=}
This is the new way of accessing variables. x is actually bound to a sub-tree (Almost everything in GeekWeaver is a sub-tree, except a couple of weird cases like __ which is a list.)
Although a simple $x still works if you want the whole of a tree flattened into a string, ${} expressions give you a way to pull data from a single path in the tree. In this case we're just getting the text content of the root node of x.
But it's also possible to write stuff like this : ${company/employees/__3/name} which means from the symbol "company" get the labelled child "employees" from which get the non-labelled 3rd child, from which get the child labelled "name".
:hasChild, like :for, is a build-in function. If the tree in x has any children, it evaluates the body of the :hasChild tree. If not, it returns nothing. This tests for our "base-case" when we've hit a leaf of the tree we're recursing through.
The final line :
:rec ++ #x__
is the one which I've been struggling with for the last three months, ever since I started trying to figure out how to support recursion. I'm still not 100% happy with the solution I've come up with, but it's getting there.
:rec is calling the recursive block again. And obviously I need to pass the children of x as arguments. However the way the function is written, it is working on the anonymous children (inside the default variable __)
How am I going to get the children of x into the __ variable inside the next call of :rec? That's what ++ does. Not sure what I'm going to call this, I may call it a "pivot" although that may confuse as much as help. It captures something of the idea that I need to swing the anonymous children of x (#x__) around so that they can go into the next call of :rec as though they were children of the calling node
Like I say, don't know if I like this name or the ++ symbol being used for it. So consider both as provisional for now.
OK, I'm too tired to make the build with this stuff working tonight. I'll try to get a build together in the next couple of days, but meanwhile, if this looks interesting to you and you can't contain yourself, send me an email (interstarATgmail.com), say hello and I'll see what I can do.
Sunday, November 18, 2007
Sunday, November 11, 2007
Hey! I like NeoVictorianism.
There's a movement I can sign-up for :
There's a movement I can sign-up for :
Built for people
Built by people
Crafted in workshops
Embracing irregularity
Inspired
Thursday, November 08, 2007
Just spent the last few hours downloading and playing with the beta of Flex 3, Adobe's IDE for Rich Internet Applications (ie. applications running on the Flash Virtual Machine) which is based on Eclipse and has an XML-based UI / form description language more or less like HTML.
I'm having two thoughts about it. One is a kind of sigh of relief. This is, after all, finally, The One. After years of fruitless searching I'm pretty sure here's a framework I can settle down with and commit to, and start making babies with. At least, it's more or less mature enough, handsome enough and well endowed enough to put these thoughts into a girl's head. A browser and a desktop? Holidays in Windows, Mac and Linux? Own grid and canvas. Tabbed notebook and some cute chunky buttons.
And it's all done in a way that's pretty self-evident when you look at a few examples. Forms and input widgets are described in XML. They layout nice; and you can start banging them in and prototyping the look of your interface in a couple of minutes. The round-trip from coding to running and testing is a bit slow on my poor 512MB Vista laptop, but it's going to be bearable. And the Eclipsyness of it all is comfortingly familiar if a trifle overblown.
As long as my next experiments turn out right (the one where I try to find a tutorial example of pulling data off a server over http, and the one where I try to compile with AIR into a stand-alone application) then I'm sold.
But there's another part of me going, "huh? Is this all there is? WTF?"
I mean, it's 2007 and I'm happy because I've finally found a way to make GUIs that's sufficiently lower than my pain threshold that I might actually get a piece of software released again. Zowie! But that's what I had with Visual Basic 6 - which came out in about 1997!
In fact, I was already a Pythonista before I started writing SdiDesk in VB. And I only pulled out VB (a language I thought I'd left behind for good) because I got impatient to see what the UI of an SdiDesk could look like and thought I'd prototype it. As often happens, the prototype spiraled out of control as I kept thinking, "maybe I can just also add ... " and within a month or so it had already started to grow into a real program. Another phase of development with some serious refactoring and cleaning up the internal architecture, and it was a quite respectable and powerful bit of software (If I say so myself; I'm talking about the time I made the tutorial screen-casts.)
(Then, of course, I hit the crisis of not wanting to be on the Microsoft treadmill and forced to upgrade to .NET; even though it was obvious that VB6 was as extinct as a very extinct thing from the Lower Devonian period. But also of not having any viable alternative. )
So there's a sense that Flex smells extraordinarily similar. I can see how you can knock out your prototype interface and start building backwards from it. That feels good. That's why it seems like this is plausible option to get development rolling again.
But, like I say, it *is* basically what I had 10 years ago. Except with javascript dressed up in Java's suit and tie to look more grown-up and respectable. And XML.
In fact, I was gchatting to Zbigniew earlier today, and realizd that all of this stuff is hardly a big advance on Hypercard back in 1985. Or perhaps Smalltalk 1972. Why the hell haven't we progressed further? Why am I struggling on each new platform to rediscover the level of comfort I had on the previous one? What's going wrong here?
I suppose it could just be that the idea of quick GUI builders is inherent in the idea of a GUI?
Or maybe we programmers of the noughties need to get our acts together and start coming up with serious new, cool shit. Stuff which couldn't have been thought up in the 60s and 70s. Stuff which is radically easier and more productive than something we had 10 years ago. Something likereinventing Lisp with a cleaner (non)syntax ... erm ... well anyway, I'm off to do more experiments with Flex and try to get it to talk to some kind of server.
If I succeed, then expect to see some interesting developments along the lines I mentioned earlier today ... steps towards a new SdiDesk, possibly a GeekWeaver development environment ... maybe even the long fabled, but never released SystemSketch. Or even the more outré things I've got buzzing around in my fevered imagination like "SexyCells" and "FlowerBrush".
Of course, it still sucks that Flex / Flash seems to have no musical ability whatsoever so Gbloink! doesn't look like an option. Which is a double pity because I think it would make a great Chumby widget and that would have justified me buying one.
:-(
I'm having two thoughts about it. One is a kind of sigh of relief. This is, after all, finally, The One. After years of fruitless searching I'm pretty sure here's a framework I can settle down with and commit to, and start making babies with. At least, it's more or less mature enough, handsome enough and well endowed enough to put these thoughts into a girl's head. A browser and a desktop? Holidays in Windows, Mac and Linux? Own grid and canvas. Tabbed notebook and some cute chunky buttons.
And it's all done in a way that's pretty self-evident when you look at a few examples. Forms and input widgets are described in XML. They layout nice; and you can start banging them in and prototyping the look of your interface in a couple of minutes. The round-trip from coding to running and testing is a bit slow on my poor 512MB Vista laptop, but it's going to be bearable. And the Eclipsyness of it all is comfortingly familiar if a trifle overblown.
As long as my next experiments turn out right (the one where I try to find a tutorial example of pulling data off a server over http, and the one where I try to compile with AIR into a stand-alone application) then I'm sold.
But there's another part of me going, "huh? Is this all there is? WTF?"
I mean, it's 2007 and I'm happy because I've finally found a way to make GUIs that's sufficiently lower than my pain threshold that I might actually get a piece of software released again. Zowie! But that's what I had with Visual Basic 6 - which came out in about 1997!
In fact, I was already a Pythonista before I started writing SdiDesk in VB. And I only pulled out VB (a language I thought I'd left behind for good) because I got impatient to see what the UI of an SdiDesk could look like and thought I'd prototype it. As often happens, the prototype spiraled out of control as I kept thinking, "maybe I can just also add ... " and within a month or so it had already started to grow into a real program. Another phase of development with some serious refactoring and cleaning up the internal architecture, and it was a quite respectable and powerful bit of software (If I say so myself; I'm talking about the time I made the tutorial screen-casts.)
(Then, of course, I hit the crisis of not wanting to be on the Microsoft treadmill and forced to upgrade to .NET; even though it was obvious that VB6 was as extinct as a very extinct thing from the Lower Devonian period. But also of not having any viable alternative. )
So there's a sense that Flex smells extraordinarily similar. I can see how you can knock out your prototype interface and start building backwards from it. That feels good. That's why it seems like this is plausible option to get development rolling again.
But, like I say, it *is* basically what I had 10 years ago. Except with javascript dressed up in Java's suit and tie to look more grown-up and respectable. And XML.
In fact, I was gchatting to Zbigniew earlier today, and realizd that all of this stuff is hardly a big advance on Hypercard back in 1985. Or perhaps Smalltalk 1972. Why the hell haven't we progressed further? Why am I struggling on each new platform to rediscover the level of comfort I had on the previous one? What's going wrong here?
I suppose it could just be that the idea of quick GUI builders is inherent in the idea of a GUI?
Or maybe we programmers of the noughties need to get our acts together and start coming up with serious new, cool shit. Stuff which couldn't have been thought up in the 60s and 70s. Stuff which is radically easier and more productive than something we had 10 years ago. Something like
If I succeed, then expect to see some interesting developments along the lines I mentioned earlier today ... steps towards a new SdiDesk, possibly a GeekWeaver development environment ... maybe even the long fabled, but never released SystemSketch. Or even the more outré things I've got buzzing around in my fevered imagination like "SexyCells" and "FlowerBrush".
Of course, it still sucks that Flex / Flash seems to have no musical ability whatsoever so Gbloink! doesn't look like an option. Which is a double pity because I think it would make a great Chumby widget and that would have justified me buying one.
:-(
Quick Note : I just had a revolution in my thinking, triggered by Enso but influenced by several other recent trends.
You write Enso "extensions" as XML-RPC servers sitting on your local machine, register them with Enso and it calls them using XML-RPC. I tried the example from the tutorial and it's very cute and simple. So I've decided this may be a way forward for the dilemma which has kept the "new SdiDesk" on hold for several years(!!!)
If you remember, the issue has been whether the new SdiDesk should be a "web"-application (accessed through the browser) or a desktop application? And how to implement the UI.
The problem with the "browser" answer has always been : "but how to do the network diagramming bit?" - which requires interactive vector graphics. SVG doesn't seem quite stable or cross-browser enough. Canvas isn't cross-browser. Flash is proprietory.
The problem with the "desktop application" is, well, the many rival Python GUI libs with different degrees of maturity. And the question of getting them to work cross-platform.
A meta-problem : I just don't have time and energy to go through learning lots of different GUI frameworks to decide which I want to use. And the ideal answer to the browser / desktop question is probably "both" which doubles the amount of work.
In fact, one of the motivations for GeekWeaver is to see if I can use it define a higher-level UI description that can be compiled down into both XHTML and a GUI widget-set.
Of course, with XUL, Open Laszlo, Adobe Flex, XUML etc. lots of people have been looking at something like HTML for defining desktop apps. too, but the free Python frameworks don't seem to have caught up with that yet. XUL sounds most promising especially with the open sourcing of Active State's Komodo ... but that's also a big complicated thing to even start looking into.
Anyway, inspired by the Enso extensions and Bruce Eckel's interesting example of hooking up a Python XML-RPC server behind an Adobe Flex application I've been wondering about blowing the project apart entirely into a number of services connectd only XML-RPC or something more ReSTful.)
So there'll be a WADS (SdiDesk PageStore) service, a GeekWeaver interpreter service, a "user navigation history service" etc. Even the glue which ties all this together will be another service that's neutral about the user-interface. Effectively the model, view and controller will be completely separate programs. (I know, I know ;-) )
Then there'll be a variety of different types of access with different UIs.
Now that Adobe's AIR has put Flash on the desktop and made it a serious rival to the Java virtual machine - I *am* tempted to put some time into learning it. It would give me a reasonable GUI widget set (including TreeGrid, yay!) and the vector graphics needed for networks. It will run both on the desktop and in the browser and on Linux, PC and Mac. The tools are free-as-in-beer (Flex beta) or free-as-in-speech (Open Laszlo). It's also possible to imagine generating the Flex XML or the Open Laszlo format directly from GeekWeaver. (Aside : I wish ActionScript hadn't borrowed quite so much from Java, but still, I'd only be using it for the front-of-the-front-end UI stuff.)
Then I want to experiment with Enso access - for example, Enso commands like "page HelloWorld" or "pagehistory ChocolateCake"
And there'll be web-browser access probably through a "gateway" that accepts http requests and spits out HTML for a browser. The only thing I don't know is whether I *really* should be using WSGI somewhere here.
Anyway ... that's a quick update of my thinking this week ... tune in soon for the next GeekWeaver release (really, it's coming together, and gonna be very powerful). Then it's back to work on this larger project.
You write Enso "extensions" as XML-RPC servers sitting on your local machine, register them with Enso and it calls them using XML-RPC. I tried the example from the tutorial and it's very cute and simple. So I've decided this may be a way forward for the dilemma which has kept the "new SdiDesk" on hold for several years(!!!)
If you remember, the issue has been whether the new SdiDesk should be a "web"-application (accessed through the browser) or a desktop application? And how to implement the UI.
The problem with the "browser" answer has always been : "but how to do the network diagramming bit?" - which requires interactive vector graphics. SVG doesn't seem quite stable or cross-browser enough. Canvas isn't cross-browser. Flash is proprietory.
The problem with the "desktop application" is, well, the many rival Python GUI libs with different degrees of maturity. And the question of getting them to work cross-platform.
A meta-problem : I just don't have time and energy to go through learning lots of different GUI frameworks to decide which I want to use. And the ideal answer to the browser / desktop question is probably "both" which doubles the amount of work.
In fact, one of the motivations for GeekWeaver is to see if I can use it define a higher-level UI description that can be compiled down into both XHTML and a GUI widget-set.
Of course, with XUL, Open Laszlo, Adobe Flex, XUML etc. lots of people have been looking at something like HTML for defining desktop apps. too, but the free Python frameworks don't seem to have caught up with that yet. XUL sounds most promising especially with the open sourcing of Active State's Komodo ... but that's also a big complicated thing to even start looking into.
Anyway, inspired by the Enso extensions and Bruce Eckel's interesting example of hooking up a Python XML-RPC server behind an Adobe Flex application I've been wondering about blowing the project apart entirely into a number of services connectd only XML-RPC or something more ReSTful.)
So there'll be a WADS (SdiDesk PageStore) service, a GeekWeaver interpreter service, a "user navigation history service" etc. Even the glue which ties all this together will be another service that's neutral about the user-interface. Effectively the model, view and controller will be completely separate programs. (I know, I know ;-) )
Then there'll be a variety of different types of access with different UIs.
Now that Adobe's AIR has put Flash on the desktop and made it a serious rival to the Java virtual machine - I *am* tempted to put some time into learning it. It would give me a reasonable GUI widget set (including TreeGrid, yay!) and the vector graphics needed for networks. It will run both on the desktop and in the browser and on Linux, PC and Mac. The tools are free-as-in-beer (Flex beta) or free-as-in-speech (Open Laszlo). It's also possible to imagine generating the Flex XML or the Open Laszlo format directly from GeekWeaver. (Aside : I wish ActionScript hadn't borrowed quite so much from Java, but still, I'd only be using it for the front-of-the-front-end UI stuff.)
Then I want to experiment with Enso access - for example, Enso commands like "page HelloWorld" or "pagehistory ChocolateCake"
And there'll be web-browser access probably through a "gateway" that accepts http requests and spits out HTML for a browser. The only thing I don't know is whether I *really* should be using WSGI somewhere here.
Anyway ... that's a quick update of my thinking this week ... tune in soon for the next GeekWeaver release (really, it's coming together, and gonna be very powerful). Then it's back to work on this larger project.
Tuesday, November 06, 2007
Next installment of the must-read series on FogCreek's Wasabi.
Fascinating to see the problems they've come up against and the solutions. What Stefan calls "picture functions" sound close to GeekWeaver "blocks".
Fascinating to see the problems they've come up against and the solutions. What Stefan calls "picture functions" sound close to GeekWeaver "blocks".
Monday, November 05, 2007
Thursday, November 01, 2007
Very interesting ... seems that FogCreek's Wasabi is a language to compile into the various parts of a web-app in ASP or PHP.
So kind of a competitor to GeekWeaver. :-) Better take notes.
I wonder if it's gonna be released to the public.
So kind of a competitor to GeekWeaver. :-) Better take notes.
I wonder if it's gonna be released to the public.
Subscribe to:
Posts (Atom)