[DDW-245] Download manager

This PR implements a download manager.
Todos

[x] Method for requesting a new download
[x] Method for requesting the local data for a stopped download
[x] Method for resuming a stopped download

Testing Checklist

Slack QA thread

Steps for testing:

Open the Devtools, Console tab;
Open the State directory (it can be found in the diagnostics screen);
Run the command daedalus.stores.appUpdate._requestUpdateDownload();
Inside the Downloads folder a file with a name format of Unconfirmed-{timestamp}.crdownload should appear;
The download progress should be printed in the Console;
Close the app when the download is about 50%;
Reopen the app;
Run the command daedalus.stores.appUpdate._managePendingUpdate() in the Devtools console;
A downloadLocalData object should be printed, containing the download's data and progress information;
Run the command daedalus.stores.appUpdate._requestResumeUpdateDownload();
The download should resume from the correct percentage progress;
After the download is finished, the file inside the Downloads folder should have been renamed to daedalus-1.1.0-mainnet-12849.pkg.

Obs: this task doesn't handle the app update itself. It's a generic Download Manager.

Review Checklist
Basics

[ ] PR has been assigned and has appropriate labels (feature/bug/chore, release-x.x.x)
[ ] PR is updated to the most recent version of the target branch (and there are no conflicts)
[ ] PR has a good description that summarizes all changes
[ ] PR has default-sized Daedalus window screenshots or animated GIFs of important UI changes:

[ ] In English
[ ] In Japanese

[ ] CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub
[ ] Automated tests: All acceptance and unit tests are passing (yarn test)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in development build (yarn dev)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in production build (yarn package / CI builds)
[ ] There are no flow errors or warnings (yarn flow:test)
[ ] There are no lint errors or warnings (yarn lint)
[ ] There are no prettier errors or warnings (yarn prettier:check)
[ ] There are no missing translations (running yarn manage:translations produces no changes)
[ ] Text changes are proofread and approved (Jane Wild / Amy Reeve)
[ ] Japanese text changes are proofread and approved (Junko Oda)
[ ] UI changes look good in all themes (Alexander Rukin)
[ ] Storybook works and no stories are broken (yarn storybook)
[ ] In case of dependency changes yarn.lock file is updated

Code Quality

[ ] Important parts of the code are properly commented and documented
[ ] Code is properly typed with flow
[ ] React components are split-up enough to avoid unnecessary re-renderings
[ ] Any code that only works in main process is neatly separated from components

Testing

[ ] New feature/change is covered by acceptance tests
[ ] New feature/change is manually tested and approved by QA team
[ ] All existing acceptance tests are still up-to-date
[ ] New feature/change is covered by Daedalus Testing scenario
[ ] All existing Daedalus Testing scenarios are still up-to-date

After Review

[ ] Merge the PR
[ ] Delete the source branch
[ ] Move the ticket to done column on the YouTrack board
[ ] Update Slack QA thread by marking it with a green checkmark

@daniloprates can you please merge in latest develop?

I can confirm that this works on the passing Mac builds.


Add cache invalidation to API store

This also does a lot of general refactoring and documentation, limited to the first commit.
Closes #225

Coverage increased (+0.06%) to 93.859% when pulling 0199cc8ed84c1af1b2efa1e0bba8aa1250f133ed on refactoring/api-store into 8c26862282ee2d5adf32ebee9bf68ea53fb37366 on master.

Nice work. This really makes this stuff a lot easier to understand

👍

Thanks!


Sync sample data for 'Amend order confirmation' to apparel

This sample data (spartacussampledataaddon) that is in electronics were put by was Tobias
--- anyone can take this ticket

Please add missing sample data to apparel

MASTER ticket: https://github.com/SAP/cloud-commerce-spartacus-storefront/issues/6231
please tick the checkbox once merged and completed

QA steps:

Go to /apparel-uk-spa/en/GBP
If you dont' have any orders in your account create one
check the cancel/return orders flow behave the same way as in electronics store in context of changes done in the impex

QA done, all cancel and return components exists and rendering properly on apparel.


Zoom image to drawing window

Is there a feature to zoom image to the window drawing from top left to bottom right, just as photoshop's zoom feature did.
Thanks.

I don't know what you mean... What kind of zooming is this? Can you give an example?
If you are trying to zoom to a specific location, I recommend viewer.viewport.fitBounds.


Keep timepicker open

is there a way to disabled the click off event so the timepicker doesn't close when i inspect my code using dev tools?

if you're using the dev branch, I just added a debug option. setting this to true will prevent the hide() from being called on a blur event

Sorry my knowledge of jQuery isn't the best. Like this?

yup!

Doesn't seem to work
https://jsfiddle.net/5fu1w85L/

the fiddle has console error's and you're loading the datepicker from the master branch. You'll need to download the files from the dev branch

is there not just a simple function which keeps the timepicker open so i can inspect it and add some styling?
wheres the dev branch - out of interest?

The dev branch is here: https://github.com/Eonasdan/bootstrap-datetimepicker/tree/development
As I said, this feature hasn't made it into the master yet. Adding debug: true will keep the picker open.

Excellent - sorry for my stupidity.

hopefully option to keep open just like debug:true will also be added.


Allow graphite/reporter to take existing Graphite instance

...rather than resolving (hostname, port) to InetSocketAddress once.
We've been using this library in production for a few months, and it's been working great. But every few weeks, we noticed some of our applications would stop reporting to Graphite: Unable to report to Graphite. Once this condition was reached, the affected apps would not report to Graphite until being restarted. We were able to time-correlate these incidents with AWS recycling IP addresses in the ELB that fronts our Graphite instances.
The issue seems to be that graphite-sender resolves hostname to a particular IP address, and uses the Graphite constructor that accepts a InetSocketAddress. When the IPs behind a hostname change over time, that IP address may no longer be valid but will never be re-resolved by the Graphite reporter.
It appears this code in Graphite.connect() will never re-resolve the IP address if Graphite was instantiated with the InetSocketAddress constructor, since this.address == null will never be true, and address.getAddress() doesn't re-resolve the IP address from the hostname if it's already been resolved once.
My proposed fix is to use the Graphite constructor that takes the same arguments as graphite-sender: hostname and port.

Thanks for the quick response!

It makes sense but I'd like to avoid this being a breaking change.

Is this considered a breaking change because it uses a different Graphite constructor under the hood? AFAICT the clojure-metrics public API would remain unchanged. It changes how Graphite internally resolves the IP address it sends metrics to, but I'm not sure how breaking that might be. Maybe I'm missing something, but I'm not sure what the utility is in resolving hostname and port to InetSocketAddress before instantiating Graphite, when Graphite already has a constructor that takes hostname and port.

Can we massage graphite-sender to accept both?

Yes, but being a private function that's only called by reporter, I think we'd have to also add some option input to reporter to specify whether Graphite should be constructed with hostname+port, or InetSocketAddress?
Or... what do you think about this:
(defn- ^GraphiteReporter reporter
  ([opts]
   (reporter m/default-registry opts))
  ([^MetricRegistry reg {:keys [graphite host hostname port prefix clock rate-unit duration-unit filter] :as opts
                         :or   {port 2003}}]
   (let [g (or graphite (graphite-sender (or host hostname "localhost") port))
         b (builder-for-registry reg)]
     (when-let [^String s prefix]
       (.prefixedWith b s))
     (when-let [^Clock c clock]
       (.withClock b c))
     (when-let [^TimeUnit ru rate-unit]
       (.convertRatesTo b ru))
     (when-let [^TimeUnit du duration-unit]
       (.convertDurationsTo b du))
     (when-let [^MetricFilter f filter]
       (.filter b f))
     (.build b g))))

☝ Add an opts key so a pre-constructed Graphite instance can be passed in to reporter? In that case, the [host hostname port] keys would be ignored.

Yes, I'm concerned that unless Graphite constructor already does argument normalization/resolution then currently used string values will fail as they are IP addresses and not hostnames.
A new opts key definitely works. However, I agree that supporting hostnames is a good idea as they tend to be

More stable than IP addresses
More widely used

but I'd understand if you stop at adding support for pre-configured graphite instances since it would be sufficient for your needs :)
Thanks again!

Thank you!
I will try to publish a preview release to Clojars tomorrow the latest.


Test 'My reservations'

It showed No upcoming reservations, followed by the list of reservations, but in the bug, 'my reservation' was queried first and then 'my reservations'.

Working on it..found the bug.. the "No Upcoming reservations" is coming up due to asynchronous nature or code execution in node.js

fixed in it commit issue#63


ModuleNotFoundError: No module named 'eerie.nn.functional.bconv'

It seems that the 'bconv.py' file is missing in 'eerie/nn/functional/'.

Hi Zichen, sorry for my late response. The bconv.py file is not necessary. I might have forgotten to put its requirement away somewhere. Could you please tell me which experiments / files were you trying to run?
Thanks for the hands-up!
David


Header fields are too long for server to interpret

cannot flash and delete. show "Header fields are too long for server to interpret"

Hello,hase
Thank you very much. I made it

Great! I am closing this issue for now.


Currency

Nice bro! this library will help me a lot.

Thanks. If you have any suggestions for improvement, just let me know.


When .vs folder is included in git checkout, the application wont run (missing config file)

I forked the project and cloned to my local machine, was able to build etc... but not run the project. I was receiving the following error:

The project is being made aware of the web.config file in the .vs\config\applicationhost.config file, which is user-dependent settings. The file is regenerated with the proper values when the .vs folder is deleted. Adding the .vs folder to .gitignore will solve this problem.

Closing. Thanks


Trying TravisCi

@Hambrsoom Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.


console.log

Hi Richard,
On this plugin, there are three references to console.log. Can that be changed to apex.debug.log? i'm happy to do a PR to make the change!

I changed the code to reflect your wishes.


Could we add lscache_runner as user agent?

lscache_runner is a user agent for cache warmers for LSCache from Litespeed servers. Currently if our project uses Crawler-Detect those hits are not treated as bots.
lscache_runner iPhone is another user agent for their mobile crawling.
Documentation: https://docs.litespeedtech.com/lscache/lscps/crawler/
Thanks!

Looks good, create a PR 👍

