Day: March 2, 2006

How can I use information from sfattr or sfget in SConstruct Flows?

March 2, 2006 FAQ No comments

This may not be the most elegant solution but you can try using parameter files. Here is an example:

  1. Create some data.
    Flow('data',None,'spike n1=100 | bandpass fhi=40')
  2. Generate a parameter file from it.
    Flow('mag.par','data',"attr want=max | sed 's/value = /mag=/' ")
  3. Use the parameter file in processing.
    Flow('test','mag.par','spike n1=100 par=$SOURCE',stdin=0)

Nick Vlad on RSF and XML

March 2, 2006 Systems No comments

Thoughts from Nick Vlad on RSF and XML

Provocative idea for the long term that you may post if it seems interesting: Making the history files XML
documents. Their “written by machine, sometimes read by a human” paradigm is exactely that of XML. This
will not impede reading with existing programs, but will instead open intriguing possibilities. The
machine would be able to construct a diagram of the processing history. One does not need to write C++
code to do graphical interfaces. Just transform XML into XHTML 1.0 Strict through a XSLT filter – or
through a basic python script (i.e. <sfwindow> into <div class=”sfwindow”> ). Format with CSS. The history of the file becomes all of a sudden a nice suite of boxes on a webpage. One can do Fahrner Image Replacements in the CSS stylesheet to use specific icons for various (classes of) programs. We’ve just got ourselves a neat little “Processing History Explorer”!
But this is not all. Assume that each RSF program, when appropriately queried, would return a range of valid values for its parameters and a list of the file tags it needs, with intent (in, out, inout). Then it would be possible to automatically transform the XML information about a program into SVG drawings (again, with a XSLT stylesheet), with arrows connecting the processes/files. It is possible to do hyperlinks from SVG elements, so the user can open a window with a XHTML form with menus, radio buttons, etc, with the settings of the program. Now, all of a sudden, we have more than a “Processing History Explorer”. Change the parameters, press submit, modify the flow, run it, the XML description of the processing flow gets transformed into a Scons file, and runs on the remote machine!
The great advantages of doing graphical interfaces this way would be that: (A) they would be entirely platform-independent; (B) They would run as well on remote user machines as on the local host; (C) The number of people who can do web development is much greater than that of the people who know how to do GUI development, so it will be easier to get people to contribute.