[Swift-devel] printing and library functions

[Michael Wilde]

[was: Re: [Swift-devel] could we set the job sequence without a file 
dependency?]

[digression on]

 From what Ive done with oops over the past month I observe a need to 
print the status of the workflow as it proceeds.

I guess thats a kind of "debugging" - watching to make sure a workflow 
is making progress.

I *used* to tail the debug log; then I started tailing that log to watch 
and count specific status messages. Now Ive taken to entirely watching 
just stdout, and only looking in the log when things fail and the output 
file doesnt clearly say why. I feel its a good step forward that I can 
do this.

But users will, I believe, want some way beyond just the periodic status 
line to show how their script is progressing.  I used trace, which is 
OK. I think this need will grow as I hand oops over the people who will 
be running it to do science (and by the way, thanks to all of you that 
is happening as we speak!).

This comment, btw, is not on the topic of "seq{}", but rather on the 
need for output primitives.

So, while we're on this topic and digressing:

I often missed various string and data handling operations in Swift. In 
a few points of developing oops, I was delighted to find that I could 
implement almost any library function I wanted (including string 
functions like sprintf/fprintf, intToStr(), etc, using a 2-step call: an 
app to call the external function, and if needed a proc to wrap it and 
use readData() or readdata2() to extract back the return value(s).

I turned out to be pretty reasonable to define a nice sprintf at the 
moment by passing a varying number of arguments as an array of strings 
using an array constructor:

[ s1, s1, itos(i1), ftos(f1), btos(b1) ]

using one layer of primitives to convert all objects to strings, and 
then passing the string array to sprintf(), and back to trace().

Discovering how to do this eliminated a request I had long been 
repressing for "easier to implement built-in functions".

The fact that readdata accepted a file in addition to a file name was 
critical.

A few things that do come to mind on this, to permit more flexible (or 
aesthetic) library functions, are:

- varying length arg lists (or)
- arrays of type Object (ie heterogeneous arrays)
- \ escapes in strings (\n \t etc)
- sizeof(array)
- isSet() etc: See if a var is set or not. cant recall now where I 
wanted this, need to check my notes. Not very important, I think this 
was to hack around some other issue, cant recall what. Im sure its a 
functional and synchronization no-no.

One might define the first two in various ways related to each other.

So out of all these things, the only one that might be nice to do sooner 
is the \ escapes in strings, iff thats easy.

Just thought I would toss those out in case others have seen similar 
needs and see easy ways to implement them.

Im excited about the prospects of seeing a Swift library grow. I'll try 
to package up the few functions Ive played with to spark some ideas and 
library development. We should start batting around ideas for libraries, 
and for naming, etc, but a simple include mechanism for now will get us far.

- Mike

(the astute will notice that I have neglected to set [digression off]. 
That may or may not have been intensional... ;)



On 3/24/09 4:37 PM, Ben Clifford wrote:
> On Tue, 24 Mar 2009, Ian Foster wrote:
> 
>> This was the case in PCN when people were trying to do printf-like output. So
>> you introduced a version of printf that bound a variable when it was done, and
>> then wrote something like:
> 
>> BUT -- maybe we don't really do output like this in Swift programs (I don't
>> think it is common, is it)?
> 
> Its not common to do "meat output" like that, no - all of that comes from 
> procedures which generate files, which tend to not need sequencing of 
> output.
> 
> Most of what you've talked about seems debugging oriented - none of the 
> debugging I've done with people has really felt like I've wanted that kind 
> of sequence operator. But I think some debugging-oriented something (be it 
> language features, runtime options, something) would be useful - but its 
> not clear to me what.
>