Add @deprecated and @experimental GDScript annotations pointing to comments

These annotations don't exist at a source level, so the new annotations are only here to point to the documentation comment syntax.
This makes it easier to discover the feature as it'll now appear in the help search as well.

This closes https://github.com/godotengine/godot-proposals/issues/7622.

Testing project: test_gdscript_deprecated_experimental.zip
Preview

Is the long term objective to have these as actual annotations? Or is this how we want it to work going forward?

You can check and generate the error here:
https://github.com/godotengine/godot/blob/aa8d9b83f66488dbb2c9c918e9016ef80f821fb4/modules/gdscript/gdscript_parser.cpp#L1626-L1629

I gotta say, going as far as making these annotations actually supported, documented and overall entirely valid, only to then consider them errors is a very unsatisfying way to go about this.

Note that @deprecated, @experimental, and @tutorial are not annotations, but doc comment tags. They just both use the same symbol @. See GDScript documentation comments.
@deprecated and @experimental are implemented as doc comment tags, because they are part of the documentation system and use the same BBCode markup as descriptions. There is no way to declare an API deprecated/experimental "fundamentally", through core systems like ClassDB, Object, Script. In the engine and extensions we just edit XML files. So I think it makes sense for GDScript to have it just as part of doc comments, not at the language level.

You may say as such, but from the user's perspective this still remains a somewhat perplexing decision.

Would you prefer the following?
@description("""
Do something for this plugin. Before using the method
you first have to [method initialize] [MyPlugin].[br]
[color=yellow]Warning:[/color] Always [method clean] after use.[br]
Usage:
[codeblock]
func _ready():
    the_plugin.initialize()
    the_plugin.do_something()
    the_plugin.clean()
[/codeblock]
""")
@deprecated("Use [method other] instead.")
func do_something():
    pass

Im not sure about the description one, but I prefer it for the deprecated and experimental ones

You can check the name and adjust the error message here:

The downside is that they won't appear in the class reference anymore. That said, it may be preferable to create a pseudo-class (like @GlobalScope) to document GDScript documentation comments specifically, e.g. @GDScriptComments.

I don't like the idea of reserving a name with no proper implementation. If custom annotations became a thing, this API should be removed immediately to allow these otherwise valid names to be usable.
Documenting other things in the class ref sounds great, I've made a proposal for this as well. I'd prefer it to be less hacky and better integrated with the rest of the docs, but I see no clear solution for implementation here.
Or simply hard-coding the error message to substitute the generic "annotation not found" error just for these specific annotation names, without registering them as annotations.

Declaring a class member deprecated/experimental does nothing at the language level, it doesn't even produce warnings like in C#. And we don't have a foundation for this, the same in the core. Deprecated/experimental is just metadata, just like the description.

That's outside the scope of this PR, but IMO we should add support for deprecated/experimental at the language level. In my understand, this was the plan all along but we merged the quick-and-dirty "edit the XML" approach first, and that ended up being permanent.
Ideally we'd support ClassDB::bind_deprecated_method or ClassDB::set_method_deprecated etc. and make proper use of this information:

To add the flag and deprecation message in the XML.
To flag deprecated methods as such in the autocompletion.
To generate warnings that help users port their code to non-deprecated methods.
Possibly to remove them from the API if #ifdef DISABLE_DEPRECATED.

If we do this, then adding the annotations to GDScript would make sense too.
Until then, I tend to agree with RedMser that just hardcoding a check for those two in the error message for unknown annotations might be better than creating ineffective annotations.

To be honest, I didn't even think that someone would try to use unknown keywords/annotations. Usually, if I don't know if a language has a feature, I open the documentation or a search engine, rather than trying to use a random construct.
In my opinion, checking for non-existent things should only be done if it's a common and frequent mistake, or if the user might be confused by autocomplete, etc. Yes, we have a check for the C-style ternary operator. But I'm curious how often users try to use the operator without reading the docs. Would users draw a different conclusion if they got a generic "Invalid token" error instead of a dedicated message?
Built-in help lacks many things that the online documentation has (shader reference, RichTextLabel BBCodes, Expression operators, GDScript keywords, etc.). If we want to include this in the built-in help, we should create pseudo-pages (like @ShaderReference) and/or add support for custom sections in existing doc pages.
Regarding @deprecated and @experimental annotations, I think the current consensus is that we shouldn't register non-existent annotations solely for the purpose of documenting doc comment tags, especially in an unrelated section. Maybe in the future we'll upgrade the level of support for deprecated/experimental information and actual annotations will make sense, as akien-mga said.

I've pushed a commit that removes the annotation registrations and modifies the "unknown annotation" message instead.
Note that this means multiple @deprecated or @experimental invalid annotation uses will no longer show multiple errors, but only a single error for the first occurrence of the invalid annotation. This is also an issue with the original "unknown annotation" message which should probably highlight all error instances too.

The commit message/PR title should be adjusted since it's no longer adding annotations.

Thanks!


Clarifying title/project name

Hello,
Could you put more emphasis on the fact this is not exactly dear imgui but a rewrite?

I think the word "port" is misleading and using the word "rewrite" would be more clear and appropriate to the casual reader? (both to suggest that it doesn't provide the guarantee that dear imgui provides, but also suggesting your version may be a better fit for java/kotlin users)
Change the title of the page and in licence at the bottom from e.g. "dear imgui" to "dear jvm_imgui"
I also feel renaming the repo e.g. kotlin-graphics/imgui/ to kotlin-graphics/jvm_imgui (or another name) would help convey this. (Note that github redirect old repo names.)

They are merely suggestions, and I see there are already efforts to reduce ambiguity but I believe there's still a lot of possible confusion for the reader. Those are the suggestions I have here.
Thank you!

Hello Omar!
Yeah, sure
as you see there are already links and descriptions to your original library and your work (with credits and description of your development process at the end) and I believe port is equivalent to rewrite, it's also very common in the jvm world
Nonetheless if you think there might be still some space for confusion, I'll do as you suggest to be double sure people don't misunderstand, since I have absolutely nothing against it and I own you this very nice gui :)
so, I just committed:

I replaced all five port occurrences with rewrite in the readme
changed the title of the page and the license at the bottom from dear imgui to dear jvm imgui
regarding the repository renaming, I kind of dislike it. I had myself this doubt very long time ago and I decided against for various reasons I'll tell you now

First of all, because if I do rename the repository, I shall do the same for all the others for coherenc:, this mean assimp, openvr, gli, glm, ovr and bullet will all become jvmAssimp, jvmOpenvr, jvmGli, jvmGlm, jvmOvr, jvmBullet...
What about the others, since they don't have have a c++ counterpart, and gln too which also fits directly within glm and gli, it wont be usually listed together with the two just mentioned (with alphabetical order).
I also kind don't particularly love camelCase projects names (it makes harder to distinguish capital i from l) or names containing _ in the middle (some IDEs, such as Netbeans, will ctrl-jump the whole world).
So at the end we would end up with a lot of projects starting with the same name jvm*.
Also this noise will be in the IDE, as you will see tons of jvm* everywhere (which we already do often for others stuff) and in the emails when you get replies/notifications (the source is always clear because the organization/owner name is always present).
Moreover, I really love very short (conciseness is also one of the main reasons of my preference for kotlin), syntetic and lower names (I plan even to change uno-sdk to simply uno and Vulkan to vulkan).
I find it also fits quite nicely with the way we declare dependencies using Gradle in our build.gradle.
This is also the same reason I didnt standardized also the repository name it when you prefixed at the time all the imgui occurrences with dear (althogh I see you also didn't change the repo, probably on the same wave of mine)
Anyway, to overcome this last point, I added this explicit sentence (rewrite of dear imgui) right in the project description, which is visible directly at first sight at the organization level. This will be also visible at first sight in google once its cache gets updated.
I hope you will appeciated (and understand) :)

Thanks a lot, this is more than good enough for me!
I didn't realize you had a whole ecosystem of library and agree it makes sense to keep the /imgui repo name in your case.
Good luck ahead!

Glad to read that..
Ps: forgot to say, I also added It doesn't provide the guarantee that dear imgui provides, but it is actually a much better fit for java/kotlin users. at the beginning paragraph


Sonoff L1 shown as Entity but not as a device

Hi Alex
Kudos for a great job and thanks your help on the last issue I raised - sorted👍
I can access the Sonoff L1 LED Strip via Lovelace dashboard but assigned to area : lights (See pic)

I can’t seem to be able to move to a room and when I look at my device list to do this - it doesn’t exist yet it does under entity list. Is this right?
Sonoff L1 v2.7.0 firmware
Thanks again

Duplicate #83


Add react and react-dom to devDependencies for the docs

I tried installing React 15 and encountered issues with installing the modules. Looks like we need react and react-dom in dev mode for our examples page. Not sure if this was related to React 15 but worth looking into it.

:+1:


Code actions, completions and signature help support for the new Query syntax

Description:
$title for the new query syntax which has a limited tooling support now.

This has been addressed with the latest changes, hence closing the issue


[vm_deploy] does not check for available disk capacity

Description
You can deploy any number of VMs on the same datastore as long as the disk size is under the TOTAL_MB size.
In other works, vm_deploy does not check the ALLOCATED capacity, and it can't since the ALLOCATED capacity is not a computed parameter.
This is a HUGE issue, due to the fact that when the allocated space starts to fill up and the VMs will start crashing due to overprovisioning.
To Reproduce
Create a new datastore with 30GB.
Create 2 new VM under this datastore with 20GB each.
Expected behavior
The 1st VM should provision.
The 2nd VM should fail due to unavailable space.
Details
The 2nd VM does not fail, as there is indeed free space on the DISK due to thin provisioning. Other types of provisioning are available mostly for vCenter, but the ALLOCAED space has been overprovisioned.
It should fail to provisioning returning an error with not available space.
Affected versions:

<IP_ADDRESS>-CE
6.8.0-CE

The same behavior can be observed in vm_disk_resize.
Details available in:
https://github.com/OpenNebula/one/blob/master/src/rm/RequestManager.cc
https://github.com/OpenNebula/one/blob/master/src/rm/RequestManagerVirtualMachine.cc
Please raise the priority to HIGH as all production environments are affected.
Related:
https://github.com/OpenNebula/one/issues/1982

I agree with your @TGM , but this more like a feature request than a bug. I think the idea of the cloud is to give you the chance to create VMs as many as you want, and the cloud admin should have a monitoring system to check the FS usage....if you are running out of space, you know you need to add more disks to your cloud, so user dont be affected.

while the idea is that, without a metric for allocation, it's impossible to know overindexing of resources before it's too late.
It's not impossible to have a case where lots of vm gets allocated and suddenly all the guests start generating data that fills a lot of storage, causing failures all over the place if overallocated over certain amounts.
So one should be able to overallocate, but one should be very much aware of how much over-allocation is happening, so this information is paramount to have for proper management of a large platform, both in metric form and something that's easy to see from dashboards


NTR: convolved/deconvolved sequence data and ?term label mismatches

We have:
sequence library multiplexing:
definition "a planned process which consists in running a set of samples as a pool in one single instrument run of data acquisition process while retaining the ability to associate individual results to each of the individual input samples thanks to the use of a multiplex identifier, introduced during the ligation step of the individual library preparation and specific to a given sample."@en
http://purl.obolibrary.org/obo/OBI_0001959
and we have
"sequence library deconvolution"
definition "is a data transformation which uses sequence alignment and  'multiplex identifier sequence' information to pull together all reads belonging to a given single sample following the sequencing of a multiplexed library which combining several samples in one sequencing event"
http://purl.obolibrary.org/obo/OBI_0001966
To link these two concepts, we need new terms, either "convolved sequence data" or "multiplexed sequence data", and "deconvolved sequence data" or "demultiplexed sequence data" .  In my group we call this kind of data multiplexed/demultiplexed, but if the process is already called deconvolution...maybe it should be convolved/deconvolved.  Parent should be "sequence data" http://purl.obolibrary.org/obo/OBI_0000973.
Then we could add the axioms:
"sequence library deconvolution" has specified input "convolved sequence data"
"sequence library deconvolution" has specified output "deconvolved sequence data"

I asked our Bioinformatics lead, Will Hsiao about deconvoluted vs demultiplexed.  According to him, demultiplexed sequence or read data is used more specifically in conjunction with barcoding to describe sequences or reads that have been separated out (digitally) from pooled data usually from a sequencing run.
Deconvolved data he says pertains more to methods used to correct error or weed out extraneous signal, so it speaks to error correction within the realm of bioinformatics.  I see convoluted/deconvoluted data has its roots in math/engineering world as a means to describe an initial signal that has been contorted by other signals or noise.
From: DNA sequencing and parametric deconvolution (2001)
"A large portion of DNA sequencing errors come from the di#usion e#ect in electrophoresis, and deconvolution is the tool to solve this problem. "
This suggests to me that we could try to keep the meanings separate - using "multiplexed/demultiplexed" for data involving processes that focus on the "multiplex identifier", and "deconvolution" for processes that are involved in finding the prototypical or error-corrected sequence.

I.e. OBI_0001966 "sequence library deconvolution" should actually be "sequence library demultiplexing", and we should only be referencing multiplexed/demultiplexed sequence data.

I would agree with that.
On Mon, Jul 30, 2018 at 10:00 PM, Damion Dooley<EMAIL_ADDRESS>wrote:

I.e. OBI_0001966 "sequence library deconvolution" should actually be
"sequence library demultiplexing", and we should only be referencing
multiplexed/demultiplexed sequence data.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/obi-ontology/obi/issues/941#issuecomment-408991035,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANN9IvzZZ0tkiRu8qVgA8GE_7G3FIkhHks5uL2XvgaJpZM4Ue2Gw
.

--
Bjoern Peters
Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

I agree we should multiplexing/demultiplexing in the sequencing assay context, particularly for multiple samples.  I think "sequence library data demultiplexing" is better than "sequence library demultiplexing", because it's a transformation of the library read data, not the library biosamples.

Changing "sequence library deconvolution" class label to "sequence library data demultiplexing".
Adding concepts for "multiplexed sequence data" and "demultiplexed sequence data".
Refining existing concept "multiplex nucleotide library sequencing", so that it's output is multiplexed sequence data.

Refining axioms for "sequence library data demultiplexing".


Formatting shortcut (cmd-k cmd-f) no longer working on mac

VSCode Version: Version 1.17.1 (1.17.1)
OS Version:  OS X 10.13 (17A405)

Steps to Reproduce:

Select text to format
Press Command-K Command-F
You get the message in the status bar that "the key combination (command-K command-F) isn't a command.
However, when you go to see the shortcuts we see:
{
"command": "editor.action.formatSelection",
"key": "cmd+k cmd+f",
"when": "editorHasDocumentSelectionFormattingProvider && editorHasSelection && editorTextFocus && !editorReadonly"
}

so command-k command-f is certainly defined.

@jyavenard in what kind of file does this happen? I cannot reproduce it in a TypeScript file.
The when clause is editorHasDocumentSelectionFormattingProvider and not all language services provide a selection formatter.

C++ file

Looks like the C++ extension doesn't provide a formatter that can support the selection only. I suggest that you file a feature request against the C++ extension https://github.com/Microsoft/vscode-cpptools, nothing we can do about this on the VS Code side.

You're kidding right?
Formatting a selection worked just fine until I updated VS Code this morning....
You've dropped the usefulness of VS Code by half with whatever change you decided to make.
And the CPP provides all tools to format the code.
"C_Cpp.clang_format_path"
Please re-open, your conclusion is obviously wrong

We support this in the C++ extension. I suspect that the extension is currently unresponsive. There is a known issue on mac/linux causing the extension to stop receiving messages from VS Code. Try using the "Reload Window" command to reset the extension and formatting should work again.
Sorry for the inconvenience!

@bobbrow It didn't work after my first reload.. It did work again the 2nd time.. So indeed, it appears to be an intermittent issue...


refactor(gyro_odometer)!: prefix package and namespace with autoware

Description
This PR will add a autoware_ prefix to gyro_odometer.
Related links
Parent Issue:

https://github.com/autowarefoundation/autoware/issues/4569

How was this PR tested?
Checked it works with autoware sample-rosbag.
Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

Resolved conflicts.

@a-maumau
Sorry, some conflicts occurred again. Please check .github/CODEOWNERS.

@SakodaShintaro I fixed the conflict.

The following error occurred:
+ rosdep install -y --from-paths src --ignore-src --rosdistro humble
ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
tier4_localization_launch: Cannot locate rosdep definition for [gyro_odometer]

I fix the launch/tier4_localization_launch/package.xml, so I think the issue is fixed.

