text:
[Announcement] Improving I/O for correct and consistent experience

tl;dr: how to migrate to new backend/interface

If you are using torchaudio in Linux/macOS environments, please use torchaudio.set_audio_backend("sox_io") to adopt to the upcoming changes.

If you are in Windows environment, please set torchaudio.USE_SOUNDFILE_LEGACY_INTERFACE = False and reload backend to use the new interface.

Note that this ships with some bug-fixes for formats other than 16bit signed integer WAV, so you might experience some BC-breaking changes as described in the section below.

News
[UPDATE] 2020/10/21

Added Description of "soundfile" backend legacy interface.

[UPDATE] 2020/09/18

Added migration guide for "soundfile" backend.
Moved the phase when "soundfile" backend signatures change from 0.9.0 to 0.8.0 so that they match with "sox_io" backend, which becomes default in 0.8.0.

[UPDATE] 2020/09/17

Added information on deprecation of native libsox structures such as signalinfo_t and encoding_t.

Improving I/O for correct and consistent experience
This is an announcement for users that we are making backward-incompatible changes to I/O functions of torchaudio backends from 0.7.0 release throughout 0.9.0 release.
What is affected?

Public APIs

torchaudio.load

[Linux/macOS] By switching the default backend from "sox" backend to "sox_io" backend in 0.8.0, loading audio formats other than 16bit signed integer WAV returns the correct tensor.
[Linux/macOS/Windows] The signature of "soundfile" backend will be change in 0.8.0 to match that of "sox_io" backend.

torchaudio.save

[Linux/macOS] By switching to "sox_io" backend, saving audio files will no longer degrade the data. The supported format will be restricted to the tested formats only. (please refer to the doc for the supported formats.)
[Linux/macOS/Windows] The signature of "soundfile" backend will be change in 0.8.0 to match that of "sox_io" backend.

torchaudio.info

[Linux/macOS/Windows] The signature of "soundfile" backend will be change in 0.8.0 to match that of "sox_io" backend.

torchaudio.load_wav

will be removed in 0.9.0. (load function with normalize=False will provide the same functionality)

Internal APIs
The following functions/classes of "sox" backend were accidentally exposed and will be removed in 0.9.0. There is no replacement for them. Please use save/load/info functions.

torchaudio.save_encinfo

will be removed in 0.9.0

torchaudio.get_sox_signalinfo_t

will be removed in 0.9.0

torchaudio.get_sox_encodinginfo_t

will be removed in 0.9.0

torchaudio.get_sox_option_t

will be removed in 0.9.0

torchaudio.get_sox_bool

will be removed in 0.9.0

The signatures of the other backends are not planned to be changed within this overhaul plan.

Classes

torchaudio.SignalInfo and torchaudio.EncodingInfo

will be replaced with AudioMetaData in 0.8.0 for "soundfile" backend
will be removed in 0.9.0

Why
There are currently three backends in torchaudio. (Please refer to the documentation for the detail.)
"sox" backend is the original backend, which binds libsox with pybind11. The functionalities (load / save / info) of this backend are not well-tested and have number of issues. (See https://github.com/pytorch/audio/pull/726).
Fixing these issues in backward-compatible manner is not straightforward. Therefore while we were adding TorchScript-compatible I/O functions, we decided to deprecate this original "sox" backend and replace it with the new backend ("sox_io" backend), which is confirmed not to have those issues.
When we are switching the default backend for Linux/macOS from "sox" to "sox_io" backend, we would like to align the interface of "soundfile" backend, therefore, we introduced the new interface (not a new backend to reduce the number of public API) to "soundfile" backend.
When / What Changes
The following is the timeline for the planned changes;

Phase
Expected Release
Expected Changes

1
0.7.0(Oct 2020)
"sox" backend issues deprecation warning. ~#904~ "soundfile" backend issues warning of expected signature change. ~#906~ Add the new interface to "soubdfile" backend. ~#922~load_wav function of all backends are marked as deprecated. ~#905~

2
0.8.0
[BC-Breaking] "sox_io" backend becomes default backend. Function signatures of "soundfile" backend are aligned with "sox_io" backend. ~#978~ get_sox_XXX functions issue deprecation warning. ~#975~

3
0.9.0
"sox" backend is removed.The legacy interface of "soundfile" backend is removed.[BC-Breaking] load_wav functions are removed from all backends.

Planned signature changes of "soundfile" backend in 0.8.0
The following is the planned signature change of "soundfile" backend functions in 0.8.0 release.
info function
AudioMetaData implementation can be found here. The placement of the AudioMetaData might be changed.

 ~0.7.0   0.8.0

def info(
  filepath: str
) ->
  Tuple[SignalInfo, EncodingInfo]

def info(
  filepath: str
) ->
  AudioMetaData

Migration
The values returned from info function will be changed. Please use the corresponding new attributes.

 ~0.7.0   0.8.0

si, ei = torchaudio.info(filepath)
sample_rate = si.rate
num_frames = si.length
num_channels = si.channels
precision = si.precision

metadata = torchaudio.info(filepath)
sample_rate = metadata.sample_rate
num_frames = metadata.num_frames
num_channels = metadata.num_channels
# precision is not available

load function

 ~0.7.0   0.8.0

def load(
  filepath: str,
  # out: Optional[Tensor] = None,
      # To be removed.
      # Currently not used
      # Raise AssertionError if given
  normalization: Optional[bool] = True,
      # To be renamed to normalize.
      # Currently only accept True
      # Raise AssertionError if given
  channels_first: Optional[bool] = True,
  num_frames: int = 0,
  offset: int = 0,
      # To be renamed to frame_offset
  # signalinfo: SignalInfo = None,
      # To be removed
      # Currently not used
      # Raise AssertionError if given
  # encodinginfo: EncodingInfo = None,
      # To be removed
      # Currently not used
      # Raise AssertionError if given
  filetype: Optional[str] = None
      # To be removed
      # Currently not used
) -> Tuple[Tensor, int]

def load(
  filepath: str,
  frame_offset: int = 0,
  num_frames: int = -1,
  normalize: bool = True,
  channels_first: bool = True,
) -> Tuple[Tensor, int]

Migration
Please change the argument names;

normalization -> normalize
offset -> frame_offst

 ~0.7.0   0.8.0

waveform, sample_rate = torchaudio.load(
    filepath,
    normalization=normalization,
    channels_first=channels_first,
    num_frames=num_frames,
    offset=offset,
)

waveform, sample_rate = torchaudio.load(
    filepath,
    frame_offset=frame_offset,
    num_frames=num_frames,
    normalize= normalization,
    channels_first=channels_first,
)

save function

 ~0.7.0   0.8.0

def save(
  filepath: str,
  src: Tensor,
  sample_rate: int,
  precision: int = 16,
    # To be removed.
    # Internally converted to
    # PCM_S8, PCM_16, PCM_24, PCM_32, FLOAT
    # Will be changed to auto detect from
    # the input Tensor’s dtype
  channels_first: bool = True
)

def save(
  filepath: str,
  src: Tensor,
  sample_rate: int,
  channels_first: bool = True,
  compression: Optional[float] = None,
    # Added only for compatibility.
    # soundfile does not support compression option
    # Raises Warning if not None
)

Migration
The precision parameter will be removed. Please convert your Tensor to the desired type.

 ~0.7.0   0.8.0

torchaudio.save(
    filepath,
    waveform,
    sample_rate,
    precision,
    channels_first
)

# Denormalize the Tensor, then, convert it to the type that
# corresponds to the precision you want to save.
#
# precision == 8
# Convert the value range from [-1, 1] to [-128, 127]
# waveform *= 128 * (waveform < 0) + 127 * (waveform > 0)
# waveform = waveform.to(torch.int8)
#
# precision == 8 and unsigned
# Convert the value range from [-1, 1] to [0, 255]
# waveform *= 128 * (waveform < 0) + 127 * (waveform > 0) + 128
# waveform = waveform.to(torch.uint8)
#
# precision == 16
# Convert the value range from [-1, 1] to [-32768, 32767]
# waveform *= 32768 * (waveform < 0) + 32767 * (waveform > 0)
# waveform = waveform.to(torch.int16)  # precision == 16
#
# waveform = waveform.to(torch.int32)  # precision == 32
# Convert the value range from [-1, 1] to [-32768, 32767]
# waveform *= 2147483648 * (waveform < 0) + 2147483647 * (waveform > 0)
#
# waveform = waveform.to(torch.float32)  # precision == 32 and float
# waveform = waveform.to(torch.float64)  # precision == 64 and float

torchaudio.save(filepath, waveform, sample_rate, channels_first)

BC-breaking changes
Read and write operations on the formats other than WAV 16-bit signed integer were affected by small bugs.

Fixing these issues in backward-compatible manner is not straightforward. Therefore while we were adding TorchScript-compatible I/O functions, we decided to deprecate this original "sox" backend and replace it with the new backend ("sox_io" backend), which is confirmed not to have those issues.

When we are switching the default backend for Linux/macOS from "sox" to "sox_io" backend, we would like to align the interface of "soundfile" backend, therefore, we introduced the new interface (not a new backend to reduce the number of public API) to "soundfile" backend.

Just a quick question, does it mean that since 0.7 or 0.8 we can include torchaudio.load inside of our jit-traced modules? Are you planning to support only Linux, or will you also have a list of binaries for some other platforms (i.e. mobile, raspberry pi)? With soundfile backend?

Hi @snakers4

does it mean that since 0.7 or 0.8 we can include torchaudio.load inside of our jit-traced modules?

Yes. Technically, you can do it already with 0.6, however, the corresponding library is not available in any form yet, so you cannot run it outside Python application.
I have a prototype C++ app in my branch which depends on refactored torchaudio. The model I used can be found here
I plan to propose this to the team after the release work, but no fixed time frame for landing it yet or even I am not sure if I can land this.
This was an exercise to learn how much we can do with TorchScript, and I have found that the I/O-capability is very limited. It can only load audio data from files. I intend to look into other ways to get tensor data (like pass memory objects to TorchScript) but it's not in the top priority in my list.

Are you planning to support only Linux, or will you also have a list of binaries for some other platforms (i.e. mobile, raspberry pi)?

We are considering the possibility to add an I/O module (not another backend but something like torchaudio.io), that works not just on Linux/macOS, but also on Windows. We are thinking to bind a correction of codecs libraries that are cross-platform. Mobile is not necessarily in our scope, because we do not have an infrastructure to test them, or we have not seen a demand for it yet. Hypothetically, if the refactored torchaudio is landed, the build-process will be CMake, so it will be easier for those familiar with CMake, but again, these plans are not finalized. We are trying to figure out a good "research to production" usecase.

With soundfile backend?

The Python "soudfile" package is not TorchScript compatible, so one of the thing we are considering as a part of the I/O module described above is to bind libsnd directly.

Nice!  This is probably months from becoming actually useful by end users like us, but this increases the value of pytorch ecosystem quite a bit
Btw,  currently a vad in torch audio seems to be a port of some energy based algorithm
We are planning to make a public general torch-scriptable noise / voise / music VAD pre-trained on large voice / noise / music corpora
Guess we could collaborate on that

@snakers4

Nice! This is probably months from becoming actually useful by end users like us,

Ah, that's very optimistic view, although that's what I am aiming for. I am working on a RFC with example usage, so that community can respond. Then we will finalize the interface and will start working on the implementation.

but this increases the value of pytorch ecosystem quite a bit

Thanks, that's a nice reaction to have. One of the things we struggle is to get a signal from the community, so feedback like that is really helpful. (and motivating for me ;) )

Btw, currently a vad in torch audio seems to be a port of some energy based algorithm

The current VAD is basically, the port of sox implementation.

We are planning to make a public general torch-scriptable noise / voise / music VAD pre-trained on large voice / noise / music corpora
Guess we could collaborate on that

That's very interesting. Please keep us updated!

One of the things we struggle is to get a signal from the community, so feedback like that is really helpful. (and motivating for me ;) )