I have issues with the tests. Should we only leave 'lscache_runner'? Will it cover the other UA?

Yes, just add that one, as it will cover the other, that's why the tests are failing 👍🏻

Thanks!
New PR - https://github.com/JayBizzle/Crawler-Detect/pull/528


[Question] What's the recommended way to differentiate different kind of output paths.

Describe the use-case for this feature
In definition of OutputPathItem, the spec has kind for File and Directory. But in some cases, these two might not be enough.
For example. In Gradle, the source set can have different output paths for class files and resource files:

The spec has two dedicated requests for sources and resources. What's the recommended way to differentiate the output of them?
What do you propose
I'm now using query string of uris:
?kind=sources or ?kind=resources
I've checked to make sure there isn't already a way to support this in the current protocol

[X] I've checked the existing protocol and there isn't a way to do this currently

Maintainer approval (This is for the maintainers)

[ ] Jetbrains
[ ] Metals
[ ] Scala Center

I think there is currently nothing missing. Although there are two dedicated requests for sources and resources, neither of them need any kind of output, as these files and directory are already known through the request. Only the compilation request needs some output location for the produced files. This is the defined output path(s). Unless we also add some compile-resources request, I don't see the need for an resource output path. Can you elaborate on your use case? What you want to achieve?

I'm trying to write an Eclipse project importer to import bsp project.
The Importer will ask build server to get project structures like sources, resources, dependencies, ...
And the output of the source dirs and resource dirs are also needed by the importer.

I wonder what the output of a resources might be, without the mention of any task that can produce additional resources. Also there is no output of a sources. Output only makes sense in combination with a task that can produce something. So, the compile task is supposed to produce something from the sources. But AFAIK there is no task to produce something from the resources.
It might be, that in gradle, configuration of outputs is coupled to the concept of sources, but this is not the case in other tools nor in BSP.
Are you looking into mapping some resource generation task into BSP?

what the output of a resources might be

Let's say there is a Gradle Java project, by default:

the task compileJava will compile the sources, and output the .class file into ./build/classes
the task processResources will copy the resources to the target folder: e.g. ./build/resources. In that case, the target folder can be considered as the output of the processResources task.

It might be, that in gradle, configuration of outputs is coupled to the concept of sources, but this is not the case in other tools nor in BSP.

Yes, I understand that it might not apply to other build tools. So I come here to ask for any recommendation in this case :)

I'm now using query string of uris:
?kind=sources or ?kind=resources

What do you mean by that?


Add support for multiple languages

The SDK currently supports Go for now. We should be able to write analyzers for multiple languages using the SDK.

Closed in favor of #4.


updating JMeter documentation with correct links to images

This PR contains the following documentation updates:

updating links to images to be correctly represented in HelloDev docs
updating information about the latest version of JMeter used in kangal-jmeter docker image

Codecov Report

Merging #167 (9666a39) into master (56ccdcb) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #167   +/-   ##
=======================================
  Coverage   59.80%   59.80%
=======================================
  Files          35       35
  Lines        2458     2458
=======================================
  Hits         1470     1470
  Misses        883      883
  Partials      105      105

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4b4e83c...9666a39. Read the comment docs.


Suggestion: Add an $ErrorView option that displays concise, single-line error information and consider making that the default - default formatting of ErrorRecord

The currently supported $ErrorView values are:

NormalView - the default, "noisy", multi-line display:

> Get-Item /NoSuch
Get-Item : Cannot find path '/NoSuch' because it does not exist.
At line:1 char:1
+ Get-Item /NoSuch
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (/NoSuch:String) [Get-Item], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetItemCommand

CategoryView - a terse, single-line display that doesn't always contain enough information:

> $ErrorView = 'CategoryView'; 1 / 0
NotSpecified: (:) [], RuntimeException

It would be nice to have another option - e.g., ConciseView - that limits output to a single line that contains the immediately relevant information (digging deeper - if needed -  is always possible via $Error[0]):
> $ErrorView = 'ConciseView'; Get-Item /NoSuch   # wishful thinking
Get-Item : Cannot find path '/NoSuch' because it does not exist.

Arguably, this kind of display is the most useful to end users when viewed in the console, so perhaps it should be the default.
As an aside: requiring the $ErrorView values to end in *View seems redundant; related: #3644 and #3645.
Environment data

PowerShell Core v6.0.0-alpha (v6.0.0-alpha.18) on Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64

I agree - there is a ton of room for improvement.
I do think the default view needs to be smart - e.g. the position information is sometimes useless, sometimes not. Maybe some heuristics are needed to decide when to show the error position. For example, if it's a PowerShell parser error, it's probably useful. If it's the entire line, maybe not. But maybe showing the line is useful.
It's easy enough to override the default error view with your own custom ps1xml - it would be good to prototype something, share it and get some feedback before we change the default.

This becomes somewhat tricky because not all exception messages contain the target against which the action is taking place. $Error has all the data that we have at our disposal to construct the message, could you expand more on the different scenarios where errors can occur? Would it be acceptable if CategoryView has more useful data when the message was unhelpful rather than creating a new view?

Wouldn't changing CategoryView be considered a breaking change though? Personally, I find CategoryView useless so I can't imagine anyone relying on it.
I think what most of us are wanting is a view that just gives the Exception Message or maybe the same information but formatted better. This could be the CategoryView or a new View. If it is a new View, I would go with ErrorSummary as the name as it gives a better description of what we are wanting.
Option 1:
CommandName: Get-Item
Exception Message: Cannot find path '/NoSuch' because it does not exist.

Option 2:
Get-Item: Cannot find path '/NoSuch' because it does not exist.

Option 3:
Get-Item: Cannot find path '/NoSuch' because it does not exist. At line:1 char:1

Either one of those gives a simple view of the error that can be acted upon.

@dragonwolf83: I don't think there's a need to change CategoryView, I was thinking of a new view, so, yes, something  like Summary[View] would work.
@JamesWTruher:
Yes, it's a challenge to come up with a concise message that still contains all relevant information for a human to get the gist of the problem at a glance.
It seems to me that CategoryView is more geared toward machine parsing, and it focuses on error properties of secondary interest to a human, so  I think a new view makes more sense.
That said, if CategoryView is enhanced to give concise, meaningful error information, I won't complain. (I truly wonder whether anyone uses CategoryView in its present form at all.)
To elaborate on the motivation:

What's needed is a concise, single-line message that conveys all necessary information for a human to comprehend the gist of the error at a glance; if digging deeper is needed, $Error can be examined.

To a human, the current default view amounts to "scary, noisy, lengthy information overload" that not only makes it hard to quickly understand the error cause, but also crowds out the success output.

I agree with @lzybkr that heuristics and smarts are needed, because different properties are relevant to different errors; I'll see if I can come up with a prototype.

@mklement0
IIRC, CategoryView was indeed targeted at a machine parsing scenario. We reckoned that we would need something along those lines. I don't have any problem in creating a new view, having you come up with a mock-up of what you would like to see would be great, and a prototype would be awesome, but capturing the output for a number of the scenarios would be best. If we start to see patterns we can work on the code to build it. If there's no pattern, that tells us something too.

At the bottom is a script you can run as-is, which redefines the default error view and outputs a few sample errors.
The redefinition stays in effect for the remainder of the session, so you can experiment interactively.
Here are the sample error representations, preceded by the commands that trigger them, as run on a Ubuntu system:
# Expression-statement-terminating error (from an all-PS expression)
      1 / 0
>>>1 / 0<<<: Attempted to divide by zero. (At /tmp/2294.ps1:5 char:7)
------------------------
# Expression-statement-terminating error (from a .NET method call)
      [int]::Parse('not-a-number')
>>>[int]::Parse('not-a-number')<<<: Exception calling "Parse" with "1" argument(s): "Input string was not in a correct format." (At /tmp/2294.ps1:12 char:7)
------------------------
# Non-terminating error
      Get-Item /NoSuchItem
Get-Item: Cannot find path '/NoSuchItem' because it does not exist. (At /tmp/2294.ps1:19 char:7)
------------------------
# Pipeline-statement-terminating error
      Get-Item -NoSuchParam
Get-Item: A parameter cannot be found that matches parameter name 'NoSuchParam'. (At /tmp/2294.ps1:26 char:16)
------------------------
# Indirect parse error, via Invoke-Expression. (If we tried ``1 * 2)`` directly in a script, the whole script would fail to parse.)
      Invoke-Expression '1 * 2)'
PARSE ERROR: Invoke-Expression: 1 * 2)<<< Unexpected token ')' in expression or statement. (At /tmp/2294.ps1:33 char:7)
------------------------
# Remoting (job) error
      Receive-Job -Wait -AutoRemoveJob (Start-Job { Get-Item /NoSuchItem })
[localhost] Get-Item: Cannot find path '/NoSuchItem' because it does not exist. (remoting/job)
------------------------
# Script-terminating error, via Throw
      Remove-Item $PSCommandPath # Since the Throw statement terminates the script
      Throw "Not at $HOME"
STOPPED: >>>Throw "Not at $HOME"<<<: Not at /home/jdoe (At /tmp/2294.ps1:49 char:7)

The overall format is:
[[<computer-name>] ]<immediate-error-source>: <message>[ (<context/position>)]

Things to note:

Each error is deliberately represented as a single line:

Depending on the terminal width and a given error, it may display across more than 1 line.
However,  when redirecting to a file / transcribing, processing is easier if each error can be assumed to occupy just 1 line.

I've tried to anticipate many error situations, but I wouldn't be surprised if I forgot a few.

.PSMessageDetails is currently not being used; should it be, and under what circumstances?

In the context of remoting / jobs, other than determining the originating computer name, I wasn't able to find other useful information to report as context. Is there?

Parse errors and script-terminating errors are called with all-caps prefixes PARSE ERROR:  and STOPPED: , respectively.

Positional information (e.g, At line:1 char:1) is omitted if the error occurred in a command typed directly on the command line (if there is no script context).

Only the first parse error is reported; should an exception to the single-output-line rule be made to show them all?

Some text elements introduced that are currently hard-coded will have to be localized.

Source-code location relating to the questions raised above are marked with  comments containing ??.

Update-DefaultErrorView.ps1

