[Swift-devel] changes in trunk (tracing and usability)

[Michael Wilde]

All sounds very cool - Im eager to try this. We may want to update 0.94 with these features, or push 0.94 out sooner and release this as 0.95.

- Mike

----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Swift Devel" <swift-devel at ci.uchicago.edu>
> Sent: Friday, November 9, 2012 11:54:45 PM
> Subject: [Swift-devel] changes in trunk (tracing and usability)
> Hello,
> 
> I added a few things in trunk meant to make it easier to debug issues
> with scripts.
> 
> The major one is tracing. It's disabled by default, but can be enabled
> with -tracing.enabled on the command line (or with the tracing.enabled
> property).
> What it does is it traces app calls, compound calls, assignments, etc.
> It does it with line numbers, threads, and run-time information where
> available (such as the exact values of the k, v pair for an iteration,
> the exact arguments to a function or app, etc.).
> Not all things are traced yet, but I wanted to see if it's useful
> before
> putting too much effort into it.
> 
> The minor ones are:
> - stack traces for errors. When swift fails, it prints a swift stack
> trace instead of just the error message with no location information.
> This is in non-lazy error mode, and lazy errors might need more work.
> - the "invalid path" errors are gone. You now get "Array index <value>
> not found for <array> of <size>" or "Invalid field name <name> for
> <struct_variable> of type <type>". These types of errors should be
> caught at compile-time, but there are still places where the static
> system can be bypassed.
> - there was a race condition in the creation of array elements of
> struct
> type which would sometimes produce the "Invalid path
> <valid_struct_field> for <variable>". It's fixed now.
> 
> Mihael
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory