Schema is not updated on schemaPath file changes when schema file is outside of project's directory

Describe the bug
Houdini's config file houdini.config.js allows to use a schemaPath file to use as its schema source, but this file is not watched.

This issue makes it a bit annoying to work in a monorepo, as every change to the API I make needs to be reflected in houdini via a client restart (and I mean a full stop and start, as simply restarting the vite server with r is not enough). While vite is fast to start, this messes up my workflow of using vscode tasks to debug my websites, and I must close everything and reopen everything, losing context.
Severity
annoyance
Steps to Reproduce the Bug

Setup bare repo with a random graphql schema file
Use schemaPath in houdini.config.js to point to this graphql schema file
Start Vite server
Update graphql schema file with new query
Try to use new query in repo

Reproduction
No response

Yes, if I remember correctly, vite can't watch outside of its directory.
I could see 3 workarounds:
A/ At the root level of the monorepo, add vite-plugin-watch-and-run and trigger cd myPath && npm run houdini generate on this file change?
B/ The API could write into 2 places at the same time?
C/ You could watch the schema via watchSchema option in http mode
What do you think?

Yes, if I remember correctly, vite can't watch outside of its directory.
I could see 3 workarounds: A/ At the root level of the monorepo, add vite-plugin-watch-and-run and trigger cd myPath && npm run houdini generate on this file change?
B/ The API could write into 2 places at the same time?
C/ You could watch the schema via watchSchema option in http mode
What do you think?

Ah, I see how this isn't feasible to watch as a vite plugin then, I'll see about some of these features!
For the C/ option, I do not believe it works with both using schemaPath and watchSchema.url ; Updating the schema (both the file and the endpoint at the same time) does not update houdini.
For the A/ option, is using houdini generate updating the vite plugin? or would I need to disable the vite plugin's watcher while running a custom watcher + manual generate command?

Yeah, sorry I didn't elaborate too much.
For C/, I was thinking to remove the schemaPath and it would create a local ./schema.graphql that will be used for the frontend portion.
For A/, same thing, removing schemaPath, so that generate regenerate the schema file for the frontend when needed. You still need to keep the vite houdini plugin as it's doing a lot more things ;)

No worries, I like pushing things so that I understand correctly :)

remove the schemaPath

The JSDoc of the schemaPath and schema config values mention there needs to be at least one of the two, do you mean removing the schemaPath and not using schema or essentially switching to schema?

Probably a JSDoc info to update, because schemaPath (optional, default: "./schema.graphql")
You should be able to comment all of it

Well, I will take the solution with C/ as this is currently the fastest way for me to get this annoying kink worked out.
Essentially, setting neither schemaPath, schema and watchSchema does not work, but setting both schemaPath and watchSchema makes it so that houdini watches from the watchSchema.url property, but writes the file to the filepath defined by schemaPath.

However, using this approach, you cannot reference in the schemaPath folders that do not exist as a nasty error pops up while trying to either use houdini pull-schema or starting the vite dev server. Either create the folder first, or use a generic name. My guess is that it is simply because houdini does not try to create missing folders while writing to the schemaPath specified.
Welp, I was trying to prevent using http polling since I had the file already in my filesystem, but working around vite's limitations is annoying for sure so this is the best solution so far.
Thanks for the pointers! You can close this issue if you want, or leave it up for a JSDoc clarification reminder :)

Although now I remember why I did want to use the schemaPath: CI build uses the auto-generated schema file to prevent having to spin up an entire server just for the sake of generating the houdini runtime...
So I guess my issue is still not resolved...

Because you put your generated frontend schema in ./$houdini, so gitignored.
If you don't gitignore it, it should be good.

Because you put your generated frontend schema in ./$houdini, so gitignored. If you don't gitignore it, it should be good.

Well, yes, I do gitignore my generated schema because I don't want to pollute my repo with auto-generated documents. A simple fix is to commit it indeed.
I think I'll look into using a file watcher that runs from a vscode task (I already have three, might as well patch this into one of them haha).
Just to properly understand, is there a command to make the vite plugin pick up the changes to the schema? If I run houdini generate on file change myself, the vite plugin does not pickup the changes... Should I try to send a restart command to vite somehow?

If you prefer, we can pop in the Discord server for a more direct chat, then I'll summarize what we say in here - I'm having a hard time wrapping my head around how the houdini cli and the vite plugin communicate together 😅

Let's continue here: https://discord.com/channels/1024421016405016718/1177011137552855100 :)

Summary of solution from discord chat :
With my particular setup, since I generate the schema file automatically, what I did was add a copy file directive to my api script that essentially copies the schema file toward the gitignored $houdini folder, making it available for the build context as discussed in https://github.com/HoudiniGraphql/houdini/issues/1234#issuecomment-1823560715.
So yeah, solution B/ was the thing (for me) after all!
Git commit link for those interested (ignore the added defaultFragmentMasking: 'disable', line) : https://github.com/ved-websites/fullstacked/commit/036b4afd8b08a203351974f1a18bbb00b49e8159

Im going to close this since its gone a bit stale and we. are limited by vite's functionality


Fix bower

when installing with bower the latest version available is 1.1.6, I believe this is related to tag 1.2 that should be 1.2.0

thx for noticing it ;)


feat: handle errors in async middlewares

errors thrown in async middlewares would usually lead to
unhandled promise rejections and wouldn't trigger the express
error handler.
this change catches exceptions in async middlewares and forwards
them to the express error handler by calling next
Co-authored-by: Björn Brauer<EMAIL_ADDRESS>Co-authored-by: Jonas Holland<EMAIL_ADDRESS>This pull request closes issue # (put the issue number here)

Current state

Changes introduced here

Checklist

[ ] All commit messages adhere to the appropriate format in order to trigger a correct release
[ ] All code is written in untranspiled ECMAScript (ES 2017) and is formatted using prettier
[ ] Necessary unit tests are added in order to ensure correct behavior
[ ] Documentation has been added

Bors merge bot cheat sheet
We are using bors-ng to automate merging of our pull requests. The following table provides a summary of commands that are available to reviewers (members of this repository with push access) and delegates (in case of bors delegate+ or bors delegate=[list]).

Syntax
Description

bors merge
Run the test suite and push to master if it passes. Short for "reviewed: looks good."

bors merge-
Cancel an r+, r=, merge, or merge=

bors try
Run the test suite without pushing to master.

bors try-
Cancel a try

bors delegate+
Allow the pull request author to merge their changes.

bors delegate=[list]
Allow the listed users to r+ this pull request's changes.

bors retry
Run the previous command a second time.

This is a short collection of opinionated commands. For a full list of the commands read the bors reference.

bors merge


Could not create task for annotating 3D point cloud

Actions before raising this issue

[X] I searched the existing issues and did not find anything similar.
[X] I read/searched the docs

Steps to Reproduce

Open the CVAT home page
Go to the page for creating a new annotation task (from CVAT home page, click 'Try it Now')
Click '+' icon  and then click on 'Create new task'
On the 'Create a new task' window, enter the name of the task and the labels.
In the 'Select File' section, Select the zip file containing the point clouds to be annotated (I tried with the individual files as well). I am trying to upload the files stored on my computer.
Click 'Submit and open'.

