guess_filename(obj) doesn't recognize werkzeug.datastructures.FileStorage

This is my first issue ever on any repo. So kindly forgive me if I'm asking a naive question or don't have enough information provided.
I am currently working on an API in Flask-Restful on Client side and also have to consume the Server side API using Requests API.

So I was adding an image along with some other form components like text and sending it to the Server side API using Requests' POST call.
The datastructure understood by Flask-restful for Images/ Files is werkzeug.datastructures.FileStorage, which I think is similar to a Multi-dict.

def post():
    payload_data = {}   # some data
    payload_files = {}   # abc.png
    url = http://xyz/api/
    response_obj = requests.post(url, data=payload_data, files=payload_file)

Now inside the models.py, at line https://github.com/kennethreitz/requests/blob/master/requests/models.py#L117 gives me the value for files as

[('form_image', <FileStorage: 'abc.png' ('image/png')>)]
# form_image is just the name of the image in form.

The key-value structure of a normal FileStorage object is something like this (from debugger)
* {FileStorage} <FileStorage: 'abc.png' ('image/png')>
     * _parsed_content_type = {tuple} ('image/png', {})
     * content_length = {int} 0
     * content_type = {str} 'image/png'
     * filename = {str} 'abc.png'
     * headers = {Headers} Content-Disposition: form-data; name="form_image";
     * filename="abc.png"\r\nContent-Type: image/png\r\n\r\n
     * mimetype = {str} 'image/png'
     * mimetype_params = {dict} {}
     * name = {str} 'form_image'
     * stream = {BufferedRandom} <_io.BufferedRandom name=9>

Note that the filename is inside the key filename and not name.
Then it calls the guess_filename at
fn = guess_filename(v) or k

In the guess_filename(obj), the value of the obj is still
<FileStorage: 'abc.png' ('image/png')>

THIS LINE checks the object and checks the key "name" instead of "filename"
name = getattr(obj, 'name', None)

After this, the value of name is now "form_image" instead of "abc.png"

As a result, the server side receives the file with the name form_image, instead of the real file name.

Is there a solution to this? Please let me know.

If not, it seems that FileStorage works differently than was anticipated in guess_filename. So does there have to be some line that does this:

from werkzeug import datastructures
if isinstance(obj, FileStorage):
    name = getattr(obj, 'filename', None)
else:
    name = getattr(obj, 'name', None)

This is my first issue ever on any repo. So kindly forgive me if I'm asking a naive question or don't have enough information provided.

Welcome! Thanks for getting started with us! :tada: :cake: :balloon:
So to your core question, the guess_filename function is a bit tricky. It basically does its best to handle things that might reasonably be passed in that come from the standard library. Sadly, writing special-case code to handle all non-stdlib objects is probably outside the scope of this library.
The "correct" way to do this is to use the extended form of the files parameter. Rather than pass just the FileStorage object as the value of the dict, try passing a tuple of the form (payload_file.filename, payload_file). The first element will be used as the filename, overriding the choice of guess_filename. That's what you should use whenever our choice is bad.

Oh yeah. I should have read this properly. It solved the filename problem. :+1:  Thank you so much.
Although, it opened up a problem incomprehensible to me,
While feeding the file from Client-side API to Server-side API through Requests, the content-type gets set to None.

This is when I POST to the Requests API, inside the sessions.py, the value of files is this:

But, when it comes out of it (I tried really hard to debug, but didn't understand what's happening behind the scenes), this is the format of files in the entry point of Server-side API.

Do you think I am doing something wrong here? Can you suggest something?

Also, why can't I do this:

def post():
    payload_json = {}   # data in json format
    payload_files = {}   # abc.png
    url = http://xyz/api/
    response_obj = requests.post(url, json=payload_data, files=payload_file)

(If I do this, the files data gets sent and the json and data header are None.)
Instead of this:
def post():
    payload_data = {}   # some data
    payload_files = {}   # abc.png
    url = http://xyz/api/
    response_obj = requests.post(url, data=payload_data, files=payload_file)

Probably the server side takes the content type from a specific header. Try using the even more extended form of the files parameter, by passing a tuple of the form (payload_file.filename, payload_file, payload_file.content_type).
As to why you can't use JSON with files, the main reason is that it's not clear how the JSON will fit into the multipart upload. It's generally better to let users do this themselves,as we will just get it wrong.


Allow use of MSBuild without Git

Fixes #1594

Build hasn't fallen over immediately so this should be ready for review (1 LOC)


[BUG] Press the Enter key, the page will be refreshed automatically

Describe the bug

Press the Enter key, the page will be refreshed automatically
To Reproduce
Steps to reproduce the behavior:

go to setting page
edit cluster-registration-url setting.   (The same problem exists with ui-index， upgrade-checker-url， support-bundle-timeout)
Focus the mouse on the input box
Press enter   key（The page will refresh）

https://images.zenhubusercontent.com/279592699/06360e66-f2ba-40a5-8b9b-f2a17c1a1ce0/____2022_07_26_19_38_12.mov
Expected behavior

Pressing Enter should not refresh the page，
Support bundle

Environment

Harvester ISO version:
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.

Verified fixed on v1.0-b6244fcd-head (220801, backport v1.0)
But not fixed on master-89385df9 (220729 1.1.0 master)
@WuJun2016, do you think we need to open another issue for the v1.1.0 master or also check the master version behavior before closing this issue.
Result
On v1.0.3 backport, when we press the Enter key in the following page fields, it will not being refreshed automatically.

Cluster registration

ui-index

upgrade-checker-url

support-bundle-timeout

http proxy

overcommit-config

support-bundle-image

vm-force-reset-policy

backup target

release download url

Test Information

Test Environment: 1 node harvester on local kvm machine
Harvester version: v1.0-b6244fcd-head (220801, backport v1.0)

Verify Steps

Check every page have input filed in the Settings page
Move cursor to any input field
Click the Enter button
Check the page will not be automatically loaded


Bleat Classic API: Retrieving services, charactertistics and descriptors independetly of UUID casing

To get objects for services, charactertistics and descriptors in Bleat Classic API, map indexing is used.
Keys are UUIDs and these are case dependent.
Would there be a way to make UUIDs case independent?
For example, methods on device, service and characteristic objects?
Example:
var service = device.getService(serviceUUID);
var characteristic = characteristic.getCharacteristic(characteristicUUID);
var descriptor = characteristic.getDescriptor(descriptorUUID);

The above functions would then convert the case of the supplied parameter, so that both upper and lower case UUIDs would work.

I wrote the bleatHelpers.getCanonicalUUID() function to fully expand a uuid and help with matching.
You can always use toUpperCase() in JavaScript, but I don't understand why you need this (unless I've missed something and BLE UUIDs are case insensitive?)

@thegecko Thanks, looks like ´bleatHelpers.getCanonicalUUID()´could be useful. In my experience hexadecimal numbers in general usually are case insensitive, and also UUIDs. I ran into this problem today when I had UUIDs specified in uppercase but they keys in the map were lower case. Was thinking this might be a problem others could run into.

@thegecko My understanding is that the proposed functions are not really needed. Closing this issue.


[WIP] + Support HashiCorp Vault as a remote KMS

This PR is still work in progress, but I'd like to use it to address some questions before it'd be ready for merge.
Questions:
Tests
In order to test the code we need to spin up a HashiCorp Vault server. There is a docker image I can use for the server, but it'll add Docker requirement for the test. WDYT?
*_client.go logic
GCP and AWS clients have some logic I don't quite understand. It seems like they supposed to support prefix-based keys comparison, for example:
// Supported true if this client does support keyURI
func (g *GCPClient) Supported(keyURI string) bool {
	if (len(g.keyURI) > 0) && (strings.Compare(strings.ToLower(g.keyURI), strings.ToLower(keyURI)) == 0) {
		return true
	}
	return ((len(g.keyURI) == 0) && (strings.HasPrefix(strings.ToLower(keyURI), gcpPrefix)))
}

the code above implies that there might be a case when len(g.keyURI) == 0, but how this can happen assuming that in the constructor function we explicitly check that keyURI must have a non-empty gcpPrefix?
Am I missing anything?

In order to test the code we need to spin up a HashiCorp Vault server. There is a docker image I can use for the server, but it'll add Docker requirement for the test. WDYT?

I'm not sure if our test infra supports this. I'll ping you on chat to discuss.

the code above implies that there might be a case when len(g.keyURI) == 0, but how this can happen assuming that in the constructor function we explicitly check that keyURI must have a non-empty gcpPrefix?

The code should support two use cases:

The client is bound to a single keyURI. NewGCPClient does this.
The client can support any keyURI starting with gcp-kms://. I think there's a missing constructor that supports this use case. Could you please help add it?

@thaidn Thank you, please let me know how we can solve the testing question. Maybe similar to GCP and AWS integrations we can run a HashiCorp Vault instance in the cloud.
Regarding the prefix-based client support, I'll create a new PR for it.


Add go based launcher

The compiled, static binaries are used instead of a python script. This is drop-in replacement with the same configuration/usage. Implementation is covered by tests to ensure compatibility.

Airlift contribution check list

[x] Git commit messages follow https://cbea.ms/git-commit/.
[x] All automated tests are passing.
[x] Pull request was categorized using one of the existing labels.

Nit - don't use golang, just go.

Nit - don't use golang, just go (in the commit message and PR title).

Add Go-based launcher

@martint macos added (I still think it's unnecessary tho as we don't ship MacOS docker images)

@martint macos added (I still think it's unnecessary tho as we don't ship MacOS docker images)

But there are people using it locally from the tarball with macos (like myself) and we should continue to support this usage.
I also hope it will continue to work with Windows via WSL (so that would be Linux technically I think)

@martint AC

Tested locally with https://github.com/trinodb/trino/pull/24132

The build now requires go to be installed, which is not typical for a Maven build. Can we make it run in Docker by default?

