Alternative command implementation

These are just some thoughts about an alternative way to implement commands, no actual implementation done. It might be overkill, result in a weird API, or plain unnecessary, but I might as well post this here. Idea came after reading this introduction to frp. I hope this is not just incoherent mumbling, but actually understandable.
Basic concept: Commands communicate via frp streams. Each instance of a command has an input stream and an output stream. When a user types and activates a command, an instance of the command is created, based on the given options. The actual argument is not used in the creation of the command instance. Then, the argument(s) are passed to the command's input stream. The command does some stuff, then writes the output through it's output stream. The output stream is listened to by vorpal, and by default the output is printed into the console. When the command is done, it ends the stream, which vorpal interprets as if the command's callback in the current implementation was called, returning focus to the user.
Command piping could easily be implemented by piping the output stream of the first command into the input stream of the second one. Unlike the current implementation, commands would run asynchronously. This way, two commands separated by ; could be started simultaneously.
Commands could also emit errors. This would allow implementing && and || for command chaining. One could even go further and use 2>> to only pass on errors etc.
Parsing a command string from the user could be done in two stages: First, separate actual commands and chaining operators via regexes. Second, create command instances and correctly chain the streams together. By separating this, parsing the command options could be delegated to one of the existing node modules.
edit: Parsing using regexes is not a good idea...
Command definition would be done by giving methods handling arguments from the input stream, errors from the input stream, and end of the input stream (vorpal could provide a sensible default for errors and end of stream), instead of command.action().
Pros:

asynchronous commands
well structured command parsing
clear implementation of various piping and chaining possibilities
well testable

Cons:

slightly more complex API
API breakage? (The stream based implementation can simulate the current one, so maybe not)
Vantage integration?
Complete rewrite of a lot of code needed

I currently don't have time to spend on this, but I wanted to get the idea out there. And if this is not just garbage, I could start working on this later - no need to hurry...

Thanks and received! I'll have to spend some more time thinking this over, but this is possibly something we can implement in the future.

Further thoughts: Instead of using the streams of a FRP library, this should instead use simple node streams. The implementation could actually mirror that of UNIX pipes, with a stdout, a stderr and an exit code. Then, a bridge could be built to Node's Child Process, which could enable running normal commands from vorpal.
This implementation of commands with std-streams and exit code should probably go into its own module, which Vorpal then could use. The module would also do the command parsing, handling the piping logic itself, and delegating options to Commander/Minimist/whatever proven library exists.
Since this would be rather low-level, Vorpal would probably provide a more convenient API.
 Even if it might be overkill for Vorpal, I find this much too fascinating not to do it.

Yeah, those darn real-life grumble grumble grumble... :)
I'm totally down for streaming. It's kind of embarrassing that Vorpal piping doesn't use streams.
Whenever you get around to it, throw together some concepts and then we'll go over it.

Basic API sketch (without asynchronous support): The functions defined here would be passed to some constructor.
// A fizzbuzz command.
var init = function () {
  this.fizzCount = 0;
};

var onInput = function (input) {
  var number = parseInt(input);
  if (Number.isNaN(number)) {
    // method provided by library
    this.stdErr("invalid input, expected a number");
  } else {
    var fb = "";
    if (number % 3 === 0) {
      fb += "Fizz";
      this.fizzCount++;
    }
    if (number % 5 === 0) {
      fb += "Buzz";
    }
    // method provided by library
    this.stdOut(fb === "" ? number : fb);
  }
};

var onInputExit = function (code) {
  this.stdOut("fizzCount: " + this.fizzCount);
  // method provided by library
  this.exit(0);
};

Expected outputs:
$ fizzbuzz 2
=> 2
=> fizzCount: 0

$ fizzbuzz 15
=> FizzBuzz
=> fizzCount: 1

$

// A counter command.
var init = function () {
  var delta = 1;
  // options object provided by library
  if (this.options.from > this.options.to) {
    delta = -1;
  }

  for (var i = this.options.from; i === this.options.to; i += delta) {
    if (i !== 12) {
      this.stdOut(i);
    } else {
      this.stdErr("Nah, no 12.");
    }
  }

  this.exit(0);
};

Expected outputs:
$ counter --from 3 --to 6
=> 3
=> 4
=> 5
=> 6

$ counter --from 13 --to 11
=> 13
=> Nah, no 12. # evil red error message
=> 11

$

Combining them:
$ counter --from 3 --to 6 | fizzbuzz
=> Fizz
=> 4
=> Buzz
=> Fizz
=> fizzCount: 2

$ counter --from 13 --to 11 | fizzbuzz
=> 13
=> Nah, no 12. # evil red error message
=> 11
=> fizzCount: 0

$

Behind the scenes, each command has three streams, stdin, stdout, and stderr (stdin and stdout can optionally be object streams). stdout is piped to the next command's stdin (or to the higher-level stdout). stdin is listened on to call onInput. stderr goes directly to the higher-level management code.
Stuff to consider: How to handle asynchronous actions.

init would be given a callback to signal that initialization is done and onInput may be called.
onInput can be async as well. May keep track of a queue of onInput calls, each call signals via callback that it is done. Exiting the command can then wait for async input handling to terminate.

Substitute "promise" for "callback" as preferred.
The code managing the command lifecycles should be able to interrupt commands (analogy to SIGINT). Maybe an event system is needed to notify the commands.
Anyways, doing more pesky real life grumbling for now =)

Any ideas for the SIGINT-equivalent? The framework should be able to stop a running command, but forcing the interruption does not sound like a good approach. Maybe add a shouldTermintate method to the object bound to init, onInput and onInputExit, returning whether interruption was requested?
The average command is not complex enough and can safely ignore that.
Or do you think a more forceful interruption is needed?
Also I'd gladly take better naming suggestions for the functions (or the module itself for that matter) - you are far better with (English) words than I am...

First of all, I'm not expecting immediate feedback on this, I suppose cash keeps you pretty busy right now. I'm just sharing some of the involved decisions. Because why not?
Thoughts on objectMode for the streams:
The low-level implementation can do either via options, but perhaps Vorpal should enforce one or the other.

Object streams allow convenient implementation of commands interacting with specific other commands.
Strings/Buffer streams would allow all commands to interact uniformly. Especially important if plugins are added, but this already applies for extensions.

Alternatively, commands could define whether they expect objects or strings. Vorpal could pass the required format (e.g. by using JSON.stringify when appropriate).
In eiter case, the developer using vorpal should not have to worry about handling strings as well as objects in the same command.
Similiary, should the error stream use strings, Error objects, both? Again the low-level implementation should allow both, but Vorpal might want to restrict this for consistency and a more convenient API.

This turned out to be more work than I anticipated, but here is a first implementation. Most of the complexity will be abstracted away, the end user would only pass three lifecycle methods (init, onInput, cleanup) with access to some properties to a constructor.
As a next step I'll write something which parses strings like 'foo || bar', passes 'foo' and 'bar' to a factory method returning a CommandInstanceand properly connects them. Then I'll try do build an example factory which executes the string as a ChildProcess and wraps that childprocess into a CommandInstance. That way I can do some sweet tests where I simply compare the input of e.g. ls | grep foo in an actual shell to that of the javascript version. And that code would make a useful vorpal extension as well.
The parser will be independently extendable with redirection, command substitution, here documents etc. Also, tee could be done as a vorpal extension/plugin.
A realistic command factory would be given command definitions similiar to the ones currently used in vorpal, parsing the string for options and passing the options for the created instances. The factory would probably be implemented by vorpal (but it can utilize commander or yargs or someting similiar), but the parser and the CommandInstance class would be self-contained modules.
All in all still a lot of work to do, but the result should be worth it.

You're overwhelming me with good ideas! Great work, will try to take a thorough look at this as soon as I can.
First priority currently is closing existing issues, so we have a clean base for some redesigns.

Okay, I looked at this a bit, it actually looks really good.
The most important thing though, as you said, very simply abstracting it for the user, and making it behave similarly to existing Vorpal commands.
For example,

this.stdin could simply be this.log and this.stderr could be this.error, which would match console.log and console.error.

As cleanup would be optional for a user, it should be an optional method on command:

vorpal.command('foo')
  .action(action)
  .cleanup(cleanup);

Piping of commands should just work like streams people are used to. Perhaps:

vorpal.command('foo')
  .action(function () {
    this.on('data', function() {
      // piped data.
    });
   });

Can we discuss the end-user syntax on this?

Abstraction Hierarchy
I'll outline a full abstraction hierarchy for implementing all this stuff in this comment. See comments below for API discussion.
Command Instance
Not going to summarize this again, just check the readme.
Command Chain
The CommandChain takes CommandInstances, chains them together and initializes them. It has a stream.Readable input stream, a stream.Writable output stream and a stream.Writable error stream. If no stream redirection is requested, the input of the chain is piped into the stdin of the first CommandInstance, the output is piped to by the last CommandInstance's stdout and all stderrstreams are piped into the error stream of the CommandChain. This is basically the top right diagram here.
The CommandChain provides some methods which operate on command-instance level and implement different control structures. E.g. chain.pipe(commandInstanceA, commandInstanceB) (pipe stdout of A into stdin of B), or chain.conditionalAnd(commandInstanceA, commandInstanceB) (only run B if A exists with code 0) and so on.
Stream redirection belongs on this level as well.
The implementation might need to not only operate on CommandInstances, but on some sort of command blocks or command groups, but we can get to that later...
Parser
The Parser takes a string and contructs a corresponding CommandChain from it (or rejects it as syntactically invalid). It distinguishes between command strings and control structures. We can start by implementing only simple control structures (since these have to be implemented in CommandChain as well), but here is a more complex example:
ping -c1 <IP_ADDRESS> || {echo 'no internet connection'; ls /etc/netctl | grep wlp2s0}