@a-maumau
Unfortunately, .github/CODEOWNERS conflicts again :(

I resolved the .github/CODEOWNERS.


Added US-4 Support

Sorry about the previous bad PR.

Sorry about the previous bad PR.

sure, no problem
US-4 or US-WEST-4 ?

We also need EU-CENTRAL3. I don't have an account in that region. Do you know what the API gateway is?


fix(docs): fix toc links in faq and recipes

Fixes the TOC links under faq and recipes with the correct anchor tags
Issue: https://github.com/reduxjs/redux/issues/3090

Thanks!


support mermaid diagram blocks

It would be cool to render mermaid diagrams, like github markdown:
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams#creating-mermaid-diagrams

Agreed, would be nice to have. It's too late for 0.19.0 which is nearing its completion, but I'll add it for the 0.19.1 milestone as there is probably a binary-compatible way to implement it.

Or PlantUML since that may be more aligned as it has a Java Library

Completed in #516


Update tantivy to v0.22

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Note: Only English and Chinese posts are allowed in the issues section. English is preferred.
请使用英文或中文发 issue.

Done in https://github.com/Endle/fireSeqSearch/pull/140
Need some time to merge into master


Creating networks via docker

There's not much point in having the whole driver subsystem unless one can actually create a network. I don't see that as part of docker/docker#13060.
If it is a requirement to not add new commands to docker (e.g.,docker network create), then perhaps it can be part of the syntax of the --net argument. For example,
docker run --net=weave:mynet

where weave refers to the driver, and mynet is a network created with that driver (if it doesn't already exist).

@squaremo docker/docker#13060 is only the first of a set of PR which will made in there. So the short answer is it's coming. The idea is to implement the majority of the CLI handles and remote API handlers in libnetwork itself and just hook it up to docker core with a small function. Introducing a new UI or remote API in docker needs more discussion and that's why the goal of docker/docker#13060 has been limited to modularize networking code out of docker and providing a clean interface to networking code for docker or anybody else to use.
BTW, for the initial implementation of CLI handlers take a look at libnetwork/client code

Also, we are currently integrating the libnetwork/client with libnetwork/api as we speak and we will have a dnet tool that makes use of these. As @mrjana suggested, the docker CLI integration will follow soon after #13060 is merged.

Another requirement: the ability to add more than one network in the same invocation is quite important. Typically one interface will provide internet-in-general access, and one will be the "cluster" network (e.g., weave).

@squaremo so assuming weave1 is a  network created using the weave driver, you'd want --net=bridge --net=weave1?

so assuming weave1 is a network created using the weave driver, you'd want --net=bridge --net=weave1?

Yes exactly. One wrinkle is that typically we'd want the bridge driver to set the default gateway, but the weave driver to provide (or at least influence) the /etc/resolv.conf.

Thanks @squaremo, @mavenugo this seems like a sensible requirement. Are multiple occurrences of the --net flag going to be supported in the integration PR mentioned above? If not, can we add them?

@dave-tucker @squaremo no. I will be pushing https://github.com/mavenugo/docker/commit/c0c7f372375b3bd112c6e0aaa28001f495273782 shortly. This is based on the discussions that i followed for volumes, the idea is to introduce --network-driver instead of overloading the --net string. We need to find a way with these constraints.

@mavenugo Does --network-driver coexist with --net; i.e., could one use
docker run --net=bridge --network-driver=weave -ti ubuntu

and expect a bridge interface as well as a weave interface?

@mavenugo right, I'm not talking about overloading of --net here, I'm talking about supporting multiple occurrences of --net assuming that a network has already been created using the docker network create CLI

If there are going to be multiple --net's, is there an idea on how to pass network labels per --net?

@dave-tucker @squaremo @shettyg All are valid and reasonable questions. There are a few trade-offs to be made between simple, consistent UI & functionality. I will get back to you all later today.

It hasn't been discussed here yet, but my expectation is that labels are namespaced per the docs
docker run -it --net=bridge --net=weave1 -net=vmware1 -l works.weave.foo=bar -l com.vmware.baz=quux debian:jessie
A driver should get passed all labels, but only respond to those in it's namespace

It hasn't been discussed here yet, but my expectation is that labels are namespaced per the docs
docker run -it --net=bridge --net=weave1 -net=vmware1 -l works.weave.foo=bar -l com.vmware.baz=quux debian:jessie
A driver should get passed all labels, but only respond to those in it's namespace

Ah, but the label namespaces correspond to the driver name, rather than the network name. So if a container has two endpoints provided by the same driver, how will that driver know which labels apply to which endpoint?

Prefix the label with the network name?  E.g works.weave.weave1.foo

@squaremo @dave-tucker @mavenugo  Is it very important to support to support multiple networks in docker run command. docker run can be used to join the initial network. There are always going to be network service join commands to join additional endpoints after the initial join. I know this is racy to some extent if the application wants to communicate in the "cluster" network immediately but then we are probably risking introducing something hastily here. Please let me know what you guys think?
Also the labels in the docker run command are always going to be considered as container labels and are given to the driver only on joins

There are always going to be network service join commands to join additional endpoints after the initial join. I know this is racy to some extent if the application wants to communicate in the "cluster" network immediately but then we are probably risking introducing something hastily here.

@mrjana, the raciness may be important IMO. Many badly written applications will simply fail when they can't reach out to peers. So you are effectively expecting applications to be written in a way that IP reachability to a peer should always have retry logic.

@shettyg I am not saying solving the raciness is not important. But it is much more important to get the UI right, otherwise it is very difficult to revert it back.

@shettyg I think the race condition manifests in ways that are worse than "simply fail".  E.g. if your container has a service that listens on <IP_ADDRESS>, it will listen on all interfaces that are active /at the time you do the listen/; it will not add interfaces that are added later.

I know this is racy to some extent if the application wants to communicate in the "cluster" network immediately

It's already the case that you can add a weave interface to a container after the fact; avoiding the extra command (and the entailed race) is the primary motivation for developing a plugin.
Weave needs containers to have an interface on the bridge network as_well, and for this not to be racy or require extra commands, since it's used to provide name resolution.

Since endpoint creation has been separated out, would something like the following not work for anyone?

docker network create NETWORK --driver=driver1 --labels foo=bar
docker endpoint create NETWORK --labels alice=bob

With the UUID returned by the endpoint creation (Similar syntax as --net=container:containerid):

docker run --net=bridge --net=driver1:EP_ID1 --labels driver1.ep_id1=foo --net=driver2:EP_ID2 --labels driver2.ep=bar command

The above only calls join() and skips createendpoint().

@shettyg There is an important difference between an endpoint that is created during docker run and an endpoint created ad-hoc; the former is garbage collected when the container stops, but the latter will hang around until deleted explicitly. That latter behaviour requires much more diligence on the part of the user, especially since it won't necessarily be obvious when those endpoints can reasonably be deleted.

@squaremo
I see what you mean. I wonder whether we can do both. For e.g., one could do:
docker run --net=bridge --net=driver1:mynet
In the above case, you would call createendpoint() and join()
Alternatively,
docker run --net=bridge --endpoint=driver1:uuid
In the above case, you would only call join()
My suggestion likely won't fly because now there is a new docker cli option '--endpoint'.
(According to @mrjana, labels provided to createndpoint() and join() are different, so that is another constraint with which this has to work)

I believe https://github.com/docker/docker/pull/13441 will address this issue, in part, but seems caught up in bikeshedding :(

It looks like Solomon's 'docker run --publish-service db.work-dev' is similar to my 'docker run  --endpoint=driver1:uuid'

@mavenugo @dave-tucker can this issue be closed now that it is tracked under https://github.com/docker/docker/issues/14593

Thanks @tomdee, closing in favour of docker/docker#14593


about torch2onnx question in 3.x version

there is no pytorch2onnx.py file in 3.x and main version, how can i export the pth model to onnx?
1、i try use the open-mmlab / mmdeploy, but meet the error:
RuntimeError: Only tuples, lists and Variables are supported as JIT inputs/outputs. Dictionaries and strings are also accepted, but their usage is not recommended. Here, received an input of unsupported type: InstanceData
04/26 15:34:22 - mmengine - ERROR - /home/heyue/miniconda3/lib/python3.8/site-packages/mmdeploy-1.0.0-py3.8-linux-x86_64.egg/mmdeploy/apis/core/pipeline_manager.py - pop_mp_output - 80 - mmdeploy.apis.pytorch2onnx.torch2onnx with Call id: 0 failed. exit.
2、i use the  follow code，but the output model doesn‘t include the post nms processing,
torch.onnx.export(model,
dummy_input,
"yolox_nano.onnx",
verbose=True,
input_names=['input'],
output_names=['dets', 'labels'],
keep_initializers_as_inputs=True,
opset_version=12,
do_constant_folding=True)

Any update on this ? How can we export model to onnx in latest version ?


Deal with initialNavigation in SSR mode

Hi,
I'm trying to follow this guide to enable  initialNavigation in the Universal project.
It looks like something is not working properly, as soon as I start up the application (it is enough to use ng serve to reproduce the issue) the page is not rendering correclty.
Please refer to this project to reproduce the issue.
Thanks in advance

Thanks! Could be similar to this issue ?

Thanks, I've made the change and updated the package to 15.0.1. This commit https://github.com/penleychan/ngx-transloco-router/commit/61eea21f40b22c3f0eb360becd63cb63c8796287 should fix the issue.


javax.el/3.0.0

Type: Missing
Summary:
javax.el/3.0.0
Details:
No info in package files. Pom file confirms GPL 2.0 or CDDL 1.1.
Resolution:
https://repo1.maven.org/maven2/javax/el/javax.el-api/3.0.0/javax.el-api-3.0.0.pom
Affected definitions:

javax.el 3.0.0

@capfei I would curate as "CDDL-1.1 OR GPL-2.0-with-classpath-exception", do you agree?

@AE49 Yes, it should be GPL-2.0-only WITH Classpath-exception-2.0.


add blog about OpenFunction TOC

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

@yangchuansheng You need to sign the commit by git commit -s --amend and then git push -f
It will be better if you sign the CLA as well


[SPARK-34795][SPARK-35192][SPARK-35293][SQL][TESTS][3.1] Adds a new job in GitHub Actions to check the output of TPC-DS queries

What changes were proposed in this pull request?

This PR proposes to add a new job in GitHub Actions to check the output of TPC-DS queries.
NOTE: To generate TPC-DS table data in GA jobs, this PR includes generator code implemented in https://github.com/apache/spark/pull/32243 and https://github.com/apache/spark/pull/32460.
This is the backport PR of https://github.com/apache/spark/pull/31886.
Why are the changes needed?

There are some cases where we noticed runtime-realted bugs after merging commits (e.g. .SPARK-33822). Therefore, I think it is worth adding a new job in GitHub Actions to check query output of TPC-DS (sf=1).
Does this PR introduce any user-facing change?

No.
How was this patch tested?

The new test added.

NOTE: Since it is difficult to backport these commits separately, I made a single PR for them.

Test build #138225 has started for PR 32462 at commit b8fc22b.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42747/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42747/

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

We are not going to bring SPARK-35327, right? If you want SPARK-35327 too, let's hold on this PR.

Test build #138225 has finished for PR 32462 at commit b8fc22b.

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

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

We are not going to bring SPARK-35327, right? If you want SPARK-35327 too, let's hold on this PR.

Yea, right. That should be included in this PR, too.


Fix dtype deserialization

Closes #820

Okay so not only the incoming dtype needs to be deserialized correctly, but in some cases also the structured arrays. So the changes needed are a little more extensive.

Shape Validation (mongo):
https://github.com/danielballan/databroker/blob/6c7c26a8752709ee102e2551c2a12bd4d671a9f2/databroker/mongo_normalized.py#L932-L946

numpy.asarray(item): the conversion of item to an ndarray has to be done with the appropriate numpy dtype,  from the data_key['dtype_descr'] if it exists, and each structured array element has to be turned into a  tuple

Config xarray:
https://github.com/danielballan/databroker/blob/6c7c26a8752709ee102e2551c2a12bd4d671a9f2/databroker/mongo_normalized.py#L1081

columns[key] = numpy.array(column, dtype=numpy_dtype)
if numpy_dtype is a structured array, the data in column needs to be turned into a list of lists of tuples.
How would you like to proceed, sould I open my own PR or do you want to implement these changes?


fix(ci): fix flamegraph generation for rewritten queries

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Some queries left out of flamegraph generation because of bad regex / not synced with kube-bench sink templates.
Fixes q6 as well to use blackhole sink.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR contains user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

Only left q5 not passing, but it's just due to buildkite cancelling the job.


Fix typo in pre-commit file name

If no pre_commit_dir exists the --install-pre-commit option creates a pre-commit hook with the file name pre_commit in .git/hooks/ resulting in the pre-commit hook not working. This pr fixes the typo.

Can't believe I missed that, thanks for fixing!

:) Thank you for creating a great tool!


[Upstream] What's the best practice to update upstream

When using service manager system like nacos, only all instances could be get without know whether some instance got added or removed.
In this case, how to update the upstream? One way may be calling each instance with upstream_replace_server, is this
the suggest way?
Another suggestion about upstream:
It will be useful if upstream could have a interface which could return the final address (e.g. ip with port), thus could integrate
upstream with third party service easily.

OK, it is an interesting topic. In our framework you need to create an upstream name before adding a server. But any operation on upstream, creating or  adding/replacing servers, is absolutely thread-safe. You may call the upstream interfaces any time you want. But currently we don't support adding servers to an upstream name that doesn't exist. Maybe we will support this feature later.

OK, it is an interesting topic. In our framework you need to create an upstream name before adding a server. But any operation on upstream, creating or adding/replacing servers, is absolutely thread-safe. You may call the upstream interfaces any time you want. But currently we don't support adding servers to an upstream name that doesn't exist. Maybe we will support this feature later.

Yes, any upstream operations are thread-safe, and you can always call upstream_replace_server to add or update a server. But we found a little bug in upstream_replace_server. We will fix it right away.

Fixed!

The first question: How to use other service manage system?
Of course you can use upstream_replace_server(). This api will remove the existed servers with this server_name, and guarantee to add a new one. The return value means how many servers is removed just now.
The second question: How to get the final addresses?
Sorry, you cannot get the ip with port in upstream. You can use void get_main_address(std::vector<std::string>& addr_list); to get all the servers you added before.

@hiberabyss


Typo fixed on useWindowSize documentation

Keep up the awesome work in this repo. It's an amazing idea and I can't wait for Vue 3 to be fully released so I can use this properly. For now, I'll help find typos. :)

Thanks! much appreciated.


Rendering Helm chart template for a single release, ignoring needs

Is it possible to run helmfile template --selector name=x to output the template for a release which has needs?
I updated to 0.132.0 but still can't get around in helmfile.yaml: "x" depends on nonexistent release "y" 😿
I'm trying to run some tests like kubeval and kube-score on the "final" release output as the YAML can be quite different based on the values in the Helmfile if the chart has conditionals in the template, so it would be much more useful to let Helmfile do its magic on it rather than just using the output of the vanilla chart with helm template.

https://github.com/roboll/helmfile/blob/16288dfa7da390bee208f46eaeb69061507c7ca8/pkg/state/state_run.go#L151
That appears to be where we are getting stuck.  I dont know go, but I assume this section of code has no idea if its a apply or a template.

I had a look in the code and it seems that the fundamental problem is that template seems to be running with the full withDAG release list: https://github.com/roboll/helmfile/blob/c170b5a62173872158ed424e7bcf3504bede9474/pkg/app/app.go#L1381
Whereas other misc ("non-executive", ie not touching k8s) commands like diff are in a different class and use custom code: https://github.com/roboll/helmfile/blob/b176408eb2c351f5730c914a12a72b587aac23f9/pkg/app/run.go#L115

@daaain @jseiser Thanks for reporting and the info! After some debugging, I realized that I had mistakenly inverted a necessary flag that resulted in the  --selector is applied and processed "before" computing the DAG. #1564 fixes that.
Just to be clear, the important point here is that we need to compute the DAG with all the releases, and then apply the selector to avoid missing the dep release error.
The bug resulted in applying selectors before computing the DAG. This code of block is for any helmfile command that doesn't support DAG yet, and shouldn't be called for commands like diff, apply, and template. #1564 fixes the flag for helmfile-template.

@mumoshu maybe I am not quite understanding the feature, but when I use the selector I see the DAG get rendered in the debug, but none of the needs resources are included.


Make Modipulate play nice with Love Audio/Sound

Right now, Bad Things(TM) happen when you try to use Love's own audio engine with Modiuplate.
Ideally, these should be able to work together.  Modipulate wasn't designed for playing sound effects, for example. Since Love already has a way to do this, we should use that.

Note that this changes the interface (slightly.)
modipulate.love() now takes an optional bool parameter.  If this is set to true, it will handle initialization of OpenAL inside Modipulate.  Otherwise, by default it will let Love (or any parent process) initialize OpenAL on its own.


DOCS: Remove the "global" dependency on writing .pod files from .pod.in

The dependency was made in such a way that .pod.in -> .pod generation
would always be done, no matter what.  This changes the procedure so
that the generation is made "on demand", i.e. when the resulting .pod
files are needed.
This turned out to be duplicated dependencies, as the .pod -> .pod.in
dependencies were already in place.  Just removing the duplicate fixes
the situation.
'make build_all_generated' still works, for those who do want to have
all file generations performed.  (as a reminder, this is suitable to
generate the files a fast system and then copy the result to a slower
system, or system where there's no perl)

doc-nits and cmd-nits failed.  Fixed by adding a separate make target to generate the pod files to be generated separately.
This requires re-approval.

Are the generated .pod files part of the release tarball? Does this change mean that the plain make won't build the .pod files on fresh git checkout? Will make install do it?

Are the generated .pod files part of the release tarball?

No

Does this change mean that the plain make won't build the .pod files on fresh git checkout?

It never did.  You have to say make all to get that effect, ... or

Will make install do it?

Yes, as it depends on install_docs, which depends on building the man files and the html files, and they in turn depend on the pod-files, and the generated pod-files depend on the .pod.in files.  [pfew] that was a mouthful...

b8393eae224d11276323957fcd493953d5b135b9 DOCS: Remove the "global" dependency on writing .pod files from .pod.in
9ca08f91e9817892c3545612a91d38687e593e14 Makefile template: Allow separate generation of .pod.in -> .pod


Requests timeout when making a large number

Hello,
I'm having issues with requests timing out. I'm parsing a CSV file that contains a large number of sites (10,000) and buffering (1000) records at a time and making requests to the sites. Each site is different and the maximum number of futures at any one time is under my OS's maximum allowed number of open files.
$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 62386
max locked memory       (kbytes, -l) 16384
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 62386
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

For a given run of the program:
$ ls /proc/28799/fd/ | wc -l
909

The code is done as follows:
        let fetches = csv_rx
            .take(10000)
            .map(|data| tokio::spawn(Agent::run(data, ctx.clone())))
            .buffer_unordered(1000)
            .collect::<Vec<_>>();

In another part, I'm listening for these requests and then spawning a thread to handle it:
      while let Some(req) = rx.recv().await {
            let fut = HostResolver::do_request(req, client.clone(), request_timeout);
            let _ = tokio::spawn(fut);
        }

The client is initialised as:
        let client = ClientBuilder::new()
            .connection_verbose(true)
            .timeout(Duration::from_secs(10))
            .build()
            .unwrap();

And each request is created as:
            let mut headers = HeaderMap::new();

            headers.insert(DNT, HeaderValue::from(1));
            headers.insert(UPGRADE_INSECURE_REQUESTS, HeaderValue::from(1));
            headers.insert(
                USER_AGENT,
                HeaderValue::from_str(
                    "Mozilla/5.0 (Windows NT x.y; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0",
                )
                .unwrap(),
            );
            headers.insert(ACCEPT, HeaderValue::from_str("text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9").unwrap());
            headers.insert(
                ACCEPT_LANGUAGE,
                HeaderValue::from_str("en-GB,en-US;q=0.9,en;q=0.8").unwrap(),
            );
            headers.insert(
                ACCEPT_ENCODING,
                HeaderValue::from_str("deflate, gzip").unwrap(),
            );

            let req = client
                .get(&uri.to_string())
                .headers(headers)
                .body(Body::from(String::new()))
                .build()
                .unwrap();

            let req = client.execute(req);

The problem that I'm having is that after a certain number of requests/time has passed, most of the requests start to fail and timeout:
error sending request for url (****): operation timed out

I've tried this is many different ways and with both Hyper and Reqwest and I'm a bit lost as to what the problem is. I've tried increasing the number of Tokio threads and creating a new Client instance for each request or after X requests have been made. The websites are all different host addresses and will work fine from a browser when the application is running.
Would anyone be able to provide any guidance?
Thanks!

As a simpler example of what's going on:
let fetches = csv_rx
    .take(100000)
    .map(|data| {
        let client = ClientBuilder::new()
            .connection_verbose(true)
// I've tried it without this property too
            .max_idle_per_host(0)
            .connect_timeout(Duration::from_secs(10))
            .build()
            .unwrap();

        let mut headers = HeaderMap::new();

        headers.insert(DNT, HeaderValue::from(1));
        headers.insert(UPGRADE_INSECURE_REQUESTS, HeaderValue::from(1));
        headers.insert(
            USER_AGENT,
            HeaderValue::from_str(
                "Mozilla/5.0 (Windows NT x.y; Win64; x64; rv:10.0) Gecko/20100101 Firefox/10.0",
            )
                .unwrap(),
        );
        headers.insert(ACCEPT, HeaderValue::from_str("text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9").unwrap());
        headers.insert(
            ACCEPT_LANGUAGE,
            HeaderValue::from_str("en-GB,en-US;q=0.9,en;q=0.8").unwrap(),
        );
        headers.insert(
            ACCEPT_ENCODING,
            HeaderValue::from_str("deflate, gzip").unwrap(),
        );

        let req = client
            .get(&data.uri.to_string())
            .headers(headers)
            .body(Body::from(String::new()))
            .build()
            .unwrap();

        let f = async move {
            match client.execute(req).await {
                Ok(r)=> {
                },
                Err(e)=> {
                    println!("Err: {:?}", e);
                }
            }
        };

        tokio::spawn(f)
    })
    .buffer_unordered(900)
    .collect::<Vec<_>>();

let _ = fetches.await;

This will start the 900 requests at the beginning, but the 10 second connect timeout with be started for all of them, and as the time goes by processing all the requests, the latter ones may timeout. If they are all to different sites, it's likely that DNS must be done for all of them, and that can be a common bottleneck.

This will start the 900 requests at the beginning, but the 10 second connect timeout with be started for all of them, and as the time goes by processing all the requests, the latter ones may timeout. If they are all to different sites, it's likely that DNS must be done for all of them, and that can be a common bottleneck.

Hi @seanmonstar, thanks for replying. I would have thought that the timeout would not start until the future begins? And then as it is on its own thread then this wouldn't be a problem? This is new to me so forgive my lack of understanding! I did also try another approach using Hyper and using tokio::timeout for the request but I know this is for the whole request and not just connect like Reqwest is.
If you can see what I'm trying to achieve here, would you have any recommendations for architect it differently/some advice as to how to go about it? I'm basically trying to execute as many of these futures as possible in parallel.

Do you have any suggestions as to how to investigate the bottleneck? Why the requests are timing out? I don't quite understand why they'll time out if they're all on their own thread.

That's true, the timeouts start when the future starts. What happens is all the futures as spawned, and then once they can't make progress, the other futures are started/polled.
The default DNS resolver uses the system resolver (well, getaddrinfo), which is blocking. So it runs in Tokio's blocking pool. That means it can only resolve a certain amount at a time (up to the max threads that you can configure). You could try enabling the trust-dns feature of reqwest, which provides a non-blocking DNS resolver that might help.
Another option you could try is to execute less requests at once (the value you're passing to buffered_unordered).

I've tried using the trust-dns feature flag and it's helped slightly but not solve the issue entirely. I think really that I'm trying to do a bit more than is possible. So I'll turn down the number of requests that are being buffered and just dial it back to something sensible.
To find a sensible value, is there a way to find out whether a request timed out due to the host not responding/not being available or due to DNS resolution taking too long?

Would you advise using one client for all of the requests or one per request?

One Client should be fine, more aren't going to allow the system to do more DNS at once.

Thanks! Also, is it possible to get the certificate details of the server from a request?

Not at the moment. We could open an issue about it. Would be good to gather use cases and proposed APIs.

It would certainly be useful. I'd quite like to log some information from
the certificates but the only way I can see to do it is using the openssl
crate, setting a verify callback and setting the X509 verification to none.
But that changes the verification process.
On Tue, 19 May 2020, 02:15 Sean McArthur<EMAIL_ADDRESS>wrote:

Not at the moment. We could open an issue about it. Would be good to
gather use cases and proposed APIs.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/seanmonstar/reqwest/issues/915#issuecomment-630517751,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUDHJZVM4664NRQWV2YHLLRSHMRPANCNFSM4NEDHYOQ
.

Well, we can open a new issue. I'm going to close this one, it seems like it's solved.


Copyright notice?

It looks like you have taken Michael Rushton's regex pattern as used in PHP, but you forgot to add the copyright notice?

 * Michael's regex carries this copyright:

523     *
524     * Copyright © Michael Rushton 2009-10
525     * http://squiloople.com/
526     * Feel free to use and redistribute this code. But please keep this copyright notice.

thx for the feedback -> fixed -> https://github.com/voku/email-check/commit/cb0ba41126bc79334745ae0607b721579bc1f8af


Request for Ctrl+D (find next): if no text is selected, find next whole word; if selected, match all occurrences instead (like in Sublime)

In Sublime Text, if you have nothing selected when you press Ctrl+D, it first selects the word where your cursor is at (VSCode also does this). Then, the next Ctrl+D will automatically use whole word search, regardless of the whole word setting.
If you have this:
wordword
word code word

And begin Ctrl+D'ing on the first standalone "word" in the second line, you will get:
wordword
[word] code [word]

(selections marked with [])
In contrast, if you already have text selected (with your mouse, or Shift+Arrow combinations), Ctrl+D will search WITHOUT whole word (i.e. matching all occurrences of the selected text even if they are not a complete token)
If select the first "word" in "wordword" with your mouse, you will get:
[word][word]
[word] code [word]

I hope my explanation was clear. :)
I understand that this might be something some users wouldn't want by default, but at least an option would be incredible, because this subtlety in Sublime avoids constantly changing whole word modes (case is respected either way) and I find it very productive.

Mastering Cmd+D / Ctrl+D
The Add Selection To Next Find Match action (Cmd+D / Ctrl+D) and other related actions  change their behaviour based on the find input state even if the find widget is hidden

The two toggles can be changed via keybindings even when the find widget is hidden:

Option
Default keybinding

Match Case
Alt+CCmd+Alt+C (Mac)

Match Whole Word
Alt+WCmd+Alt+W (Mac)

That is why, starting with VSCode 1.9.0, the find options will be revealed briefly or highlighted briefly whenever running this action.

I'm sorry, I don't think this should be closed when the reply doesn't address my suggestion or gives me a straight "no, we don't want to do that".
I know of the Alt+C and Alt+W combinations and have been using them for a while, even before the latest update made them more visible to the user. It is precisely because I use them so much (mainly the "whole word" one) that I miss Sublime's behavior (the one I described), which lets me do what I want without touching the setting.
It was because of the most recent update to VSCode that I noticed that no one was paying attention to this, despite making the options more clear (and I thank you for that), so I decided to post here.

Can anyone please reopen this request or justify why it was closed?

I appreciate that you reopened this. Thank you! :)

Sorry for closing, I didn't read the issue with the attention I should have.
I've been thinking about this. I personally don't really like the idea of always honoring the match case, and honoring the whole words only in certain cases. i.e. if the selection is collapsed, and doing Ctrl+D, then forcing whole words.
I'm thinking if it would make sense that the first Ctrl+D in such a case (a collapsed selection) would flip the whole words and match case toggles on. It already "writes" to the find widget, i.e. the search string is replaced by the current word, so perhaps we could also "write" the match case and whole words toggles as well.

Thank you for your reply. I understand the problem with inconsistent usage of settings (whole vs case) and I wouldn't actually even recommend this as a default feature. :)
I was thinking of this more like an editor option for "addSelectionToNextFindMatch" (Ctrl+D); to be able to let the way your text is (or isn't) selected affect Ctrl+D's behavior (instead of the global setting), if you'd like that to happen. I also wasn't thinking of letting it alter the global whole word setting. That setting would be used pretty much for Find only. Ctrl+D would have its own, based on the selection.
That said, I realize that your suggestion is more sensible and seems to respect the current way VSCode does things. It's just that the Sublime way, though perhaps more "obtuse", has always been much more useful to me and at least another programmer I know of, to whom I mentioned this.
Thank you for considering this.

FWIW, Atom and Sublime Text both have this behaviour, and the workflow is much more convenient. The case/word toggles don't display until you hit the keyboard shortcuts, and they're tied to the Find/Replace popup, so the mode is completely unpredictable. (I, at least, don't remember what my last case/word toggle settings were from minute to minute!)

Agree on that. As I use the Cmd+D massively, that's the last thing that keeps me from full switch from Atom to vscode. I wonder if it could be written as a plugin, or has to be done directly in the vscode core?

I believe this is resolved with PR #36682 (for #8869) . When starting with a collapsed selection, Command+D will now search with wholeWords: true and caseSensitive: true.

Great! So when starting with just the cursor (i.e. no selection i.e. "collapsed selection") it always uses whole words and is case sensitive. When there's a selection in respects whatever the find settings are.
Thank you for your work. :)
By the way, I believe you mean "non-collapsed" in the last bold "Find widget opened - starting with a collapsed selection" of your gifs, no?

@CanisLupus yes, that's exactly it. Thanks for spotting the copy-paste error :)


Make storage-viz more durable

An intermediate storage viz (https://batch.hail.populationgenomics.org.au/batches/445677) failed for an out-of-memory issues.
There are two options, but the easiest is to bump the memory, and fail the dataset. Some later options is partition by bucket instead of dataset, but let's do it later if we need.
Also make the last aggregate bash always run, and just post an error if datasets are missing.
Also, noting the actual path construction was pretty disconnected, an output_prefix was supplied, but then the output_path function was used later to construct the web URL prefix. I tested the aggregation works locally.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (main@d778456). Click here to learn what that means.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #232   +/-   ##
=======================================
  Coverage        ?   90.67%
=======================================
  Files           ?        4
  Lines           ?      429
  Branches        ?        0
=======================================
  Hits            ?      389
  Misses          ?       40
  Partials        ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Memory usage:

Chatty summary doesn't really give anything surprising:

blobs = storage_client.list_blobs(bucket_name): If there are a huge number of blobs, this can potentially consume a lot of memory since the list might be very large. Consider using pagination or streaming the blobs if supported by the library to avoid loading all blobs into memory at once.

Though, given it's able to report millions of blobs summarised already, I find this pretty unlikely this is the problem. Unless it's not purging them from memory?

stats = aggregate_stats_container[path]: If aggregate_stats_container is a dictionary that grows indefinitely with new paths, this can lead to a memory leak as more and more entries are added. Make sure to monitor and manage the size of this container, possibly by purging old data if it's no longer needed.

I've added some reporting every million blobs to report the memory used - which is where I suspect it's actually being consumed.

Yeah, I know python dicts are pretty inefficient memory wise so it could just be the sheer amount of paths stored in the aggregate_stats_container dict that's causing the high memory usage.


Unsound use of object spread with non-exact objects isn't caught by flow.

Object spread doesn't seem to account for extra properties in non-exact types, and as such it can be used in an unsound manner:
type Foo = {
  foo : number,
};

type Bar = {
  foo : number,
  bar? : string
}

const f : Foo = { foo :3, bar : 4 };
const b : Bar = { ...f }; //no compile time error
b.bar.substr(1); // runtime type error

Flow version: 0.56

I get an error for your code as is, but I assume what you meant was for the last line to be:
if (b.bar) b.bar.substr(1); // runtime type error

In either case, the error you were expecting does show up if you remove the Foo annotation from f:
const f = { foo :3, bar : 4 };
const b : Bar = { ...f };
if (b.bar) b.bar.substr(1);

Still seems like a bug.

Related: #5015.

Related: #5015.

This is now caught


Add ContainerExpirationPolicyAttributes

The project API contains settings for changing the container expiration policy.
This PR implements these settings for both the create / edit project as well as for retrieving the project settings.

@svanharmelen thanks for the quick response and the excellent review comments. I've tried to address them all. Please let me know if I missed something or there is still something I can do to improve the PR.

@svanharmelen thanks for the quick response and the excellent review comments. I've tried to address them all. Please let me know if I missed something or there is still something I can do to improve the PR.

Thanks @svanharmelen to help me out finishing this PR!

Thanks @svanharmelen to help me out finishing this PR!


fix: health probe fails after some time

After installing connaisseur the health probe will fail after some time though it only returns true it runs health checks on validators that will not influence the health status but be logged if unhealthy. In case the health checks for the validators take too long, the pod health probe timeouts and the pod is considered unhealthy. Validator health checks are now separated from the pod health.

Codecov Report

Merging #166 (f26c683) into develop (165f518) will increase coverage by 3.26%.
The diff coverage is 97.43%.

@@             Coverage Diff             @@
##           develop     #166      +/-   ##
===========================================
+ Coverage    93.52%   96.78%   +3.26%
===========================================
  Files           15       22       +7
  Lines          633     1059     +426
===========================================
+ Hits           592     1025     +433
+ Misses          41       34       -7

Impacted Files
Coverage Δ

connaisseur/__main__.py
0.00% <ø> (ø)

...naisseur/validators/notaryv2/notaryv2_validator.py
80.00% <80.00%> (ø)

connaisseur/validators/static/static_validator.py
94.11% <94.11%> (ø)

connaisseur/util.py
94.28% <94.28%> (-5.72%)
:arrow_down:

connaisseur/policy.py
93.67% <94.44%> (+0.16%)
:arrow_up:

...naisseur/validators/notaryv1/notaryv1_validator.py
95.65% <95.65%> (ø)

connaisseur/config.py
95.83% <95.83%> (ø)

connaisseur/flask_server.py
97.80% <96.82%> (+26.37%)
:arrow_up:

connaisseur/alert.py
96.87% <96.87%> (ø)

connaisseur/validators/notaryv1/notary.py
97.47% <97.47%> (ø)

... and 24 more

Continue to review full report at Codecov.

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


test: extend test runner to print errors (fixes #51)

test needs to be updated.

I have added the commit to cst-parser branch, so this can be closed now. :)


Data Structures challenges accept every solution - even without any code

Describe your problem and - if possible - how to reproduce it
Challenges are accepted despite entered code (even without any).
Add a Link to the page with the problem
Data Structures: Perform an Intersection on Two Sets of Data
Data Structures: Perform a Difference on Two Sets of Data
Data Structures: Perform a Subset Check on Two Sets of Data
Data Structures: Create and Add to Sets in ES6
Data Structures: Remove items from a set in ES6
Data Structures: Use .has and .size on an ES6 Set
Data Structures: Use Spread and Notes for ES5 Set() Integration
Tell us about your browser and operating system

Browser Name: Chrome
Browser Version: 65.0.3325.181 64bit
Operating System: Win10 64bit

If possible, add a screenshot here

@wawraf  I'll look into it.

Still the same!

Closing this issue, because it has been fixed in beta. Viewable at https://www.freecodecamp.rocks/


blender to visii export(blender)->import(visii)

maya / fbx would be nice as well

The blender exporter for this is mostly working (perhaps besides light source intensity). However, we might want to create a separate repository / branch for developing the exporter, since it’s quite easy to break depending on the scene.


ci: update node version.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (197fc4f) to head (d8ec548).

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #34   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines           77        77
  Branches        20        20
=========================================
  Hits            77        77

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Lobby example update

Missing files from PR 957

:tada: This PR is included in version 3.11.7 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[QUESTION]: Investigate Flakiness in Reference Field Tests On Alpha with 27.1

After deploying 27.1 to alpha there seems to be an increased flakiness in reference field tests:
https://onspringqareports.stevanfreeborn.com/reports/1701804448889-ALPHA-failure-Playwright_Tests-70-1/
https://onspringqareports.stevanfreeborn.com/reports/1701798254528-ALPHA-failure-Playwright_Tests-69-1/

Ran the following locally against the alpha environment:
npx playwright test referenceField.spec.ts --headed --workers 1 --project chrome

All tests passed...🤔

Looking at the trace files for the failures I think what is happening is that the grid fields dropdown is not being populated quickly enough prior to the automated user trying to click save...why this is happening in alpha now i don't have a great explanation for.
However to test that theory I'd like to implement a solution where after selecting the proper app to related to we then wait for the grid fields dropdown to be populated with some value which currently should just be the record id field.
Once that is implemented and tested locally I'd like to rerun the suite with these changes.


auto_cue not respecting manual set values?

Not an issue, more a question to understand auto_cue better. I download news file, get the duration with ffprobe and use Azuracast API to set cross_start_next and cue_out with full duration.

But in LS log it seems it don't use this values. Why?
2024/06/28 13:50:40 [autocue.cue_file:3] Metadata added/corrected for "/var/azuracast/stations/eisradio/media/Syndication/lautfm-news.mp3":
2024/06/28 13:50:40 [autocue.cue_file:3] ("duration", "163.76")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_amplify", "-5.39 dB")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_amplify_adjustment", "0.00 dB")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_blank_skipped", "false")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_blankskip", "0.00")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_cross_start_next", "159.4")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_cue_duration", "159.40")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_cue_in", "0.00")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_cue_out", "159.4")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_fade_in", "0.1")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_fade_out", "0.")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_longtail", "false")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_loudness", "-12.61 LUFS")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_loudness_range", "5.74 LU")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_reference_loudness", "-18.00 LUFS")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_sustained_ending", "true")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_true_peak", "1.040000")
2024/06/28 13:50:40 [autocue.cue_file:3] ("liq_true_peak_db", "0.34 dBFS")
2024/06/28 13:50:40 [autocue.cue_file:3] ("replaygain_reference_loudness", "-18.00 LUFS")
2024/06/28 13:50:40 [autocue.cue_file:3] ("replaygain_track_gain", "-5.39 dB")