# Define the PS code to embed in the XML below here.
$sb = {

  # Make sure we control the specific strict mode in effect.
  # (The strict-mode setting is inherited from the parent scope.)
  Set-StrictMode -Version 1

  # Save the error record at hand as well as its invocation info.
  $err = $_
  $myInv = $err.InvocationInfo

  function append($s, $new, $sep = ': ') { $s + $(if ($s) { $sep } else { '' }) + $new }

  switch ($ErrorView) {
    'CategoryView' { $err.CategoryInfo.GetMessage(); break }
    Default {  # 'NormalView'

      if ($err.FullyQualifiedErrorId -like 'NativeCommandError*') { # External-utility STDERR output - covers both 'NativeCommandError' and 'NativeCommandErrorMessage'
        # NOTE:
        #    By default, stderr lines output by external utilities are NOT processed here, because they now go straight to the host.
        #    Only if you redirect stder output to the success stream, using 2>&1, are stderr lines processed here - one by one.
        # The *first* stderr line is reported as 'NativeCommandError', and all subsequent lines as 'NativeCommandErrorMessage'
        # Generally, external utilities prefix their error message with their executable name, such as 'FINDSTR: ...', so no addtional
        # context is needed.
        # However, invoking `cmd.exe` builtins with `cmd /c` does NOT (e.g., `cmd /c 'dir /z'`), so, if the error message doesn't start with "<someIdentifier>:",
        # prepend the invoking command's name.
        $msg = $err.Exception.Message
        if ($err.FullyQualifiedErrorId -eq 'NativeCommandError' -and $msg -notmatch '^\w+:') {
          $msg = $myInv.MyCommand.Name + ': ' + $msg
        }
        # Output the message.
        $msg

      } else { # PS error

        # See if the error is a parsing error.
        # !! Apparently, a parsing error that occurs *directly on the command line* results in an $err.Exception
        # !! of type [System.Management.Automation.ParentContainsErrorRecordException]
        # !! By contrast, if you inspect $Error[0] after provoking a parsing error directly on the command line
        # !! you get a [System.Management.Automation.ParseException] *directly*, which *itself* also implements the
        # !! [System.Management.Automation.IContainsErrorRecord] *interface*.
        $isParseError = $err.Exception -is [System.Management.Automation.ParseException] -or $err.Exception -is [System.Management.Automation.ParentContainsErrorRecordException]
        $isRemotingError = $err -is [System.Management.Automation.Runspaces.RemotingErrorRecord] # remoting error, including from jobs
        $isScriptTerminatingError = [bool] $err.Exception.WasThrownFromThrowStatement # $err.CategoryInfo.Category -eq 'OperationStopped'

        # Identify the *immediate* source of the error:
        $source = ''
        if ($isParseError) {
          # Clearly mark parsing errors as such.
          # NOTE: ?? This string will have to be localized.
          $source = 'PARSE ERROR'
          # If $myInv.MyCommand.Name has a value, the implication is that the exception
          # is an *indirectly* triggered parse error, via Invoke-Expression, so we indicate that.
          # Otherwise, we rely on the exception message to provide sufficient information.
          if ($myInv.MyCommand.Name) {
            $source = append $source $myInv.MyCommand.Name
          }
        } else {
          if ($isScriptTerminatingError) {
            # Clearly mark a script-terminating error (triggered with Throw) as such.
            # NOTE: ?? This string will have to be localized.
            $source = 'STOPPED'
          }
          if ($isRemotingError) { # remoting error (including from jobs)
            # Prepend the name of the originating computer.
            $source = append $source ("[{0}]" -f $err.OriginInfo.PSComputerName)
            # Add the command name, if a command caused the error.
            if ($err.CategoryInfo.Activity) { # Contains the command name, if a *command* caused the error.
              $source = $source + ' ' + $err.CategoryInfo.Activity
            }
          } elseif ($myInv.MyCommand.Name) {
            # If a *command* is the error source: this generally evaluates to the resolved underlying cmdlet/function name,
            # even if the invocation used an alias or & or .
            $source = append $source $myInv.MyCommand.Name
          } elseif ($myInv) { # expression such as `1/0` or `& { 1/0 }` or Throw statements
            # $source = append $source $myInv.Line.Trim() # the input expression / statement list
            $source = append $source ('>>>{0}<<<' -f $myInv.Line.Trim()) # the input expression / statement list
          }
        }

        # Identify the larger error context (script / function of origin) and source-code position,
        # if available.
        $context = ''
        if ($myInv.PositionMessage) {
          # Note: We only include a position message (e.g., 'At line:1 char:1') if we have a script filename,
          # as it isn't really useful for a command issued directly on the command line.
          if ($myInv.ScriptName) {
            # Use only the *first line* of  .PositionMessage, which usually provides
            # script path, and the line and column number.
            # The remaining lines are too verbose for our single-line representation.
            $context = ($myInv.PositionMessage -split '\r?\n')[0]
          }
        } elseif ($isRemotingError) {
          # NOTE: ?? This string will have to be localized.
          $context = 'remoting/job' # ?? Is there more information available?
        } else { # ?? Does this ever happen?
          # NOTE: ?? This string will have to be localized.
          $context = 'unknown'
        }

        # Transform the message to a single-line string.
        if ($isParseError) {
          # Parse errors have multi-line messages in the following format:
          #    At ....:<line> char:<col>
          #     + <broken-part-of-statement>
          #     +         ~
          # where the "~" indicates the precise location of the error.
          # We reformat this message to a single line
          $contextPart, $offendingLinePart, $indicatorLine, $reason, $rest = $err.ToString() -split '\r?\n'
          # We omit the "~" line and directly append '<<<' to the offending part of the
          # line and also strip the '+ ' prefix, then append the specific parsing error message.
          # !! There could be MULTIPLE parsing errors, however, we only report the FIRST.
          # ?? Is this a reason to *always* present parsing errors as multi-line errors?
          $msg = '{0}<<< {1}' -f ($offendingLinePart -replace '^[+]\s+'), $reason
          # !! We IGNORE $contextPart, and instead use the $context value we've constructed above,
          # !! because it generally contains the same information and additionally contains the more
          # !! relevant script-context information when the parse error was triggered by a *string* passed to *Invoke-Expression*.
          # !! ($contextPart in that case only contains position information *inside the string* passed to Invoke-Expression)
        } else {
          # All other errors: replace newlines with spaces to output a single line.
          $msg = $err.ToString() -replace '\r?\n', ' '
        }
        # ?? When is $err.PSMessageDetails ever filled and does it matter?

        # Output the synthesized message as a *single-line* string.
        # Note that no effort is made to word-wrap overly long lines:
        #  * Hopefully, most terminals are wide enough to fit most errors on 1 line
        #  * When redirecting to a file / transcribing, processing is easier if every
        #    error can be assumed to occupy just 1 line.
        $combinedMsg = '{0}: {1}' -f $source, $msg
        if ($context) {
          $combinedMsg += ' ({0})' -f $context
        }
        $combinedMsg
      }

    }
  }

}

# Create a *.ps1xml file on the fly, using a fixed-per-session file path
# based on the process ID. This is helpful, because PS remembers previously
# loaded *.ps1xml files and tries to reload them, so if we used a different
# path every time (and deleted the file after), every subsequent
# Update-FormatData call would complain about missing files.
@"
<Configuration>
<ViewDefinitions>
      <View>
          <Name>ErrorInstance</Name>
          <OutOfBand />
          <ViewSelectedBy>
              <TypeName>System.Management.Automation.ErrorRecord</TypeName>
          </ViewSelectedBy>
          <CustomControl>
              <CustomEntries>
                  <CustomEntry>
                     <CustomItem>
                          <ExpressionBinding>
                              <ScriptBlock>
                                <![CDATA[
$sb
                                ]]>
                              </ScriptBlock>
                          </ExpressionBinding>
                      </CustomItem>
                  </CustomEntry>
              </CustomEntries>
          </CustomControl>
      </View>
</ViewDefinitions>
</Configuration>
"@ > ($tmpFile = [io.path]::GetTempPath() + "$PID.ps1xml")

# Load the format data via -PrependPath, which *preempts* preloaded definitions.
Update-FormatData -PrependPath $tmpFile

# Clean up.
Remove-Item $tmpFile

# === Create a test script that provokes various errors

$sbs = {
      # Expression-statement-terminating error (from an all-PS expression)
      1 / 0
    },
    {
      # Expression-statement-terminating error (from a .NET method call)
      [int]::Parse('not-a-number')
    },
    {
      # Non-terminating error
      Get-Item /NoSuchItem
    },
    {
      # Pipeline-statement-terminating error
      Get-Item -NoSuchParam
    },
    {
      # Indirect parse error, via Invoke-Expression. (If we tried ``1 * 2)`` directly in a script, the whole script would fail to parse.)
      Invoke-Expression '1 * 2)'
    },
    {
      # Remoting (job) error
      Receive-Job -Wait -AutoRemoveJob (Start-Job { Get-Item /NoSuchItem })
    },
    {
      # Script-terminating error, via Throw
      Remove-Item $PSCommandPath # Since the Throw statement below terminates this temp. script, we self-delete it first here.
      Throw "Not at $HOME"
    }
    # !! Even the current 'NormalView' view makes no attempt to identify
    # !! the *function* inside a script in which the error occurred.
    # {
    #   # Error inside a function
    #   Function Foo { Get-Item /NoSuchItem }; Foo
    # }

$tmpScript = [io.path]::GetTempPath() + "$PID.ps1"

$sbs | % {
  @"
  '$(($_.ToString() -replace "'", "''").Trim())'
  $($_.Tostring())
  "------------------------"
"@
} > $tmpScript

# Write-Verbose -Verbose $tmpScript

# Invoke the temp. script to show how the errors are formatted.
# !! Do not use try / finally here, because the first terminating error
# !! would trigger the finally block.
& $tmpScript

# Since the Throw statement inside the temp. script aborts this script too,
# we never get here.
# Remove-Item $tmpScript

To help with experimenting, find helper function out-ErrorDetails at the bottom, which visualizes a given error comprehensively, though not quite as detailed as the Resolve-ErrorRecord PSCX function that @rkeithhill mentions.
By default it targets the most recent error.
E.g.:
gi /NoSuch; out-ErrorDetails