Expected Behavior
The task should be created.
However, it shows the following error in case of the zip file:
cvat-ui.458741b2860df2418acd.min.js:2 Error: Could not create task. Data processing failed. Traceback (most recent call last):   File "/opt/venv/lib/python3.10/site-packages/rq/worker.py", line 1428, in perform_job     rv = job.perform()   File "/opt/venv/lib/python3.10/site-packages/rq/job.py", line 1278, in perform     self._result = self._execute()   File "/opt/venv/lib/python3.10/site-packages/rq/job.py", line 1315, in _execute     result = self.func(*self.args, **self.kwargs)   File "/usr/lib/python3.10/contextlib.py", line 79, in inner     return func(*args, **kwds)   File "/home/django/cvat/apps/engine/task.py", line 757, in _create_thread     extractor = MEDIA_TYPES[media_type]['extractor'](**details)   File "/home/django/cvat/apps/engine/media_extractors.py", line 333, in __init__     super().__init__(file_list,   File "/home/django/cvat/apps/engine/media_extractors.py", line 156, in __init__     raise Exception('No image found') Exception: No image found e @ cvat-ui.458741b2860df2418acd.min.js:2
If I try with the individual files. I get the following error:
cvat-ui.458741b2860df2418acd.min.js:2 Error: Could not create task. Data processing failed. Traceback (most recent call last):   File "/opt/venv/lib/python3.10/site-packages/rq/worker.py", line 1428, in perform_job     rv = job.perform()   File "/opt/venv/lib/python3.10/site-packages/rq/job.py", line 1278, in perform     self._result = self._execute()   File "/opt/venv/lib/python3.10/site-packages/rq/job.py", line 1315, in _execute     result = self.func(*self.args, **self.kwargs)   File "/usr/lib/python3.10/contextlib.py", line 79, in inner     return func(*args, **kwds)   File "/home/django/cvat/apps/engine/task.py", line 652, in _create_thread     media, task_mode = _validate_data(media, manifest_files)   File "/home/django/cvat/apps/engine/task.py", line 266, in _validate_data     raise ValueError('No media data found') ValueError: No media data found
Possible Solution
I am not sure. Is it because I am trying to upload point clouds? But I saw some YouTube videos showing that CVAT supports point cloud annotation as well. So, it should not be the reason.
Context
I am trying to use CVAT for annotation of point cloud files (in .xyz format) for deep learning tasks. I could not attach the .xyz file as it is not supported here.
Environment
I am using the Windows 10 operating system and trying to use CVAT online on the Google Chrome browser.

I figured it out. Thanks.


complexity-tests: add bpf_network configuration

cc @learnitall

/ci-verifier

/ci-verifier

/ci-verifier

/ci-verifier

/ci-verifier

Can't get the verifier log until https://github.com/cilium/cilium/pull/29752 is merged

/ci-verifier

Superseded by Ryan's PR.


License?

What license is the code released under?
I may be blind, but I can't it referenced anywhere.

Added one. Thanks for reminding me.


Does not correctly handle multiple "schemes" values

The OpenAPI spec allows for the schemes: property to be an array of strings, see https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#schema
If a Swagger file includes something like this
schemes:
  - https
  - http

the importer apparently ignores both values and shows this instead:

Thanks for the report, I'll look into it!

@lumaxis Found the bug, working on a fix right now (your two issues are linked and are part of a much wider issue)

I had a feeling this might be the case. Thanks for looking into it and working on a fix!

@JonathanMontane Should this already be fixed by 3.0.9? I noticed things changed a little but the current behavior is still a bit strange.
I think the schemes values now get imported using JSF enums but this is not very practical imo. The way it works now, the actually used protocol becomes random and unpredictable whereas I would love to have this become a globally changeable environment variable.
Same goes for the host: parameter btw. I would love to have a way to easily change the host used for all requests 😊
Thad said, thanks for the work you're doing on this! Great to see the progress and fixes. ❤

@lumaxis Sorry about that! The issue was internal to Paw and got fixed in Paw 3.0.9. However, what you are describing was also fixed in a joint release. Try updating your extensions, you should now have two additional options for the random generation on imports, specifically for the protocol and host (we were also annoyed by it). In theory, these two checkboxes should be disabled by default, so you won't have to do anything to fix this issue, apart from updating.
If you still encounter any other issue,  feel free to open up an issue or create a ticket with support!

Hah, you're indeed right :) When I had tried last night, the Swagger Importer update hadn't reached me yet, now it's looking exactly like you describe.


Stored properties cannot be marked unavailable with '@available'

Stored properties cannot be marked unavailable with '@available'

参考:

https://github.com/AAChartModel/AAChartKit/issues/1501


Does not work for non root domain name

As far as I'm able to tell, this only works if the app is deployed on a root domain. e.g. https://mydomain.tld
It does not work if it's deployed in a path such as https://mydomain.tld/myapp/

I'll look into it...

It's been a few days... But I just took a quick look and believe that it's probably because the scripts are not beeing loaded, as they point to /bundles. Could you confirm that, if you still have somewhere to test this?

I actually deployed it as root in the meantime. So I can't test it.


[Privacy/Security] Agent string and local system hostname in MessageID field of sent e-mails

I've noticed that on e-mails sent by nmail, the content of Message-ID field is:
Message-ID: <nmail.3.62.624368d7.2eb141f2.263@LocalSystemHostName>
Sending from the same account through other MUA,
Message-ID<EMAIL_ADDRESS>Privacy and security wise, I suggest to remove the content of this field and substitute it with something generalized or random. Or remove the field completely if possible. It leaks the MUA, its version and the local hostname of the system of the sender.
MUA string is not considered a problem and usually presented, but still it can be hidden as an option on most MUAs (it's an info for a possible attacker). But the local hostname should be removed.

Ok, will take a look at this. The current Message-ID was based, like a lot of other things, on the alpine email client.

Btw, short-term you can override sender hostname using the sender_hostname config parameter. The email client name and version will still be visible though.

I tried sender_hostname, it works fine. It's ok for me, you can close this if you like, leaving user agent as is. I'll change the text describing the issue but I think I cannot rename it.

I checked Thunderbird and it generates (as an example<EMAIL_ADDRESS>when sending from a gmail account. I think nmail could be changed to follow a similar format.

A fix for this has been implemented now in above commit, so nmail generates a uuid.
Take note that nmail still passes its hostname as part of smtp authentication, unless sender_hostname is configured. The mail service provider may choose to include this hostname in the email headers.

The option sender_hostname has been deprecated as of ba2a192 and instead a new option send_hostname has been added, to control whether to send client hostname in SMTP authentication (default enabled). One can disable it and then nmail behaves similarly to Thunderbird, sending [local ipaddress] (ex: [<IP_ADDRESS>] as hostname during SMTP authentication.
Message-id generation is unaffected and continous to use a uuid.

The option send_hostname has been deprecated and instead send_ip has been added (enabled by default). Enabling this by default is made possible by incorporating a custom version of the underlying libetpan library with improved support for smtp handshake using IP address (instead of hostname).


Internal Proxy Exceptions

Add this to the proxy exceptions so that we can use discord with cultivation.
https://*.discord.com;https://*.discordapp.net;https://discord.gg/*;https://*.discordapp.com;https://*.discordapp.net;https://*.discordapp.net;https://*.discord.media;https://*.discord.gift/*

I tried to search in registry after what store these values but weren't able to find it

From what i have found it should be in ProxyOverride but i couldn't find anyhting and when i create the value and add data to it then it just disable the whole proxy thing.
Source : https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-ie-clientnetworkprotocolimplementation


[SPARK-30066][SQL] Support columnar execution on interval types

What changes were proposed in this pull request?
Columnar execution support for interval types
Why are the changes needed?
support cache tables with interval columns
improve performance too
Does this PR introduce any user-facing change?

Yes cache table with accept interval columns
How was this patch tested?

add ut

cc  @cloud-fan @maropu, we may need  https://github.com/apache/spark/pull/26680 to be merged to make this forward here, thanks for reviewing

Test build #114561 has started for PR 26699 at commit 4728ba4.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19389/
Test PASSed.

Is the title Support cache for interval data?

Test build #114561 has finished for PR 26699 at commit 4728ba4.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/114561/
Test FAILed.

Is the title Support cache for interval data?

cache seems API-like to me, here we also use this cache for underly optimization

Test build #114790 has started for PR 26699 at commit 1365d5d.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19611/
Test PASSed.

Test build #114790 has finished for PR 26699 at commit 1365d5d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/114790/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19671/
Test PASSed.

Test build #114849 has started for PR 26699 at commit 96803a3.

Test build #114849 has finished for PR 26699 at commit 96803a3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/114849/
Test PASSed.

cc @cloud-fan  @maropu  again, ready for review, thanks for your help.

Test build #115017 has started for PR 26699 at commit 5f809b7.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19837/
Test PASSed.

Test build #115017 has finished for PR 26699 at commit 5f809b7.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/115017/
Test FAILed.

retest this please

Test build #115020 has started for PR 26699 at commit 5f809b7.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19840/
Test PASSed.

Test build #115020 has finished for PR 26699 at commit 5f809b7.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/115020/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19881/
Test PASSed.

Test build #115064 has started for PR 26699 at commit 49d8122.

Test build #115064 has finished for PR 26699 at commit 49d8122.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/115064/
Test PASSed.

Looks fine to me. cc @cloud-fan

Thanks for the check, @viirya

Retest this please.

Test build #115266 has started for PR 26699 at commit 49d8122.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/20074/
Test PASSed.

Test build #115266 has finished for PR 26699 at commit 49d8122.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/115266/
Test PASSed.

Thanks @dongjoon-hyun for bringing up jenkins.

Test build #115329 has started for PR 26699 at commit c5a7374.

Thanks very much for your comments @dongjoon-hyun

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/20136/
Test PASSed.

Test build #115329 has finished for PR 26699 at commit c5a7374.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/115329/
Test PASSed.


Workflow queue

This PR implements a workflow queue for each competition to avoid a git conflict in the participants.txt file in case two competition workflows are running in parallel.
The run workflow of the competition template was updated to notify webots.cloud when the job is complete and the queue item can be released, and a new job can possibly start.

Thank you!


Unable to build bustools in Docker

Hi, I am making a Dockerfile to run Kallisto and BUStools on AWS. I've been testing it locally, and when building the image, Kallisto and its dependencies build fine, but for some reason BUStools exits out when building. Here is the dockerfile:
RUN apt-get update && apt-get install -y
build-essential
cmake
zlib1g-dev
autoconf
libhdf5-dev
git
python
RUN git clone https://github.com/pachterlab/kallisto.git
WORKDIR /kallisto
RUN mkdir build
WORKDIR /kallisto/build
RUN cmake .. && make && make install
RUN git clone https://github.com/BUStools/bustools.git
WORKDIR /bustools
RUN mkdir build
WORKDIR /bustools/build
RUN cmake .. && make && make install
And here is the error message received:
Step 10/14 : RUN git clone https://github.com/BUStools/bustools.git
---> Running in 999d92843bfe
Cloning into 'bustools'...
Removing intermediate container 999d92843bfe
---> af3edab1833e
Step 11/14 : WORKDIR /bustools
---> Running in cc4c8dee1555
Removing intermediate container cc4c8dee1555
---> 2328d6d20c0a
Step 12/14 : RUN mkdir build
---> Running in 70ded1b3cf3f
Removing intermediate container 70ded1b3cf3f
---> 29d2c462fc2d
Step 13/14 : WORKDIR /bustools/build
---> Running in 1cf7ae9f56ce
Removing intermediate container 1cf7ae9f56ce
---> 59ab53fec43b
Step 14/14 : RUN cmake .. && make && make install
---> Running in 00deb484376f
CMake Error: The source directory "/bustools" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
The command '/bin/sh -c cmake .. && make && make install' returned a non-zero code: 1
Do you have any idea why this could be happening? I tried to follow the installation instructions to the letter from the tutorial.

In the docker script
...
WORKDIR /kallisto/build
RUN cmake .. && make && make install
RUN git clone https://github.com/BUStools/bustools.git
WORKDIR /bustools
RUN mkdir build
WORKDIR /bustools/build
RUN cmake .. && make && make install

It seems that you would git clone bustools into /kallisto/build/. Although I'm not too familiar with docker.
I think a WORKDIR / in between the steps might fix it

Following up on this, I see that Pall's suggestion to @jamesrhowe worked for me. However, I am encountering an apparent error during cmake for bustools:
Step 18/27 : RUN cmake .. && make && make install
 ---> Running in c2fc77eb3a50
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
release mode
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /bustools/build
Scanning dependencies of target bustools_core
[  7%] Building CXX object src/CMakeFiles/bustools_core.dir/BUSData.cpp.o
[ 15%] Building CXX object src/CMakeFiles/bustools_core.dir/Common.cpp.o
[ 23%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_capture.cpp.o
[ 30%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_count.cpp.o
[ 38%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_inspect.cpp.o
[ 46%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_linker.cpp.o
[ 53%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_main.cpp.o
[ 61%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_project.cpp.o
[ 69%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_sort.cpp.o
[ 76%] Building CXX object src/CMakeFiles/bustools_core.dir/bustools_whitelist.cpp.o
/bustools/src/bustools_whitelist.cpp: In function ‘void bustools_whitelist(Bustools_opt&)’:
/bustools/src/bustools_whitelist.cpp:111:58: error: ‘pow’ was not declared in this scope
     threshold = avgCount * (1 - pow(1 - ERROR_RATE, bclen));
                                                          ^
src/CMakeFiles/bustools_core.dir/build.make:278: recipe for target 'src/CMakeFiles/bustools_core.dir/bustools_whitelist.cpp.o' failed
make[2]: *** [src/CMakeFiles/bustools_core.dir/bustools_whitelist.cpp.o] Error 1
CMakeFiles/Makefile2:87: recipe for target 'src/CMakeFiles/bustools_core.dir/all' failed
make[1]: *** [src/CMakeFiles/bustools_core.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
The command '/bin/sh -c cmake .. && make && make install' returned a non-zero code: 2

Any recommendations here? By way of background, I'm using the git install approach because I'd like to use some of the features in 39.3, which does not appear to be available in conda. If there's a better solution there I'd be obliged to know about it.

function pow is defined in math.h, just add  #include <math.h> somewhere in the header of bustools_whitelist.cpp

Why hasn't the source code been updated to include that in the header?

This has been fixed in the latest release


Fixed redact_event function call in room.py and fixed arguments.

This PR is to fix redact_message in room.py calling the incorrect function name for redact_event.
I also made it so redact_event takes a content dict instead of a reason string, because redact_message was already passing a content dict.

Hi @rrigby thanks so much for catching this and for the fix. Given that
reason is the only json key defined by the spec for this endpoint, I
think we should keep "reason" as an arg rather than an ambiguous "content"
arg where it's less clear what the contents of "content" should be.
I'll also need a sign-off from you per CONTRIBUTING.rst
Thanks!

I've made the requested changes so that the function takes a reason string instead of a content dict.

Sorry, just saw you edited the sign-off into your top-level comment. Fix the nit on documentation, and we'll be good. Thanks!

After checking current functionality in riot when redacting a message I decided on leaving in the if guard.
By default riot returns "content": {} when viewing source, likewise with the if guard.
Without the if guard I see  this when viewing source.
"content": {
    "reason": null
}

For the sake of consistency I left it in, it also looked cleaner in my opinion and matched the "content": {} on the parent object.


Allow specifying multiple page types in PageChooserPanel

Currently when adding links to pages it is possible to link to every page on the site. It would be great if the page links could be limited according to specified page types.

Autodetecting page type from the ForeignKey is being addressed in #509. Will keep this ticket open for the other request, allowing multiple types to be specified. (I'm not 100% sure if the superclass approach works - in particular I suspect it might fail on abstract base classes, because we're using ContentTypes, and I don't think abstract classes have those. Either way, we can still improve things by having it accept an arbitrary list of page types.)

Would be nice to have this feature.
I have different article types and from the section the admin can feature an article.

This affects me as well, I was trying to create a PageChooserPanel that filters by two page types. It would by useful if you could pass a list of page types to filter with.

Final version of this feature was merged in #1621.


ReSwift 2.0.0 Release

Bumping version number to 2.0.0 for next release. Also adding relevant changelog entries.

[Current coverage][cc-pull] is 100%

Merging [#125][cc-pull] into [master][cc-base-branch] will not change coverage

@@           master   #125   diff @@
====================================
  Files           6      6
  Lines         107    109     +2
  Methods         0      0
  Messages        0      0
  Branches        0      0
====================================
+ Hits          107    109     +2
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last updated by [6371e98...bf9c2bd][cc-compare]
[cc-base-branch]: https://codecov.io/gh/ReSwift/ReSwift/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/ReSwift/ReSwift/compare/6371e9817d9e7d0c11e178753d1f185ac881ba9d...bf9c2bdde354dfd592f02afd8ed61722e0d6ddc5
[cc-pull]: https://codecov.io/gh/ReSwift/ReSwift/pull/125?src=pr

Note on the code change as part of this Release:
I decided to make on change to StandardAction which handles the serialization of nil payload values. A nil payload is now simply represented by a string constant defined by ReSwift. Technically we should be using NSNull but since ReSwift has no other Foundation dependencies I think we should avoid adding it.
In the end the serialization/deserialization of nil payloads is entirely owned by the library itself so it doesn't really matter how we represent them.


null guard not working correctly

I am getting the following error:
157:             } else if (this.state.row.name.toLowerCase() == q.toLowerCase()) {
                                           ^^^^ property `name`. Property cannot be accessed on possibly null value
157:             } else if (this.state.row.name.toLowerCase() == q.toLowerCase()) {
                            ^^^^^^^^^^^^^^ null

But from what I can tell this.state.row will never be null on 157 because I am checking for that.
if (this.state.row == null) {
    console.log("onBlur condition 1a: getByName");
    this.getByName(q);
}
else if (this.state.row.name.toLowerCase() != q.toLowerCase()) {
    console.log("onBlur condition 1b: getByName");
    this.getByName(q);
} else if (this.state.row.name.toLowerCase() == q.toLowerCase()) {
    console.log("onBlur condition 1c: no action required");
}
else {
    throw new Error("IllegalState");
}

Try
const row = this.state.row;
<Your code, but with s/this.state.row/row/>

Calling functions invalidates refinements of non-locals. Flow is worried that the toLowerCase() calls in the first else if might set this.state.row back to null, so the second else if errors.
Check out https://flowtype.org/docs/dynamic-type-tests.html#caveats

It won't help you more than gabelevi helped but I noticed that you're type checking this.state.row for a null value, however you aren't checking this.state.row.name before call .toLowerCase() and name maybe null.


distsql: support lookup join on secondary index

PR: https://github.com/cockroachdb/cockroach/pull/25628
From release notes:

The experimental lookup join feature now supports secondary indexes. [#25628][#25628] {% comment %}doc{% endcomment %}

Covered by https://github.com/cockroachdb/docs/issues/3153.


Settings: Updates Headings to Titlecase

Currently the headings of the settings option and the Settings in Obsidian are mixed case; some are titlecase and some are first letter capitalised of sentence. This makes them titlecase for uniformity. This will close #7

Hello, @sigrunixia, thanks for helping out ❤


Some unnatural Korean translations

Problems
There are somewhat unnatural Korean translations at the bottom of the LNB.
Solution
(Kor.) 사용 가이드 : 다운로드 / 온라인
(Eng.) User guide : Download / Online
(Kor.) 연락처
(Eng.) Contact
Expected behavior
People using Korean should not have any objection to using the service in Korean.
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
#1977

@deidera08 @AnnieHwang
Someone said 'contact' was awkward. Do you have any better ideas?

@minjung-cho How about '문의'?


Require TRANSPORT_LE for connectGatt().

Hi!
I did not get flutter_blue to connect to a BLE device due to error/status 133 received upon onClientConnectionState() in BluetoothGatt. I then realized, that I previously had the same issue when working on a "classical" Android project back a while. Fixing the issue back then took quite some research, however the problem is described here: https://stackoverflow.com/questions/25330938/android-bluetoothgatt-status-133-register-callback#25364567
This pull request adds the same fix to flutter_blue and has been successfully tested to resolve the issue in connecting to my BLE device. It was tested on a Nexus 5X running Android 8.1.0. I'm happy to help with more details if required.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I cannot legally sign this CLA thing, however I do not assume that this is really required for changing a single line of code and adding a parameter to a function call. If that's the only thing which hinders discussion of this issue, please come back to me and I may have to recheck with my legal department...

@pauldemarco Did you have time to look into this PR already - or is it ignored due to te CLA issue?

Closing, duplicate of #229 ...


[#22] [Android] [Integrate] As a user, I can see the log in screen

Close #22

What happened 👀

Validate email and password (email must has a correct format, password must be filled).
Call the login endpoint which was done in https://github.com/nimblehq/avishek-phong-kmm-ic/issues/7 when user tap on Log in button.
Save the retrieved cridentials for later use.

Insight 📝

Used the LoginViewModel in branch feature/#21-#7-integrate-and-backend-for-log-in-screen to validate email and password, execute the use case, etc.
Updated the text field to show a red border when there is a validation error.
The standard coroutine scope in the Android ViewModel is viewModelScope, which is automatically canceled when the VM is cleared. But this causes the VM unit tests in :commonTest to fail. Tried several ways to fix that, e.g., passing UnconfinedTestDispatcher in Dispatchers.setMain(), runTest(UnconfinedTestDispatcher) {}, etc. but nothing worked. So MainScope is used in the VM which is cancelled manually in onCleared callback method.
The test when logging in successfully, it navigates to the Home screen is failing due to the error below:

I could not find any solution to fix this. The test is commented out until a fix is found. Ideas are welcome.

Proof Of Work 📹
https://user-images.githubusercontent.com/8093908/237049084-217f2f71-88cf-4eba-b375-3224e4237e87.mp4

@AVI5HEK Just need some more padding for AlertDialog box as we discussed. The rest LGTM.

@kaungkhantsoe I haven't found any quick fix. I will improve it once I'm done with the higher-priority tasks. 🙏🏽


after upload a song, the song didn`t play

after upload a song, the song didn`t play. after refresh with Iris scan folders, the song played.

Sep  1 23:37:27 raspberrypi mopidy[25929]: INFO     [MpdSession-2623] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40934
Sep  1 23:37:27 raspberrypi mopidy[25929]: INFO     [MpdSession-2624] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40938
Sep  1 23:37:27 raspberrypi mopidy[25929]: INFO     [MpdSession-2625] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40942
Sep  1 23:37:27 raspberrypi mopidy[25929]: INFO     [MpdSession-2626] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40946
Sep  1 23:37:27 raspberrypi mopidy[25929]: INFO     [MpdSession-2627] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40950
Sep  1 23:37:27 raspberrypi mopidy[25929]: INFO     [MpdSession-2628] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40954
Sep  1 23:37:44 raspberrypi lighttpd[6366]: chown: changing ownership of '/home/pi/RPi-Jukebox-RFID/shared/audiofolders/3Band': Operation not permitted
Sep  1 23:37:44 raspberrypi lighttpd[6366]: chown: changing ownership of '/home/pi/RPi-Jukebox-RFID/shared/audiofolders/3Band/Band Of Horses - No One'''s Gonna Love Y$
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2629] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40958
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2630] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40962
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2631] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40966
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2632] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40970
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2633] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40974
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2634] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40978
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2635] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40982
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2636] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40986
Sep  1 23:37:52 raspberrypi mopidy[25929]: INFO     [MpdSession-2637] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40990
Sep  1 23:37:56 raspberrypi lighttpd[6366]: /home/pi/RPi-Jukebox-RFID/scripts/inc.writeFolderConfig.sh: line 106: /home/pi/RPi-Jukebox-RFID/shared/audiofolders/3Band/f$
Sep  1 23:37:56 raspberrypi lighttpd[6366]: rm: cannot remove '/home/pi/RPi-Jukebox-RFID/shared/audiofolders/3Band/folder.conf': No such file or directory
Sep  1 23:37:57 raspberrypi mopidy[25929]: INFO     [MpdSession-2638] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40994
Sep  1 23:37:57 raspberrypi mopidy[25929]: INFO     [MpdSession-2639] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:40998
Sep  1 23:37:57 raspberrypi mopidy[25929]: INFO     [MpdSession-2640] mopidy_mpd.session New MPD connection from [::ffff:<IP_ADDRESS>]:41002

Any Ideas, what can I do?

So does it play after the scan folders? That’s intended, the database needs to be refreshed after uploading new files.

Yes, after the manual scan, play the songs again, not before. Normal white it was automatically updated after uploading. Is  something wrong at permission and which file ?


LinearGradient component

I recently came across this beautiful landing page from auth0: https://auth0.design/
It included these cool gradients:

Which reminded me of this webflow theme I used for the doorman.cool website:

It would be cool to have a LinearGradient component in Dripsy, which re-exports Expo's.
import { LinearGradient } from '@dripsy/gradient'

// theme colors
<LinearGradient colors={['primary', 'accent']} />

Maybe you could even have gradients in your theme.
const theme = {
  linearGradients: {
    strong: ['primary', 'secondary']
  }
}

<LinearGradient variant="strong" />

The variant prop might not be the right one to use here, since we're technically not applying a set of styles, but rather we're using an opinionated mapping of colors -> props.
This might be more appropriate:
const theme = {
  linearGradients: {
    strong: ['primary', 'secondary']
  }
}

<LinearGradient gradient="strong" />

This is super cool. It'd be instantly useful for me, I'm currently using a dripsy + expo-linear-gradient combo myself.
Mind if I take a crack at this? I can also add in a re-exported Pressable component while I'm at it.

Definitely, go for it.
This is what I'm using in my app now:
import React from 'react'
import { LinearGradient } from 'expo-linear-gradient'
import { styled, useDripsyTheme } from 'dripsy'
type Props = React.ComponentProps<typeof LinearGradient>

const Grad = styled(
  React.memo(
    function Gradient(props: Props) {
      const { colors } = useDripsyTheme().theme
      return (
        <LinearGradient
          {...props}
          colors={props.colors?.map(
            (color) => (colors?.[color] as string) ?? color
          )}
        />
      )
    },
    (prev, next) => JSON.stringify(prev) === JSON.stringify(next)
  )
)({})

export default function Gradient(props: React.ComponentProps<typeof Grad>) {
  return <Grad {...props} />
}

The memoizing might not be necessary, but I noticed flickers on web when I didn't do it. Might be better for people to do that in their own apps if they want it and to document it.
Since we're adding a dependency, I think it would be good to make this a @dripsy/gradient package. It might also mean we should move styled etc to a @drispy/core package, the way I did for moti.

I've had issues with wrapping Pressable. Its TS types don't lend themselves well to HOCs, so I think we're best off making our own component for it. I think I linked to mine in another issue, but this is it for context:
import React, { ReactNode, ComponentProps } from 'react'
import { styled } from 'dripsy'
import {
  Pressable as NativePressable,
  PressableStateCallbackType,
  ViewStyle,
} from 'react-native'

// react-native-web/overrides.ts
declare module 'react-native' {
  interface PressableStateCallbackType {
    hovered?: boolean
    focused?: boolean
  }
  interface ViewStyle {
    transitionProperty?: string
    transitionDuration?: string
  }
  interface TextProps {
    accessibilityComponentType?: never
    accessibilityTraits?: never
  }
}

type CallbackWithHovered = PressableStateCallbackType
const StyledPressable = styled(NativePressable)({})

type Props = {
  style?: ((prop: CallbackWithHovered) => ViewStyle) | ViewStyle
  children?: ReactNode | ((prop: CallbackWithHovered) => ReactNode)
} & Omit<ComponentProps<typeof StyledPressable>, 'children' | 'style'>

const Press = React.forwardRef(function Pressable(
  { sx = {}, disabled, ...props }: Props,
  ref: ComponentProps<typeof NativePressable>['ref']
) {
  return (
    <StyledPressable
      {...props}
      ref={ref as any}
      disabled={disabled}
      sx={{
        cursor:
          props.onPress || props.accessibilityRole === 'link' || !disabled
            ? 'pointer'
            : 'default',
        ...sx,
      }}
    />
  )
})

export default Press

Should probably add a Platform.select for the cursor style, such that we only show it on web.

Since we're adding a dependency, I think it would be good to make this a @dripsy/gradient package. It might also mean we should move styled etc to a @drispy/core package, the way I did for moti.

Got it.

Alright, I'll try to make your code the basis for the pressable component and check out that other issue. We can always tweak as we go.

One last thing, which is unrelated but I'm seeing on the Pressable code. Our current types for the ref prop in createThemedComponent are wrong. I'm forced to pass as any whenever I pass a ref down.

How do you think we should start breaking up the main dripsy package into smaller packages? I think that's the first PR I'm going to handle so that it's a little more flexible.
Do you think we should take the current dripsy package and move all of that into @dripsy/core or break that out further? Into something like @dripsy/css, @dripsy/utils, etc.

Do you think the gradient prop should replace the color prop entirely? I don't know what the best move would be here is, Otherwise, either the gradient or the colors object needs to take precedence, if we choose this way I think the colors prop should probably take precedence.
So it could be used like:
const theme = {
  linearGradients: {
    strong: ['primary', 'secondary']
  }
}

<LinearGradient gradient="strong" />
// or
<LinearGradient gradient={['primary', 'secondary']} />

Let me know what you think.

Similar to what you said, here's what I think makes sense:
const theme = {
  linearGradients: {
    strong: ['primary', 'secondary']
  }
}

// these are equivalent
<LinearGradient gradient="strong" />
<LinearGradient colors={['primary', 'secondary']} />

// colors prop takes precedence
<LinearGradient gradient="strong"  colors={['accent', 'highlight']}  />

Got it. That's how I'm currently handling it.
I have this just about done along with another branch for the pressable component if we can get #74 merged in.


Adjust module / series listing typography & spacing

[x] Make cursor pointer
[x] Adjust series title and module titles font weight to 400
[x] Adjust second line of series info: font-size: 14px, opacity: 0.8 (we should work towards the design on the whiteboard)
[x] Adjust padding for series to: 12px 5px 12px 20px
[x] Adjust series margin to 40px (so that 20px padding will bring it to the same 60px indent but with 20 px padding)
[x] Adjust padding for modules to: 15px 5px 10px 0
[x] Adjust border colour between series to #127077, but leave border between modules on black
[x] Adjust :hover state of list items to #277A81

See below for specific look:

Coverage remained the same at 100.0% when pulling df0934ca3d3d80638d04f2b1c84c7da1ca54028c on bp323:issue-218 into 613d6e92e5954b3461c2692ceac264e3805fe0be on CUL-DigitalServices:master.


Allow predefined core allocation

Sometimes it useful to have a predefined core allocation. This pull request adds such functionality.

This has since been implemented with support for multiple groups. See "main_stream_layer_splitting.py" for an example


Linux wallet consumes CPU when it should be idle

Hi, after updating the wallet to v<IP_ADDRESS> I observe continuous CPU usage of about 20-30% of a single CPU core. Earlier it was ~1%. The CPU usage doesn't seem to be related to any actions such as GUI operations, staking, etc. It is pretty linear - after half an hour from launching the wallet, the CPU time for its process is 10.5min, after 21 hours the CPU time is 6.5h.
I'm using a package from Marix repository on fedora 23.

As a baseline, how much CPU is litecoin using on Linux-QT?

Can anyone else confirm the figure Bzaborow states matches their personal experience?

Update - I've build and measured older versions and there is a very small difference. So it may be a regression in my system or something like this. My bad. Anyway I'll do some tests on other systems.

OK, I've done my homework. the problem is not releated to any of the last versions, it just became visible for me. I've found that the thread which consumes CPU power is the staking thread. The loop in this thread sleeps 0.5s (default for minersleep) every turn, but also computes intesively for ~0.15s (in my case).
The particularly costly line of the staking thread code is a call to
CBlock* CreateNewBlock(CWallet* pwallet, bool fProofOfStake, int64_t* pFees).
But this function, despite being quite complex also has a single most costly line: a call to
StructCPID GetLifetimeCPID(std::string cpid, std::string sCalledFrom).
And here we have a problem. The GetLifetimeCPID goes in a loop through all the blocks staked so far by this wallet. It is expensive, as it takes about 0.5-1ms to process each block. In my case some 300 blocks take 0.15s on a pretty fast CPU (intel i7 3.9GHz), so the problem will be more visilbe for people with higher number of blocks or weaker CPU.
The main question is: do we need to perform this loop through past blocks every staking attempt? For me this could (and should!) be cached and computed only when it changes - after staking a block or after finding an orphan. Or even once per getting new block from a network, but not twice a second!

@bzaborow You make a good point regarding possible efficiencies that could be made within the staking mechanism. If it was already computed prior to attempting to stake then staking would be less compute intensive.

I think #158 closes this one.

Yep, it does. Great work!


for:each

[ ] Choose a filter

[BW vibe](BW Vibe)
Bubblegum
sepia filter
cyber punk

[ ] Design idle mode
[ ] Design end screen

[ ] include both the original and the transformed image
[ ] some code?

[ ] Design the for:each booth

[ ] material to project the image
[ ] material to project the code
[ ] layout of image and code
[ ] light atmosphere
[ ] background for the image
[ ] text and images inside and outside the booth


UI crash on displaying Container Volumes in a Grid

When you try to display container volumes in a grid by clicking on the relevant icon:

The UI crashes with:

[----] F, [2016-05-10T12:52:14.456327 #8169:14f1ec8] FATAL -- : Error caught: [NoMethodError] undefined method `base_class' for NilClass:Class
/home/simon/src/manageiq/app/views/layouts/quadicon/_single_quad.html.haml:56:in `_app_views_layouts_quadicon__single_quad_html_haml__205715719587989182_70006022173100'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:158:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:166:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:348:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:156:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:343:in `render_partial'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:311:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:42:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:41:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:310:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:47:in `render_partial'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:21:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/helpers/rendering_helper.rb:32:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/haml-4.0.7/lib/haml/helpers/action_view_mods.rb:12:in `render_with_haml'
/home/simon/src/manageiq/app/helpers/quadicon_helper.rb:35:in `block in render_quadicon'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/helpers/capture_helper.rb:39:in `block in capture'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/helpers/capture_helper.rb:203:in `with_output_buffer'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/haml-4.0.7/lib/haml/helpers/action_view_xss_mods.rb:5:in `with_output_buffer_with_haml_xss'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/helpers/capture_helper.rb:39:in `capture'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/haml-4.0.7/lib/haml/helpers/action_view_mods.rb:52:in `capture_with_haml'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/helpers/tag_helper.rb:107:in `content_tag'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/haml-4.0.7/lib/haml/helpers/action_view_mods.rb:61:in `content_tag_with_haml'
/home/simon/src/manageiq/app/helpers/quadicon_helper.rb:25:in `render_quadicon'
/home/simon/src/manageiq/app/views/layouts/gtl/_grid.html.haml:20:in `block in _app_views_layouts_gtl__grid_html_haml___3814180850048275033_70007623733640'
/home/simon/src/manageiq/app/views/layouts/gtl/_grid.html.haml:4:in `each'
/home/simon/src/manageiq/app/views/layouts/gtl/_grid.html.haml:4:in `_app_views_layouts_gtl__grid_html_haml___3814180850048275033_70007623733640'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:158:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:166:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:348:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:156:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:343:in `render_partial'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:311:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:42:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:41:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:310:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:47:in `render_partial'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:21:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/helpers/rendering_helper.rb:32:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/haml-4.0.7/lib/haml/helpers/action_view_mods.rb:12:in `render_with_haml'
/home/simon/src/manageiq/app/views/layouts/_gtl.html.haml:25:in `_app_views_layouts__gtl_html_haml__3905847717351289664_70007600434180'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:158:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:166:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:348:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:156:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:343:in `render_partial'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:311:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:42:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:41:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/partial_renderer.rb:310:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:47:in `render_partial'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:21:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/helpers/rendering_helper.rb:32:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/haml-4.0.7/lib/haml/helpers/action_view_mods.rb:12:in `render_with_haml'
/home/simon/src/manageiq/app/views/persistent_volume/show_list.html.haml:2:in `_app_views_persistent_volume_show_list_html_haml___4093351536214215861_70007624237000'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:158:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:166:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:348:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/template.rb:156:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/template_renderer.rb:54:in `block (2 levels) in render_template'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:42:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/abstract_renderer.rb:41:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/template_renderer.rb:53:in `block in render_template'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/template_renderer.rb:61:in `render_with_layout'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/template_renderer.rb:52:in `render_template'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/template_renderer.rb:14:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:42:in `render_template'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/renderer/renderer.rb:23:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/rendering.rb:103:in `_render_template'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/streaming.rb:217:in `_render_template'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/rendering.rb:83:in `render_to_body'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/rendering.rb:52:in `render_to_body'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/renderers.rb:144:in `render_to_body'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/abstract_controller/rendering.rb:26:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/rendering.rb:36:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/instrumentation.rb:44:in `block (2 levels) in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/core_ext/benchmark.rb:12:in `block in ms'
/home/simon/src/rvm/rubies/ruby-2.2.4/lib/ruby/2.2.0/benchmark.rb:303:in `realtime'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/core_ext/benchmark.rb:12:in `ms'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/instrumentation.rb:44:in `block in render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/instrumentation.rb:87:in `cleanup_view_runtime'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activerecord/lib/active_record/railties/controller_runtime.rb:25:in `cleanup_view_runtime'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/instrumentation.rb:43:in `render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/implicit_render.rb:36:in `default_render'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/basic_implicit_render.rb:4:in `block in send_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/basic_implicit_render.rb:4:in `tap'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/basic_implicit_render.rb:4:in `send_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/abstract_controller/base.rb:181:in `process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/rendering.rb:30:in `process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:126:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:126:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:506:in `block (2 levels) in compile'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:455:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:455:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:101:in `__run_callbacks__'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:750:in `_run_process_action_callbacks'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:90:in `run_callbacks'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/abstract_controller/callbacks.rb:19:in `process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/rescue.rb:31:in `process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `block in instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/notifications.rb:164:in `instrument'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/instrumentation.rb:30:in `process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal/params_wrapper.rb:248:in `process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activerecord/lib/active_record/railties/controller_runtime.rb:18:in `process_action'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/abstract_controller/base.rb:126:in `process'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/rendering.rb:30:in `process'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal.rb:190:in `dispatch'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_controller/metal.rb:262:in `dispatch'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/routing/route_set.rb:50:in `dispatch'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/routing/route_set.rb:32:in `serve'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/journey/router.rb:39:in `block in serve'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/journey/router.rb:26:in `each'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/journey/router.rb:26:in `serve'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/routing/route_set.rb:725:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/omniauth-1.3.1/lib/omniauth/strategy.rb:186:in `call!'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/omniauth-1.3.1/lib/omniauth/strategy.rb:164:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/omniauth-1.3.1/lib/omniauth/builder.rb:63:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/secure_headers-3.0.3/lib/secure_headers/middleware.rb:10:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionview/lib/action_view/digestor.rb:12:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/etag.rb:25:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/conditional_get.rb:25:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/head.rb:12:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/session/abstract/id.rb:220:in `context'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/session/abstract/id.rb:214:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/cookies.rb:613:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/callbacks.rb:38:in `block in call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:97:in `__run_callbacks__'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:750:in `_run_call_callbacks'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/callbacks.rb:90:in `run_callbacks'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/callbacks.rb:36:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/executor.rb:12:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/remote_ip.rb:79:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/debug_exceptions.rb:49:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/show_exceptions.rb:31:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/railties/lib/rails/rack/logger.rb:36:in `call_app'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/railties/lib/rails/rack/logger.rb:26:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/request_store-1.3.1/lib/request_store/middleware.rb:9:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/request_id.rb:24:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/method_override.rb:22:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/runtime.rb:22:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/activesupport/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/executor.rb:12:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/actionpack/lib/action_dispatch/middleware/static.rb:136:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/rack-2.0.0.alpha/lib/rack/sendfile.rb:111:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/bundler/gems/rails-254f57ca3668/railties/lib/rails/engine.rb:522:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/puma-3.3.0/lib/puma/configuration.rb:224:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/puma-3.3.0/lib/puma/server.rb:561:in `handle_request'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/puma-3.3.0/lib/puma/server.rb:406:in `process_client'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/puma-3.3.0/lib/puma/server.rb:271:in `block in run'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/puma-3.3.0/lib/puma/thread_pool.rb:111:in `call'
/home/simon/src/rvm/gems/ruby-2.2.4/gems/puma-3.3.0/lib/puma/thread_pool.rb:111:in `block in spawn_thread'

cc @zakiva

@miq-bot add_label containers/providers, bug

@miq-bot add_label providers/containers

@miq-bot assign zakiva


RuntimeError

Hello，I run the code and got Error RuntimeError: Given input size: (50x1x28). Calculated output size: (50x1x0). Output size is too small. And I think it may be a problem with torch and torchvision version. Could you please tell me what torch and torchvision version do you use in this project? Thanks.

Hello，I run the code and got Error RuntimeError: Given input size: (50x1x28). Calculated output size: (50x1x0). Output size is too small. And I think it may be a problem with torch and torchvision version. Could you please tell me what torch and torchvision version do you use in this project? Thanks.

Hello， I got the same problem, have you solved this?

models.py
class CNNCharEmb(nn.Module):
def forward(self, input):

list_pooled.append(F.max_pool1d(conved,kernel_size=conved.shape[1]).squeeze(2))

change to:
kernel_size = min(conved.shape[1], conved.shape[2])
list_pooled.append(F.max_pool1d(conved, kernel_size=kernel_size).squeeze(2))


[Cognitive Services] Track 1, Update to RP version 2022-12-01

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

We still need track 1 SDK for PowerShell. we will update track 2 SDK in a separate PR.


Allow the developer to set the initially selected tab using selected attribute on vaadin-tab

To make it easier to have a certain tab pre-selected.
<vaadin-tabs>
  <vaadin-tab>Tab one</vaadin-tab>
  <vaadin-tab selected>Tab two</vaadin-tab>
</vaadin-tabs>

he can do with <vaadin-tabs selected=2> which is the same api than paper and it's easy to bound. Or do you suggest to have both ways and maintain two api's

Yeah, I was asking if we could/should support two APIs. This suggestion came from @stramel, actually.
I do see there could be potential issues having two APIs doing basically the same thing. So there are at least these edge cases, where it’s not obvious what should happen:
<vaadin-tabs selected="0">
  <vaadin-tab>Tab one</vaadin-tab>
  <vaadin-tab selected>Tab two</vaadin-tab>
</vaadin-tabs>

<vaadin-tabs>
  <vaadin-tab selected>Tab one</vaadin-tab>
  <vaadin-tab selected>Tab two</vaadin-tab>
</vaadin-tabs>

I took a deeper look at the code. Seems like you guys implement the same public API as paper-tabs which would allow for attr-for-selected. I think that was what I was really looking for.
<vaadin-tabs selected="foo" attr-for-selected="name">
  <vaadin-tab name="baz">Tab Baz</vaadin-tab>
  <vaadin-tab name="bar">Tab Bar</vaadin-tab>
  <vaadin-tab name="foo">Tab Foo</vaadin-tab>
</vaadin-tabs>

I also noticed you guys are applying the selected attribute which again aligns with what paper-tabs does.
I do however think it is intriguing to be able to set the initially selected tab with a selected attribute.

There are two features here, I might agree with the attr-for-selected, but should be discussed/tracked in a different thread.
I'm still not convinced about the selected attr in items, which makes a complicated API. We need to document a lot of edge cases that might confuse the user. For instance what would expect the user in these cases?
<vaadin-tabs selected="2">
  <vaadin-tab selected>Tab 0</vaadin-tab>
  <vaadin-tab selected>Tab 1</vaadin-tab>
  <vaadin-tab>Tab 2</vaadin-tab>
</vaadin-tabs>

<vaadin-tabs selected="{{selected}}">
  <vaadin-tab selected>Tab 0</vaadin-tab>
  <vaadin-tab selected$=[[_isFooSelected()]]>Foo</vaadin-tab>
  <vaadin-tab>Tab 2</vaadin-tab>
</vaadin-tabs>

For sure that each reader could have a different solution, hence we need to clearly explain what will happen when the developer mixes different ways of selecting/binding. That is imho a anti-pattern of fight for simplicity ;-)


[Feature] Ability to typeof imports

Suggestion
Expand the (very nice) ability to infer the type of an import() call expression so that such imports can be wrapped.
🔍 Search Terms
typeof import
✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
Make it possible to expose the type of what a module exports:
function loadModule<T extends string>(modulePath: T): Promise<typeof import(T)>;

📃 Motivating Example
Library code that allows plugins, lazy-loading, etc. needs the user code to perform the import call itself in order to get typing information.
const plugin = await loadPlugin('@project/x/y', 'exportedFunction');

Without the feature, anything can be used instead of exportedFunction, but with the feature it would be possible to restrict the name and type the result:
function loadPlugin<
  ModuleName extends string,
  ExportName extends keyof typeof import(ModuleName)
>(
  moduleName: ModuleName,
  exportName: ExportName
): Promise<Plugin<typeof import(ModuleName)[ExportName]>>;

That's a fairly simple example, but it becomes more interesting when passing functions that would receive those exported objects as their parameters, etc.
💻 Use Cases
Usage:

plugin mechanisms
lazy-loading features
build-time DSLs

Short-comings with the current approach:

nothing but import() can be used while keeping type information

Short-comings with the proposed approach:

tooling may sometimes need to be adapted to "detect" such new import constructs

Workarounds:

not many are available apart from importing the type/re-declaring separately

Seems like a duplicate of #26139 and a duplicate of #41550.

Seems like a duplicate of #26139 and a duplicate of #41550.

Hm true, and a little bit #31090 as well
I suppose it's not worth keeping this one opened then, and instead I can go thumb-up the other ones or something 😅

Hm true, and a little bit #31090 as well
I suppose it's not worth keeping this one opened then, and instead I can go thumb-up the other ones or something 😅


Add version info

Adds a version number in the lower left corner for #424

I'm going to take it on faith that this works, as testing it isn't the easiest..


Add conditional styles for different active states of the navigation items / Look at styling of the aria

What
Add conditional styles for different active states of the navigation items. We have the option for users to remove the link from an individual navigation item when it is active.
There are two active states that we need to consider:

An active state of a navigation item with sub navigation, where the page displayed to the user is determined by the sub navigation selection.
An active state of a navigation item without sub navigation or on a homepage before a sub navigation is selected (For example, https://design-system.service.gov.uk/components/ in the GOV.UK Design System).

Setting aria-current specifically doesn't change the visuals of anything.

Setting the current or active Nunjucks parameters adds a class that adds the blue bottom border. We could make those look different by making each one add a different class.

Why
The working group raised that they would like to see more visual distinction between the 'active' nav item and the other nav items.
They also mentioned that the nav item shouldn't be a link if active, we have already addressed this with current or active Nunjucks parameters.
Done when

[ ] Existing styles for the parameters are observed
[ ] Alternate styles are suggested and tested
[ ] A decision is made on whether we introduce new styles
[ ] Content on how the component when 'active' can be reconfigured to remove the link (add additional styles) is added to the component guidance

Technically, there is a matrix of different parameters.

When an item is highlighted, is it highlighted because that is the page your are on ("current") or under ("active")?

This is where we add the aria-current attribute and change its value accordingly ("page" vs "true").
There doesn't need to be a sub navigation for the item to be under the page, but could be.

Is it a link or not?

It's considered best practice to not add links when you are on the page. Although in practice very few websites actually do that, including bbc.co.uk and w3.org.
This is currently a separate option in our code. Our breadcrumbs component combines those two parameters, i.e. when the item is not a link then it is also assumed to be the item for the current page you are on and sets the aria-current accordingly.

The core question is: Does any combination of the above need to look different from the other?

Current page which is a link
Active page which is a link
Current page which is not a link
Active page which is not a link

Number 1 and 2 currently look the same. If I understood the working group's comment correctly, this is what they suggested should look different.
Number 4 probably doesn't make any sense and could maybe be actively made impossible? (Not sure if it is currently possible.)

A design suggestion has been made to make the bottom border of an active navigation item black when the href is removed.

We have had to go forward and revert back on this one.
Initial decision
We made an initial decision to refactor the Navigation component so the active styles and text colour change could happen at the same code item level. Although we would not introduce new styles this change would make it easier to provide new styling to the active and link elements.
However, this had an impact on the focus states of the Navigation items and caused visual disruption on the page. This could make Navigation items harder to be understood as focused in different colour modes as well as being very overwhelming visually in default.
Example of a focused navigation item after refactoring

Example of a focused and active navigation item after refactoring

Reverted decision
We reverted the decision based on what we learned about the change in focus state.
There is a method for our users to still customise the styles by using :has(). Although it's relatively new and is not supported by older browsers.
Example of a focused navigation item before refactoring


Updates challenge to return boolean expression

Based on #24026 I've changed this challenge to return a boolean expression rather than boolean values.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the 24026 below with the issue number.
Closes #24026

@RandellDawson IMO we should close it.

I agree.

Thank you for submitting a pull request to attempt to resolve PR#24026.  However, upon review, your additions change the function from returning a Boolean value, which is what the original challenge did, to returning strings.  In the original issue PR #24026, it was asked whether or not to return a Boolean expression or explicitly return true and false.  You completely changed the challenge to return strings which is unnecessary.
The focus of this challenge is on understanding the Constructor Property and not on how to return Boolean expressions.   The only suggested change which would fit with @mail-liam's original suggestion would be to just change the example in the Description section to return a Boolean expression.  This way, it makes the code concise and does not involve needing to change the Tests section of the challenge.  If you want to do that, then please create a new PR with just that change.
Thank you.


Is there a way to include multiple numbers?

Hi All,
I'm sorry this is a very very basic question but today is the first time I have used Raw! I am loving it but having a few problems with my data (which is very simple)
I have 2 strings and each strings has 2 numbers but when I go to visualise I am not able to show both strings, with both of their values at the same time.
I can only show one string with both values. Is there any way to rectify this? On the charts I have been looking at I am only numbers are singular.
Any help would be much appreciated.
Many thanks

Hello,
can you provide a sample of the data? I'm not sure to have understood the problem

Probably you have multiple values in the same cell. In this case you must work on the dataset splitting them or in different columns, or in different rows, then reuploading it in RAWGraphs. OpenRefine could be a good solution:
https://github.com/OpenRefine/OpenRefine/wiki/Cell-Editing#splitting-multiple-values-within-cells-to-produce-records


leverage itemize_list and write_list to recover trait bound comments

Fixes #2055
Now when using version::Two, rustfmt will permit comments within trait bounds and actually reformat them instead of refusing to rewrite the entire trait definition because there are comments in the bounds.
This follows the approach hinted at in https://github.com/rust-lang/rustfmt/issues/2055#issuecomment-343150579.
Edit -- Other issues fixed by this change:
Fixes #6127

TODO: add test case for #5321, which I think this also fixes

I tried a bit, I think we can do better for supertrait:
I have this code:
pub trait MyLongTraitName:
	MyLongBoundName<
		MyLongAssociatedType:
			SomeAnotherBound<
				YetAnotherType: YetAnotherBound,
				YetAnotherType2: YetAnotherBound2
			>,
		OtherType: SmallBound
			+ SmallBound2
			+ AnotherLongBound<
				WithSomeType: BeingBound,
				WithSomeType2: BeingBound,
				WithSomeType3: BeingBound
			>
			+ SmallBound3
			+ AnotherLongBound2<
				WithSomeType: BeingBound,
				WithSomeType2: BeingBound,
				WithSomeType3: BeingBound
			>,
	>
{}

It get formatted into this with this PR:
pub trait MyLongTraitName:
    MyLongBoundName<
        MyLongAssociatedType: SomeAnotherBound<
            YetAnotherType: YetAnotherBound,
            YetAnotherType2: YetAnotherBound2,
        >,
        OtherType: SmallBound
                       + SmallBound2
                       + AnotherLongBound<
            WithSomeType: BeingBound,
            WithSomeType2: BeingBound,
            WithSomeType3: BeingBound,
        > + SmallBound3
                       + AnotherLongBound2<
            WithSomeType: BeingBound,
            WithSomeType2: BeingBound,
            WithSomeType3: BeingBound,
        >,
    >
{
}

we can the generics inside AnotherLongBound are not correctly formatted.
And the + is maybe too far on the right?


get information about dpms/screensaver state

Trying to write a rofi script to disable/enable screensaver/screen blanking, but could not find a way to query X for actual state with available tools.
Maybe this might be a useful addition to xininfo?

Added screensaver , please test.


rust installation failing

curl https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init | sha256sum
The checksum of the rust installer changed to 49c96f3f74be82f4752b8bffcf81961dea5e6e94ce1ccba94435f12e871c3bdb

Fixed, thanks!


Replace PROOF_SOURCES with ABSTRACTIONS when using stubs in CBMC proofs

Replace PROOF_SOURCES with ABSTRACTIONS when using stubs in CBMC proofs.

Was this added in the merged PR?


HTTP FAILED: java.lang.IllegalStateException: message == null

Hi guys and thank you for this great lib !
I'm currently using it for the first time and I have a small problem. Maybe it comes from a wrong usage of the lib.
Concretely, I have :

a BASE_URL = "https://changeme.com"
a file hello.json located at assets/api which content is :
{ "hello": "test" }
a model class :
data class Hello(val hello:String)
a retrofit service :
interface HelloService {   @GET("api/hello")   fun getHello(): Single<Hello> }

Here's how I create my retrofit instance including the mock interceptors on OkHttpClient :
           val httpClient = OkHttpClient.Builder()

           if (BuildConfig.DEBUG)
            httpClient.addInterceptor(HttpLoggingInterceptor().setLevel(HttpLoggingInterceptor.Level.BODY))

           if (inputStreamProvider != null)
                httpClient.addInterceptor(OkHttpMockInterceptor(inputStreamProvider, 5))

            val retrofit = Retrofit.Builder()
                    .addConverterFactory(GsonConverterFactory.create())
                    .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
                    .baseUrl(baseUrl)
                    .client(httpClient.build())
                    .build()

Finally, here's my inputStreamProvider instanciation :
private val inputStreamProvider = InputStreamProvider {
        try {
            assets.open(it)
        } catch (e: IOException) {
            e.printStackTrace()
        }
        null
    }

The error I have when I use my service is that I haven't the response I expect and I have an error :
D/OkHttp: --> GET https://changeme.com/api/hello
          --> END GET
D/OkHttp: <-- HTTP FAILED: java.lang.IllegalStateException: message == null

Has anyone an idea of the problem here ? It will be very useful !
Thank you :+1: !

Hi @Aissa-H,
I am so busy these days. so maybe I have a bit of extra time on the weekend to fix this problem. but no promises :)

I tried to reproduce the issue and I noticed that it happened when the json asset can't be found.
are you sure you have hello.json under assets/api/?
also assets.open(filename) is  case-sensitive, so for example if you have helLO.json file in assets/api/ and you are calling api/hello then it will throw a java.io.FileNotFoundException.

Closing due to inactivity.


[portal]: region details on the map should show details of both MSP and divisions

Currently, when checking region details on the portal map, it's not clear how many divisions joined - just legal entities are shown
Can we please add divisions too?
cc: @kmakarenko @lymychp

not required anymore

oops sorry, wrongly closed

no, that's correct - not required anymore =))


when set TransitionType.fadeIn  iOS Swipe back not work，Android working fine

Hi：
This is greate libary，but i have a problem。
When set TransitionType.fadeIn  iOS Swipe back not work，Android working fine
How to solve this problem？
Do you have any idea？
Thank you

That’s because the slide back on iOS is part of the CupertinoTransition.

@miguelpruivo
you mean if we set transition type to 'cupertino', it can work both on android and ios?

@miguelpruivo it worked on ios after I changed the transition type to 'cupertino'

Closing because there is nothing actionable


virt-api, iface-hotplug: Drop redundant conditions

What this PR does / why we need it:
The request.AddInterfaceOptions != nil has been used in a defensive manner on functions which are dedicated to adding an vNIC. I.e. the code flow would have reached these functions only if the operation has been recognized as a hotplug, implying that the request has this data and there is no need to re-check it again in the stack.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:
NONE

/sig network

/cc AlonaKaplan

/test  pull-kubevirt-e2e-kind-1.23-sriov

thanks!
/approve


Document that blog_name changes the navbar

I love the new design, but was confused why the blog link didn't show up on the nav bar.  It was because the blog needs a name for it to appear.  Just added a comment in the config that documents this behavior.
Thank you for a great template!

Great, thanks for the contribution!