Hmm. A possible reason I could see is that cue_file found a reason to re-analyze the file, then overriding with freshly calculated data. News typically vary in length, maybe that’s it, or—if you pretagged—some diverging parameter between the tags and the station settings (mostly caused by blankskip).
It would be helpful to also see the lines above Metadata added/corrected…, like such:
2024/06/28 22:00:15 [autocue.cue_file:3] Now autocueing: "/var/azuracast/stations/niteradio/media/time/time.niteradio-test-loveit.mp3"
2024/06/28 22:00:15 [autocue.cue_file:3] Blank (silence) skipping active: true, set to 5. s
2024/06/28 22:00:15 [autocue.cue_file:3] Clipping prevention active: true
2024/06/28 22:00:15 [autocue.cue_file:3] Writing tags: false, including ReplayGain: false
2024/06/28 22:00:15 [autocue.cue_file:3] Writing metadata to /tmp/cue_filed1251d.json
2024/06/28 22:00:15 [autocue.cue_file:3] cue_file result for "/var/azuracast/stations/niteradio/media/time/time.niteradio-test-loveit.mp3": {"duration": 7.199999999999999, "liq_cue_duration": 4.9, "liq_cue_in": 2.0, "liq_cue_out": 6.9, "liq_cross_start_next": 6.8, "liq_longtail": false, "liq_sustained_ending": false, "liq_loudness": "-13.99 LUFS", "liq_loudness_range": "5.15 LU", "liq_amplify": "-4.01 dB", "liq_amplify_adjustment": "0.00 dB", "liq_reference_loudness": "-18.00 LUFS", "liq_blankskip": 5.0, "liq_blank_skipped": false, "liq_true_peak": 0.864, "liq_true_peak_db": "-1.27 dBFS"}
2024/06/28 22:00:15 [autocue.cue_file:3] Inserted replaygain_track_gain -4.01 dB and replaygain_reference_loudness -18.00 LUFS
2024/06/28 22:00:15 [autocue.cue_file:3] Given fade-out (0.1 s) < overlay duration (0.1 s), moving cue-out point from 6.9 s to 6.9 s.
2024/06/28 22:00:15 [autocue.cue_file:3] Metadata added/corrected for "/var/azuracast/stations/niteradio/media/time/time.niteradio-test-loveit.mp3":

