UIUC Transportation Demand

This issue can be closed when a document or jupyter notebook has been created to answer the following questions (with detailed steps on how to replicate the answers):

[ ] Approximately how many miles are driven by each type of vehicle per year?

[ ] How many vehicles of each type does the University have in its fleet?

[ ] What is the average gas mileage for each type of vehicle?

[ ] What is the CO2 equivalent per mile driven (tons of CO2eq/ mile). Note: It's important that this an equivalent because emissions might consist of more than just CO2. E.g. 1 ton of CH4 released might be the same as 3 tons of CO2. So report 3 tons of CO2eq.

[ ] Document to replicate answers and sources cited.

Vehicles should be sorted by fuel type (E85, Diesel, Unleaded).
edited for clarity.

Copied from Slack reply
Thanks and last thing just for my clarification: are you looking for TOTAL amount of cars using that fuel type within the fleet, or the amount of models that use that fuel types. For instance, if there were 8 Fords and 3 Dodges using one of the fuel type, are you looking for 11 vehicles or 2 vehicle types.

I see, 11 vehicles would be the answer I'm looking for. Thanks for checking!

Before I go ahead and submit a request to the Office of Campus Emergency Management for access to information on approximate miles driven by each vehicle of the fleet, there was not a separate excel sheet that contained this information, correct? I see the purchase records and the fuel numbers, but I do not see anything about miles traveled.

Yes, I believe that is correct. If that data is available it would be exact miles driven per vehicle. I encourage you to pursue this data, but don't get hung up on waiting for a response -- an approximate answer is fine (by using average mpg and total gallons consumed).

In that case should I just look up the average mpg for the different vehicles? Because I initially assumed we would get that statistic by using the exact mileage traveled by each vehicle.

Hi Folks, @robfairh should be tightly involved in this discussion. I think he has already asked for and received much of this information from Facilities. We should not be repeatedly asking facilities services for the same data for the same project (there are humans behind the request form). @robfairh can you please coordinate with @samgdotson and @datw0258 ?

For clarification, do you still want me to look at the things listed in the initial issue, or just finding GGE equivalents for the technologies you listed and their corresponding $/GGE?

I'll edit the issue to reflect our earlier conversation. I think @katyhuff is right, we should be concerned with gallon-gasoline-equivalent for now (the phrase "your mileage may vary" applies here in the literal sense..).

I am emailing you an update of where I am so you can let me know if I've misinterpreted some of the checkpoints so far. If there is a better/preferred way of sending files to you (ipynb in this case) in the future, please let me know!

Excellent, I just took a look at the files and it seems like you're going the right direction.
Regarding the sending of files, this is precisely what GitHub is designed to do!
Here's the outline for using GitHub:

Fork the repository
Clone repository using git clone git@github.com:datw0258/2020-dotson-optimal-sizing
(I recommend setting up ssh keys)
Set up a new working branch with git checkout -b IssueName
Do the work you're currently doing
Regularly commit changes with git add FileName then ``git commit -m "descriptive message"
When you feel like you've checked most of the boxes, make a pull request by comparing across forks. We can discuss the work that you're doing in a pull request.

Before I make a pull request, I just wanted to confirm I am doing this right as I am not completely confident with GitHub yet (it says something like "These branches can be automatically merged").

I forked the repository and made a new branch "UIUC-Transportation-Demand"
Added a folder called "UIUC-Transportation-Demand" containing the notebook and csv's
I open a pull request, and submit it

Looks good to me.
Just don't press "merge" before a review.
Minor comments: capital letters are annoying. Try to use lowercase (indeed,
ideally snake case) for folder names, branch names, filenames, etc.
On Thu, May 28, 2020 at 12:54 PM datw0258<EMAIL_ADDRESS>wrote:

Before I make a pull request, I just wanted to confirm I am doing this
right as I am not completely confident with GitHub yet (it says something
like "These branches can be automatically merged").

I forked the repository and made a new branch
"UIUC-Transportation-Demand"
Added a folder called "UIUC-Transportation-Demand" containing the
notebook and csv's
I open a pull request, and submit it

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arfc/2020-dotson-optimal-sizing/issues/41#issuecomment-635502232,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADAFK74JIS5IPAWAQHLFRDRT2QORANCNFSM4NKQCSHA
.

--
http://katyhuff.github.com

Okay sounds good. Do I have to assign someone (Sam) to the Pull Request, or will it automatically add him?

It's best to assign someone. It will not automatically add anyone, though
it may "suggest" someone.
On Thu, May 28, 2020 at 1:51 PM datw0258<EMAIL_ADDRESS>wrote:

Okay sounds good. Do I have to assign someone (Sam) to the Pull Request,
or will it automatically add him?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arfc/2020-dotson-optimal-sizing/issues/41#issuecomment-635531233,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADAFK2PLSM2WOHRQIJOHXLRT2XCNANCNFSM4NKQCSHA
.

--
http://katyhuff.github.com

closed by #42


Integration with Weld - workflow

Questions:

Account creation: should we automatically create an Account for each User? And then e.g. Polarn O. Pyret users can change account to a shared account?

@hankmander


Charts with database stats

General data (counters):

total games, teams, assets, media, networks

Create charts for the following data (examples):

games released by year  / bar
active teams types (company, personal, team) / pie
events per year
companies founded per year  / bar
games status (released, under dev, etc) / pie

Using https://github.com/jerairrest/react-chartjs-2


currencyservice: bring back multistage build

Changes
This commit brings back the multistage docker build that was removed since #991
Merge Requirements
For new features contributions please make sure you have completed the following
essential items:

[x] CHANGELOG.md updated to document new feature additions
[ ] N/A Appropriate documentation updates in the docs
[ ] N/A Appropriate Helm chart updates in the helm-charts

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

@styblope please resolve the conflicts, and we should be good to merge this one


ImportError: cannot import name 'DocstringAttr' from 'docstring_parser.common'

From time to time I run into the following issue
$ pydoclint .
Traceback (most recent call last):
  File "/home/mlengqui/miniconda3/envs/sohvida_dc_update/bin/pydoclint", line 5, in <module>
    from pydoclint.main import main
  File "/home/mlengqui/miniconda3/envs/sohvida_dc_update/lib/python3.9/site-packages/pydoclint/main.py", line 18, in <module>
    from pydoclint.visitor import Visitor
  File "/home/mlengqui/miniconda3/envs/sohvida_dc_update/lib/python3.9/site-packages/pydoclint/visitor.py", line 5, in <module>
    from pydoclint.utils.arg import Arg, ArgList
  File "/home/mlengqui/miniconda3/envs/sohvida_dc_update/lib/python3.9/site-packages/pydoclint/utils/arg.py", line 4, in <module>
    from docstring_parser.common import DocstringAttr, DocstringParam
ImportError: cannot import name 'DocstringAttr' from 'docstring_parser.common' (/home/mlengqui/miniconda3/envs/sohvida_dc_update/lib/python3.9/site-packages/docstring_parser/common.py)

This is even though I have the docstring_parser_fork installed.
$ pip list | grep docstring_parser
docstring_parser           0.16
docstring_parser_fork      0.0.9

Is this due to that pydoclint is using the 'regular' version instead of the fork in this case?

Hi @magnussommarsjo , maybe it's best to uninstall docstring_parser to avoid naming conflicts.  I added DocstringAttr in the fork, but apparently your Python was still looking into the original "docstring_parser" library.

Removing by simply pip uninstall docstring-parser will then give an ModuleNotFoundError: No module named 'docstring_parser.common' when running pydoclint ..
Why I ending up with both is that I have another dependency on docstring-parser called kfp. Below is the "inverted" dependency graph.
docstring-parser v0.16
└── kfp v1.8.22 (*)
docstring-parser-fork v0.0.9
└── pydoclint v0.5.8
    ├── my-project

Here is a minimal code sample that will recreate this issue using conda.
conda create -n testenv python=3.9 -y
conda activate testenv
pip install kfp pydoclint
pydoclint .

Could you run pydoclint in a separate environment?
My earlier suggestion to uninstall docstring_parser wouldn't work, because it turned out that both docstring_parser and docstring_parser_fork were installed in the same folder: /Users/...../anaconda3/envs/testenv/lib/python3.9/site-packages/docstring_parser/*, because they share the same module name, which is docstring_parser.
There is unfortunately not a perfect fix for this situation.  I prefer not to change the module name of the forked library (otherwise keeping up with the latest changes on the original repo would be difficult).  I also couldn't get bug fixes to be merged in the original repo (which is why I had to fork it).

Well I can run it in another environment. But that is not a great workflow for me or my team. This would basically mean that as soon as I need to commit and run "pre-commit" where my linting checks are run. I'll then need to temporarily  switch environment and then back again when I need to run testing with pytest.
I understand that this issue might be hard to fix. But anyhow I wanted to raise it so that you are aware of it. 😉

May I see your tox or pre-commit config? I've always been running pydoclint in a dedicated env in tox, so I never ran into this issue before.
And btw I just found a workaround:
conda create -n testenv python=3.9 -y
conda activate testenv
pip install kfp
pip install pydoclint
pydoclint .

The key is to split up kfp and pydoclint into 2 commands, and make sure you install pydoclint last so that the old (original) docstring_parser gets overwritten by docstring_parser_fork.  You can inspect the file .../anaconda3/envs/testenv/lib/python3.9/site-packages/docstring_parser/common.py to double check: the forked version has 298 lines while the original version has 228 lines.


Prevent leaking CommandSenderInner struct