the current state of audio is that there are no go-to tools / components, that would work on all platforms
there is record.js for browsers, but porting models to js is a pain now (looks like the only decent option is re-implementing from scratch in tf.js, onnx.js has very poor layer support)
ofc, you can go low-level and compile everything for each platform, but usually you care about your algorithms working properly in real life first
in real projects you basically need a VAD + STT + some post-processing
VAD ideally should be served on edge to improve user experience, whereas STT can be better served via an API (if you use OPUS e.g. traffic is negligible)
there is nothing stopping us from making our own VAD in PyTorch, but the actual audio reading part will be outside as well
for edge deployments we still need 2-4x size reduction in model size (which is already achievable) but as I mentioned there still is not easy way to run a pytorch model in a browser

That's very interesting. Please keep us updated!

I will post an update here

This is great news, this will definitely improve trust and adoption of torchaudio 🙂 !

This might be a stupid question, but should the warning UserWarning: "sox" backend is being deprecated. The default backend will be changed to "sox_io" backend in 0.8.0 and "sox" backend will be removed in 0.9.0. Please migrate to "sox_io" backend. Please refer to https://github.com/pytorch/audio/issues/903 for the detail. disappear after setting the backend?
I import torchaudio in the following way:
import torchaudio
torchaudio.set_audio_backend("sox_io")

but still get the above warning.

Hi @expectopatronum
The warning is issued at the time import torchaudio is executed, where the default backend is set. I get that it's annoying and sorry for the confusion, but I really needed to raise a strong awareness as the sox backend was not handling data correctly.

@expectopatronum
If you use nightly builds, then the default backend is already changed to the new one, and you won't see the warning.

Hi @expectopatronum
The warning is issued at the time import torchaudio is executed, where the default backend is set. I get that it's annoying and sorry for the confusion, but I really needed to raise a strong awareness as the sox backend was not handling data correctly.

No worries, I just wanted to make sure I am doing it right! Thanks for the quick reply!

@mthrok I have a problem getting int16 saving to work on 0.7.2. What is the recommended procedure for this?
Furthermore, you mentioned above:

Convert the input Tensor to the type that corresponds to the precision you want to save.

just converting a [-1, 1] to(torch.int16) wouldn't create a valid PCM 16bit wav file since it still has to be denormalized. Is this supposed to be done by the user?

@mthrok I have a problem getting int16 saving to work on 0.7.2. What is the recommended procedure for this?
Furthermore, you mentioned above:

Convert the input Tensor to the type that corresponds to the precision you want to save.

just converting a [-1, 1] to(torch.int16) wouldn't create a valid PCM 16bit wav file since it still has to be denormalized. Is this supposed to be done by the user?

@faroit
Yeah, one needs to denormalize the Tensor, that's what I meant there. I will update the description.

@mthrok

Yeah, one needs to denormalize the Tensor, that's what I meant there. I updated the description.

thanks. Give that by far the most likely use-case for audio-to-audio models are:
16bit PCM audio input -> 32bit float torch model -> 16bit PCM audio output

and I don't think users should write out 32bit float except for they really want to (its twice the file-size). As such, it would be nice if the denormalization is builtin in to make int16 as simple to use as possible.

@faroit

and I don't think users should write out 32bit float except for they really want to (its twice the file-size). As such, it would be nice if the denormalization is builtin in to make int16 as simple to use as possible.

You are bringing up a very good point. Do you have a suggestion for API change?
The followings are the things we want to keep in mind;

Correct (if saving float32, the same information should be recoverable up to the precision)
No subtlety/surprise (conversion that involves potential data loss should be explicit)
Convenient

I think adding a new argument of target dtype and default to int16 is one way.

@mthrok
Hi again,
Regarding this discussion

We are planning to make a public general torch-scriptable noise / voise / music VAD pre-trained on large voice / noise / music corpora

Guess we could collaborate on that

That's very interesting. Please keep us updated!

Basically we have released the bare-bones version here:

https://github.com/snakers4/silero-vad

We are planning to add a couple of network "heads", finish the docs and then submit to Torch hub:

Number detector (sometimes especially in enterprise people want to make data anonymous, and personal data is basically name + some numbers)
Spoken language classifier (low hanging fruit)
We can add some other eazy heads like music detector (i.e. now we have voice vs noise + music, but we can have music vs voice + noise, music is kind of similar to noise)

You are bringing up a very good point. Do you have a suggestion for API change?
I think adding a new argument of target dtype and default to int16 is one way.

I would be in favor of defaulting (and converting) to 16bit PCM except for when users would set a different dtype.

Correct (if saving float32, the same information should be recoverable up to the precision)
No subtlety/surprise (conversion that involves potential data loss should be explicit)
Convenient

if someone wants a "correct" - and recoverable - output, torch.save exist and is convenient to use also for audio tensors. Which is why i think torchaudio.save should be more closer to what is used in the audio domain.

You are bringing up a very good point. Do you have a suggestion for API change?
I think adding a new argument of target dtype and default to int16 is one way.

I would be in favor of defaulting (and converting) to 16bit PCM except for when users would set a different dtype.

Correct (if saving float32, the same information should be recoverable up to the precision)
No subtlety/surprise (conversion that involves potential data loss should be explicit)
Convenient

if someone wants a "correct" - and recoverable - output, torch.save exist and is convenient to use also for audio tensors. Which is why i think torchaudio.save should be more closer to what is used in the audio domain.

I have a question about migrating to 'sox_io' backend from 'sox'.
I used >>> torchaudio.set_audio_backend("sox_io") after $ python3.
It shows no error.
However, it seems that the backend is not to be changed.
For example, after exit() and doing python3 again, the warning message(The default backend will be changed to "sox_io" backend in 0.8.0) still comes out.
How can I migrate correctly? Thank you.

I have a question about migrating to 'sox_io' backend from 'sox'.
I used >>> torchaudio.set_audio_backend("sox_io") after $ python3.
It shows no error.
However, it seems that the backend is not to be changed.
For example, after exit() and doing python3 again, the warning message(The default backend will be changed to "sox_io" backend in 0.8.0) still comes out.
How can I migrate correctly? Thank you.

Hi @aturahc13
That's the correct way to set the backend for the active session. For example, help(torchaudio.load) should display the different help message before and after the set_audio_backend call. The thing is that we did not ship a way to persist the configuration, so the next time the Python is launched, it goes back to the default backend.

Hi @aturahc13
That's the correct way to set the backend for the active session. For example, help(torchaudio.load) should display the different help message before and after the set_audio_backend call. The thing is that we did not ship a way to persist the configuration, so the next time the Python is launched, it goes back to the default backend.

The thing is that we did not ship a way to persist the configuration, so the next time the Python is launched, it goes back to the default backend.
Thank you. So should I do set_audio_backend every time when I use $ python3 ?
Or should I wait for the update?
Actually, all I want to do is "not showing the warning message for 'sox will be deprecated...'". I know there is a way to hidden warning messages themselves. But if there is a way to migrate the backend by hand, I will try it and ask this question. Thank you.

The thing is that we did not ship a way to persist the configuration, so the next time the Python is launched, it goes back to the default backend.
Thank you. So should I do set_audio_backend every time when I use $ python3 ?
Or should I wait for the update?
Actually, all I want to do is "not showing the warning message for 'sox will be deprecated...'". I know there is a way to hidden warning messages themselves. But if there is a way to migrate the backend by hand, I will try it and ask this question. Thank you.

Sorry I'm late to the party, I'm not using torchaudio yet, but interested in using it, and came here because of the backend deprecation warning.

normalize: bool = True,

As a non-user, I would expect that this normalizes the waveform based on the maximum amplitude value. I would also be unsurprised if it actually just converts from integers to floats.
Reading the current docstring for sox_io, it says that sample values are always normalized to [-1.0, 1.0]. It is ambiguous whether it normalizes based on the maximum amplitude found in the input, or based on the data type.
If the latter, what about changing the parameter name to as_float, or floatify? This would also make clear why it only makes a difference for integer wave files.
Alternatively, for more flexibility, it could take a dtype parameter which defaults to float32, and scales whenever converting from integers. dtype=None would return the original dtype. Of course this would mean extra work to support conversion from int8 to int16 and the like.

waveform *= 128 * (waveform < 0) + 127 * (waveform > 0)

I'm surprised -- is this the correct way to do it, using a different factor for the positive and negative part? All the code I've seen for converting from integers to floats just uses a single scaling factor for positive and negative parts (2**bits - 1), so the opposite direction should also use a single factor to not distort the audio.

Sorry I'm late to the party, I'm not using torchaudio yet, but interested in using it, and came here because of the backend deprecation warning.

normalize: bool = True,

