Can you instantiate a Wavesurfer with a MediaElement which is already playing, without interrupting its playback?

If an audio tag is already present on the page, can an instance of Wavesurfer be created to visualize that element's waveform (and subsequently control navigation/playback), but without reloading or otherwise interrupting the playback of the existing element?
My attempts so far have left me with the impression that, using the MediaElement backend, calling .load(mediaElement) forces the existing media element to reload and restart its playback. Is there any way around this, if the audio is already present and loaded?
Thanks for any help.

@abrahamian looks like this is your problem? https://github.com/katspaugh/wavesurfer.js/blob/master/src/mediaelement.js#L132 Can you comment that (and/or other relevant stuff in that method) out, check what happens?

yo @abrahamian, any feedback?

@thijstriemstra, I’m still working on this.
For context: My specific use case relies on another library (cassette) to instantiate the MediaElement and initiate playback. I’ve had some success implementing what I want by  simply commenting out some lines of code (such as the one you referenced, and others that pause/unpause) in my fork of wavesurfer, but only in Chrome. In Firefox and Safari I get bugs that I am still working to understand.

TL:DR
I am enabling and disabling audio tracks on a html 5 video Dom element interactively. I cant get wavesurfer to update the audio graph without reloading the source media and having the default tracks enabled. Does wavesurfer let me 'hot reload' the graph based on the state of a media element?

Hi all.
Firstly, thank you for Wavesurfer - its great and ive been able to very quickly do some fun things.
My current situation is such that I have a video element which contains multiple tracks in the container video mov / mp4. These are 'broadcast masters' from a major streaming provider and contain 20 tracks of AAC discrete mono audio channels. My web app toggles certain channels on and off for a 'quality control' reason (we listen to tracks in isolation).
My intent is to use wavesurfer.js to visualize the audio which is helpful to identify track assignment and encoding issues.
However, wavesurfer doesnt appear to have a facility to update the audio being previewed if the the active audio track of a video element is changed interactively. Is there a way to tell wavesurfer to not 'reload' the media - but to re-build /re-reference the video elements audio context?
Im by no means a web dev - I'm a multimedia engineer normally working on pro desktop apps in c / c++ so im admittedly out of my element - so forgive me if this is trivial.


[dcmtk] The dcmtk[openssl] not actually apply WITH_OPENSSL in windows x64

Describe the bug
I use the command to install the dcmtk with openssl feature on
vcpkg install dcmtk[openssl]

Then I write some sample code using dcmtk tls like
...
#include <dcmtk/dcmtls/tlslayer.h>
...
int main(int, char **)
{
...
 DcmTLSTransportLayer::initializeOpenSSL();
...
}

It works well when building and executing in linux environment (in my WSL2 ubuntu), But in windows, I got below errors when build the project
[build] C:\fly_dev_3\cmake_try\4-sample-win\main.cpp(147,5): error C2653: 'DcmTLSTransportLayer': is not a class or namespace name [C:\fly_dev_3\cmake_try\4-sample-win\out\build\Test\MyTest.vcxproj]
[build] C:\fly_dev_3\cmake_try\4-sample-win\main.cpp(147,27): error C3861: 'initializeOpenSSL': identifier not found [C:\fly_dev_3\cmake_try\4-sample-win\out\build\Test\MyTest.vcxproj]

I find that the windows dcmtk package in dcmtk/config/osconfig.h file the WITH_OPENSSL not defined
Seems the feature not truly enabled.
Environment

OS: Windows 10
Compiler: Visual Studio 2022 X64

To Reproduce
Steps to reproduce the behavior:

./vcpkg install dcmtk[openssl]
Create a cmake project using the following code

#include <iostream>
#include "dcmtk/dcmdata/dctk.h"
#include "dcmtk/dcmnet/assoc.h"
#include <dcmtk/dcmnet/dimse.h>
#include <dcmtk/dcmtls/tlslayer.h>
using namespace std;
int opt_acse_timeout = 30;
int main(int, char **)
{
    DcmTLSTransportLayer::initializeOpenSSL(); // initialize OpenSSL library
    T_ASC_Network *net; // network struct, contains DICOM upper layer FSM etc.
    OFCondition cond = ASC_initializeNetwork(NET_REQUESTOR, 0, opt_acse_timeout, &net);
    if (!cond.good())
    {
        return 1;
    }
    T_ASC_Parameters *params; // parameters of association request
    cond = ASC_createAssociationParameters(&params, ASC_DEFAULTMAXPDU);
    if (!cond.good())
    {
        return 1;
    }
    ///////////////////////TLS//////////////////////////
    {
        T_ASC_NetworkRole opt_networkRole = NET_REQUESTOR;
        DcmTLSTransportLayer *tLayer = new DcmTLSTransportLayer(opt_networkRole, OFnullptr, OFFalse);
        auto rootCAFile = "/mnt/c/test/rootCA.cer";
        cond = tLayer->addTrustedCertificateFile(rootCAFile, DcmKeyFileFormat::DCF_Filetype_PEM);
        if (cond.bad())
        {
            return 1;
        }
        // skip cert check
        tLayer->setCRLverification(TCR_noCRL);
        cond = tLayer->setTLSProfile(DcmTLSSecurityProfile::TSP_Profile_BCP_195_RFC_8996);
        if (cond.bad())
        {
            return 1;
        }
        tLayer->setCertificateVerification(DcmCertificateVerification::DCV_requireCertificate);
        cond = ASC_setTransportLayer(net, tLayer, 0);
        if (cond.bad())
        {
            return 1;
        }
        cond = ASC_setTransportLayerType(params, true);
        if (cond.bad())
        {
            return 1;
        }
    }

    // set calling and called AE titles
    ASC_setAPTitles(params, "ECHOSCU", "ANY-SCP", NULL);
    ASC_setPresentationAddresses(params, "<IP_ADDRESS>", "<IP_ADDRESS>:8889");
    // list of transfer syntaxes, only a single entry here
    const char *ts[] = {UID_LittleEndianImplicitTransferSyntax};
    // add presentation context to association request
    int preId = 1;
    ASC_addPresentationContext(params, preId, UID_VerificationSOPClass, ts, 1);

    // request DICOM association
    T_ASC_Association *assoc;
    cond = ASC_requestAssociation(net, params, &assoc);
    if (!cond.good())
    {
        return 1;
    }
    {
        T_DIMSE_Message msg;
        memset((char *)&msg, 0, sizeof(msg));
        msg.msg.CStoreRQ.MessageID = 1;
        msg.CommandField = DIMSE_C_STORE_RQ;
        msg.msg.CStoreRQ.DataSetType = T_DIMSE_DataSetType::DIMSE_DATASET_PRESENT;
        strcpy(msg.msg.CStoreRQ.AffectedSOPClassUID, "1.2.840.10<IP_ADDRESS>.1.1.2"); // 不传文件名会unknown开头
        strcpy(msg.msg.CStoreRQ.AffectedSOPInstanceUID, "<IP_ADDRESS>.5");              // 设置受影响的SOP实例UID
        auto dcmFile = "/mnt/c/test/CT.DCM";
        cond = DIMSE_sendMessageUsingFileData(assoc, preId, &msg, NULL, dcmFile, NULL, NULL);
        if (!cond.good())
        {
            return 1;
        }
    }

    cond = ASC_releaseAssociation(assoc); // release association
    if (!cond.good())
    {
        return 1;
    }
    cond = ASC_destroyAssociation(&assoc); // delete assoc structure
    if (!cond.good())
    {
        return 1;
    }
    cond = ASC_dropNetwork(&net); // delete net structure
    if (!cond.good())
    {
        return 1;
    }
}

Build failed, because the macro WITH_OPENSSL not defined, so the tlslayer.h not contain the tls related classes.

Expected behavior
Should build success like in linux env
Failure logs
···
[build] C:\fly_dev_3\cmake_try\4-sample-win\main.cpp(147,5): error C2653: 'DcmTLSTransportLayer': is not a class or namespace name [C:\fly_dev_3\cmake_try\4-sample-win\out\build\Test\MyTest.vcxproj]
[build] C:\fly_dev_3\cmake_try\4-sample-win\main.cpp(147,27): error C3861: 'initializeOpenSSL': identifier not found [C:\fly_dev_3\cmake_try\4-sample-win\out\build\Test\MyTest.vcxproj]
[build] C:\fly_dev_3\cmake_try\4-sample-win\main.cpp(149,5): error C2065: 'DcmTLSTransportLayer': undeclared identifier [C:\fly_dev_3\cmake_try\4-sample-win\out\build\Test\MyTest.vcxproj]
···
Additional context
If I define the WITH_OPENSSL in my code , then build. it will return the LINK error. So I believe the DCMTK not enable the OPENSSL feature in windowsX64
below is the vcpkg list
PS C:\Debug> vcpkg list
boost-uninstall:x64-linux                         1.84.0              Internal vcpkg port used to uninstall Boost
dcmtk:x64-linux                                   3.6.8#3             This DICOM ToolKit (DCMTK) package consists of s...
dcmtk:x64-windows                                 3.6.8#3             This DICOM ToolKit (DCMTK) package consists of s...
dcmtk[openssl]:x64-linux                                              Enable OpenSSL
dcmtk[openssl]:x64-windows                                            Enable OpenSSL
openssl:x64-linux                                 3.3.0               OpenSSL is an open source project that provides ...
openssl:x64-windows                               3.3.0               OpenSSL is an open source project that provides ...
vcpkg-cmake-config:x64-linux                      2022-02-06#1
vcpkg-cmake-config:x64-windows                    2022-02-06#1
vcpkg-cmake-get-vars:x64-linux                    2023-12-31
vcpkg-cmake-get-vars:x64-windows                  2023-12-31
vcpkg-cmake:x64-linux                             2023-05-04
vcpkg-cmake:x64-windows                           2023-05-04

This issue could be reproduced with vcpkg 2024-03-14-7d353e869753e5609a1f1a057df3db8fd356e49d and VS2022 17.9.6

I was not able to reproduce the issue with "vcpkg 2024-03-14-7d353e869753e5609a1f1a057df3db8fd356e49d" @ baseline 59aeb8fe8fe1c980de6bd5ba634cf21024522d81 with VS2022 17.8.3, on neither x64-windows nor x64-windows-static.
Could you try to apply the PR https://github.com/microsoft/vcpkg/pull/38932 to see if it helps / to pin down the problem?

@zzfzzf1018 If other people have difficulties reproducing the problem, it could be helpful to check or share the configuration logs from buildtrees/dcmtk. Not just the config log there, but also CMakeFiles/CMakeConfigureLog.yaml in the subdirectories. dcmtk has extra checks and find modules, and these might clash with vcpkg.
And the next step is to inject --trace-expand into the cmake options and look for other evil.