The command strings in here are "ping -c1 <IP_ADDRESS>", "echo 'no internet connection'", "ls /etc/netctl/profiles" and "grep wlp2s0". The control structures form a tree hierarchy with command strings as leaves.
Coding all this will take some work, but we can start by just implementing piping - that's all vorpal currently does as well. But by writing a parser which builds a syntax tree, all of this becomes doable. And the implementation is abstracted away in the CommandChain, which idealy has exactly one method corresponding to exactly one constrol structure node.
The parser needs to deal with command strings, because the CommandChain expects CommandInstances. For this, the parser delegates to a CommandInstanceFactory. Such a factory has a very simple interface: It takes a command string and returns a corresponding CommandInstance. The CommandInstanceFactory is supplied to the parser, so it does not care about the implementation itself.
Vorpal Implementation
Vorpal lets the parser build CommandChains from user input. Vorpal interacts with these chains by supplying input for interactive commands, and displaying (or at least handling) the output stream, the error stream and exit codes and messages. The parser is given a CommandInstanceFactory by vorpal, which is constructed at vorpal's initialization (but could be modified at runtimes if commands are added/removed/edited at runtime).
Vorpal's command function would essentially be a builder for a CommandInstanceFactory, which then constructs the correct CommandInstance. So the information it needs to provide are:

How to parse a command string (anything between the control structures like |, ;, && etc):

determine which command to instantiate
set options
set arguments (operands)

Implementation for the lifecycle functions of the command:

init
onInput
cleanup

The information from all commands is pooled to create the factory. The factory determines which command is going to be constructed and then dispatches to some objects/functions constructed via the command function.
This would create a bare-bones factory, but vorpal can enhance it with automatic help etc.

CommandInstance discussion
For some reason I thought about piping the operand of a command into the CommandInstance after initialization, so mkdir foo and echo foo | mkdir would be the same. This comes with a lot of problems, I'm not even sure why I thought this would be a good idea. But we can make the operand(s) easily available in the lifecycle functions so that's not actually a problem.
I'll need to adjust handling initialization and the 'ready' event a bit. Currently commands need to be started in the reverse order, which calls init in reverse order, which is pointless.
I could switch the implementation to use callbacks instead of promises. Promise resolution and rejection are handled the same anyways, they just indicate that the lifecycle method is done with its potentially async action. Errors need to be signaled with this.stderr and if unrecoverable exit(code, msg) anyways. Any preferences?

Vorpal Command API Discussion
Everything below is of course just a suggestion. Point of view is that of the CommandInstanceFactory. The API methods modify the factory (or rather they modify a command object which is passed to the factory once it is done).
To recap what information we need:

parsing a command string:

determine which command to instantiate
parse and set options
read in operand(s)

lifecycle implementation

init
onInput
cleanup

Determining which command to instantiate:
Strategy:
Interpret the first part of the command string as the name. Dispatch which CommandInstance to create based on a map of names. Fail if no command of this name is found.
API:

vorpal.command('name'): Vorpal's command creating method(s) should all take the command name.
cmd.name('name'): Explicitely set the name for a command
cmd.alias('name'): Set another key for the map which is used by the dispatcher of the CommandInstanceFactory.

Parse and set options
Strategy:
Define which options the command takes, and what kind of options they are. Pass the parsing of the command string and the actual creation of an options hash to library like commander or yargs.
API:
Can stay the same.
Read in operands
Strategy:
Pass the operands of a command to its stdin after its initialization
API:
None, this happens implicitely.
Lifecycle:
Strategy:
Allow the user to pass a function, or supply a default no-op one (e.g. function () {return Promise.resolve();}).
API:

cmd.init(fn): Set the given function as the init lifecycle method.
cmd.action(fn(input)): Set the given function as the onInput lifecycle method.
cmd.cleanup(fn): Set the given function as the cleanup lifecycle method.
fn mus always return a promise (or this could be callback-based instead).

Trivial command:
vorpal.command('name');

A simple command:
vorpal.command('reverse').action(function (input) {
  // don't reverse strings like this at home!
  this.log(input.split('').reverse().join(''););
  return Promise.resolve();
});

The FizzBuzz command from the CommandInstance example:
vorpal.command('fizzbuzz')
  .init(function () {
	this.fizzCount = 0;
	return Promise.resolve();
  }).action(function (input) {
    // nobody wants to read another FizzBuzz implementation
    // returns a promise
    return doTheFizzBuzz();
  }).cleanup(function () {
    this.log('fizzCount: ' + this.fizzCount );
    return Promise.resolve();
  });

Example with options:
vorpal.command('repeat')
  .option('-a, --amount <int>', 'How often to repeat.')
  .action(function (input) {
    for (var i = 0; i < this.options.amount; i++) {
      this.log(input);
    }
    return Promise.resolve();
  });

Always returning Promise.resolve() for these synchronous commands is rather annoying though, could Vorpal detect and wrap this?
Stream handling
An interesting question is how vorpal should handle the stream options. Commands could output Buffers, Strings in various encodings, these could be automatically decoded, or object mode could be used. Vorpal coul either restrict this to one, or default to one but allow usage of others. No idea for the API for that though...

However: What happens with a command like echo foo | grep bar? While 'bar' looks like an operand, it actually isn't, the real operand is 'foo'. 'bar' would need to be translated into an option. Which is completely doable, I'm just not sure how to expose this to command implementors.

Foo would be stdin, and bar is the operand. Don't see why this is a problem.

onInput

Can we just refer to onInput as data, to match stream syntax? I think this will be clearer in the long run. As well, cleanup could be called end. These are standard stream events.