Summary
Earlier, this struct was being leaked due to the implementation of Deref. However, since the struct was never actually exported, documentation was not being generated for it's methods.
This commit just makes the struct private and instead creates wrapper functions over it. This is typically whats done in Rust std.
Signed-off-by: Ayush Singh<EMAIL_ADDRESS>Checklist

[x] cargo fmt
[x] cargo clippy
[x] cargo test
[ ] updated CHANGES.md

Looks good. Could you add an entry for this to the changelog in the category "Fixed"?

Should I add a new Release as well, or just add the changes to 0.5.0-rc.1?

Just put a ### Fixed below ## Unreleased . We collect changes under Unreleased until a new version comes out.


orch/run: Added scan_unit_test_error

Currently when a unittest in RemoteProcess
fails it will throw a CommandFailure with
no information regarding which unittest
failed.
This PR will enable the CommandFailure to scan
for unittest failures in teuthology.log
and output them to paddles.
Currently only supports these unittests:

gtest c++
python nose

Signed-off-by: Kamoltat Sirivadhna<EMAIL_ADDRESS>

https://pulpito.ceph.com/ksirivad-2021-12-01_22:29:48-rgw:sts-wip-skoduri-dbstore-mp-distro-basic-smithi/

Parsing logs during core exception handling is in general not a good idea. Especially if we do that for any failed command, even if we know that we are not running unittest and we expect the command to be failed. If you really want to parse logs from unittest running remotely, it is better to do with separate utility wrapper runner and the decision should be taken on the caller side.
As an idea, for example, maybe there can be a parsers class for each unittest type, and there can be a list of parsers passed to the run method as a parameter to check the stream.

Work being done in https://github.com/ceph/teuthology/pull/1768 instead


I have a problem, I cannot compile Osiris

https://i.imgur.com/wHCQTue.png

Update your visual studio

I have the same errors, and my visual studio is updated

I have the same errors, and my visual studio is updated

If you have this error your visual studio must be older than version 16.5 as that's the version where numbers.h was implemented

No, i have latest version 16.7.6, the error that is showing is this
Fatal Error C1083

Fixed it, some visual studio files where missing idk why, downloaded and installed it again and its working.

Thnx


cmd/vet: prefix in vet output breaks error file format compatibility

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/Users/mbp/go/bin"
GOCACHE="/Users/mbp/Library/Caches/go-build"
GOENV="/Users/mbp/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY="github.com/mirza-s"
GONOSUMDB="github.com/mirza-s"
GOOS="darwin"
GOPATH="/Users/mbp/go"
GOPRIVATE="github.com/mirza-s"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nt/0hzfppd92jvbk99fhvnhy8ph0000gn/T/go-build729502798=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Run
go vet cmd/main.go

What did you expect to see?
cmd/main.go:187:62: undefined: a

What did you see instead?
vet: cmd/main.go:187:62: undeclared name: a

This appears to be introduced in 38431f1044880b936e35034ded19a6a8bc9faa21

Hi @mirza-s,
I can confirm this output change locally:
# vet.go
package main

import "fmt"

func main() {
	fmt.Println(a)
}

$ go1.12 vet ./vet.go
# command-line-arguments [command-line-arguments.test]
./vet.go:6:14: undefined: a

$ go vet ./vet.go
# command-line-arguments
vet: ./vet.go:6:14: undeclared name: a

$ go build ~/vet.go
# command-line-arguments
./vet.go:6:14: undefined: a

I'm not sure if this is a feature or a bug.
/cc @rsc, @josharian and @bradfitz, who have context on the CLs for #31916


Mapping returns PyList for keys, values, and items

From the PyMappingProxy PR.
Since Python 3.7 PyMapping_Keys, PyMapping_Values, and PyMapping_Items always returns a list instead of a sequence. This PR updates the corresponding return types in PyMapping.

Thanks, I guess this needs rebasing on main now that #4644 was merged :)


Stop filtering out Owners

Now that the Owners team is frowned upon, there's no reason to keep it filtered out of the dashboard. Remove that logic.

Done.


Simulate mouse hover?

That would be very useful to have, although maybe it is impossible since you seem to replicate finger taps instead of a real android mouse connected through usb?

this documents several modes that I believe can do what you want. Unfortunately in my experience with them, I would say it's difficult for a beginner to understand how to control using those modes, so ask me for help if you need it.

Implemented by #5039.


Integrate SEI network

📝 Description
Integrate SEI Network
❓ Context

Impacted projects: LLC
Linked resource(s): https://ledgerhq.atlassian.net/browse/LIVE-7906

✅ Checklist

[x] Test coverage
[x] Atomic delivery
[x] No breaking changes

📸 Demo

🚀 Expectations to reach
Please make sure you follow these Important Steps.
Pull Requests must pass the CI and be internally validated in order to be merged.

Pending funds to test

Need to update unit tests

Need to update unit tests

Which ones ? Integration is already covered by integration + cosmos framework unit tests

Check out the CI, need to regenerate cryptoassets.md: https://github.com/LedgerHQ/ledger-live/actions/runs/6404391222/job/17384857963

Need to update unit tests

Which ones ? integ tests are WIP and there is already cosmos framework unit tests where I did updates

Check out the CI, need to update cryptoassets.md: https://github.com/LedgerHQ/ledger-live/actions/runs/6404391222/job/17384857963


Declaration of C function with **in leads to error

I'm creating APR Cython bindings and I just came across this parsing error. The original function is this:
APR_DECLARE(apr_status_t) apr_file_pipe_create(apr_file_t **in,
                                               apr_file_t **out,
                                               apr_pool_t *pool);

And if I declare it as:
    apr_status_t apr_file_pipe_create(apr_file_t **in, apr_file_t **out, apr_pool_t *pool)
I get a compilation error on the PXD file that says: "Expected ')', found 'in'". If I rename the function argument 'in' to 'file_in' everything works. I'm not familiar enough with Cython's code base to fix it.

in is a reserved keyword in Python (hence Cython).

Thanks! I didn't know 'in' was a reserved keyword on declarations as well.

Yes, just like you couldn't name a variable "for" or "const" in C.


Limit softfailure for bsc#1221983 to JDK11

The jshell failure is only present on OpenJDK-devel 11, so we need to limit the softfailure also to just this Java version.
[CI:TOXENVS] openjdk_devel

@grisu48 please run tox -e format

@grisu48 please run tox -e format

I'm stuck elsewhere, please see https://suse.slack.com/archives/C02AF8LALDA/p1733901150518579?thread_ts=1733900588.468239&cid=C02AF8LALDA

The jshell failure is only present on OpenJDK-devel 11, so we need to limit the softfailure also to just this Java version.

can you point where the xfail is passing?
according to my emulated testing this isn't limited to openjdk 11 at all, and the referenced bugreport confirms it happens with 21.


Note system

Design db, backend & frontend note system

See layout

https://react-native-training.github.io/react-native-elements/docs/card.html


Add report creation timestamp to text output if requested

Signed-off-by: Maxime Gervais<EMAIL_ADDRESS>

Argh, merged two quickly, sponsor reported that there is an offset of 1 hour (and this is not local time, it is in the opposite direction). @g-maxime please an update with the right UTC time.


Add fluxsvc db query metrics

If we put all the operations in their own metric, does this make it impossible to look at say, the mean over all operations?

D'oh. Right. Not impossible, but a pain. Will fix that. Made the same
mistake on platform.Metrics
On Thu, 22 Dec 2016 at 07:47, Michael Bridgen<EMAIL_ADDRESS>wrote:

If we put all the operations in their own metric, does this make it
impossible to look at say, the mean over all operations?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/flux/pull/324#issuecomment-268739289, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPRVxwk9HGia7DZ_08f8RaUFOd7W1Mmks5rKisOgaJpZM4LSB4p
.


TypeError: needs a 'context' argument when using version 0.2.1

Hi,
I just upgraded to version 0.2.1 and I keep getting the error TypeError: needs a 'context' argument unless I change the function readConfig in the file config-serializer.js as follow:
var ctx = vm.createContext(sandbox);
vm.runInContext(cfgCode, ctx); // I changed the second parameter from sandbox to ctx
return sandbox.System.cfg;

@Jak3b0 This is probably a bug. I will look into it. Thanks for reporting.

@Jak3b0 I could not reproduce it in my machine. Could you point me to the github repo that have this issue?

On my machine, aurelia-bundler is installed from npm and the file/line I'm talking about is this one.

What is your node and npm version?

Node is at 0.12.2 and npm is at 2.7.4.

This may be the issue. I am on node v5. I will try that. Probably need a version manager.  @EisenbergEffect what is oldest version of node we should support.

@Jak3b0 Can you try after updating node to v4/v5. This will greatly help isolating the issue.

Hum.. I might be missing something here.. I have the version 5.3 installed on Windows (Windows Installer) but when I do node -v in a command prompt, I get the version 0.12.2...

I think the version was messup because of the order of the directories in my PATH variable. Visual Studio 2015 has it's own version of node if I'm not mistaken. I corrected the PATH and installed the version 5.4 and I still have the issue.

If it is not a private project, can you share the github link?

Ok, I got it fixed. In Visual Studio, there is another option for the location of external tools (like node). This is a list of locations to search for those tool. My "PATH" location was after the one of Microsoft.
All is working now :)

I'm seeing this too with the latest Aurelia starter kit. Tried with both node 4.4.3 and 6.0.0. It doesn't appear to be only a node version issue.

Moving the $(PATH) item to the top of the list under Options|Projects and Solutions|External Web Tools as suggested by @Jak3b0 does fix the problem.

If anybody needs a concrete instruction to configure Visual Studio to use the new/external Node.js version, have a look at https://blogs.msdn.microsoft.com/webdev/2015/03/19/customize-external-web-tools-in-visual-studio-2015/.


