flowbased / flowtrace Goto Github PK
View Code? Open in Web Editor NEWTraces for retroactive debugging of FBP programs
Traces for retroactive debugging of FBP programs
Branch | Build failing 🚨 |
---|---|
Dependency |
grunt
|
Current Version | 1.0.2 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
grunt is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 10 commits.
9ba3a99
1.0.3
eee4c33
Changelog v1.0.3
46da7f2
Merge pull request #1636 from gruntjs/upt
00f4d8a
Drop support for Node 0.10 and 0.12
e852727
util update
56d702e
Update deps
0105524
Fix race condition with file.mkdir and make it operate more similarily to mkdir -p (#1627) r=@vladikoff
303d445
https links (#1629)
d969132
Merge pull request #1624 from gruntjs/rm-bump-deps
289ff91
Remove old bump task and deps
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
Just using the code also from the command-line tool for instance.
Especially since the graphical timeline etc is kinda useless right now.
Should also be configurable as a URL parameter (ref #24).
Should be workflow oriented. "this is how you do that"
Right now there is nothing with is very scary. Should just take some input trace files, process/setup using various (high-level) options and verify regular output.
For replay this means the FBP protocol, for show it means the strings outputted.
When we support uploading to a service like Flowhub (#2), flowtrace-replay
and flowtrace-show
should be able to show information directly from a URL. This likely requires them to pass along authentication information, which should be read from an envvar.
First need to store it, noflo/noflo-runtime-base#32
Then send over FBP protocol as component
messages
Branch | Build failing 🚨 |
---|---|
Dependency | grunt-bower-install-simple |
Current Version | 1.2.4 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
grunt-bower-install-simple is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 5 commits.
c48fc1e
release version 1.2.5
f72a5f3
bump year in all copyright messages
abcb10d
upgrade dependencies
319220c
upgrade dependencies
37ed003
upgrade dependencies
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
For instance interesting to find which connections have certain data come past. Also what groups it was included with it at that time. Mostly so one can find a particular request, and then do other filtering later.
Branch | Build failing 🚨 |
---|---|
Dependency |
mocha
|
Current Version | 5.1.1 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
mocha.opts
(@plroebuck)before
hooks when using --bail
(@outsideris)Buffer.from()
(@harrysarson)The new version differs by 30 commits.
5bd33a0
Release v5.2.0
0a5604f
reformat missed files
7c8f551
ensure scripts/*.js gets prettiered
d8ea2ba
update CHANGELOG.md for v5.2.0 [ci skip]
7203ed7
update all dependencies
fb5393b
migrate Mocha's tests to Unexpected assertion library (#3343)
fae9af2
docs(docs/index.md): Update "mocha.opts" documentation
9d9e6c6
feat(bin/options.js): Add support for comment lines in "mocha.opts"
e0306ff
fix busted lint-staged config
f2be6d4
Annotate when exceptions are caught but ignored; closes #3354 (#3356)
889e681
remove dead code in bin/_mocha
8712b95
fix(ocd): re-order Node.js tests in .travis.yml (descending)
3ab0e7e
fix to exit correctly when using bail flag
d87b12e
add Node.js v10 to build; fix win32 issues (#3350)
b392af5
update package-lock.json for npm@6 [ci skip]
There are 30 commits in total.
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
When capturing traces from production environment with lots of processing, one often encounters scenarios where many failures are in fact caused by same bug/issue. And that small changes in inputs often are difference between triggering an issue or not, and that such differences can say a lot about the nature of the bug.
Interesting questions include:
With the ability to upload traces to a service (#2), it becomes interesting to have cloud-based tools which help answer these problem at scale. Performance of making the needed analysis - both how quick to get results, and how much it costs, are key considerations.
Should be autodeploy via Travis.
Could use Github Pages for hosting, would then appear as https://flowbased.github.com/flowtrace
Combined with #25, #24 and something like noflo/noflo-runtime-base#64 + #2, could be a minimally-useful post-mortem debugger for issues that happens in CI or production.
Useful to be able to debug an issue with different code/environment.
Should be able to specify which edge to inject into, and which to read from (default to same as inject).
Right now have to manually copy&paste the url.
https://github.com/sindresorhus/opn
Should allow to disable this behavior --open=false
.
Sometimes the issue/bug is caused inside component code, like an exception / returned Error.
In this case it would be nice to be able to look inside the component, and see exception wrt to that. Like a regular imperative/OOP debugger.
Must be able to look up component code, #6
Looks like this now when redirecting output to a file...
�[34m�[3m-> CSS image/GetColors_at7fj�[23m�[39m �[33mCONN�[39m
�[34m�[3m-> CSS image/GetColors_at7fj�[23m�[39m �[32mDATA�[39m false
�[34m�[3m-> CSS image/GetColors_at7fj�[23m�[39m �[33mDISC�[39m
Basically we're reusing a lot of other FBP formats, like the protocol and graph format.
Ideally those would have JSON schemas which we could just refer, but that is currently not in a good shape. Might be good to start with a top-level schema here, where we are starting from scratch and plug in more as we improve the other specs.
For instance:
Should be able to target inside a subgraph, and to combine these to get a particular view.
Should be transparently handled when loading.
Need to standardize supported compression schemes
Branch | Build failing 🚨 |
---|---|
Dependency |
grunt-contrib-watch
|
Current Version | 1.0.1 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
grunt-contrib-watch is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 4 commits.
3b7ddf4
v1.1.0
72b1214
Updating dependencies, async, lodash and tiny-lr
5adb27c
Merge pull request #543 from digitalbazaar/master
f07311b
Update tiny-lr dependency to 1.x
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
Should load the trace and display it.
Branch | Build failing 🚨 |
---|---|
Dependency | commander |
Current Version | 2.15.1 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
commander is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.
The new version differs by 17 commits.
4cc348b
Merge pull request #822 from abetomo/version_bump_2.16.0
8db14db
version bump 2.16.0
1f9354f
Remove Makefile and test/run
(#821)
3f4f5ca
Make 'npm test' run on Windows (#820)
3b8e519
Merge pull request #807 from styfle/patch-1
77ffd4f
Merge pull request #814 from DanielRuf/chore/cache-node-modules
6889693
chore: cache node_modules
ff2f618
Merge pull request #813 from DanielRuf/chore/remove-nodejs-4-add-nodejs-10
d5c1d7d
chore: remove Node.js 4 (EOL), add Node.js 10
c05ed98
Merge pull request #812 from yausername/fixReadme
55ff22f
fixed typo in readme
2415089
Add badge to display install size
89edef0
Fix types (#804)
001d560
Update eslint to resolve vulnerabilities in lodash
988d09b
Merge pull request #791 from yausername/master
There are 17 commits in total.
See the full diff
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
Would require the trace to either:
npm list
dump, though maybe one should extract repo
(typically but not alway github) from the package.json right away. Then would have to get the path from base of repo to the particular component. And have a way to HTTP GET the actual source code..Since we want this in a non-NPM specific manner in general, there are some relationships here to noflo/noflo#247
Should give machine-readable data, to compliment flowtrace-show
(which gives human-friendly output).
Should reuse the filtering options (#10 #11 #12). By default should probably create a new Flowtrace file with "subtrace". But should also have other options to extract other things, for working onwards using other tools.
Maybe option for
Currently hardcoded to localhost
This way debugging tools can be live updated with changes to the system.
One possibility is to use text/event-stream
format. It is a simple \n\n delimited format, with good support for JSON payloads.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#Event_stream_format
It has the benefit of also being used in server-side-events which is supported by webbrowsers.
The header information like the graph should also be sent as an event. It should be supported to have this change in the middle of a stream also.
Ideally tools can also deal with the header not being present, and recontructing information from data events (to the extent possible)
It should be possible to annotate a trace, with comments / metadata. This is especially useful when collaborating, as a developer can add their analysis/questions in a way that other tools can then display.
It may also be useful for semi/automated analysis tools to inject annotations, to point to specific areas of interest.
Annotations should be stored outside the events
stream, as an event is considered immutable.
Possibly we should add an 'event id', to allow such references to be done in an unambigious way (even when trace is/has-been transformed). As a prototype one could use the array index though.
Would connect to a runtime over the FBP runtime protocol, and listen there for messages and from those produce a flowtrace file.
This allow to listen remotely, for instance if the runtime under investigation does not have capacity/permissions to write a flowtrace to disk. Often it is also more convenient to have the files on a developer machine. And it enables using flowtrace with FBP runtimes which do not have integrated support for flowtrace (but support the protocol).
This is basically the opposite of the already existing flowtrace-replay
.
For many bugs, it is often possible to narrow things down to get one (or more) test run which succeeds, and one (or more) test runs which fails.
Sometimes the cause for difference is in input data, and sometimes in the (version of) code used. Or in some cases, the environment the code is executing in.
But then to figure out why exactly this makes causes difference in behavior. In dataflow/FBP that usually means following the data until it starts diverging. A tricky/tedious part is usually being able to distinguish the insignificant from significant differences.
There might be timestamps, payload sizes etcs that continiously vary, but are not of interest. Or in other cases, there are slight differences which are functionally equivalent. For instance existance or value of some keys in an object might not matter at all. Or addition/removal of some elements of an array (but not others).
In general we'd need tooling that brings down the differences enough to be analyzed/understood easily/quickly by the developer. It should allow to progressively tighten whats shown when one has narrowed down possibilities.
If one does not know if difference is input or code/graphs, it may be useful with tools to help figure that out. For diffing the graphs, some integration with (yet to be developed) fbp-diff may be useful. Alternatively, one could use require user to combine (proposed)[https://github.com/flowbased/flowtrace/issue/13] flowtrace-extract --graph
+ fbp-spec
for that.
Especially useful for sending traces from automated tests ran on Travis CI, or production systems.
Now the runtime gets a random UUID every time it is started, which is somewhat confusing to clients like noflo-ui. It would be better to generate a UUID and persist it in the pwd
in a dotfile.
Needs to be calculated from timestamp
.
Needs to use groups to correlate events I guess?
To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:
.travis.yml
If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.
Greenkeeper has checked the engines
key in any package.json
file, the .nvmrc
file, and the .travis.yml
file, if present.
engines
was only updated if it defined a single version, not a range..nvmrc
was updated to Node.js 10.travis.yml
was only changed if there was a root-level node_js
that didn’t already include Node.js 10, such as node
or lts/*
. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.For many simpler .travis.yml
configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖
There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot 🌴
At least
Should be possible to add multiple such matching rules.
Later we'd probably also want:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.