Okay, I'm really liking all of this. Here's the deal: I want to model Vorpal into a full bash interpreter (as you are saying). This would mean we would match all syntax and functionality of bash (including &&, ||, #, etc.) and properly implement stdin, stdout as you've gone over.
It is very possible that Cash is going to be packaged into NPM as a cross-platform Unix shell, and this update would make this possible.
I think this should release as Vorpal 2.0.
If I added you as a collaborator to Vorpal, and created a 2.0 branch, do you think we could start rolling on all of this? Is this something you could dedicate some time to? I would ideally love to do this as soon as possible.

Okay you have access to the repo now, and I created a 2.0 branch. You're free to push whatever you want to it (if you need to push something to 1.0, just ping me first).

Always returning Promise.resolve() for these synchronous commands is rather annoying though, could Vorpal detect and wrap this?

Sure. Additionally, I would like commands to support sync, async (callbacks and Promises. Right now async and Promise are supported, with sync supported through vorpal.execSync, however it should all be available through the same method.

Another thing is that I would like actions to return status code (0, 1), etc. Perhaps all stdout and stderr are sent through logs, and only status codes are returned? Vorpal could then abstract the this all to a standard interface.

btw, what time zone are you in (I'm PST). We seem to have flipped schedules, which is going to suck.

Foo would be stdin, and bar is the operand. Don't see why this is a problem.

Because it would be very elegant to handle operands by piping them into stdin after initialization. Disregarding exceptions like grep, most commands want to handle stdin as if it just contained additional operands, which happen to be supplied asynchronously. That way, our user has to define only one function which handles operands as well als stdin.
This is different from the way UNIX commands work. E.g. echo foo | mkdir won't create a foo directory. But a vorpal implementation of mkdir might as well get that behaviour for free.
However, if we actually try to copy bash, this would have to be handled differently. And since commands like grep require an operand as well as stdin, the current CommandInstance implementation will need to be changed anyways.
I suppose CommandInstance should just mimic UNIX commands and vorpal has to figure out how to provide a convenient API for command definition.

Can we just refer to onInput as data, to match stream syntax? I think this will be clearer in the long run. As well, cleanup could be called end. These are standard stream events.

Sure, sounds reasonable.

I want to model Vorpal into a full bash interpreter (as you are saying). This would mean we would match all syntax and functionality of bash (including &&, ||, #, etc.) and properly implement stdin, stdout as you've gone over.

A full bash iterpreter is going to be a lot of work. Also a pretty interesting challenge. I'd suggest writing a jison grammar with the most basic features and then gradually adding to it.

Another thing is that I would like actions to return status code (0, 1), etc.

The current CommandInstance implementation already has these, exit code and message are given witht the 'exit' event. These are a must for bash syntax like && and ||.

btw, what time zone are you in (I'm PST). We seem to have flipped schedules, which is going to suck.

I'm in CET, but look on the bright side: 24h/day of combined vorpalness...

Is this something you could dedicate some time to? I would ideally love to do this as soon as possible.

It is something I want to dedicate some time to. Currently writing my bachelor's thesis tough, so working on open source projects obviously is a lower priority. Then again, I don't spend all my waking hours on the thesis anyways, so I will get some coding done. And I will put aside some other projects/ideas of mine for this. So yes, count me in.

Also, we can move the CommandInstance specific discussion to its repo, and focus on the vorpal API here.

As for the bash reimplementation, I found these two projects, which may or may not be helpful.
The bash manual looks surprisingly readable.
Do you think a full reimplementation is necessary and realistically possible? Bash essentially provides a whole programming language. A bash-inspired custom syntax or a strict subset of bash might be the way to go.

Wow - it is surprisingly readable. How pleasantly rare.

I think you nailed it on what's needed, I was about to say the same things.
Getting through the manual myself, will update you in a bit.

As a sequence of actions, I think I'm going to start working on the shell parser / AST. If you continue on the control flow (CommandInstance), I think we can move along pretty well in parallel.

Ok, my next step after polishing CommandInstance (which mirrors 3.2.1 simple commands) is to build a CommandGroup, which represents one of some of the the subsections of command from 3.2 shell commands, i.e. simple commands, pipelines, lists and groups. Of course extensible to include the full 3.2.4 compound commands in the future.
A CommandGroup instance will have the same API as CommandInstance, so that all the command group functionality can be defined recursively and eventually boils down to simple CommandInstances. It will expose an API to create new CommandGroups from existing ones, representing pipes, lists and groupings. This API would be called from the parser / AST.
At a later point, the CommandGroup will also provide abstractions for 3.6 redirections, again accesible for the parser.
But before coding another line of javascript I have to take care of some other stuff first, which might take a few days. I'll still read everything and try to respond, though.
If you haven't built a parser/ast before, I recommend taking a look at this tutorial for a nice explanation of the manual process in js, and jison for automatic parser generation from a grammar (which is the approach I'd prefer). Or you might know this stuff already =)

Thanks.
js-shell-parse is very close on its AST, so it looks like I'm going to use it for now. He stopped maintaining it, so I'm going to fork it into the Vorpal org, and I got the nodeos guy to agree on working on it with me to finish.
Let me know when your time frees up a bit!

Sweet! I spent some time tinkering with the babel api, and I'm tempted to try the following for a basic shell implementation:

add a plugin to babel which parses command-expressions like foo | bar
use babel to compile the whole thing back to js
execute js in a vm

I'm not sure whether that is a very practical approach, but the idea is cool enough to build a prototype for. For vorpal, building on js-shell-parse should be the better plan.
As for useful stuff, I'll soon upload a process class with an API similiar to node's ChildProcess to represent parts of a command chain.

Okay, awesome. Maybe we should focus on the plan in line with Vorpal, just because its already a huge amount of work, and then once we have a proof of concept we can turn it into tons of powerful offshoots, like the babel one (which sounds like a cool idea!).
My thought is:
vorpaljs/bash-parser: Parses into AST
vorpaljs/bash: Takes parsed AST and does low-level, context-independent actions such as all of the expansions, blowing things up into full commands.
vorpal will then take a high level rendition of the command and throw it into CommandInstance for execution with proper flow control.

Just uploading this before going to bed, without finished tests or documentation: pseudo-process.
This could represent commands internally, with an API similiar to node's ChildProcess. Instances of PseudoCommand have methods to pipe and to redirect input and output. Also has a function to construct PseudoCommands from actual ChildProcesses.

Very nice!


Contribution to "Command Injection in Parse server"

Updates

CVSS
Description
Severity

Hi there @mtrezza! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.
This change will be reviewed by our highly-trained Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

Not sure what the intentions of these changes are.


TypeError in qlib/examples/workflow_by_code.ipynb

🐛 Bug Description

When I run the analyze graphs  section in the workflow_by_code.ipynb in Google colab, I got the following error message. The error came from the line of "from qlib.contrib.report import analysis_model, analysis_position". Everything above that line was running fine. May I know what is the reason for it and how to fix it?
TypeError                                 Traceback (most recent call last)
 in ()
----> 1 from qlib.contrib.report import analysis_model, analysis_position
2 from qlib.data import D
3 recorder = R.get_recorder(recorder_id=ba_rid, experiment_name="backtest_analysis")
4 print(recorder)
5 pred_df = recorder.load_object("pred.pkl")
14 frames
/usr/local/lib/python3.7/dist-packages/distributed/config.py in ()
18
19 with open(fn) as f:
---> 20     defaults = yaml.load(f)
21
22 dask.config.update_defaults(defaults)
TypeError: load() missing 1 required positional argument: 'Loader'
To Reproduce
Steps to reproduce the behavior:
1.Load qlib/examples/workflow_by_code.ipynb in Google Colab
2.Run the code from the beginning to the "analyze graphs"  section
3.The error will show up when runs the line "from qlib.contrib.report import analysis_model, analysis_position"
Expected Behavior

Screenshot

Environment
Note: User could run cd scripts && python collect_info.py all under project directory to get system information
and paste them here directly.

Qlib version:
Python version:
OS (Windows, Linux, MacOS):
Commit number (optional, please provide it if you are using the dev version):

Additional Notes

The first thing I'll try is to  see if the fn exists:
os.path.exists(fn)
and start from there.

Me too when doing 'python run_all_model.py run 3' .

My bugs:
File "run_all_model.py", line 385, in
fire.Fire(ModelRunner)  # run all the model
File "/home/wlh/anaconda3/envs/qlib/lib/python3.7/site-packages/fire/core.py", line 141, in Fire
component_trace = _Fire(component, args, parsed_flag_args, context, name)
File "/home/wlh/anaconda3/envs/qlib/lib/python3.7/site-packages/fire/core.py", line 471, in _Fire
target=component.name)
File "/home/wlh/anaconda3/envs/qlib/lib/python3.7/site-packages/fire/core.py", line 681, in _CallAndUpdateTrace
component = fn(*varargs, **kwargs)
File "run_all_model.py", line 40, in _return_wrapped
return function_to_decorate(*args, **kwargs)
File "run_all_model.py", line 320, in run
yaml_path = gen_yaml_file_without_seed_kwargs(yaml_path, temp_dir)
File "run_all_model.py", line 190, in gen_yaml_file_without_seed_kwargs
config = yaml.load(fp)
TypeError: load() missing 1 required positional argument: 'Loader'

May I know any advice from Microsoft team?

This is likely due to your pyyaml version. See here https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col for a similar problem.
If your pyyaml version is 6.0 in your environment, try downgrade it to 5.4.1 to see if the problem goes away:
pip install pyyaml==5.4.1

I have added pip install pyyaml==5.4.1 in
# install qlib
! pip install --upgrade numpy
! pip install pyqlib
! pip install pyyaml==5.4.1

but got another error
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
yellowbrick 1.3.post1 requires numpy<1.20,>=1.16.0, but you have numpy 1.21.5 which is incompatible.
datascience 0.10.6 requires folium==0.2.1, but you have folium 0.8.3 which is incompatible.
albumentations 0.1.12 requires imgaug<0.2.7,>=0.2.5, but you have imgaug 0.2.9 which is incompatible.
Successfully installed numpy-1.21.5
WARNING: The following packages were previously imported in this runtime:
[numpy]
You must restart the runtime in order to use newly installed versions.

Will  https://github.com/microsoft/qlib/pull/853/files#diff-25cbd3758720e92892899650518bd0168c8d742ad65cdf895ce75c437ae7ea08R189  fix this issue ?

@you-n-g running !pip install pyyaml==5.4.1 before anything else in the notebook, with pyqlib v0.8.4 everything in the file runs and is displayed correctly. Your merged PR seems to have fixed the issue, provided you downgrade to that version of pyyaml first (otherwise the error is still there).


Dose sails has any middleware or any callbacks to do some extra actions before or after certain model methods, e.g. Logging project create

Node version: v14.16.1
Sails version: 1.4.2
ORM hook version: 3.0.2
Sockets hook version: 2.0.0
Organics hook version: N/A
Grunt hook version: 4.0.0
Uploads hook version: N/A
DB adapter & version<EMAIL_ADDRESS>Skipper adapter & version: N/A

Hi I am developing a Sails app and I want to store all users' actions in a Log model. Such as logging the action of creating a project as below:
const new_project = await Project.create(project_data);
await Log.create({
      id,
      actionType: "create",
      tableName: "project",
      content,
      created_by,
      created_at
    }).;

However, there are too many controllers. I need to copy above code and paste it in many controllers for each action (create, update, delete). Is there any method to solve this problem?
Thanks

Hi @AlanNggg, You might want to create a helper that creates logs and call it in your controllers instead. you can read about helpers in our docs https://sailsjs.com/documentation/concepts/helpers#helpers

Hi @eashaw, I also wonder what should I use if I want to check whether something exists in many controllers.  Such as c checking whether a project exists as below:
const project = await Project.findOne({id: projectId});

if (!project) {
      return this.res.badRequest(ErrorResponse.PROJECT_NOT_EXIST);
}

Should I use helper or is there a better way?
Thanks

@AlanNggg, In projects we've worked on, we've found it best to keep validations like your example in the controller in case you need other validations.

Thx


Mesh colliders

More "real" simulations often involve complex collider geometry that must be modeled accurately in the simulator.
Convex hull is probably sufficient.  Would need to support not just Mesh<>Mesh, but also Mesh<>Capsule, Mesh<>Plane, ...

As of e2ab3aaa84f1d6ae1280ec79c5d77fb44e9c3777 we now have initial support for mesh colliders, but right now have only implemented mesh<>plane and mesh<>capsule.  Check it out!
Before we call this done we'd also like to add mesh<>mesh and also some example documentation for how to use it, perhaps include it into the colabs.
But for now, here's the Utah teapot colliding with a plan and a cylinder in Brax:

Interesting. Ive wondered how to elegantly implement this kind of thing in brax. Never tried my hand at it, but it occurred to me that deepSDFs might be the way to go here. Given a function to find intersection points between two SDFs, and some handcrafted SDFs for simple primitives, it should be easy to just fit SDFs to arbitrary meshes using established techniques, and you should have a very nice and generic framework, that should paralelize just fantastically on the TPU.
Some googling shows this hot off the press. Nothing remarkable here, just an implementation of the above. But the performance comparison is interesting. It seems to compare favorably in terms of compute/memory tradeoff; and I think the compute would look even better if youd consider it in the context of a parallelized simulation running many actors batched in the same env.

Speaking to the notion of 'good enough'; seems like the current box-box collision implementation only handles box-corner contacts; and as such probably yolos the edge-edge contact scenario entirely. Would be an interesting exercise to reimplement the box-box logic as more generic convex hulls, implemented as 'handcrafted deep SDFs'; a convex hull is just the max over a bunch of linear projections, after all. That would make improving edge-edge handling easy; just spawn some extra vertices on the edges.

Hi, can you share a code for the teapot or some other example of using meshes? I am trying to simulate lifting a box with outer boxes, but there are no box vs box colliders.

Yes certainly, please see the mesh test here:
https://github.com/google/brax/blob/main/brax/tests/physics_test.py#L305
Config specifies a mesh path which is loaded from disk, in this test's case here:
https://github.com/google/brax/blob/main/brax/tests/testdata/cylinder.stl
We currently support mesh<>plane and mesh<>capsule, as demonstrated in the tests.  Mesh<>mesh development is in progress.  Hope that helps!

thanks, @erikfrey! will check it out.

Closing this issue as we now have general convex colliders now implemented:
https://github.com/google/brax/blob/f0de0e56126b7cd7cdf941f0fc02f3480a02716a/brax/v2/geometry/contact.py#L441-L454


xrefs should work when selecting function name in the header at the top of graph

Selecting the function name in the prototype bar at the top of a graph does not update xrefs, but should

I think I already fixed this. Will double-check and find a version number

implemented in dev 2.1.2385


added getTypes() method

See: https://jira.duraspace.org/browse/FCREPO-1717

I added some debug logging in the getTypes() implementation and cleaned up the unit test.

This looks good.

Resolved with: https://github.com/fcrepo4/fcrepo4/commit/b03c4ea93d0471f2c46ba2c626d3e2427429a41d


Add markdown extension

My guess is that using markdown will be the common case, so it should be easy to use it.

This is not within the scope of the project. Users are free to extend the project to handle markdown if they like (and instructions are here) but staticjinja is only ever going to compile Jinja2.


Cleanup Windows libc-test build.rs

@gnzlbg: no appropriate reviewer found, use r? to override

@retep998 I don't have a windows machine to test, so i'm basically relying on travis. I wanted to get those tests to pass before starting to remove all the unnecessary stuff. There is a ctest option, cfg.verbose_skipped(true) which dumps which variables are actually skipped.  Any idea of what's going on ?

Also I tried to remove the Winsock2.h header, but too many exposed APIs use the SOCKET type defined there.
We should probably open new issues for these things, and fix them in a subsequent PR. There are probably some more unnecessary headers and things that can be removed from the build.rs.
Now that this PR separates that from the rest, doing that shouldn't be too hard.

@bors: r+

:pushpin: Commit 0980cf593aa75ab1f3e890c8dc43dcba025a7b49 has been approved by gnzlbg

:hourglass: Testing commit 0980cf593aa75ab1f3e890c8dc43dcba025a7b49 with merge 2ea72069e21e4d2f32520d7574cd294d91a5e9f2...

:sunny: Test successful - checks-cirrus, checks-travis, status-appveyor
Approved by: gnzlbg
Pushing 2ea72069e21e4d2f32520d7574cd294d91a5e9f2 to master...

It appears that on all windows builds, the functions are pointing to incorrect addresses. Any idea of what's going on ?

@gnzlbg Rust makes it really unwieldy to choose whether to specify dllimport because it determines it from #[link] blocks directly attached to the extern {} block. Because libc chooses what to link to separately from where it specifies the symbols themselves, dllimport is not specified despite those symbols coming from dlls. Without dllimport Rust generates code that cannot be relocated at runtime, so the Rust code ends up linking against thunks that in turn call the actual functions.

@retep998 is there a way to do that correctly? Maybe we shouldn't be using #[link] blocks here but something else. In particular, if the libc-test are not linking the appropriate functions at run-time, I have no reason to believe some other code will magically do that. So I wonder if using windows api via libc is FUBAR or how is anyone getting this to work at all?

It still works, it's just not as efficient because the function calls are going through thunks instead of being done directly. It's a tricky problem to fix because if you want dllimport to be specified you have to slap a #[link] block on every extern {} block, and that gets somewhat annoying. If your bindings are split up into multiple extern {} blocks, then you end up with the same library specified multiple times in the linker command line. If you have complicated logic around deciding which library to link to (say UWP vs desktop libraries, or static vs dynamic CRT), then that logic gets replicated on each extern {} block. While for winapi in the future this won't be relevant anymore once it uses kind="raw-dylib", for libc this will remain an issue as it does not know which version of the CRT it is linking to and therefore which dlls the symbols come from.


Spawning

Viridian city spawns correctly, and Route 1 spawns only once. Also, spawnedBy timestamps now stay consistent, even after going through transporters.

swag


Is recalculateLayoutOnMouseUp deprecated in version 4.1.65?

Hi Scott,
I'm finally doing an upgrade from 40.2 (or a similar early version) and I'm coming across a few quirks. The biggest however right now is finding a solution to "recalculateLayoutOnMouseUp"
I can't find where it is documented any more, and my app is littered with statements for this call.
Did I miss something in the upgrade? Is it deprecated? I see plenty of other examples using it, but it's not working for me.
 'Configuration' does not contain a definition for 'recalculateLayoutOnMouseUp' and no accessible extension method 'recalculateLayoutOnMouseUp' accepting a first argument of type 'Configuration' could be found (are you missing a using directive or an assembly reference?)
Cheers,
Steve

And yes, it's a .NET 4.8 c# winforms app.

@vrdriver It looks like you are upgrading your project from a far away version.
I am not a ScottPlot specialist (I am using it since about 6 month), but after taking a look at the source code and the Git history, the parameter recalculateLayoutOnMouseUp has been removed.
In fact, the complete initialisation of ScottPlot has drastically changed between 4.0.xx and 4.1.xx, perhaps you should take a look at the very good documentation:

https://scottplot.net/quickstart/winforms/
https://scottplot.net/faq/version-4.1/
https://scottplot.net/cookbook/4.1/

Thanks @KroMignon. I've had a look at the upgrade page about 4.1 and the basic function changes, but it didn't mention anything about deprecated functions such as this one.

Hi @vrdriver and the group,
Unlike ScottPlot 4.0 which only recalculated the layout after the mouse button was released, ScottPlot 4.1 recalculates the layout continuously (before each rendered frame). This means the recalculateLayoutOnMouseUp() function is no longer necessary!
If you wish to have more advanced control over the layout (or disable the automatic adjustment) more information can be found here: https://scottplot.net/faq/layout/

Ok, thanks @swharden and @KroMignon That all makes sense now.
Yes, I was coming from a much earlier version, and I've managed to get the program running again after changing plenty of things. Now to work on the new layout methods and the 4.1 way of doing things and tweaking even more. Thanks again.


Making Myo Armband vibrate

Hi, I would like to know how to make the myo armband vibrate (sorry, I'm not an expert of Python).
Here is my code:
import time
import myo as libmyo
libmyo.init('D:/Program Files/myo-sdk-win-0.9.0/bin')

class Listener(libmyo.DeviceListener):

    def on_connect(self, myo, timestamp, firmware_version):
        print("Hello, Myo!")

    def on_disconnect(self, myo, timestamp):
        print("Goodbye, Myo!")

    def on_battery_level(self, event):
        print("Your battery level is:", event.battery_level)

    def on_pose(self, myo, timestamp, pose):
        if pose == libmyo.Pose.fist:
            print("Pose: Fist")
            return False
        if pose == libmyo.Pose.double_tap:
            print("Pose: Double tap")
            return False

hub = libmyo.Hub()
listener = Listener()
hub.run(1000, listener)
try:
    while hub.running:
        print("listening")
        time.sleep(0.5)
except KeyboardInterrupt:
    print("Quitting...")
finally:
    hub.shutdown()

If I want to make the armband vibrate just after the fist pose detected, what should I add?
I saw that there is the function vibrate() in the class MyoProxy, and I tried some things, but I didn't succeed.
Thank you in advance

Hi @Mel-Srt ,
there's some code in the examples:
https://github.com/NiklasRosenstein/myo-python/blob/1a07093ff1d7d485f9ef8f47aad07586da22f4fb/examples/hello_myo.py#L66-L68
Does this help you?


[issue 9585][Consumer]delete disconnected consumers to allow auto-discovery

Fixes #9585
Motivation
Explain here the context, and why you're making that change. What is the problem you're trying to solve.
Modifications
Describe the modifications you've done.
Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API: (yes / no)
The schema: (yes / no / don't know)
The default values of configurations: (yes / no)
The wire protocol: (yes / no)
The rest endpoints: (yes / no)
The admin cli options: (yes / no)
Anything that affects deployment: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

yes sure !

I should be OK now but the CI workers seem hanging...

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks


[Cleanup] Break IntermediateResultsBlock into different results blocks

Currently IntermediateResultsBlock is used for all types of queries, which makes it quite complicated because it needs to hold all different types of responses and handle the data table conversion for all of them.
This PR breaks it into different results blocks for different types of queries so that the logic is simpler, and future changes are easier

Codecov Report

Merging #9282 (806a07f) into master (88bb40c) will increase coverage by 1.50%.
The diff coverage is 89.85%.

@@             Coverage Diff              @@
##             master    #9282      +/-   ##
============================================
+ Coverage     68.42%   69.93%   +1.50%
+ Complexity     5016     4695     -321
============================================
  Files          1864     1870       +6
  Lines         99469    99436      -33
  Branches      15133    15121      -12
============================================
+ Hits          68060    69537    +1477
+ Misses        26560    24968    -1592
- Partials       4849     4931      +82

Flag
Coverage Δ

integration1
26.26% <65.07%> (?)

integration2
24.90% <70.74%> (+0.06%)
:arrow_up:

unittests1
67.10% <83.58%> (+0.01%)
:arrow_up:

unittests2
15.29% <0.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...operator/AcquireReleaseColumnsSegmentOperator.java
0.00% <0.00%> (ø)

...ot/core/operator/blocks/InstanceResponseBlock.java
50.00% <ø> (-6.25%)
:arrow_down:

...ot/core/operator/combine/CombineOperatorUtils.java
100.00% <ø> (ø)

...a/org/apache/pinot/core/plan/DistinctPlanNode.java
86.95% <ø> (ø)

.../org/apache/pinot/core/plan/SelectionPlanNode.java
100.00% <ø> (ø)

...perator/query/DictionaryBasedDistinctOperator.java
76.08% <50.00%> (ø)

.../pinot/core/operator/InstanceResponseOperator.java
75.00% <72.72%> (-2.36%)
:arrow_down:

.../core/operator/query/SelectionOrderByOperator.java
87.84% <75.00%> (ø)

...reaming/StreamingSelectionOnlyCombineOperator.java
66.00% <84.61%> (ø)

...e/operator/blocks/results/GroupByResultsBlock.java
85.71% <85.71%> (ø)

... and 165 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


OP_RETURN script length inconsistent

nStratis allows OP_RETURN scripts up to the maximum length currently supported in Bitcoin itself (83 bytes).
The Stratis GUI wallet (currently <IP_ADDRESS>) rejects the resulting OP_RETURN transaction from nStratis with an error in debug.log:
ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
It appears that scripts < 40 bytes are accepted, so the length validation is incorrect in either nStratis or the wallet.

I think we should fix this on the stratisx wallet


remove unsafe_eval from CSP policies

We should investigate how to fix the webpack configuration so it doesn't break on runtime because of string evaluation to javascript.

To reproduce, one would remove "'unsafe-eval'" from the csp config and re-run invenio-cli update, correct? And something should break?

Yes, you would see that there is an error in console at the point that webpack is injecting a script tag to include the react application. You will see that the application is never rendered!

I was able to reproduce but unfortunately spent the afternoon on this and got nowhere slowly. This thread: https://github.com/webpack/webpack/issues/5627 seemed to be about this, but a better knowledge of webpack than I have is needed to understand what they are talking about.
good luck!


Group chat tab with dynamic preview and sorting

When viewing the list of member groups, incoming messages should dynamically update and re-order the list.
Screenshot

/gcbrun


Error passing parameters --environment-variables

Hi Team,
I'm trying to pass my parameters as I already use in the docker but it's failing. I have the block called 'app' where I have my internal parameters.
Docker Sample
-e app= 'MyInternalValue=3,myname=true'
-e db= 'Load=true, othervalue=true'
az containerapp create -n $app -g $group -e $appenv -i $myimage  --registry-login-server $myimagelogin
--registry-username $acrid --registry-password $acrkey --target-port 80 --ingress 'external' --query configuration.ingress.fqdn -v app='MyInternalValue=3,myname=true'
Result:
Environment variables must be in the format "=,=secretref:,...".
Note:
I believe the rule should not validate my internal value 'MyInternalValue=3,myname=true'

Hi @ramonduraes , thanks for reporting the bug. As an immediate mitigation, please use the create command using a yaml configuration (--yaml parameter). We will work on a bugfix for environment variables with "," and "=" characters in the value

Hi @calvinsID Thanks. Do you have an example of this yaml?

This is fixed in the new CLI extension, secrets/env variables are now space delimited


Initial signed commit readme update, 1st since 2015

Try this pull

Anyone out there to review and close that?

Can I be the one that rights the review here?

Commenting on this @GroundRod
(Sorry for such late response. I haven't been checking in on Github lately.)


Document how to use shebang in environments where env -S is not available

Version(s)
Latest one
Describe the bug
I'm writing a script for Amazon Linux.
Here is how the script starts:
#!/usr/bin/env -S scala-cli shebang

The problem is that env doesn't have the -S option
In Ubuntu that option does exists, but in Amazon Linux (Red Hat based) doesn't:
NAME
       env - run a program in a modified environment

SYNOPSIS
       env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]

DESCRIPTION
       Set each NAME to VALUE in the environment and run COMMAND.

       Mandatory arguments to long options are mandatory for short options too.

       -i, --ignore-environment
              start with an empty environment

       -0, --null
              end each output line with 0 byte rather than newline

       -u, --unset=NAME
              remove variable from the environment

       --help display this help and exit

To Reproduce
Run a script
Expected behaviour
Scripts are easy to write.
Only workaround I can think of, is to create an auxiliary script like:
$cat scala-cli2
exec scala-cli shebang "$@"

What I've done as a workaround is install GNU env in /usr/llocal/bin and then reference it from my shebang line.
Another workaround would be to hardcode the location of scala-cli in the shebang line. (If the full path is unwieldy, a symbolic link can be made from /usr/local/bin or wherever to the real path.)
I think this is not a bug in scala-cli, but perhaps the documentation could say something about it.

I think this is not a bug in scala-cli, but perhaps the documentation could say something about it.

I agree on this. We should add a section about it in the shebang sub-command and scripts-related docs. Not much else that we can do with this on Scala CLI side, I think.

With Ammonite scripts,  I haven't experienced this problem, as I don't need to pass any special arguments.

This problem exists also in Alpine Linux, that I use often in containers.


Drag Object and get Value?

Hi guys,
it's more a question than an issue, but what and how is the event i have to listen for, to get the last added Item? I have 2 components, and i want to drag from one to another. How can I access the dropped Object in the 2. component?
Thx

hi @Helmi-helmutson
onAdd event is what you are looking for if it is cross-container, onUpdate if it is within the same container.
Does this help?

closing for inactivity


Fix "magic" so it just uses the metatable of the Context

(and avoid creating new metatables everytime a new context is created).

Thanks! Tagged as v1.3.1-0.


feat(useFetchData): 增加错误抛出

onRequestError 这个方法不是必传的参数，在没有传递这个参数的时候，如果在请求数据和数据处理过程中，出现问题，比如调用了错误的方法，错误会被吞并，导致难以定位问题。

Codecov Report

Merging #636 into master will decrease coverage by 0.24%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master     #636      +/-   ##
==========================================
- Coverage   17.43%   17.19%   -0.25%
==========================================
  Files          21       21
  Lines        1147     1146       -1
  Branches      374      374
==========================================
- Hits          200      197       -3
- Misses        947      949       +2

Impacted Files
Coverage Δ

src/Table.tsx
20.47% <ø> (-0.28%)
:arrow_down:

src/component/toolBar/index.tsx
6.77% <0.00%> (-0.12%)
:arrow_down:

src/useFetchData.tsx
31.25% <40.00%> (-2.60%)
:arrow_down:

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 11c3709...e097315. Read the comment docs.


Improve pset.execute time management

This PR fixes #1625

converting to draft until I've managed to take a look at refactoring the pset.execute() loop


Representation of the structured sections in the composition

The HDR model includes some very strcutured sections see e.g http://hl7.eu/fhir/hdr/StructureDefinition/AdmissionEvaluation or HospitalStay or the recommendations section. that includes also the "medication recommended for the period after discharge".
A similar structured structure was present aso in the PS model that have been at the end represented as a flat slit of content-oriented sections.
Should the Composition structure reflects the model structure or it should be flat as it is for the PS and substantially in the CCDA Discharge Summary https://build.fhir.org/ig/HL7/ccda-on-fhir/StructureDefinition-Discharge-Summary.html

If we go for structured Composition as in the Logical Model there are some cross-issues:

A.2.6.1 - Medical history
A.<IP_ADDRESS> - History of problems
A.<IP_ADDRESS> - Devices and Implants
A.<IP_ADDRESS> - History of procedures
A.<IP_ADDRESS> - Vaccination

In PS there is:

A.2.2 Medical history
A.2.2.1 Vaccination/ prophylaxis information
A.2.2.2 Resolved, closed or inactive problems
A.2.2.3 Medical history

Also w/o devices and procedures which are in:

A.2.3 Medical problems
A.2.3.1 Current problems
A.2.3.2 Medical devices and implants
A.2.3.3 Procedures
A.2.3.4 Functional status

So the meaning of "Medical problems" as a section is different in HDR and PS, and there are 2 "Medical history" sections in PS, one a composite one (A 2.2) and a narrative one (A.2.2.3).
If we flatten the PS and HDR in a flattened Composition with just the lowest section level:

is is much easier to have - where the content fits - the same section in HDR and PS
we avoid the problem of having to find LOINC codes for "Medical history" (3 times), as well as some other incongruencies between PS and HDR Logical Model

Capturing (I hope rightly) the discussion on 22 Nov 2024: we start with a "library" of low level sections and for now a flattened Composition. On al logical model (EU, national, or other)  those can be aggregated in composite sections and a mapping can reflect that. Open question is whether there is an appropriate code for such a section which captures "staging" semantics (admission, stay, discharge) but we can see that when we model the low level sections.

And there was the comment that the incongruencies between HDR and PS logical models I mentioned above are being addressed within XtEHR

Question from Kari:
I might be missing something obvious but the HDR Composition section:sectionAdmissionEvaluation (LOINC 67852-4) and section:sectionDischargeDetails (LOINC 8650-4) seem to have similar sub-sections as sliced by SCT codes i.e. currently the hierachy is used to nominate the context. How would these work in the flattened model ? Find new 'magic values' that combine current stage designation (LOINC) and data category (SCT) ?

Decision from the 2024-11-22 meeting "We offer library of sections in a flat structure, and provide mapping to models. Implementers are allowed to use subsections."

Capturing (I hope rightly) the discussion on 22 Nov 2024: we start with a "library" of low level sections and for now a flattened Composition. On al logical model (EU, national, or other) those can be aggregated in composite sections and a mapping can reflect that. Open question is whether there is an appropriate code for all such sections which captures "staging" semantics (admission, stay, discharge) but we can see that when we model the low level sections.

This is another issue (a) for not all of them exist a 'context' specialized LOINC e.g. there are for medication but not for others (b) an pen question is if we should look in any case for generic containers to be used both an higher or at a lower level or not (c) how much we should be generic e.g. I choose Discharge Summary medication instead of Hospital Discharge medications to possible reuse that section for other discharge summary is this ok ?

Changed applied.. should we keep this issue open or not ?


Cndb 8696

Renamed from https://github.com/datastax/cassandra/pull/998

There is one test failure https://jenkins-stargazer.aws.dsinternal.org/job/ds-cassandra-pr-gate/job/PR-1014/2/testReport/junit/org.apache.cassandra.distributed.test/SSTableIdGenerationTest/tests_stage_1___jvm_distributed___testSnapshot/ which feels like a general flakiness related to closing the in-jvm dtest cluster. I'm going to ignore that because it is not related to this ticket.

Rebased and squashed, once the build is done, I'll merge it

Publishing artifacts: https://jenkins-stargazer.aws.dsinternal.org/view/cc-builds/job/ds-cassandra-publish-j11/418/


fix(tooltip): series enterable

close: https://github.com/ant-design/ant-design-charts/issues/2560

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.009%) to 86.414%

Totals

Change from base Build<PHONE_NUMBER>:
-0.009%

Covered Lines:
10392

Relevant Lines:
11647

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.009%) to 86.414%

Totals

Change from base Build<PHONE_NUMBER>:
-0.009%

Covered Lines:
10392

Relevant Lines:
11647

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.009%) to 86.391%

Totals

Change from base Build<PHONE_NUMBER>:
-0.009%

Covered Lines:
10397

Relevant Lines:
11657

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.009%) to 86.391%