...

plus the lines from show_meta for this track, to see if the Liquidsoap integration layer did something odd.
Also, if one of the mandatory tags is missing, cue_file might initiate a new analysis. You can check these using cue_file --help:
The absolute minimum set to (possibly) avoid a re-analysis is:
duration, liq_cross_start_next, liq_cue_in, liq_cue_out,
replaygain_track_gain.

(These might not always be enough.)
I still think the values from the VCE or advanced tab should override even a new analysis, but to see that, we’d need the output from show_meta (=the final values having been used).

Yes. i set fadein/out as in your screenshot. But sometimes it works very well and sometimes it is cutting off the last few seconds. So i tried download the file, pre-tag with cue_file -kwrn, analyse duration with ffprobe and pass this to Azuracast.
curl<EMAIL_ADDRESS>--output $directory/temp/lautfm-news.mp3  >>$MAILLOG 2>&1
    cue_file -fkwrn $directory/temp/lautfm-news.mp3 >>$MAILLOG
    LENGTH="$(ffprobe -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 "$directory/temp/lautfm-news.mp3" 2>/dev/null)" >>$MAILLOG
    mid3v2 -A "laut.fm Nachrichten" -g "News" $directory/temp/lautfm-news.mp3 >>$MAILLOG
    curl -X 'PUT' 'https://stream.eisradio.de/api/station/1/file/6880' -H 'accept: application/json' -H 'X-API-Key: ###' -H 'Content-Type: application/json'  -d '{ "extra_metadata": { "liq_fade_in": "0.1", "liq_fade_out": "0.1", "liq_cue_out": "'$LENGTH'", "liq_cross_start_next": "'$LENGTH'" } }'