As a non-user, I would expect that this normalizes the waveform based on the maximum amplitude value. I would also be unsurprised if it actually just converts from integers to floats.
Reading the current docstring for sox_io, it says that sample values are always normalized to [-1.0, 1.0]. It is ambiguous whether it normalizes based on the maximum amplitude found in the input, or based on the data type.
If the latter, what about changing the parameter name to as_float, or floatify? This would also make clear why it only makes a difference for integer wave files.
Alternatively, for more flexibility, it could take a dtype parameter which defaults to float32, and scales whenever converting from integers. dtype=None would return the original dtype. Of course this would mean extra work to support conversion from int8 to int16 and the like.

waveform *= 128 * (waveform < 0) + 127 * (waveform > 0)

I'm surprised -- is this the correct way to do it, using a different factor for the positive and negative part? All the code I've seen for converting from integers to floats just uses a single scaling factor for positive and negative parts (2**bits - 1), so the opposite direction should also use a single factor to not distort the audio.

Hi @f0k
Thanks for the comment. Those are very good points.
Let me first tell you the context. The design principle for the new I/O modules are

Correct
Since I/O is the first part of data processing, these I/O modules must be returning the data as accurate (close to that in file format) as possible.
Easy to use
We want our library to be easy to use. In this case, since it's common practice for DL application to work on floating point values within the range of[-1.0, 1.0].
Predictable/reversible behavior
Since we want the library to be a good building block of research/real world application, we want our features to be well mannered.

For the normalization, it is because of the principle 2 and 3 that we return the normalized value by default, and the normalization is performed on fixed coefficients. (Determined by dtypes) If we normalize the resulting tensor with the value found in the tensor, users will have questions like "what was the normalization coefficient being used?", which they might never get an answer. Also it is because of the principle 1 we want to provide the option to return the uncompressed data without normalized. This design is influenced by spicy.io.wavfile.read function. If someone is working on non-DL application and wants to decode some audio data in the format other Python libraries do not support, they can use torchaudio as PyTorch provides zero-overhead conversion from Tensor to NumPy NDArray type.
Now, for the parameter name "normalization", I get that it's confusing. (There were other users who had the same confusion.) This is kind of historical. The previous backend had similar argument and when I started workin on this module, we did not intend to introduce the BC-braking change.
As of your suggestion of as_float or floatify, I think there is still an ambiguity, as for the range value of the resulting Tensor. It is more explicit about the data type, but none of them are perfect, so I am in favor of keeping it as-is. However I think the documentation should be updated so that normalization is based on data type.
For the dtype argument, it would be nice to do but that's also something users can do easily. And since we expect floating type with [-1.0, 1.0] value range throughout the library (except kaldi module that was introduced without design review, which we plan to address), and the use of integer type is reserved for user-specific case, so I think the use-case is under defined from our perspective.
About the un-normalization process. I looked into some detail and now I think you are right. Let me give you why I suggested the formula. When I started writing the new loading function in C++, I wondered how I know my code is doing the right thing the resulting Tensor has right values. I ended up with this. Internally, libsox represents 32 bit signed integer so normalization was needed. At the time I did not know how libsox internally do the conversion, so I set up the test and change the normalization strategy until I found an acceptable one. (That is, values are close to what sox command generates, and there should be no overflow) I ended up with this normalization, which is the reverse of what you pointed out. This achieved about 4e-05 (or 3e-03 for mp3) closeness, which was the best.
Now, I understand the code base of libsox better and I digged into it to find how libsox does it and found the following. As you say it does normalization with single value and apply clipping.
https://github.com/dmkrepo/libsox/blob/b9dd1a86e71bbd62221904e3e59dfaa9e5e72046/src/sox.h#L994
I think I can update the implementation to do the same and that should yield the result even closer to sox.
For the saving part, as @faroit suggested above, I am thinking to include un-normalization inside of the save function and default to 16-bit signed integer. So that users are not bothered for un-normalization and to cover the most of real world use case with default.

Hi @f0k
Thanks for the comment. Those are very good points.
Let me first tell you the context. The design principle for the new I/O modules are

Correct
Since I/O is the first part of data processing, these I/O modules must be returning the data as accurate (close to that in file format) as possible.
Easy to use
We want our library to be easy to use. In this case, since it's common practice for DL application to work on floating point values within the range of[-1.0, 1.0].
Predictable/reversible behavior
Since we want the library to be a good building block of research/real world application, we want our features to be well mannered.

For the normalization, it is because of the principle 2 and 3 that we return the normalized value by default, and the normalization is performed on fixed coefficients. (Determined by dtypes) If we normalize the resulting tensor with the value found in the tensor, users will have questions like "what was the normalization coefficient being used?", which they might never get an answer. Also it is because of the principle 1 we want to provide the option to return the uncompressed data without normalized. This design is influenced by spicy.io.wavfile.read function. If someone is working on non-DL application and wants to decode some audio data in the format other Python libraries do not support, they can use torchaudio as PyTorch provides zero-overhead conversion from Tensor to NumPy NDArray type.
Now, for the parameter name "normalization", I get that it's confusing. (There were other users who had the same confusion.) This is kind of historical. The previous backend had similar argument and when I started workin on this module, we did not intend to introduce the BC-braking change.
As of your suggestion of as_float or floatify, I think there is still an ambiguity, as for the range value of the resulting Tensor. It is more explicit about the data type, but none of them are perfect, so I am in favor of keeping it as-is. However I think the documentation should be updated so that normalization is based on data type.
For the dtype argument, it would be nice to do but that's also something users can do easily. And since we expect floating type with [-1.0, 1.0] value range throughout the library (except kaldi module that was introduced without design review, which we plan to address), and the use of integer type is reserved for user-specific case, so I think the use-case is under defined from our perspective.
About the un-normalization process. I looked into some detail and now I think you are right. Let me give you why I suggested the formula. When I started writing the new loading function in C++, I wondered how I know my code is doing the right thing the resulting Tensor has right values. I ended up with this. Internally, libsox represents 32 bit signed integer so normalization was needed. At the time I did not know how libsox internally do the conversion, so I set up the test and change the normalization strategy until I found an acceptable one. (That is, values are close to what sox command generates, and there should be no overflow) I ended up with this normalization, which is the reverse of what you pointed out. This achieved about 4e-05 (or 3e-03 for mp3) closeness, which was the best.
Now, I understand the code base of libsox better and I digged into it to find how libsox does it and found the following. As you say it does normalization with single value and apply clipping.
https://github.com/dmkrepo/libsox/blob/b9dd1a86e71bbd62221904e3e59dfaa9e5e72046/src/sox.h#L994
I think I can update the implementation to do the same and that should yield the result even closer to sox.
For the saving part, as @faroit suggested above, I am thinking to include un-normalization inside of the save function and default to 16-bit signed integer. So that users are not bothered for un-normalization and to cover the most of real world use case with default.

The thing is that we did not ship a way to persist the configuration, so the next time the Python is launched, it goes back to the default backend.

Thank you. So should I do set_audio_backend every time when I use $ python3 ?
Or should I wait for the update?
Actually, all I want to do is "not showing the warning message for 'sox will be deprecated...'". I know there is a way to hidden warning messages themselves. But if there is a way to migrate the backend by hand, I will try it and asked this question. Thank you.

Hi @aturahc13
In the next release, (expected early March) the default backend will be switched to "sox_io", so you will not need to do anything once you update to it. Until then sorry but you need to do set_audio_backend all the time.

The thing is that we did not ship a way to persist the configuration, so the next time the Python is launched, it goes back to the default backend.

Thank you. So should I do set_audio_backend every time when I use $ python3 ?
Or should I wait for the update?
Actually, all I want to do is "not showing the warning message for 'sox will be deprecated...'". I know there is a way to hidden warning messages themselves. But if there is a way to migrate the backend by hand, I will try it and asked this question. Thank you.

Hi @aturahc13
In the next release, (expected early March) the default backend will be switched to "sox_io", so you will not need to do anything once you update to it. Until then sorry but you need to do set_audio_backend all the time.

@mthrok
Hi again,
Regarding this discussion

We are planning to make a public general torch-scriptable noise / voice / music VAD pre-trained on large voice / noise / music corpora

Guess we could collaborate on that

That's very interesting. Please keep us updated!

Basically we have released the bare-bones version here:

https://github.com/snakers4/silero-vad

We are planning to add a couple of network "heads", finish the docs and then submit to Torch hub:

Number detector (sometimes especially in enterprise people want to make data anonymous, and personal data is basically name + some numbers)
Spoken language classifier (low hanging fruit)
We can add some other easy heads like music detector (i.e. now we have voice vs noise + music, but we can have music vs voice + noise, music is kind of similar to noise)

Please do not hesitate to provide feedback
We were mostly aiming at having small enough networks to be run on 1 core of any CPU, even mobile or IOT devices
Turns our for VAD / number detector / language or music classifier you can have very high performance with quite tiny networks

Hi @snakers4
Sorry for the late reply and thanks for the update. This is very cool. I have questions on mobile I/O situation. How are you feeding the audio in your use case? Did you work on real-time application?

@mthrok
Hi again,
Regarding this discussion

We are planning to make a public general torch-scriptable noise / voice / music VAD pre-trained on large voice / noise / music corpora

Guess we could collaborate on that

That's very interesting. Please keep us updated!

Basically we have released the bare-bones version here:

https://github.com/snakers4/silero-vad

We are planning to add a couple of network "heads", finish the docs and then submit to Torch hub:

Number detector (sometimes especially in enterprise people want to make data anonymous, and personal data is basically name + some numbers)
Spoken language classifier (low hanging fruit)
We can add some other easy heads like music detector (i.e. now we have voice vs noise + music, but we can have music vs voice + noise, music is kind of similar to noise)

Please do not hesitate to provide feedback
We were mostly aiming at having small enough networks to be run on 1 core of any CPU, even mobile or IOT devices
Turns our for VAD / number detector / language or music classifier you can have very high performance with quite tiny networks

Hi @snakers4
Sorry for the late reply and thanks for the update. This is very cool. I have questions on mobile I/O situation. How are you feeding the audio in your use case? Did you work on real-time application?

Reading the current docstring for sox_io, it says that sample values are always normalized to [-1.0, 1.0]. It is ambiguous whether it normalizes based on the maximum amplitude found in the input, or based on the data type. If the latter, what about changing the parameter name to as_float, or floatify? This would also make clear why it only makes a difference for integer wave files. Alternatively, for more flexibility, it could take a dtype parameter which defaults to float32, and scales whenever converting from integers. dtype=None would return the original dtype. Of course this would mean extra work to support conversion from int8 to int16 and the like.