Alternatively, we could create a new launcher project repository that builds the same way with Maven and the build.sh but requires go. Then Airlift itself can simply depend on the binary (which hopefully won't need to change often).

@electrum Dependencies are now:
UPX 4.2.4       Markus Oberhumer, Laszlo Molnar & John Reiser    May 9th 2024
github.com/fatih/color v1.18.0 h1:S8gINlzdQ840/4pfAwic/ZE0djQEH3wM94VfqLTZcOM=
github.com/fatih/color v1.18.0/go.mod h1:4FelSpRwEGDpQ12mAdzqdOukCy4u8WUtOY6lkT/6HfU=
github.com/gofrs/flock v0.8.1 h1:+gYjHKf32LDeiEEFhQaotPbLuUXjY5ZqxKgXy7n59aw=
github.com/gofrs/flock v0.8.1/go.mod h1:F1TvTiK9OcQqauNUHlbJvyl9Qa1QvF/gOUDKA14jxHU=
github.com/mattn/go-colorable v0.1.13 h1:fFA4WZxdEF4tXPZVKMLwD8oUnCTTo08duU7wxecdEvA=
github.com/mattn/go-colorable v0.1.13/go.mod h1:7S9/ev0klgBDR4GtXTXX8a3vIGJpMovkB8vQcUbaXHg=
github.com/mattn/go-isatty v0.0.16/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM=
github.com/mattn/go-isatty v0.0.20 h1:xfD0iDuEKnDkl03q4limB+vH+GxLEtL/jb4xVJSWWEY=
github.com/mattn/go-isatty v0.0.20/go.mod h1:W+V8PltTTMOvKvAeJH7IuucS94S2C6jfK/D7dTCTo3Y=
github.com/spf13/afero v1.11.0 h1:WJQKhtpdm3v2IzqG8VMqrr6Rf3UYpEF239Jy9wNepM8=
github.com/spf13/afero v1.11.0/go.mod h1:GH9Y3pIexgf1MTIWtNGyogA5MwRIDXGUr+hbWNoBjkY=
github.com/theckman/go-flock v0.8.1 h1:kTixuOsFBOtGYSTLRLWK6GOs1hk/8OD11sR1pDd0dl4=
github.com/theckman/go-flock v0.8.1/go.mod h1:kjuth3y9VJ2aNlkNEO99G/8lp9fMIKaGyBmh84IBheM=
golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
golang.org/x/sys v0.27.0 h1:wBqf8DvsY9Y/2P8gAfPDEYNuS30J4lPHJxXSb/nJZ+s=
golang.org/x/sys v0.27.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=
golang.org/x/text v0.20.0 h1:gK/Kv2otX8gz+wn7Rmb3vT96ZwuoxnQlY+HlJVj7Qug=
golang.org/x/text v0.20.0/go.mod h1:D4IsuqiFMhST5bX19pQ9ikHC2GsaKyk/oF+pn3ducp4=
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405 h1:yhCVgyC4o1eVCa2tZl7eS0r+SDo693bJlVdllGtEeKM=
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=

@electrum I've addressed your concerns

Closing in favor of https://github.com/airlift/launcher/pull/1


COR issue

Using the example chat unchanged I receive a
"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://file/socket.io/?EIO=3&transport=polling&t=My7DERo. (Reason: CORS request did not succeed)."
message. Looking around for enabling CORS I found a few tips like:
app.options('*', cors()) // include before other routes
app.use(cors({origin: 'http://localhost:3000', }));
but I do not see where and how I can enable it in this app.
It would be great if you would COR enable the example app since it would make the example work again and I could learn how to use the solution in my app based on your example.
Thank you in advance
g strubinsky

app.use(cors({
origin: ""
}));
app.options('', cors());


Remove hardcoded browse endpoints

This PR connects to #147
It is still a work in progress.
The code should be done, but I need to add more tests.

This PR is now ready for review
The performance issues I mentioned during last week's meeting turned out to be caused by inadvertently triggering Angular's change detection in the RemoteDataBuildService (sometimes dozens of times a second).
Fixing the problem made a different issue come to light: Angular's change detection doesn't work automatically on RemoteData objects used as @Input(), they're too complex. We've been having this issue all along but weren't able to notice it because change detection was triggered by the RemoteDataBuildService all the time.
The solution was to turn all observable properties from RemoteData in to regular properties, and instead having the RemoteDataBuildService return an Observable<RemoteData>. So now, every time something about the RemoteData object's state changes, a complete RemoteData object is emitted, not just the property that changed.
Because the observable is now on the outside, we can rely on Angular to automatically detect changes. It also makes working (and testing) with remote data objects easier.
The change also allowed me to switch to ChangeDetection.OnPush everywhere, which further reduces the number of times change detection needs to run.

As we discussed yesterday, I refactored all the async usages in the templates using a custom ngVar directive, that allows us to define a variable outside an ngIf


tensorrt ValuError while onnx is working

Hi , I am trying to run infernce on a yolov5 model using tensorrt backend. It works fine with onnx backend in "auto" mode using gpu and in "cpu" as well . when I use the tensorrt backend I get the error message:cannot reshape array of size 280500 into shape (1,newaxis,8).
the full trace is:
[CVU-Info] Building and Optimizing TRT-Engine for input_shape=(640, 640). This might take a few minutes for first time.
[03/27/2023-11:41:21] [TRT] [I] Loaded engine size: 270 MiB
[03/27/2023-11:41:21] [TRT] [I] [MemUsageChange] TensorRT-managed allocation in engine deserialization: CPU +0, GPU +268, now: CPU 0, GPU 268 (MiB)
[03/27/2023-11:41:21] [TRT] [I] [MemUsageChange] TensorRT-managed allocation in IExecutionContext creation: CPU +0, GPU +43, now: CPU 0, GPU 311 (MiB)
[03/27/2023-11:41:21] [TRT] [E] 1: [pointWiseV2Helpers.cpp::launchPwgenKernel::282] Error Code 1: Cuda Driver (invalid resource handle)
Traceback (most recent call last):
File "/run/user/1000/gvfs/smb-share:server=ednas.local,share=promethai/transfer/parsec_checkpoints/onnx_test_no_jupyter.py", line 28, in
preds = infer(image,detector)
File "/run/user/1000/gvfs/smb-share:server=ednas.local,share=promethai/transfer/parsec_checkpoints/onnx_test_no_jupyter.py", line 19, in infer
preds = detector(image)
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/cvu/detector/yolov5/core.py", line 106, in call
outputs = self._model(processed_inputs)
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/cvu/detector/yolov5/backends/yolov5_tensorrt.py", line 320, in call
preds = self._post_process(outputs)
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/cvu/detector/yolov5/backends/yolov5_tensorrt.py", line 369, in _post_process
outputs = outputs[-1].reshape((1, -1, self._nc + 5))
ValueError: cannot reshape array of size 280500 into shape (1,newaxis,8) #
I initially had an error that stated :
[CVU-Info] Building and Optimizing TRT-Engine for input_shape=(640, 640). This might take a few minutes for first time.
[03/27/2023-11:10:37] [TRT] [I] [MemUsageChange] Init CUDA: CPU +318, GPU +0, now: CPU 383, GPU 1440 (MiB)
[03/27/2023-11:10:39] [TRT] [I] [MemUsageChange] Init builder kernel library: CPU +442, GPU +116, now: CPU 880, GPU 1545 (MiB)
[03/27/2023-11:10:39] [TRT] [W] CUDA lazy loading is not enabled. Enabling it can significantly reduce device memory usage. See CUDA_MODULE_LOADING in https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#env-vars
[CVU-Info] Platform has fp16 support. Setting fp16 to True
[libprotobuf WARNING google/protobuf/io/coded_stream.cc:604] Reading dangerously large protocol message.  If the message turns out to be larger than<PHONE_NUMBER> bytes, parsing will be halted for security reasons.  To increase the limit (or to disable these warnings), see CodedInputStream::SetTotalBytesLimit() in google/protobuf/io/coded_stream.h.
[libprotobuf WARNING google/protobuf/io/coded_stream.cc:81] The total number of bytes read was 560598739
[03/27/2023-11:10:39] [TRT] [W] onnx2trt_utils.cpp:377: Your ONNX model has been generated with INT64 weights, while TensorRT does not natively support INT64. Attempting to cast down to INT32.
[03/27/2023-11:10:41] [TRT] [I] [MemUsageChange] Init cuBLAS/cuBLASLt: CPU +854, GPU +362, now: CPU 2311, GPU 1905 (MiB)
[03/27/2023-11:10:41] [TRT] [I] [MemUsageChange] Init cuDNN: CPU +129, GPU +58, now: CPU 2440, GPU 1963 (MiB)
[03/27/2023-11:10:41] [TRT] [W] TensorRT was linked against cuDNN 8.6.0 but loaded cuDNN 8.5.0
[03/27/2023-11:10:41] [TRT] [I] Local timing cache in use. Profiling results in this builder pass will not be stored.
[03/27/2023-11:12:05] [TRT] [I] Some tactics do not have sufficient workspace memory to run. Increasing workspace size will enable more tactics, please check verbose output for requested sizes.
[03/27/2023-11:17:55] [TRT] [I] Total Activation Memory: 377833472
[03/27/2023-11:17:55] [TRT] [I] Detected 1 inputs and 5 output network tensors.
[03/27/2023-11:17:58] [TRT] [I] Total Host Persistent Memory: 524032
[03/27/2023-11:17:58] [TRT] [I] Total Device Persistent Memory: 1577984
[03/27/2023-11:17:58] [TRT] [I] Total Scratch Memory: 0
[03/27/2023-11:17:58] [TRT] [I] [MemUsageStats] Peak memory usage of TRT CPU/GPU memory allocators: CPU 309 MiB, GPU 268 MiB
[03/27/2023-11:17:58] [TRT] [I] [BlockAssignment] Started assigning block shifts. This will take 243 steps to complete.
[03/27/2023-11:17:58] [TRT] [I] [BlockAssignment] Algorithm ShiftNTopDown took 21.2057ms to assign 10 blocks to 243 nodes requiring 42944512 bytes.
[03/27/2023-11:17:58] [TRT] [I] Total Activation Memory: 42944512
[03/27/2023-11:17:58] [TRT] [W] TensorRT encountered issues when converting weights between types and that could affect accuracy.
[03/27/2023-11:17:58] [TRT] [W] If this is not the desired behavior, please modify the weights or retrain with regularization to adjust the magnitude of the weights.
[03/27/2023-11:17:58] [TRT] [W] Check verbose logs for the list of affected weights.
[03/27/2023-11:17:58] [TRT] [W] - 160 weights are affected by this issue: Detected subnormal FP16 values.
[03/27/2023-11:17:58] [TRT] [W] - 3 weights are affected by this issue: Detected values less than smallest positive FP16 subnormal value and converted them to the FP16 minimum subnormalized value.
[03/27/2023-11:17:58] [TRT] [I] [MemUsageChange] TensorRT-managed allocation in building engine: CPU +267, GPU +269, now: CPU 267, GPU 269 (MiB)
[CVU-Info] Engine serialized and saved !
[03/27/2023-11:17:58] [TRT] [I] [MemUsageChange] TensorRT-managed allocation in IExecutionContext creation: CPU +0, GPU +42, now: CPU 267, GPU 311 (MiB)
[03/27/2023-11:17:58] [TRT] [W] CUDA lazy loading is not enabled. Enabling it can significantly reduce device memory usage. See CUDA_MODULE_LOADING in https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#env-vars
/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/tensorrt/init.py:166: FutureWarning: In the future np.bool will be defined as the corresponding NumPy scalar.  (This may have returned Python scalars in past versions.
bool: np.bool,
Traceback (most recent call last):
File "/run/user/1000/gvfs/smb-share:server=ednas.local,share=promethai/transfer/parsec_checkpoints/onnx_test_no_jupyter.py", line 25, in
preds = infer(image,detector)
File "/run/user/1000/gvfs/smb-share:server=ednas.local,share=promethai/transfer/parsec_checkpoints/onnx_test_no_jupyter.py", line 17, in infer
preds = detector(image)
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/cvu/detector/yolov5/core.py", line 106, in call
outputs = self._model(processed_inputs)
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/cvu/detector/yolov5/backends/yolov5_tensorrt.py", line 308, in call
self._allocate_buffers()
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/cvu/detector/yolov5/backends/yolov5_tensorrt.py", line 272, in _allocate_buffers
dtype = trt.nptype(self._engine.get_binding_dtype(binding))
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/tensorrt/init.py", line 166, in nptype
bool: np.bool,
File "/home/ed/anaconda3/envs/prometai_v1/lib/python3.8/site-packages/numpy/init.py", line 284, in getattr
raise AttributeError("module {!r} has no attribute "
AttributeError: module 'numpy' has no attribute 'bool'
[03/27/2023-11:17:59] [TRT] [E] 1: [resizingAllocator.cpp::deallocate::105] Error Code 1: Cuda Runtime (invalid argument)
[03/27/2023-11:17:59] [TRT] [E] 1: [resizingAllocator.cpp::deallocate::105] Error Code 1: Cuda Runtime (invalid argument)
[03/27/2023-11:17:59] [TRT] [E] 1: [resizingAllocator.cpp::deallocate::105] Error Code 1: Cuda Runtime (invalid argument) #
which i found to be a numpy version issue since types in 1.24.1 are deprecated ( as info), I downgraded numpy tp 1.23.1 and received above first error .
Does anyone have an idea wht can be done to mitigate?
Thanks

@ronin2304 can you share a minimal working example code to reproduce the error?
What kind of data are you using for the model? What is your batch size?
This error
 ValueError: cannot reshape array of size 280500 into shape (1,newaxis,8) #

makes sense: 280500 is not divisible by 8. Maybe you should investigate what this value is. Maybe the pixels in your image, hard to say before you post the code. Thank you.


Query parameter Account is ignored

Describe the bug
When I query get /transactions?account=some-account-here it ignore the account query parameter
To Reproduce
curl --request GET \
--url 'http://localhost:3068/quickstart/transactions?account=211212'
--header 'Accept: application/json' | jq
Expected behavior
return the transactions that match with the desired account
Logs
If applicable, add logs to help explain your problem.
Environment (please complete the following information):

OS: BigSur
Numary Version

Version: 1.0.0-beta.11
Date: 2021-11-23T11:54:22Z
Commit: 48ca56b

Fixed by #71 - thanks @S0c5!


Ensure that page-feedback events are usable with Google Analytics 4

Related to #2861
The Docsy page feedback feature has been enabled since v1.4 of the docs
There's feature interaction with GA4. For details, see the upstream issue: https://github.com/google/docsy/issues/1302

If there's a feeling of urgency to collected page-feedback events in GA4, then the local partial layouts/partials/feedback.html will at least need to be updated to use the gtag.js library, and an event-modification rule implemented. For an example of how this has been implemented, see:

https://github.com/kubernetes/website/issues/37657

Specifically, https://github.com/kubernetes/website/issues/37657#issuecomment-1301548361.
If there is no feeling of urgency in gathering this data under GA4, then I'd suggesting waiting for the upstream fix and then updating Hugo.

I went ahead and created an event-modification rule, in case we get local changes into the project-local feedback-partial override before the Docsy fix lands:

@chalin would you say this issue is resolved?

Hi @hhunter-ms - yes in that I created the necessary event-modification rule, but it will only work for v1.7+ of the docs. I didn't close this issue at the time because I wasn't sure how far back in the doc versions you wanted analytics support for.
According to https://github.com/dapr/docs/issues/2861#issuecomment-1349504800, v1.7+ is good enough. Closing!


⚠ RPC server - Optimism has degraded performance

In d5dcbc4, RPC server - Optimism ($OPTIMISM_RPC_URL) experienced degraded performance:

HTTP code: 429
Response time: 394 ms

Resolved: RPC server - Optimism performance has improved in 1529041 after 11 minutes.


Improve theme display

Need to move variable to :root.

I won't do it, unless you could write clear code to implement it, but I think it is impossible.

I don't see why a regex like --theme-display-name:\s?(\S+) wouldn't work.

Easy match: https://regex101.com/r/nJEo79/1

I don't see why a regex like --theme-display-name:\s?(\S+) wouldn't work.

Just do it.

Working on new :root regex.

Ugh thanks for the merge conflict.

It's the same time as answering https://github.com/go-gitea/gitea/pull/30671#discussion_r1579829693 ... the conflict could be simple because I didn't change much, only removed PreferColorSchemes and added some comments

New version is up. It parses for the last occurence of a variable in a file. If that does not suit you, we install a full CSS parsers.

we install a full CSS parser.

Definitely say no to CSS parser, it is over-engineering.

Looking for feedback from other maintainers:
@wxiaoguang's proposal (matching specific non-existant element):
gitea-theme-meta-info {
  --theme-display-name: "My Theme";
}
:root {
  --is-dark-theme: false;
}

My proposal (matching last occurence of variable anywhere in the theme):
:root {
  --theme-display-name: "My Theme";
  --is-dark-theme: false;
}

My proposal (matching last occurence of variable anywhere in the theme, but could be restricted to last :root selector as well):

See my comments above, your proposal doesn't work.
Please propose a workable sample first, just like my workable sample in https://github.com/go-gitea/gitea/pull/30671#discussion_r1579985228 :

Backend code could know the theme's mode: light, dark, auto (to display in the list).
JS code could know whether the current theme scheme is light/dark (no auto), to decide how to apply colors.

Your edit was incorrect, I updated "my proposal".

Your edit was incorrect, I updated "my proposal". I don't know the purpose of your --theme-website.

The meta info should never be inherited. "website" is a demo.

Your edit was incorrect, I updated "my proposal". I don't know the purpose of your --theme-website.

Your demo is too simple and doesn't reflect the true content. I disagree with your sample.

This --theme-website would not be inside the media queries. It's metadata that is true for both color schemes, so would be outside most likely. Inside media queries scheme we really only need --is-dark-theme.

I suggest we rename to --theme-name, shorter and more memorable, the other one is the "file name".

I think this is very important decision which towards the possibility of a dynamic theme which maybe installed online by Gitea. The remote or local theme packages could contain multiple files. Maybe a directory structure or a zip package with a meta file is better. So that, maybe all the metat theme information should be stored in another yml file? Maybe we can mkdir for every theme but not only a CSS file.

The remote or local theme packages could contain multiple files

I would not support multi-file themes, and if user really wants to, they must put metadata into the first file.

metat theme information should be stored in another yml file

I think that needlessly complicates things. Putting it into the CSS is ideal because then we can also access this data in frontend.

Basic design

use --theme-xxx to store meta info like display name, color scheme (dark/light/auto), etc.
use a separate var like --is-dark-them in :root to present whether the current applied scheme is dark, it is different from "color scheme (dark/light/auto)"  and can not be deduplicated.

About the samples
Silverwind's samples are too simple, and do not really reflect the true content. When an "auto" them imports others, there are --theme-xxx vars in each @media (prefers-color-scheme) section, see the Gitea's builtin compiled auto theme.
About where to store --theme-xxx vars
I believe my method is the right one, use a privately defined section gitea-theme-meta-info, we handle everything clearly without any surprise.
Silverwind's method mixes the --theme-xxx into :root section, but:

--theme-xxx should never be directly used b frontend, neither CSS nor JS, there is no such use case.
Putting --theme-xxx in :root causes unnecessary overriding problems for meta info parsing, using them directly in frontend will case abusing, see the --theme-website case.
If frontend would like to know some --theme-xxx  values, backend could pass them via various approaches, backend could guarantee the provided values are well-defined and well-formatted.

My example is complete. Themes that make use of media features should declare their "general" vars outside these block. Here is a example of a theme in my format that supports all prefers-* media features:
@media (prefers-color-scheme: dark) { :root { --is-dark-theme: true; } }
@media (prefers-color-scheme: light) { :root { --is-dark-theme: false; } }
@media (prefers-color-contrast: no-preference) { :root { --is-contrast-theme: false; } }
@media (prefers-color-contrast: more) { :root { -is-contrast-theme: true; } }
@media (prefers-color-contrast: less) { :root { -is-contrast-theme: true; } }
@media (prefers-reduced-motion: no-preference) { :root { -is-reduced-motion-theme: false; } }
@media (prefers-reduced-motion: reduce) { :root { -is-reduced-motion-theme: true; } }

:root {
  --theme-display-name: "My Theme";
  --theme-website: "https://gitea.com/user/mytheme";
  --theme-color-scheme: auto;
  --theme-color-contrast: auto;
  --theme-reduced-motion: auto;
}

@wxiaoguang please show me how this would look in your format and you will see that your method simply does not scale to multiple media features.

When an "auto" them imports others, there are --theme-xxx vars in each @media (prefers-color-scheme) section, see the Gitea's builtin compiled auto theme.

See this:
@import "./theme-gitea-light.css" (prefers-color-scheme: light); // it has --theme-xxx
@import "./theme-gitea-dark.css" (prefers-color-scheme: dark); // it has --theme-xxx

--theme-xxx // this file's

I have shown my format in https://github.com/go-gitea/gitea/pull/30671#issuecomment-2077995426 , my method does work well, for your new case:

Your method would needlessly duplicate stuff like --theme-name and --theme-author into every @media block, so in total you would have theme name 6 times. This repetition is simply unacceptable in my book.

I have shown my format in #30671 (comment) , my method does work well, for your new case:

Your method would needlessly duplicate stuff like --theme-name and --theme-author into every @media block, so in total you would have each variable 6 times. Such repetition is simply unacceptable.

No, I don't! I have told you that these --theme-xxxx are from other CSS files imported
My method do not need any extra --theme-author for each media block. See https://github.com/go-gitea/gitea/pull/30671#issuecomment-2079192477

What's the difference in yours?

I have explained above.

It looks exactly the same to me.

Then why not use my method?

Your only difference is gitea-theme-meta-info and I'm still against it as it's a dead selector and therefor inaccesible to JS getComputedStyle. It does seem we agree on the other parts thought, so this selector is the only contentious part.

Everything I have explained many times. I am sure my method is the right method, while yours will cause problems.

gitea-theme-meta-info is not bad, it is only privately defined and used by backend code
gitea-theme-meta-info should never be used directly in frontend, using it in frontend will definitely cause problems.

I am 100% sure I will never agree with putting them into :root.

I reset the branch to my method. Your work is saved in https://github.com/wxiaoguang/gitea/commits/theme-meta-info-silverwind/

I think the difference between the two solution is not big. But for @wxiaoguang 's solution, all the theme meta info will be under a private namespace gitea-theme-meta-info which is better than putting them in a public :root namespace to avoid mistake usage.

Why not some form of parse-able frontmatter contained within a defined CSS comment? (Perhaps I missed some prior discussion. Sorry if so.)
/** gitea-meta
display-name: Dark
**/

and parse it as YAML (or JSON, INI, etc.)

Why not some form of parse-able frontmatter contained within a defined CSS comment? (Perhaps I missed some prior discussion. Sorry if so.)

Because may frontend compilers remove all the comments.

I have no real preference between the two proposed solutions.
I don't love magical CSS being parsed/scraped for metadata. I don't want to "concern stall" this PR into the ground, though, so if no one else has similar concerns I will leave it at that.

I still want it in :root. One usage example might be if the theme wants to display it's name in the footer. This is impossible with that non-existant selector:
footer .left-links:after {
  content: var(--theme-name);
}

I still want it in :root. One usage example might be if the theme wants to display it's name in the footer. This is impossible with that non-existant selector:
footer .left-links::after {
  content: var(--theme-name);
}

As CSS gets more advanced, more such use cases will arise and we are blocking us out of them by making the variables unavailable to CSS.
I find it insane that we declare variables that are out of variable scope. It's like a unused variable.

I have also explained the problem above: it is absolutely an abuse. The "display name" should be prepared by backend code and provided by data-theme-display-name=xxxx, but not directly read by JS/CSS.

I guess I won't block any more because the changes are needed for later work, but I won't approve it either until it's changed to use :root.

Another we should just put put it into a "legal comment" block at the start, arguably better then a CSS block that never matches anything.
/*!
name: Theme
url: https://gitea.com/my/theme
*/
```

Another we should just put put it into a "legal comment" block at the start, arguably better then a CSS block that never matches anything.
/*!
name: My Theme
url: https://gitea.com/my/theme
*/

Or even simpler:
/*! My Theme - https://gitea.com/my/theme */

I agree
But https://github.com/go-gitea/gitea/pull/30671#issuecomment-2096448914

Why not some form of parse-able frontmatter contained within a defined CSS comment? (Perhaps I missed some prior discussion. Sorry if so.)

Because many frontend compilers remove all the comments.

By putting a ! first character into a comment, it becomes a legal comment which by default many minifiers retain in the output.

Why not some form of parse-able frontmatter contained within a defined CSS comment? (Perhaps I missed some prior discussion. Sorry if so.)

Because many frontend compilers remove all the comments.

By putting a ! first character into a comment, it becomes a legal comment which by default many minifiers retain in the output.

Then it sill needs some "tag" to help the locate the comment block.
Does this look good to you? Or other ideas?
/*!gitea-theme-meta-info
theme-name: My Theme
*/

@wxiaoguang I think this proposal looks good, and it would solve the remaining criticism, could you update the PR?

I'm sorry the documentation changes need to be sent to https://gitea.com/gitea/docs


ntr: cellular detoxification of flouride

From @ValWood on October 20, 2017 9:40
standard def
Any process carried out at the cellular level that reduces or removes the toxicity of a flouride. These may include transport of flouride away from sensitive areas and to compartments or complexes whose purpose is sequestration of the toxic substance.
does this also include "export"? this isn't clear from the standard def?
"Therefore, fluoride is toxic for S. pombe even at low concentrations, and specific channels that export fluoride ions are required for normal growth."
Copied from original issue: geneontology/go-annotation#1665

From @ValWood on October 20, 2017 9:40
PMID:27327046


Textarea formatting issue

Problem
textarea tag gets wrapped incorrectly.
Environment
vscode - 1.67.2
vscode-blade-formatter - 0.14.3
OS: Pop!_OS 22.04 LTS x86_64
Settings
"bladeFormatter.format.sortTailwindcssClasses": true,
"bladeFormatter.format.wrapLineLength": 100,
"bladeFormatter.format.wrapAttributes": "force-expand-multiline",
"bladeFormatter.format.indentSize": 2

Attached

Thanks @MBM1607
It's similar to https://github.com/shufo/vscode-blade-formatter/issues/414

Fixed at https://github.com/shufo/vscode-blade-formatter/releases/tag/v0.14.6

I finally got around to check this and its working like a charm now. Thank you so much @shufo .


No implementation found for method listen on channel PonnamKarthik/flutter_youtube_stream

nothing happens while click the button

Same problem occurred to me, but if I try the example project it works fine, I don't know why.

So what I did was download de zip project, named the folder as flutter_youtube and put it at the same level of pubspec.yaml, and changed the pubspec.yaml lines to this way.


Can't use other locales, always uses english

Hi,
I wanted to use another locales so I've tried all the ways I could find on the documentation, but the results were only given in english.
I've tried to define a default locale with the following code:
(this is the only code I have in my application.js route file)
import Ember from 'ember';
import moment from 'moment';

export default Ember.Route.extend({
	beforeModel() {
		moment.locale('pt');
	}
});

And this:
{{moment-from-now my_date locale="pt"}}

And I'm getting this warning in the js console, although I don't think this is related, but here it is:
ember-moment: an empty value (null, undefined, or "") was passed to moment-format

https://github.com/stefanpenner/ember-moment#globally-set-locale is how you change the locale

This is my code now, still getting results in english
import Ember from 'ember';
import config from '../config/environment';

export default Ember.Route.extend({
	moment: Ember.inject.service(),
	beforeModel() {
		this.get('moment').changeLocale('fr');
	}
});

Push an example app with the issue isolated to github.

I have the same problem @ptraceur, did you solve it?

The easiest/quickest way for me to solve these is if I can reproduce it, so if you can throw together a quick dummy app with the bug I can take a look.  FYI, most of the time I've encountered this issue is when another addon also app.imports moment and there for momentjs gets bundled twice.

Also,  @chamoysvoice and @ptraceur be sure to read https://github.com/stefanpenner/ember-moment#cherry-pick-locales-optimal if you already haven't since you did not mention adding the locales to config/environment.

Having the same problem, everything works if I build production version, in dev I only see en locale

@xomaczar likely one of your dependencies is including moment.
Also see https://github.com/stefanpenner/ember-moment/issues/132

Can we add some verbiage to README.md?

I'd happily review any PR around this since it seems to continue to surface.


release build is not working

Current Behavior

I'm currently facing some issue with the latest haul & react native in RELEASE BUILD.
Please find the attached to understand the issue better.
I followed through the documentation and I managed to run the application in DEBUG BUILD.
You can reproduce the issue here: https://github.com/lavaxun/haul-issue.
HOWEVER it's not working well in the release build.
I changed the 'scheme' in xcode to be using 'Release' and clicked the 'Run'.
Screenshot below shows the error.
As you can see the build phase is using CLI_PATH. And it's giving a long list of errors when executing the bundling script during the build phase. (but the app can still be started despite of the build errors)
When I try to use 'fetch' to perform HTTP POST. it shows me 'unsupported bodyinit type' error.

Another screenshot below shows the bundling script is working fine in the build phase. but without specifying CLI_PATH.
And there is no problem in using 'fetch' to do HTTP POST.

Expected Behavior

The RELEASE build should be executed without errors. It should work just like the second screenshot above but with CLI_PATH.
Haul Configuration (haul.config.js)

import { createWebpackConfig } from "haul";

export default {
  webpack: createWebpackConfig(({ platform }) => ({
    entry: `./index.js`
  }))
};

Your Environment

software
version

Haul
1.0.0-rc.9

react-native
0.57.2

react-native-navigation
1.1.491

node
8.11.4

yarn
1.10.1

1

+1

Hi, I'm facing the same issue as well with the latest React Native version and Haul on Android. I'm able to run release build but I get this unsupported BodyInit type error while debug mode is working properly.

+1

Would be great if somebody created a repo with a repro and investigate.

@thymikee
I have made a repo here https://github.com/lavaxun/haul-issue.
would be great if someone can help to investigate it.

Did some quick hacks and managed to fix the issue here!
https://github.com/lavaxun/haul/commit/f112dc0b832242856d2d65d20beb30b231fd971b
Hope someone can send a proper PR to fix this issue.
Context:
I suspect this has got to do with polyfill and hence started to zoom down to the src/utils/polyfillEnvironment.js.
Then I figured out there was a previous issue on the global fetch at https://github.com/callstack/haul/issues/146
And there is a PR https://github.com/callstack/haul/pull/74 addresses this problem.

I have made a PR https://github.com/callstack/haul/pull/494 to fix the issue using webpack banner.


[refactor-prompt] Migrate command: wallet import token

What current issue(s) does this address, or what feature is it adding?
#623
Migrate the command wallet import token to the new Command system.
How did you solve this problem?
Implementation of CommandWalletImportToken
How did you make sure your solution works?
unit tests & manual testing
Are there any special changes in the code that we should be aware of?
No
Please check the following, if applicable:

[x] Did you add any tests?
[x] Did you run make lint?
[x] Did you run make test?
[x] Are you making a PR to a feature branch or development rather than master?
[ ] Did you add an entry to CHANGELOG.rst? (if not, please do)

Coverage increased (+0.04%) to 85.973% when pulling b54648a5552f8ded02b98ddccf95b1a23560f640 on LysanderGG:wallet-import-token into 53c4eece99d6a24389e0c5ab095acc3d629ec9f6 on CityOfZion:refactor-prompt.

Needs conflict resolving.

Needs conflict resolving.

@ixje Done!

great! with this just 1 more group to go I think 💯


Test on iOS

Definition of done

[ ] Tonomy ID is successfully run locally iOS device

Cutoff 6 hours and then stop

Issue when running. It was solved by running app in linux, not Mac OS:
https://discord.com/channels/1029385699071381524/1039498885598552065/1060494250363588618


Graphing mode disabled sometimes

Describe the bug
Graphing mode is not available sometimes when starting calculator. Restarting fixes it.
Steps To Reproduce
Open calculator, try to go to graphing mode, button is inactive. Seems to happen randomly.
Expected behavior
Should be always available.
Screenshots

Device and Application Information

OS Build: Windows 10 21H2 19044.2364
Architecture: x86_64
Application Version: 11.2210.0.0
Region: ru-RU
Dev Version Installed: No

Requested Assignment
I'm just reporting this problem.  I don't want to fix it.

I reproed this issue as well.

I just experienced the same issue. I opened Calculator, and the "Graphing" menu item was disabled. I closed and re-opened Calculator, and "Graphing" was enabled.
Edition: Windows 10 Enterprise
Version: 22H2
OS build: 19045.2486
Experience: Windows Feature Experience Pack 120.2212.4190.0
Architecture: x86_64
Application Version: 11.2210.0.0
Region: en-US
Dev Version Installed: No

Got this too.
Windows: Windows 10 Education 21H1, Build 19043.2364, Windows Feature Experience Pack 120.2212.4190.0
Hardware: 64-bit operating system, x64-based processor
Calculator: Calculator 11.2210.0.0

Sometimes restarting calculator fixes it, but sometimes, i have to restart my computer.

Same issue here. I don't restart my computer, I just wait 'till it's back up and use desmos.com in the meantime :)


Update index.d.ts

error TS7010: 'protect', which lacks return-type annotation, implicitly has an 'any' return type

it is not a void:
https://github.com/exceljs/exceljs/blob/f50693b344c938d4384208a9ead8bdfa9da17600/lib/doc/worksheet.js#L593

@cosmonovallc could you amend this PR to include the right return type?


Forge2D docs link in README dead (404)

https://flame-engine.org/docs/forge2d.md points to a non-existent page. Where can I find the documentation for Forge2D?

It is slightly outdated, but here are the docs:
https://flame-engine.org/docs/box2d.md
(Replace all the box2d with forge2d)
We are updating all of them at the moment so soon they should get an update.

Should work now on the new site:
https://flame-engine.org/docs/#/docs/forge2d


thaumcraft support for voidmetal and steam heaters

please add void metal plates as option for the exosuit. suggested traits would be the same vis discount as thaumium with a slightly higher armor bonus to the exosuit, and the addition of warping 1, to the armor piece the plate is attached to.
in case the exosuit gets durability, the plates would rather add auto repair and a bit of armor, plus warping 1.
as for the steam heaters, it would be nice if they were able to heat up alchemical furnaces, so steam powered thaumcraft systems are possible.
EDIT BY SANTA:
In case these features get accepted:

[ ] Steam Heater -> Alchemical Furnace support
[ ] Void Exo Plates

Whoever checked those check-boxes needs a slap (probably me)


⚠ wakapi has degraded performance

In 33bc277, wakapi (https://waka.mcha.cloud/api/health) experienced degraded performance:

HTTP code: 503
Response time: 15422 ms

Resolved: wakapi performance has improved in f76e161 after 34 minutes.


Empty line no longer added to start of strings files on sort

As discussed in #178 - when normalising and sortByKeys = true, BartyCrouch adds a new line to the start of every strings file. This PR resolves this issue.

@hactar Noticed one more thing: You've added a . at the end of your commit message. Would you be up to fix that quickly by doing a rebase? If not, I can also merge as is, it's not a big deal.

Sorry bout that, but I'm afraid that goes beyond the scope of things I can quickly do via git.

Ok, sure, no worries. Merging, thank you! 🎉


Improve Cassandra deployment for Kubernetes / OpenShift

During the initial Docker/Kubernetes/OpenShift , we took some shortcuts regarding Cassandra and they need to be sorted out.
Points to solve:

[x] Use a more appropriate Cassandra Docker image
[ ] Wrap the Docker entry point to run a nodetool drain on shutdown, as suggested by @jsanda
[ ] Figure out the best approach regarding the replication strategy and datacenter configuration

fixed issue for replication strategy https://github.com/jaegertracing/jaeger-kubernetes/issues/15

nodetool drain  in hawkular-metrics
https://github.com/openshift/origin-metrics/blob/master/cassandra/cassandra-prestop.sh
https://github.com/openshift/openshift-ansible/blob/master/roles/openshift_metrics/templates/hawkular_cassandra_rc.j2#L114-L123

@jpkrohling I think this can be closed
nodetool drain https://github.com/jaegertracing/jaeger-kubernetes/pull/21 and https://github.com/jaegertracing/jaeger-openshift/pull/27
Configuration for replication factor is already in master.


remove route option from component settings

Fixes
https://issues.redhat.com/browse/HAC-2933
Description
Removes the option to change the route.
Right now the option doesn't function as expected. The decision was made to remove this option altogether for now.
Type of change

[ ] Feature
[x] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Screen shots / Gifs for design review
wizard:

settings form:

Browser conformance:

[x] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

/lgtm


[Feature request]: Verify Flatpak on Flathub

Version

[X] I'm using version 1.14.0

Existing requests

[X] I've checked Existing requests

Advanced Preferences

[X] I've checked Advanced Preferences

What operating system are you using?
Linux
Operating System Version
Fedora Silverblue 38
Problem description
There's a new Flathub website where it is possible mark apps as verified. This is described in the new About page.
Possible solution
@hovancik, if you login to the Flathub website with your GitHub account, it should automatically associate the Stretchly Flatpak with your account. You can then follow the instructions in the Developer Settings page for Stretchly to perform Website verification.
Alternative solutions
N/A
Additional information
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

:+1:


VSCode slow and crashes - Python and Jupyter Notebooks

Type: Performance Issue
Hi,
When working with large Python Notebook files and restart the kernel, it takes way too long to do so and most often than not it crashes. When opening VSCode again, all the workspaces/folders are closed and have to open them again.
Also regarding Python + Jupyter, doing some quick benchmarking between VSCode and JupyterLab (or Notebook), VSCode feels like a snail. It takes forever to run, i.e. generating the same graph in VSCode takes sometimes 66s and in Jupyter takes 30s, half the time hence making us work double the time (if you take that in perspective).
When I began using VSCode for Jupyter it was a breeze because it was almost as fast as Jupyter, but it has been decreasing in performance over time, especially with the latest release. I know you work hard to keep it updated and for integrating new features, but with the latest release everything just went mental and it has become almost impossible to use it.
Thanks
Best
VS Code version: Code 1.87.1 (1e790d77f81672c49be070e04474901747115651, 2024-03-06T00:22:39.156Z)
OS version: Darwin arm64 23.3.0
Modes:

System Info

Item
Value

CPUs
Apple M1 Pro (10 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
3, 3, 2

Memory (System)
16.00GB (0.08GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (9)

Extension
Author (truncated)
Version

black-formatter
ms-
2024.0.1

debugpy
ms-
2024.2.0

python
ms-
2024.2.1

vscode-pylance
ms-
2024.2.3

jupyter
ms-
2024.2.0

jupyter-keymap
ms-
1.1.2

jupyter-renderers
ms-
1.0.17

vscode-jupyter-cell-tags
ms-
0.1.8

vscode-jupyter-slideshow
ms-
0.1.5

(1 theme extensions excluded)

@kburchfiel @paul-rogers
If you too are running into this, please can you disable all extensions except, Jupyter and Python and verify you are still running into this. If yes, please create a new issue.
@ale-dg thanks for identifying the fact that it was the Pylance extension

HI @DonJayamanne,
No problem. Glad I could help. I am having a nice talk with the Pylance team here https://github.com/microsoft/pylance-release/issues/5614, though I had to downgrade a lot of versions of all the tools (VSCode, Jupyter, Pylance) to be able to work smoothly. So, if I may suggest something, I wouldn't discard a memory leak in the Jupyter extension as sometimes it also utilises a lot of threads when running.
Thanks for your help.
Best

discard a memory leak in the Jupyter extension as sometimes it also utilises a lot of threads

Jupyter extension doesn't start any threads.
Perhaps the perf issues are from Python process spawned for the kernel, the Python processes start threads/sub processes.

Hi @DonJayamanne, thank you for your response! I continued to experience performance issues after disabling Pylance and all other extensions (except for Juptyer and Python), unfortunately. I've also noticed some other odd UI issues; the 'Go To' button is no longer working and the scroll bar sometimes disappears. (I've actually noticed this same 'Go To' disappearance within Jupyter Lab; however, my notebook tends to run much more quickly on Jupyter Lab, so I think there's still something within Code that's causing the sluggish behavior).
I saw that there's an update to Code available, so I'll see if that resolves these issues; if not, I'll submit a new bug per your request.
I really do love working in Code and am looking forward to getting these issues resolved!

Hi @DonJayamanne,
Just for the record, I had forgotten this issue, which seems related to the Jupyter extension as well. Another lad also posted the logs there and is experiencing issues: https://github.com/microsoft/vscode-jupyter/issues/14459#issuecomment-1986677050 (and, according to him, he does not have Pylance installed).
Best

Let me repro with the upgraded version as I have downgraded a lot of versions for working further on my project...

@DonJayamanne I have finished without markdown... as I was fixing some issues, it stopped until an error, but went smoothly. Now I am running the one with markdown and the main difference has been that it took longer to start-up and the number of cells are increasing (and the computer went a bit hot).
As per your request, I'll share the log files in the other comment.
Best

@ale-dg In summary, having markdown cells slows execution, is that right?

Yes, but consider I did not use Pylance. Would you like me to test with it? I just activated it and opened the log trace for python and just for indexing it finishes its memory.
2024-03-13 17:51:01.092 [info] [Info  - 17:51:01] (4192) Heap stats: total_heap_size=1220MB, used_heap_size=1156MB, total_physical_size=1218MB, total_available_size=2900MB, heap_size_limit=4096MB
2024-03-13 17:51:01.108 [info] [Warn  - 17:51:01] (4192) Workspace indexing has hit its upper limit: 2000 files

Great, lets create a new issue as you seem to be running into issues with Pylance,
I'd like to ensure we isolate the problems and resolve them one by one,
there could be number of issues that contribute to this poor user ex and I'd like to get them all resolved, hence the focus on creating separate issues (to resolve them individually)


EvmError: OutOfGas with combination: vm.pauseGasMetering(), vm.rollFork()

Component
Forge, Anvil
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (9b1fe58 2022-12-08T00:15:07.729566Z)
What command(s) is the bug in?
forge script scripts/GMXHistoricalJSON.s.sol
Operating System
macOS (Intel)
Describe the bug
After applying the vm.pauseGasMetering() and using together with vm.rollFork() I get error right after any contract call, example of the trace:
Traces:
  [2971690] → new GMXHistorical@0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496
    ├─ [0] VM::envUint(START) [staticcall]
    │   └─ ← <env var value>
    ├─ [0] VM::envUint(END) [staticcall]
    │   └─ ← <env var value>
    ├─ [0] VM::envUint(INTERVAL) [staticcall]
    │   └─ ← <env var value>
    ├─ [0] VM::envString(NETWORK) [staticcall]
    │   └─ ← <env var value>
    └─ ← 14266 bytes of code

  [9223372036854775807] GMXHistorical::run()
    ├─ [0] VM::rpcUrl(avax) [staticcall]
    │   └─ ← https://api.avax.network/ext/bc/C/rpc
    ├─ [0] VM::createSelectFork(https://api.avax.network/ext/bc/C/rpc, 22968009)
    │   └─ ← 0
    ├─ [0] VM::rollFork(22968010)
    │   └─ ← ()
    ├─ [0] VM::pauseGasMetering()
    │   └─ ← ()
    ├─ [464448] 0x9ab2De34A33fB459b538c43f251eB825645e8595::allWhitelistedTokensLength() [staticcall]
    │   └─ ← 0x0000000000000000000000000000000000000000000000000000000000000007
    └─ ← "EvmError: OutOfGas"

Gas used:<PHONE_NUMBER>854775807
Error:
Script failed.

thanks for narrowing it down. looking into this

Hm seems like pauseGasMetering may not be working when used with vm.writeFile. I've got a loop which writes many files, but I get an out of gas error from that loop even when using pauseGasMetering

this is actually a out of memory issue. see #3971. solidity doesn't reuse the memory in a loop so you hit the memory expansion limit


"ID" column in job history doesnt sort correctly

Describe the Issue
ID is the default sort column, but it doesn't sort right.
Screenshots

Script Sample
Attempt to attach sample code that will allow others to reproduce the issue. NOTE: Generally speaking this is the MOST EFFECTIVE way to have your issue resolved.
Version Information

Host Operating System: 2019
Host PowerShell Version:5.1
Universal Automation Version: latest
Universal Dashboard Version: 2.7
UD Hosting Method: (Powershell, IIS, App Service, Etc.)

Just found this myself. Looks like it's sorting as a string instead of an int.

Yeah, looks like the ID is a string:

I think this example is taken in build 2502.


Sort unstructured boundary conditions

Improve the performance and type stability of the calc_boundary_flux of the unstructured solver. Addresses part of #542

Looks already quite good. Just a minor comment and we can merge it from my side.
A general comment: Please consider using the GitHub feature to apply proposed changes directly. You would have saved both of us quite some time by doing that for #570 (comment) where I already fixed the problematic allocations I fixed in 875ad6c

Okay, I will start using this feature. I used to like and combine the changes into a single commit to avoid cluttering the git log. But now that we use squash merge for PRs this is no longer an issue

Okay, I will start using this feature. I used to like and combine the changes into a single commit to avoid cluttering the git log. But now that we use squash merge for PRs this is no longer an issue

You can go to the "Files changed" section at the top and select something like "Add suggestion to batch" for all of them. Then, you can commit them in one batch/commit.

You can go to the "Files changed" section at the top and select something like "Add suggestion to batch" for all of them. Then, you can commit them in one batch/commit.

Good to know. I will make sure I use this in the future

The changes in this PR seem to add some more complexity. How does the performance compare to the stuff benchmarked by @ranocha in #573?

It actually improves the performance, according to some benchmarks shown to me by @andrewwinters5000

The high-level overview: The first version implemented by @andrewwinters5000 payed the price of dynamic (runtime) dispatch (type instability) for every node on every boundary when at least two different BCs were used. My PR reduced that to runtime dispatch once per boundary. This PR fixed the underlying type instability completely, removing the cost of dynamic dispatch.

I'm still surprised though that you can see the difference between the second and third versions. Intuitively, I would've thought this should be negligible.

I'm still surprised though that you can see the difference between the second and third versions. Intuitively, I would've thought this should be negligible.

It had less impact, that's true. A bigger performance improvement came from

A general comment: Please consider using the GitHub feature to apply proposed changes directly. You would have saved both of us quite some time by doing that for #570 (comment) where I already fixed the problematic allocations I fixed in 875ad6c

Nevertheless, I think it's good to avoid type instabilities and train people to get used to some of these design choices.


Fix Country.byId performance

The lookup of a Country byId is pretty slow when having to do repeated lookups. This PR adds direct lookup by key which greatly boosts performance.
Testcase:
const start = Date.now();
for (let i = 0; i < 100000; i++) {
  Country.byId('nl');
}
console.debug('Country.byId took', Date.now() - start, 'ms');

before: Country.byId took 16413 ms
after: Country.byId took 8 ms

Thank you for looking into this, was on our todo list for a while.
We decided to improve the underlying methods byId and byIds in the Enum class so that all big Enum (like Locale) have a fast byId lookup. See https://github.com/thisisagile/easy/releases/tag/v14.0.0
This was a breaking change because we no longer use the equals function in byId and byIds which causes the Country and Locale to no longer support fuzzy id's (like NL vs nl or nl_NL vs nl-NL). We instead created a lookup function that does the fuzzy id search


[MRESOLVER-104] - maven-resolver-demo-maven-plugin uses reserved artifactId

https://issues.apache.org/jira/browse/MRESOLVER-104
[INFO] — maven-plugin-plugin:3.5.2:descriptor (default-descriptor) @ maven-resolver-demo-maven-plugin —
[ERROR]

Artifact Ids of the format maven-___-plugin are reserved for
plugins in the Group Id org.apache.maven.plugins
Please change your artifactId to the format ___-maven-plugin
In the future this error will break the build.

Removed maven- prefix, because it's reserved by specific group ids

I have applied a minimal version of the patch because only the artifact id is problematic and it is a demo after all.


Fix typos in README.md

Just a couple of typo fixes.
Hope you're having a great day! :)

Hello @ivuk thank you very much for the fixes and welcome to drive! LGTM, merging!


Ledger Nano S - Could not sign TX & display sending/receiving address

Hi,
Ledger Nano S Firmware 2.1.0
Bitcoin Version on it: 2.0.4
Error message, when trying to display the Receiving address:
('0x6a80', 'Error in <BitcoinInsTzpe.GET_WALLET_ADRESS: 3> COMMAND', ")
Could not find anything in Log file.
Thanks for reply.
Jiri

The same problem with Signing the Sending address:
('0x6a80', 'Error in <BitcoinInsType.SIGN_PSBT: 4> command', ")

Thanks, duplicate of #553.


Fail on duplicate mapping

Is there a way to make whick-key.nvim fail when you accidentally define the same mapping twice?
I sometimes forget I have some sequence of keys mapped to something, and then map something else to the same sequence of keys. I'm looking for something to help protect me from my own forgetfulness 😅

Nope, but you can run :checkhealth to see if there's duplicates 🙂

Ooh, that's nice, but it still requires me to go look there 😅. I'm looking for something with faster feedback, kind of like vim.tbl_extend("error",...).
Is there perhaps a way to query the state of which-key for a given buffer? Then I could create a little wrapper function around register.
Of course I can write something myself outside of which-key, but it first has all the information, it feels redundant to keep two lists of mappings.

Yep! The duplicates are always calculated, you can check them in the table below:
require("which-key.keys"). duplicates

dups where other has buffer=0, can be ignored, since those are overrides from buffer-local mappings

You could see which ones we show in checkhealth using that table here

Oooh, that's really nice! Thank you!

I tried to get this to work like this:
function M.whichkey_register(mappings)
  require('which-key').register(mappings, { buffer = nil })
  local dups = require('which-key.keys').duplicates
  if #dups > 0 then
    vim.cmd('echoerr "Duplicate mapping detected"')
  end
end

I've called it twice with the same mapping:
whichkey_register({
  [']b'] = { '<cmd>bnext<CR>', 'next' }
})
whichkey_register({
  [']b'] = { '<cmd>echo "yeah"<CR>', 'next' }
})

But it doesn't register the duplication. :checkhealth, however, does:
  - WARNING: buffer-local keymap overriding global for mode **"n"**, buf: 0, lhs: **"]b"**
  - INFO: old rhs: `<cmd>bnext<CR>`
  - INFO: new rhs: `<cmd>echo "yeah"<CR>`

I don't really understand what's going on here. Did I do something wrong? Or does it take a while before the mapping is actually processed?

#dups doesnt work for tables used as dictionaries ;)
#{a=1, b=2} => 0
#{1, 2} => 2

OK, that's my bad, indeed. Thanks for your patience, I'm still a bit new to Lua.
However, it's still not working:
function M.whichkey_register(mappings)
  require('which-key').register(mappings, { buffer = nil })
  local dups = require('which-key.keys').duplicates
  vim.cmd('echom "dup: ' .. vim.inspect(dups) .. '"')
  local count = 0
  for _ in pairs(dups) do
    count = count + 1
  end
  if count > 0 then
    vim.cmd('echoerr "Duplicate mapping detected"')
  end
end

This yields the following output in :messages:
dup: {}
dup: {}

The first one is expected, because that's the first call to the whichkey_register function. But on the second call, I would have expected some content. In fact, when Neovim has started up, if I give a manual `:lua print(vim.inspect(require('which-key.nvim').duplicates)), I do get some output:
{ {
    cmd = '<cmd>echo "yeah"<CR>',
    mode = "n",
    other = {
      buffer = 0,
      expr = 0,
      lhs = "]b",
      lnum = 2,
      mode = "n",
      noremap = 1,
      nowait = 0,
      rhs = "<cmd>bnext<CR>",
      script = 0,
      sid = 30,
      silent = 1
    },
    prefix = "]b"
  } }

Right. That won't work like this, since we automatically lazy load any keybindings. any register is postponed to VimEnter for performance. Registers after that are executed immediately though

OK, now I have an autocmd set up like this:
function M.whichkey_checkduplicates()
  local dups = require('which-key.keys').duplicates
  if vim.tbl_count(dups) > 0 then
    vim.cmd('echoerr "Duplicate mapping detected"')
  end
end

autocmd BufNew * lua require('mappings').whichkey_checkduplicates()

That seems to work. Thanks for your help!


Drag helper in wrong styling context

Since the "drag helper" (the new DOM node added to the end of the  which is the actual element being dragged) is not within the same parent element as the source being dragged, styles have a strong potential of getting messed up on the helper (which may rely on parent context). In other words if I have:

Draggable User

Draggable User

I might depend (in CSS) on a .user-list > .user relationship for styling the
. But when the drag starts, we essentially get...

Draggable User

Draggable User

Draggable User

This can be fixed if it is possible to put the drag-helper node as a sibling to the original thing being dragged instead of at the end of the body. Thoughts?

I see also that this is related to #40, although I don't think all uses of .parent > .child selectors would qualify as "over selecting". I realize there are methodologies out there like BEM which don't encourage any parent-child selectors, and many do inline-styles with React. But there are still many who don't do either of those and there are lots of CSS methodologies in which one uses parent-child selectors in a non-overselecting manner.
If it is possible to place the drag helper somewhere else, you wouldn't have to impose a CSS methodology opinion on a nice JS tool. Or at least make a mention of it in the docs somewhere. Once I realized what the issue was, it was an easy fix, but it did take a while to find the issue.
Also, GREAT JOB on this tool, I love it

Hey @bradwestfall, first off, thanks for the kind words, it's always nice to hear.
A few of the reasons why I originally chose this approach this decision were discussed in #20, though I'd say the main reason was to minimize the chance of conflicts with other libraries.
Having said that, you do raise valid points. I'd be willing to at least entertain the idea of having a configurable parent element for the helper node. Conflicts could still arise though, so it would be a use at your own risk kind of feature and most likely.

Thanks @clauderic. Yea now that I think about it, I can see the potential conflicts with, not only other tools, but what if the developer wants to count DOM nodes in their container, or is using :last-child CSS and now your drag handle is messing with that because it's mixed into the same parent context.
I appreciate the suggestion and you're awesome for wanting to update the API to accomodate edge cases. But honestly, I don't see a lot of value in the configurable parent element helper because it would maybe help for some CSS selectors but not all. I think this is actually more of a general problem of all draggable APIs. Maybe just some mention in the documentation. I probably wouldn't have read it if it weren't smack in the middle of main README (because who reads all the docs before using a tool right), but at least some people will see it and prevent the headache.

Hey @bradwestfall, going to close this one out as I don't want people to think this is a behavior I intend to change, at least for the foreseeable future, and it is now something that is covered in the common pitfalls section thanks to your PR 👍


Ensure the vmservice assets tar is pinned in memory

If it is, we can decode the tar into external strings for filenames, and external typed data arrays for the contents without needing to copy this data.

CC @johnmccutchan


Difficult to identify top scroll bar

Issue Type: Bug
I felt, its difficult to identify top scroll bar & scroll   when files are more in a single VS code window.
VS Code version: Code 1.24.0 (6a6e02cef0f2122ee1469765b704faf5d0e0d859, 2018-06-06T17:35:02.816Z)
OS version: Windows_NT ia32 6.1.7601

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz (4 x 2893)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: unavailable_softwarevideo_decode: enabledvideo_encode: enabledvpx_decode: unavailable_softwarewebgl: enabledwebgl2: enabled

Memory (System)
7.88GB (1.74GB free)

Process Argv
C:\Program Files (x86)\Microsoft VS Code\Code.exe

Screen Reader
no

VM
0%

Extensions (3)

Extension
Author (truncated)
Version

expand-region
let
0.1.2

material-icon-theme
PKi
3.5.0

sort-lines
Tyr
1.7.0

(1 theme extensions excluded)

@itsamy003 I am not sure what you mean, can you perhaps show a screenshot of what is difficult to identify ?

Scroll bar is difficult to identify in the background colour and it’s very
small.
On Wed, 20 Jun 2018 at 2:41 PM, Alexandru Dima<EMAIL_ADDRESS>wrote:

@itsamy003 https://github.com/itsamy003 I am not sure what you mean,
can you perhaps show a screenshot of what is difficult to identify ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/52323#issuecomment-398679930,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEiEd1nCfe7clOBHLMBeiZrey_uogjobks5t-hGlgaJpZM4UtYFN
.

It is possible to install / change to themes which have different colors for the scrollbars.


round trip marketplace template

Right now the template only has a us-east-1 AMI.  We need to get in the habit of round tripping it once AWS inserts the AMIs.

This has been rectified and we will ensure that the 'round-trip' is included in our deployment process from now on.


Add an option to choose the format for the author name

I work with two people with the same last name and can't tell apart in git-blame. Having the ability to choose to display either first name, last name, full name or email address would be great.

Just wrote up #112.
(Showing email addresses/first names only/etc. would be a neat idea. Don't care enough myself to implement it, though.)

@till-varoquaux happy to entertain a PR for this change. Can follow #112 lead.


FYI: LZ4 removed from 5.12.11

The mainline kernel removed LZ4 as an AMD64 build dependency on 5.12.11, and added zstd.
$ git diff cod/mainline/v5.12.10 debian.master/control.stub.in
diff --git a/debian.master/control.stub.in b/debian.master/control.stub.in
index c8bc555da0f6..01cd82721efd 100644
--- a/debian.master/control.stub.in
+++ b/debian.master/control.stub.in
@@ -37,7 +37,8 @@ Build-Depends:
  libnuma-dev [amd64 arm64 ppc64el s390x] <!stage1>,
  dkms <!stage1>,
  curl <!stage1>,
- lz4 [amd64 s390x] <!stage1>,
+ lz4 [s390x] <!stage1>,
+ zstd [amd64] <!stage1>,
  dwarves [amd64 arm64 armhf ppc64el s390x] <!stage1>,
 Build-Depends-Indep:
  xmlto <!stage1>,

However the kernel config file is still set to use LZ4 compression.
$ grep -i lz4 debian.master/config/amd64/config.common.amd64
CONFIG_KERNEL_LZ4=y
CONFIG_LZ4HC_COMPRESS=y
CONFIG_LZ4_COMPRESS=y

It looks like mainline may be intending to switch to zstd compression on amd64, so I've not opened a bug on launchpad.
The build.sh script now checks for LZ4 in the kernel config and re-adds the dependency.
Fix: 3435a1d0dc78693557fd41510f3e94a8de0392ef
When/if mainline switch to zstd we should automatically stop adding the dependency.

5.12.14 and 5.13 are now using ZSTD. Closing.


Implemented capture device selection for PulseAudio

Note: Older PulseAudio seem to be buggy with this, but works with pulseaudio >= 11.1

@marcelofg55 I'll try and merge this shortly, but I've actually encountered some other problems while I was rebasing to make things compatible with the new interface for writing data to vectors. I don't know if this slipped me by, but it looks (#b2bd521ff8d2d24ca0e70df1a8b835197aef2d2d) might have reintroduced the microphone clipping issue which was solved before, at least when I tested it under WASAPI. I narrowed down the problem to appearing in that specific commit, but I have no idea what's causing it.
Secondly, when using the device selection, it seems there is lacking functionality to resample between input devices with differing sample rates. For example, my main microphone is set to a 44100hz, while the Oculus Rift internal microphone is 48000hz, and as such, comes out sounding very high pitched. I believe I accounted for this in my initial code, but it seems to be non-functional here.

Can you test with the Oculus Rift mic set to 44100Hz ? Does that fixes the clipping issue?

@marcelofg55 Give me second...

@marcelofg55 Okay, so I wasn't actually able to change the microphone settings on the Rift, they are locked to one setting (1 channel, 16bit, 48000hz). However, I did try to change my normal mic to match those settings and wasn't able to recreate the high pitch problem. The only thing I wasn't able to set was the microphone to a single channel; all the settings are locked to two channels.
One other thing I noticed though is that after changing the sample rate on my main microphone, the clipping problems would mostly go away, but changing the audio device mid use would seem to randomly introduce the clipping at seemingly completely arbitrary levels of severity. What's concerning about this is I can't discern a consistent pattern behind this behavior.

Let me fix the rate issue, I've figured out the problem with it.

@marcelofg55 Awesome! 👍

Does the last commit help?

@marcelofg55 I'm actually rebasing it at the moment since there was a very recent change to the vector array class.

@marcelofg55 Well, I tested it, but it doesn't seem to have made any difference. Clipping is still present and the Rift mic is still high pitched :/

@marcelofg55 By the way, do you think it would be possible to rebase onto the latest master and pull again? Our branches are currently out of sync. The only really change is that now all the vectors now include .write when writing data.

Yeah, should I rebase it? I'm not that good rebasing :P

What I would suggest is making a backup copy of your current audio_mic branch, delete the original, update your master branch, then pull this branch again.

Let me try..

@marcelofg55 Also, once you've done that, you can pull this PR again to get a rebased version of these recent changes too. That said, wait a moment since I made a very minor error with them.

@marcelofg55 Okay, should be all good now to pull the rebased commits from this PR too.

@marcelofg55 Sorry, I might have made it more complicated than it needs to be. You should just now be able to just backup your branch, update the master branch, and then pull everything back from your audio_mic_mf branch on your Github page since I already rebased it.

Hopefully it will be easier to narrow down these problems once we've ensured that we're both running the exact same code.

I've just merged it, can it be merged like this?

If it's working with the latest version of the original master branch, then it's fine. To confirm everything's okay, the latest commit should just be a minor fix to a mistake involve indentation.

I've just checked the "Files Changes" tab on github and it seems okay.

@marcelofg55 Okay, so assuming everything is up to date, you should be fine. That said, the issues with clipping and pitch still remain, but it should now be a lot less hassle to work through these.

@marcelofg55 Just so you know, I managed to fix the Oculus Rift microphone issue in WASAPI. Basically, it was all down to the fact that the Rift only supports one channel; one of your commits removed the handling in WASAPI for single channel capture streams so I put it back in now it is the correct pitch.
However, I have not yet managed to solve the reintroduced clipping issues. The only thing I can confirm is that the regression with the commit from this PR (#1 ), which broke your clipping fixes from the previous commit. I'm going to give it a rest for now, but so far I've only managed to look for two potential changes: the shift from floats to integers for the audio input buffer, and some changes to how the AudioStreamMicrophone interprets that buffer. Since you managed to fix the clipping before, if you can, try look over what could have changed in that commit which broke the previous fix.

@marcelofg55 Good news, I think I've solved the clipping bug too (at least in WASAPI). The bug was actually caused by a couple of things which were broken in your single microphone receiver revision, including bounds checking to ensure that the stream didn't to read beyond an amount of data which has been filled in the buffer, as well as getting the arguments in the Initialize method for the AudioClient being in the wrong order, making it so that the capture buffer was too small. I also changed the stream's mixer function to make it so that the offset gets reverted back to the beginning if it the requested frames overflows whats available, which seems to handle device switching (however, clipping still occurs if the default device is changed; is there a callback for this?)
You will probably to add the bounds measurements back in for PulseAudio and CoreAudio too, but it should be pretty straightforward. Just take note of the latest commit.

Nice work @SaracenOne !
Can you merge this first? And then I'll re-sync my branch and update the other drivers.

@marcelofg55 Sure thing. I just need to make sure this isn't merging more commit than necessary, in which case I might merge the commit from my end on the desktop then rather through Github.

@marcelofg55 One problem I'm having with the mix rate commit is that it's introducing major latency into the audio capture. I need some more time to understand why it's doing that.

@marcelofg55 Okay, so since this branch seems to have had some rebasing problems, I went and committed your PulseAudio commit manually. It should be in the main branch now. I didn't merge your changes for mix rate though for the aforementioned de-sync issues, but on the other hand, it seems to work fine without them.
Due to the fact that this branch seems to have been rebased badly, my advice would just be to now create another branch based on my default audio_mic branch again to ensure everything is synced up correctly. It's already cleaned up and rebased onto the latest master. If you can add the same fixes I added to the WASAPI driver to fix single channel microphones and audio clipping, I could probably then petition to get this thing merged 👍

Alright, I'm on it :)


Change Country of Origin input tag to a Picker

Country of Origin field in the registration is just an input box but should be a picker so to make sure that the input is sanitized. The picker should be populated with a list of all countries in the world.

Done


Initialize .comply.yaml file with minimal information

This PR creates the initial .comply.yaml file. This file will make it easier for us to see who owns this repository.
We've created a Slack command so that you can easily check this right from your conversations. To see this in action, fill in the file details and merge the PR. Then go to Slack and type '/repo {repo-name}' and be amazed

+1


"Error with PGs, check config" on ubuntu-xenial

The error
Trying to setup ceph on a ceph/ubuntu-xenial box, I ran into the following error:
RUNNING HANDLER [ceph.ceph-common : restart ceph osds daemon(s)] ***************
fatal: [osd1]: FAILED! => {"changed": true, "cmd": ["/tmp/restart_osd_daemon.sh"], "delta": "0:20:11.467822", "end": "2017-04-23 13:00:01.293471", "failed": true, "rc": 1, "start": "2017-04-23 12:39:49.825649", "stderr": "", "stdout": "Error with PGs, check config", "stdout_lines": ["Error with PGs, check config"], "warnings": []}
fatal: [osd0]: FAILED! => {"changed": true, "cmd": ["/tmp/restart_osd_daemon.sh"], "delta": "0:20:11.648671", "end": "2017-04-23 13:00:01.513573", "failed": true, "rc": 1, "start": "2017-04-23 12:39:49.864902", "stderr": "", "stdout": "Error with PGs, check config", "stdout_lines": ["Error with PGs, check config"], "warnings": []}

I don't know what "PGs" refers to, so I don't know how to interpret the error message.
Steps to reproduce
Here are the steps I followed before getting this error (I am running macOS Sierra, with ansible and vagrant installed via Homebrew):

I cloned the repository https://github.com/ceph/ceph-ansible.git.

I copied vagrant_variables.yml.sample, site.yml.sample, and group_vars/all.yml.sample to vagrant_variables.yml, site.yml, and group_vars/all.yml, respectively, making the following changes:

$ diff vagrant_variables.yml{.sample,}
7,8c7,8
< mon_vms: 3
< osd_vms: 3
---
> mon_vms: 1
> osd_vms: 2
55c55
< vagrant_sync_dir: /home/vagrant/sync
---
> # vagrant_sync_dir: /home/vagrant/sync

$ diff group_vars/all.yml{.sample,}
80,84c80,84
< #debian_ceph_packages:
< #  - ceph
< #  - ceph-common    #|--> yes, they are already all dependencies from 'ceph'
< #  - ceph-fs-common #|--> however while proceding to rolling upgrades and the 'ceph' package upgrade
< #  - ceph-fuse      #|--> they don't get update so we need to force them
---
> debian_ceph_packages:
>  - ceph
>  - ceph-common    #|--> yes, they are already all dependencies from 'ceph'
>  # - ceph-fs-common #|--> however while proceding to rolling upgrades and the 'ceph' package upgrade
>  - ceph-fuse      #|--> they don't get update so we need to force them
91c91
< #ceph_origin: 'upstream' # or 'distro' or 'local'
---
> ceph_origin: 'upstream' # or 'distro' or 'local'
114c114
< #ceph_stable: false # use ceph stable branch
---
> ceph_stable: true # use ceph stable branch

(I was getting an error telling me to "choose an upstream installation source" before making the above change to all.yml.)

I ran

vagrant up --no-provision --provider=virtualbox
Note that I had to run vagrant plugin install vagrant-vbguest to make this work (I was getting an error saying that "the "vboxsf" file system is not available." otherwise).

I ran

vagrant provision
This got pretty far before failing with the "Error with PGs, check config" message.

Hmm, I tried from scratch and it worked this time.  Weird.


Create args_helloworld.py

What does the program do ?
Say "Hello World", "Bye World" or "Hey World" depending on the args specified.

In what programming language it is written?
Python 3.x

Thank you for participating  in hacktoberfest ❣ if you liked working on this repo you can share it with friends and star this project for helping others


better means of defining provider-specific errors

For instance, if a required bin is missing.
This can include simple steps to resolve / auto-resolve.

No longer applicable


https port

If you're running site user https and you don't specify port setting, but specify address setting, in other words something like:
http-server -a static.site.ca -S --cert=site.cert --key=site.key

then http-server will use default port - 8080. That means that you'll only be able to load your site if you explicitly specify port in browser: https://static.site.ca:8080. If you would like to be able to access your site using just address: https://static.site.ca, then don't forget to set port to default value which browsers use: 443.
http-server -p 443 -a static.site.ca -S --cert=site.cert --key=site.key

It would be nice if http-server can do that out of the box.

One of the reasons why small adhoc HTTP servers don't do this is because you need sudo to listen on a port below 1000.

I see, thanks.


Crashes on launch

yarn dev just causes crashes
msg="preparing execution context failed: setting up global config failed: cannot get home directory: exec: "sh": executable file not found in $PATH"

@vlance11 Sorry this slipped by me!
I can tell the error is coming from the Hasura service..
What is the full console output?
What happens if you try to manually run the docker run command shown in output? (Starts with docker run --name hnme_hasura_1)
If you get the same error, does any variation of that command work?


Firmware fetch timeout

For people with slow connections, downloading the firmware may cause a timeout and display an error.
Workaround:
Click the button multiple times until it works. This causes the browser to cache the chunks of the file it receives until the whole file is transferred and cached.

Reported in 1.0.5

Fixed in https://github.com/Digilent/waveforms-live/commit/6d9a2ba27e1333cd929b5cd05c58efc576d81f06.


File save hooks don't seem to work in JLDA

It seems Jupyter Desktop App doesn't use File Save hooks, which work for Jupyter Lab.
https://jupyter-server.readthedocs.io/en/latest/developers/savehooks.html
JLDA version: 3.6.1-1 (hooks don't work)
JL version: Version 3.4.8 (hooks work)
Update. When connected to existing JL server then they work in JLDA. So it must be different location expected for the hooks for the JLDA. Currently my hooks are in ~/.jupyter. Which directory this should be for the JLDA?

PR #588 is merged, so it seems like this bug is now fixed. Thanks!


Mark plugin as thread safe

@phax
Please consider using maven-plugin-annotations and its @Mojo annotation in the longer term. But this gets rid of the now unnecessary warning:
[WARNING] *****************************************************************
[WARNING] * Your build is requesting parallel execution, but project      *
[WARNING] * contains the following plugin(s) that have goals not marked   *
[WARNING] * as @threadSafe to support parallel building.                  *
[WARNING] * While this /may/ work fine, please look for plugin updates    *
[WARNING] * and/or request plugins be made thread-safe.                   *
[WARNING] * If reporting an issue, report it against the plugin in        *
[WARNING] * question, not against maven-core                              *
[WARNING] *****************************************************************
[WARNING] The following plugins are not marked @threadSafe in document:
[WARNING] com.helger.maven:ph-javacc-maven-plugin:4.1.2-SNAPSHOT
[WARNING] Enable debug to see more precisely which goals are not marked @threadSafe.
[WARNING] *****************************************************************

Codecov Report

Merging #16 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #16   +/-   ##
=========================================
  Coverage     25.54%   25.54%
  Complexity      141      141
=========================================
  Files            16       16
  Lines          1061     1061
  Branches        165      165
=========================================
  Hits            271      271
  Misses          697      697
  Partials         93       93

Impacted Files
Coverage Δ
Complexity Δ

...main/java/org/codehaus/mojo/javacc/JavaCCMojo.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

This is the shorthand. If you like, you can add ' true' behind the annotation.


readme: update examples to use the library name

Following the readme, I copied the example and found out that another library by the name of dom-helper (no 's') exists and that it is very different. I wish the names were less alike.
This PR updates the readme to use this library in the examples.

ooops silly oversight on my part. thanks.