Totals

Change from base Build<PHONE_NUMBER>:
-0.009%

Covered Lines:
10397

Relevant Lines:
11657

💛  - Coveralls


New message marker and new message badge are not dismissed when user opens report via URL - Reported by: @parasharrajat

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open two browsers.
Login with Account A in browser A.
Login with account B in browser B.
Close app on browser B.
Send message from account A from browser A to account B.
Copy the report url from browser a.
Go to browser B.
Paste the url of the Report you copied.

Expected Result:
New marked and badge should be dismissed if the user pressed on the badge.
Actual Result:
New marked and badge are not dismissed if the user pressed on the badge.
Workaround:
None needed, visual issue.
Platform:

Where is this issue occurring?

Web

Version Number: 1.1.7-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/44479856/137184320-661b4ad8-7281-4e0d-b244-07cc910b4dd0.mp4
Expensify/Expensify Issue URL:
Issue reported by: @parasharrajat
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1633934312104700
View all open jobs on GitHub

Triggered auto assignment to @chiragsalian (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Triggered auto assignment to @jboniface (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

12 days overdue. Walking. Toward. The. Light...

Noice, reproduction steps seem clear & straightforward. Ready for proposals

Not overdue, waiting for proposals

Proposal

I think we just need to change the callback called on MarkerBadge onClick to scrollToListBottom method of the ReportActionsView.js instead of scrollToBottom.

Previously, scrolling the list to the bottom will mark the latest last read but now I think this behaviour is recently changed to keep the markasUnread messages after the app is put to the foreground from the background.
So now we need to explicitly mark the message read as well as scroll the list to the bottom which scrollToListBottom does.

@parasharrajat that sounds like a great idea, nice and simple too - go ahead and submit a PR when you can 👍

Not overdue, waiting to get merged into Production

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.1.16-10 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

https://github.com/Expensify/App/pull/6328

If no regressions arise, payment will be issued on 2021-12-06. :confetti_ball:

hey @parasharrajat, i invited you to this job, but it looks like you might have missed it on upwork. can you respond to the invite or re-apply, so I can pay you out?

no worries. paid with hold and reporting bonuses.


Enhanced Editor - Preset value table

1:  Change column Field Alias to Just Field
2:  Match table to attribute inspector, dijit input inner css

Can we right justify the preset value label or align with text boxes?

I think this should already be fixed with my recent check-in. Please let me know if it's not. Thanks.

Verified


search for how to use rasbperry pi gpio with rust & assign expected time to implementation

General note
First to interact with the gpio we should prefer an implementation that do not use quite complicated abstraction (e.g. sysfs /sys/class/gpio/, chardev /dev/gpiochip) as we would have to put it in the computing base and complicated abstraction are more prone to implementation error or even use error. Moreover, minimal OS have less chance to offer it. For now my preferred abstraction to use would be /dev/gpiomem or /dev/mem.
First way of access to GPIO
To start we are going to interact with the gpio using a library, rppal seem like a good choice (see https://docs.rs/rppal/0.12.0/rppal).
Second way of access to GPIO
Then if do not want to put the library in the trusted computing base, we could implement an API from user space to access the gpio.
Final way of access to GPIO
If we then move to a minimal OS, we could either implement the abstraction used in the previous step. That should not be too hard, or write implementation of the previous API, that we can call, in the kernel space, i.e. where the physical memory address are similar to the virtual memory address.


Some more string functions

I know we generally do not want to bloat Ramda with functions that are easily created, but I find myself creating these functions when manipulating strings all the time. They're so simple and help with point free programming so I still think we should consider adding them.
const prefix = R.add
const suffix = R.flip(R.add)
const startsWith = R.curry((q, str) => str.startsWith(q))
const endsWith = R.curry((q, str) => str.endsWith(q))
const stripl = R.curry((q, str) => startsWith(q, str) ? str.slice(q.length) : str)
const stripr = R.curry((q, str) => endsWith(q, str) ? str.slice(0, str.length - q.length) : str)
const strip = R.curry((q, str) => stripl(q, stripr(q, str)))

What do you think?

I'm pretty sure they're trying to minimize aliases (R.add -> prefix and its fipped counterpart).
I'm on board with starts/endsWith, except keep in mind your implementation is not ie friendly
Not on board with your implementations of stripl/r simply because it's not in lodash.  My only reasoning for adhering to lodash in this case is that it's likely the most popular utility lib next to underscore.  If lodash hasn't found a need to implement those functions, then, considering ramda's smaller string category, I would assume it shouldn't be implemented here.

You can use underscore.string.fp or other string manipulation library.

Nice library - thanks for mentioning it.
Notice their aliases conflict with OP's strip implementation

strip     = trim
lstrip    = ltrim
rstrip    = rtrim

Hmm. I just find it so awkward that I have to keep writing these functions. Seems like JS should really just have a standard lib...

I'd like to leave this open for a few days to give others a chance to comment.

That works for me :)

If lodash hasn't found a need to implement those functions, then, considering ramda's smaller string category, I would assume it shouldn't be included here.

I wouldn't buy that at all.
You might notice, in fact, that lodash/fp is essentially an API clone of Ramda, with an entirely different implementation (and, of course, assorted incompatibilities.)
Ramda looks to lodash/underscore/FKit/fn.js/fnuc/wu/sugar/lazy/Bilby/whatever when we're building new functions to see if there's clear consensus on naming that we can willingly join.  Occasionally we'll look at others for their implementations of functions, especially if there seems to be an issue with our own.
But mostly we strike out on our own, building functions that seem useful to our community, and paying little heed to these others.

I'm pretty sure they're trying to minimize aliases

More like: entirely avoid aliases.

(edit: though I haven't read enough to understand their criterion for when aliases are ok)

Never.  See the parable by @davidchambers .
But note that the suggested prefix would not be a true alias of add, even if it could be implemented as such due to the overloading of + in JS.  It's simply not the same logical function.

I know we generally do not want to bloat Ramda with functions that are easily created, but I find myself creating these functions when manipulating strings all the time.

These feel more suited to the Cookbook to me.  I don't feel there is likely enough call for them to include them in Ramda itself.  I did have to write startsWith and endsWith on a recent project, but that's one time in my 3+ years with Ramda.  The others I've never written with Ramda.
Other thoughts?

But mostly we strike out on our own, building functions that seem useful to our community, and paying little heed to these others.

Hmm - I respect that decision though think you should consider the popularity of functions that other libraries include.  Functions are only popular out of need, and those which this community needs will not deviate much from the greater javascript population (besides those specific to functional programming of course)

parable

haha thanks for the correction and the link.  I definitely agree.

It's simply not the same logical function.

Somehow I missed that and just assumed he was referencing R.concat which is already overloaded for such functionality.

We do consider functions for which people make requests, and popular functions from other libraries are more likely to be raised that way.  But their popularity is a fairly small factor.  We're much more interested in how useful they seem to us, how well they fit with Ramda's philosophy (we wouldn't even consider an impure function, for instance), how easy/difficult they are to implement, and how much excitement they generate in our discussions, all sorts of factors.

I appreciate the time you put into explanations @CrossEye .  Helps me learn a lot.

These feel more suited to the Cookbook to me. I don't feel there is likely enough call for them to include them in Ramda itself.

Well you could say this about a lot of Ramda functions though:
concat = R.curry((a,b) => a.concat(b))

Why is concat in Ramda and not just in the cookbook? Maybe I have a different perspective here, but I like to think of Ramda as a standard library for my projects. And in that regard, I find it convenient to have these sorts of string functions...

concat is not a good example to illustrate the point you are trying to make. that is the fundamental operation that defines a semigroup. So it makes sense we would take control of that one.

Yeah, but my point is that we shouldn't have concat -- I would like to see Ramda have all kinds of useful functions. Even if they are one liners.

@ccorcos i am 100% in the other direction. I'd love to see the lib pared down to just the essentials. should make for interesting discussion :-)

I'll be the referee; I keep bouncing between these two points of view, but can't quite find the balance I'd like to strike.

Well one place to start is the left-pad fiasco. Surely, you could write your own, and there are a million ways to do it. Here's my one liner:
const leftPad = (str, n, char) => Array(Math.max(str.length - n, 0)).fill(char).concat([str]).join('')

But why should I have to write and test this function?
So then I might go looking on npm.  I was no expecting that... I'm sure this function works though and now I don't have to write test for it. But now we're just bloating our dependencies (and then the whole left-pad fiasco). Sure I could use underscore.string, but the arguments are going to be in the wrong order and thats really annoying.
So what if you could just use R.leftPad? Its going to be curried. There arguments are going to be in the correct order. Its going to be tested, and we're using Ramda everywhere already! So whats the harm? Its not like leftPad is going to involve any maintenance for the library maintainers. Or maybe you're worried about the side of the library? Well its not to hard to create a babel plugin to cherry-pick only the functions you want from Ramda.
So that's it for my main argument, but while we're on the topic, I want to fantasize a little bit...
I would love is Ramda become something like a standard library. Why do I need to write R.map -- shouldn't I be able to just write map? What kind of language doesn't have a map?! What if Ramda's functions were just global and you can use them freely. leftPad, stripl, startsWith... It would feel a lot more like programming in a language like Clojure which comes with batteries included.
Idk if you guys have seen the Wolfram Language but its one of the most incredible things I've seen. They take "batteries included" to the max.

Any reason R can't be the bare-bones behind R.contrib (similar to lodash & underscore.contrib?)
https://github.com/node4good/lodash-contrib
Fwiw, I've never had an issue keeping my own set of utilities because I'm fully  aware of the ambiguity surrounding what functions "should" be in any given library.  In fact, functions that I write are more dependable than those from other libs which, although tested, still behave differently than my intuition expects.

I second olsonpm's approach. This way the core would't become bloated, yet one could use a community driven utility lib for extended purposes.

I suppose... But thats just fragmenting the ecosystem even more... :/

It's the only solution to satisfy both trains of thought, and it's a proven solution.  You are never going to convince the maintainers of a given library to support "all kinds of useful functions".  I think of 'contrib' similar to community supported packages in a given linux repo.  Along with installing those packages comes added risk, less support, and all around more responsibility.

I could certainly live with such a solution.  It's been discussed several times, but no one has stepped forward to own it.  Such a package could clearly live in the same space that ramda-fantasy, ramda-lens, etc. live.  But it would be nice if there was some folks who wanted to own maintenance of it.
Of course I'm sure we'd still want to insist that the functions match Ramda's philosophy and design, but there could be less vetting of whether they were important enough to be included in the core.

Yeah that's another issue.  Finding someone who wants to invest that amount of time heh.

And documentation...


matplotlib 3.6.3 bug when changing the norm of CameraDisplay after adding a colorbar

In https://github.com/cta-observatory/ctapipe/pull/2207/commits/a6dc89238d33f09d75627ec864d34236b6114a57 I introduced a test that is skipped in matplotlib 3.6.3 showing the difference.  This test should run regardless of the version.
I tried to narrow it down, and it seems like the values that should get scaled are the values of the colors inside the colorbar, not the values they represent. E.g. the "colors" are always 0--1, but the values they represent are like 10--100 or whatever.
When adding the colorbar to images with values 10--100, the colorbar-values are 0--1. Changing the norm to logarithmic now tries to scale 0--1, which is of course not possible (log(0, 1) == -inf, 0).
I don't know if this is really a bug in matplotlib or in our way of handling the norm on patches of pixels.

Definitely a bug in matplotlib, issue: https://github.com/matplotlib/matplotlib/issues/25077

Fix was merged, to be released with 3.7

matplotlib 3.7 is released since quite a while, let's close this


[Feature Request] Setting to disable tray

Ability to have settings dependencies in the custom settings page, if user doesn't want to close to tray, they may want to disable tray icon all together.


Red background when hit #59

👉 Checklist

Please make sure to check off the following before submitting:

[x] I have reviewed my submission thoroughly.
[x] I have tested my code (if submission is related to coding) and run the game before pushing (to make sure the project compile).
[ ] I have run the JUnit tests (if submission is related to coding).
[x] I have read the Code of Conduct and Contribution Guidelines.

✍ Description of the Pull Request

Please concisely describe the changes you have made.

When the spaceship gets hit a red background will appear for half a second in the game to show there's damage done to the spaceship.

🔗 Issue link

Issue reference number and link goes here e.g. 'Fixes/Closes #<issue_number>'.

[x] This Pull Request fixes the issue : 'Closes #'
[ ] This Pull Request does not fix an issue.

Thanks for taking the time to fill out this Pull Request! ❤ Thanks for contributing to this project 🦖

No problem :)


Quick Start Hello World Application cannot build/find container

Description:
Running the Quick Start Hello World Application described at https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html raises a RuntimeError.
Steps to reproduce the issue:

Install Docker for Windows using default settings
Install SAM CLI version 0.8.1
Follow Quick Start Hello World Application, including commands "sam init --runtime python3.7" and "cd sam-app"
Run "sam build --use-container" raises RuntimeError

Observed result:
Relevant command output:
Fetching lambci/lambda:build-python3.7 Docker container image.............
2018-12-05 19:07:12 Mounting C:\PythonCode\sampoc\sam-app\hello_world as /tmp/samcli/source:ro inside runtime container
Traceback ....
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\samcli\local\docker\container.py", line 195, in wait_for_logs
raise RuntimeError ("Container does not exist. Cannot get logs for this container")
Expected result:
Expected the result described in the Quick Start instructions.

I just tried to repro this and didn't run into this issue. Could you try restarting your docker, maybe?

Yes, I did restart both Docker and my computer. I ran these commands both yesterday and today with the same results.
I'm not familiar with Docker, but its Windows default uses Linux containers(?). An output message I quoted in my OP describes mounting a Windows item to a Linux reference. Could this be an issue?

the path mount shouldn't be an issue, we want to choose Linux containers. can you try running with --debug and the paste the entire trace here

Here is all the output from the command "sam build --use-container --debug".
2018-12-06 17:01:30 Using SAM Template at C:\PythonCode\sampoc\sam-app\template.yaml
2018-12-06 17:01:30 Changing event name from creating-client-class.iot-data to creating-client-class.iot-data-plane
2018-12-06 17:01:30 Changing event name from before-call.apigateway to before-call.api-gateway
2018-12-06 17:01:30 Changing event name from request-created.machinelearning.Predict to request-created.machine-learning.Predict
2018-12-06 17:01:30 Changing event name from before-parameter-build.autoscaling.CreateLaunchConfiguration to before-parameter-build.auto-scaling.CreateLaunchConfiguration
2018-12-06 17:01:30 Changing event name from before-parameter-build.route53 to before-parameter-build.route-53
2018-12-06 17:01:30 Changing event name from request-created.cloudsearchdomain.Search to request-created.cloudsearch-domain.Search
2018-12-06 17:01:30 Changing event name from docs..autoscaling.CreateLaunchConfiguration.complete-section to docs..auto-scaling.CreateLaunchConfiguration.complete-section
2018-12-06 17:01:30 Changing event name from before-parameter-build.logs.CreateExportTask to before-parameter-build.cloudwatch-logs.CreateExportTask
2018-12-06 17:01:30 Changing event name from docs..logs.CreateExportTask.complete-section to docs..cloudwatch-logs.CreateExportTask.complete-section
2018-12-06 17:01:30 Changing event name from before-parameter-build.cloudsearchdomain.Search to before-parameter-build.cloudsearch-domain.Search
2018-12-06 17:01:30 Changing event name from docs..cloudsearchdomain.Search.complete-section to docs..cloudsearch-domain.Search.complete-section
2018-12-06 17:01:30 Changing event name from creating-client-class.iot-data to creating-client-class.iot-data-plane
2018-12-06 17:01:30 Changing event name from before-call.apigateway to before-call.api-gateway
2018-12-06 17:01:30 Changing event name from request-created.machinelearning.Predict to request-created.machine-learning.Predict
2018-12-06 17:01:30 Changing event name from before-parameter-build.autoscaling.CreateLaunchConfiguration to before-parameter-build.auto-scaling.CreateLaunchConfiguration
2018-12-06 17:01:30 Changing event name from before-parameter-build.route53 to before-parameter-build.route-53
2018-12-06 17:01:30 Changing event name from request-created.cloudsearchdomain.Search to request-created.cloudsearch-domain.Search
2018-12-06 17:01:30 Changing event name from docs..autoscaling.CreateLaunchConfiguration.complete-section to docs..auto-scaling.CreateLaunchConfiguration.complete-section
2018-12-06 17:01:30 Changing event name from before-parameter-build.logs.CreateExportTask to before-parameter-build.cloudwatch-logs.CreateExportTask
2018-12-06 17:01:30 Changing event name from docs..logs.CreateExportTask.complete-section to docs..cloudwatch-logs.CreateExportTask.complete-section
2018-12-06 17:01:30 Changing event name from before-parameter-build.cloudsearchdomain.Search to before-parameter-build.cloudsearch-domain.Search
2018-12-06 17:01:30 Changing event name from docs..cloudsearchdomain.Search.complete-section to docs..cloudsearch-domain.Search.complete-section
2018-12-06 17:01:30 'build' command is called
2018-12-06 17:01:30 Starting Build inside a container
2018-12-06 17:01:30 Looking for credentials via: env
2018-12-06 17:01:30 Looking for credentials via: assume-role
2018-12-06 17:01:30 Looking for credentials via: shared-credentials-file
2018-12-06 17:01:30 Found credentials in shared credentials file: ~/.aws/credentials
2018-12-06 17:01:30 Loading JSON file: C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\botocore\data\endpoints.json
2018-12-06 17:01:30 Event choose-service-name: calling handler <function handle_service_name_alias at 0x000001DF332F4F28>
2018-12-06 17:01:30 Loading JSON file: C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\botocore\data\serverlessrepo\2017-09-08\service-2.json
2018-12-06 17:01:30 Event creating-client-class.serverlessapplicationrepository: calling handler <function add_generate_presigned_url at 0x000001DF332B8D90>
2018-12-06 17:01:30 The s3 config key is not a dictionary type, ignoring its value of: None
2018-12-06 17:01:30 Setting serverlessrepo timeout as (60, 60)
2018-12-06 17:01:30 Loading JSON file: C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\botocore\data_retry.json
2018-12-06 17:01:30 Registering retry handlers for service: serverlessrepo
2018-12-06 17:01:30 No Parameters detected in the template
2018-12-06 17:01:30 2 resources found in the template
2018-12-06 17:01:30 Found Serverless function with name='HelloWorldFunction' and CodeUri='hello_world/'
2018-12-06 17:01:30 Trying paths: ['C:\Users\scalwas\.docker\config.json', 'C:\Users\scalwas\.dockercfg']
2018-12-06 17:01:30 Found file at path: C:\Users\scalwas.docker\config.json
2018-12-06 17:01:30 Couldn't find auth-related section ; attempting to interpret as auth-only file
2018-12-06 17:01:30 Config entry for key stackOrchestrator is not auth config
2018-12-06 17:01:30 Building resource 'HelloWorldFunction'
2018-12-06 17:01:30 Trying paths: ['C:\Users\scalwas\.docker\config.json', 'C:\Users\scalwas\.dockercfg']
2018-12-06 17:01:30 Found file at path: C:\Users\scalwas.docker\config.json
2018-12-06 17:01:30 Couldn't find auth-related section ; attempting to interpret as auth-only file
2018-12-06 17:01:30 Config entry for key stackOrchestrator is not auth config
2018-12-06 17:01:30 http://localhost:None "GET /v1.35/images/lambci/lambda:build-python3.7/json HTTP/1.1" 200 None
2018-12-06 17:01:30 Looking for auth config
2018-12-06 17:01:30 Looking for auth entry for 'docker.io'
2018-12-06 17:01:30 No entry found
2018-12-06 17:01:30 No auth config found
2018-12-06 17:01:32 http://localhost:None "POST /v1.35/images/create?tag=build-python3.7&fromImage=lambci%2Flambda HTTP/1.1" 200 None
Fetching lambci/lambda:build-python3.7 Docker container image......
2018-12-06 17:01:32 Mounting C:\PythonCode\sampoc\sam-app\hello_world as /tmp/samcli/source:ro inside runtime container
2018-12-06 17:01:58 http://localhost:None "POST /v1.35/containers/create HTTP/1.1" 500 26
Traceback (most recent call last):
File "c:\python3\lib\runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "c:\python3\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\Scripts\sam.exe_main.py", line 9, in
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\click\core.py", line 722, in call
return self.main(*args, **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\click\core.py", line 697, in main
rv = self.invoke(ctx)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\click\core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\click\core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\click\decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\samcli\commands\build\command.py", line 94, in cli
skip_pull_image, parameter_overrides)  # pragma: no cover
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\samcli\commands\build\command.py", line 132, in do_cli
artifacts = builder.build()
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\samcli\lib\build\app_builder.py", line 117, in build
lambda_function.runtime)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\samcli\lib\build\app_builder.py", line 189, in _build_function
runtime)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\samcli\lib\build\app_builder.py", line 249, in _build_function_on_container
container.wait_for_logs(stdout=stdout_stream, stderr=stderr_stream)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\site-packages\samcli\local\docker\container.py", line 195, in wait_for_logs
raise RuntimeError("Container does not exist. Cannot get logs for this container")
RuntimeError: Container does not exist. Cannot get logs for this container

Any news on this issue? I tried the newest SAM v0.10.0 and backtracking from Python 3.7.1 to 3.6.8, but they had no effect. I also tried backtracking the pypiwin32 package from 223 to 220 as described in issue #847, but again had no effect.
Here is the debug output from running SAM 0.10.0, Python 3.6.8, pypiwin32 223.
$ sam build --use-container --debug > log.txt
2018-12-27 17:40:40 Using SAM Template at C:\PythonCode\sampoc\sam-app\template.yaml
2018-12-27 17:40:40 Changing event name from creating-client-class.iot-data to creating-client-class.iot-data-plane
2018-12-27 17:40:40 Changing event name from before-call.apigateway to before-call.api-gateway
2018-12-27 17:40:40 Changing event name from request-created.machinelearning.Predict to request-created.machine-learning.Predict
2018-12-27 17:40:40 Changing event name from before-parameter-build.autoscaling.CreateLaunchConfiguration to before-parameter-build.auto-scaling.CreateLaunchConfiguration
2018-12-27 17:40:40 Changing event name from before-parameter-build.route53 to before-parameter-build.route-53
2018-12-27 17:40:40 Changing event name from request-created.cloudsearchdomain.Search to request-created.cloudsearch-domain.Search
2018-12-27 17:40:40 Changing event name from docs..autoscaling.CreateLaunchConfiguration.complete-section to docs..auto-scaling.CreateLaunchConfiguration.complete-section
2018-12-27 17:40:40 Changing event name from before-parameter-build.logs.CreateExportTask to before-parameter-build.cloudwatch-logs.CreateExportTask
2018-12-27 17:40:40 Changing event name from docs..logs.CreateExportTask.complete-section to docs..cloudwatch-logs.CreateExportTask.complete-section
2018-12-27 17:40:40 Changing event name from before-parameter-build.cloudsearchdomain.Search to before-parameter-build.cloudsearch-domain.Search
2018-12-27 17:40:40 Changing event name from docs..cloudsearchdomain.Search.complete-section to docs..cloudsearch-domain.Search.complete-section
2018-12-27 17:40:40 Changing event name from creating-client-class.iot-data to creating-client-class.iot-data-plane
2018-12-27 17:40:40 Changing event name from before-call.apigateway to before-call.api-gateway
2018-12-27 17:40:40 Changing event name from request-created.machinelearning.Predict to request-created.machine-learning.Predict
2018-12-27 17:40:40 Changing event name from before-parameter-build.autoscaling.CreateLaunchConfiguration to before-parameter-build.auto-scaling.CreateLaunchConfiguration
2018-12-27 17:40:40 Changing event name from before-parameter-build.route53 to before-parameter-build.route-53
2018-12-27 17:40:40 Changing event name from request-created.cloudsearchdomain.Search to request-created.cloudsearch-domain.Search
2018-12-27 17:40:40 Changing event name from docs..autoscaling.CreateLaunchConfiguration.complete-section to docs..auto-scaling.CreateLaunchConfiguration.complete-section
2018-12-27 17:40:40 Changing event name from before-parameter-build.logs.CreateExportTask to before-parameter-build.cloudwatch-logs.CreateExportTask
2018-12-27 17:40:40 Changing event name from docs..logs.CreateExportTask.complete-section to docs..cloudwatch-logs.CreateExportTask.complete-section
2018-12-27 17:40:40 Changing event name from before-parameter-build.cloudsearchdomain.Search to before-parameter-build.cloudsearch-domain.Search
2018-12-27 17:40:40 Changing event name from docs..cloudsearchdomain.Search.complete-section to docs..cloudsearch-domain.Search.complete-section
2018-12-27 17:40:40 'build' command is called
2018-12-27 17:40:40 Starting Build inside a container
2018-12-27 17:40:40 Looking for credentials via: env
2018-12-27 17:40:40 Looking for credentials via: assume-role
2018-12-27 17:40:40 Looking for credentials via: shared-credentials-file
2018-12-27 17:40:40 Found credentials in shared credentials file: ~/.aws/credentials
2018-12-27 17:40:40 Loading JSON file: C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\botocore\data\endpoints.json
2018-12-27 17:40:40 Event choose-service-name: calling handler <function handle_service_name_alias at 0x000001F206AC4EA0>
2018-12-27 17:40:40 Loading JSON file: C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\botocore\data\serverlessrepo\2017-09-08\service-2.json
2018-12-27 17:40:40 Event creating-client-class.serverlessapplicationrepository: calling handler <function add_generate_presigned_url at 0x000001F206A85B70>
2018-12-27 17:40:40 The s3 config key is not a dictionary type, ignoring its value of: None
2018-12-27 17:40:40 Setting serverlessrepo timeout as (60, 60)
2018-12-27 17:40:40 Loading JSON file: C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\botocore\data_retry.json
2018-12-27 17:40:40 Registering retry handlers for service: serverlessrepo
2018-12-27 17:40:41 No Parameters detected in the template
2018-12-27 17:40:41 2 resources found in the template
2018-12-27 17:40:41 Found Serverless function with name='HelloWorldFunction' and CodeUri='hello_world/'
2018-12-27 17:40:41 Trying paths: ['C:\Users\scalwas\.docker\config.json', 'C:\Users\scalwas\.dockercfg']
2018-12-27 17:40:41 Found file at path: C:\Users\scalwas.docker\config.json
2018-12-27 17:40:41 Couldn't find auth-related section ; attempting to interpret as auth-only file2018-12-27 17:40:41 Config entry for key stackOrchestrator is not auth config
2018-12-27 17:40:41 Building resource 'HelloWorldFunction'
2018-12-27 17:40:41 Trying paths: ['C:\Users\scalwas\.docker\config.json', 'C:\Users\scalwas\.dockercfg']
2018-12-27 17:40:41 Found file at path: C:\Users\scalwas.docker\config.json
2018-12-27 17:40:41 Couldn't find auth-related section ; attempting to interpret as auth-only file2018-12-27 17:40:41 Config entry for key stackOrchestrator is not auth config
2018-12-27 17:40:41 http://localhost:None "GET /v1.35/images/lambci/lambda:build-python3.6/json HTTP/1.1" 200 None
2018-12-27 17:40:41 Looking for auth config
2018-12-27 17:40:41 Looking for auth entry for 'docker.io'
2018-12-27 17:40:41 No entry found
2018-12-27 17:40:41 No auth config found
2018-12-27 17:40:42 http://localhost:None "POST /v1.35/images/create?tag=build-python3.6&fromImage=lambci%2Flambda HTTP/1.1" 200 None
Fetching lambci/lambda:build-python3.6 Docker container image......
2018-12-27 17:40:42 Mounting C:\PythonCode\sampoc\sam-app\hello_world as /tmp/samcli/source:ro inside runtime container
2018-12-27 17:40:49 http://localhost:None "POST /v1.35/containers/create HTTP/1.1" 500 42
Traceback (most recent call last):
File "c:\python3\lib\runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "c:\python3\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\Users\scalwas\AppData\Roaming\Python\Python37\Scripts\sam.exe_main.py", line 9, in
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\click\core.py", line 722, in call
return self.main(*args, **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\click\core.py", line 697, in main
rv = self.invoke(ctx)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\click\core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\click\core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\click\decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\samcli\commands\build\command.py", line 94, in cli
skip_pull_image, parameter_overrides)  # pragma: no cover
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\samcli\commands\build\command.py", line 132, in do_cli
artifacts = builder.build()
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\samcli\lib\build\app_builder.py", line 129, in build
lambda_function.runtime)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\samcli\lib\build\app_builder.py", line 201, in _build_function
runtime)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\samcli\lib\build\app_builder.py", line 261, in _build_function_on_container
container.wait_for_logs(stdout=stdout_stream, stderr=stderr_stream)
File "C:\Users\scalwas\AppData\Roaming\Python\Python36\site-packages\samcli\local\docker\container.py", line 196, in wait_for_logs
raise RuntimeError("Container does not exist. Cannot get logs for this container")
RuntimeError: Container does not exist. Cannot get logs for this container