When i disable autocue and using smart.crossfade everything works fine.

I did not set liq_cue_in.  :(   It is nearly rocket science to understand that all. ggg I set it in Azuracast to 0.0. Seems to work now. ffprobe calculated duration is 153,835102
autocue:annotate:title="Nachrichten",artist="lautfm",duration="163.24",song_id="7da67716a6a2b7eb0d748b135b4b890e",media_id="6880",liq_fade_in="0.10",liq_fade_out="0.10",liq_cue_out="153.84",liq_cross_start_next="153.84",liq_cue_in="0.00":media:Syndication/lautfm-news.mp3
2024/06/28 20:06:34 [decoder.ffmpeg:3] Requested content-type for "/var/azuracast/stations/eisradio/media/Syndication/lautfm-news.mp3": {audio=pcm(stereo)}
2024/06/28 20:06:34 [decoder.ffmpeg:3] FFmpeg recognizes "/var/azuracast/stations/eisradio/media/Syndication/lautfm-news.mp3" as audio: {codec: mp3, 44100Hz, 2 channel(s)}
2024/06/28 20:06:34 [decoder.ffmpeg:3] Decoded content-type for "/var/azuracast/stations/eisradio/media/Syndication/lautfm-news.mp3": {audio=pcm(stereo)}
2024/06/28 20:06:34 [autocue.cue_file:3] Now autocueing: "/var/azuracast/stations/eisradio/media/Syndication/lautfm-news.mp3"
2024/06/28 20:06:34 [autocue.cue_file:3] Blank (silence) skipping active: false, set to 0. s
2024/06/28 20:06:34 [autocue.cue_file:3] Clipping prevention active: true
2024/06/28 20:06:34 [autocue.cue_file:3] Writing tags: false, including ReplayGain: false
2024/06/28 20:06:34 [autocue.cue_file:3] Writing metadata to /tmp/cue_filee1917f.json
2024/06/28 20:06:34 [autocue.cue_file:3] cue_file result for "/var/azuracast/stations/eisradio/media/Syndication/lautfm-news.mp3": {"duration": 153.835102, "liq_cue_duration": 153.84, "liq_cue_in": 0.0, "liq_cue_out": 153.84, "liq_cross_start_next": 153.84, "liq_longtail": false, "liq_sustained_ending": false, "liq_loudness": "-12.42 LUFS", "liq_loudness_range": "3.57 LU", "liq_amplify": "-5.58 dB", "liq_amplify_adjustment": "0.00 dB", "liq_reference_loudness": "-18.00 LUFS", "liq_blankskip": 0.0, "liq_blank_skipped": false, "liq_true_peak": 1.041, "liq_true_peak_db": "0.35 dBFS"}
2024/06/28 20:06:34 [autocue.cue_file:3] Clipping prevention: Adjusted calculated replaygain_track_gain from -5.58 dB to -5.58 dB
2024/06/28 20:06:34 [autocue.cue_file:2] Given fade-out duration (0.1 s) exceeds available time, using 0. s.
 Could have happened to me :-) You’re right, it’s getting rather complicated if one has to think about all possible side effects… +grin+ I will possibly also have forgotten in a few weeks. :rofl: Then again, we can fortunately look things up in the code. Long live FOSS!