When we started writing our audio pipelines we essentially used just scipy wavread and pysoundfile reading just integers to avoid any bias inside of audio libraries. And there were some gotchas and insights that may seem relevant in this context:

While in general for DL it may hardly matter if you normalize to say 1 / abs(max(wav)) or to 1 / (2 ** 15 - 1) (NNs can even work better because of such "errors"), it will certainly matter for edge cases, like whispers or just audios with loud noise, high dynamic range, rapid change in volume, etc
The thing that you may want to avoid - is making your pre-processing work against you in these edge cases (or in different IO settings with different libraries);
So I suppose that the optimal strategy may be just to stick to reading audio in [-1, 1] (preferably just manually doing the normalization part), and then perform some form of STFT and then apply some dynamic normalization, so the "brightness" of loud and quiet parts of audio does not differ 10x or 100x. This may help disentangle the actual IO part from the logic part;

Reading the current docstring for sox_io, it says that sample values are always normalized to [-1.0, 1.0]. It is ambiguous whether it normalizes based on the maximum amplitude found in the input, or based on the data type. If the latter, what about changing the parameter name to as_float, or floatify? This would also make clear why it only makes a difference for integer wave files. Alternatively, for more flexibility, it could take a dtype parameter which defaults to float32, and scales whenever converting from integers. dtype=None would return the original dtype. Of course this would mean extra work to support conversion from int8 to int16 and the like.

When we started writing our audio pipelines we essentially used just scipy wavread and pysoundfile reading just integers to avoid any bias inside of audio libraries. And there were some gotchas and insights that may seem relevant in this context:

While in general for DL it may hardly matter if you normalize to say 1 / abs(max(wav)) or to 1 / (2 ** 15 - 1) (NNs can even work better because of such "errors"), it will certainly matter for edge cases, like whispers or just audios with loud noise, high dynamic range, rapid change in volume, etc
The thing that you may want to avoid - is making your pre-processing work against you in these edge cases (or in different IO settings with different libraries);
So I suppose that the optimal strategy may be just to stick to reading audio in [-1, 1] (preferably just manually doing the normalization part), and then perform some form of STFT and then apply some dynamic normalization, so the "brightness" of loud and quiet parts of audio does not differ 10x or 100x. This may help disentangle the actual IO part from the logic part;

Hi @snakers4
Sorry for the late reply and thanks for the update. This is very cool. I have questions on mobile I/O situation. How are you feeding the audio in your use case? Did you work on real-time application?

@mthrok
Hi,
The VAD itself can work with whole files and in a real-time / streaming application. Other heads (number detector, language classifier) work only with whole "files" (which are essentially just [-1, 1] normalized streams of floats), but the are meant as a downstream heads after the VAD.
Our VAD is a neural network in PyTorch (JIT / ONNX), and obviously it benefits from batching. This may be a bit complex with streaming especially if you try streaming N streams at the same time. So we provided a few explanations and simple tools to help people integrate our VAD in their applications:

A colab with examples - single file, single stream, multiple streams - https://colab.research.google.com/github/snakers4/silero-vad/blob/master/silero-vad.ipynb - utils are just seamlessly loaded via torch hub, but they are simple enough to be reimplemented in other languages
Explanation how VAD works - https://github.com/snakers4/silero-vad#how-vad-works
VAD knobs - https://github.com/snakers4/silero-vad#vad-parameter-fine-tuning
Quality when we vary the chunk length - https://github.com/snakers4/silero-vad/issues/2#issuecomment-750840434

Hi @snakers4
Sorry for the late reply and thanks for the update. This is very cool. I have questions on mobile I/O situation. How are you feeding the audio in your use case? Did you work on real-time application?

@mthrok
Hi,
The VAD itself can work with whole files and in a real-time / streaming application. Other heads (number detector, language classifier) work only with whole "files" (which are essentially just [-1, 1] normalized streams of floats), but the are meant as a downstream heads after the VAD.
Our VAD is a neural network in PyTorch (JIT / ONNX), and obviously it benefits from batching. This may be a bit complex with streaming especially if you try streaming N streams at the same time. So we provided a few explanations and simple tools to help people integrate our VAD in their applications:

A colab with examples - single file, single stream, multiple streams - https://colab.research.google.com/github/snakers4/silero-vad/blob/master/silero-vad.ipynb - utils are just seamlessly loaded via torch hub, but they are simple enough to be reimplemented in other languages
Explanation how VAD works - https://github.com/snakers4/silero-vad#how-vad-works
VAD knobs - https://github.com/snakers4/silero-vad#vad-parameter-fine-tuning
Quality when we vary the chunk length - https://github.com/snakers4/silero-vad/issues/2#issuecomment-750840434

Also I hope that our torch.hub submission of the VAD gets approved soon!
Also also I understand that we may be kind of leaking in our validation metrics and that our validation approach may be too drastic (in real speech, web RTC usually has issues on speech start / end and it is difficult to tune) ... but just for lulz we applied our VAD to NASA's recordings of the Apollo program, and it worked. Web RTC did not really work there.

Also I hope that our torch.hub submission of the VAD gets approved soon!
Also also I understand that we may be kind of leaking in our validation metrics and that our validation approach may be too drastic (in real speech, web RTC usually has issues on speech start / end and it is difficult to tune) ... but just for lulz we applied our VAD to NASA's recordings of the Apollo program, and it worked. Web RTC did not really work there.

@faroit
I made a plan for adding dtype in save function. https://github.com/pytorch/audio/issues/1197 I appreciate it if you can take a look at it.

@faroit
I made a plan for adding dtype in save function. https://github.com/pytorch/audio/issues/1197 I appreciate it if you can take a look at it.

When we started writing our audio pipelines we essentially used just scipy wavread and pysoundfile reading just integers to avoid any bias inside of audio libraries. And there were some gotchas and insights that may seem relevant in this context:

While in general for DL it may hardly matter if you normalize to say 1 / abs(max(wav)) or to 1 / (2 ** 15 - 1) (NNs can even work better because of such "errors"), it will certainly matter for edge cases, like whispers or just audios with loud noise, high dynamic range, rapid change in volume, etc
The thing that you may want to avoid - is making your pre-processing work against you in these edge cases (or in different IO settings with different libraries);
So I suppose that the optimal strategy may be just to stick to reading audio in [-1, 1] (preferably just manually doing the normalization part), and then perform some form of STFT and then apply some dynamic normalization, so the "brightness" of loud and quiet parts of audio does not differ 10x or 100x. This may help disentangle the actual IO part from the logic part;

I believe I share the similar view with you. The only concern is that the normalization should be following the standard approach so that model works with other audio sources and libraries, even though, as you pointed out, the impact would not be huge.

Also I hope that our torch.hub submission of the VAD gets approved soon!

I believe your request is approved. The team has invited us to work on these approval process so in the future hopefully your experience will be smooth.

Also also I understand that we may be kind of leaking in our validation metrics and that our validation approach may be too drastic (in real speech, web RTC usually has issues on speech start / end and it is difficult to tune) ... but just for lulz we applied our VAD to NASA's recordings of the Apollo program, and it worked. Web RTC did not really work there.

That's super cool. The recordings are very noisy, right? Did you use noisy train samples as well?

When we started writing our audio pipelines we essentially used just scipy wavread and pysoundfile reading just integers to avoid any bias inside of audio libraries. And there were some gotchas and insights that may seem relevant in this context:

While in general for DL it may hardly matter if you normalize to say 1 / abs(max(wav)) or to 1 / (2 ** 15 - 1) (NNs can even work better because of such "errors"), it will certainly matter for edge cases, like whispers or just audios with loud noise, high dynamic range, rapid change in volume, etc
The thing that you may want to avoid - is making your pre-processing work against you in these edge cases (or in different IO settings with different libraries);
So I suppose that the optimal strategy may be just to stick to reading audio in [-1, 1] (preferably just manually doing the normalization part), and then perform some form of STFT and then apply some dynamic normalization, so the "brightness" of loud and quiet parts of audio does not differ 10x or 100x. This may help disentangle the actual IO part from the logic part;

I believe I share the similar view with you. The only concern is that the normalization should be following the standard approach so that model works with other audio sources and libraries, even though, as you pointed out, the impact would not be huge.

Also I hope that our torch.hub submission of the VAD gets approved soon!

I believe your request is approved. The team has invited us to work on these approval process so in the future hopefully your experience will be smooth.

Also also I understand that we may be kind of leaking in our validation metrics and that our validation approach may be too drastic (in real speech, web RTC usually has issues on speech start / end and it is difficult to tune) ... but just for lulz we applied our VAD to NASA's recordings of the Apollo program, and it worked. Web RTC did not really work there.

That's super cool. The recordings are very noisy, right? Did you use noisy train samples as well?

That's super cool. The recordings are very noisy, right? Did you use noisy train samples as well?

We used a lot of noise (we collected a proprietary database from a number of sources) when training our models as augmentation
Nasa samples are noisy and low SNR
We had to tweak 2 probabilities for Nasa though, but they are documented and their meaning is obvious

That's super cool. The recordings are very noisy, right? Did you use noisy train samples as well?

We used a lot of noise (we collected a proprietary database from a number of sources) when training our models as augmentation
Nasa samples are noisy and low SNR
We had to tweak 2 probabilities for Nasa though, but they are documented and their meaning is obvious

Hi @faroit
Regarding the save function. I added bits_per_sample and encoding option in #1226. Unfortunately, I could not make it default to 16-bit for the feat of BC breaking behavior, but with the new parameters, you can just do encoding="PCM_S", bits_per_sample=16 to save tensor data to 16-bit signed integer PCM. You do not need to perform conversion by yourself. Let me know what you think.

Hi @f0k
Turned out that libsox had the capability of converting numerical types (among float, uint8, int16, int32 etc) so now the save function can handle Tensors of dtype float, uint8, int16, int32 natively. You can do torchaudio.save(path, tensor, format="wav", encoding="PCM_S"|"PCM_U"|"PCM_F", bits_per_sample=8|16|32) without manually converting the Tensor.

Regarding the save function. I added bits_per_sample and encoding option in #1226. Unfortunately, I could not make it default to 16-bit for the feat of BC breaking behavior, but with the new parameters, you can just do encoding="PCM_S", bits_per_sample=16 to save tensor data to 16-bit signed integer PCM. You do not need to perform conversion by yourself. Let me know what you think.