yields the following:
Message: Cannot find path '/nosuch' because it does not exist.

CategoryInfo:
	Category   : ObjectNotFound
	Activity   : Get-Item
	Reason     : ItemNotFoundException
	TargetName : /nosuch
	TargetType : String

Exception:
	Type: System.Management.Automation.ItemNotFoundException

InvocationInfo:

	MyCommand             : Get-Item
	BoundParameters       : {}
	UnboundArguments      : {}
	ScriptLineNumber      : 1
	OffsetInLine          : 1
	HistoryId             : 86
	ScriptName            :
	Line                  : gi /nosuch
	PositionMessage       : At line:1 char:1
	                        + gi /nosuch
	                        + ~~~~~~~~~~
	PSScriptRoot          :
	PSCommandPath         :
	InvocationName        : gi
	PipelineLength        : 0
	PipelinePosition      : 0
	ExpectingInput        : False
	CommandOrigin         : Internal
	DisplayScriptPosition :

Stack traces:
  * Script:
	at <ScriptBlock>, <No file>: line 1
  * Exception:
	at System.Management.Automation.LocationGlobber.ExpandMshGlobPath(String path, Boolean allowNonexistingPaths, PSDriveInfo drive, ContainerCmdletProvider provider, CmdletProviderContext context)
	at System.Management.Automation.LocationGlobber.ResolveDriveQualifiedPath(String path, CmdletProviderContext context, Boolean allowNonexistingPaths, CmdletProvider& providerInstance)
	at System.Management.Automation.LocationGlobber.GetGlobbedMonadPathsFromMonadPath(String path, Boolean allowNonexistingPaths, CmdletProviderContext context, CmdletProvider& providerInstance)
	at System.Management.Automation.LocationGlobber.GetGlobbedProviderPathsFromMonadPath(String path, Boolean allowNonexistingPaths, CmdletProviderContext context, ProviderInfo& provider, CmdletProvider& providerInstance)
	at System.Management.Automation.SessionStateInternal.GetItem(String[] paths, CmdletProviderContext context)
	at System.Management.Automation.ItemCmdletProviderIntrinsics.Get(String path, CmdletProviderContext context)
	at Microsoft.PowerShell.Commands.GetItemCommand.ProcessRecord()

Function out-ErrorDetails
# Print the specified error in detailed form - defaults to the most recent error.
# You may also specify an *index* into the $Errors array.
# Note: By default, if $Error[0] is [Management.Automation.ActionPreferenceStopException] rather than [Management.Automation.ErrorRecord],
#       $Error[1] is printed, because [Management.Automation.ActionPreferenceStopException] is a *wrapper* error that indicates that execution was
#       aborted due to -ErrorAction Stop or $ErrorActionPreference = 'Stop'.
function out-ErrorDetails([object] $eo = $Error[0]) {

  # Skip the escalation-to-script-terminating-error wrapper, if present.
  if ($eo -eq $Error[0] -and $eo -is [Management.Automation.ActionPreferenceStopException]) {
    Write-Warning "Skipping escalation-to-script-terminating-error wrapper error, inspecting $Error[1] instead."
    $eo = $Error[1]
  }
  if ($eo -is [int]) { $eo = $Error[$eo] } # if a mere index was specified, assume it refers to the $Errors array list
  if (-not $eo) { Write-Warning "No error object was passed, or no error has yet occurred in this session."; return }
  Write-Host -fore yellow @"
Message: $($eo.ToString())
$(if ($eo.OriginInfo) {
"  Origin: $($eo.OriginInfo.PSComputerName) (runspace ID: $($eo.OriginInfo.RunSpaceId))"
# Note: There's also an InstanceId property (PSv3+), but it is usually '00000000-0000-0000-0000-000000000000'. ?? what does it refer to?
# "global identifier of the origin of the error record" - https://msdn.microsoft.com/en-us/library/system.management.automation.remoting.origininfo(v=vs.85).aspx?cs-save-lang=1&cs-lang=csharp#code-snippet-1
})
CategoryInfo: $($eo.CategoryInfo | Format-List * | out-string -stream | % { if ($_) { ("`n`t" + $_) } })

$(if ($eo.Exception) {
"Exception:
`tType: $($eo.Exception.GetType().FullName)"
})
$(if ($eo.Exception -and $eo.Exception.InnerException) {
"`tInner exception:
`t  Type: $($eo.Exception.InnerException.GetType().FullName)
`t  Message: $($eo.Exception.InnerException.Message)"
})
$(if ($eo.PSMessageDetails) {
"  PSMessageDetails:
     $($eo.PSMessageDetails | Out-string -stream | % { if ($_) { ("`n`t" + $_) } })"
})
$(if ($eo.InvocationInfo) {
"InvocationInfo:
     $($eo.InvocationInfo | Out-string -stream | % { if ($_) { ("`n`t" + $_) } })"
})

Stack traces:
  * Script:
$("`t" + $eo.ScriptStackTrace -replace '\r?\n', "`n`t")
  * Exception:
$("`t" + ($eo.Exception.StackTrace -replace '^\s+' -replace '\r?\n\s+', "`n`t"))
"@

}

I would also suggest that non-terminating errors have a different color (magenta?) than terminating errors

@SteveL-MSFT:
That's a great idea, but - given just a [System.Management.Automation.ErrorRecord], as when formatting for output - we currently have no way (that I know of) of determining whether a given error was terminating or not.
If we clear that hurdle, we also need to decided whether we want to apply that coloring situationally: e.g., if a non-terminating error is promoted to (script)-terminating via -EA Stop, for instance, should it then print in red, not magenta?
Do we also need to color-distinguish between statement-terminating and script-terminating errors? (Though the latter are more easily spotted coming last in the output.)

We can add additional properties to the ErrorRecord type to differentiate terminating vs non-terminating.  For script vs statement, it seems the simplest is to output:
Encountered statement-terminating error:
...

@SteveL-MSFT:
Re adding a new property: I've created a new issue: #4781.
Re script vs statement:
That's a little verbose for the single-line representation we're trying to create here.
Perhaps color coding alone will be enough?
As a wistful aside:
In a world without backward-compatibility constraints, ideally we wouldn't have to deal with the distinction between statement-terminating and script-terminating at all, because there should only be one type of terminating error: the script-terminating type. (If only the documentation were correct...):
The nature of the current statement-terminating errors is so severe that it makes no sense to let scripts continue by default.

For the one-line, I think the first word should be ERROR:. That is consistent with how Warning and Verbose outputs their text.
A key scenario that needs to be considered is logging the output to a file. The output should be easy to parse and won't have color coding to help. Using ERROR first aligns with that scenario.
Statement vs Non-Termination can be differentiated by one of the following:
ERROR:   Type: Non-Terminating;  Message:
ERROR:   Severity: Non-Terminating;  Message:
ERROR:   Non-Terminating;  Message:
Severity is what SQL Server calls the these types of errors and it makes the most sense. It would probably make the documentation clearer as well because a non-terminating error is not as severe as a terminating error which stops the script.

@dragonwolf83:
Good points re symmetry with VERBOSE: and WARNING: and parsing logs (selective coloring and wording aren't mutually exclusive, of course).
Again, though, I'm worried about verbosity for single-line representations:
There's a tension between:

favoring human eyeballs for at-a-glance comprehension - for which I'd leave out labels such as Type: or Message: as part of the output (except for the ERROR: prefix)  and

suitability for machine parsing.

Even though CategoryView is probably insufficient in its current form, its purpose is to provide the latter, according to @JamesWTruher.
I'd say the default view should favor human eyeballs, with opt-in for strict machine parsing.

FWIW, it seems that currently $errorRecord.Exception.WasThrownFromThrowStatement is insufficient to detect the script-terminating errors described in PowerShell/PowerShell-Docs#1583.  For example,
try
{
    throw [System.Exception]::new('message')
}
catch
{
    [bool]$_.Exception.WasThrownFromThrowStatement
}

outputs $false.

@alx9r:
You've found an edge case: It works as intended if you throw anything other than a [System.Exception] (or derived) instance, which PowerShell conveniently lets you do.
The only exception type you can throw and still have it reflected in .Exception.WasThrownFromThrowStatement is [System.Management.Automation.RuntimeException], because that is what PowerShell uses _internally_ to wrap whatever (non-exception) you pass to throw`.
Thus, the following 2 commands are equivalent and both output $True:
try { throw 'message' } catch { $_.Exception.WasThrownFromThrowStatement }
try { throw [System.Management.Automation.RuntimeException]::new('message') } catch { $_.Exception.WasThrownFromThrowStatement }

I agree that throwing an actual exception-type instance should also be reflected in .Exception.WasThrownFromThrowStatement, however; not sure if there are technical challenges; I suggest you open a new issue.

Thanks @mklement0.  I opened issue #6288.

It sure would be nice if some form of simplified error output makes it into 6.2.  :-)

@rkeithhill I agree, but would need some proposals that we can discuss.  I played with @mklement0's prototype and made some changes to leverage VT100 escape sequences: https://gist.github.com/SteveL-MSFT/edf969ee676206a47d520a9032dcf6e3

Something I would really love to see is some sort of indication as to what type of error is being shown. Since terminating errors behave pretty differently to non-terminating errors (ignoring -ErrorAction common parameter, etc) I think it would be valuable if we could distinguish the type of error at a glance.

Can we make this a lot easier to extend by just allowing anyone to write a Format-ErrorSimple and set $ErrorView = "Simple" -- basically by looking for matching commands in the formatter, and falling back to the current NormalView?

OK, I had a poke at this, just to provide another approach.
function ConvertTo-SimpleErrorView {
    [CmdletBinding()]
    param(
        [System.Management.Automation.ErrorRecord]
        $InputObject
    )

    if ($InputObject.FullyQualifiedErrorId -eq "NativeCommandErrorMessage") {
        $InputObject.Exception.Message
    } else {
        $myinv = $InputObject.InvocationInfo
        if ($myinv -and ($myinv.MyCommand -or ($InputObject.CategoryInfo.Category -ne 'ParserError'))) {
            # rip off lines that say "At line:1 char:1" (hopefully, in a language agnostic way)
            $posmsg  = $myinv.PositionMessage -replace "^At line:1 .*[\r\n]+"
            # rip off the underline and instead, put >>>markers<<< around the important bit
            # we could, instead, set the background to a highlight color?
            $pattern = $posmsg -split "[\r\n]+" -match "\+( +~+)\s*" -replace '(~+)', '($1)' -replace '( +)','($1)' -replace '~| ','.'
            $posmsg  = $posmsg -replace '[\r\n]+\+ +~+'
            if ($pattern) {
                $posmsg  = $posmsg -replace "\+$pattern", '+ $1>>>$2<<<'
            }
        } else {
            $posmsg = ""
        }

        if ($posmsg -ne "") {
            $posmsg = "`n" + $posmsg
        }

        if ( & { Set-StrictMode -Version 1; $InputObject.PSMessageDetails } ) {
            $posmsg = " : " + $InputObject.PSMessageDetails + $posmsg
        }

        $indent = 4
        $width = $host.UI.RawUI.BufferSize.Width - $indent - 2

        $originInfo = & { Set-StrictMode -Version 1; $InputObject.OriginInfo }
        if (($null -ne $originInfo) -and ($null -ne $originInfo.PSComputerName)) {
            $indentString = "+ PSComputerName        : " + $originInfo.PSComputerName
            $posmsg += "`n"
            foreach ($line in @($indentString -split "(.{$width})")) {
                if ($line) {
                    $posmsg += (" " * $indent + $line)
                }
            }
        }

        if (!$InputObject.ErrorDetails -or !$InputObject.ErrorDetails.Message) {
            $InputObject.Exception.Message + $posmsg + "`n "
        } else {
            $InputObject.ErrorDetails.Message + $posmsg
        }
    }
}