It is driving me crazy. It happened again. I tried all now. cue_file=false, fadein/out=0.1, cue_in, cue_out, cross_start_next. Nothing helps. It cuts off sometimes which doesn't sounds good. When using cross.smart this don't happens.

Phew. Have to have my head switched back to here… deep into some other projects currently, Perl and JS.
Don’t know really, I guess we can rule out missing RG tags, since you write them using cue_file. I’m a little unsure if the API still takes strings, after all the PHP typing efforts lately. (I assume that should work, but can’t right now test it.)

I am not sure, but i guess cue_file recalculates everytime, even when i set all manually.
Would it be possible to add a flag e.g. liq_force_full_duration? when is true then set fadein/out to 0.1 and cue_out, cross_start_next = duration. Could it work? What do you think?

To be honest, I wouldn’t currently want to change much. We’d have to update AzuraCast (and others using Autocue) everytime, so I’d prefer to fix bugs only for now.
I still wonder why it doesn’t do what we think it should to in your setup. Could you set
settings.log.level := 4

(first or second input box of AzuraCast Edit LS Config)?
I’d be interested what your station actually transmits to cue_file in the temporary JSON. So if we could create a situation where the file in question plays, and check the JSON temp file data (set log level to 4 for this).
2024/06/30 19:26:56 [autocue.cue_file:4] Writing metadata to /tmp/cue_filea20c87.json: {JSON DATA HERE}

I agree not changing things to often. It is better to fix things wherever possible.
I set settings.log.level := 4
Rolling Release #dcd4fdc (2024-06-26 23:40)
# settings.autocue.cue_file.path := "cue_file"
 settings.autocue.cue_file.fade_in := 0.5  # seconds
 settings.autocue.cue_file.fade_out := 5.0  # seconds
# settings.autocue.cue_file.timeout := 60.0  # seconds
# settings.autocue.cue_file.target := -18.0  # LUFS
# settings.autocue.cue_file.silence := -42.0  # LU below track loudness
# settings.autocue.cue_file.overlay := -8.0  # LU below track loudness
# settings.autocue.cue_file.longtail := 15.0  # seconds
# settings.autocue.cue_file.overlay_longtail := -12.0 # extra LU
 settings.autocue.cue_file.sustained_loudness_drop := 10.0  # max. percent drop to be considered sustained
 settings.autocue.cue_file.noclip := true  # clipping prevention like loudgain's `-k`
 settings.autocue.cue_file.blankskip := 5.0  # skip silence in tracks
 settings.autocue.cue_file.unify_loudness_correction := true  # unify `replaygain_track_gain` & `liq_amplify`
# settings.autocue.cue_file.write_tags := false  # write liq_* tags back to file
# settings.autocue.cue_file.write_replaygain := false  # write ReplayGain tags back to file
# settings.autocue.cue_file.force_analysis := false  # force re-analysis even if tags found
# settings.autocue.cue_file.nice := false  # Linux/MacOS only: Use NI=18 for analysis
# settings.autocue.cue_file.use_json_metadata := true  # pass metadata to `cue_file` as JSON

I'll keep an eye on it and copy the log if it happens again.

Thanks. Remember you might have to copy the Liquidsoap logs from the station. The log in the browser is quite short-lived when so much diagnostics data is produced.
Just to recap: If writing tags+ReplayGain, the settings above would translate to one of these cue_file commandlines:
cue_file -f -d 10.0 -k -b 5.0 -w -r filename.ext  # long form, floats written out
cue_file -f -d 10 -k -b 5 -w -r filename.ext  # long form, floats abbreviated
cue_file -fkwr -d 10 -b 5 filename.ext  # short form, specifying -b duration
cue_file -fkwr -d 10 -b -- filename.ext  # short form, leaving -b at default 5.0s, using --

For ease of use, commandline parameters will be auto-converted to float if needed (so 10 and 10.0 and 10.00 are the same, but 10. isn’t allowed).

I am not sure, but i guess cue_file recalculates everytime, even when i set all manually. Would it be possible to add a flag e.g. liq_force_full_duration? when is true then set fadein/out to 0.1 and cue_out, cross_start_next = duration. Could it work? What do you think?

New day, fresh thinking… Know what? You can already do all that! cue_file accepts an override JSON (stdin or file), which I internally use to pass the values from AzuraCast, i.e. from the Visual Cue Editor/Advanced tab.
Here’s the forgotten secret: If you’re pre-tagging, you could use this input to set your desired values and write them to the tags even. Just create well-formed JSON from your values and pass it on to cue_file—et voilà!
So instead of using the API (which is perfectly fine, too), you could tag the file:
echo '{"liq_fade_in": 0.1, "liq_fade_out": 0.1, "liq_cue_out": '$LENGTH', "liq_cross_start_next": '$LENGTH'}' | cue_file -j - -fkwr -d 10 -b -- filename.ext

The -j - tells cue_file to read its JSON from stdin, not from a file. You can pass any tag in the JSON, but cue_file will only ever write tags staring with liq_* and (if selected) replaygain_*.
Unfortunately, using -f/--force does just that: It forces a new analysis, getting you new cue-out and cross-start-next points.
I’ll check the internal logic and see what can be done.

v4.0.4 is out and should help in the case -f was used and you still want to overwrite some values. ;-)
See Release Notes and new FAQ section.

Thanks for your patience, help and support. As I try out a lot, I often change the scripts. At the moment i use
cue_file -fkwrn -b 5 -d 10 -- $directory/temp/lautfm-news.mp3 >>$MAILLOG
I'll give it a try. So snippet of my download script is now
    curl<EMAIL_ADDRESS>--output $directory/temp/lautfm-news.mp3  >>$MAILLOG 2>&1
   # rsgain custom -I3 -a -L -c p -s i $directory/temp/lautfm-news.mp3 >>$MAILLOG
   LENGTH="$(ffprobe -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 "$directory/temp/lautfm-news.mp3" 2>/dev/null)" >>$MAILLOG
    echo '{"liq_fade_in": 0.1, "liq_fade_out": 0.1, "liq_cue_out": '$LENGTH', "liq_cross_start_next": '$LENGTH'}' | cue_file -j - -fkwrn -d 10 -b 5 --  $directory/temp/lautfm-news.mp3 >>$MAILLOG
    mid3v2 -A "laut.fm Nachrichten" -g "News" $directory/temp/lautfm-news.mp3 >>$MAILLOG