@zzfzzf1018, I can't reproduce your error using the latest version of dcmtk. Does this problem still exist?


add "null value support" in spec?

Per https://github.com/swagger-api/swagger-core/issues/459 there are cases where passing null is important.  For example:
[ null ]

will be quite different than [].  See if this can be an option

Love to see this. Especially helpful for us with some of the datetime requirements we have. Right now I'm resorting to "x-isnullable" : true

I'd like to see this too. I'm trying to define a PATCH endpoint which merges incoming fields of a JSON object over the existing one.
Accepting a document with age: null is the way I intend to specify that the value should be overwritten, rather than left as it currently is (which is what would happen when omitting the age key from the request).

Having null as type would be handy.
Otherwise in Response Class (Status 200) Model Schema you get
{
  "payload": {},
  "status": "ok"
}

instead of
{
  "payload": null,
  "status": "ok"
}

@z0r1k - null normally makes sense in requests but less so in responses (though I can think of use cases it's useful for responses as well).
In your example, wouldn't it make more sense to just have the following if there's no payload?
{
  "status": "ok"
}

To me, null has the meaning of "this property existed before, and I want to nullify its value". If there's no value, or the value needs not change (for requests, for example), it just shouldn't be sent.

I'm in similar situation with jphastings (and chimmelb). Allowing null values is required for PATCH as I don't want to support empty strings for that. Support for null would be needed.

+1. Nullability is a sort of awkward thing to not have. It's definitely a distinct case from required. One is KEY must be present. One is VALUE of key must be present.

+1. We're using the good suggestion by @enkafan too.

+1 ran into this today, trying to validate responses in tests against Swagger schema.
A suggestion for a non-breaking change: nullable: true. This would avoid the problem of API developers being silly and implementing polymorphic fields (although I could see a Postel's Law argument on the request side).

If you're suggesting x-nullable *cough* then sure, go ahead and use it for now :)

On Sat, Dec 20, 2014 at 03:22:16PM -0800, Tony Tam wrote:

Per https://github.com/swagger-api/swagger-core/issues/459 there are
cases where passing null is important.

I bumped into this for enums (swagger-api/swagger-js#507) and was sent
here.  Arguing for nulls in responses:
I restrict the information that gets returned to a user based on their
authorization.  So using my pet.species example from
swagger-api/swagger-js#507, returning a response without pet.species
means “I won't tell you” and returning a response with a null
pet.species as null means “I don't know”.
Is the resistance to nulls in enums “this is too much work to
implement” (i.e. “patches welcome”) or “we disagree with JSON Spec's
choices” (i.e. “patches will be refused”).

The 'resistance' is that 2.0 is finalized and won't change. There's no resistance to include it in a newer version of the spec (just need to make sure that we agree on the details).

On Thu, Jun 25, 2015 at 12:51:54PM -0700, Ron wrote:

The 'resistance' is that 2.0 is finalized and won't change. There's
no resistance to include it in a newer version of the spec (just
need to make sure that we agree on the details).

The swagger 2.0 spec just defers to JSON Schema (latest!) for the enum
type [1,2] and it's listed as a “taken directly” property 3.  So it
seems like swagger-js is just diverging from the spec, and could be
fixed in a 2.x.y patch relases.  Users who currently don't use 'null'
in their specs won't be broken by us bringing swagger-js in line with
the spec in this regard.  Or am I misunderstanding?

null is not a valid type as it is not listed in the spec. You can't use an invalid type as a type for enum. There's no full compliance with JSON Schema, and while the spec defers to JSON Schema in some sections, it also imposes limitations on others. If you feel there needs to be extra clarification on null not being usable anywhere, I'll be happy to clarify it in the spec itself.

On Thu, Jun 25, 2015 at 01:08:54PM -0700, Ron wrote:

null is not a valid type as it is not
listed
in the spec. You can't use an invalid type as a type for enum.

Ah, that makes sense.

If you feel there needs to be extra clarification on null not
being usable anywhere, I'll be happy to clarify it in the spec
itself.

The current spec does allow it in x-* fields, but yeah, I think more
clarity in the spec would help (so we don't have to refer folks here).
So that clears me up on the 2.0 issue.  How do I go about working
towards adding a null datatype for 3.0?  Just open a swagger-spec
issue?  Is this that issue?  Should I PR swagger-js?

This is the issue.
Nothing to PR on swagger-js, it won't change we start an official process for the next iteration of the spec (and I don't know when that will be).

On Thu, Jun 25, 2015 at 01:19:11PM -0700, Ron wrote:

Nothing to PR on swagger-js, it won't change we start an official
process for the next iteration of the spec (and I don't know when
that will be).

No hurry, I'll just patch my copy locally until we get to it.

Sounds good! Hopefully in the (not too far) future will have easier support for extensions (via vendor extensions) to the UI and that would make your patching easier, but can't make any promises as to when.

I run into this same issue today. Specifically to my case, this makes Swagger harder to add support for in legacy systems, where breaking the API contract is not ideal or requires great effort.
+1 for supporting null values in future versions

I started getting this error after using the spec converter to upgrade my working 1.2 spec to 2.0. I hate null as much as the next guy but, this is the real world, and we can't just pretend that it doesn't exist. It does and, as such, it needs to be represented. What I've always liked about swagger was that it allowed me to describe my API without trying to force me to restructure it and this seems, at least to me, to be a major and very unsettling deviation from that role in my stack.
For the time being, I appear to have been given no choice but to continue using my 1.2 spec until this issue is addressed.

Well, technically 1.2 doesn't allow it either. Just because the tools may be forgiving about it, doesn't mean it's supported.

Something to note:
We closed #459 in favor of this but this issue doesn't cover the whole issue that #459 does. When this is considered we definitely should look at it in terms of expanding to all array-of-types

Hi,
i read all you wrote here, but i still don't fully understand.
i have situation like this:
i have some permission tree which every node is a role object.
every role has a field name parent which point to his role parent. but of course the root doesn't have a parent so he has null value for this field.
i have APIs to add and retrieve roles.
of course the user can't add new or other root, so he must have parent field for the new role.
but when he retrieve roles, he can get the root which has null.
currently i can't use the same scheme for post and get because for get the parent is not required / can be null but for post it's required.
(The same problem will be for post and patch because patch can update only specific fields like only the role name, so i need to make everything not required for patch)
is there any way i can use the same scheme for all? or at lease for post and get?
Thx.

So, the nullable types:

are valid to use in properties - swagger 2.0 spec references directly the JSON Schema which allows this - and we can assume this is not being dropped in the future? latest ui works also with these.

not supported in with operations

is this correct?

Nope. They are invalid anywhere. The spec doesn't allow them, and that's the source of truth.

@enkafan where can i found the x-isnullable implementation?
i want to use it as well.
Thx.

@GiladShoham - I'm using Swashbuckle as part of our .NET WebAPI project. It allows me to customize how it builds the scheme like so
var vendorExt = new Dictionary<string, object> { { "x-nullable", true } };
c.MapType<int?>(() => new Schema { type = "integer", format = "int32", vendorExtensions = vendorExt });

in it's configuration. this results in code that looks like
"LastUserId":{"format":"int32","type":"integer","x-nullable":true}

Adding my :+1: to nullable support in future versions of the spec. Unfortunately I'm leading a project that is going to ramp up heavy use of 2.0 across our organization soon, so it sucks that we'll have to write tooling around x-nullable or similar until the next version of the spec comes out.

how should then the allowEmptyValue be handled? The spec says:

Sets the ability to pass empty-valued parameters. This is valid only for either query or formData parameters and allows you to send a parameter with a name only or an empty value. Default value is false.

Still it does nothing, at least in the ui and it's a spec issue? see https://github.com/swagger-api/swagger-ui/issues/1396.
And, is it advised to use also the x-nullable for now?

@enkafan
Thx for your response.
actually im writing the spec my self, so i can just add the x-nullable property, but i need the swagger validator to know what is this field.
so my question is what did you change in the validator to make this work?

+1. We'll use the good suggestion by @enkafan too.

Nope. They are invalid anywhere. The spec doesn't allow them, and that's the source of truth.

I feel like I'm missing something.
https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#schemaObject says "The following properties are taken directly from the JSON Schema definition and follow the same specifications".  the type field is included in that list, and json schema defines a null type.
I'm failing to see why using "type": ["null", "string"], "format": "datetime" would be invalid.
cc @webron

@pipermerriam - it's just not supported. If you feel there's a need to clarify that around the type specifically, I'd be happy to add that. An array value in general is not allowed for type (regardless of null) so there's probably room for that explanation anyways.
Not disagreeing that it should have been supported, that there are ways to support it general or anything of that sort. It was an unfortunate aspect that wasn't included in this version of the spec or any of the previous ones. I'm afraid the only workaround for now is to use a vendor extension.

An array value in general is not allowed for type

How do you reconcile that statement with:

Json Schema says "The value of this keyword MUST be either a string or an array." which unambiguously states that the type keyword can be either a string or an array of strings. http://json-schema.org/latest/json-schema-validation.html#anchor79
Swagger's 2.0 spec says "The following properties are taken directly from the JSON Schema definition and follow the same specifications:" which unambiguously says that the type keyword for a swagger Schema Object's definition is defined exactly as it is in json schema?

That statement that an array value is not allowed for the type keyword seems to directly contradict the spec.

It's a discrepancy in the written spec. I'm human and I make mistakes too - and that was written before I realized JSON Schema allows for array values. Like I said in my previous comment, I'd be more than happy to clarify that in the spec itself. I'm afraid that mistake, however, doesn't change the fact that null nor array values are supported.

Which document is considered the definitive source of truth for swagger?
On Mon, Dec 14, 2015, 4:26 PM Ron<EMAIL_ADDRESS>wrote:

It's a discrepancy in the written spec. I'm human and I make mistakes too

and that was written before I realized JSON Schema allows for array
values. Like I said in my previous comment, I'd be more than happy to
clarify that in the spec itself. I'm afraid that mistake, however, doesn't
change the fact that null nor array values are supported.

—
Reply to this email directly or view it on GitHub
https://github.com/swagger-api/swagger-spec/issues/229#issuecomment-164592837
.

@pipermerriam this was an error in the documentation.  The spec doc is the source of truth and it was well written.  That said, this is indeed an error and should be clarified.

Forgive my directness.  No intended hostility here.  Just searching for
understanding.
I believe the cited reason for not spring this feature is that the swagger
2.0 spec is frozen.
If the spec document is the source of truth and the spec document
unambiguously states that this functionality is supported then it seems
logical that changing the spec document to not support this functionality
is equivalent to changing the spec.  This revision would not be a
clarification.  It would be an arbitrary change in the specification (which
is supposed to be frozen) as decided by the swagger developers.
My library flex currently supports this nullibility functionality as it was
written to implement the 2.0 specification.
Help me understand how making this change to the spec is a fix when nothing
is broken about the current wording? It really feels a lot like an
arbitrary change to a spec that is supposed to be frozen.
On Mon, Dec 14, 2015, 4:53 PM Tony Tam<EMAIL_ADDRESS>wrote:

@pipermerriam https://github.com/pipermerriam this was an error in the
documentation. The spec doc
https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md
is the source of truth and it was well written. That said, this is indeed
an error and should be clarified.
—
Reply to this email directly or view it on GitHub
https://github.com/swagger-api/swagger-spec/issues/229#issuecomment-164597832
.

What you're describing was not supposed to be in the spec, and therefore the intent of what is written is wrong.  That's quite different than saying that it was "supposed to be there but because it's not, we're going to update the docs".
I know it may feel frustrating, but there are man, many projects that behave in the manner that the spec intends to describe, and therefore updating the documentation to the intention is the right thing todo.
The spec is actively being developed.  I encourage you to join in that conversation--2.0 is by no means the last version of the spec.  In fact, the cooperation about the changes is now open and governed neutrally.  If you want to be a part of that, go to https://openapis.org

Semantics aside, I'm failing to understand the strong resistance to letting this functionality stand?  Why exactly must this be changed to not allow this feature if it's something that people clearly want and the spec as written already allows it, and that you're clearly open to including in future versions of the spec.

@pipermerriam next version, please wait for that.  There is NO resistance to considering it in the future, but we are not amending the intended functionality of the 2.0 spec.

Will you please confirm that the source of truth is not the spec document, but rather the intent of @fehguy / @webron / ??is there anyone else that should be in this list??.

@pipermerriam this is an OSS project.  Please feel free to participate but leave your attitude at home

@fehguy  I just don't understand what is happening here.  You and @webron are contradicting each other.

Either the spec document is the source of truth and it isn't frozen so you can change the spec
Or the source of truth is not the document but rather the intent of some set of individuals and the spec is frozen but there is a bug in it so it needs to be fixed.

These two things cannot both be true.  Which one is it.
If you change the wording in the spec to disallow arrays for the type keyword then any library author who wrote a spec compliant implementation of the swagger 2.0 schema will need to go and change their implementation to be compliant.
I don't understand why you are so intent on changing this to disallow this feature.  What is so important that you need to break spec-compliant implementations?

please see https://github.com/swagger-api/swagger-spec/issues/229#issuecomment-164606645

please see #229 (comment)

Am I incorrect that this comment by webron is referencing updating the swagger 2.0 spec?

please see #229 (comment)

Also, will you please actually answer my question.

Is the problem that swagger doesn't support the null type?  It looks like http://editor.swagger.io/#/ at least supports using an array as the value of the type keyword.
If that's the problem, then I completely understand updating the current 2.0 spec to be clear that the data-types allowed for this value are only those that swagger defines.

I'd love to have nullable primitives as well as nullable objects, this would make it much easier to use Swagger for describing OData services (#230)

Would love to see this!

As a work around, I've been specifying null types with quotes, like this:
topic:
  type:
    - string
    - 'null'

This way those types do show up in swagger-ui (this is extracted from a successful response example):

Although the example value for that successful response does not appear at all (probably a separate issue) because of the multiple possible types (not necessarily related to passing null, it does that with all type fields with a list)

I didn't realize that this is allowed because of the garbled response examples in Swagger UI. The Swagger schema inherits this feature from JSON Schema, and the prose specification doesn't disallow it. Swagger Editor even supports it:

I can switch between "null" and the non-null primitive type per property (here Description and DiscontinuedDate are nullable).
Next place where I tried it is within parameter objects: here the prose specification and the schema clearly only allow single values, and Swagger UI breaks down when encountering an array of primitive types, but Swagger Editor gracefully accepts this and even offers the dropdown menu to switch between types:

Third situation where I need nullable types is with objects. Imagine a Person has a HomeAddress and a WorkAddress, both are nullable, and both refer to the same definition. I currently do this with  an x-nullable extension property within the reference object
      HomeAddress:
        $ref: '#/definitions/ODataDemo.Address'
        x-nullable: true
      WorkAddress:
        $ref: '#/definitions/ODataDemo.Address'
        x-nullable: true

The correct JSON Schema construct would be
"anyOf":[
  {"$ref":"#/definitions/ODataDemo.Address"},
  {"type":"null"}
]

which is both more verbose and harder to recognize for clients that are not validators.
So all in all I'd prefer a new keyword nullable  that I can use for all three cases. I could also live with type arrays within parameter objects and anyOf within schema objects, and then would stick to x-nullable to cater for the non-validator clients.

I'm also :+1: for this.
My current workaround is deleting the null fields before returning the JSON. This works for me because my nullable fields aren't required, so Swagger doesn't complain if they're undefined.

+1
Definitely need to support null. Placeholders in arrays, purposefully empty values...
Not supporting a JSON primitive type makes for a weird inconsistency IMO.

We have a required field for specifying that a key must exist or can be absent.  It follows logically that the same would exist for values.
I think I have a common use case: my responses are paginated, and I provide a "next" field that has a URI to the next page.  For the last page, "next" is null.

I recently submitted Swashbuckle PR #776 which proposes using x-type and x-nullable vendor extensions. I'd appreciate any feedback.

My 2 cents on this issue:

The array type support for "type" parameter as defined in JSON Schema was never meant to be used with swagger. As I see it, it would cause issues with "format" (on which item of the array does the format apply ?), "default",  and with code generation in strongly typed languages (if type is ["integer", "string"], on what Java type do I map in the POJO model ?).
The current spec says that the JSON Schema "type" can be used but doesn't restrict on string type for it for the Schema Object like it does for the Parameter Object or Header Object. So IMO the v2.0 spec should be fixed to clarify this.
Without the possibility of having array types, I don't know if there is an interest for a null type. In any case, the types allowed for "type" in Schema Object should also be clarified especially if null cannot be used.
As for nullability of fields in Schema Object, I am more in favor of introducing "nullable" than a complex way of explaining that "type can be an array but in that case it has at most 2 elements and if it has 2 elements one of them is null". The change would obviously be in the next version of the spec and in the meantime swagger implementations can use "x-nullable"

@cbornet I think we're agreeing that type should be a single type, not an array; I'm not thinking about using a separate null type at all, but we need a way to express null-ability of a type, hence the x-nullable extension is desired and sufficient express this in the meantime. Hopefully nullable will replace it when the dust settles.

@gitfool yes, that's my last point :smile:

@fehguy @webron Could we have a "semi-official" definition of the nullable vendor-extension so that systems that decide to implement it all do it the same way ?
In short, should it be x-nullable: true/false or x-isNullable: true/false ?

That's a brilliant idea. Maybe there could be a wiki-page for all the common extensions (and libs using those)? Having x-oneOf & friends implemented in most web libs (and forked swagger-uis) gives a strong signal that they should be in the core.

Can someone explain how this is not already implemented with the required property?  Doesn't it follow that if a field is not required, then it can be missing from the result document, and hence null can just be represented as not-present.  Therefore isn't this a problem for the generator of choice to convert incoming fields which are not required as allowed as nullable.  In strong-typed languages you would have to do that anyway, and in weak-typed dictionary checks of non-existent keys is the same as null
dictionary['missing-key'] == null => true

@wparad you can see in #459 comments the difference between required and nullable.

@wparad "On the wire" (i.e. when serialized as JSON), a property being absent is strictly different than a property having a null value. When mapping to dictionaries or class objects in object oriented languages, an absent key might be mapped to null (or whatever that language is using for this concept) (or a null value might be omitted), but it is actually not the same thing.
Also, for array elements there is no required property, and simply omitting an element might not work when the order/index is significant (i.e. when two arrays have corresponding entries).

@cbornet None of the boolean names in the specification use an "is" prefix, so for consistency / sanity we should surely use x-nullable (rather than x-isNullable). :wink:

Here's my example of why null values are important. I have an array that represents the colour (RGBA) of an element, the definition I have is
RgbaArray:
  type: array
  items:
    type: number
    minimum: 0
    maximum: 1
  minItems: 4
  maxItems: 4

But some elements don't yet have a colour, so I'd to be able to allow null as the colour in place of the array (as it's a required field).

@j0hnsmith I guess in your case I would not make this property required, if it can happen that some elements don't have it.

@ePaul  in the context of an array, the index in the array must be present. If you just remove it that's an entirely different array.

@bpicolo Yes, but the example of @j0hnsmith wasn't of that form.

@ePaul  Ah, correct. :)

@ePaul This is a required field (as determined by another system), if I change that for the api then I have to handle it as a special case, possible but a workaround, I've got enough of those already.
There are parts of the spec that cause friction, this is one of those parts for me.

@j0hnsmith Okay, so you have some existing API (implementation) which needs null instead of a non-existing property for a thing which is not existing, and want to describe this with OpenAPI, and this causes problems because OpenAPI has no support for nulls at all.
This reasoning is fine, it just was not what I did read out of your original comment. Sorry for any confusion.

I have been hit by an error due to C# System.Nullable. Therefore rather then populating this post I have created the question separately here http://discuss.jsonapi.org/t/handling-nullables-in-swagger/591. Need an expert advice.

Tackling PR: #741

We also got a javascript exception (and swagger-ui would not render the API) when an "examples" object contained
   "null" : null

The exception in the Javascript debugger showed
Exception
:
TypeError: Swagger 2.0 does not support null types ([object Object]). See https://github.com/swagger-api/swagger-spec/issues/229. at Resolver.resolveAllOf (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2952:13) at Resolver.resolveAllOf (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2955:12) at Resolver.resolveAllOf (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2955:12) at Resolver.resolveAllOf (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2955:12) at Resolver.resolveAllOf (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2955:12) at Resolver.finish (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2674:10) at http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2527:16 at Resolver.resolve (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:2580:6) at obj.on.response (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:1459:26) at responseInterceptor (http://swagger.na.sas.com/swagger-ui/swagger-ui.js:1995:12)
message : "Swagger 2.0 does not support null types ([object Object]).  See https://github.com/swagger-api/swagger-spec/issues/229."
stack
:
(...)
...
key : "null"

Gosh. This thread opened at Dec 21, 2014.
Unfortunately I have the feeling it will be dragged on for a long time.
One can argue that null value is as good as undefined, and therefore the attribute should be omittedf entirely.
IMHO - that's a limited narrow thinking.
Strong-typed implementations will require this null - and we've seen references to such reports here.
It seems like a contradiction between the intent and the spec.
The problem is that the current language of the spec allows it, and many people used this spec as their source of truth.
Here we saw mentions of swagger-ui, flex and json-schema and I know of proprietary implementations I cannot name here.
Changing the spec that was stated as frozen smells bad to me.
So ok, We got a "bug" in the spec. When my PM tells me he has a "bug" in the task description - we check to whom this task description was presented. If it's only me - then we "fix" it.
Alas, here - this description was communicated with the world, and the length of this thread suggests that the world minds...
Except for ...intent, I could not find any reason for the objection to adopt this spec.
This is an OSS, this is a community discussion, and proposal has been expressed.
So why won't we?

This has been interesting to follow. Google's Protocol Buffers v3 also omit a null type, which does simplify their message format but requires a few tricks, such as passing a message with a list of field names ("FieldMask") in order to be able to remove values on a partial update (PATCH).
Their message format would never allow a [null] but it does allow a [''] and that would have the same meaning. From their perspective, it actually makes it easier to work with strongly typed languages. (Note that strongly typed languages do not necessarily allow null for primitive types — an int[] in Java will have to become a Integer[] to accommodate this change)
OpenAPI has the same constraint and some of the same solutions, but this thread makes it sound as if this constraint was introduced without thought. Was null left out by accident? If not, what were the considerations behind leaving it out?

It doesn't look like the spec has been updated to clarify this yet.  This means that people will continue to run into this issue, and have to dig through search results until they find and read this entire thread.  Is there a reason why?  Is it just waiting on someone to submit a PR?  It seems to be that the pr should:

change https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md to clarify the type property in schema objects is not an array and one of the OpenAPI types.
change https://github.com/OAI/OpenAPI-Specification/blob/master/schemas/v2.0/schema.json to make sure that apis that define types this way will fail validation.  (Currently validation is successful and I think that is a big sense of confusion).

We are not updating the 2.0 version, please follow the OpenAPI.next branch for changes in the next version of the spec.

OAI v3 will be released in one month. Can we have a status on this very commented issue ?
It really seems important for a lot of people to have nullable support and actually a lot of implementations already support an "x-nullable" field. So it would be great to have this become an official "nullable" field and not postpone it to 2 more years. Or just close this issue if all this is really silly...

@cbornet it won't be released in one month, it'll be in "first implementor draft" which means major changes will not be added.
I believe null support was added, I'll check through the merged PRs in the 3.0 working copy (which lives here as I think you know)

It should be supported once the json schema support is merged: https://github.com/OAI/OpenAPI-Specification/pull/741
Then the anyOf type could be used (waiting for this too :)).
I suppose when that gets merged the issue could be closed.

We're not not adding support for null as a type, but adding a property nullable.

@webron does that mean json schema support will not be merged? as it's a lot easier to validate the output if it uses valid json schema.
If both options would be supported it would perhaps be a bit weird as it would be an own addition to the json schema spec.

The PR does not add full JSON Schema support. And we will not have full JSON Schema support in 3.0.

Is there any reason to support anyOf in json schema but not support a null type and instead add a nullable property? As there already is an entire ecosystem to do output validation if it would stick to json schema instead of reinventing the wheel.

:+1: on @cdekok. As the 3.0 rc is not out, there is time to do changes still?  Was there a good reason for not to support null?

It's been a while, so doing my best to remember. I believe the reason is that we don't allow multi-typed definitions (so you can't have type: [ 'string', 'null' ] and it's somewhat unlikely to define something that's always null. To overcome that, the nullable came in.
And before you ask - it's unlikely that we'll add support for multi-types in 3.0. Perhaps in the next iteration.

Multitype support would be a nightmare for code generators...

@webron the mentioned pull requests suggests that there would be a oneOf which would allow a null value to be added.

@cdekok theoretically, yes. Hopefully, people will be wise enough with the usage of oneOf and anyOf. Regardless, for now, we won't be adding null as a type.

So with JSON (yaml here) schema, we generally do this for nullability:
my_nullable_string:
  anyOf:
  - type: string
  - type: 'null'

we can't do that because of no support for type null, instead we should do:
my_nullable_string:
  type: string
  nullable: true

It's unfortunate that it doesn't match the JSON schema way of doing things so we can use tooling around that. But at least we'll be able to represent it somehow so its a step forward.

Regarding nullable.  Does it support query and path parameters? For example, GET /customer?phone=null to get customers who have no phone number set.  When something is defined to be nullable, does that mean null="null"=null for primitives, or are only objects supported.

I don't understand what you mean by null="null"=null, but yes, it's supported for all parameters, including primitives.

Maybe I'll ask another way.  If a query parameter qp is of type string, and is nullable, does ?qp=null mean the value is the string "null" or an indication of null?

Got it. Fair question. I don't know, but it seems like it would be outside the scope of the spec, potentially.
When you define a primitive type, you give the meaning of a type to the text. In id=42, 42 can be a string, a number or an integer. The same would go for nullable. If you set it to true, as a producer, you might assume that means you translate null value not as a string, and can never have a null string value. We're not here to invent a way to separate between a null value and a null string for such parameters.

Thanks for the clarification Ron.  And I understand that if you put a stake in the ground either way someone would be unhappy.

FWIW in JSON Hyper-Schema, we specify that null, true, and false SHOULD become "null", "true", and "false" when used to fill out URI templates (including query parameters handled through URI Templates).  That's not currently directly relevant to OpenAPI, but it's a data point for how it's being handled in a similar situation.

We've added nullable as a solution in 3.0.0-RC0.

This represents a divergence from the json-schema specification, right?

In a sense.

On one hand I respect your philosophy about not trying to be the product for every API, and think I'd make the same decision in your shoes.
On the other, I really wish Swagger was a superset of json-schema so the existing validation libraries out there, which seem to do a very good job, were a good fit for validating API responses against the Swagger docs.

Cannot agree more I can't see any reason why you would want to make a frankenstein json-schema while it already can deal with null values.

We're not opening this up for discussion again at this point. The decision was made for 3.0 and it won't change. We might revisit it in the future.

We're not opening this up for discussion again at this point. The decision was made for 3.0 and it won't change. We might revisit it in the future.

Hey, it's the future! What's up April people. How are things looking today?
@webron I appreciate your strong stance, and your wish to avoid another bikeshed. It seems like there has been a lot of conversation around this, and I'd be interested to see the archives. For the casual observer however, it looks like this whole "type should be a string" thing is a cruel and unnecessary deviation from JSON Schema.
I've put off using Swagger for a very long time due to the whole "it's kinda JSON Schema, but an old version, and we added some bits, and ignored some bits" situation. I think Open API 3.0 would be an absolutely amazing time to resolve a bunch of these known deviations, even if it involves a bit of extra work right now.
Do you have a link to a convincing argument for why type: ['string', 'null'] is going to be ignored, or is it just "meh dont want to" (which I also understand. #opensource).

@philsturgeon swagger is used to generate code including in stronglt typed languages so it' not possible to support multi type fields.

@cbornet I've always felt like that should up to the implementors.  There's no reason a generator for a dynamic language couldn't allow multi types, but a strongly typed language generator could restrict it.

@natebrunette This is a slippery slope to allowing tool vendors to optionally implement anything at which point, the value of the standard is severely reduced.

The particular case of ["string", "null"] should be OK for a strongly-typed language.  The type could be tested for null or a the generator could create a type called StringOrNull with an isNull() method.

@philsturgeon swagger is used to generate code including in strongly typed languages so it' not possible to support multi type fields.

Are strongly typed languages the only use case for swagger?  Dynamically typed languages are common in web programming, to put it mildly.  Crippling them for the sake of strong static typing is an odd choice.  If an API does not want to support clients in strongly typed languages that's a valid decision.

I mean Option/Maybe/Optional etc. are real things so I don't get the static/strong typing argument here.

Yeah, @darrelmiller, I don't think this is a conversation about "Yolo everyone can just do whatever they want.", I think @natebrunette was more suggesting that if a strongly typed language does not support union types, there are ways to handle JSON Schema's multiple types in that language that dont blow the whole thing up.
  JSON Schema is much more suited to validating instance documents than it is at describing the shape of things. There are so many things you can do with JSON Schema that make projecting types from it challenging.
I'd rather move to using a far more constrained version of JSON schema that allows users to unambiguously describe the shape of payloads than to enable the full expressiveness of JSON Schema for validation.
However, I'm not sure that the subset of JSON Schema for modelling should be defined within the scope of the OAI and instead think it should be done under the umbrella of the JSON Schema work.  With all the V3 work going on I haven't had time to bring this to the JSON Schema folks yet.

This discussion is causing flashbacks to the challenges with supporting xsd:any, xsd:anyType in the XML glory days.  I'm not advocating for reintroducing the horrors of xsd:any or xsd:anyType, but maybe the equivalent of xsi:nil.

@cipresso And the new nullable property in V3 does that https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md#fixed-fields-20  Admittedly not in the same way JSON Schema normally does it, but that's because we didn't want to re-open this can of worms :-)

@darrelmiller

However, I'm not sure that the subset of JSON Schema for modelling should be defined within the scope of the OAI and instead think it should be done under the umbrella of the JSON Schema work. With all the V3 work going on I haven't had time to bring this to the JSON Schema folks yet.

It is actually one of the three proposed new vocabularies, and the only one currently lacking a champion :-)  We haven't really started any of these projects b/c all of the main contributors had Life Stuff(tm) going on for the last few months, but I do expect things to start moving on at least UI and Documentation soon (I see the Documentation vocabulary as focusing on the challenges of dynamic hypermedia as opposed to OpenAPI's focus on statically describable APIs).
https://github.com/json-schema-org/json-schema-vocabularies

Also I'll add (again) that the swagger field "format" would be incompatible with an array of types.

+1 for subset of json schema for structure/shape definition.
While working with FHIR standard, which also mix structure definition and validation, i came up to conclusion - that separation of this concerns is a good thing (as well as tricky;)
From other side you also could  provide a different place in swagger doc for validation by unconstrained json schema.


Fix duplicated file identifiers from sharing metadata

Main fix is manually generating new uuid before creating second NWBFile. Also added logic so that the auto-detected session start times from the SpikeGLX interface aren't overwritten unnecessarily, and fixed the neuroconv requirement after the recent schemas fix.

LGTM, anything else you wanted to include in this PR?

nope but I would like to run it on the other session they shared just to double check, since that one had the spike weirdness (if you're okay with holding off reviewing/merging until next Monday). The first session is now in the embargoed dandiset though


Start multiple runners for processing a couple of jobs in parallel

This is actually quite easy to implement, I've done it in my fork of this project for huaweicloud, see https://github.com/messense/huaweicloud-github-runner/commit/2354ded37963c009a9c03067cfe99eacd862676d

Is there going to be support for matrix jobs in the future? Is there a way to workaround it for now?


jit: support Swap instruction

part of #65
Signed-off-by: Takeshi Yoneda<EMAIL_ADDRESS>

@codefromthecrypt thank you!! 💯


Are there any plans to add assign a user task functionality?

Hi
zeebe api has added the function of assign a user task. Do you have any plans to add this function?
https://docs.camunda.io/docs/apis-tools/zeebe-api-rest/specifications/assign-a-user-task/

Hi @KricYi, In the next release, the Zeebe client will have a User Tasks API

That's great! Thank you very much.


Jupiter lab: Write cell content to file using %%file magic gives error [Errno 21] Is a directory: '/'

Bug: Notebook Editor, Interactive Window, Editor cells
Steps to cause the bug to occur

Open a workspace with Jupyter Lab notebook
Create a cell with the magic keyword '%%file my_file.txt' at the top and some text below

Actual behavior
No file is written into the current directory and an error is thrown. NOTE: it works using Jupyter lab running locally in the browser.
Error in calling magic 'file' on cell:
[Errno 21] Is a directory: '/'
args: ['my_file.txt']
kwargs: {'append': False}
Traceback (most recent call last):
File "/Users/nikolasborrel/opt/anaconda3/lib/python3.7/site-packages/metakernel/magic.py", line 96, in call_magic
func(*args, **kwargs)
File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/metakernel/magics/file_magic.py", line 33, in cell_file
os.makedirs(path)
File "/Users/user/opt/anaconda3/lib/python3.7/os.py", line 223, in makedirs
mkdir(name, mode)
IsADirectoryError: [Errno 21] Is a directory: '/'
Expected behavior
Should write the file my_file.txt with the content of the cell
Your Jupyter and/or Python environment

Jupyter server running: Local
Extension version: 2020.8.10939020YY.MM.#####-xxx
VS Code version: 1.49.0
Setting python.jediEnabled: ?
Setting python.languageServer: Jedi
Python and/or Anaconda version: conda 4.8.5
OS: Mac OS 10.15.6
Virtual environment: conda
Python version: 3.7.8

Python Output
debug.log
Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

Thanks for reporting this issue. Unfortunately I'm struggling to understand the bug.
Are you facing issues in Jupyter lab or on VS Code?
Please could you provide steps to repro this issue in VS Code (you have provided instructions for opening a file in Jupyter lab).

Try creating a cell with the following content:
%%file my_file.txt

This is the content of the file

Then the error occurs

Thanks for getting back. Unfortunately this feature isn't supported yet.


Launch Demo Readiness

git clone github.com/gordian-engine/gcomos
make install
make run-testnet
gcosmos gordian watermark
gcosmos gordian validators
gcosmos keys list
gcosmos q auth account
gcosmos q bank balances
gcosmos tx bank send val
gcosmos q bank balances

[ ] Create Makefile

[ ] make deps - calls the vendored stuff in cosmos and ensures user is ready for build
[ ] make build - calls go build command, assumes you've make deps already
[ ] make install - run make deps and go install
[ ] make testnet-start - runs ./scripts/run_gcosmos
[ ] refactor ./scripts/run_gcosmos to create 4 validators and use a data folder in the gcosmos folder for the validator home folders.
[ ] make testnet-stop - stops testnet validators
[ ] make testnet-clean - removes testnet data
[ ] make install-grpcurl
[ ] add affordance to tail logs for the validators
[ ] OPTIONAL use a ./demo.sh file to put all the testnet stuff in there instead of in the Makefile see gordian

[ ] Move setup and sdk patch readme into a docs folder and out of the main readme
[ ] eliminate usage of grpcurl wherever possible by 1. moving queries to work with the gcosmos binary or 2. making a new cobra command to call the grpc service directly
[ ] remove interactive key generation in the ./scripts/run_gcosmos.sh (should be able to use --keyring-backend and --home to achieve this for all 4 valdiators)
[ ] Fix bug with 2-10 validator networks (this is kinda a showstopper IMO)
[ ] Fix gcosmos query unmarshalls

see https://github.com/gordian-engine/gcosmos/issues/2


Notifications have stopped in 1.4.0

Summary
As of upgrade to 1.4.0, several users report no more notifications.
Environment Information
Device 1 + 2

Device Name: Samsung Galaxy S7 Edge
OS Version: Android 7.0
Mattermost App Version: 1.4.0
Mattermost Server Version: 4.2.0

Steps to reproduce
Receive a message that should trigger a notification and would have triggered it in 1.3.0.
Expected behavior
Notification should appear
Observed behavior
No notifications appear. When mattermost app is opened, new messages are noted that should have flagged notifications. All notification settings appear to be correctly set, including inside OS and inside app.
Possible fixes
NA

Hi @tareko - do you see any errors:

In the Mattermost logs?
For the affected users, if they go to the mobile app settings menu > Report a problem?

Hello @lfbrock,
Thank you for your quick reply. Here are the mattermost server level logs:
[2017/11/09 06:37:54 UTC] [DEBG] /api/v3/users/websocket:user_typing
[2017/11/09 06:37:57 UTC] [DEBG] POST - /api/v4/posts
[2017/11/09 06:37:57 UTC] [DEBG] Sending push notification to device X for user Y with msg of 'tarek posted in mattermost help'
08:40
[2017/11/09 06:37:57 UTC] [DEBG] Sending push notification to device A for user B with msg of 'tarek posted in mattermost help'
[2017/11/09 06:38:35 UTC] [DEBG] Sending push notification to device C for user D with msg of 'jason posted in mattermost help'
[2017/11/09 06:38:35 UTC] [DEBG] Sending push notification to device X for user Y with msg of 'jason posted in mattermost help'
08:40
[2017/11/09 06:38:38 UTC] [DEBG] POST - /api/v4/posts
[2017/11/09 06:38:38 UTC] [DEBG] Sending push notification to device X for user Y with msg of 'jason posted in mattermost help'
[2017/11/09 06:38:38 UTC] [DEBG] Sending push notification to device A for user B with msg of 'jason posted in mattermost help'
[2017/11/09 06:38:48 UTC] [DEBG] POST - /api/v4/users/status/ids
[2017/11/09 06:39:04 UTC] [DEBG] POST - /api/v4/users/status/ids

For a working user, here is a screenshot that shows notifications working as expected (iOS):

For our server configuration, we're trying to get a license for EE, but in the meantime, here is the backend configuration:

I have asked the users for the logs as you requested above and will report them when I receive them.
Thank you,
tarek : )

Hello all,
During the debugging process, our team's notifications for Android all resumed. This happened when changing Log level to debug. I assume that this restarted some process in the server and returned notifications.
I will close this issue for now. If others have this problem, perhaps restart / reboot and then try again and reopen as necessary?
Thank you,
tarek : )


why Tone.Time('0 + 8n + 8n + 8n + 8n').toNotation() returns "2n" in old version,and retrun "1m" in new ?

use lastet version from https://tonejs.github.io/build/Tone.js
result:
Tone.Time('0 + 8n + 8n + 8n + 8n').toNotation() 1m
Tone.Time('8n + 8n + 8n + 8n').toNotation() 1m
Tone.Time('8n + 8n').toNotation() 1m
Tone.Time('4n + 4n').toNotation() 1m
all of them returns "1m" . why?
and . I use this version https://www.guitarland.com/javascripts/Tone.js
results:
Tone.Time('4n + 4n').toNotation() 2n
Tone.Time('8n + 8n').toNotation() 4n
Tone.Time('8n + 8n + 8n + 8n').toNotation() 2n
Tone.Time('0 + 8n + 8n + 8n + 8n').toNotation() 2n

use lastet version  from  https://tonejs.github.io/build/Tone.js
result:
Tone.Time('0 + 8n + 8n + 8n + 8n').toNotation()      1m
Tone.Time('8n + 8n + 8n + 8n').toNotation()   1m
Tone.Time('8n + 8n').toNotation()   1m
Tone.Time('4n + 4n').toNotation()     1m
all of them returns  "1m" .  why?
and . I use this version https://www.guitarland.com/javascripts/Tone.js
results:
Tone.Time('4n + 4n').toNotation()  2n
Tone.Time('8n + 8n').toNotation()  4n
Tone.Time('8n + 8n + 8n + 8n').toNotation()  2n
Tone.Time('0 + 8n + 8n + 8n + 8n').toNotation()  2n

string expressions were removed in version 12, so it seems like the fact that they always return "1m" is just a bug from it not being able to parse the expression. I think the best way to acheive what you're trying to do is probably something like this:
Tone.Time(Tone.Time('8n') + Tone.Time('8n')).toNotation()
Since Tone.Time implements valueOf(), the expression will be converted to seconds and then you can find the closest notation value of that.


Add modulesync config

Checklist

[x] Keep pull requests small so they can be easily reviewed.

@ccremer I was thinking about that and decided to not do that now, but defer it to if/when we make changes to the component the next time.


Tin extension work

From Swift, save a secure message to keychain. From Extension, write a placeholder function that reads the message from keychain and print it out. We give this to Tin so they can start working on their side
From Ensemble, we provide a javascript function `ensemble.saveToKeyChain(key, value), which will write to keychain (probably trigger the Swift code from #1 to write to keychain)
When our App opened with a deep link, we need to expose a onDeepLink action of some sort on Ensemble that can take the params and execute. This probably should be similar to how we listen for notifications.

If you can do #2 quickly, then skip #1.

Here, I think the first one is not needed. Saving the token from the ensemble to the keychain using the flutter_secure_storage is fine. Then we can able to access it from App and Extension via Keychain using the app groups

Tin got #1 and #2 working so no additional work there. #3 is still pending.
I also added https://github.com/EnsembleUI/ensemble/issues/730 to your queue


Consider not jumping to a file when clicking on a style property

I would suggest aligning the behavior of clicking on a style property in the extension with the behavior of the developer tools in the browser. Currently, the behavior seems to be different: in the extension the CSS file is directly opened, while in the browser this does not happen. I think it's more useful to have the browser behavior, because I often use the extension to do some style tweaks / experiments without necessarily wanting to jump to the corresponding file. Furthermore, when using WSL I get some error messages every time I click a style property, because the file can't be opened. This would also be avoided if the extension doesn't immediately try to open the file.
I previously raised this suggestion (#259) and it was implemented. However, in the current version (2.1.3) of the extension the old behavior is back.
Previous suggestions that were implemented:

when clicking on a style property, don't jump to the file
when clicking on the filename, do jump to the file
when control-clicking on a selector, style property or value, do jump to the corresponding file and line

Is it possible to re-introduce this behavior? Or alternatively, provide a configuration setting for this behavior or a configuration setting to turn off every jump-to-file behavior?

Thanks for following up on this, and sorries about the old behavior being re-introduced. I'll flag this for the team to investigate and find what happened.


Decision tree sections intro

Please delete checklist items and sections that are not relevant
Checklist

[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

Please check if the PR fulfills these requirements

[x] Tests for the changes have been added (for bug fixes / features)
[x] Storybook or docs have been added / updated (for bug fixes / features)

What is the ticket / issue associated with this change? (Link to the ticket or issue) Specifically it adds the Section intro pages and handles the special cases for its flow.
Does this PR introduce a breaking change? No
Other information:
Storybook Link (Link to a local storybook url to review new functionality)

PR to introduce the section Intro question. Handles the navigation flow exceptions. Some styling is done, some customization is needed from the Catch repo.


Toggle on/off data saver

As a user I want to be able to toggle on/off data saver to conserve my data so that songs can be streamed in low bits.

Duplicate issue


Added formality change

#77 combined casual2formal and formal2casual

I believe it might also make sense to add the active to passive (https://huggingface.co/prithivida/active_to_passive_styletransfer) and passive to active (https://huggingface.co/prithivida/passive_to_active_styletransfer) transfers, as they essentially share all the plumbing.

Thanks @rg089 for your efforts!
The PR has addressed all the suggestions in https://github.com/GEM-benchmark/NL-Augmenter/pull/77 and followed the review criteria. If you are interested to add the active/passive model, you could do that in a separate PR.


Details why each permissions is needed for GitHub

What type of suggestions?
Unclear Information
What page is concerned?
https://docs.kubefirst.io/common/gitAuth
What version of the docs?
2.3+
What is the issue?
Details why each permissions is needed for GitHub so users know why kubefirst need them. It can help with trusting our product.
Code of Conduct

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

Done


Newaliases

Added in "glvp" alias to provide a one-line git log alias that displays:

Commit ID
Author
Time
Branch
Commit message

Also added in "lrt" alias for "ls -lrth", which is useful for seeing at a glance which files in a directory were most recently modified.

Same as glol.


fix: HorizontalBarChart xAxisLabelPosition = .bottom.

It seems that this branch is deleted accidentally in some reorganizing attempts.

Thanks!


added description and installation guides to README

Created a new PR for #2 since the old PR #6 had merge conflicts. We can scrap PR #6  and take this PR into consideration instead.

@swetshaw Added a couple suggestions for the code changes for the formatting for the markdown.
A small trick is to run prettier on the markdown file to see if it auto formats the markdown correctly with:
npx prettier --write README.md;

@swetshaw Added a couple suggestions for the code changes for the formatting for the markdown. A small trick is to run prettier on the markdown file to see if it auto formats the markdown correctly with:
npx prettier --write README.md;

Thanks for the suggestion, it was really useful. Used that. 👍

Thanks for this @swetshaw I'll drop an update once we roll out the first versions of the packages.

I think we unfortunately might need to close this since we kinda diverged away from this initial idea and this PR became stale :(
Thanks though!


Script test send fund and fix bug when send fund for some tokens

Describe the task

[x] Script test send fund

Connect to all connectable network
Create extrinsic (success or not?)

[x] Fix bug send token for some token:

[x] tKSM (Karura)

[x] BNB (Etherium)

[x] THETA (Etherium)

Zero value:

SMS (Shiden-EVM)
SRISE (Shiden-EVM)
FEGS (Shiden-EVM)

Owner only:

KZY (Astar-EVM)

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./upgrade-ui-pr-1466-build-1.0.6-2023-05-30T10-24-30UTC.zip
Validation passed.


analysis: Thread1.1 5.1.7 Minimum Supported Children – IPv6 Datagram Buffering

According to Conformance Document requirement for Router device:

It should support minimal 10 children (at least 6 SEDs)

Thread Router must be able to buffer at least one 1280-octet IPv6 datagram destined for an attached SED

Thread Router must be able to buffer at least one 106-octet IPv6 datagram per attached SED

Test case 5.1.7 assumes that there are 12 thread devices in network (1 Leader + 1 DUT as Router + 10 children: 4ED and 6 SED). Currently we support maximum 5 children by default and allocate 64 message buffers totally, 128bytes size per buffer. For supporting 10 children, maybe we need more memory allocation for messages of buffering above IPv6 datagram.

Verify this case with latest Harness V26, that has been updated for detecting each echo reply from SED children, Router_5_1_7 passes now, will update the result to wiki page. Close this issue.


Token FE, invalid token address on vesting page

The token address displayed on the vesting page (pointing to testnet) is currently shown as 0X0

Clicking on Show this token in your Ethereum wallet returns MetaMask - RPC Error: Invalid address "0x0"

Close as wont fix


Application#convert silently fails in misleading way

[x] I have checked issues with bug label and found no duplicates

Expected Behavior

When app.convert(app.expandInputFiles(["../invalid/path/here"])) is provided an invalid file/directory path it will throw an error or otherwise indicate failure.
Actual Behavior

It silently fails and calling app.generateJson() returns
{ id: 0, name: '', kind: 0, flags: {} }

Steps to reproduce the bug

Here's a small script to reproduce the error:
const {Application} = require("typedoc");
const app = new Application();
app.bootstrap();
const project = app.convert(app.expandInputFiles(["../fake/lol/index.d.ts"]));
if(project != null)
  app.generateJson(project, "./data.json");

Environment

Typedoc version: 0.17.0 or next (both have this)
Node.js version: 13.11.0
OS: Windows 10

Thanks for digging into this! Yea this is an issue...
Seems like a fairly simple fix, we just need to check if we are processing an input file here and throw if the file doesn't exist. (Will also require a modification to cli.ts to catch said error and log instead of crashing)
https://github.com/TypeStrong/typedoc/blob/master/src/lib/application.ts#L285

I knew there was an issue for this! #1404 was somewhat caused by the same issue. 0.20 includes a fix (currently typedoc@beta)


v2.9.1-rc0

what happened with this rc? are we ok to release 2.9.1?

There hasn't been any feedback except https://github.com/nameko/nameko/pull/351#issuecomment-397102500.
I think we're OK to release.


Race condition: TileOverlay.clearTileCache() is called on a null object reference

I'm submitting a ...  (check one with "x")
[ ] question
[x] any problem or bug report
[ ] feature request
The plugin version:  (check one with "x")
[ ] 2.0-beta3 (github)
[ ] 2.0 (npm)
[x] 2.1.0-beta-20170929-1050
If you choose 'problem or bug report', please select OS:  (check one with "x")
[x] Android
[ ] iOS
cordova information:  (run $> cordova plugin list)
cordova-plugin-googlemaps 2.1.0-beta-20170929-1050 "cordova-plugin-googlemaps"

Current behavior:

I have differents views on my app. The bug can be spotted by doing the following steps:

Go to map view.
Wait for the map loading.
Leave the view.
Repeat step 1 until the app crash (you may repeat it several times).

Expected behavior:

The app is not crashing when going back to the view.
Steps to reproduce:

Install last version, create 2 views (home page / map view). Switch between the pages until the app crash..
Related code, data or error log (please format your code or data):
10-05 12:09:41.996 21321-21321/com.xxx.xxx E/AndroidRuntime: FATAL EXCEPTION: main
                                                                   Process: com.xxx.xxx, PID: 21321
                                                                   java.lang.NullPointerException: Attempt to invoke virtual method 'void com.google.android.gms.maps.model.TileOverlay.clearTileCache()' on a null object reference
                                                                       at plugin.google.maps.PluginTileOverlay$2.run(PluginTileOverlay.java:175)
                                                                       at android.os.Handler.handleCallback(Handler.java:739)
                                                                       at android.os.Handler.dispatchMessage(Handler.java:95)
                                                                       at android.os.Looper.loop(Looper.java:148)
                                                                       at android.app.ActivityThread.main(ActivityThread.java:7331)
                                                                       at java.lang.reflect.Method.invoke(Native Method)
                                                                       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230)
                                                                       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120)

A race condition occurs sometimes, during the map destruction, the Tile handler destructor (remove) is called, however it is sometimes called even if Tile hasnt been (yet) created. The faulty code line 175 of maps/PluginTileOverlay.java :
    tileOverlay.clearTileCache();

** How to solve **
Check if tileOverlay is not null before calling any method (like you did on line 94).

Please share your project files on github.

Dude, the stacktrace is self explanatory, I dont have time to provide a new sample project. Plus, I gave you the "one line code" solution.... If you read the stack-trace and the source, you will not need to spend time debugging.

Important thing is to figure out the reason of the error.
I haven't experienced the error never.
And I haven't received this error except you.
Further, the plugin does not execute the clearTileCache method automatically.
So I guess the reason is based in your code.
If you don't share the project, I will close this thread.
I'm so busy.

It is called when I destroy map (as said in my issue). The issue is related to the way I destroy the map, in following order (during the view destruction) :

map.clear();
map.off();
map.remove();

I think the problem is that map.clear() is the first to destroy the TilesOverlay, and Map.remove() tries to destroy it again... Its not 100% due to my code (To avoid this issue, i just removed the map.clear). I use it to be sure there is 0 memory leak. I think you should care about not trying to remove a null object that was destroyed wiht map.clear()...Or state it in the documentation. No need to thanks me.
Good luck.

Thank you. I agree your code was the reason, because the steps.
The most plugin users do the same thing, like you, but map.remove() executes map.clear() and map.off() internally.
And when you execute the map.clear(), the plguin executes the clearTileCache() method.
I think it is the timing.
Because you execute map.clear() and map.remove().
Until you explain your code steps, I couldn't figure out the reason. Then I can test to reproduce the issue.


command line tips and tricks

set baudrate: ~$ stty -F /dev/ttyUSB0 1000000
read from tty: cat < /dev/ttyUSB0
read from tty in hex format: od -x < /dev/ttyUSB0

Added to: https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/main/end_user_manual/README.md


Support importing graphs in JSON format

First effort at supporting non-Skyframe graphs, as requested in #91.

Superseded by #102.


line-number plugin not working when using language-none

Hi,
The line-number plugin only seems to be working if you set the highlighting to something other then none. While none is the advised one to use for plain text (if i read prismjs.com correctly).
What i "think" is going on is the hooks not being executed if highlighting wasn't used. Perhaps a simple fix would be to always execute the hooks?
Cheers,
Mark

Hey @markg85!
(Thanks for reporting this!)
I think this is the same problem that was discussed in #181: basically, (as @Golmote explains), the line numbers plugin runs in the after-highlight hook, which is never called because no highlighting occurs.
@Golmote lays out two approaches to fix this in #181: add a no-grammar hook or a complete hook. I think the latter approach makes the most sense.
I'm wondering if we should close #181 and have this be the main issue for this problem since #181 is actually about two different issues, the first of which we already solved.
(Let me know if you feel like I got this wrong, @markg85!)

hi @loganfranken,
You seem to be spot on. A "no-grammer" hook sounds a bit weird to me. I'd probably go for a "complete", "completed" or "done" hook which should probably be run when the core prismjs is done doing it's thing.

Hi both of you.
I followed your advice, @loganfranken, and closed the other issue.
@markg85 I agree that the complete hook makes more sense than my other proposal. PRs are welcome to solve this issue, since I won't have much time during the next weeks to look into this. But I'll give it a try after my holidays if nobody did it in the meantime.

@Golmote I'm not quite familiar with how this script works and where it should be adapted. So I happily leave this to your (or anyone else who knows what needs to be done) capable hands :)

This is fixed, as you can see in the last example on the plugin page.

It still isn't working for me with the latest code downloaded from prismjs.com. Do I need to do something special to get it to work? I can't find any information on getting it to work.


Protect against malicious PUTs

Validate against public/private keys or JSON Web Tokens to verify the data pushed to this proxy/API comes from a trusted source.

implemented in f4c16bbc67261450bd4bc6a43fc0afabdd0ef515


[WIP] wasm-bindgen & ffi-gen

changes to ffi-gen @ https://github.com/cloudpeers/ffi-gen/pull/60
to test
cd api
./build.sh
npx --yes http-server .

open browser and check console output:
RuntimeError: null function or function signature mismatch
    at <core::pin::Pin<P> as core::future::future::Future>::poll::hee1f14e768aa370f (05653dba:0xc3577a)
    at tlfs::api::FfiFuture<T>::poll::h76c2bf01723a3ed7 (05653dba:0x96beba)
    at tlfs::api::__create_memory_future_poll::{{closure}}::h662b2f4756108fd2 (05653dba:0x461870)
    at std::panicking::try::do_call::h2d6078dda0039457 (05653dba:0x87c3fc)
    at std::panicking::try::h92d29eb55d90adbf (05653dba:0x73cc07)
    at std::panic::catch_unwind::h3ccbc55a52d5dafb (05653dba:0xd1d2f9)
    at tlfs::api::panic_abort::hdc1653a7cab383da (05653dba:0x9225a4)
    at __create_memory_future_poll (05653dba:0xb40cef)
    at Api.createMemoryFuturePoll (bindings.mjs:655)
    at bindings.mjs:284

I worked around having to merge the importObject by providing the notifier callback via the global window object.

would be nice to have a test for the native and web transports connecting, not sure how feasible that is

why is the cloud relay commented out, is it not needed?

would be nice to have a test for the native and web transports connecting, not sure how feasible that is

Got one of those for libp2p-webrtc here: https://github.com/wngr/libp2p-webrtc/blob/master/integration/src/main.rs
Will look into adding some tests here as well.


Line removal on click

The selected line will now be removed on click. The hydrograph will be redrawn, with new Voronoi and axes.

This DOES NOT implement the second part of FV-17, emphasizing a line on mouseover. That is a feature implemented FV-15


All guides deprecated: how to simply load bootstrap 3 and jquery in 5.1.1

Just cloned the starter and i'm stuggling to get bootstrap 3 (css and js) and jquery running. I'm not interested in sass stuff: just simple bootstrap and jquery.
Previously on our project we used Angular-CLI and importing bootstrap and in the angular-cli.json we simply had to add (after a proper npm install bootstrap jquery --save):
"scripts": [
  "../node_modules/jquery/dist/jquery.min.js",
  "../node_modules/bootstrap/dist/js/bootstrap.min.js"
],
"styles": [
  "styles.css",
  "../node_modules/bootstrap/dist/css/bootstrap.min.css"
],

But here, with "raw" webpack, i'm lost. All the guides, previous issues and so on seems outdated as they use a vendor.ts which seems not to exist anymore.
Is there any way to import easily bootstrap and jquery working with the current Starter version?

Toward the top of ./src/app.app.module.ts:
To import CSS:
import 'bootstrap/dist/css/boostrap.min.css'
To import JS:
Follow instructions here:
https://github.com/AngularClass/angular2-webpack-starter/issues/696#issuecomment-226442566
After #1304 is merged you will be able to directly import Bootstrap SASS files, customize the variables, and Webpack will automatically generate an external CSS file for your production build. Right now it all gets inlined in the Javascript which slows loading time for a big library like Bootstrap.

I would recommend to extract all critical css to a css file outside of the module. It will allow to use it for anything that is also necessary for loading screens etc. I usually extract everything to a critical.scss and have this above the fold.

same question for recent v5.2.0 Release.
@colinskow you referenced comment #696, but in there's also use of non existing vendor.ts.
Is there any current, v5.2.0 compatible guide to easily integrate jquery+bootstrap (3.3.7 or 4) into this Seed?

@basst314 vendor.ts is no longer necessary. Just skip it. All dependencies inside node_modules will automatically be extracted to the vendor chunk without you having to specify them.

using  ng2-bootstrap as described in
angular2-webpack-starter/wiki/How-to-use-Bootstrap-3-and-Sass-and-ng2-bootstrap worked for me now.

@colinskow so we juste have to install bootstrap and jquery and the js files for both will automatically be included? As stated by @blackholegalaxy Angular-CLI provide simple styles and script part in angular-cli.json which is somehow translated in webpack instruction.
I'm quite surprised angular class started doesn't provide such a simple way to include external css and js. The same question as bootstrap and jquery could apply to bootstrap-select module for example or font-awesome.

We do support external stylesheets. Follow these instructions:
https://github.com/AngularClass/angular2-webpack-starter#external-stylesheets
To import JQuery and Bootstrap JS follow the instructions here (but just JavaScript instructions, ignore stylesheets.)
https://github.com/ghillert/angular2-webpack-starter-bootstrap
Most people tend to use Angular 2 specific Bootstrap plugins instead of the official JS, which is why we don't support it out of the box.
Many of the Wiki guides are out-dated and need to be updated!

Ok thanks for resources. But if we need any other JS file it could be convenient to be able to import it in the js bundled produced by webpack.
For example, how can I include bootstrap-fileinput JS or any JS bootstrap/jquery plugin? Angular-CLI achieved to simpli list the file in the proper section of their conf file. I found it simple. But I don't want to use angular-cli packages. Just pointing out their method is simpler and allow easy include of any JS file in the bundle.

If the JS library doesn't export a global to window just import it into your project wherever you need it. If it needs to be a global, then follow instructions on the second link I gave you above.


Add a prod docker compose file

Ideally this file would point to a dockerhub/gh packages image and not have minio components

#15 starts this

Resolved in #34


HardFault trampoline makes it difficult for probe-rs debugger to unwind past the exception handler.

The HardFault trampoline overwrites the EXC_RETURN magic values when it writes to the lr register.
Currently, the probe-rs debugger relies on those magic values during stack unwinding, to identify exception handlers, and unwind the stack that caused the exception. For instance, it used to be possible to get a stack like this:
__cortex_m_rt_HardFault (/Users/jn/dev/debug/probe-rs-debugger-test/src/thumbv7em-none-eabihf/nRF52833_xxAA.rs:43)
"HardFault handler. Cause: Escalated BusFault (Precise data access error) at location: 0x3ffffffc." (Unknown Source:0)
div_half_u128 (/rustc/0ecbd0605770f45c9151715e66ba2b3cae367fcb/library/core/src/ptr/mod.rs:1636)
__cortex_m_rt_SysTick (/Users/jn/dev/debug/probe-rs-debugger-test/src/thumbv7em-none-eabihf/nRF52833_xxAA.rs:32)
__cortex_m_rt_SysTick_trampoline (/Users/jn/dev/debug/probe-rs-debugger-test/src/thumbv7em-none-eabihf/nRF52833_xxAA.rs:17)
"Systick handler." (Unknown Source:0)
__delay #[inline] (/Users/jn/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cortex-m-0.7.7/asm/inline.rs:62)
delay (/Users/jn/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cortex-m-0.7.7/src/asm.rs:29)
__cortex_m_rt_main (/Users/jn/dev/debug/probe-rs-debugger-test/src/thumbv7em-none-eabihf/nRF52833_xxAA.rs:85)
__cortex_m_rt_main (/Users/jn/dev/debug/probe-rs-debugger-test/src/thumbv7em-none-eabihf/nRF52833_xxAA.rs:62)

With the trampoline, the debugger has no way of knowing that it is an exception handler that needs register substitutions before the calling frames can be identified, and it stops unwinding at the first frame.
I've notice in the unreleased code, that users can bypass the trampoline, with#[exception(trampoline = false)], and this restores the previous behaviour of the stack unwind.
Unfortunately, this means that the users have to modify their code before they can use the debugger in these situations.
Is there any way we can make the default to be trampoline = false?

I think there's fairly broad support for removing the trampline from cortex-m-rt, but we can't do it in the 0.7 series as it's a breaking change, and we're reluctant to release 0.8 because it massively fractures the ecosystem (every cortex-m PAC depends on cortex-m-rt 0.7, so the PACs have to update, and then the HALs on top of those have to update, etc).
I think the best option we have at the moment is to get the "trampolines are optional" change out in 0.7, then plan for 0.8 (or more likely 1.0) without the trampoline and with our other planned changes, including decoupling PACs from this crate a bit to make it easier to update later.

That seems like a sensible approach. In the mean time, I will add some docs for probe-rs to help users use the opt-out of trampoline. Thanks for the quick response.

Disabling the trampoline means you no longer get the ef: &ExceptionFrame argument passed to the hard fault handler, right? Or I might be confused about how this works.


Allow swagger API to be rendered when running from JAR file

This fixes #1230.  The resource handler I added in the original implementation used a mapping that would only work when run from a source tree.  I've changed the mapping to refer to the classpath-based location that works either from a source tree or from the JAR file.

Thanks for the quick fix! :)


[Addition]: Spoofing Farm in Bielefeld Germany

Hotspot b58 Addresses
look for this miner: Jovial Cream Cuckoo
they make much HNT look at them, everyone is an a forest there. i live in this town, there arent miner in this region. i was there to look.  Theyre whitnessing so much
theyre get all 1 HNT plus a day. and every owner wallet has got 3 miner max in it. dont understand what they do there. Please check them out in this region, Thank you

Discord Handle
philbng#5186
Reason(s)
I think this is a spoofing Farm

actually i found similar patterns on the other hotspots from that wallet please check this out

All payments go to a none mining wallet
13a2GVp1scVD5sqz1tNymUQ5LK1SVfQRTKrRK8XQEabvyUeSgGx


Where i can find more working examples?

Unfortunately, Artur is a bit behind on documentation as he is actively building out features (the only documentation that exists at this point is very outdated). At some point I may attempt to start putting stuff together


Holidays breaks on HA 2022.3.0+

Before you submit a new bug report, please check that

[X] I have read frequently asked questions and limitations
[X] I'm running the newest version of Holidays, or the next pre-release.
[X] I have enabled debug logging for my installation.

Describe the bug
Steps to reproduce:
Upgrade a working installation with Holidays to 2022.3.0 or above
holidays.calendar sensor is unavailable
The following error appears repeatedly in the system log:
2022-03-04 19:29:14 ERROR (MainThread) [homeassistant.helpers.entity] Update for calendar.holidays fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 521, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 726, in async_device_update
raise exc
File "/config/custom_components/holidays/calendar.py", line 243, in async_update
await self._async_load_holidays()
File "/config/custom_components/holidays/calendar.py", line 75, in _async_load_holidays
hol = create_holidays(
File "/config/custom_components/holidays/__init__.py", line 137, in create_holidays
return holidays.country_holidays(country, **kwargs)
AttributeError: module 'holidays' has no attribute 'country_holidays'

Configuration
{
  "home_assistant": {
    "installation_type": "Unknown",
    "version": "2022.3.1",
    "dev": false,
    "hassio": false,
    "virtualenv": false,
    "python_version": "3.9.9",
    "docker": false,
    "arch": "x86_64",
    "timezone": "America/Chicago",
    "os_name": "Linux",
    "os_version": "4.19.0-18-amd64",
    "run_as_root": true
  },
  "custom_components": {
    "nodered": {
      "version": "1.0.6",
      "requirements": []
    },
    "hacs": {
      "version": "1.23.0",
      "requirements": [
        "aiogithubapi>=21.11.0"
      ]
    },
    "magic_areas": {
      "version": "3.0.0-beta",
      "requirements": []
    },
    "pyscript": {
      "version": "1.3.2",
      "requirements": [
        "croniter==1.0.2",
        "watchdog==2.0.3"
      ]
    },
    "alexa_media": {
      "version": "3.10.15",
      "requirements": [
        "alexapy==1.25.3",
        "packaging>=20.3",
        "wrapt>=1.12.1"
      ]
    },
    "icloud3": {
      "version": "2.4.6",
      "requirements": []
    },
    "adaptive_lighting": {
      "version": "1.0.14",
      "requirements": []
    },
    "grocy": {
      "version": "v3.0.1",
      "requirements": [
        "pygrocy==1.0.0",
        "iso8601==0.1.12",
        "integrationhelper==0.2.2"
      ]
    },
    "browser_mod": {
      "version": "1.3.1",
      "requirements": []
    },
    "plex_recently_added": {
      "version": "0.3.8",
      "requirements": []
    },
    "garbage_collection": {
      "version": "4.6",
      "requirements": [
        "python-dateutil>=2.8.2"
      ]
    },
    "scheduler": {
      "version": "v0.0.0",
      "requirements": []
    },
    "var": {
      "version": "0.12.3",
      "requirements": []
    },
    "notify_mqtt": {
      "version": "0.1.1",
      "requirements": []
    },
    "anniversaries": {
      "version": "4.5.0",
      "requirements": [
        "python-dateutil>=2.8.1",
        "integrationhelper>=0.2.2",
        "voluptuous>=0.12.1"
      ]
    },
    "attributes": {
      "version": "1.2.0",
      "requirements": []
    },
    "saver": {
      "version": "v1.1.3",
      "requirements": []
    },
    "weatheralerts": {
      "version": "0.1.5",
      "requirements": []
    },
    "pid_controller": {
      "version": "v1.1.3",
      "requirements": []
    },
    "blitzortung": {
      "version": "1.0.1",
      "requirements": [
        "paho-mqtt>=1.5.0"
      ]
    },
    "calendarific": {
      "version": "0.14.0",
      "requirements": [
        "sampleclient",
        "integrationhelper"
      ]
    },
    "car_wash": {
      "version": "1.5.2",
      "requirements": []
    },
    "spotcast": {
      "version": "v3.6.27",
      "requirements": [
        "spotify_token==1.0.0"
      ]
    },
    "authenticated": {
      "version": "21.9.0",
      "requirements": []
    },
    "holidays": {
      "version": "1.7.1",
      "requirements": [
        "python-dateutil>=2.8.2",
        "holidays>=0.13"
      ]
    },
    "o365": {
      "version": "v2.3.1",
      "requirements": [
        "O365==<IP_ADDRESS>",
        "BeautifulSoup4>=4.10.0"
      ]
    },
    "cryptoinfo": {
      "version": "0.0.10",
      "requirements": []
    },
    "readme": {
      "version": "0.4.0",
      "requirements": []
    },
    "config_check": {
      "version": "0.1.1",
      "requirements": []
    },
    "powercalc": {
      "version": "v0.18.4",
      "requirements": [
        "numpy>=1.21.1"
      ]
    },
    "schedule_state": {
      "version": "0.12.2",
      "requirements": [
        "portion==2.2.0"
      ]
    },
    "thermal_comfort": {
      "version": "1.4.3",
      "requirements": []
    }
  },
  "integration_manifest": {
    "domain": "holidays",
    "name": "Holidays",
    "version": "1.7.1",
    "documentation": "https://github.com/bruxy70/Holidays/",
    "issue_tracker": "https://github.com/bruxy70/Holidays/issues",
    "iot_class": "calculated",
    "dependencies": [],
    "config_flow": true,
    "codeowners": [
      "@bruxy70"
    ],
    "requirements": [
      "python-dateutil>=2.8.2",
      "holidays>=0.13"
    ],
    "is_built_in": false
  },
  "data": {
    "entity_id": "calendar.holidays",
    "state": null,
    "attributes": {
      "next_date": null,
      "next_holiday": null,
      "last_updated": null,
      "holidays": {}
    },
    "config_entry": {
      "entry_id": "79fbd98da7963089e2d3743686067c21",
      "version": 2,
      "domain": "holidays",
      "title": "Holidays",
      "data": {
        "unique_id": "41ab6991-7b97-48d7-9ad5-7d2e0edfdb5c",
        "icon_normal": "mdi:trash-can",
        "icon_today": "mdi:delete-restore",
        "icon_tomorrow": "mdi:delete-circle",
        "country": "US",
        "observed": true,
        "subdiv": "KS"
      },
      "options": {},
      "pref_disable_new_entities": false,
      "pref_disable_polling": false,
      "source": "user",
      "unique_id": null,
      "disabled_by": null
    }
  }
}

Debug logs
2022-03-04 19:29:14 ERROR (MainThread) [homeassistant.helpers.entity] Update for calendar.holidays fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 521, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 726, in async_device_update
raise exc
File "/config/custom_components/holidays/calendar.py", line 243, in async_update
await self._async_load_holidays()
File "/config/custom_components/holidays/calendar.py", line 75, in _async_load_holidays
hol = create_holidays(
File "/config/custom_components/holidays/__init__.py", line 137, in create_holidays
return holidays.country_holidays(country, **kwargs)
AttributeError: module 'holidays' has no attribute 'country_holidays'

Not sure what is your installation type. But you need to have holidays library version 0.13. This normally comes with HA 2022.3.x (with teh workday integration) . Looks like not on your system for some reason. Do you perhapos have a custom version of workday?

It's containerized; it shows as unknown, I think, because I'm running it in k3s rather than docker.
No custom version of workday, but curiously enough, I've had an issue with workday as well after this upgrade, so given your comment I took a look under deps and found that for some reason there was an old version of the holidays library (0.12) installed in there, presumably from a previous install of this (not sure I have anything else that uses it)? Deleting that seems to have fixed both this issue and the one with workday.


[ch123224] Optimize dashboard loading when the number of datasets is very large - v2

Resources

Clubhouse story

This is the continuation of the following PRs:

https://github.com/CartoDB/cartodb/pull/16014
https://github.com/CartoDB/db-connectors/pull/61

Context
The performance was improved for the requests to the VisualizationsController#index, but for the ones that include types other than table, the performance is still bad. The main problem is that the Carto::Visualizations doesn't have a user_table associated directly. They have "related tables" through the data_layers of the related map, and to load them for a lot of visualizations is too slow.
Since the total statistics are only required for the filters in the datasets section, according to Filters component, the best improvement would be to only load the DO totals when those values are required.
Changes

Add a new parameter load_do_totals to request explicitly the loading of the DO totals, and use it in the dataset section requests.
Refactor Carto::Api::VisualizationsController#index.
Update tests properly.

Adding @jgoizueta as representative of DB connectors


MSID: 91168 Version: 2 DOI: 10.1101/2<IP_ADDRESS>9306

MSID: 91168
Version: 2
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>9306
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=91168
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>9306

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/91168v2
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>9306
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/91168/v2/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

Hi @acollings, please could you assist with rewording this Assessment? Thanks

Thanks @fred-atherden should be sorted!

Thanks


MongoError: auth fails / Unable to define multiple connections Sails v0.10.5

I experienced something similar with 0.10.5 as issue #2123 . After inspecting the connectionString, I found the issue that the password was being prefixed with whitespace.
error: A hook (`orm`) failed to load!
error: MongoError: auth fails

While debugging to fully isolate the whitespace issue, I noticed some more odd behaviour.  I made it to build-orm.js from the actual sails-mongo adapter, but even there while inspecting sails.config.connections, I found that the first connection's password would be fine, but the subsequent ones would have the whitespace prefix. I was able to work around it by simply assembling my own connectionString.  But it was a quick fix, and doesn't address the root cause - which I'm still working on isolating.
Lastly, I found that when I have multiple connections (remote/sails-mongo) defined, I received the following:
error: A hook (`orm`) failed to load!
error: Error: failed to connect to [localhost:27017]

I highlight the connections being remote because for a reason unknown it is defaulting to localhost.  Also, because if there are two connections but one of them simply disk, it doesn't happen, and the remote connection is still successful.  Lastly, not sure if related, but I found that specifying the default connection name in env/production/development  or models.js doesn't make a difference.   I'm not familiar enough with the codebase, and too tired at the moment to continue this investigation :-P

Is this still going on?