And then I made a quick demo module, setting the ErrorInstance view to call named functions ...
<ExpressionBinding>
  <ScriptBlock>
    <![CDATA[
      if ($formatter = Get-Command "ConvertTo-$($global:ErrorView -replace "View")ErrorView" -ListImported -ErrorAction Ignore -ParameterName InputObject -ParameterType [System.Management.Automation.ErrorRecord]) {
        &@($formatter)[0] $_
      } else {
        ConvertTo-NormalErrorView $_
      }
    ]]>
  </ScriptBlock>
</ExpressionBinding>

And of course, copying the existing Normal and Category views into ConvertTo-NormalErrorView and ConvertTo-CategoryErrorView ...
And then I wrote a hack of a Format-Error function so that I can switch between views without messing with the preference variable or having to do  | Format-List * -Force ...
I'd definitely like to see something like this in core, so we can easily customize error formatting in our profiles without writing format files...
Here's my attempt (and it works down to PowerShell 5.x, at least) as a mini module called ErrorView

While we're at it, how about making error text white characters on red background. That would be so much easier to read than dark red on black, especially on a projector.

Why not let the user pass an { Scriptblock } or Function to self define the error formatting and output?
Like in https://github.com/PowerShell/PowerShell/issues/6010

While a think a new error view could be helpful (to the point where I had implemented one in a module many years ago, but then I lost that module due to clumsy fingers on my keyboard), I prefer heading towards something smarter. @lzybkr talked about a smarter default view here. That's where my line of thinking tends to go as well.
For example, I was thinking about errors today, in particular about how they are presented. In some cases, the text we present is not as clear and straightforward as it could be. In some cases, we show a bunch of extra detail that is not necessary (position, etc.). In all cases, the error is red. We can do better.
How do we identify when errors should be presented differently?
For PowerShell use errors (an error that occurs from ad-hoc PowerShell use and is clearly an error that came from incorrect use of something in PowerShell, e.g. invoking a command ad-hoc and parameter binding/validation fails, trying to invoke a command that does not exist, and other parameter binder or argument validator errors that occur), or other user errors (permission denied when trying to do something, unable to find a resource because it does not exist, etc., still done through ad-hoc command invocation), position details don't matter, other than perhaps the marker indicating where the error came from in the command that was invoked. For errors that come from a script or module or remote invocation of a job, the script/file position matters.
Beyond determining whether or not position should be shown, based on whether or not the command came from ad-hoc use vs running a script, module, job, etc., color matters, to the point where some presenters, myself included, suggest people change their error color so that it's more presentable and easier to read. That general change aside, it would be beneficial for us to show different colors for use errors vs resource not found errors vs access denied errors, or other errors.
While this may be over-simplifying things, looking through the System.Management.Automation.ErrorCategory enumerations, I would group SyntaxError and ParserError together with errors that occur due to parameter binding/validation as one color, ObjectNotFound as another color by itself (this is so common in ad-hoc use, and being able to look through errors and identify when something simply was not found and resulted in an error could help solve many problems when working out errors in scripts), and the rest I would put in the "default" error color.
This approach keeps the number of colors small enough to be manageable (3), and simplifies display of ad-hoc errors vs script errors so that users can work with error messages more easily and have a better chance at knowing at a glance where something came from and what happened.

@whereisaaron: There are diverse needs to consider. Making error messages simple for end users is one need. Making error messages more detailed for scripters is another. Doing so while at considering tool builders is important. It doesn't mean that is what will be built, but the entire discussion is worthwhile having.


Isochrone center cannot be set as "destination"