It's funny that nothing has been cut off from the news in the last few hours. But for a jingle. I will post a recording.
I'll downloaded 4.0.4 and use it when next download is triggered.

Tagging with your command works perfect.
 echo '{"liq_fade_in": 0.1, "liq_fade_out": 0.1, "liq_cue_out": '$LENGTH', "liq_cross_start_next": '$LENGTH'}' | cue_file -j - -fkwrn -d 10 -b 5 --  $directory/temp/lautfm-news.mp3
I let the script send me emails with the result.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0 100 2679k    0 2679k    0     0  12.0M      0 --:--:-- --:--:-- --:--:-- 12.0M

{"duration": 171.404, "liq_cue_duration": 169.904, "liq_cue_in": 0.0, "liq_cue_out": 171.47675, "liq_cross_start_next": 171.47675, "liq_longtail": false, "liq_sustained_ending": false, "liq_loudness": "-12.42 LUFS", "liq_loudness_range": "3.77 LU", "liq_amplify": "-5.58 dB", "liq_amplify_adjustment": "0.00 dB", "liq_reference_loudness": "-18.00 LUFS", "liq_blankskip": 5.0, "liq_blank_skipped": false, "liq_true_peak": 0.975, "liq_true_peak_db": "-0.22 dBFS"}

Download lautfm-news.mp3 finished

 STARTED: Mo 1. Jul 16:44:01 CEST 2024
 FINISHED: Mo 1. Jul 16:44:03 CEST 2024

It's funny that nothing has been cut off from the news in the last few hours. But for a jingle. I will post a recording. I'll downloaded 4.0.4 and use it when next download is triggered.
Found the reason why the jingle was "cut off". The duration tag was not set. I pre-tagged newly with cue_file 4.0.4 and issue has gone.
So i decided to pre-tag all my files again with 4.0.4 and hope then all working as we want it.

It happened again, but this time i know why. You can listen here
2024-07-01-T19_00_00.webm
This time it happened because news file queued at 18:25, playout was 19:04. Playing a 30 minute syndicated show in this time.  But i download news every hour at minute 51. So queued file had correctly announced 153 seconds, but new downloaded file had 170 seconds. Don't know how to avoid this.
Downloading and tagging with
echo '{"liq_fade_in": 0.1, "liq_fade_out": 0.1, "liq_cue_out": '$LENGTH', "liq_cross_start_next": '$LENGTH'}' | cue_file -j - -fkwrn -d 10 -b 5 --
runs great also with syndicated shows!

I wonder if my LS corrects the "duration": 171.404 vs set "liq_cue_out": 171.47675, "liq_cross_start_next": 171.47675—those are "beyond the end".
Problem is, especially with MP3, and especially especially with VBR MP3, the duration LS or ffprobe "read" is just a guesstimate, and cue_file reads the whole file, so usually knows better.
liq_cue_duration was meant to indicate the real playout duration (cue_out - cue_in), so for instance a more precise broadcast clock could be built.

I wonder if my LS corrects the "duration": 171.404 vs set "liq_cue_out": 171.47675, "liq_cross_start_next": 171.47675—those are "beyond the end".
Problem is, especially with MP3, and especially especially with VBR MP3, the duration LS or ffprobe "read" is just a guesstimate, and cue_file reads the whole file, so usually knows better.

There is no audible issue. Do you need logs?

liq_cue_duration was meant to indicate the real playout duration (cue_out - cue_in), so for instance a more precise broadcast clock could be built.

Now i understand that. Thanks.
Everything looks good so far. Everything now seems to be working as you would expect. So i think we could close this issue.

Fine, thanks! And happy it works out for you!
Now it’s Buster’s turn for AzuraCast. :-)

Tonight I had another idea. I thought why use ffprobe when cue_file already have a more precise duration. So why don't run cue_file, then read duration from tag and use mid3v2 to set liq_cue_out and liq_cross_start_next. This way I would have the exactly same values and wouldn't need to calculate duration two times.
I think I will give it a try.

Yes, why not. It actually uses ffprobe to read the initial metadata (and duration), but (only) when it does an analysis, it updates the value to what is has found out.
Say, are you available somewhere else for a talk? Don’t like to pollute the issue, so talking on phone or Discord or my Nextcloud would be nice. (Re: possible error, news, etc.). If you don’t want to make contact data public, you can send me an email to moonbase (at) quantentunnel.de.

Testing 4.0.5 right now. I am on Discord also as Lord_Helmchen

Missed the friend request for a while, sorry. Maybe when you have time and are in the mood, we can have a chat/talk over there.


Add marketplace page to browse the new assets and free monthly assets.

I hope you add a new page so we can browse the marketplace just like webview , so we can browse the new assets and check the free monthly assets.
you can just make a webview to display the marketplace like normal browsers , and it will be cool if we can log in so we can add some assets to our inventory.

I would like to add this eventually, sadly the status of webkit2gtk for GTK4 is not ideal at this point. It is also the reason why the login process requires manual copy of SID instead of doing it in app.


repro: checkbox bug

Attempting to reproduce https://www.reddit.com/r/vuejs/comments/rqer1q/help_with_issue_testing_custom_checkbox_component/ but no luck yet.

User needed to add attachTo. Weird! We should doc that.


Integrate Report Generation from mlte-report

Currently, report generation functionality is dispatched to the mlte-report component, which is deployed as a totally separate web service hosted on cloud resources. The decoupling is nice, but the fact that users have to "reach out" to the WAN in order to generate reports seems surprising and un-parsimonious. We should consider bundling the report generation as functionality within the package itself, such that it can be used offline.

As an updated, this is being done by rendering the report as part of the new UI frontend, in #179

Resolved by #289.


Improving readability of errors

Started work on improving how errors are printed to display to aid understanding of errors from regex rules. For example, if a value is meant to (but does not) meet the regex rule "datetime", previously the error printed was
[global-attributes:******:time_coverage_start]*** Value '20230609' does not match regex rule: 'datetime'.

Now, an example of a valid value is also printed:
[global-attributes:******:time_coverage_start]*** Value '20230609' does not match regex rule: 'datetime' - Example valid value '2023-11-17T15:00:00'.

This is now ready to be merged. The above regex-rule examples have been filled out to all regex rules in rules.py-Rules-static_regex_rules, and additional quote marks have been added to some error messages around the values for easier reading and understanding, e.g.
Attribute 'long_name' must have definition Cloud Base Altitude (Geometric height above geoid WGS84), not Cloud Base Altitude (Geometric height above geoid (WGS84)).

would now print as
Attribute 'long_name' must have definition 'Cloud Base Altitude (Geometric height above geoid WGS84)', not 'Cloud Base Altitude (Geometric height above geoid (WGS84))'.

This will be particularly helpful when values end in punctuation, clarifying whether that punctuation is part of the value or the message.


deploying  behind proxy???

Hello'
I can't deploy the sample while runninthg proxy ,is there any suggestion about??

Hey @mayassalman It seems this is a known issue with the Firebase CLI. Please follow this issue: https://github.com/firebase/firebase-tools/issues/155
Sorry about that!


Bug/naming conventions problems

Description
Fixes #

What work was done?
Fixed naming conventions in the backend regarding story router and models
Why was this work done?
To fulfill the trello card : https://trello.com/c/29MvQpud/854-resolve-naming-conventions-in-be-that-are-causing-errors
What feature / user story is it for?
Any relevant links or images / screenshots
Loom Video: https://www.loom.com/share/4e8a90c687db48399dd44fa03fad2f2a

Type of change
Please delete options that are not relevant.

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

Change Status

[ ] Complete, tested, ready to review and merge
[x] Complete, but not tested (may need new tests)
[ ] Incomplete/work-in-progress, PR is for discussion/feedback

Has This Been Tested

[x] Yes
[ ] No
[ ] Not necessary

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] There are no merge conflicts

So I just rebased it and it wants me to re-request reviews, nothing changed other than the rebase


headers to lowercase

What:

[x] Bug Fix
[ ] New Feature

Description:

Related:

Hi @chengxs1994
Thank you for your PR!
Could you provide an example why this changes is necessary? As far as I understand the OpenAI docs, the headers should always be in lowercase.

According to the psr specification, the getHeaderLine method is case insensitive, but the conversion to array does not automatically convert to lowercase

Thanks for clarification 👍


No sw.js file loaded on our server - IOS Devices Run Issue

We are trying to install your QRcode scanner, and succeed by Chrome and IE. Safari gives an error.
Here is your https://qrcodescan.in/ inspected scanner.

And so work good on IOS :

We have done everything as you said.
Works good on Chrome and IE, but on IOS (Safari) doesn't work
It looks so:

Here is our inspected scanner.

So the difference is that by your scanner there are this sw.js and we don't have it.
We have this sw.js on our server, but our scanner doesn't use it, and we don't know why.
Maybe is this issue.
Any solution?

@mihajlon97 Service Workers is not supported in iOS devices (safari, chrome etc,). More info Webkit Status. But i have written code to upload or take picture and scan the QR code in iOS devices.

@alextappin I tested the qrcodescan app using media stream API. There are some issues with safari which prevents us from proceed further. Mentioning the issues below.

Not able show video stream without a small hack.
After adding the app to add to home screen, and opening it doesn't show video stream at all. This is bug in safari. We will follow up with bugs see to if its fixed and then we can proceed further on this issue.

Thanks

Thank you. I will be watching this project for updates.

@alextappin @mihajlon97
PR Link: https://github.com/code-kotis/barcode-scanner/pull/52. Just FYI guys. Since this is most asked feature for this app. Will close the issue once PR got merged.

Closing in favour of #52