@mthrok sounds good. What happens if you specify non-standard combinations such as encoding="PCM_F", bits_per_sample=8?

@mthrok sounds good. What happens if you specify non-standard combinations such as encoding="PCM_F", bits_per_sample=8?

@faroit If the combination is allowed, it will be succeed, but if the combination is not supported, then it will cause an error. This was typical hard error vs fallback design decision, and we decided to start from hard error. If users find this behavior too inconvenient, then we can change that.

With torchaudio.load() in v0.8, the sox_io backend does not support 24-bit signed PCM audio files. Right now the only workaround is to switch back to the sox backend using torchaudio.set_audio_backend("sox").
Is 24-bit signed going to be supported in 0.9 before removing sox? Thanks!
It is not possible to convert the dataset I'm using to 16-bit or 32-bit.

With torchaudio.load() in v0.8, the sox_io backend does not support 24-bit signed PCM audio files. Right now the only workaround is to switch back to the sox backend using torchaudio.set_audio_backend("sox").
Is 24-bit signed going to be supported in 0.9 before removing sox? Thanks!
It is not possible to convert the dataset I'm using to 16-bit or 32-bit.

Hi @ketanhdoshi
Thanks for the report. If it's causing you the trouble, we will definitely support it.
Since PyTorch does not have 24-bit int type. I need to think of a behavior when normalize=False.
In your use case, are you loading data in float32 type?
Also if you can tell us a command to generate the same type you are dealing with (with tools like ffmpeg or sox), that will be helpful.

With torchaudio.load() in v0.8, the sox_io backend does not support 24-bit signed PCM audio files. Right now the only workaround is to switch back to the sox backend using torchaudio.set_audio_backend("sox").
Is 24-bit signed going to be supported in 0.9 before removing sox? Thanks!
It is not possible to convert the dataset I'm using to 16-bit or 32-bit.

Hi @ketanhdoshi
Thanks for the report. If it's causing you the trouble, we will definitely support it.
Since PyTorch does not have 24-bit int type. I need to think of a behavior when normalize=False.
In your use case, are you loading data in float32 type?
Also if you can tell us a command to generate the same type you are dealing with (with tools like ffmpeg or sox), that will be helpful.

Thanks @mthrok. Yes, data is being loaded as float32. Here's an example of a dataset that has many sound files that I'm using that are in 24-bit signed format.