According to ORS isochropne API (https://openrouteservice.org/dev/#/api-docs/v2/isochrones/{profile}/post) it is possible to use the optional field location_type to specify that the points in the locations field are destinations (that is, the output isochrone is the set of points from which we can reach the location in less than X minutes or meters). However the default is start (that is, the output is the set of points reachable in less than X minutes, starting from the location). There is no GUI widget (or any other way ?) to specify that the locations should be destinations.
Expectation is that there should be a way to specify which type of location is desired.

Hey,
yes, the QGIS plugin is unfortunately not feature complete in regard to the API, and it is not something we're currently working on.
We'll happily review a pull request implementing this, though :)
Best regards


Flow breaks when constant name changes in design_top.json

When Jeff changes the name of the const from "const" to "const_186" the flow breaks.  I (steveri) added a hack in the travis script to undo the name, but this is of course not the right fix.  I suspect the problem is either in the mapper or in one of the pnr scripts, respectively.  You can see source for working and non-working design_top.json in builds 145 (https://travis-ci.org/StanfordAHA/CGRAFlow/builds/219574814) and 146 (https://travis-ci.org/StanfordAHA/CGRAFlow/builds/219898992) respectively---the only difference is one line where the working version says "const" and the nonworking version says "const_186"
diff design_top_145.json design_top_146.json
< "const"

"const_186"

Note that "const_186" is simply a name of the constant being using. Ideally subsequent scripts would not rely on the instance name for parsing.

Yes; to be clear, this is exactly what we want to fix.  Subsequent-script authors please verify that you do not rely on this name to always/only be "const"
On April 8, 2017 4:51:23 PM PDT, Jeff Setter<EMAIL_ADDRESS>wrote:

Note that "const_186" is simply a name of the constant being using.
Ideally subsequent scripts would not rely on the instance name for
parsing.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Remember Ross wrote the mapper, not me... I looked at his code, and he does hardcode a "const" in a few places, but it wasn't obvious to me that that was the problem. It could be. IMO @rdaly525  and @cdonovick should update their code to error out if the input doesn't match what is expected. As of right now, it looks like their code is silently failing, which makes this hard to track down.
I would maybe also recommend removing the workaround... keeping the build working is a good idea, but IMO this is a real problem we should track down. But thanks for doing this Steven!
Is everyone getting these alerts?

It's possible btw that this has nothing to do with Jeff's change, remember, we pull down all the repos each time so it could have been another change.

I tried the flow twice in quick succession, with the only difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure that
new change is causing the problem downstream.  Also if you look at
past builds that succeed, all use "const" as the constant name.

If you want to do the experiment yourself, simply uncomment my
travis script hack...

  # FIXME/TODO oops Jeff's recent change broke the flow.
  # This temporary hack undoes the change and lets the
  script succeed,
    # but this is not a reasonable fix going forward!
  - mv build/design_top.json /tmp/design_top.json
  - sed 's/const_186/const/' /tmp/design_top.json >
  build/design_top.json
  - grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...

SR

PS FWIW it looks to me like the mapper script more or less passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where things
fall apart...

On 4/8/2017 5:31 PM, jameshegarty
  wrote:

  It's possible btw that this has nothing to do with Jeff's
    change, remember, we pull down all the repos each time so it
    could have been another change.
  —
    You are receiving this because you were assigned.
    Reply to this email directly, view
      it on GitHub, or mute
      the thread.

  {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/StanfordAHA/CGRAFlow","title":"StanfordAHA/CGRAFlow","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in #3: It's possible btw that this has nothing to do with Jeff's change, remember, we pull down all the repos each time so it could have been another change."}],"action":{"name":"View Issue","url":"https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}

If changing the name of the constant changes value of
instance.get_config_value('op') from 'const' to something else then it will
break my code.  However, as the API is now there is no way for me to work
around that.
Caleb
On Apr 8, 2017 7:49 PM, "steveri"<EMAIL_ADDRESS>wrote:

I tried the flow twice in quick succession, with the only difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure that
new change is causing the problem downstream.  Also if you look at
past builds that succeed, all use "const" as the constant name.
If you want to do the experiment yourself, simply uncomment my
travis script hack...
FIXME/TODO oops Jeff's recent change broke the flow.
This temporary hack undoes the change and lets the
script succeed,
but this is not a reasonable fix going forward!

mv build/design_top.json /tmp/design_top.json
sed 's/const_186/const/' /tmp/design_top.json >
build/design_top.json
grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...
SR
PS FWIW it looks to me like the mapper script more or less passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where things
fall apart...
On 4/8/2017 5:31 PM, jameshegarty
wrote:
It's possible btw that this has nothing to do with Jeff's
change, remember, we pull down all the repos each time so it
could have been another change.
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/StanfordAHA/CGRAFlow","title":
"StanfordAHA/CGRAFlow","subtitle":"GitHub repository","main_image_url":"
https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-
11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
cloud.githubusercontent.com/assets/143418/15842166/
7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in
GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in #3:
It's possible btw that this has nothing to do with Jeff's change, remember,
we pull down all the repos each time so it could have been another
change."}],"action":{"name":"View Issue","url":"https://github.
com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292759941,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF13dCCYgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU
.

It appears to be producing this (see build log 149 https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):
instances": {
"const_186": {
"config": {
"constvalue": 2,
"op": "const"
On April 8, 2017 9:10:43 PM PDT, Caleb Donovick<EMAIL_ADDRESS>wrote:

If changing the name of the constant changes value of
instance.get_config_value('op') from 'const' to something else then it
will
break my code.  However, as the API is now there is no way for me to
work
around that.
Caleb
On Apr 8, 2017 7:49 PM, "steveri"<EMAIL_ADDRESS>wrote:

I tried the flow twice in quick succession, with the only difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure that
new change is causing the problem downstream.  Also if you look at
past builds that succeed, all use "const" as the constant name.
If you want to do the experiment yourself, simply uncomment my
travis script hack...
FIXME/TODO oops Jeff's recent change broke the flow.
This temporary hack undoes the change and lets the
script succeed,
but this is not a reasonable fix going forward!

mv build/design_top.json /tmp/design_top.json
sed 's/const_186/const/' /tmp/design_top.json >
build/design_top.json
grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...
SR
PS FWIW it looks to me like the mapper script more or less passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where things
fall apart...
On 4/8/2017 5:31 PM, jameshegarty
wrote:
It's possible btw that this has nothing to do with Jeff's
change, remember, we pull down all the repos each time so it
could have been another change.
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/StanfordAHA/CGRAFlow","title":
"StanfordAHA/CGRAFlow","subtitle":"GitHub
repository","main_image_url":"

https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-

11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
cloud.githubusercontent.com/assets/143418/15842166/
7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in
GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in
#3:
It's possible btw that this has nothing to do with Jeff's change,
remember,
we pull down all the repos each time so it could have been another
change."}],"action":{"name":"View Issue","url":"https://github.
com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292759941,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AF13dCCYgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Oh and also this, earlier in the same file
        "instances": {
          "const_186": {
            "config": {
              "value": 2
            },

On April 8, 2017 9:41:47 PM PDT, Stephen<EMAIL_ADDRESS>wrote:

It appears to be producing this (see build log 149
https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):
instances": {
"const_186": {
"config": {
"constvalue": 2,
"op": "const"
On April 8, 2017 9:10:43 PM PDT, Caleb Donovick
<EMAIL_ADDRESS>wrote:

If changing the name of the constant changes value of
instance.get_config_value('op') from 'const' to something else then it
will
break my code.  However, as the API is now there is no way for me to
work
around that.
Caleb
On Apr 8, 2017 7:49 PM, "steveri"<EMAIL_ADDRESS>wrote:

I tried the flow twice in quick succession, with the only difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure that
new change is causing the problem downstream.  Also if you look at
past builds that succeed, all use "const" as the constant name.
If you want to do the experiment yourself, simply uncomment my
travis script hack...
FIXME/TODO oops Jeff's recent change broke the flow.
This temporary hack undoes the change and lets the
script succeed,
but this is not a reasonable fix going forward!

mv build/design_top.json /tmp/design_top.json
sed 's/const_186/const/' /tmp/design_top.json >
build/design_top.json
grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...
SR
PS FWIW it looks to me like the mapper script more or less passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where things
fall apart...
On 4/8/2017 5:31 PM, jameshegarty
wrote:
It's possible btw that this has nothing to do with Jeff's
change, remember, we pull down all the repos each time so it
could have been another change.
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/StanfordAHA/CGRAFlow","title":
"StanfordAHA/CGRAFlow","subtitle":"GitHub
repository","main_image_url":"

https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-

11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
cloud.githubusercontent.com/assets/143418/15842166/
7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in
GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in
#3:
It's possible btw that this has nothing to do with Jeff's change,
remember,
we pull down all the repos each time so it could have been another
change."}],"action":{"name":"View Issue","url":"https://github.
com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292759941,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AF13dCCYgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

The latter of the two ?might? break my code but I'm not completely up on
COREIR format.  Looked 150 like it broke because missed named filles.
Caleb
On Apr 8, 2017 9:47 PM, "steveri"<EMAIL_ADDRESS>wrote:

Oh and also this, earlier in the same file
"instances": {
"const_186": {
"config": {
"value": 2
},
On April 8, 2017 9:41:47 PM PDT, Stephen<EMAIL_ADDRESS>wrote:

It appears to be producing this (see build log 149
https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):
instances": {
"const_186": {
"config": {
"constvalue": 2,
"op": "const"
On April 8, 2017 9:10:43 PM PDT, Caleb Donovick
<EMAIL_ADDRESS>wrote:

If changing the name of the constant changes value of
instance.get_config_value('op') from 'const' to something else then it
will
break my code. However, as the API is now there is no way for me to
work
around that.
Caleb
On Apr 8, 2017 7:49 PM, "steveri"<EMAIL_ADDRESS>wrote:

I tried the flow twice in quick succession, with the only difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure that
new change is causing the problem downstream. Also if you look at
past builds that succeed, all use "const" as the constant name.
If you want to do the experiment yourself, simply uncomment my
travis script hack...
FIXME/TODO oops Jeff's recent change broke the flow.
This temporary hack undoes the change and lets the
script succeed,
but this is not a reasonable fix going forward!

mv build/design_top.json /tmp/design_top.json
sed 's/const_186/const/' /tmp/design_top.json >
build/design_top.json
grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...
SR
PS FWIW it looks to me like the mapper script more or less passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where things
fall apart...
On 4/8/2017 5:31 PM, jameshegarty
wrote:
It's possible btw that this has nothing to do with Jeff's
change, remember, we pull down all the repos each time so it
could have been another change.
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/StanfordAHA/CGRAFlow","title":
"StanfordAHA/CGRAFlow","subtitle":"GitHub
repository","main_image_url":"

https://cloud.githubusercontent.com/assets/
143418/17495839/a5054eac-5d88-

11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
cloud.githubusercontent.com/assets/143418/15842166/
7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in
GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in
#3:
It's possible btw that this has nothing to do with Jeff's change,
remember,
we pull down all the repos each time so it could have been another
change."}],"action":{"name":"View Issue","url":"https://github.
com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292759941
,

or mute the thread

<https://github.com/notifications/unsubscribe-auth/
AF13dCCYgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU>

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292763903,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF13dFqW-N6Tc6EkA_WEHjpajPWCEXioks5ruGLDgaJpZM4M33iU
.

I'll look at all of it tomorrow, trying to read Travis logs on a phone is
suboptimal.
On Apr 8, 2017 9:49 PM, "Caleb Donovick"<EMAIL_ADDRESS>wrote:

The latter of the two ?might? break my code but I'm not completely up on
COREIR format.  Looked 150 like it broke because missed named filles.
Caleb
On Apr 8, 2017 9:47 PM, "steveri"<EMAIL_ADDRESS>wrote:

Oh and also this, earlier in the same file
"instances": {
"const_186": {
"config": {
"value": 2
},
On April 8, 2017 9:41:47 PM PDT, Stephen<EMAIL_ADDRESS>wrote:

It appears to be producing this (see build log 149
https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):
instances": {
"const_186": {
"config": {
"constvalue": 2,
"op": "const"
On April 8, 2017 9:10:43 PM PDT, Caleb Donovick
<EMAIL_ADDRESS>wrote:

If changing the name of the constant changes value of
instance.get_config_value('op') from 'const' to something else then it
will
break my code. However, as the API is now there is no way for me to
work
around that.
Caleb
On Apr 8, 2017 7:49 PM, "steveri"<EMAIL_ADDRESS>wrote:

I tried the flow twice in quick succession, with the only difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure that
new change is causing the problem downstream. Also if you look at
past builds that succeed, all use "const" as the constant name.
If you want to do the experiment yourself, simply uncomment my
travis script hack...
FIXME/TODO oops Jeff's recent change broke the flow.
This temporary hack undoes the change and lets the
script succeed,
but this is not a reasonable fix going forward!

mv build/design_top.json /tmp/design_top.json
sed 's/const_186/const/' /tmp/design_top.json >
build/design_top.json
grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...
SR
PS FWIW it looks to me like the mapper script more or less passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where things
fall apart...
On 4/8/2017 5:31 PM, jameshegarty
wrote:
It's possible btw that this has nothing to do with Jeff's
change, remember, we pull down all the repos each time so it
could have been another change.
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/StanfordAHA/CGRAFlow","title":
"StanfordAHA/CGRAFlow","subtitle":"GitHub
repository","main_image_url":"

https://cloud.githubusercontent.com/assets/143418/
17495839/a5054eac-5d88-

11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
cloud.githubusercontent.com/assets/143418/15842166/
7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in
GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in
#3:
It's possible btw that this has nothing to do with Jeff's change,
remember,
we pull down all the repos each time so it could have been another
change."}],"action":{"name":"View Issue","url":"https://github.
com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecom
ment-292759941>,

or mute the thread

<https://github.com/notifications/unsubscribe-auth/AF13dCC
YgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU>

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292763903,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF13dFqW-N6Tc6EkA_WEHjpajPWCEXioks5ruGLDgaJpZM4M33iU
.

Yes dont look at build 150 look at 149 instead.
On April 8, 2017 9:50:00 PM PDT, Caleb Donovick<EMAIL_ADDRESS>wrote:

The latter of the two ?might? break my code but I'm not completely up
on
COREIR format.  Looked 150 like it broke because missed named filles.
Caleb
On Apr 8, 2017 9:47 PM, "steveri"<EMAIL_ADDRESS>wrote:

Oh and also this, earlier in the same file
"instances": {
"const_186": {
"config": {
"value": 2
},
On April 8, 2017 9:41:47 PM PDT, Stephen<EMAIL_ADDRESS>wrote:

It appears to be producing this (see build log 149
https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):
instances": {
"const_186": {
"config": {
"constvalue": 2,
"op": "const"
On April 8, 2017 9:10:43 PM PDT, Caleb Donovick
<EMAIL_ADDRESS>wrote:

If changing the name of the constant changes value of
instance.get_config_value('op') from 'const' to something else then
it
will
break my code. However, as the API is now there is no way for me to
work
around that.
Caleb
On Apr 8, 2017 7:49 PM, "steveri"<EMAIL_ADDRESS>wrote:

I tried the flow twice in quick succession, with the only
difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure that
new change is causing the problem downstream. Also if you look at
past builds that succeed, all use "const" as the constant name.
If you want to do the experiment yourself, simply uncomment my
travis script hack...
FIXME/TODO oops Jeff's recent change broke the flow.
This temporary hack undoes the change and lets the
script succeed,
but this is not a reasonable fix going forward!

mv build/design_top.json /tmp/design_top.json
sed 's/const_186/const/' /tmp/design_top.json >
build/design_top.json
grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...
SR
PS FWIW it looks to me like the mapper script more or less passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where
things
fall apart...
On 4/8/2017 5:31 PM, jameshegarty
wrote:
It's possible btw that this has nothing to do with Jeff's
change, remember, we pull down all the repos each time so it
could have been another change.
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/StanfordAHA/CGRAFlow","title":
"StanfordAHA/CGRAFlow","subtitle":"GitHub
repository","main_image_url":"

https://cloud.githubusercontent.com/assets/
143418/17495839/a5054eac-5d88-

11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
cloud.githubusercontent.com/assets/143418/15842166/
7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open
in
GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty
in
#3:
It's possible btw that this has nothing to do with Jeff's change,
remember,
we pull down all the repos each time so it could have been
another
change."}],"action":{"name":"View Issue","url":"https://github.
com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292759941
,

or mute the thread

<https://github.com/notifications/unsubscribe-auth/
AF13dCCYgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU>

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292763903,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AF13dFqW-N6Tc6EkA_WEHjpajPWCEXioks5ruGLDgaJpZM4M33iU

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

  :)
Certainly doesnt have to be fixed tonight.
SR
On April 8, 2017 9:51:37 PM PDT, Caleb Donovick<EMAIL_ADDRESS>wrote:

I'll look at all of it tomorrow, trying to read Travis logs on a phone
is
suboptimal.
On Apr 8, 2017 9:49 PM, "Caleb Donovick"<EMAIL_ADDRESS>wrote:

The latter of the two ?might? break my code but I'm not completely up
on
COREIR format.  Looked 150 like it broke because missed named filles.
Caleb
On Apr 8, 2017 9:47 PM, "steveri"<EMAIL_ADDRESS>wrote:

Oh and also this, earlier in the same file
"instances": {
"const_186": {
"config": {
"value": 2
},
On April 8, 2017 9:41:47 PM PDT, Stephen<EMAIL_ADDRESS>wrote:

It appears to be producing this (see build log 149
https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):
instances": {
"const_186": {
"config": {
"constvalue": 2,
"op": "const"
On April 8, 2017 9:10:43 PM PDT, Caleb Donovick
<EMAIL_ADDRESS>wrote:

If changing the name of the constant changes value of
instance.get_config_value('op') from 'const' to something else
then it
will
break my code. However, as the API is now there is no way for me
to
work
around that.
Caleb
On Apr 8, 2017 7:49 PM, "steveri"<EMAIL_ADDRESS>wrote:

I tried the flow twice in quick succession, with the only
difference
being constant name "const_186" (build 150, failed) vs. "const"
(Build 151, passed) in "design_top.json", so I'm pretty sure
that
new change is causing the problem downstream. Also if you look
at
past builds that succeed, all use "const" as the constant name.
If you want to do the experiment yourself, simply uncomment my
travis script hack...
FIXME/TODO oops Jeff's recent change broke the flow.
This temporary hack undoes the change and lets the
script succeed,
but this is not a reasonable fix going forward!

mv build/design_top.json /tmp/design_top.json
sed 's/const_186/const/' /tmp/design_top.json >
build/design_top.json
grep const build/design_top.json /tmp/design_top.json

...and you can see it fail again...
SR
PS FWIW it looks to me like the mapper script more or less
passes
the constant name through unchanged, from "design_top.json" to
"mapped.json," so I suspect that it's in the PNR script where
things
fall apart...
On 4/8/2017 5:31 PM, jameshegarty
wrote:
It's possible btw that this has nothing to do with Jeff's
change, remember, we pull down all the repos each time so it
could have been another change.
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/StanfordAHA/CGRAFlow","title":
"StanfordAHA/CGRAFlow","subtitle":"GitHub
repository","main_image_url":"

https://cloud.githubusercontent.com/assets/143418/
17495839/a5054eac-5d88-

11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
cloud.githubusercontent.com/assets/143418/15842166/
7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open
in
GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty
in
#3:
It's possible btw that this has nothing to do with Jeff's
change,
remember,
we pull down all the repos each time so it could have been
another
change."}],"action":{"name":"View Issue","url":"https://github.
com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecom
ment-292759941>,

or mute the thread

<https://github.com/notifications/unsubscribe-auth/AF13dCC
YgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU>

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292763903,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AF13dFqW-N6Tc6EkA_WEHjpajPWCEXioks5ruGLDgaJpZM4M33iU

.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

FYI I removed the log for build 150 so as to (hopefully) lessen
confusion (it broke because I initially messed up my sed-script
hack).  For an example of the failing design_top and mapped.json
files, see log 149 instead...

On 4/8/2017 9:50 PM, Caleb Donovick
  wrote:

The latter of the two ?might? break my code but I'm
  not completely up on
  COREIR format. Looked 150 like it broke because missed named
  filles.

  Caleb

  On Apr 8, 2017 9:47 PM, "steveri"<EMAIL_ADDRESS>  wrote:

  > Oh and also this, earlier in the same file
  >
  > "instances": {
  > "const_186": {
  > "config": {
  > "value": 2
  > },
  >
  >
  > On April 8, 2017 9:41:47 PM PDT, Stephen
<EMAIL_ADDRESS>wrote:
  > >It appears to be producing this (see build log 149
  >
  >https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):
  > >
  > >
  > >instances": {
  > > "const_186": {
  > > "config": {
  > > "constvalue": 2,
  > > "op": "const"
  > >
  > >
  > >
  > >On April 8, 2017 9:10:43 PM PDT, Caleb Donovick
  ><EMAIL_ADDRESS>wrote:
  > >>If changing the name of the constant changes value of
  > >>instance.get_config_value('op') from 'const' to
  something else then it
  > >>will
  > >>break my code. However, as the API is now there is no
  way for me to
  > >>work
  > >>around that.
  > >>
  > >>
  > >>Caleb
  > >>
  > >>On Apr 8, 2017 7:49 PM, "steveri"
<EMAIL_ADDRESS>wrote:
  > >>
  > >>>
  > >>>
  > >>>
  > >>>
  > >>>
  > >>> I tried the flow twice in quick succession, with
  the only difference
  > >>> being constant name "const_186" (build 150,
  failed) vs. "const"
  > >>> (Build 151, passed) in "design_top.json", so I'm
  pretty sure that
  > >>> new change is causing the problem downstream.
  Also if you look at
  > >>> past builds that succeed, all use "const" as the
  constant name.
  > >>>
  > >>> If you want to do the experiment yourself,
  simply uncomment my
  > >>> travis script hack...
  > >>>
  > >>> # FIXME/TODO oops Jeff's recent change broke the
  flow.
  > >>> # This temporary hack undoes the change and lets
  the
  > >>> script succeed,
  > >>> # but this is not a reasonable fix going
  forward!
  > >>> - mv build/design_top.json /tmp/design_top.json
  > >>> - sed 's/const_186/const/' /tmp/design_top.json
  >
  > >>> build/design_top.json
  > >>> - grep const build/design_top.json
  /tmp/design_top.json
  > >>>
  > >>> ...and you can see it fail again...
  > >>>
  > >>> SR
  > >>>
  > >>> PS FWIW it looks to me like the mapper script
  more or less passes
  > >>> the constant name through unchanged, from
  "design_top.json" to
  > >>> "mapped.json," so I suspect that it's in the PNR
  script where things
  > >>> fall apart...
  > >>>
  > >>>
  > >>> On 4/8/2017 5:31 PM, jameshegarty
  > >>> wrote:
  > >>>
  > >>>
  > >>> It's possible btw that this has nothing to do
  with Jeff's
  > >>> change, remember, we pull down all the repos
  each time so it
  > >>> could have been another change.
  > >>> —
  > >>> You are receiving this because you were
  assigned.
  > >>> Reply to this email directly, view
  > >>> it on GitHub, or mute
  > >>> the thread.
  > >>>
  > >>>
  > >>>
  > >>>
  > >>>
  > >>>
  > >>>
  > >>> {"api_version":"1.0","publisher":{"api_key":"
  > >>>
  05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
  > >>>
  {"external_key":"github/StanfordAHA/CGRAFlow","title":
  > >>> "StanfordAHA/CGRAFlow","subtitle":"GitHub
  > >>repository","main_image_url":"
  > >>>
  > >>https://cloud.githubusercontent.com/assets/
  > 143418/17495839/a5054eac-5d88-
  > >>>
  11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://
  > >>>
  cloud.githubusercontent.com/assets/143418/15842166/
  > >>>
  7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open
  in
  > >>>
  GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"
  > >>>
  updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in
  > >>#3:
  > >>> It's possible btw that this has nothing to do
  with Jeff's change,
  > >>remember,
  > >>> we pull down all the repos each time so it could
  have been another
  > >>> change."}],"action":{"name":"View
  Issue","url":"https://github.
  > >>>
  com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}
  > >>>
  > >>> —
  > >>> You are receiving this because you were
  mentioned.
  > >>> Reply to this email directly, view it on GitHub
  > >>>
  >

<https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292759941
,

or mute the thread

<https://github.com/notifications/unsubscribe-auth/
AF13dCCYgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU>

.

--
Sent from my Android device with K-9 Mail. Please excuse my
brevity.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292763903,
> or mute the thread
>
https://github.com/notifications/unsubscribe-auth/AF13dFqW-N6Tc6EkA_WEHjpajPWCEXioks5ruGLDgaJpZM4M33iU
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view
it on GitHub, or mute
the thread.
  {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/StanfordAHA/CGRAFlow","title":"StanfordAHA/CGRAFlow","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"updates":{"snippets":[{"icon":"PERSON","message":"@cdonovick in #3: The latter of the two ?might? break my code but I'm not completely up on\nCOREIR format.  Looked 150 like it broke because missed named filles.\n\n\nCaleb\n\nOn Apr 8, 2017 9:47 PM, \"steveri\"<EMAIL_ADDRESS>wrote:\n\n\u003e Oh and also this, earlier in the same file\n\u003e\n\u003e \"instances\": {\n\u003e \"const_186\": {\n\u003e \"config\": {\n\u003e \"value\": 2\n\u003e },\n\u003e\n\u003e\n\u003e On April 8, 2017 9:41:47 PM PDT, Stephen<EMAIL_ADDRESS>wrote:\n\u003e \u003eIt appears to be producing this (see build log 149\n\u003e \u003ehttps://travis-ci.org/StanfordAHA/CGRAFlow/builds/220134733):\n\u003e \u003e\n\u003e \u003e\n\u003e \u003einstances\": {\n\u003e \u003e \"const_186\": {\n\u003e \u003e \"config\": {\n\u003e \u003e \"constvalue\": 2,\n\u003e \u003e \"op\": \"const\"\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003eOn April 8, 2017 9:10:43 PM PDT, Caleb Donovick\n\u003e<EMAIL_ADDRESS>wrote:\n\u003e \u003e\u003eIf changing the name of the constant changes value of\n\u003e \u003e\u003einstance.get_config_value('op') from 'const' to something else then it\n\u003e \u003e\u003ewill\n\u003e \u003e\u003ebreak my code. However, as the API is now there is no way for me to\n\u003e \u003e\u003ework\n\u003e \u003e\u003earound that.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003eCaleb\n\u003e \u003e\u003e\n\u003e \u003e\u003eOn Apr 8, 2017 7:49 PM, \"steveri\"<EMAIL_ADDRESS>wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e I tried the flow twice in quick succession, with the only difference\n\u003e \u003e\u003e\u003e being constant name \"const_186\" (build 150, failed) vs. \"const\"\n\u003e \u003e\u003e\u003e (Build 151, passed) in \"design_top.json\", so I'm pretty sure that\n\u003e \u003e\u003e\u003e new change is causing the problem downstream. Also if you look at\n\u003e \u003e\u003e\u003e past builds that succeed, all use \"const\" as the constant name.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e If you want to do the experiment yourself, simply uncomment my\n\u003e \u003e\u003e\u003e travis script hack...\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e # FIXME/TODO oops Jeff's recent change broke the flow.\n\u003e \u003e\u003e\u003e # This temporary hack undoes the change and lets the\n\u003e \u003e\u003e\u003e script succeed,\n\u003e \u003e\u003e\u003e # but this is not a reasonable fix going forward!\n\u003e \u003e\u003e\u003e - mv build/design_top.json /tmp/design_top.json\n\u003e \u003e\u003e\u003e - sed 's/const_186/const/' /tmp/design_top.json \u003e\n\u003e \u003e\u003e\u003e build/design_top.json\n\u003e \u003e\u003e\u003e - grep const build/design_top.json /tmp/design_top.json\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e ...and you can see it fail again...\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e SR\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e PS FWIW it looks to me like the mapper script more or less passes\n\u003e \u003e\u003e\u003e the constant name through unchanged, from \"design_top.json\" to\n\u003e \u003e\u003e\u003e \"mapped.json,\" so I suspect that it's in the PNR script where things\n\u003e \u003e\u003e\u003e fall apart...\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e On 4/8/2017 5:31 PM, jameshegarty\n\u003e \u003e\u003e\u003e wrote:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e It's possible btw that this has nothing to do with Jeff's\n\u003e \u003e\u003e\u003e change, remember, we pull down all the repos each time so it\n\u003e \u003e\u003e\u003e could have been another change.\n\u003e \u003e\u003e\u003e —\n\u003e \u003e\u003e\u003e You are receiving this because you were assigned.\n\u003e \u003e\u003e\u003e Reply to this email directly, view\n\u003e \u003e\u003e\u003e it on GitHub, or mute\n\u003e \u003e\u003e\u003e the thread.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e {\"api_version\":\"1.0\",\"publisher\":{\"api_key\":\"\n\u003e \u003e\u003e\u003e 05dde50f1d1a384dd78767c55493e4bb\",\"name\":\"GitHub\"},\"entity\":\n\u003e \u003e\u003e\u003e {\"external_key\":\"github/StanfordAHA/CGRAFlow\",\"title\":\n\u003e \u003e\u003e\u003e \"StanfordAHA/CGRAFlow\",\"subtitle\":\"GitHub\n\u003e \u003e\u003erepository\",\"main_image_url\":\"\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003ehttps://cloud.githubusercontent.com/assets/\n\u003e 143418/17495839/a5054eac-5d88-\n\u003e \u003e\u003e\u003e 11e6-95fc-7290892c7bb5.png\",\"avatar_image_url\":\"https://\n\u003e \u003e\u003e\u003e cloud.githubusercontent.com/assets/143418/15842166/\n\u003e \u003e\u003e\u003e 7c72db34-2c0b-11e6-9aed-b52498112777.png\",\"action\":{\"name\":\"Open in\n\u003e \u003e\u003e\u003e GitHub\",\"url\":\"https://github.com/StanfordAHA/CGRAFlow\"}},\"\n\u003e \u003e\u003e\u003e updates\":{\"snippets\":[{\"icon\":\"PERSON\",\"message\":\"@jameshegarty in\n\u003e \u003e\u003e#3:\n\u003e \u003e\u003e\u003e It's possible btw that this has nothing to do with Jeff's change,\n\u003e \u003e\u003eremember,\n\u003e \u003e\u003e\u003e we pull down all the repos each time so it could have been another\n\u003e \u003e\u003e\u003e change.\"}],\"action\":{\"name\":\"View Issue\",\"url\":\"https://github.\n\u003e \u003e\u003e\u003e com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048\"}}}\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e —\n\u003e \u003e\u003e\u003e You are receiving this because you were mentioned.\n\u003e \u003e\u003e\u003e Reply to this email directly, view it on GitHub\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003chttps://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292759941\n\u003e \u003e,\n\u003e \u003e\u003e\u003e or mute the thread\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003chttps://github.com/notifications/unsubscribe-auth/\n\u003e AF13dCCYgaJ7O0cIgi3gVqf8QZYIetbPks5ruEclgaJpZM4M33iU\u003e\n\u003e \u003e\u003e\u003e .\n\u003e \u003e\u003e\u003e\n\u003e\n\u003e --\n\u003e Sent from my Android device with K-9 Mail. Please excuse my brevity.\n\u003e\n\u003e —\n\u003e You are receiving this because you were mentioned.\n\u003e Reply to this email directly, view it on GitHub\n\u003e \u003chttps://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292763903\u003e,\n\u003e or mute the thread\n\u003e \u003chttps://github.com/notifications/unsubscribe-auth/AF13dFqW-N6Tc6EkA_WEHjpajPWCEXioks5ruGLDgaJpZM4M33iU\u003e\n\u003e .\n\u003e\n"}],"action":{"name":"View Issue","url":"https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292764003"}}}

For completeness, note, this (below) should have referred to "build
149, failed" and not "build 150, failed."  Build 150 is not
useful and I deleted it as per previous e-mail...

SR

On 4/8/2017 7:49 PM, Stephen Richardson
  wrote:

  I tried the flow twice in quick succession, with the only
  difference being constant name "const_186" (build 150, failed) vs.
  "const"  (Build 151, passed) in "design_top.json", so I'm pretty
  sure that new change is causing the problem downstream.  Also if
  you look at past builds that succeed, all use "const" as the
  constant name.

  If you want to do the experiment yourself, simply uncomment my
  travis script hack...

    # FIXME/TODO oops Jeff's recent change broke the flow.
    # This temporary hack undoes the change and lets the
    script succeed,
      # but this is not a reasonable fix going forward!
    - mv build/design_top.json /tmp/design_top.json
    - sed 's/const_186/const/' /tmp/design_top.json >
    build/design_top.json
    - grep const build/design_top.json /tmp/design_top.json

  ...and you can see it fail again...

  SR

  PS FWIW it looks to me like the mapper script more or less passes
  the constant name through unchanged, from "design_top.json" to
  "mapped.json," so I suspect that it's in the PNR script where
  things fall apart...

  On 4/8/2017 5:31 PM, jameshegarty
    wrote:

    It's possible btw that this has nothing to do with Jeff's
      change, remember, we pull down all the repos each time so it
      could have been another change.
    —
      You are receiving this because you were assigned.
      Reply to this email directly, view
        it on GitHub, or mute
        the thread.

    {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/StanfordAHA/CGRAFlow","title":"StanfordAHA/CGRAFlow","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/StanfordAHA/CGRAFlow"}},"updates":{"snippets":[{"icon":"PERSON","message":"@jameshegarty in #3: It's possible btw that this has nothing to do with Jeff's change, remember, we pull down all the repos each time so it could have been another change."}],"action":{"name":"View Issue","url":"https://github.com/StanfordAHA/CGRAFlow/issues/3#issuecomment-292755048"}}}

As recommended earlier by James, I am going to remove my sed hack from the travis script so that it will fail until we get this fixed...

I would maybe also recommend removing the workaround... keeping the build working is a good idea, but IMO this is a real problem we should track down.

BTW if (like me) you are annoyed that everyone can see your comments except you, note that there is a place in your account settings where you can set "include your own updates" (seems to be off by default) - see https://github.com/settings/notifications

I am going to push a change that should fix this problem, but break Jeff's code.
@jeffsetter I am changing the type of constant, so please update your code to take this into account.
Previous: Array(16,BitOut)
New: Record({"out",Array(16,BitOut)})

I pushed the necessary change to my repo. It appears that it is working again.

Great!


Horizontal swimlines

It would be cool to have expedite/blocked/CODB horizontal swimlanes.

@fujin thanks for opening an issue!
Do you have any screenshots or examples you can point us to? Trying to get a better sense of what you're suggesting...