Error when bring up machine

OS: Centos 6.2
vagrant version: 1.7.4
xen center: 6.5
Can anyone help?
error message:
vagrant up --provider=xenserver
Bringing machine 'default' up with 'xenserver' provider...
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00309725 s, 339 MB/s
/opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:202:in conv2value': Wrong type NilClass. Not allowed! (RuntimeError)         from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:118:in block in methodCall'
from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:117:in collect'         from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:117:in methodCall'
from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/client.rb:278:in call2'         from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/client.rb:260:in call'
from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/upload_vhd.rb:72:in block in call'         from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/upload_vhd.rb:42:in synchronize'
from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/upload_vhd.rb:42:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in block in finalize_action'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in block in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/call.rb:53:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/connect_xs.rb:28:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/config_validate.rb:25:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/handle_box.rb:56:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in block in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:214:in action_raw'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:191:in block in action'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/environment.rb:516:in lock'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:178:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:178:in action'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

From the backtrace, it looks like it failed to make the VDI on the xenserver. If you rerun with '--debug' you should see a log line that looks like:
 created VDI: <some error maybe?>

The error reporting in this is poor at the moment - there's an issue to fix this up (#20)

Thanks  jonludlam. When I use debug option, I do find the error.
INFO upload_vhd: created VDI:
ERROR warden: Error occurred: Wrong type NilClass. Not allowed!
Below is the detail debug message:
INFO global: Vagrant version: 1.7.4
INFO global: Ruby version: 2.0.0
INFO global: RubyGems version: 2.0.14
INFO global: VAGRANT_OLD_ENV__system_version="6"
INFO global: VAGRANT_INSTALLER_ENV="1"
INFO global: VAGRANT_OLD_ENV_rvm_bin_path="/usr/local/rvm/bin"
INFO global: VAGRANT_OLD_ENV_HISTSIZE="1000"
INFO global: VAGRANT_OLD_ENV_IRBRC="/usr/local/rvm/rubies/ruby-1.9.3-p551/.irbrc"
INFO global: VAGRANT_OLD_ENV_MY_RUBY_HOME="/usr/local/rvm/rubies/ruby-1.9.3-p551"
INFO global: VAGRANT_OLD_ENV_LESSOPEN="||/usr/bin/lesspipe.sh %s"
INFO global: VAGRANT_OLD_ENV_HOSTNAME="buildmachine"
INFO global: VAGRANT_OLD_ENV_SSH_TTY="/dev/pts/0"
INFO global: VAGRANT_OLD_ENV_USER="root"
INFO global: VAGRANT_OLD_ENV__="/opt/vagrant/bin/vagrant"
INFO global: VAGRANT_OLD_ENV_SELINUX_LEVEL_REQUESTED=""
INFO global: VAGRANT_OLD_ENV_SHLVL="2"
INFO global: VAGRANT_OLD_ENV_rvm_path="/usr/local/rvm"
INFO global: VAGRANT_OLD_ENV_LANG="en_US.UTF-8"
INFO global: VAGRANT_OLD_ENV_HISTCONTROL="ignoredups"
INFO global: VAGRANT_OLD_ENV_RUBY_VERSION="ruby-1.9.3-p551"
INFO global: VAGRANT_OLD_ENV_SELINUX_ROLE_REQUESTED=""
INFO global: VAGRANT_OLD_ENV_SHELL="/bin/bash"
INFO global: VAGRANT_OLD_ENV_TERM="vt100"
INFO global: VAGRANT_OLD_ENV_HOME="/root"
INFO global: VAGRANT_OLD_ENV__system_name="CentOS"
INFO global: VAGRANT_OLD_ENV_rvm_prefix="/usr/local"
INFO global: VAGRANT_INSTALLER_VERSION="2"
INFO global: VAGRANT_OLD_ENV_SSH_CLIENT="<IP_ADDRESS> 50396 22"
INFO global: VAGRANT_OLD_ENV_SELINUX_USE_CURRENT_RANGE=""
INFO global: VAGRANT_OLD_ENV_LS_COLORS="rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arj=01;31:.taz=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.zip=01;31:.z=01;31:.Z=01;31:.dz=01;31:.gz=01;31:.lz=01;31:.xz=01;31:.bz2=01;31:.tbz=01;31:.tbz2=01;31:.bz=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.rar=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.jpg=01;35:.jpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.axv=01;35:.anx=01;35:.ogv=01;35:.ogx=01;35:.aac=01;36:.au=01;36:.flac=01;36:.mid=01;36:.midi=01;36:.mka=01;36:.mp3=01;36:.mpc=01;36:.ogg=01;36:.ra=01;36:.wav=01;36:.axa=01;36:.oga=01;36:.spx=01;36:.xspf=01;36:"
INFO global: VAGRANT_OLD_ENV__system_type="Linux"
INFO global: VAGRANT_OLD_ENV_SSH_CONNECTION="<IP_ADDRESS> 50396 <IP_ADDRESS> 22"
INFO global: VAGRANT_OLD_ENV_G_BROKEN_FILENAMES="1"
INFO global: VAGRANT_OLD_ENV_GEM_HOME="/usr/local/rvm/gems/ruby-1.9.3-p551"
INFO global: VAGRANT_OLD_ENV_PWD="/root/vagrant_xen"
INFO global: VAGRANT_OLD_ENV_rvm_version="1.26.11 (latest)"
INFO global: VAGRANT_EXECUTABLE="/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/bin/vagrant"
INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/opt/vagrant/embedded"
INFO global: VAGRANT_OLD_ENV_MAIL="/var/spool/mail/root"
INFO global: VAGRANT_OLD_ENV_LOGNAME="root"
INFO global: VAGRANT_OLD_ENV_PATH="/usr/local/rvm/gems/ruby-1.9.3-p551/bin:/usr/local/rvm/gems/ruby-1.9.3-p551@global/bin:/usr/local/rvm/rubies/ruby-1.9.3-p551/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/rvm/bin:/root/bin"
INFO global: VAGRANT_OLD_ENV__system_arch="x86_64"
INFO global: VAGRANT_OLD_ENV_GEM_PATH="/usr/local/rvm/gems/ruby-1.9.3-p551:/usr/local/rvm/gems/ruby-1.9.3-p551@global"
INFO global: VAGRANT_INTERNAL_BUNDLERIZED="1"
INFO global: VAGRANT_LOG="debug"
INFO global: Plugins:
INFO global:   - builder = 3.2.2
INFO global:   - bundler = 1.10.5
INFO global:   - i18n = 0.6.11
INFO global:   - json = 1.8.3
INFO global:   - mime-types = 1.25.1
INFO global:   - mini_portile = 0.6.0
INFO global:   - nokogiri = <IP_ADDRESS>
INFO global:   - trollop = 2.1.2
INFO global:   - rbvmomi = 1.8.2
INFO global:   - rest-client = 1.6.9
INFO global:   - vagrant-share = 1.1.4
INFO global:   - vagrant-vsphere = 1.5.0
INFO global:   - vagrant-xenserver = 0.0.11
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/windows/plugin.rb
INFO manager: Registered plugin: Windows host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/gentoo/plugin.rb
INFO manager: Registered plugin: Gentoo host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/suse/plugin.rb
INFO manager: Registered plugin: SUSE host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/freebsd/plugin.rb
INFO manager: Registered plugin: FreeBSD host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/redhat/plugin.rb
INFO manager: Registered plugin: Red Hat Enterprise Linux host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/arch/plugin.rb
INFO manager: Registered plugin: Arch host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/linux/plugin.rb
INFO manager: Registered plugin: Linux host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/bsd/plugin.rb
INFO manager: Registered plugin: BSD host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/null/plugin.rb
INFO manager: Registered plugin: null host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/darwin/plugin.rb
INFO manager: Registered plugin: Mac OS X host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/hosts/slackware/plugin.rb
INFO manager: Registered plugin: Slackware host
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/omnios/plugin.rb
INFO manager: Registered plugin: OmniOS guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/windows/plugin.rb
INFO manager: Registered plugin: Windows guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/gentoo/plugin.rb
INFO manager: Registered plugin: Gentoo guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/solaris/plugin.rb
INFO manager: Registered plugin: Solaris guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/suse/plugin.rb
INFO manager: Registered plugin: SUSE guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/freebsd/plugin.rb
INFO manager: Registered plugin: FreeBSD guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/funtoo/plugin.rb
INFO manager: Registered plugin: Funtoo guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/esxi/plugin.rb
INFO manager: Registered plugin: ESXi guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/solaris11/plugin.rb
INFO manager: Registered plugin: Solaris 11 guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/redhat/plugin.rb
INFO manager: Registered plugin: Red Hat Enterprise Linux guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/arch/plugin.rb
INFO manager: Registered plugin: Arch guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/debian8/plugin.rb
INFO manager: Registered plugin: Debian Jessie guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/tinycore/plugin.rb
INFO manager: Registered plugin: TinyCore Linux guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/mint/plugin.rb
INFO manager: Registered plugin: Mint guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/netbsd/plugin.rb
INFO manager: Registered plugin: NetBSD guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/debian/plugin.rb
INFO manager: Registered plugin: Debian guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/smartos/plugin.rb
INFO manager: Registered plugin: SmartOS guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/linux/plugin.rb
INFO manager: Registered plugin: Linux guest.
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/nixos/plugin.rb
INFO manager: Registered plugin: NixOS guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/ubuntu/plugin.rb
INFO manager: Registered plugin: Ubuntu guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/photon/plugin.rb
INFO manager: Registered plugin: VMware Photon guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/darwin/plugin.rb
INFO manager: Registered plugin: Darwin guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/coreos/plugin.rb
INFO manager: Registered plugin: CoreOS guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/pld/plugin.rb
INFO manager: Registered plugin: PLD Linux guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/fedora/plugin.rb
INFO manager: Registered plugin: Fedora guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/atomic/plugin.rb
INFO manager: Registered plugin: Atomic Host guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/guests/openbsd/plugin.rb
INFO manager: Registered plugin: OpenBSD guest
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/kernel_v1/plugin.rb
INFO manager: Registered plugin: kernel
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/ssh/plugin.rb
INFO manager: Registered plugin: ssh communicator
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/communicators/winrm/plugin.rb
INFO manager: Registered plugin: winrm communicator
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/docker/plugin.rb
INFO manager: Registered plugin: docker-provider
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/hyperv/plugin.rb
INFO manager: Registered plugin: Hyper-V provider
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/plugin.rb
INFO manager: Registered plugin: VirtualBox provider
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/pushes/noop/plugin.rb
INFO manager: Registered plugin: noop
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/pushes/ftp/plugin.rb
INFO manager: Registered plugin: ftp
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/pushes/heroku/plugin.rb
INFO manager: Registered plugin: heroku
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/pushes/local-exec/plugin.rb
INFO manager: Registered plugin: local-exec
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/pushes/atlas/plugin.rb
INFO manager: Registered plugin: atlas
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/kernel_v2/plugin.rb
INFO manager: Registered plugin: kernel
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/synced_folders/nfs/plugin.rb
INFO manager: Registered plugin: NFS synced folders
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/synced_folders/rsync/plugin.rb
INFO manager: Registered plugin: RSync synced folders
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/synced_folders/smb/plugin.rb
INFO manager: Registered plugin: SMB synced folders
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/cfengine/plugin.rb
INFO manager: Registered plugin: CFEngine Provisioner
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/docker/plugin.rb
INFO manager: Registered plugin: docker
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/salt/plugin.rb
INFO manager: Registered plugin: salt
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/chef/plugin.rb
INFO manager: Registered plugin: chef
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/shell/plugin.rb
INFO manager: Registered plugin: shell
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/ansible/plugin.rb
INFO manager: Registered plugin: ansible
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/file/plugin.rb
INFO manager: Registered plugin: file
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/provisioners/puppet/plugin.rb
INFO manager: Registered plugin: puppet
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/halt/plugin.rb
INFO manager: Registered plugin: halt command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/suspend/plugin.rb
INFO manager: Registered plugin: suspend command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/status/plugin.rb
INFO manager: Registered plugin: status command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/box/plugin.rb
INFO manager: Registered plugin: box command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/destroy/plugin.rb
INFO manager: Registered plugin: destroy command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/list-commands/plugin.rb
INFO manager: Registered plugin: list-commands command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/resume/plugin.rb
INFO manager: Registered plugin: resume command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/help/plugin.rb
INFO manager: Registered plugin: help command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/push/plugin.rb
INFO manager: Registered plugin: push command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/ssh/plugin.rb
INFO manager: Registered plugin: ssh command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/package/plugin.rb
INFO manager: Registered plugin: package command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/plugin/plugin.rb
INFO manager: Registered plugin: plugin command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/init/plugin.rb
INFO manager: Registered plugin: init command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/rdp/plugin.rb
INFO manager: Registered plugin: rdp command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/version/plugin.rb
INFO manager: Registered plugin: version command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/provision/plugin.rb
INFO manager: Registered plugin: provision command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/ssh_config/plugin.rb
INFO manager: Registered plugin: ssh-config command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/reload/plugin.rb
INFO manager: Registered plugin: reload command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/up/plugin.rb
INFO manager: Registered plugin: up command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/global-status/plugin.rb
INFO manager: Registered plugin: global-status command
DEBUG global: Loading core plugin: /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/commands/login/plugin.rb
INFO manager: Registered plugin: vagrant-login
INFO global: Loading plugins!
INFO manager: Registered plugin: vagrant-share
INFO manager: Registered plugin: vsphere
INFO manager: Registered plugin: XenServer provider
INFO vagrant: vagrant invoked: ["up", "--provider=xenserver", "--debug"]
DEBUG vagrant: Creating Vagrant environment
INFO environment: Environment initialized (#Vagrant::Environment:0x00000002402d68)
INFO environment:   - cwd: /root/vagrant_xen
INFO environment: Home path: /root/.vagrant.d
INFO environment: Local data path: /root/vagrant_xen/.vagrant
DEBUG environment: Creating: /root/vagrant_xen/.vagrant
INFO environment: Running hook: environment_plugins_loaded
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: environment_plugins_loaded #Vagrant::Action::Builder:0x00000002ddd270
INFO environment: Running hook: environment_load
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: environment_load #Vagrant::Action::Builder:0x0000000318eec8
INFO cli: CLI: [] "up" ["--provider=xenserver"]
DEBUG cli: Invoking command class: VagrantPlugins::CommandUp::Command ["--provider=xenserver"]
DEBUG command: 'Up' each target VM...
INFO loader: Set :root = #Pathname:/root/vagrant_xen/Vagrantfile
DEBUG loader: Populating proc cache for #Pathname:/root/vagrant_xen/Vagrantfile
DEBUG loader: Load procs for pathname: /root/vagrant_xen/Vagrantfile
INFO loader: Loading configuration in order: [:home, :root]
DEBUG loader: Loading from: root (evaluating)
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
DEBUG command: Getting target VMs for command. Arguments:
DEBUG command:  -- names: ["default"]
DEBUG command:  -- options: {:provider=>"xenserver"}
DEBUG command: Finding machine that match name: default
INFO environment: Getting machine: default (xenserver)
INFO environment: Uncached load of machine.
INFO loader: Set "26549500_machine_default" = []
INFO loader: Loading configuration in order: [:home, :root, "26549500_machine_default"]
DEBUG loader: Loading from: root (cache)
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
INFO box_collection: Box found: centos65 (xenserver)
INFO machine: Initializing machine: default
INFO machine:   - Provider: VagrantPlugins::XenServer::Provider
INFO machine:   - Box: #Vagrant::Box:0x000000032efb78
INFO machine:   - Data dir: /root/vagrant_xen/.vagrant/machines/default/xenserver
INFO machine: Calling action: read_state on provider XenServer (new)
DEBUG environment: Attempting to acquire process-lock: machine-action-9a044fa05599da7322b628969a1a4d35
DEBUG environment: Attempting to acquire process-lock: dotlock
INFO environment: Acquired process lock: dotlock
INFO environment: Released process lock: dotlock
INFO environment: Acquired process lock: machine-action-9a044fa05599da7322b628969a1a4d35
INFO host: Autodetecting host type for [#<Vagrant::Environment: /root/vagrant_xen>]
DEBUG host: Trying: gentoo
DEBUG host: Trying: suse
DEBUG host: Trying: freebsd
DEBUG host: Trying: redhat
INFO host: Detected: redhat!
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: machine_action_read_state #Vagrant::Action::Builder:0x0000000260c488
INFO warden: Calling IN action: #Vagrant::Action::Builtin::ConfigValidate:0x000000032649d8
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ConnectXS:0x000000032649b0
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ReadState:0x00000003287b68
DEBUG read_state: XXXXX In ReadState
DEBUG read_state: state=not_created
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ReadState:0x00000003287b68
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ConnectXS:0x000000032649b0
INFO warden: Calling OUT action: #Vagrant::Action::Builtin::ConfigValidate:0x000000032649d8
INFO environment: Released process lock: machine-action-9a044fa05599da7322b628969a1a4d35
DEBUG environment: Attempting to acquire process-lock: dotlock
INFO environment: Acquired process lock: dotlock
INFO environment: Released process lock: dotlock
INFO machine: New machine ID: nil
INFO command: With machine: default (#<VagrantPlugins::XenServer::Provider:0x000000027e0070 @machine=#<Vagrant::Machine: default (VagrantPlugins::XenServer::Provider)>, @cap_logger=#<Log4r::Logger:0x000000027ebe98 @fullname="vagrant::capability_host::vagrantplugins::xenserver::provider", @outputters=[], @additive=true, @name="provider", @path="vagrant::capability_host::vagrantplugins::xenserver", @parent=#<Log4r::Logger:0x0000000317df60 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x00000003190f98 @mon_owner=nil, @mon_count=0, @mon_mutex=#Mutex:0x00000003190f20, @name="stderr", @level=0, @formatter=#<Log4r::DefaultFormatter:0x00000003196060 @depth=7>, @out=#<IO:>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x0000000317de48 @level=0, @outputters=[]>, @level=1, @trace=false>, @level=1, @trace=false>, @cap_host_chain=[[:xenserver, #<#Class:0x000000027e0160:0x00000002b48488>]], @cap_args=[#<Vagrant::Machine: default (VagrantPlugins::XenServer::Provider)>], @cap_caps={:docker=>#<Vagrant::Registry:0x000000027e2dc0 @items={:public_address=>#Proc:0x000000031afba0@/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/docker/plugin.rb:54, :proxy_machine=>#Proc:0x000000031afa88@/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/docker/plugin.rb:59}, @results_cache={}>, :hyperv=>#<Vagrant::Registry:0x000000027e1fd8 @items={:public_address=>#Proc:0x000000031b3070@/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/hyperv/plugin.rb:25}, @results_cache={}>, :virtualbox=>#<Vagrant::Registry:0x000000027e1808 @items={:forwarded_ports=>#Proc:0x000000031bb5e0@/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/plugin.rb:27, :nic_mac_addresses=>#Proc:0x000000031bb540@/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/plugins/providers/virtualbox/plugin.rb:32, :public_address=>#Proc:0x0000000326d240@/opt/vagrant/embedded/gems/gems/vagrant-share-1.1.4/lib/vagrant-share.rb:39}, @results_cache={}>, :vsphere=>#<Vagrant::Registry:0x000000027e0db8 @items={:public_address=>#Proc:0x000000032760c0@/opt/vagrant/embedded/gems/gems/vagrant-vsphere-1.5.0/lib/vSphere/plugin.rb:33}, @results_cache={}>}>)
INFO interface: info: Bringing machine 'default' up with 'xenserver' provider...
Bringing machine 'default' up with 'xenserver' provider...
INFO machine: Calling action: read_state on provider XenServer (new)
DEBUG environment: Attempting to acquire process-lock: machine-action-9a044fa05599da7322b628969a1a4d35
DEBUG environment: Attempting to acquire process-lock: dotlock
INFO environment: Acquired process lock: dotlock
INFO environment: Released process lock: dotlock
INFO environment: Acquired process lock: machine-action-9a044fa05599da7322b628969a1a4d35
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: machine_action_read_state #Vagrant::Action::Builder:0x00000003189888
INFO warden: Calling IN action: #Vagrant::Action::Builtin::ConfigValidate:0x0000000318e108
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ConnectXS:0x0000000318e0b8
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ReadState:0x000000031c73e0
DEBUG read_state: XXXXX In ReadState
DEBUG read_state: state=not_created
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ReadState:0x000000031c73e0
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ConnectXS:0x0000000318e0b8
INFO warden: Calling OUT action: #Vagrant::Action::Builtin::ConfigValidate:0x0000000318e108
INFO environment: Released process lock: machine-action-9a044fa05599da7322b628969a1a4d35
DEBUG environment: Attempting to acquire process-lock: dotlock
INFO environment: Acquired process lock: dotlock
INFO environment: Released process lock: dotlock
INFO batch_action: Enabling parallelization by default.
INFO batch_action: Disabling parallelization because only executing one action
INFO batch_action: Batch action will parallelize: false
INFO batch_action: Starting action: #Vagrant::Machine:0x00000003bfcd10 up {:destroy_on_error=>true, :parallel=>true, :provision_ignore_sentinel=>false, :provision_types=>nil, :provider=>"xenserver"}
INFO machine: Calling action: up on provider XenServer (new)
DEBUG environment: Attempting to acquire process-lock: machine-action-9a044fa05599da7322b628969a1a4d35
DEBUG environment: Attempting to acquire process-lock: dotlock
INFO environment: Acquired process lock: dotlock
INFO environment: Released process lock: dotlock
INFO environment: Acquired process lock: machine-action-9a044fa05599da7322b628969a1a4d35
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: machine_action_up #Vagrant::Action::Builder:0x00000003246870
INFO warden: Calling IN action: #Vagrant::Action::Builtin::HandleBox:0x00000003261dc8
INFO handle_box: Machine already has box. HandleBox will not run.
INFO warden: Calling IN action: #Vagrant::Action::Builtin::ConfigValidate:0x00000003285a20
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ConnectXS:0x000000032859d0
INFO warden: Calling IN action: #Vagrant::Action::Builtin::Call:0x000000032bd3d0
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: machine_action_up #Vagrant::Action::Builder:0x00000003b6c990
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::IsCreated:0x00000003b71ee0
INFO machine: Calling action: read_state on provider XenServer (new)
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: machine_action_read_state #Vagrant::Action::Builder:0x00000003dd7108
INFO warden: Calling IN action: #Vagrant::Action::Builtin::ConfigValidate:0x00000003de5208
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ConnectXS:0x00000003de5168
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ReadState:0x007f293c17a5b8
DEBUG read_state: XXXXX In ReadState
DEBUG read_state: state=not_created
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ReadState:0x007f293c17a5b8
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ConnectXS:0x00000003de5168
INFO warden: Calling OUT action: #Vagrant::Action::Builtin::ConfigValidate:0x00000003de5208
INFO machine: Calling action: read_state on provider XenServer (new)
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: machine_action_read_state #Vagrant::Action::Builder:0x007f293c220af8
INFO warden: Calling IN action: #Vagrant::Action::Builtin::ConfigValidate:0x007f293c22a288
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ConnectXS:0x007f293c22a260
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::ReadState:0x0000000258e380
DEBUG read_state: XXXXX In ReadState
DEBUG read_state: state=not_created
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ReadState:0x0000000258e380
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::ConnectXS:0x007f293c22a260
INFO warden: Calling OUT action: #Vagrant::Action::Builtin::ConfigValidate:0x007f293c22a288
INFO warden: Calling OUT action: #VagrantPlugins::XenServer::Action::IsCreated:0x00000003b71ee0
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: machine_action_up #Vagrant::Action::Warden:0x0000000318a8a0
INFO warden: Calling IN action: #<Proc:0x007f293c17b030@/opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:94 (lambda)>
INFO warden: Calling IN action: #VagrantPlugins::XenServer::Action::UploadVHD:0x0000000318a760
INFO upload_vhd: box name=centos65
INFO upload_vhd: box version=0
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00267847 s, 391 MB/s
INFO upload_vhd: md5=e82a8917e6b385eb708dafc5830448a0
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: []
INFO upload_vhd: virtual_size=21475270656
INFO upload_vhd: default_SR=OpaqueRef:NULL
INFO upload_vhd: created VDI:
ERROR warden: Error occurred: Wrong type NilClass. Not allowed!
INFO warden: Beginning recovery process...
INFO warden: Recovery complete.
ERROR warden: Error occurred: Wrong type NilClass. Not allowed!
INFO warden: Beginning recovery process...
INFO warden: Recovery complete.
ERROR warden: Error occurred: Wrong type NilClass. Not allowed!
INFO warden: Beginning recovery process...
INFO warden: Calling recover: #Vagrant::Action::Builtin::Call:0x000000032bd3d0
INFO warden: Beginning recovery process...
INFO warden: Recovery complete.
INFO warden: Recovery complete.
INFO warden: Beginning recovery process...
INFO warden: Recovery complete.
INFO warden: Beginning recovery process...
INFO warden: Recovery complete.
INFO warden: Beginning recovery process...
INFO warden: Recovery complete.
INFO environment: Released process lock: machine-action-9a044fa05599da7322b628969a1a4d35
INFO environment: Running hook: environment_unload
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: environment_unload #Vagrant::Action::Builder:0x007f293c22ab20
/opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:202:in conv2value': Wrong type NilClass. Not allowed! (RuntimeError)         from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:118:in block in methodCall'
from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:117:in collect'         from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/create.rb:117:in methodCall'
from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/client.rb:278:in call2'         from /opt/vagrant/embedded/lib/ruby/2.0.0/xmlrpc/client.rb:260:in call'
from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/upload_vhd.rb:72:in block in call'         from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/upload_vhd.rb:42:in synchronize'
from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/upload_vhd.rb:42:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:95:in block in finalize_action'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in block in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/call.rb:53:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /root/.vagrant.d/gems/gems/vagrant-xenserver-0.0.11/lib/vagrant-xenserver/action/connect_xs.rb:28:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/config_validate.rb:25:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builtin/handle_box.rb:56:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/warden.rb:34:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/builder.rb:116:in call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in block in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/util/busy.rb:19:in busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/action/runner.rb:66:in run'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:214:in action_raw'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:191:in block in action'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/environment.rb:516:in lock'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:178:in call'         from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/machine.rb:178:in action'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

I think the issue is that your default SR isn't set - you should configure this on your Xenserver. I recommend using an NFS SR.

Thanks. It works after I set a default SR.

OK, I'll close this issue then.

I've added a line to README.md to say that the default_SR needs to be set. Thanks for the report!


feat: remote loop= keyword arg #1

async_timeout 4.0 dropped support for loop= keyword arg. Home assistant 2022.3 switched to aiohttp 3.8, thus this fix is to be applied to keep the integration working (https://github.com/home-assistant/core/pull/65732)

Thank you.
I merged this, though I can't test it anymore as I switched to https://github.com/travisghansen/hass-pfsense instead, which supports much more features, including gateway status.
I recommend to use that instead of this.


cc.org/blog ordering of posts + displaying dates

hi, re: https://creativecommons.org/blog/
blog posts on this page display in this order:
1 hero post
then 4 featured posts
then all posts, from most to least recent
the effect of this ordering has always struck me as odd. if you go to this page, i feel you would expect to see a more straightforward view, with the most recent news at the top. i understand having Hero and Featured hierarchy for how posts appear on CC's homepage, but having that hierarchy carry over to /blog is confusing. especially because posts end up appearing twice on this page if they are selected as Hero or Featured.
at any rate, i would like to change things so that this page simply shows the most recent blog post up at the top, and does away with elevating Hero and Featured posts
ALSO, i would like each post on this page to show the date it was published. Currently, the date shows up for the Hero and (three of the four?) Featured posts, but it should show up for all of them.
THANKS
cc @victoriaheath @jennryn

"featured news" widget removed and date added to the entries list

I think it would be good to remove leading 0s from the date @hugosolar. It should just say "December 9, 2019".

Hi all,
Not sure if anyone else is experiencing this, but I was looking at my blog
posts and realized not all are listed anymore. Here are two that do not
come up under my name:
https://creativecommons.org/2018/05/15/certificates-updates/
https://creativecommons.org/2018/04/14/announcing-open-registration-for-cc-certificates/
Maybe some have been lost in the shuffle for others too?
Best,
Jennryn
Jennryn Wetzler
Assistant Director of Open Education
Creative Commons https://creativecommons.org/

Learn: CC Certificate https://certificates.creativecommons.org/
Join: CC Open Education Platform
https://creativecommons.org/2017/09/05/invitation-join-cc-open-education-platform/
Sign up: CC newsletter
https://creativecommons.org/about/contact/newsletter
Read: Creative Commons for Educators and Librarians
https://www.alastore.ala.org/content/creative-commons-educators-and-librarians?_zs=pbaiW1&_zl=1XGC6
Tw: @jennrynw
ICDE Ambassador for the global advocacy of OER

On Wed, Dec 11, 2019 at 9:29 PM Kriti Godey<EMAIL_ADDRESS>wrote:

I think it would be good to remove leading 0s from the date @hugosolar
https://github.com/hugosolar. It should just say "December 9, 2019".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/creativecommons/creativecommons.org/issues/1033?email_source=notifications&email_token=AI7XL4C3VDE5EUY7BYEQLH3QYGOZ5A5CNFSM4I6K5JY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGVIBOA#issuecomment-564822200,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI7XL4FJKN3V3CCVD3OYZFDQYGOZ5ANCNFSM4I6K5JYQ
.

Reopening issue so we can investigate @jennryn's issue.

Jennryn's issue isn't related to this
I create a new issue to fix that problem: #1054
I'll keep this issue open until I fix the date format pointed by @kgodey


Support cancelling of CDTFetchChanges

What
We now periodically check for the NSOperation's cancelled
property and bail early rather than always running the whole
changes fetch process.
How
Returning early from methods if the cancel state is set.
reviewer: @indisoluble
reviewer: @gadamc
BugId: 46038

@indisoluble probably has more NSOperations experience than me, but it looks good to me.
When will direct tests be added? (CDTFetchChanges is tested indirectly via the Index tests, I presume.)

After reading a bit more on NSOperations, I have a question.
Is CDTFetchChanges re-usable? From what I understand, after a CDTFetchChanges object completes the -main function, the isFinished property will be set to YES and will no longer call -main on subsequent calls to -start. From the documentation (https://developer.apple.com/library/ios/documentation/Cocoa/Reference/NSOperation_class/index.html#//apple_ref/occ/instm/NSOperation/start)

The default implementation of this method updates the execution state of the operation and calls the receiver’s main method. This method also performs several checks to ensure that the operation can actually run. For example, if the receiver was cancelled or is already finished, this method simply returns without calling main.

Additionally... the next few lines in this documentation describe exceptions thrown by NSOperation. Do we handle those properly? Our -main method doesn't catch anything. (Am I reading the documentation correctly?)

(In OS X v10.5, this method throws an exception if the operation is already finished.) If the operation is currently executing or is not ready to execute, this method throws an NSInvalidArgumentException exception. In OS X v10.5, this method catches and ignores any exceptions thrown by your main method automatically. In OS X v10.6 and later, exceptions are allowed to propagate beyond this method. You should never allow exceptions to propagate out of your main method.

@gadamc Yes, you're right about exceptions. This isn't related to this PR, but I should go re-read the NSOperation docs.
I also intend to add tests but have been pulled in a bunch of different directions so haven't got to this as quickly as I'd like after getting the merge in for the changes reading bug fix.

@gadamc You are absolutely right, a NSOperation  can only be used once.
I've re-read the documentation and I haven't found any reference to set startSequenceValue and call again -start. I think this was my mistake, I said that CDTFetchChanges (as well as its Apple counterpart CKFetchRecordsOperation) could be re-used in this comment.

@indisoluble I don't think there's an explicit instruction in the documentation to set startSequenceValue and then call -start, but I think it's definitely implied by lines:
https://github.com/cloudant/CDTDatastore/blob/master/Classes/common/CDTFetchChanges.h#L34
https://github.com/cloudant/CDTDatastore/blob/master/Classes/common/CDTFetchChanges.h#L60-L62
https://github.com/cloudant/CDTDatastore/blob/master/Classes/common/CDTFetchChanges.h#L156.
These lines reference a "previous fetch". I think it would be more clear if they said something like "obtained from the completion block of a previous CDTFetchChanges object", or "previous CDTFetchChanges object". Also, I think we should put at the top of the documentation for the class, as a reminder, that this is a single-use object because it inherits from NSOperation. (Not everybody is going to remember that NSOperations are single-use could be a pain point for somebody. I don't see why we just wouldn't remind them here in the class description.)
I've opened a new FB ticket (46342)

I agree, the reminder would be a good idea ... I totally forgot it :)

@gadamc I updated the docs to replace "request" and "fetch" with "operation" which implies to me a new operation object.

@indisoluble and @gadamc please check this one again.

+1

Thanks @indisoluble @gadamc


Refactor character stats

Just making this PR to prevent future merge conflicts. This adds no additional functionality since it's not wired up

Don't want this accidentally merged. Closing for now.


[WIP] Add warning if backend is paused

Summary
Fixes #99
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-2 of 3 (33.33%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-3.3%) to 29.783%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_ibm_provider/ibm_backend.py
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
-3.3%

Covered Lines:
1647

Relevant Lines:
5530

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 3 (33.33%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-3.3%) to 29.783%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_ibm_provider/ibm_backend.py
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
-3.3%

Covered Lines:
1647

Relevant Lines:
5530

💛  - Coveralls


Using yarn scheduler, transformsTopology and WindowedWordCountTopology can not be run well.

I run SmartWatchTopology example well on yarn well, two yarn containers are created and topology can work well. But when I run TransformsTopology on yarn, only one yarn container is created ,so topology can not work.  Comparing the driver.err files, when TransformsTopology is running, less logs can not be seen than SmartWatchTopology such as :
localHostTrusted = false, remoteHostTrusted = false
2020-03-16 15:19:01,926 INFO impl.NMClientAsyncImpl: Processing Event EventType: START_CONTAINER for Container container_1584341343088_0001_01_000002
2020-03-16 15:19:01,981 INFO impl.NMClientAsyncImpl: Processing Event EventType: QUERY_CONTAINER for Container container_1584341343088_0001_01_000002
2020-03-16 15:21:13,302 INFO imps.CuratorFrameworkImpl: backgroundOperationsLoop exiting
2020-03-16 15:21:13,305 INFO zookeeper.ZooKeeper: Session: 0x1000000f3f50003 closed
2020-03-16 15:21:13,305 INFO zookeeper.ClientCnxn: EventThread shut down for session: 0x1000000f3f50003
2020-03-16 15:21:13,393 INFO impl.AMRMClientImpl: Waiting for application to be successfully unregistered.
heron submit yarn TransformsTopology
part of driver.err:
2020-03-16 15:31:21,116 INFO zookeeper.ZooKeeper: Client environment:java.io.tmpdir=/var/folders/zr/dgwn7zgn3fbcjmv25t_ybsc80000gp/T/
2020-03-16 15:31:21,116 INFO zookeeper.ZooKeeper: Client environment:java.compiler=
2020-03-16 15:31:21,116 INFO zookeeper.ZooKeeper: Client environment:os.name=Mac OS X
2020-03-16 15:31:21,116 INFO zookeeper.ZooKeeper: Client environment:os.arch=x86_64
2020-03-16 15:31:21,116 INFO zookeeper.ZooKeeper: Client environment:os.version=10.14.6
2020-03-16 15:31:21,116 INFO zookeeper.ZooKeeper: Client environment:user.name=guoxinghua
2020-03-16 15:31:21,117 INFO zookeeper.ZooKeeper: Client environment:user.home=/Users/guoxinghua
2020-03-16 15:31:21,117 INFO zookeeper.ZooKeeper: Client environment:user.dir=/Users/guoxinghua/hadoop-3.2.1/hdfs_dir/nm-local-dir/usercache/guoxinghua/appcache/application_1584341343088_0004/container_1584341343088_0004_01_000001
2020-03-16 15:31:21,117 INFO zookeeper.ZooKeeper: Initiating client connection, connectString=<IP_ADDRESS>:2181 sessionTimeout=30000 watcher=org.apache.curator.ConnectionState@39e43310
2020-03-16 15:31:21,128 INFO zookeeper.ClientCnxn: Opening socket connection to server localhost/<IP_ADDRESS>:2181. Will not attempt to authenticate using SASL (unknown error)
2020-03-16 15:31:21,129 INFO zookeeper.ClientCnxn: Socket connection established to localhost/<IP_ADDRESS>:2181, initiating session
2020-03-16 15:31:21,135 INFO zookeeper.ClientCnxn: Session establishment complete on server localhost/<IP_ADDRESS>:2181, sessionid = 0x1000000f3f50020, negotiated timeout = 30000
2020-03-16 15:31:21,140 INFO state.ConnectionStateManager: State change: CONNECTED
heron submit yarn SmartWatchTopology
part of driver.err:
2020-03-16 15:18:47,230 INFO state.ConnectionStateManager: State change: CONNECTED
2020-03-16 15:19:01,066 INFO sasl.SaslDataTransferClient: SASL encryption trust check: localHostTrusted = false, remoteHostTrusted = false
2020-03-16 15:19:01,438 INFO sasl.SaslDataTransferClient: SASL encryption trust check: localHostTrusted = false, remoteHostTrusted = false
2020-03-16 15:19:01,777 INFO sasl.SaslDataTransferClient: SASL encryption trust check: localHostTrusted = false, remoteHostTrusted = false
2020-03-16 15:19:01,879 INFO sasl.SaslDataTransferClient: SASL encryption trust check: localHostTrusted = false, remoteHostTrusted = false
2020-03-16 15:19:01,926 INFO impl.NMClientAsyncImpl: Processing Event EventType: START_CONTAINER for Container container_1584341343088_0001_01_000002
2020-03-16 15:19:01,981 INFO impl.NMClientAsyncImpl: Processing Event EventType: QUERY_CONTAINER for Container container_1584341343088_0001_01_000002
2020-03-16 15:21:13,302 INFO imps.CuratorFrameworkImpl: backgroundOperationsLoop exiting
2020-03-16 15:21:13,305 INFO zookeeper.ZooKeeper: Session: 0x1000000f3f50003 closed
2020-03-16 15:21:13,305 INFO zookeeper.ClientCnxn: EventThread shut down for session: 0x1000000f3f50003
2020-03-16 15:21:13,393 INFO impl.AMRMClientImpl: Waiting for application to be successfully unregistered.

Hmm. You mean other topologies work but these two don't?


Expose multi-sided card/printing data

This PR will implement the multi-sided card data in the API.
In it's current form, cards and printings have card/printing faces associated with them respectively that can be accessed through a relationship. All cards/printings have at least one face, where multi-sided cards have multiple. Any data omitted in the source JSON faces will be copied from the base card/printing.
Some issues:

Does not unify card faces with printing faces as the existing API does for cards and printings
Cards/printings are inconsistent

some multi-sided cards have only one printing face (SYNC: Everything, Everywhere all at once)
some multi-sided printings only have one card face (Matryoshka)

Card images are not yet supported across faces

the flip sides of cards aren't yet available on nrdb so would need uploading

I also want to change the terminology in the source json to match this better:

sides -> faces
the layout ID single-sided -> normal
single-sided was originally normal but I changed it. I'm not sure that change was good though since, if Netrunner ever starts printing cards like MtG, then it becomes inaccurate.

Example of card faces:

Example of printing faces:

JSON fixes are added here

Also, how do you feel about the faces tables only having entries for other faces, without duplicating anything that is on the first face?
I think omitting data like that means if users want to get the complete data on a card's face they need to manually piece it together themselves

Users won’t be dealing with the tables. They will be dealing with the
output of the api.
I maybe made an incorrect assumption that the faces table would only have
faces that aren’t single sided cards, because why duplicate it?
I think we can separate out the db schema from how we represent it in the
api, but I also have a bit of a preference for faces only being populated
if needed.
On Wed, Jun 7, 2023 at 6:54 AM distributive law @.***>
wrote:

Also, how do you feel about the faces tables only having entries for other
faces, without duplicating anything that is on the first face?
I think omitting data like that means if users want to get the complete
data on a card's face they need to manually piece it together themselves
—
Reply to this email directly, view it on GitHub
https://github.com/NetrunnerDB/netrunnerdb-api-server/pull/177#issuecomment-1580649735,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADA2EV4HUEXAYHGC6SVB2TXKBTYDANCNFSM6AAAAAAYNFFOOQ
.
You are receiving this because your review was requested.Message ID:
@.***>

--
-jason

I misunderstood yeah. Do you mean we should leave the data blank when duplicated or are there fields we should omit from the tables?
Also we shouldn't have a face for cards with only one. I'll make that change.

I misunderstood yeah. Do you mean we should leave the data blank when duplicated or are there fields we should omit from the tables?

I would go with:

only add fields to faces when we have a card/printing that needs them
leave the fields that exist blank when duplicated.

the operation in the api will be ~ merge with base, use non-null fields to overwrite.
That won't work if we have some fields that are straight up not present on the other faces, though, so duplicating isn't bad in that case.


Undoing change that broke code samples

@DuncanmaMSFT,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-autogen/account.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/acr.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/acr/credential.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/acr/repository.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/acs.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/acs/dcos.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/acs/kubernetes.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/ad/app.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/ad/group.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/ad/group/member.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/ad/sp.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/ad/user.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/plan.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/config.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/config/appsettings.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/config/backup.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/config/container.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/config/hostname.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/config/ssl.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/deployment.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/deployment/slot.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/deployment/user.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/log.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/appservice/web/source-control.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/account.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/account/autostorage-keys.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/account/keys.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/application.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/application/package.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/application/summary.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/certificate.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/job-schedule.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/job.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/job/all-statistics.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/job/prep-release-status.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/location/quotas.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/node.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/node/file.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/node/remote-desktop.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/node/remote-login-settings.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/node/scheduling.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/node/user.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/pool.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/pool/all-statistics.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/pool/autoscale.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/pool/node-agent-skus.pycliyml
:white_check_mark:Succeeded
View

docs-ref-autogen/batch/pool/os.pycliyml
:white_check_mark:Succeeded
View

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add react-virtualized-tree

Don't create a pull request to add a library, instead use devarchy.com/react.
Only create a pull request to change the categorization.
Open an issue if you are not sure how to change the categorization to fit a library you want to add.

Is there a reason you didn't use https://devarchy.com/react?


fix hang of server waiting for forked daemon to time out

Temporarily fixes #254.

Maybe we should add a TODO or open another ticket to remind us to remove the workaround in the future

I don't think this needs a todo in the code. Whenever we get an updated version of Connext which addresses the problem we can remove the patch.

In several places we track upstream issues otherwise we never revert the hacks, I'm not sure why this particular one is different

Please feel free to add a todo if you think it is necessary.

Sounds good https://github.com/ros2/rmw_connext/commit/2edfe9da0ced9b9e44382a773216fb01e2768b4a


poison version 4 breaks decoding

Poison Version 4 changes interface for decoding into structs.
This results in an error like:

function Poison.Decode.decode/2 is undefined or private

Poison.Decode.decode -> Poison.Decode.transform (different options)
https://github.com/devinus/poison/compare/3.1.0...master#diff-008cd84cae620b00278a75ce952aa006
Will need to update GoogleApi.Gax.ModelBase to handle either version.
Until fixed, you can bypass this by forcing old :poison in your mix.exs
    {:poison, "~> 3.1.0"}, # force old poison

It's been a while, but I've just revisited this code and updating the lib from 0.0.1 to 0.9.1 has fixed this issue. Means I can remove a lot of boilerplate from my code and just use these API calls :+1:

@zeroasterisk Does @absolutejam's comment fix the issue for you too?

@JustinBeckwith This is still an issue. (That the libraries are incompatible with the latest poison.) We've only papered over it by pinning to an earlier version.

Yes, sorry I have not had any time to look into Elixir code in months (woe is me). But until we abstract out the marshaling of structs, I think this issue remains... and the longer it remains, the more new users will be blocked/stumbled by it.


Question: ROS2 control of Cyberdog

Hi!
I'm using the robot and so far I'm really impressed with it, awesome work!
I was able to get sample gRPC code running, and build some sample apps on top of that.
I'm curious whether there are any simple examples of operating using ROS2 directly?  If not, do you have any recommendations on how to approach it? So far, the best idea I have is to instantiate Cyberdog_app Node and go from there.
Best,
Tomasz

Hi Tomasz. Thanks for your attention! There are many ways to control cyberdog, like using gRPC, ROS 2 messages, LCM, etc. We use gRPC as a very high level to control the robot, because it support so many programming languages. But ROS messages is only support C++ and Python, if you do not install third party RCL implementation. LCM is only designed for locomotion controling, we use it because MIT mini cheetah using it. The locomotion is built on their exellent work.
You can do more things by using ROS messages, but I'm refactoring the whole project recently. Hince many APIs will change in Future. APIs are including all controlling cmds, sensor datas, output devices cmds.
But if you want to control robot only. Please refer to https://github.com/MiRoboticsLab/cyberdog_ros2/tree/devel/cyberdog_interfaces/motion_msgs and https://github.com/MiRoboticsLab/cyberdog_ros2/blob/devel/cyberdog_managers/README_EN.md . I forgot writing English README for interfaces, you could translate it with Google Translation. If you have any problem, please let me know. And post in this issue. Thank you.

By the way. As we chatted at Telegram. Publishing the IP of the HOST device as a string to topic "ip_notify" is the best way to active cyberdog with gRPC. The HOST device could be your mobile phone, or your PC in the same local area network or wireless local area network.

https://github.com/MiRoboticsLab/cyberdog_ros2/blob/devel/cyberdog_managers/README_EN.md

The url:
https://github.com/MiRoboticsLab/cyberdog_ros2/blob/devel/cyberdog_managers/README_EN.md
was changed to
https://github.com/MiRoboticsLab/cyberdog_ros2/blob/devel/cyberdog_decision/README_EN.md


Splitting a table into two based on a condition

Add a function which splits a table based on a condition, returning two tables, one where the condition is True, the other where the condition is False.
This is convenience for two calls to select():
def biselect(tbl, *args):
    return select(tbl, *args), select(tbl, *args, complement=True)

Name of new function TBD.

Working on this now.


Switch to client-side rendering

Generating static pages for each symbol is a no-go; way too many, way
too big content. Let's "just" request the JSON from the client, and
render on the client.

Fetching (including caching) with https://swr.vercel.app/, as
recommended by Next.js
Updated README.md (and created .gitkeep) to store devenv index in
www/public, so that it gets served at the same URL as in prod

Oh, one more thing. publish.sh needs changing to use the new www/public/_index dir

Oh, one more thing. publish.sh needs changing to use the new www/public/_index dir

Right. I assumed this works differently than it does.


Add manual eviction and move semantics

Sometimes you need to evict an item from
the cache (i.e. if you know the underlying
object is no longer valid).
Move semantics allow us to place objects in
and evict objects from the cache without
copying them.
Bonus: It's now possible to pass non-copyable
objects like unique_ptr through the cache,
although you won't be able to retrieve them
without eviction.

I looked at your pull request and decided to make better tests in the project. Now they seem to be pretty good.
Could you please rebase to fresh master and add tests to your changes?


Update Rmd to use the Valtools framework

Hey @mariev
I was adding this to the process but I thought of something that could be an issue. One of the reasons the process currently writes to txt files and reads them is that we don't want any dependancies on other packages because they can cause the container or system to become too large. Can you think of a way to render the results of the validation tests without having valtools installed?
I was thinking we could have a process that saves the output but then those can be pulled down and rendered into a valtools report in a different system.
Let me know if you have any thoughts


🐛 Fix Defender broken Endpoint #11217

Defender can be used (rolled out) on various devices: servers, mobile phones, IoT devices, clients. This results in broken endpoints, because DefectDojo parses "computerDNSName" as an endpoint. However, dropping this information is not beneficial as it is an important identifier especially for mobile phones, IoT devices and clients. The problem is that the computerDNSName of these devices do not always follow https://en.wikipedia.org/wiki/URL#Syntax.
Thus, this information needs to be cleaned up. An example is the following string:
Max Mustermann iPadAir 17zoll (2ndgeneration)

I'm not sure about putting DNS name to UserInfo. It is quite well defined, what should be there

An optional userinfo subcomponent followed by an at symbol (@), that may consist of a user name and an optional password preceded by a colon (:). Use of the format username:password in the userinfo subcomponent is deprecated for security reasons. Applications should not render as clear text any data after the first colon (:) found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password).

https://en.wikipedia.org/wiki/URL#Syntax

Could you merge this @mtesauro?


Update to use KepConfig package for Project Sync example

@MRoyPTC Do you mind reviewing and verifying these changes?

Reviewed and verified.


Use chrome HTML template for local development.

Changes

update webpack-dev-server
use chrome HTML template in development environment; New version of webpack dev server broke ESI tags mutation due to closed response headers.

The solution seems ok, but I wasn't able to get the UI running with stage-beta (via our "start" target).

Right, I forgot to remove the original template override. It should be working now, can you verify?

Curious why the templates are used only with isProduction?

Because in a dev environment, the HTML middleware would override the chrome template that is duplicated before the dev server is turned on. We don't want to use that template anymore. This change is now in stage beta but not yet in production.


Patch v8 to support promise cross-context resolution

Draft for now until I add tests tests and more tests
export default {
  async fetch(req, env, ctx) {
    if (globalThis.resolve === undefined) {

      {
        const { promise, resolve } = Promise.withResolvers();
        setTimeout(resolve, 1000);
        ctx.waitUntil(promise);
      }

      // This is our first request. We will create a new promise and resolver
      // pair and store it in a global. This request will then wait for the
      // promise to be resolved before continuing.
      const { promise, resolve } = Promise.withResolvers();
      globalThis.resolve = resolve;
      globalThis.promise = promise;
      const ab = AbortSignal.abort();
      console.log(ab.aborted);
      promise.then(() => {
        // This will be run within the correct IoContext now...
        try {
          console.log('test1', ab.aborted);
        } catch (err) {
          // We would get here if the IoContext was incorrect because
          // of the call to ab.aborted
          console.log(err.message);
        }
      });
    } else {
      // This is our second request. We will resolve the promise created in the
      // first request.
      console.log('....');
      globalThis.resolve();
      globalThis.resolve = undefined;
      console.log('test2');
    }

    return new Response("Hello World\n");
  }
};

Some details on how this works:

Per the original fixup, every IoContext has an associated opaque JS object called the "promise tag"
Originally, this promise tag was just a simple, ordinary JS object. With this PR it becomes an opaque wrapper around an kj::Own<IoContext::WeakRef>
When an IoContext becomes current/locked, that IoContexts promise tag is associated with the v8::Isolate as the "current promise tag"
Per the original fixup, whenever a Promise is created, the Isolate's "current promise tag" is associated with the Promise in an internal field.
In the original fixup, when a Promise is followed (.then(...), .catch(...), etc), we check to see if the current promise tag matches the promises context tag. If they are not the same, then the promise is a "cross-context promise" and we arrange for proper cross-context signaling.
This PR adds that when the resolve(...) or reject(...) methods are called, and we determine that the promise is a cross-context promise, scheduling of the promise continuations will be deferred until after we re-enter the promise's original IoContext.
If the promise's original IoContext has been destroyed, we drop the continuations on the floor and emit a warning.

TODOs

Handle reject() ... Currently this only deals with the resolve case. Needs to handle the reject case also but that will follow the identical pattern.
Tests! Make sure all the various ways promises are resolved are handled. Async iterators, custom thenables, etc
Documentation ... We should add documentation to the website

Patch updated to address the linux-debug CI failure, and added an additional test case.

CI is failing due to a transient issue downloading stuff....

Here's a diff to the diff file, which uses Handles more, and raw Tagged pointers less.  Feel free to use it, or I'll just do a separate change tomorrow (where I'll probably also unify the 0007 and 0019 patches to one file).
handles.txt

Rebased and squashed


make doesn't work for missing some packages

In some VMs, it would occur some errors below when the ansible executes make operation:
TASK [common : build opensds binary file] **********************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": "make", "delta": "0:00:06.949644", "end": "2018-06-11 01:28:35.678342", "msg": "non-zero return code", "rc": 2, "start": "2018-06-11 01:28:28.728698", "stderr": "# github.com/opensds/opensds/vendor/github.com/ceph/go-ceph/rados\nvendor/github.com/ceph/go-ceph/rados/conn.go:4:21: fatal error: stdlib.h: No such file or directory\n // #include <stdlib.h>\n                     ^\ncompilation terminated.\nmake: *** [osdsdock] Error 2", "stderr_lines": ["# github.com/opensds/opensds/vendor/github.com/ceph/go-ceph/rados", "vendor/github.com/ceph/go-ceph/rados/conn.go:4:21: fatal error: stdlib.h: No such file or directory", " // #include <stdlib.h>", "                     ^", "compilation terminated.", "make: *** [osdsdock] Error 2"], "stdout": "mkdir -p  ./build/out/bin/\ngo build -o ./build/out/bin/osdsdock github.com/opensds/opensds/cmd/osdsdock\nMakefile:24: recipe for target 'osdsdock' failed", "stdout_lines": ["mkdir -p  ./build/out/bin/", "go build -o ./build/out/bin/osdsdock github.com/opensds/opensds/cmd/osdsdock", "Makefile:24: recipe for target 'osdsdock' failed"]}

After some research, I found that the reason is that these VMs doesn't contain build-essential package by default, so we should add them in package downloading step.

Solved


Newton's cradle gets "stuck" on wide canvas

If I have a canvas that's around 1400px wide and center the cradle inside, the furthest right body will get "stuck" up on the right side after the first collision.
http://codepen.io/anon/pen/doJWrL?editors=001

Just saw this is a duplicate of https://github.com/liabru/matter-js/issues/67


Don't always assume Bible type from repo name with bookname

Pull Request Test Coverage Report for Build 287

12 of 18 (66.67%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.05%) to 74.901%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

resource_container/ResourceContainer.py
7
13
53.85%

Totals

Change from base Build 284:
-0.05%

Covered Lines:
4906

Relevant Lines:
6550

💛  - Coveralls


cases.facilitators vs. method.facilitator

Normalize the case used between articles.

fixed by PR #525
Requires a database reset


The page about the "image" function in the official documentation cannot be opened

Description
The page about the "image" function in the official documentation cannot be opened.
Cannot open https://typst.app/docs/reference/visualize/image/
Reproduction URL
No response
Operating system
No response
Typst version

[ ] I am using the latest version of Typst

Works fine here


more information for 'firsts'

eg hovering over first blood should show who got fb, and who died. showing only the timer is very abstract.

This is a client side issue.  Could you reopen it there?

done. btw i'm not entirely clear on which features would depend on backend changes and need to be opened here.

As far as I'm aware all of the "first" information that is currently displayed is generated from the match data sent to the client.  If there is something specific desired, we can open a new issue for that.

i meant in general, it's not obvious which information is sent to the client, unless you open a console or dig through the code. a short section in the readme to clarify this would help me decide which repo to open an issue in.


[Secondary Actions Header] ReactDom is undefined

Current behaviour
When we click on the button generated by the secondary actions header, the error : Uncaught ReferenceError: ReactDOM is not defined appear.

We need to import ReactDom in our view to solve this issue.
Expected behaviour
The import is done in the class which manage the header.
Versions
Focus-core: 0.14.0
Focus-components: 0.14.1

Are you sure?
See https://github.com/KleeGroup/focus-components/blob/2a9e39d1ed08cdb103abbd0fc013a29858d10d0f/src/components/icon-dropdown/index.js#L2
The import is already done.

Yes, I tried again and the error is still here when i click on the secondary action button.

You can update to the next version, the problem is solved.

@JohnnP Upgrade and reopen the issue if there is a problem.


Add heartbeat to editor tunnel websocket

Description
If the device editor has the editor tunnel connected, but there is no active editor open, the websocket goes idle and gets disconnected by the platform regularly. This fills the logs with connection closed/reconnecting log messages - which can make the platform appear unstable to the user.
It would be better to have a heartbeat keeping the connection alive.
Will need to be done in a way that doesn't upset the platform when this new heartbeat packet arrives from an updated device agent.
Epic/Story
No response

@knolleary how did you get the editor tunnel to connect, but not have an open editor?
Do you need to open a editor then close it?