@SCalwas Looking at your output, this is the key part:
2018-12-27 17:40:42 http://localhost:None "POST /v1.35/images/create?tag=build-python3.6&fromImage=lambci%2Flambda HTTP/1.1" 200 None

Fetching lambci/lambda:build-python3.6 Docker container image......
2018-12-27 17:40:42 Mounting C:\PythonCode\sampoc\sam-app\hello_world as /tmp/samcli/source:ro inside runtime container
2018-12-27 17:40:49 http://localhost:None "POST /v1.35/containers/create HTTP/1.1" 500 42

You can see that the container appears to be downloaded locally but we we go to create the container, docker blows up.
Given you are on Windows, can you make sure that the container type is linux and not windows. My current guess is that docker is giving an internal service error because of this. You are able to download so that means docker is running and responsive.

Docker is using Linux containers. During installation, Linus containers were the default type, and I left that unchanged. Also, right-clicking the Docker icon pops up a menu with an item of "Switch to Windows containers..." When clicked, a dialog asks if I'm sure I want to change from Linux containers to Windows containers. So definitely using Linux containers.
FYI: Using SAM 0.10.0 and Python 3.6.8 and running "sam build --use-container," Docker prompts whether I want to share drive C:. This prompt did not occur with SAM 0.08.0 and Python 3.7.1.