I'm running into the same issue. I'm loading some 24bit audio files and sox_io fails to load them. I can use sox backend for now but would appreciate if 24bit format can be supported too in sox_io.
A good way to handle the normalize=False is to make it unsupported for this specific format given most of the time people would use normalize=True (at least that's what I do almost always). Another idea would be to convert the 24bit format automatically/internally to 32bit even if normalize=False.
Thanks

@ketanhdoshi 24-bit support seems to have been added a couple days ago to the master branch https://github.com/pytorch/audio/pull/1389
I test it (Nightly build) and seems to work for me!

@aelimame @ketanhdoshi Sorry I forgot to let you know but we added 24-bit support.
It's nice to learn that it is working for you @aelimame.
@ketanhdoshi , please try the nightly build and see if it works. If not let us know.

FYI: @ketanhdoshi @aelimame 24-bit support has been ported to release 0.8.1.

Closing the issue as 0.9 is released which concludes the migration.
Thank you for all the people who gave feedback.

authors: aelimame aturahc13 expectopatronum f0k faroit ketanhdoshi mthrok snakers4 tbazin

repo: pytorch/audio


text:
Increase beam search speed and reduce memory usage

🚀 Feature Request
Increase generation speed and reduce memory usage by making model aware beam search. This is a continue speed improvement follow up by #1851.
Motivation
In beam search, encoder state are duplicate N times and saved in GPU memory during incremental decode. Avoid these duplication can reduce memory usage for encoder state to 1/N, and enable increase batch size up to Nx to get much better speed. (N is batch size)
Measure by BART model on CNNDM summarization dataset, this change reduces memory usage to 1/4, and enable use 4x batch size, which get 2x speed up. See below table for detail.
Pitch
I created PR #1958 with below changes.

[Major change] In encoder decoder attention, reduce saved states from [batch_size*beam_size] to [batch_size], and change attention logic to compatible with original states and reduced states.
Do not duplicate encode state, contribute 10% speed.
In beam search code, only generate necessary ngram, contribute 20% speed.

Additional context

(beam=4, lenpen=2.0, max_len_b=140, min_len=55, max_source_positions=1024)
To benchmark the speed, run "CUDA_VISIBLE_DEVICES=0 python generation_speed_test.py".
cnndm_128.txt
generation_speed_test.py

Add profile result for one transformer layer.
Before change, batch size 32, cost 2.8 ms per layer
The first part of GPU computation is very sparse.

After change, batch size 128, cost 3.3 ms per layer
GPU computation is more dense compare to use small batch size.

@myleott Could you please help review this PR? It reduce memory size used for encoder-decoder attention to 1/Beam_size. (Original size is Layer_number * [Batch_size*Beam_size, Input_length, Hidden_dim]) And enable increasing batch size to get quicker generation speed.

source: gharchive/issue

repo: pytorch/fairseq

license: mit

license_type: permissive

license_source: bigquery


text:
Assertion Error in preprocessing of FAIR Sequence-to-Sequence Toolkit for Story Generation

when I run
$ TEXT=examples/stories/writingPrompts
$ python preprocess.py --source-lang wp_source --target-lang wp_target
--trainpref $TEXT/train --validpref $TEXT/valid --testpref $TEXT/test
--destdir data-bin/writingPrompts --thresholdtgt 10 --thresholdsrc 10
I get an AssertionError:
Traceback (most recent call last):
File "preprocess.py", line 201, in
main(args)
File "preprocess.py", line 101, in main
padding_factor=args.padding_factor,
File "/home/username/workspace/benchmarking-tools/fairseq/fairseq/data/dictionary.py", line 137, in finalize
assert len(new_count) == self.nspecial or min(new_count[self.nspecial:]) >= threshold
AssertionError
Upon inspection i see that min(new_count[self.nspecial:]) is 0

You can remove that assert, it's unnecessary. Fixed in #200.

authors: myleott ottj


text:
[batching] pixel_{un}shuffle

Reference: https://github.com/pytorch/functorch/issues/240

Failure looks unrelated
Traceback (most recent call last):
  File "/home/circleci/project/env/lib/python3.8/site-packages/torch/testing/_internal/common_device_type.py", line 376, in instantiated_test
    result = test(self, **param_kwargs)
  File "/home/circleci/project/env/lib/python3.8/site-packages/torch/testing/_internal/common_device_type.py", line 777, in dep_fn
    return fn(slf, *args, **kwargs)
  File "/home/circleci/project/env/lib/python3.8/site-packages/torch/testing/_internal/common_device_type.py", line 777, in dep_fn
    return fn(slf, *args, **kwargs)
  File "/home/circleci/project/env/lib/python3.8/site-packages/torch/testing/_internal/common_device_type.py", line 742, in test_wrapper
    return test(*args, **kwargs)
  File "test/test_pythonkey.py", line 249, in test_make_fx_exhaustive
    self.assertEqual(new_out, old_out)
  File "/home/circleci/project/env/lib/python3.8/site-packages/torch/testing/_internal/common_utils.py", line 1985, in assertEqual
    super().assertTrue(result, msg=self._get_assert_msg(msg, debug_msg=debug_msg))
AssertionError: False is not true : Tensors failed to compare as equal!With rtol=1.3e-06 and atol=1e-05, found 3 element(s) (out of 81) whose difference(s) exceeded the margin of error (including 0 nan comparisons). The greatest difference was 2.5272369384765625e-05 (5.405212879180908 vs. 5.405187606811523), which occurred at index (0, 0, 0, 1).

LGTM!

source: gharchive/pull-request

repo: pytorch/functorch

license_source: github-api


text:
[spmd] add more reshard suggestions to einop_rule

This PR add reshard suggestions to einop rule, namely if we found
that the same tensor dimension is both replicated and sharded across
different inputs, we return the reshard suggestions to reshard the
replicated input to sharded. Taking an example:
If we call bmm(replicate, shard(0)), we should make the first one
be also shard on the batch dimension by performing a zero cost reshard
This rule is general to all einop related rule, as long as the named
dimension of inputs are the same, added tests to test bmm and baddbmm
works
TODO: merge the reshard suggestions on this with the partial linear reshard suggestions.

Thanks @wanchaol ! At this point, are we ready to generalize to other linear operations as well?

Yep this should be generalized in addmm and mm natively, it's just that we need to add more tests to test this.

repo: pytorch/tau


text:
Fix torchrec rowwise adagrad implementation

Summary: Apparently we flipped the order of taking power 2 and taking mean.
Differential Revision: D57307271

cc @YLGH

repo: pytorch/torchrec


text:
ROIPool + Dispatcher + Autocast + Code Cleanup

part of #2797 and #2796
Implements Dispatcher + Autocast for ROIPool.
I'm also doing some clean up on the original code such as:

Remove primitive const declaration from method names.
Using references when possible.

Discussed with @datumbox offline, in order to avoid conflicts with some currently ongoing PRs he will be sending the tests in a separate PR

authors: datumbox fmassa

repo: pytorch/vision


text:
Plot contains no data, and coordinate axes are wrong

I have some working code in holoviews which displays a dataset (constructed from an xarray dataset).
(hv_ds.to(hv.Image, ["projection_x_coordinate",
"projection_y_coordinate"])).redim.range(rainfall=(0,100))

However, when I try to do the equivalent in geoviews the plot does not contain any data. Also, the axes are completely different. I think geoviews is only plotting a small section of the data, but I have no idea why.
import geoviews as gv
(hv_ds.to(gv.Image, ["projection_x_coordinate",
"projection_y_coordinate"])).redim.range(rainfall=(0,100))

Extra information
The geoviews version also runs considerably slower than the holoviews version - on the order of minutes, rather than seconds. It gave some warnings while it was running:
/opt/conda/lib/python3.6/site-packages/numpy/core/_methods.py:26: RuntimeWarning: invalid value encountered in reduce
  return umr_maximum(a, axis, None, out, keepdims)

I have also tried loading the data from iris, and regridding into latitude/longitude coordinates, but the results were much the same.

You just need to tell GeoViews what coordinate system your data is in, using the crs parameter accepted by GeoViews objects.  Without that declaration, it assumes your data is in PlateCaree, which is clearly not the case here.  Maybe pass crs=crs.GOOGLE_MERCATOR (given the size of those coordinates)?

Thanks, this helped! I switched to the geoviews Dataset and used
gv_ds = gv.Dataset(xr_ds, crs=cube.coord_system().as_cartopy_crs())

Strangely, the limits of the cartopy CRS seem to be different than in Iris so that part of the data is cut off. The original is in a TransverseMercator coordinate system, but in cartopy it is mapped to OSGB.

But I think this issue is either an Iris or a dataset issue, rather than geoviews.

You just need to tell GeoViews what coordinate system your data is in, using the crs parameter accepted by GeoViews objects. Without that declaration, it assumes your data is in PlateCaree, which is clearly not the case here. Maybe pass crs=crs.GOOGLE_MERCATOR (given the size of those coordinates)?

I think GeoViews needs its own FAQ about this heh

authors: RPrudden ahuang11 jbednar

repo: pyviz/geoviews


text:
select particular field and type keys with keyboard

Hi all,
can we select particular field and type keys with keyboard with help of pywinauto? if yes, can you share the details. below is the screenshot where i need to implement the scenario.

Thanks,
Rajarameshmamidi

Hi All,
I figured out a way to solve above issue.
Thanks,
RajarameshMamidi

repo: pywinauto/pywinauto


text:
Update chip.py

Added the SNAIL class as a physical component

Codecov Report

Merging #8 (53acf0c) into master (103762f) will decrease coverage by 0.51%.
The diff coverage is 14.00%.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
- Coverage   41.07%   40.56%   -0.52%
==========================================
  Files          28       28
  Lines        3805     3806       +1
==========================================
- Hits         1563     1544      -19
- Misses       2242     2262      +20

Impacted Files
Coverage Δ

c3/system/chip.py
54.76% <14.00%> (-12.74%)
:arrow_down:

c3/libraries/envelopes.py
30.10% <0.00%> (-10.26%)
:arrow_down:

c3/libraries/hamiltonians.py
72.72% <0.00%> (-4.78%)
:arrow_down:

c3/utils/tf_utils.py
44.58% <0.00%> (-0.48%)
:arrow_down:

c3/libraries/fidelities.py
17.69% <0.00%> (-0.24%)
:arrow_down:

c3/libraries/sampling.py
0.00% <0.00%> (ø)

c3/libraries/estimators.py
0.00% <0.00%> (ø)

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 103762f...53acf0c. Read the comment docs.

Codecov Report

Merging #8 (53acf0c) into master (103762f) will decrease coverage by 0.51%.
The diff coverage is 14.00%.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
- Coverage   41.07%   40.56%   -0.52%
==========================================
  Files          28       28
  Lines        3805     3806       +1
==========================================
- Hits         1563     1544      -19
- Misses       2242     2262      +20

Impacted Files
Coverage Δ

c3/system/chip.py
54.76% <14.00%> (-12.74%)
:arrow_down:

c3/libraries/envelopes.py
30.10% <0.00%> (-10.26%)
:arrow_down:

c3/libraries/hamiltonians.py
72.72% <0.00%> (-4.78%)
:arrow_down:

c3/utils/tf_utils.py
44.58% <0.00%> (-0.48%)
:arrow_down:

c3/libraries/fidelities.py
17.69% <0.00%> (-0.24%)
:arrow_down:

c3/libraries/sampling.py
0.00% <0.00%> (ø)

c3/libraries/estimators.py
0.00% <0.00%> (ø)

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 103762f...53acf0c. Read the comment docs.

authors: Radioactive-Waste codecov-io


text:
should not convert quoted lines in eml buffer

Complete the following information:

Vim or Neovim version: neovim 0.9,5
Filetype: mail

When running LinkConvertAll in a .eml buffer having quoted lines (i.e. starting with > ) the plugin converts links inside the quoted part. I would expect that those are ignored.

thanks

license: MIT


text:
🛑 nitter.us.projectsegfau.lt is down

In 1f43212, nitter.us.projectsegfau.lt (https://nitter.us.projectsegfau.lt) was down:

HTTP code: 503
Response time: 393 ms

Resolved: nitter.us.projectsegfau.lt is back up in 5b3af32 after 19 minutes.


text:
🛑 nitter.tiekoetter.com is down

In 3713a86, nitter.tiekoetter.com (https://nitter.tiekoetter.com) was down:

HTTP code: 502
Response time: 679 ms

Resolved: nitter.tiekoetter.com is back up in a777376 after 5 minutes.


text:
🛑 nitter.ir is down

In a719d1a, nitter.ir (https://nitter.ir) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nitter.ir is back up in 183b090 after 3 hours, 35 minutes.


text:
🛑 notabird.site is down

In fcc036e, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 88 ms

Resolved: notabird.site is back up in 6209904 after 46 days, 11 hours, 15 minutes.


text:
🛑 nitter.projectsegfau.lt is down

In ef82bb8, nitter.projectsegfau.lt (https://nitter.projectsegfau.lt) was down:

HTTP code: 502
Response time: 26688 ms

Resolved: nitter.projectsegfau.lt is back up in 896dff2 after 4 hours, 30 minutes.


text:
🛑 nitter.us.projectsegfau.lt is down

In 9437fb6, nitter.us.projectsegfau.lt (https://nitter.us.projectsegfau.lt) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nitter.us.projectsegfau.lt is back up in b4a02ad after 1 hour, 20 minutes.


text:
🛑 read.whatever.social is down

In b769962, read.whatever.social (https://read.whatever.social) was down:

HTTP code: 504
Response time: 10196 ms

Resolved: read.whatever.social is back up in 15607ef.


text:
请问macbook air 2020 M1芯片的下载哪个文件呀，小白进去发现几十个压缩包。。。

尽量每个 issue 只提一个 bug 或新功能
提新 issue 前请确认 👉

没人提过这个 issue（这里看所有 issue）
项目的 Todo 里没有与你 issue 相关的内容（这里看 Todo）

反馈 bug 需要的信息

用的是网页版还是客户端
浏览器名称或电脑操作系统
控制台 Console 页面的截图（按 F12 可打开控制台）

https://github.com/qier222/YesPlayMusic/releases/download/v0.4.5/YesPlayMusic-mac-0.4.5-arm64.dmg

Thank you very much.
------------------ 原始邮件 ------------------
发件人: @.>;
发送时间: 2022年6月6日(星期一) 下午5:58
收件人: @.>;
抄送: @.>; @.>;
主题: Re: [qier222/YesPlayMusic] 请问macbook air 2020 M1芯片的下载哪个文件呀，小白进去发现几十个压缩包。。。 (Issue #1684)
https://github.com/qier222/YesPlayMusic/releases/download/v0.4.5/YesPlayMusic-mac-0.4.5-arm64.dmg
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


text:
How would you respond if your girlfriend demands you to enter the password?

I believe that the best form of privacy protection should be that even if someone knows you have secrets, they shouldn't be able to determine where those secrets are (which directory), or what the secrets are. Even if she knows such a plugin exists, but you don’t admit the existence of a specific private directory, she still can’t do anything about it.
Could you improve the plugin to support hiding the directory entry? It would be great to have a feature that allows encrypting and hiding the entry to a notes directory. This means that the hidden directory would only be accessible when the user actively enters the directory name and the password.

If my girlfriend demands me to do this, I would say that is my personal privacy.
Your suggestion is great, but currently the technical implementation is difficult for me，because I need to consider adapting to multiple operating systems, such as Windows, iOS, Android.
So I should not support this feature in the short term.


text:
Set MessagePack as default viewer

OS
Windows 10
VERSION
1.4.8
ISSUE DESCRIPTION
We would like to ask on how to set messagepack as the default viewer when viewing the contents of redis cache. We are storing the data as MsgPack and it would be better if there is an option to set the default viewer (maybe in the settings). As of now when viewing other data, the viewer is set back to "hex".

not support yet, later may add msgpack to auto-format-list, then it will change to msgpack automatically

Yes please, i would like to request a feature where we can set msgpack as the default not hex.

done, will release in next update

@qishibo may i know what kind of fix / feature have you done? Do you have a screenshot?

I haven't modify the UI, it will change to msgpack view automatically just like json, because app will check if it is a msgpack format

Alright thanks! When will you release the new version?

@qishibo i think there is an issue when the value is boolean msgpack, the msgpack viewer doesn't get selected automatically.
Actual:

It should be:

authors: firephantomassasin qishibo

repo: qishibo/AnotherRedisDesktopManager


text:
Test Issue - tqkmr

Test Body - rruvotyfrq

Test Comment - knbsu

repo: qlikqaa/dummyrepo


text:
Test Issue - yzlso

Test Body - trbgsrzphi

Test Comment - fyayu


text:
Test Issue - cweza

Test Body - hmihfcfwbs

Test Comment - uxror


text:
Test Issue - svpgx

Test Body - yjjarpbvlq

Test Comment - mmequ


text:
Test Issue - pdspt

Test Body - lounxqyfgn

Test Comment - besxw


text:
Test Issue - zbtkf

Test Body - dsbuxzczar

Test Comment - bjjqg


text:
Test Issue - thwsq

Test Body - raqooanony

Test Comment - jotti


text:
Test Issue - ngepg

Test Body - oowjqnxxci

Test Comment - qszmt


text:
Test Issue - eozhs

Test Body - bmxrsdnmpo

Test Comment - rlqyh


text:
Test Issue - ewjap

Test Body - miiqwcmanr

Test Comment - sonpi


text:
Test Issue - egcwn

Test Body - iydsrudnpn

Test Comment - soqke


text:
Test Issue - vgfiw

Test Body - dmkcfkkksu

Test Comment - hwmmm


text:
Test Issue - qtofu

Test Body - oisneouuyr

Test Comment - ispyn


text:
Test Issue - hhgmk

Test Body - xjnigcxhqb

Test Comment - icaut


text:
Test Issue - klolg

Test Body - xliaioxhnp

Test Comment - uybqp


text:
Test Issue - abqyh

Test Body - pvsjrtflet

Test Comment - ngmjr


text:
Test Issue - ckmtw

Test Body - txzprfxavu

Test Comment - hkxtj


text:
Test Issue - twqob

Test Body - uwfcftqrxv

Test Comment - ygtwu


text:
Test Issue - ciwwr

Test Body - fsvkaahnuv

Test Comment - nqiba


text:
Test Issue - pesfi

Test Body - rdhztyfzjq

Test Comment - sxhfw


text:
Test Issue - ntngn

Test Body - vhoptjxrrm

Test Comment - tkasp


text:
Test Issue - yheln

Test Body - jlpncdqfmp

Test Comment - ejrep


text:
Test Issue - tnvbi

Test Body - jwvnpnguky

Test Comment - qhklv


text:
Test Issue - jesxr

Test Body - ulbzjjsaog

Test Comment - wurek


text:
Test Issue - hzgcq

Test Body - oqjgbrzpxn

Test Comment - johhc


text:
Test Issue - uhlyj

Test Body - tbnfgbapsm

Test Comment - pmrni


text:
Test Issue - lipmj

Test Body - njtwbcezvf

Test Comment - zylhz


text:
Grid-based mobile layout

As of commit dc1e1fb I've had a crack at a grid-based mobile layout. This first version is pretty naive: it changes the grid from 1fr 2fr (or whatever the proportions are) to a single-track 1fr column, and it positions both the narrative and sticky content on that one column. Then it sets z-index: 1 on the narrative content to ensure it's on top.
In practice, I imagine we'd have a slightly more complex (and perhaps more configurable) grid that includes gutters and maybe a few subdivisions so that you can still align overlaid narrative content to the left or right. Or perhaps the latter makes sense for 'tablet' sizing, with mobile going right down the middle.
One problem I'm seeing with this first test is that our figures don't seem to be shrinking down from their native width:

I've added a test down the bottom of the doc to compare against. Normally .quarto-figure > figure sets width: 100% and the img itself has max-width: 100%. But for some reason this isn't working now.
I was worried that maybe the poem-related and that this JS was forcing something to be wide. But it doesn't seem to be poem-related (I still see the problem if I remove those from the test). And when I click up through the DOM from the offending img, only it and the figure have a width set on them (all the others are greyed out, indicating they're set based on parent or children). So I'm a bit stumped.

Found the culprit here! It's the GraphViz diagram. It isn't wrapped in .quarto-figure and specifically has max-width: none set on it, so it stays at 672px wide, forcing the whole column out.
Have isolated and reproduced this issue at https://github.com/jimjam-slam/test-quarto-graphviz-sizing and filed it as https://github.com/quarto-dev/quarto-cli/issues/9249 😊 If it is by design, we can override it by specifying width: 100% !important on the figure if need be, but let's see if the Quarto folks change anything.

Ahh, I was wrong! I've added the workaround I described for GraphViz sizing in commit 80da14f. It works when the poems are removed, but when the poems are present they're pushing the width out. I need to put some JS debugging statements back in...

Adding a max-width to the poem mitigates but doesn't entirely fix the problem. There's still a bit too much room, and the horizontal positioning looks like it's happening based on the pre-overflow width rather than the actual width—I'll need to dip back into the JS to check that.
Also, although I've set max-width: 100svh, it should really only be that if the container is 100svh (as it currently is on mobile). On desktop, it would reflect the proportions of the grid (which could be complicated if we allow the user to configure that). Maybe a CSS variable is in order to control both—or using JS to manually calculate it. Yuck.

@andrewpbray Here's what I'm thinking in terms of grid-based layout configs.
It's really five basic layouts, with only one being possible at mobile width but up to all five available at desktop width.

The mechanism I'm thinking is that you either define the basic layout via classes or via YAML:
---
closeread:
  layout-tablet: overlay-right
  layout-desktop: sidebar-right
  # (no layout-mobile options)
---

:::{.cr-section .cr-tablet-overlayright}
:::

We could define the grid layouts for those classes in SCSS (and perhaps attach those classes in Lua to ones that have no other layout using the YAML options).
There are two ways you could do this:

Write grid tracks for all the possible layouts in one system, and then simply set the properties defining which tracks are actually used according to the class.
Write separate grid tracks for each class. Only the grid tracks that are actually used for any given section are available, and users can override the class directly if they want to customise (we could make the precise widths CSS or SCSS variables). I think this is my preference, but I'm happy to kick it around!

What do you think?

In the mean time, I still haven't fixed this horizontal space problem — I'm so stuck that I even tried rendering the poem as an SVG (which is its own can of worms and also nukes accessibility).
Even more frustrating is that I can't reproduce the original scaling problem in Safari with a simpler test case—the text looks absolutely fine blown up in a simple document:

I might need to walk away from this one and have another swing in a few days!

A quick video to demo the inconsistency of the scaling problem in Safari (it doesn't look too bad because I've shrunk the video down for GitHub's attachment sizes, but at actual screen size it's a lot worse):
https://github.com/qmd-lab/closeread/assets/6520659/8e959a40-c3f3-41fe-b7d1-0266bb913bd4

I've pushed one more change that uses a variable poem font size (based on screen width and height). It still breaks at some unusual landscape aspect ratios, but at more common ones it behaves much more (and lays out properly more often even when scrollbars do pop  in).
I'd love to get to the bottom of the Safari bug and ditch a lot of this extra complexity, but I'm also mindful of time 🤔

Some great ideas and puzzling bugs here - looking forward to chatting!

Okay, returning to the original intent of this PR: letting users specify a layout!

@andrewpbray Here's what I'm thinking in terms of grid-based layout configs.
It's really five basic layouts, with only one being possible at mobile width but up to all five available at desktop width.

The mechanism I'm thinking is that you either define the basic layout via classes or via YAML:
---
closeread:
  layout-tablet: overlay-right
  layout-desktop: sidebar-right
  # (no layout-mobile options)
---

I think the Lua function needs to place the document YAML options as classes on body, and then attributes or classes used on cr-section flow through to them on the HTML. So the CSS would be something like:
# this is less specific (0-1-1), so it applies by default...
body.cr-overlay-right-desktop {
  // layout here
}

# this is more specific (0-2-1), so it overrides any body option
body .cr-section.cr-overlay-right-desktop {
  // layout here
}

(CSS specificity calculator is useful for confirming this ahead of time!)
Since centre overlay is the only one supported by mobile, I would make that the default and then have the other options function on breakpoints going up from there (so you're only ever specifying layout or desktop layout).
Bootstrap breakpoints also function going up from a minimum width by default too, so that works (we could also use those breakpoints directly — ie. instead of -tablet and -desktop, it's -sm, -md, -lg, xl, xxl). So you might end up with something like:
@include media-breakpoint-up(lg) {
  .cr-overlay-right-lg {
    // overlay right code goes here
  }
}

// next breakpoint up goes here, so
// if you provide tablet and desktop ones,
// the desktop one overrides the tablet one at that width (i think)

Okay, the above isn't entirely working — for the overlay classes, I don't know how to calculate the space between narrative edge and sticky edge.
Maybe we just use separate grid tracks for the sidebar layouts, and all the overlay ones work as the mobile layout (overlay-center) and the sticky stack do: overlaid on one grid column, and then we margin/pad them to get the right effect.
So then for overlay layouts it becomes:

grid-column: 1
(narrative) margin-left, margin-right
(sticky col) margin-left, margin-right

While for sidebar layouts it becomes:

(narrative, sticky) grid-column: 1 or 2
(narrative, optional) margin-left, margin-right
(sticky col, optional) margin-left, margin-right

This is basically how the sidebar works currently!

I also just found out that you're supposed to set container-type on the parent when using container units and queries! That might help! 😅

Taking a look at this now... will have feedback in a couple hours...
:snail:

It could be that container-type is only used for container queries, not container units. I need to do a bit of reading on it myself!

While tinkering around with styling, I realized nytimes keeps their sidebar at a fixed width. Try widening and narrowing the window here:
https://www.nytimes.com/interactive/2022/03/06/books/auden-musee-des-beaux-arts.html

Closing in favour of #55!

authors: andrewpbray jimjam-slam

repo: qmd-lab/closeread


text:
QAF can't run with Selenium 4.3.0

Starting from Selenium 4.3.0 some of the classes that QAF uses have been moved to a new package in selenium, that causes the compilation to fail since it no longer can find the required classes
Here is the QAF class using a class that is no longer located in that package

Selenium 4.2.2
https://github.com/SeleniumHQ/selenium/tree/selenium-4.2.2-java/java/src/org/openqa/selenium/interactions
From selenium 4.2.2 to Selenium 4.3.0 this classes are moved into a new package

Selenium 4.3.0
https://github.com/SeleniumHQ/selenium/tree/selenium-4.3.0/java/src/org/openqa/selenium/interactions
https://github.com/SeleniumHQ/selenium/tree/selenium-4.3.0/java/src/org/openqa/selenium/remote/server/handler/interactions
QAF Version
QAF 3.1.0
Steps To Reproduce
1. Update POM file to use Selenium 4.3.0
2. Run mvn install

Expected behavior
mvn would run and tests start running
Actual behavior
maven fails indicating that the class org.openqa.selenium.interactions.HasInputDevices can't be found
Is the issue reproducible on runner?

[ ] QAS
[x] Maven
[ ] Gradle
[ ] Ant
[ ] Eclipse

Test case sample

Thanks for reporting. We will take a look on impact and possible solution in upcoming release. Meanwhile you can continue using previous client library version targeting on latest selenium server using remote driver.

@cjayswal  : We are facing multiple issues as well . Can you help address the core libraries

We will have QAF 4 with minimum selenium version 4.3. Meanwhile you should try using remote driver pointing to local selenium server 4.x

We will have QAF 4 with minimum selenium version 4.3. Meanwhile you should try using remote driver pointing to local selenium server 4.x

What is the expected release for QAF4 ?
We are already overriding selenium which by defuult provided by QAF which is quite old. as we are currently using 4.1+ but the problem arises when we have to use 4.8+ to have latest edge support, but QAF can't go above 4.2 due to compilation issue caused by removed interfaces.

Regarding using using selenium 4.8+,
You can continue using selenium 4.1+ in your project and target to run on selenium server 4.8+. For that you need to use remote driver. Here are the steps:

Configure your project to use remote driver, for example:
 #[selenium]
 remote.server=localhost
 remote.port=4444
 driver.name=chromeRemoteDriver

Download and run selenium server as standalone or grid.
java -jar selenium-server-4.8.3.jar standalone --port 4444

Run your tests

In example above selenium server assumed to run on local machine.

Hello Chirag,
Thank you. With QAF 4.0 can we also make necessary changes around the
driver Management ?
As you are aware starting 4.6.0 , selenium has inbuilt driver manager.
What can be done :

Remove Webdriver Manager related code from UiDriverFactory.class
Make necessary changes to allow use of latest selenium dependencies.
For any customized driver initiation , listeners can be used.

Regards
Saifuddin Raj
On Thu, Apr 13, 2023 at 4:51 AM Chirag Jayswal @.***>
wrote:

Regarding using using selenium 4.8+,
You can continue using selenium 4.1+ in your project and target to run on
selenium server 4.8+. For that you need to use remote driver. Here are the
steps:

Configure your project to use remote driver, for example:
#[selenium]
remote.server=localhost
remote.port=4444
driver.name=chromeRemoteDriver

Download https://www.selenium.dev/downloads/ and run selenium server
as standalone or grid.
java -jar selenium-server-4.8.3.jar standalone --port 4444

Run your tests
In example above selenium server assumed to run on local machine.
—
Reply to this email directly, view it on GitHub
https://github.com/qmetry/qaf/issues/425#issuecomment-1505836011, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AILXHZZZJWP5LYOX6VTPJGLXA4BTZANCNFSM565TZ2YQ
.
You are receiving this because you commented.Message ID:
@.***>

@cjayswal  : Thank you very much. As part of which release version can we try this out ?

QAF 4.0.0-SNAPSHOT is available in snapshot repository to try/test. You can refer to the commit for further details. With this update qaf-support-mobile is also updated with appium minimum version to 8.
Repo:
<repository>
   <id>oss.sonatype.org-snapshot</id>
   <url>http://oss.sonatype.org/content/repositories/snapshots</url>
  <releases>
    <enabled>false</enabled>
  </releases>
  <snapshots>
     <enabled>true</enabled>
  </snapshots>
</repository>

Hi @cjayswal,
CC: @SaifuddinR,
We did further investigation and found some issue.
We are trying to execute testcases in Docan Browser which works for specific Chrome driver version “75.0.3770.140”. We tried below options [with no ChromeOptions and no DesiredCapabilities]. But, it is not working.

We tried initializing the chrome driver as below :

WebDriverManager.globalConfig()
        .setAvoidBrowserDetection(true)
        .setChromeDriverVersion("75.0.3770.140");

But it is initializing to the latest chrome driver version and not “75.0.3770.140”.
The same is working fine in QAF 3.1.0.

We also tried to initialize the by providing chromedriver executable path for chromedriver version “75.0.3770.140". But, we are facing NoSuchMethodException.

Error log:
Starting ChromeDriver 75.0.3770.140 (2d9f97485c7b07dc18a74666574f19176731995c-refs/branch-heads/3770@{#1155}) on port 2939

Only local connections are allowed.

Please protect ports used by ChromeDriver and related test frameworks to prevent access by malicious code.

INFO  - Unable to create driver instance in 3rd attempt with retry timeout of 60 seconds. You can check/set value of 'driver.init.retry.timeout' appropriately to set retry timeout on driver initialization failure.Unable to Create Driver Instance for chromedocan: java.lang.NoSuchMethodException: org.openqa.selenium.chrome.ChromeDriver.<init>(java.net.URL, org.openqa.selenium.Capabilities)

Build info: version: '4.8.2', revision: '826dbfc730'

System info: os.name: 'Windows 10', os.arch: 'amd64', os.version: '10.0', java.version: '1.8.0_333'

Driver info: driver.version: unknown

Can you please check and fix it before deploying these change?

authors: FelipeLeon-minted SaifuddinR cjayswal mshariqa sopansh

repo: qmetry/qaf


text:
Feature Request - docs - Add instructions to get this working in Azure DevOps

Using the current instructions for dotnet tool install does not work on Azure DevOps due to an unknown error. Can you please provide instructions that will work for using this tool with Azure DevOps pipelines ?

I was able to get the tool to work in Azure DevOps by using the following script block (on ubuntu-latest):
dotnet tool install --global dotnet-zip
export PATH=$PATH:~/.dotnet/tools
dotnet zip --configuration $(buildConfiguration)

I think the core problem is that by default the dotnet tools path is not included on the image, and does not have to do with this tool itself. I found microsoft/azure-pipelines-task #12548, which is a similar problem with a different tool. I ran a test based on the issue's feedback, and it was also successful. For example see the following steps in the pipeline:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '3.1.x'
  displayName: 'use .net 3.1.x'

- script: |
    dotnet tool install --global dotnet-zip
    dotnet zip --configuration $(buildConfiguration)
  displayName: 'dotnet zip $(buildConfiguration)'

Thank you for responding @joncloud . Unfortunately for whatever reason doing a global install always fails for my organization's build machine images. After a lot of experimenting, I found that I had to create a tool manifest for my projects and then do a local tool install for the project. Here's what worked for me:

- task: DotNetCoreCLI@2
  displayName: 'Restore dotnet tools for various build tasks'
  inputs:
    command: 'custom'
    custom: 'tool'
    arguments: 'restore --tool-manifest "$(Build.SourcesDirectory)/dotnet-tools.json" --configfile "$(Build.SourcesDirectory)/nuget.config"'

- task: DotNetCoreCLI@2
  displayName: 'Run .deb packaging tool for linux-arm64'
  inputs:
    command: 'custom'
    custom: 'tool'
    arguments: 'run dotnet-deb -c Release -f netcoreapp3.1 -r linux-arm64'
    workingDirectory: '$(Build.SourcesDirectory)/MyProjectName'

repo: qmfrederik/dotnet-packaging


text:
can this module support percentage input?

I want to input a percentage value, can this feature be supported in future?

Yes, it can and It is not too complex of implement!
We could use the native input range, however, I think we should change the default style with other like this (reference), because default style is ugly and browser-dependent.
Thanks for your feedback 👍

However, I'm thinking on this and what kind of input would it be? Can you provide us an example (an image or so) of how it should be 😕
So, I'm wrong, because the range input it's already implemented...

repo: qontu/ngx-inline-editor


text:
Theme: Firefox disfunction

Please make sure that you have latest theme (18.32) and Webmin (1.830) versions installed.
Provide the following information:
server-side OS Debian Wheezy / Debian Jessie
client-side OS, browser and its versions: Debian Jessie, Firefox (38.7.1)
Connect to server
Get Left Nav Bar but blank page, Each time  try to change page by navigation bar, get a popup asking if i want to leave or stay on page : "This page is asking you to confirm that you want to leave - data you have entered may not be saved." staying or leaving lead to a blank page
No issue when using chromium, or when using theme 18.10 or 18.20
Thanks for your help
David

Hi,
Did you try to restart Webmin and clearing browser's cache? I have no issue on Firefox. Also closing and opening browser would help sometimes.

Thanks for answering that fast.
As suggested, i'd just cleared browser's cache, restart Webmin, and firefox.
No success :(
Thanks for you help,
David
On 13/01/2017 19:10, Ilia Rostovtsev wrote:

Hi,
Did you try to restart /Webmin/ and clearing browser's cache? I have
no issue on Firefox. Also closing and opening browser would help
sometimes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/qooob/authentic-theme/issues/644#issuecomment-272506439,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX8bcVlfolkon3AFBJBi6qmLT7e17cREks5rR74AgaJpZM4LjJSj.

David,
Next try to reinstall theme manually using Webmin Configuration module. You can download latest theme from release tab.
Other browser also doesn't work? Tried Incognito tab?
Last try is to reboot the server. If it's fixed I'll be very surprised and pass this issue to Jamie.

Hello,
I tried on 2 servers with the 10.32 version
first server ubuntu 9 which have been rebooted
second server debian wheezy
the issue does not appear with chromium browser
the issue still appears with incognito tab
Thanks for your help,
David
On 13/01/2017 19:33, Ilia Rostovtsev wrote:

David,
Next try to reinstall theme manually using Webmin Configuration
module. You can download latest theme from release tab.
Other browser also doesn't work? Tried Incognito tab?
Last try is to reboot the server. If it's fixed I'll be very surprised
and pass this issue to Jamie.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/qooob/authentic-theme/issues/644#issuecomment-272512100,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX8bcYS_WGUd6QoAWk5iTn4-eDRhpr_6ks5rR8N6gaJpZM4LjJSj.

David, could you close Firefox, try to store/rename all of it's cache data and config directories to something else (make it if it was fresh installed) and then try it.
It's not the theme issue. I remember this happened in my Firefox. All I needed to do is to exit it. Just kill -9 firefox, probably it hangs somewhere in the memory. I bet the issue will not show up on the other computer with Firefox.

Hello,
i made a fresh install of firefox and everything going right again.
Thanks a lot for your help
David
On 13/01/2017 21:55, Ilia Rostovtsev wrote:

David, could you close Firefox, try to store/rename all of it's cache
data and config directories to something else (make it if it was fresh
installed) and then try it.
It's not the theme issue. I remember this happened in my Firefox. All
I needed to do is to exit it. Just |kill -9 firefox|, probably it
hangs somewhere in the memory. I bet the issue will not show up on the
other computer with Firefox.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/qooob/authentic-theme/issues/644#issuecomment-272545621,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX8bcaTSDsR9OoqDcJUjw6-LnMXT7H9Gks5rR-S1gaJpZM4LjJSj.

You're welcome!

By the way, do you use proxy?

nop
On 13/01/2017 23:32, Ilia Rostovtsev wrote:

By the way, do you use proxy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/qooob/authentic-theme/issues/644#issuecomment-272566178,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX8bcWYTU0d3WdcwbJ6mrnEPlUt-msTwks5rR_t1gaJpZM4LjJSj.

authors: ddlecrapaud qooob

repo: qooob/authentic-theme


text:
Theme: Help openers are broken across different places

Screenshot as an example:

Version 18.40 will contain this fix and other unreported issues.


text:
🛑 otakusan is down

In 27cd7fe, otakusan (https://otakusan.net/LightNovel) was down:

HTTP code: 0
Response time: 0 ms

Resolved: otakusan is back up in 9df85ef after 13 minutes.


text:
🛑 Xemphim club is down

In 4ba7c31, Xemphim club (https://xemphim.club/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Xemphim club is back up in e053ab3.


text:
🛑 Xemphim club is down

In c38b2fd, Xemphim club (https://xemphim.club/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Xemphim club is back up in 8507d06.


text:
🛑 kokocon is down

In 9caccfc, kokocon (http://kokocon.net/) was down:

HTTP code: 500
Response time: 200 ms

Resolved: kokocon is back up in 442ce8f after 8 minutes.