That prompt is from Docker not SAM CLI.
You want to share the C: drive, if that is the drive you are working from. Does sharing solve this for you?

:-) FYI: I work at AWS. SDK Programmer Writer. Think I have any chance of getting past the firewall??? :-)

Hey guys,
Just in case, ensure that you initialize and build using the latest sam cli install.
I had this issue when I tried initializing the app with an old version of the aws sam cli while doing the build with the newer version.

Initially issue was due to a firewall blocking the traffic to the Docker Daemon. Closing as it was an issue with the system and not SAM CLI


Are there any more example fully rigged characters like lambert.mb? For example, woman_base rigged? Otherwise, what's the process to build one?

I've added shani.mb here:
https://mega.nz/folder/fZpiXZzS#xd3mWgqtAQND0UI90KWk7Q
I'll do a full tutorial of importing character entities once I release a new version of this tool. But for now it's probably not worth trying to do it. Shani uses the same skeleton as all other women in the game.
Here is a image of the current progress of adding entity import features:
https://i.imgur.com/qp2P3Kh.jpg
You can see you'll be able to select appearance and turn on the importing of all face poses.
The "Fbx Depo Path" will hold converted fbx files that can be imported into Maya with their skeleton.
The general process to automatically create an character would be

Open Wolven-kit and find shani.w2ent
Export shani.w2ent.json
Some process that will get all the fbx/rig files into "Fbx Depo Path" and make sure they're readable by Maya. Right now I'm using a script I wrote to do all this.
Import shani.w2ent.json in Maya, this will read and combine all items and rigs in the "Fbx Depo Path" into a full character.

Would use the same process to import things like the items in cutscenes.
You can manually create the json yourself by editing existing json and just changing the paths to some other object in the "Fbx Depo Path".

thank you - The shani.mb should actually meet my needs :)