Druid 0.10.1 release notes [WIP]

DRAFT
Druid 0.10.1 contains hundreds of performance improvements, stability improvements, and bug fixes from over 40 contributors. Major new features include:

Large performance improvements and additional query metrics for TopN queries
The ability to push down limit clauses for GroupBy queries
More accurate query timeout handling
Hadoop indexing support for the Amazon S3A filesystem
Support for ingesting Protobuf data
A new Firehose that can read input via HTTP
Improved disk space management when indexing from cloud stores
Various improvements to coordinator lookups management
A new Kafka metrics emitter
A new dimension comparison filter
Various improvements to Druid SQL

If you are upgrading from a previous version of Druid, please see "Updating from 0.10.0 and earlier" below for upgrade notes, including some backwards incompatible changes.
The full list of changes is here: https://github.com/druid-io/druid/pulls?utf8=✓&q=is%3Apr is%3Aclosed milestone%3A0.10.1
Documentation for this release is at: http://druid.io/docs/0.10.1/
Highlights
TopN performance improvements
Processing for TopN queries with 1-2 aggregators on historical nodes is now 2-4 times faster. This is accomplished with new runtime inspection logic that generates monomorphic implementations of query processing classes, reducing polymorphism in the TopN query execution path.
Added in a series of PRs described here by @leventov: https://github.com/druid-io/druid/issues/3798.
Limit clause push down for GroupBy
Druid can now optimize limit clauses in GroupBy queries by distributing the limit application to historical/realtime nodes, applying the limit to partial result sets before they are sent to the broker for merging. This reduces network traffic within the cluster and reduces the merging workload on broker nodes. Please refer to http://druid.io/docs/0.10.1/querying/groupbyquery.html#query-context for more information.
Added in https://github.com/druid-io/druid/pull/3873 by @jon-wei.
Hadoop indexing support for Amazon S3A
Amazon's S3A filesystem is now supported for deep storage and as an input source for batch ingestion tasks. Please refer to <> for documentation.
Added in https://github.com/druid-io/druid/pull/4116 by @b-slim.
Protobuf 3.0 support and other enhancements
Support for ingesting Protobuf 3.0 data has been added, along with other enhancements such as reading Protobuf descriptors from a URL. Protobuf-supporting code has been moved into its own core extension as well. See http://druid.io/docs/0.10.1/development/extensions-core/protobuf.html for documentation.
Added in https://github.com/druid-io/druid/pull/4039 by @knoguchi.
HTTP Firehose
A new Firehose for realtime ingestion that reads data from a list of URLs via HTTP has been added. Please see http://druid.io/docs/latest/ingestion/firehose.html#httpfirehose for documentation.
Added in https://github.com/druid-io/druid/pull/4297 by @jihoonson.
Improved disk space management for realtime indexing from cloud stores
The Firehose implementations for Microsoft Azure, Rackspace Cloud Files, Google Cloud Storage, and Amazon S3 now support caching and prefetching of data. These firehoses can now operate on portions of the input data and pull new data as needed, instead of having to fully read the firehose's input to disk.
Please refer to the following links for documentation:
http://druid.io/docs/0.10.1/development/extensions-contrib/azure.html
http://druid.io/docs/0.10.1/development/extensions-contrib/cloudfiles.html
http://druid.io/docs/0.10.1/development/extensions-contrib/google.html
http://druid.io/docs/0.10.1/development/extensions-core/s3.html
Added in https://github.com/druid-io/druid/pull/4193 by @jihoonson.
Improvements to coordinator lookups management
Several enhancements have been made to the state management/synchronization logic for query-time lookups, including versioning of lookup specs. Please see http://druid.io/docs/0.10.1/querying/lookups.html for documentation.
Added in https://github.com/druid-io/druid/pull/3855 by @himanshug.
Kafka metrics emitter
A new metrics emitter that sends metrics data to Kafka in JSON format has been added. See http://druid.io/docs/0.10.1/development/extensions-contrib/kafka-emitter.html
Added in https://github.com/druid-io/druid/pull/3860 by @dkhwangbo.
Column comparison filter
A new column comparison filter has been added. This filter allows the user to compare values across columns within a row, like a "WHERE columnA = columnB" clause in SQL. See http://druid.io/docs/0.10.1/querying/filters.html#column-comparison-filter for documentation.
Added in https://github.com/druid-io/druid/pull/3928 by @erikdubbelboer.
Druid SQL improvements
Druid 0.10.1 has a number of enhancements to Druid SQL, such as support for lookups (PRs by @gianm):
https://github.com/druid-io/druid/pull/4368 - More forgiving Avatica server
https://github.com/druid-io/druid/pull/4109 - Support for another form of filtered aggregator
https://github.com/druid-io/druid/pull/4085 - Rule to collapse sort chains
https://github.com/druid-io/druid/pull/4055 - Add SQL REGEXP_EXTRACT function
https://github.com/druid-io/druid/pull/3991 - Make row extractions extensible and add one for lookups
https://github.com/druid-io/druid/pull/4028 - Support for coercing to DECIMAL
https://github.com/druid-io/druid/pull/3999 - Ability to generate exact distinct count queries
Other performance improvements
Druid 0.10.1 has a number of other performance improvements, including:
https://github.com/druid-io/druid/pull/4364 - Uncompress streams without having to download to tmp first, by @niketh
https://github.com/druid-io/druid/pull/4315 - Server selector improvement, by @dgolitsyn
https://github.com/druid-io/druid/pull/4110 - Remove "granularity" from IngestSegmentFirehose, by @gianm
https://github.com/druid-io/druid/pull/4038 - serialize DateTime As Long to improve json serde performance, by @kaijianding
And much more!
The full list of changes is here: https://github.com/druid-io/druid/pulls?utf8=✓&q=is%3Apr is%3Aclosed milestone%3A0.10.1
Updating from 0.10.0 and earlier
Please see below for changes between 0.10.0 and 0.10.1 that you should be aware of before upgrading. If you're updating from an earlier version than 0.10.0, please see release notes of the relevant intermediate versions for additional notes.
Deprecation of support for Hadoop versions < 2.6.0
To add support for Amazon's S3A filesystem, Druid is now built against Hadoop 2.7.3 libraries, and we are deprecating support for Hadoop versions older than 2.6.0.
For users running a Hadoop version older than 2.6.0, it is possible to continue running Druid 0.10.1 with the older Hadoop version using a workaround.
The user would need to downgrade hadoop.compile.version in the main Druid pom.xml, remove the hadoop-aws dependency from pom.xml in the druid-hdfs-storage core extension, and then rebuild Druid.
Users are strongly encouraged to upgrade their Hadoop clusters to a 2.6.0+ version as of this release, as support for Hadoop <2.6.0 may be dropped completely in future releases.
Kafka Broker Changes
Due to changes from https://github.com/druid-io/druid/pull/4115, the Kafka indexing service is no longer compatible with version 0.9.x Kafka brokers. Users will need to upgrade their Kafka brokers to an 0.10.x version.
Coordinator Lookup Management Changes
Due to changes from https://github.com/druid-io/druid/pull/3855, if query-time lookups are used, special care is needed when upgrading the coordinators to 0.10.1.
All coordinators should be stopped, upgraded, and then started with version 0.10.1. There should never be a situation where one coordinator is running 0.10.0 while other coordinator is running 0.10.1 at the same time.
After upgrading to 0.10.1, it is also necessary to supply a lexicographically ascending version number when adding or updating a lookup spec.
Please see http://druid.io/docs/0.10.1/querying/lookups.html for the current query-time lookups documentation.
Kafka emitter?
https://github.com/druid-io/druid/pull/3860 - check with @pjain
Rolling updates
The standard Druid update process described by http://druid.io/docs/0.10.1/operations/rolling-updates.html should be followed for rolling updates.
Credits
Thanks to everyone who contributed to this release!
@akashdw
@AmarJayR
@asdf2014
@asrayousuf
@b-slim
@cesure
@cxmcc
@dclim
@dgolitsyn
@dkhwangbo
@drcrallen
@elloooooo
@erikdubbelboer
@fanjieqi
@Fokko
@freakyzoidberg
@fuji-151a
@gianm
@gkc2104
@himanshug
@hzy001
@JackyWoo
@Jdban
@jerchung
@jihoonson
@jon-wei
@kaijianding
@KenjiTakahashi
@knoguchi
@leventov
@licl2014
@logarithm
@niketh
@nishantmonu51
@pjain1
@praveev
@ramiyer
@sascha-coenen
@satishbhor
@sjvs
@taochaoqiang
@xanec
@zhihuij
@zwang180

@himanshug Do we need to resolve https://github.com/druid-io/druid/pull/4281 before releasing 0.10.1?

Also, @himanshug, is this bit from the draft release notes correct (with regard to QTL)

The standard Druid update process described by http://druid.io/docs/0.10.1/operations/rolling-updates.html should be followed for rolling updates.

Awesome work guys! Would it be possible to also add Parquet Date-column support into 0.10.1?

Thanks @Fokko and thanks also for your contributions to this release. 0.10.1 is code-frozen at this point (other than blocker bug fixes) so #4423 will be included in the next release, 0.11.0. Even though 0.10.1 hasn't been released yet, 0.11.0 is already well underway, with 19 new patches (including yours): https://github.com/druid-io/druid/milestone/23?closed=1

Thanks for the explanation. Lets wait for 0.11.0 then. Thanks!

@gianm i think 0.10.1 fulfills the updated rolling upgrade contract in #4281 , so 0.10.1 is alright.

@jon-wei under the Updating from 0.10.0 and earlier section, should the following,

Users should also update any existing druid.indexer.task.defaultHadoopCoordinates configurations to 2.7.3 versions.

read

Users should also update any existing druid.indexer.task.defaultHadoopCoordinates configurations to non-2.7.3 versions.

@john-bodley I clarified that part a bit, this was the intended meaning:

If users wish to use Hadoop 2.7.3 as default for ingestion tasks, users should double check any existing druid.indexer.task.defaultHadoopCoordinates configurations.

I hope in the nearest version . Druid will released Window Functions features .


Synopsys: Automated PR: Update com.itextpdf:itextpdf:5.5.8 to <IP_ADDRESS>

Vulnerabilities associated with com.itextpdf:itextpdf:5.5.8
BDSA-2017-4082 (HIGH): iText is vulnerable to XML External Entities (XXE) attacks due to how the XML parsers in use are not configured to disable external entities.
An attacker could abuse this issue by submitting a crafted PDF file that includes malicious XXE payloads within the XML data of the document in order to perform attacks that can extract files, make forged requests on a server or impact performance.
BDSA-2017-4117 (HIGH): iText RUPS is vulnerable due to improper XML external entity (XXE) handling. A remote attacker could exploit this vulnerability in order to  cause XXE attacks such as local and remote resource inclusion, port scanning and server-side request forgery (SSRF).
Note: iText RUPS is no longer supported. The vendor has replaced this product with i7j-RUPS.
Click Here To See More Details On Server

Automated PR Comment From BlackDuck

❌ Found dependencies violating policy!

Policies Violated
Dependency
License(s)
Vulnerabilities
Short Term Recommended Upgrade
Long Term Recommended Upgrade
Resolved / Filtered Out

No Medium Severity VulnsNo AGPL Licenses
iText, a JAVA-PDF library
N/A
❌   CVE-2022-24197 MEDIUM CVSS 6.5❌   CVE-2022-24196 MEDIUM CVSS 6.5

:grey_exclamation:

No High Severity Vulns
tough-cookie
N/A
❌   BDSA-2023-1661 HIGH CVSS 8.8

5.0.0 (0 known vulnerabilities)
:grey_exclamation:

No High Severity Vulns
PostgreSQL JDBC Driver (pgjdbc)
N/A
❌   CVE-2022-31197 HIGH CVSS 8.0
9.4-1206-jdbc42 (2 known vulnerabilities)
42.7.4 (0 known vulnerabilities)
:grey_exclamation:


Documentation of csvReaderAsync

Description
Fix the documentation of csvReaderAsync accordingly to the following screenshot.

Checklist

[ ] Fix.
[ ] Update Work in progress section in changelog.

This is a rendering error!


[WIP] Feature/local auth list

Closing in favor of https://github.com/citrineos/citrineos-core/pull/257
@ChrisWeissmann these concerns are mitigated in the above


New repo for gateway-provisioners

Hello,
The gateway_provisioners repo currently resides in the gateway-experiments organization, which is where a few experimental projects reside to complete POCs, etc.  With its 0.1.0 release, I would like to propose that it be moved into the jupyter-server organization so it can reside alongside the existing Gateway projects (Enterprise Gateway and Kernel Gateway).  In addition to perhaps making the project more available to contributions, we can also more safely leverage things like jupyter-releaser (and its use of tokens during release builds, etc.).
gateway_provisioners provides kernel provisioners for launching and managing kernel lifecycles in Kubernetes, Docker, DockerSwarm, SSH, and Hadoop Yarn clusters.  Because these are merely kernel provisioners, they are available to projects other than the Gateway projects.  (Fun fact, they are NOT currently available to EG until its 4.0 release.)  This repo was originally named remote-provisioners, but I felt that name was too generic, among other things.
I'd like to add this topic to this week's Server/Kernels Team Meeting, at which time I'm hoping we can reach a consensus.

This proposal was officially accepted by a (private) team vote! Thanks and congratulations @kevin-bates!
Feel free to transfer the repo whenever you're ready and close this issue once that's finished! 🚀

Repo has been transferred - thanks everyone!


fix: do not create a fake remote span if it does not exists

do not create a fake remote span if it does not exists, avoid <root span not yet received> when no remote span
remove the useless trace_id meta field, it has nothing to do with the final trace ID (at least it has no meaning in otlp, for jaeger, I do not know).
related issue:
https://github.com/davidB/axum-tracing-opentelemetry/issues/52#issuecomment-1484166015

It's nearly the orginal code (version 0.1). The issue with this approach it that "root span" as no trace_id

not visible in log
and (iirc) not visible if no child span is created

It's why I instroduce the "hack" of create_context_with_trace has mention in it's comment.

the problem is, the hack casued this middleware's behavior diffs from any other (maybe wideused, I thought) middleware implementions.
for example  the behavior with the Golang echo framework middleware implementation: https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/github.com/labstack/echo/otelecho/echo.go
and also the Rust actix framework middleware implementation:
https://github.com/OutThereLabs/actix-web-opentelemetry/blob/main/src/middleware/trace.rs
both will not show <root span not yet received>  if the client request does not have text propagation headers.

"not visible in log"
"and (iirc) not visible if no child span is created",
each one, can you give a reproduce example ?

The test is missing actually.
iirc, to reproduce launch the example, call the enpoint with otlp (see README). You'll notice that trace_id is not set in the reaction of the span. It's also visible into your PR. the call to info_span doesn't have trace_id, because the opentelemetry span & trace are created after info_span.

I looked at the actixweb code you shared. The actixweb code is opentelemetry only it doesn't integrate the tracing part. And it's where I have the problem.

with the original code (like you PR), opentelemetry span (and trace) is created after the tracing span, and so no trace_id in some log, events,...
with the second try, I created a full opentelemetry span & trace first, then attach to the tracing span. In this case on OpenTelemetry we have 2 span (with a fake parent), because the attachment create an opentelemetry span iirc
current implementation creates an opentelemetry trace & spancontext but with an invalid (000...) spanId, in this case no fake opentelemetry span send to collector, but the issue you mention.

(Maybe I wrongly remember the cases and symptoms)

On master (not yet releasd) I pushed an other way to fix this issue, if you want to take a look.
I would to add a dedicated test before release, but If it's too long I'll release without.

On master (not yet releasd) I pushed an other way to fix this issue, if you want to take a look. I would to add a dedicated test before release, but If it's too long I'll release without.

just tested the latest main branch. it works.

Thanks for the feedback.

With 0.12, I removed the hack to have trace_id before tracing' span creation in every case. Because it's incompatible with how tracing-opentelemetry behaves.
I'm very sad about this removal, and I'll try to find an other way.
So it should fix the issue with this "phatom" span

Thanks for the bug & PR.
Give me your feedback about 0.12+


pnpm dev with new app redirects to 404 instead of install page

Issue summary

"@shopify/shopify-app-express": "2.2.0"
Node version: v18.16.1
Operating system: Fedora 38

I have a Shopify app that is based on the node/express template.
In development mode, I want to develop on a different app name than before, then I want to install the new app on my development store. But this does not work, and instead of redirecting me to the Install page, I have:

Precision: all my dependencies are at their latest versions.
Expected behavior

Redirect to the install page for the new app.
Actual behavior

Redirects to 404.
Steps to reproduce the problem

Run pnpm dev --reset at the root of the project on Linux
Use a new app to develop on
Press p when eveything is ready

When you run the dev --reset command, are you seeing some log lines about an app uninstalled webhook? The error you're seeing is because the local database the template uses (database.sqlite) will still think the app is installed, even though it hasn't actually been installed as far as Shopify can see.
There are 2 ways this could be fixed:

The app uninstalled webhook reaches the app (which will make the template delete existing sessions for that shop)
You can delete the sessions from the database (or the database itself)


Filer first backspace removes two characters when using filer provider in Vim

Open "Clap filer" type characters and press backspace, there will be 2 characters erased. This only happens for the first time that backspace is pressed.
This is especially annoying if you open filer and type single wrong character and press backspace since this will erase the character and move to the previous directory.

Use neovim for now, the input of vim's popup is mocked and that's definitely brittle. I'm a neovim user, so not sure when I'll have time for this issue.

Ah okay, sorry that I didn't give more information but you realized it was only a vim problem.

It seems you are really messing up with the input buffer here.
Let's assume you are entering abc.
After that s:cursor_idx=3 which seems valid.
Now pressing BS leading to s:cursor_idx=2 which seems also valid BUT the input line now shows only a.
The cursor position has been moved one position but the input line decreased by two chars.
After that BS works fine BUT that's because s:cursor_idx ist always one ahead:
After typing bc it shows (and filters) abc
The s:cursor_idx=4 which is wrong.
That all starts with:
function! s:bs_action() abort
  call clap#highlight#clear()

  let input = g:clap.input.get()
  if input ==# ''
    call s:goto_parent()
  else
    call g:clap.input.set(input[:-2])
    call s:filter_or_send_message()
  endif
  return ''
endfunction

This function is written having in mind, that the buffer is still unchanged and containing all characters, in this example abc.
But the last letter c has been already stripped off by s:backspace called in
function! s:move_manager.bs(_winid) abort
  call s:backspace()
  if has_key(g:clap.provider._(), 'bs_action')
    call s:mock_input()
    call g:clap.provider._().bs_action()
  else
    call s:apply_on_typed()
  endif
endfunction

so you additionally strip off one more character by calling input.set (which is wrong, cause it already was removed) and input.set does not change the s:cursor_indx to the given new text (which is also wrong),
Or did I missed something?

@Grueslayer Looks reasonable at the first glance. Mind sending a PR?

This isn't a VIM problem at all. It still exists in nvim, the result is a little different.

in VIM it is like described: two characters are deleted, cursor_idx decreased only by one (cursor not visible in vim). Every addition character is appended at the end of the string.
in NVIM only one character is removed, the cursor_idx possible not decreased (not verified) BUT the visible cursor still is at the previous position, so writing another character it is appended with space before. Pressing abc, than BS, and d leads to abc d.

The reason is like described from me before. You need to

do not call backspace() if there is an handler subscribed (or determine by a return value from handler to do it afterwards)
or give the handler both (before and after) so you know if you pressed BS on an empty string (go parent) or the BS leads to an empty string (do nothing)

in NVIM only one character is removed, the cursor_idx possible not decreased (not verified) BUT the visible cursor still is at the previous position, so writing another character it is appended with space before. Pressing abc, than BS, and d leads to abc d.

This should be incorrect and I can not reproduce it with neovim. Neovim does not have this problem as it's focusable and you don't have to handle the cursor movment manually.

Based on your suggestion, this patch seems to work:
diff --git a/autoload/clap/popup/move_manager.vim b/autoload/clap/popup/move_manager.vim
index 2073c5e..33493d7 100644
--- a/autoload/clap/popup/move_manager.vim
+++ b/autoload/clap/popup/move_manager.vim
@@ -90,10 +90,11 @@ function! s:backspace() abort
 endfunction

 function! s:move_manager.bs(_winid) abort
+  let before_bs = s:strpart_input(0, s:cursor_idx).s:strpart_input(s:cursor_idx)
   call s:backspace()
   if has_key(g:clap.provider._(), 'bs_action')
     call s:mock_input()
-    call g:clap.provider._().bs_action()
+    call g:clap.provider._().bs_action(before_bs)
   else
     call s:apply_on_typed()
   endif
diff --git a/autoload/clap/provider/filer.vim b/autoload/clap/provider/filer.vim
index ffdb2e4..3e2cf5d 100644
--- a/autoload/clap/provider/filer.vim
+++ b/autoload/clap/provider/filer.vim
@@ -89,14 +89,14 @@ function! s:filter_or_send_message() abort
   endif
 endfunction

-function! s:bs_action() abort
+function! s:bs_action(before_bs) abort
   call clap#highlight#clear()

   let input = g:clap.input.get()
-  if input ==# ''
+  if a:before_bs ==# ''
     call s:goto_parent()
   else
-    call g:clap.input.set(input[:-2])
+    " call g:clap.input.set(input[:-2])
     call s:filter_or_send_message()
   endif
   return ''

Hi, this seems to work on VIM in the first tests but nvim didnt work anymore. You need also to change the call in autoload/clap/handler.vim to supply the additional paramater.

Great, here is the complete patch. Feel free to review. @Grueslayer

Please don't get me wrong, I am really happy for your plugin and fixing things. Maybe I am a liitle to bit on the academic side  but I think your solution isn't a good one:

now we've two interface signatures for the same function
provider programmers (which must not only be you) need to implement something for nvim and another for vim (leading possible to providers running only for one system)
provider programmers need to know about the inner implementation (which should be hidden)
nvim provider can change anything in the input, like abc() -> abc: deleting pairs when pressing BS, vim provider only handles BS outside the provider and need to run with the result.

I haven't taken a look in the source but as I understand our conversation:

nvim has a function which handles key input for you. handler.vim is your callback for this. if the provider does not register for bs_action you handle the BS otherwise the provider sets the current input like it thinks it should be.
vim hasn't such a function, you immitate it by move_manager.vim.

In my opinion vim should behave exact the same way, so move_manager.vim should call the provider, provider should set the new input. So setting the new input must lead to a change in the internal buffer from move_manager (like it does in nvim's internal handling). As you wrote there is a problem with multi-byte-support (I am no chinese/japan/korean user, so I really only know what is is technical not how to program or use such keystrokes / characters). Isn't it possible to convert to input buffer from provider (which is handles as real characters) to their responsible multi-byte represantation in the move_manager (you already must done this in the other way).
If it would be possible we can have a clean interface and keep trouble from provider implementors away.
Please don't feel attacked! Just my opionion.
Again, thank you for this.

That's totaly fine. I also don't like the way of having two different signature for neovim and vim, but it's the most simple and practical way to fix the problems people are trapped in, at least it works now. I'm happy to accept a patch that proposes a more elegant solution.
As I mentioned in https://github.com/vim/vim/issues/5639, the root cause is that vim's popup is not like neovim's floating win which is focuable, each plugin like vim-clap has to mock the input display in a dirty way, facing the multi-byte issue like https://github.com/liuchengxu/vim-clap/pull/320 directly.

Had a look into the code and don't see what makes nvim / vim in case of multi-byte different.
Both use encoding for representation of the internal strings, Lets go for German umlauts (because thats my mothers tounge):
For VIM
set encoding=iso-8859-1
echo len('Umlaut Ä')

gives you 8 because Ä is part of the Latin 1 (iso-8859-1) codepage.
set encoding=utf-8
echo len('Umlaut Ä')

will give you 9, because Ä is represented by 2 bytes (and I think this behaves like Chineese which may become 3 bytes in UTF-8).
nvim is completly on the same side, it is ALWAYS on codepage=utf-8.
In your current implementation of filer.vim you will have the same problem on nvim, you can not remove a character by byte-array access:
      call g:clap.input.set(input[:-2])

For my example
echo 'Umlaut Ä'[:-2]
echo len('Umlaut Ä'[:-2])

shows you
Umlaut <c3>
8

So you must have in vim AND nvim the multibyte utf-8 encoding in mind.

Yeah, I can't deny that there also might be some coner issues about the multi-byte in the other places.
But for neovim, I at least don't have to worry about displaying the user input and the cursor movement. For vim, you have to handle them manully. If vim can support the focuable popup like neovim, then we no longer need https://github.com/liuchengxu/vim-clap/blob/master/autoload/clap/popup/move_manager.vim, I'm really not a fan of it.
For the specific issue you just found, this patch might be helpful:
diff --git a/autoload/clap/provider/filer.vim b/autoload/clap/provider/filer.vim
index 75e0ffe..2680e09 100644
--- a/autoload/clap/provider/filer.vim
+++ b/autoload/clap/provider/filer.vim
@@ -90,7 +90,8 @@ if has('nvim')
     if input ==# ''
       call s:goto_parent()
     else
-      call g:clap.input.set(input[:-2])
+      " call g:clap.input.set(input[:-2])
+      call nvim_feedkeys("\<BS>", 'n', v:true)
       call s:filter_or_send_message()
     endif
     return ''

Just let neovim handle these stuffs.


feat: support --anvil-header for customizing anvil user-agent response

Component
Anvil
Describe the feature you would like
much like --fork-header except this would be for Anvil
should support returning current state as response, or some other unique value to that specific anvil process that is running.
by default, should return the version of anvil, though i dont have a preference for this.
Additional context
this is useful when running multiple Anvil processes for matrix testing and trying to drill down failures to specific state changes across CI.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
How I plan on tackling this issue
Mind if I try this one?

Can I contribute to this one?


(Backend integration) server.origin pointing to Vite's dev server

Describe the bug
Hi guys!
I'm working on integrating Vite for developing assets that would be loaded (both locally and when deployed) on a custom, separate backend.
After reading https://vitejs.dev/guide/backend-integration.html our setup is almost complete.
We're left with one issue during local development.
We'll load what's necessary in our custom HTML using absolute URLs to Vite's local dev server, for example:

http://localhost:5173/@vite/client
http://localhost:5173/main.js

This works great, until some entrypoint tries to load some non-js asset.
When working directly with Vite's dev server - everything is relative to the origin, so it just works.
In our case - we found that configuring server.origin with Vite's dev server URL works great.
While this works, we now have to know Vite's dev server URL in config-time, which means we have to also configure server.port, thus giving-up on the built-in available-port getter.
While this isn't too bad, I hoped to find a way to set server.origin to Vite's dev server, while also maintaining its defaults for server port, along with the port-taken behavior.
Proposed solution
While I understand why assets are loaded relative to origin by default, maybe to help with the above, a "server.origin": "absolute" configuration can be accepted?
(or server.absoluteOrigin: true? server.relativeOrigin: false? obviously open for more API ideas)
If this sounds good I can contribute this.
Reproduction
https://stackblitz.com/edit/vitejs-vite-m6xtbc
Steps to reproduce

yarn
yarn dev and yarn custom-backend in split terminals
Access http://localhost:8000

Both images aren't rendered.

Uncomment origin line in vite.config.js

Images are rendered correctly.
System Info
  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 7.17.0 - /usr/local/bin/npm
  npmPackages:
    vite: ^4.2.0 => 4.2.1

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I was also surprised that server.origin is not dynamically constructed (or at least there is no way to do it)

I would also appreciate if origin could be specified in a more dynamic way. I don't know the technical details inside vite, but maybe one of these approaches would be possible?

ability to specify origin when embedding the vite client: <script type="module" src="http://localhost:5173/@vite/client?origin=http://localhost:5173"></script> (this would be my favorite)
set origin to dev server uri automatically if origin: true (or similar) is set in vite config file
ability to specify origin via CLI: vite dev --origin http://localhost:5173

All variants would make the integration of vite in external backends much easier.

I don't know if this is helpful to anyone else, but I created a vite plugin that more or less covers my use case:
https://www.npmjs.com/package/vite-plugin-auto-origin
The plugin tries to extract the protocol/host/port from the last request to the vite dev server and uses that value as server.origin. I think that there might be timing issues if you use multiple domains in parallel, but for normal usage this seems to work just fine. Let me know if this helps you in any way or if there is a missing feature you'd like to add.

@s2b Nice work. Besides the downside of a hardcoded url to the dev server, are there any other reasons to use your plugin over just setting server.origin?

we now have to know Vite's dev server URL in config-time, which means we have to also configure server.port, thus giving-up on the built-in available-port getter.

Isn't this true even if Vite generated server.origin automatically? Won't you need to set the port value in the <script type="module" src="" /> and turn on strictPort: true?
(I agree that it would be a bit easier if Vite generated server.origin automatically.)


[Missing SNMP Polling Profile] Netgear WAX620 WiFi 6 AX3600 2.5Gbit Access Point

Device Vendor: NETGEAR
Device Model: WAX620
System Object Identifier (SysOID): .<IP_ADDRESS>.4.1.45<IP_ADDRESS>
List of critical metrics that you expect in the profile (does not need to be all-inclusive, just a general idea of your expectations):

SSID status, vlan, links, stats, errors, etc...
Client SSID Associations, Failed, etc..
Interface status, statistics, error, discards, etc...
Traffic counters

If there is a New Relic technical support case related to this request, please provide the case number: No
Please provide a public gist with a sanitized (sensitive information removed) SNMP walk of the device. Providing MIB files is not a substitute for an SNMP walk and failure to provide one here will result in delays for closing this issue. The output of these commands shows the "true story" of what a device will respond to in SNMP and is used to ensure that our profiles are efficient and accurate for your devices.
Gist Link: https://gist.github.com/mileperhour/5daaabab44b9a708f82821b0f6a5bdac

Example SNMP walk commands:
# v2c example
snmpwalk -v 2c -t 10 -On -c $COMMUNITY_STRING $IP_ADDRESS . >> snmp_walk.out

# v3 example
snmpwalk -v3 -t 10 -l authPriv -u $USERNAME -a MD5|SHA -A $AUTH_PASS -x DES|AES -X $PRIV_PASS -ObentU -Cc $IP_ADDRESS . >> snmp_walk.out

The walk you provided did not have any vendor specific OID's, and I could not find any published MIBs for this product family.  This profile will categorize the device as an AP and it will collect the interface bandwidth metrics, but this device does not expose anything about the SSID's or clients via SNMP.
From what I saw this is a cloud managed AP, similar to a Meraki, and just like those devices you can't get much info from the device directly. In the case of Meraki we have to connect to their central management UI to get anything useful, I would expect that Netgear does something similar.  If Netgear has an API you can most likely integrate it with New Relic by writing a custom flex script or by finding a prometheus exporter for that API and using remote-write to send the stats directly to New Relic.


Resolve some warnings in DnnExportImportLibrary

Arrgs, looks like that flaky test is biting us again, rerunning...

/azp run


Add better GPU support

Implements the bugs I raised in #4 and #5.
Hope you take and accept PRs! Thanks

@zdk123 which python version did you use?

3.9

Do you have instructions on how to install? After the upgrade I can’t seem to run off GPU :/


Automated cherry pick of #8561

Cherry pick of #8561 on cloud.
/cc  @michelengelen

/release-note-none


Feature: Log/Undo baseline correction, detrending and line noise removal

Is your feature request related to a problem? Please describe.
When an examiner performs baseline correction, detrending or line-noise filtering, every change is immediately affecting the TraceData stored in the CacheFile and can not be undone. Additionally, there is no logging of when or who performed any changes. Currently, for line noise removal,  there is rudimentary logging in the comments field.
Describe the solution you'd like
I want to add a field, where each manipulation is logged, instead of adding this to the comments field. Additionally, i could keep a copy of the data in a transient cache, which is updated every time a new trace is loaded into memory, e.g. via next, previous, or via arbitrary trace selection. Whenever the examiner manipulates the data, the data stored in the CacheFile is being manipulated (as it is right now), but this transient copy of the original stays unaffected. The (to-be-implemented) undo-button would overwrite the data again with this transient copy of the original. When the examiner switches to a different trace, this undo-cache is being cleared, making all changes permanent. This means that as long as the examiner works on this trace, they can undo to the state of the data when loaded, but when a new trace is selected, changes become permanent.
Describe alternatives you've considered
Every change is memorized as a step, and logged (e.g. in the preprocessing field) but the original data is never affected. Instead, whenever a new trace is loaded, each manipulation is performed again on the fly. The disadvantage is an increased load time, especially when many preprocessing steps have been performed, but the huge advantage is that the raw data will never be overwritten. An alternative is that we store a two-dimensional Trace in the CacheFile, with the first the one to be plotted, and the second the raw. This would reduce load time, but is a breaking change to all of our current CacheFiles.
Additional context
See https://github.com/translationalneurosurgery/tool-offspect/issues/42

Maybe @BettinaTrunk and @don-i want to add their opinions?

I also think that the possibility of undoing and logging all actions would be very beneficial. The solution you describe in the field 'Describe the solution you'd like' sounds sensible to me as re-doing changes would probably mostly be necessary while working on one trace. In case the examiner realises that there are (many) changes which were not correct, a new Cachefile can always be re-created from the raw data.

I implemented it  now in the following fashion:
All preprocessing steps are primarly cached, and a log of the steps is saved in a hidden field in the CacheFile. This means that, e.g. when you switch between Traces, or when you load the CacheFile again after a break, those cached steps are only replayed, but do not affect at all the data stored in the CacheFile. The advantage is that they can be undone one by one at any time.
If too many steps are cached, and you feel a drop in speed, or you are comfortable with the preprocessing, you can apply them, either from the menu or with ctrl-a. The steps are applied permanently, can not be undone anymore, and the TraceData in the CacheFile is being overwritten.

Resolved with https://github.com/translationalneurosurgery/tool-offspect/commit/91390a6f4e1bc8b817afb6f3f97ae7cc63289ede

Resolved with https://github.com/translationalneurosurgery/tool-offspect/commit/91390a6f4e1bc8b817afb6f3f97ae7cc63289ede


feat: Add support for rke2_cni: none

Description
Added a different readiness check when the rke2_cni option is set to none.
Current behavior if rke2_cni: none is set is that the playbook hangs indefinitely when trying to check if nodes are ready. (Since nodes can't report ready state without an initialized CNI)
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] 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
[ ] Small minor change not affecting the Ansible Role code (Github Actions Workflow, Documentation etc.)

How Has This Been Tested?
Tested the following rke2_cni:none scenarios using Vagrant and Ansible:

Single node cluster: Works
Single master with multiple workers: Works
Multi-master cluster with High Availability mode:

If disable_kube_proxy: false - keepalived, kubevip and preconfigured LB (used HAProxy) all work
if disable_kube_proxy: true - keepalived and preconfigured LB (used HAProxy) work, kubevip does not, but i think this cannot be made to work since kubevip is dependant on kube-proxy.

in my lab if i set cni to none(rke2_cni: none), nodes doesnt moe to ready state. I can see following error:
container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Am I missing anything here?

@pratik705 Hi,
Judging on what you wrote it seems like expected behavior to me.
When u set rke2_cni: none the cluster should be established, but the nodes (both control-plane and workers) should remain in NotReady state.
I use another method that is easier for me to maintain separately for installing a CNI (in my case cillium using the cilium cli) as an extra step - https://github.com/cilium/cilium-cli/


tree editor UI

With drag-n-drop, colour picker, and image uploader.

We'd have to be a bit careful with a normal tree editor interface, that it remains intuitive to use, and that updates to one section happen to all of its extra references: even with a loop checker, our data may not be a tree: menu 1 could refer to menus 2 and 3, but menu 2 could also refer to menu 3, for example, and in a directed graph sense this is not a loop.  Should this be allowed or should everything have to be a proper tree (not just for the sake of a tree editor UI, but the end user also)?


Include AddTutorialCommandTest

Implementing Attendance sub-feature of Tutorial in progress

Haven't implemented JSON storage for enrolledStudents and attendance in Tutorial yet; in progress!!

lgtm


show past progress before a peer connects

I've downloaded parts of this before. Even though there's no peer yet, it should know how much has been downloaded already, right?

Yep.
Also, the same bug makes it so if you download the whole thing and restart, it'll keep saying "Starting Dat" even if you connect to peers.

Unfortunately, this is not as straightforward as I thought without persisting the stats. I think rather than rewriting how existing stats work, we should do this with hyperdrive-stats integration.

OK, +1 on closing this then


Icon dont't change colors

Icon dont change color when I change color in google assistant or google home app.
Maybe has something to do with this https://github.com/actions-on-google/smart-home-nodejs/commit/55c1062a8eb3d0f758ef0ee44ef7bfc9cd0432be
POST /smarthome 200 2632.166 ms - 136
Request {
  "inputs": [
    {
      "context": {
        "locale_country": "US",
        "locale_language": "en"
      },
      "intent": "action.devices.EXECUTE",
      "payload": {
        "commands": [
          {
            "devices": [
              {
                "id": "9m1"
              }
            ],
            "execution": [
              {
                "command": "action.devices.commands.ColorAbsolute",
                "params": {
                  "color": {
                    "name": "forest green",
                    "spectrumRGB": 2263842
                  }
                }
              }
            ]
          }
        ]
      }
    }
  ],
  "requestId": "11939968081801678759"
}
Headers {
  "content-type": "application/json;charset=UTF-8",
  "google-assistant-api-version": "v1",
  "authorization": "Bearer 123access",
  "host": "c4456e05.ngrok.io",
  "content-length": "323",
  "user-agent": "Mozilla/5.0 (compatible; Google-Cloud-Functions/2.1; +http://www.google.com/bot.html)",
  "accept-encoding": "gzip,deflate,br",
  "x-forwarded-proto": "https",
  "x-forwarded-for": "<IP_ADDRESS>"
}
device state reported: { online: true,
  color: { spectrumRgb: undefined, spectrumRGB: 2263842 } }
Response {
  "status": 200,
  "headers": {
    "content-type": "application/json;charset=utf-8"
  },
  "body": {
    "requestId": "11939968081801678759",
    "payload": {
      "commands": [
        {
          "ids": [
            "9m1"
          ],
          "status": "SUCCESS",
          "states": {
            "online": true,
            "color": {
              "spectrumRGB": 2263842
            }
          }
        }
      ]
    }
  }
}

Is your device an RGB light? Does it look like a standard lightbulb or a 'light bar'? Does the Firestore update correctly?

Its smart rgb light. Its thus sample  codes, no changes made.  it updates in firestore correct


player fails to start on some dash manifests

Have you read the FAQ and checked for duplicate open issues?
yes
What version of Shaka Player are you using?
3.0.4
Can you reproduce the issue with our latest release version?
yes
Can you reproduce the issue with the latest code from master?
yes
Are you using the demo app or your own custom app?
custom and demo app
If custom app, can you reproduce the issue using our demo app?
yes
What browser and OS are you using?
Chrome and MacOS
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
What are the manifest and license server URIs?

https://manifest.googlevideo.com/api/manifest/dash/expire/1599499727/ei/bxlWX_W7Jsua1gLm6JXwAg/ip/2a02%3A2f0b%3Aae06%3A2b00%3Af120%3A79a0%3A51f2%3A7c06/id/9Auq9mYxFEE.1/source/yt_live_broadcast/requiressl/yes/tx/23908006/txs/23908006%2C23908007/as/fmp4_audio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_hd_clear/vprv/1/pacing/0/keepalive/yes/beids/9466585/itag/0/playlist_type/DVR/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Ctx%2Ctxs%2Cas%2Cvprv%2Citag%2Cplaylist_type/sig/AOq0QJ8wRQIhALgQDNQU4dOqNWX9_cMRsMgb7leP-4pvAVqBjmNyzjTOAiA3rBQ4Yfe1TA1srhiutePiBOUK987DolMd-ln3TBHx_A%3D%3D
What did you do?

tried to play a google video manifest
What did you expect to happen?
play it
What actually happened?

Shaka seems to keep updating the manifest but never plays anything
The debug message in the console is as follows
No Period ID given for Period with start time 26771390.001,  Assigning a default
dash_parser.js:1032 Updating manifest...
dash_parser.js:555 No Period ID given for Period with start time 26771400.001,  Assigning a default
dash_parser.js:1032 Updating manifest...
......

Steps to reproduce:

Open chrome with CORS disabled
 open -na Google\ Chrome --args --user-data-dir=/tmp/`openssl rand -base64 6` --disable-web-security --disable-site-isolation-trials
Open the demo app using the manifest provided above

https://shaka-player-demo.appspot.com/demo/#audiolang=en-GB;textlang=en-GB;uilang=en-GB;asset=https://manifest.googlevideo.com/api/manifest/dash/expire/1599499727/ei/bxlWX_W7Jsua1gLm6JXwAg/ip/2a02%3A2f0b%3Aae06%3A2b00%3Af120%3A79a0%3A51f2%3A7c06/id/9Auq9mYxFEE.1/source/yt_live_broadcast/requiressl/yes/tx/23908006/txs/23908006%2C23908007/as/fmp4_audio_clear%2Cwebm_audio_clear%2Cwebm2_audio_clear%2Cfmp4_sd_hd_clear%2Cwebm2_sd_hd_clear/vprv/1/pacing/0/keepalive/yes/beids/9466585/itag/0/playlist_type/DVR/sparams/expire%2Cei%2Cip%2Cid%2Csource%2Crequiressl%2Ctx%2Ctxs%2Cas%2Cvprv%2Citag%2Cplaylist_type/sig/AOq0QJ8wRQIhALgQDNQU4dOqNWX9_cMRsMgb7leP-4pvAVqBjmNyzjTOAiA3rBQ4Yfe1TA1srhiutePiBOUK987DolMd-ln3TBHx_A%3D%3D;panel=CUSTOM CONTENT;build=uncompiled
Manifest content just incase the URL expires:
https://www.dropbox.com/s/nitrrj0lzzafw0l/x.mpd?dl=1

Hello @mihaiav ,
I'm got Error 403 (Forbidden) when I loaded the test manifest. It looks like we don't have permission to get the url. Could you please get the permission? Thank you!

Hello @mihaiav ,
I got HTTP 403 (Forbidden) error when I tried to load the manifest. It looks like we don't have the permission to access the url. Could you please get us the permission? Thank you!

@mihaiav, can you please send updated URLs?  We can not access the ones you sent before.


Implement update operation

fixes #4
This is currently a WIP.

Codecov Report

Merging #5 into master will decrease coverage by 7.17%.
The diff coverage is 95.45%.

@@            Coverage Diff             @@
##           master       #5      +/-   ##
==========================================
- Coverage   97.46%   90.29%   -7.18%
==========================================
  Files          16       20       +4
  Lines         158      237      +79
  Branches        8       17       +9
==========================================
+ Hits          154      214      +60
- Misses          3       19      +16
- Partials        1        4       +3

Flag
Coverage Δ

#api
95.72% <95.45%> (-0.2%)
:arrow_down:

#ui
85% <ø> (-15%)
:arrow_down:

Impacted Files
Coverage Δ

api/src/routes/wish.js
100% <100%> (ø)
:arrow_up:

api/src/util/util.js
93.75% <93.75%> (ø)

ui/src/app/App.js
100% <0%> (ø)
:arrow_up:

ui/src/childinfo/ChildInfo.js
65.38% <0%> (ø)

ui/src/wishDetails/WishDetails.js
100% <0%> (ø)

ui/src/services/WishDetailsService.js
100% <0%> (ø)

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 7a01440...7e14d5a. Read the comment docs.


to address #92

This is to address the same issue as reported by #90, but that pull request essentially throws lhs method out of the window, which is unnecessary.

SSLSpec failed on IllegalArgumentException resulting from empty greeting string, though all tests run through in my local machine. I can hardly relate the error to the commits. Have we ever tested Travis with the current test ?

Travis is perhaps too flaky. We could consider trying out shippalble, they are compatible with travis. Also, it might help having compilation and tests in separate runs:
 script:
  - sbt -J-Xss2M -J-Xmx4G ++$TRAVIS_SCALA_VERSION compile test:compile
  - sbt -J-Xss2M -J-Xmx4G ++$TRAVIS_SCALA_VERSION test

@ahjohannessen agreed, travis is really sucking. Happy to try shippable, what's involved in setting it up?

@timperrett I think there is not much to it as they are compatible with .travis.yml - You'll need an account (free via github login) and then you can enable remotely by pointing to github repo.

I already have it enabled on my fork :)


js: Break cyclic dependency between reload and server_events.

reload.js and server_events.js was forming a 2-way cyclic import. To break the cycle, I passed server_events.cleanup_event_queue to reload module via its initialization function in ui_init and stored this function in a global variable to be later used by reload module without having us import server_events and hence breaks the cycle.

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

@timabbott Addressed your suggestion!

Merged, thanks @Lalit3716!


[critical] build broken by let keyword

https://github.com/visionmedia/debug/commit/ba8a424d41e9dc6129e081ac3aa9715be6a45fbd introduced the let keyword breaks our build:
<our-path>/node_modules/karma/node_modules/http-proxy/node_modules/follow-redirects/node_modules/debug/src/node.js:132
09:17:34,371 WARN  -     let val = process.env[key];
09:17:34,371 WARN  -     ^^^
09:17:34,371 WARN  -
09:17:34,371 WARN  - SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode

Duplicate of #603.
Please look at the issues tracker in the future.


Bump fmtlib to 10.0.0

Bump fmtlib to 10.0.0. Full release desc - https://github.com/fmtlib/fmt/releases/tag/10.0.0
In this release:

New floating-point formatting algorithm and many floating-point relative fix
Improved C++20 module support
A lot improvements in date and time functions
Many new code formatter
Fixes on UTF-8 support
Fix many warnings, build improved

There seems some compile error while using fmt 10 in CI. Could you try to investigate it? Or you can wait me for some free time to handle it (maybe next week).

This test case failure didn't relate to the current PR: https://github.com/apache/incubator-kvrocks/actions/runs/4957567221/jobs/8869740176?pr=1435
I am investigating now.

@aleksraiden Thanks for your contribution.


Add expectOr methods for custom error handling on failed expects

Reopening #1634 so we can get it across the finish line.  It looks like this is binary compatible.  Apologies for this falling off my radar.
Is this helpful as is, or do we want to address the discussion in #1632 to make it useful?
/cc @kailuowang

:+1: Definitely helpful for my use cases.

Alright, MiMa liked this.  We can get this into 0.18.4 if it's positively reviewed.


Using wrong method in next_link when list operation using POST

Hi @iscai-msft , I got an issue about list operation using post, but next_link still using get method.
It made this request failed.
code:https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/policyinsights/azure-mgmt-policyinsights/azure/mgmt/policyinsights/operations/_policy_states_operations.py#L139
python issue: https://github.com/Azure/azure-sdk-for-python/issues/17280

hey @00Kai0 , this is by design.

How to fix this: It gets a little hard fixing this, bc this is not the default behavior. The fix needs to happen in the swagger. I can't find this swagger, so I'm going to show the changes you have to make in this fake pr. I think this code will work, can't guarantee since I don't have the specific swagger. @00Kai0 can you send me the swagger when you have a chance?

Why it's not working like you think

The paging operation you're showing me is a paging operation whose initial call, and all subsequent calls are defined in the same operation in the swagger. In this case, we always have the next calls be get calls against the next link. In order to override this behavior, we basically have to tell autorest "no, we really want you to have subsequent calls be a post".

Thanks for your answer. @iscai-msft , most queryResult operations are using post calls here: https://github.com/Azure/azure-rest-api-specs/blob/master/specification/policyinsights/resource-manager/Microsoft.PolicyInsights/stable/2019-10-01/policyEvents.json#L90

@00Kai0 thanks for linking the swagger you guys use. I've updated my example showing you how to make the necessary changes. Please try these changes out for yourself on the swagger and let me know how it goes


spark: Vulnerable version of commons-codec (1.11) present in openlineage-spark_2.12 » 1.23.0

Details:
Vulnerability Details (PRISMA-2021-0055)
IBM X-Force ID:   177835
DESCRIPTION:   Apache Commons Codec could allow a remote attacker to obtain sensitive information, caused by the improper validation of input. An attacker could exploit this vulnerability using a method call to obtain sensitive information.
CVSS Base score: 7.5
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/177835 for the current score.
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

  <parent>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-parent</artifactId>
    <version>42</version>
  </parent>
  <groupId>commons-codec</groupId>
  <artifactId>commons-codec</artifactId>
  <!-- Remember to update the version in default.properties as well -->
  <version>1.11</version>
  <name>Apache Commons Codec</name>
  <inceptionYear>2002</inceptionYear>

Source: openlineage-spark_2.12-1.23.0/META-INF/maven/commons-codec/commons-codec/pom.xml

@mobuchowski Should we close this issue?


BUG:

In "MainMenu > Play", the buttons within the new game dialog seems not reacting well, their different states (highlighted etc...) does not update

FIXED
There was no real problem, the button's states were perfectly working but the background had the same sprite has the highlighted button so we could not see the transition.
Problem solved by tweaking the dialog box background color.


Karma is reporting everything twice

If I run my karma tests like this in node then the 'dots' reporter is outputting everything twice
var KarmaServer = require('karma').Server;
var karmaRunner = require('karma').runner;

var karmaConfig = {
    basePath: '',
    autoWatch: false,
    frameworks: ['jasmine'],
    reporters: ['dots'],
    files: [].concat(
        tasks['vendorJs'].getOutput(),
        'node_modules/angular-mocks/angular-mocks.js',
        'node_modules/ng-describe/dist/ng-describe.js',
        tasks['ts'].getOutput(),
        tasks['templates'].getOutput(),
        'Tests/Client/**/*.spec.js'
    ),
    browsers: ['PhantomJS']
};

var karmaServer = new KarmaServer(karmaConfig);
karmaServer.start();

karmaServer.on('browser_register', function (browser) {
    karmaRunner.run(karmaConfig);
})

This will output the following
05 02 2016 13:31:08.353:INFO [karma]: Karma v0.13.19 server started at http://localhost:9876/
05 02 2016 13:31:08.361:INFO [launcher]: Starting browser PhantomJS
05 02 2016 13:31:09.840:INFO [PhantomJS 2.1.1 (Windows 8 0.0.0)]: Connected on socket /#1rTJlVKpIc8bFuWGAAAA with id 17442726
.....
PhantomJS 2.1.1 (Windows 8 0.0.0): Executed 5 of 5 SUCCESS (0.003 secs / 0.066 secs)
.....
PhantomJS 2.1.1 (Windows 8 0.0.0): Executed 5 of 5 SUCCESS (0.003 secs / 0.066 secs)

My tests aren't actually being run twice but if I log something from a test it will show up twice in the output.
Any idea why this is happening?
Let me know if including my package.json or DEBUG output would be useful

Could you try checking if there is another phantomjs instance running that could be the reason for this.

There aren't any other node or phantom js process running. I noticed that if I give the karma runner a callback function like this
karmaRunner.run(karmaConfig, function () { });

Then I will only see the output once and when I kill the process node and phantom will keep running. But that may be unrelated

@robianmcd Are any of the output coloured? Or both?

@budde377 both are coloured

Same here but only with the phantomjs launcher, so this is probably an issue with it.

I still see the issue when I run the tests with chrome.

@robianmcd These issues might be related to the launchers and not to the karma lib. Some of the launchers, for example Firefox work properly by me.

I have same issue with karma-webdriver-launcher.

I had similar issues when trying to get a prettifier working - I'd get in my terminal both raw console output and the prettified output.
But, I was able to find a karma.conf setting that stopped the raw console output, returning only the prettified output.
karma.conf has a property called client, which is an object with several properties of its own. The one relevant here is captureConsole. This defaults to true, which means any console logging in the browser is sent back to your bash, too. Setting it to false solved my duplicate output issues. I wonder if making that change would help with this?
    client: {
        captureConsole: false
    }

I notice same issue in only one my spec file. The others specs are runed once

Chrome runner +dots or spec reporter result in same.

@tcschiller Does this eat errors? Looks like the right solution, as long as Karma still reports VM-level exceptions and not just test failures.

@EzraBrooks That's a great question, and I can't off the top of my head recall seeing it one way or another. Worthy of a test.

I've just tested this on a mid-size Angular application testing in Chrome Headless. At least for me, setting captureConsole: false appears to do nothing at all.

I realize this is now a very old question, but @robianmcd how are you running your tests?  Is there a script or tool?  Also, are files included/loaded through any other (non-karma) configuration?
I came upon this with an Angular v6 CLI app (with Typescript) and getting output duplicated 2 or 3 times in the console.  In my karma.conf.js I had two reporters defined which was causing part of the issue:
reporters: ['dots', 'kjhtml'],
Changing that to just 'dots' fixed this issue for me.

On Windows some of the browsers require CLI flags. Without the flags they can do duplications or fail, so it is always good to read the launcher description. Here are the custom launchers I use on win7:
        customLaunchers: {
            "ch": {
                "base": "Chrome",
                "flags": ["--user-data-dir=''", "--disable-web-security"]
            },
            ff: {
                base: "Firefox"
            },
            ie10: {
                base: "IE",
                'x-ua-compatible': 'IE=EmulateIE10',
                flags: ["-extoff"]
            },
            ie11: {
                base: "IE",
                'x-ua-compatible': 'IE=EmulateIE11',
                flags: ["-extoff"]
            },
            op: {
                base: "Opera",
                flags: ["--ran-launcher"]
            },
            ph: {
                base: "PhantomJS"
            }
        },

This doesn't use the PhantomJS duplication though.

I use the singleRun: true config option. It's worth a try too...

I'm not working on the project I was having these issues on but I'll pass these additional ideas along to someone who is.
Thanks!

I checked again, I experience the same problem with Opera. I am pretty sure it worked well with an old version with --ran-launcher, but the current version tries to run the tests twice.

I move this to the repo of the opera launcher, maybe somebody fixes it there.

I did some investigation, and it looks like runner.js writing directly to process.stdout on line 57 is the culprit.
Since the example in the original post has a reference to the server, it is technically possible to get around using the runner altogether, but it is likely not documented nor trivial. (Involves using the servers _injector to get its executor and invoking executor.schedule)
Perhaps we should be asking for a new method on server instances to run the configured tests.

Any ideas here? I'm also running karma with grunt-contrib-watch and have the same issue that @ezk84 has.
Basically, my grunt script runs karma:unit (with singleRun = true), and then karma:continuous:start (this should start up my karma server, but not run my tests. singleRun = false, background = true). At this point, everything is working properly. However, when I change one of my source files, and it triggers grunt-contrib-watch to fire off additional tasks (karma:continuous:run), the karma output is duplicated.
If I run karma:continuous:run from another console window, I see the correct output once in the new console, BUT I also see the duplicated output in my original console window that's running grunt watch. I'm thinking that grunt is outputting the results from the karma tests, even though the karma reporter is outputting the results to the console as well. For example, I see the dots from the "dots" reporter only once, but the final SUCCESS message is duplicated.
For now I'm just going to ignore the duplicate output, but just wondering if anyone has any ideas on how to prevent this?

Make sure that you don't include the test files:
files: [
      'test-main.js',
      { pattern: 'test/*.js', included: false }
],


Undeterministic propagation of --dry option in tmt run

Recently I found an interesting behavior of the --dry option if it is used only for the provision step. It also sets the dry option of Plan objects.
Plan.opt('dry') == True when $ tmt run --all --remove provision --how virtual --dry
Plan.opt('dry') == None when $ tmt run --all --remove provision --how virtual --dry plan
This causes a bug in the imported plan feature, which is fixed by a workaround https://github.com/teemtee/tmt/commit/47b9250f7f550b35ce1f5ac5b56a9e10ff9d903e.
Do you have any idea why it happens? Is it intentional for some reason? Or well a hidden bug?

Do you think it is possible that these three lines https://github.com/teemtee/tmt/blob/47b9250f7f550b35ce1f5ac5b56a9e10ff9d903e/tmt/base.py#L2660 may cause the problem?
A PDB tells me that these steps and Plan shares the same _options diction from tmt.utils.Common.
id(Common._options)
Out[21]:<PHONE_NUMBER>76256
id(Plan._options)
Out[22]:<PHONE_NUMBER>76256
id(tmt.steps.finish.Finish._options)
Out[23]:<PHONE_NUMBER>76256
id(tmt.steps.execute.Execute._options)
Out[24]:<PHONE_NUMBER>76256

That might be it!

The problem is that all classes inheriting from Common share the same dict unless it is overridden.
# Plan class uses Common._options
$ tmt run --all --remove provision --how virtual --dry

# Plan class receiver default context from click subcontext *
$ tmt run --all --remove provision --how virtual --dry plan

Plan context override https://github.com/teemtee/tmt/blob/47b9250f7f550b35ce1f5ac5b56a9e10ff9d903e/tmt/cli.py#L309
I have tried to fix this using a metaclass that creates a copy of _options dict for each child here: https://github.com/teemtee/tmt/pull/1983
@happz How would you solve this issue? Is it possible to get default context from click even if plan is not specified on CLI?

The problem is that all classes inheriting from Common share the same dict unless it is overridden.
# Plan class uses Common._options
$ tmt run --all --remove provision --how virtual --dry

# Plan class receiver default context from click subcontext *
$ tmt run --all --remove provision --how virtual --dry plan

Plan context override
https://github.com/teemtee/tmt/blob/47b9250f7f550b35ce1f5ac5b56a9e10ff9d903e/tmt/cli.py#L309
I have tried to fix this using a metaclass that creates a copy of _options dict for each child here: #1983
@happz How would you solve this issue? Is it possible to get default context from click even if plan is not specified on CLI?

I don't have any proposal, as of now, but I've been poking this particular set of attributes for some time. To support multiple phases on the command line (prepare -h shell --script ... prepare -h ansible --playbook ...), we will have to get rid of the singular aspect of _options and _context anyway. Now all prepare steps share the same one, as class variables, and the latter overwrites the former... So, I'm in the area, but I don't have the proposal ready - it should play nicely with steps where this approach is also used, see https://github.com/teemtee/tmt/blob/main/tmt/steps/prepare/init.py#L64. I'm experimenting with instances of these step classes.
Your metaclass might also work, although I did not try this option yet. I'm afraid it would work only for cases where classes based on Common are instantiated, but _context and _options are also used as class variables... So, no helpful advice from my side, yet, all I have at the moment is the bigger picture :(

The current problem caused by the issues has a workaround here https://github.com/teemtee/tmt/commit/47b9250f7f550b35ce1f5ac5b56a9e10ff9d903e. The question is, whether we will live with the workaround and be aware of such behavior until you refactor these options, or the metaclass from https://github.com/teemtee/tmt/pull/1983 and possibly revert the workaround.
I am OK with both.
@psss: What do you think?

I am trying to fix this issue with a simple fix https://github.com/teemtee/tmt/pull/2050, which focuses only on the Plan._options dictionary. The generic solution with the metaclass from https://github.com/teemtee/tmt/pull/1983 has an error when running in python3.6, and the fix would require a lot of code modifications.
As @happz plans to change the _options and the _context propagation in the future, I propose temporarily using this fix https://github.com/teemtee/tmt/pull/2050 instead of a generic solution from https://github.com/teemtee/tmt/pull/1983.
@psss @happz What do you think?


Why is this closed? I need to connect to a remote SQL Server and am getting the same error. I cannot change anything on the server. Downgrading openssl is not really an option. Running Ubuntu 20.4.

Why is this closed? I need to connect to a remote SQL Server and am getting the same error. I cannot change anything on the server. Downgrading openssl is not really an option. Running Ubuntu 20.4.
Originally posted by @RadBoris in https://github.com/microsoft/msphpsql/issues/252#issuecomment-655840815

Hi @RadBoris please check the related issues #1110 and #1112

Any update, @RadBoris ?

Thanks for the reference @yitam! I used the official instructions but they did not work for me on a fresh install of Ubuntu 20.04. I downgraded my openssl version and used freetds to connect to the server. Will revisit when official support for Ubuntu 20.04 is announced.

Hi @RadBoris, glad that it works for you now, but it's the server and openssl versions, not ODBC driver. You either upgrade your server or downgrade the security setting as a workaround, which is not recommended, as already explained in the related issues.


todo: compare network outputs for different trade obs

model size makes network less variable w.r.t. inputs
small models will change outputs much more than large models,
large models do the same action every step where small models do not

try the variance of 1/Ni

using a custom glorot_normal initializer that matches the paper. also, I was generating parameters sampling 1xlength glorot_normal vectors, but that yields different metrics than something like sqrt(length)xsqrt(length)


A bunch of incorrect aggressive removal listed for Safari 9.1.3 only

I don't think any of the APIs below were actually removed in Safari 9.1.3, and the catalog seems to be aware that they were present both before and after.
https://web-confluence.appspot.com/#!/catalog?releaseKeys=["Safari_9.1.3_OSX_10.11.6","Safari_8.0.8_OSX_10.10.5","Safari_7.1.8_OSX_10.9.5","Safari_6.2.8_OSX_10.8.5","Safari_6.0.5_OSX_10.7.5","Safari_5.1.9_OSX_10.6.8","Chrome_57.0.2987.98_OSX_10.11.6","Firefox_52.0_OSX_10.11","Edge_14.14393_Windows_10.0"]&releaseOptions={"Safari_9.1.3_OSX_10.11.6":false,"Chrome_57.0.2987.98_OSX_10.11.6":true,"Firefox_52.0_OSX_10.11":true,"Edge_14.14393_Windows_10.0":true}&numAvailable=[4,5,6,7,8,9]&currentPage=0&gap=5&itemPerPage=15&searchKey=""

@mdittmer Maybe there's some stale data from a previous crawl there still?  I checked a couple and the API catalog does show them present in 8 and 10 but not 9 (eg. CustomEvent.detail and window.indexedDB).
Looks like just a few and the history isn't as important as the current state, so dropping urgent label.

Poking at Safari 10.1.2 I see that properties which are supposed to be on WebGLRenderingContext.prototype are actually on an ancestor prototype which isn't exposed on window (WebGLRenderingContextBasePrototype).  But I don't see that interface listed in the catalog either.
@mdittmer we walk the whole prototype chain of interface objects we find, right?  Shouldn't we still find these properties somewhere, even if we end up reporting that they're on the wrong interface?
Re-adding urgent in case this represents a more fundamental data issue.

I'm seeing the same thing. Everything other than WebGLRenderingContext APIs are indeed not present in Safari 9.1.
I still need to dig into the code, but my guess is that since window.WebGLRenderingContext.prototype.__proto__ is not exposed on window, the code doesn't know what API to add it to. Of course, this can be fixed. If we find that the shortest path from window to window.Foo(.__proto__ ^ n) is window.Foo(.__proto__ ^ n), we should add it to Foo.

It seems a priori really unlikely that a property would be present in Safari 8.0.8, missing in Safari 9.1.3 and present in Safari 10.1.2. This is also the only Aggressive Removal claimed for any version of Safari. Like, it's possible than 9.1.3 accidentally dropped a lot of APIs but it seems pretty unlikely. I am really skeptical any of these are real, and I wonder how you tested.

Using BrowserStack to poke at Safari 9.1.3 I see there's definitely something weird going on with property enumeration:
`indexedDB` in window
> true
Object.getOwnPropertyNames(window).indexOf('indexedDB')
> -1
Object.getOwnPropertyNames(Object.getPrototypeOf(window)).indexOf('indexedDB')
> -1
Object.getPrototypeOf(Object.getPrototypeOf(window))==Object.prototype
> true

So this looks similar to #201 where properties exist but don't show up with getOwnPropertyNames.  @cdumez, sound familiar by any chance?

Object.getOwnPropertyNames(window).indexOf('indexedDB') returns a valid value (i.e. not -1) in Safari 11.

Yes, it's fine now - just seemed broken in Safari 9 only.

It's totally possible that Object.getOwnPropertyNames had a bug in some Safari 9.x versions but that's pretty far back. Regardless, it doesn't seem helpful to interpret this bug as aggressive removal of a bunch of APIs.

I agree it's not helpful, but it's pretty hard to do anything else.  Unless I'm missing something, there's no good generic way for us to discover that these APIs exist without getOwnPropertyNames working.
I suppose we could generate a list of candidate APIs (based on what we found in other browsers) and try explicitly probing for each of them rather than relying solely on enumeration.  But I think that would add significant complexity to the architecture.  @mdittmer WDYT?
We could also just make a hard-coded list of the APIs we know weren't actually removed from Safari 9 and probe for those (or even just manually augment the list with them).  That seems like a pretty ugly hack, but would work if it's really valuable to do so.
Any other ideas?

Another option is to hack around this for WebGLRenderingContext only - that seems to be the main one affecting the graphs.  In that case it does seem like we should be able to discover the properties on the ancestor prototype (WebGLRenderingContext does show up in Object.getOwnPropertyNames(window)) and copy them down to the right interface.  Understanding why that isn't already working is probably the first priority here (since it could impact other APIs elsewhere too).

I don't understand the testing approach very well. I would imagine that before claiming something is removed in a release, you could have a double-check test pass that directly checks for its presence regardless of enumeration mechanisms.
This issue makes the Safari aggressive removal graph look weird and bogus. Especially so because there are multiple 9.1.3 data points. So it looks like there was a big time range of heavy aggressive removal, without closer examination.

Yeah, I agree it's not ideal.  As I understand it, the current architecture is split into three steps:

For each browser/version/OS, collect a JS object graph dump from the device and save it to cloud storage (this is the time consuming and sometimes unreliable part and so done offline somewhat manually)
For each browser/version/OS, process the object graph dump into an API list (this is where the more brittle heuristics happen, so we can tweak and re-run this easily)
Use the above API lists to compute the metrics and expose them as catalog data.

So there are benefits to having the code that is actually running on the browser know nothing about what APIs might be "removed" - it's a one-directional pipeline of information.

So the WebGLRenderingContext issue helped me discover a Safari 9.1 peculiarity, and an issue that is definitely a data collection bug.

Not all constructors are constructors

The source of the issues with WebGLRenderingContext is that its constructor is not a function: typeof WebGLRenderingContext === WebGLRenderingContext instanceof Function === false.
In order to capture this API accurately, we would need the upstream object graph generator to use a new heuristic identifying "functions and function-like things", and for capturing function names.
In addition, we would need to modify the heuristic for API name detection: it looks for thePrototype.constructor, which right now is Object on WebGLRenderingContext.prototype.__proto__; in cases such as this we would need to remember that we are on the prototype chain of something called "WebGLRenderingContext" and shove properties on to it when !thePrototype.hasOwnProperty('constructor').

**Data collection needs to check thePrototype.hasOwnProperty('constructor') (via equivalent object-graph-js API).

Right now, the check for thePrototype.constructor in the Object Graph => API list transform walks the prototype chain. This is probably the wrong thing to do. We should only trust a prototype's constructor to correctly identify the interface when it is an own property.
Filed #210 to track this issue.

Further investigation has revealed that in Safari 6, 7, 8, WebGLRenderingContext.prototype.constructor does exist (without an extra level of indirection to [...].__proto__ as in Safari 9.1). I think for these earlier releases we are hitting this code path intended for libraries such as Math or console (and at some point extended to grab properties from the .prototype property). That code path is missed once the path looks like Foo.prototype.__proto__(.APIs) instead of Foo.prototype(.APIs).

If it proves difficult to work around the getOwnPropertyNames issue in Safari 9.x, how would everyone feel about just omitting everything prior to Safari 10? Long time series would be nice, but the actionable stuff is all about what the state during the past year was.

We get less useful data for metrics that rely on "before the 1-year grace period" if we only have two Safari releases, though.

The output files from main/og_to_journal.es6.js look like #217 will fix the WebGLRenderingContext case.

CustomEvent.detail is genuinely missing from CustomEvent.prototype in Safari 9.1. It exists in Safari 8 and 10.

The "Aggressive Removal metric" part of this is fixed in prod. Note cross-referenced outstanding issue.
@othermaciej does this look better? (Of course, properties like indexedDB that are covered in #229 still show up in the link you provided.)

Yes, looks more sensible now.


Support for PlasmoVoice. SimpleVoiceChat isn't the only VC mod.

Plasmo Voice is supported.

The Modrinth page's description never mentioned it.


Bracket completions doesn't work when Intellisense menu is open

Does this issue occur when all extensions are disabled?: Yes/No

Version: 1.70.0-insider (user setup)
Commit: b4d5b4ed69af953901051b1f049851b9dca3563e
Date: 2022-07-28T05:16:28.624Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22000
Steps to Reproduce:
When Intellisense menu and a grey text prediction are shown at the same, bracket completion doesn't work.
Example 1:

Code in file
from tkinter import font
import turtle
import random
import time
screen = turtle.Screen()
screen.title("DATA")
screen.setup(width = 700, height = 700)
Example 2

Example 3

cc @hediet

This works now.


Failure msg reports incorrect line number on Windows

The following test parser correctly reports line 6 as the errored line on Ubuntu and Mac but incorrectly reports line 5 on Windows (Windows Server 2022).
Expected Behaviour: The output to be consistent across all operating systems, with all of them reporting line 6 as the errored line.
Test
import fastparse._
import MultiLineWhitespace._

def fruits[_: P] =
  P(Start ~ "Apple" ~ "Banana" ~ "Orange" ~ End)

val string =
  """
    |Apple
    |   Banana
    |     Orange
    |
    |Sugar
    |""".stripMargin

val failure = fastparse.parse(string, fruits(_)).asInstanceOf[Parsed.Failure]
println(s"Error: ${failure.msg}")

Test Output
Error: Position 6:1, found "Sugar\n"   // Ubuntu and Mac
Error: Position 5:1, found "Sugar\r\n" // Windows

what version of fastparse are you on? I fixed some windows line number bugs recently https://github.com/com-lihaoyi/fastparse/pull/282

I'm on 2.3.3. I guess that might be it. I will test it now.

Yep 3.0.1 resolves it. Thanks heaps. Legend!


Formatter not working when pyproject.toml not at project root

My project dir structure is like this:
/project
/project/django
/project/django/pyproject.toml
/project/django/app/template/blop.html

The djlint config is inside pyproject.toml :
[tool.djlint]
profile="django"
max_line_length=120
indent=2
blank_line_after_tag="load,extends,include"

The blop.html file language mode is django-html
When running djlint from command line it work as expected:
[/absolute/path/to/project/]$ djlint --reformat django/app/template/blop.html
But when running the formatter from vscode it seems to apply a default configuration (blank_line_after_tag is not respected)
I'v tried to force djlint configuration in vscode config but it still doesn't work:
{
  "djlint.useEditorIndentation": false,
  "djlint.configuration": "/absolute/path/to/project/django/pyproject.toml"
}

The only way I've found so far to have it working is to put pyproject.toml at project root. But it is not a nice solution for me.
Other notes:

There is a python venv. Workspace is configured to use it.
djlint 1.19.0 is installed inside the venv

Did I miss something ? How to have djlint-vscode respect my pyproject.toml file ?
By the way there is a way to have logs of what djlint-vscode is doing ?

I wonder if this

should be the directory of the current file, not the project root?
Right now it is the directory that is opened in VSCode. If it were to use the current file directory it will probably work.
I'm not sure if this is the right vs command, but vscode.window.activeTextEditor.document.uri.fsPath sounds like it would work.

@monosans  Easier said than done lol, I found a way that works and uses the pyproject.toml file correctly. I'll put a PR for you.

Fixed in v2022.10.0. Many thanks to @christopherpickering for the help and quick fix!

Thanks for he fast fix ! It solve the issue main issue for me without having to specify the configuration file.
Nevertheless, it don't explain why specifying the configuration file make it not used by djlint.

Nevertheless, it don't explain why specifying the configuration file make it not used by djlint.

AFAIK --configuration doesn't support pyproject.toml, only .djlintrc format.

@monosans thats correct, sorry I didn't notice that @fabien-michel.

By the way there is a way to have logs of what djlint-vscode is doing ?

The error logs are in Developer Tools (Ctrl+Shift+I or Help > Toggle Developer Tools).


Update?

Is there any update on this?  I don't see the Xcode 10 channel anymore.  Does that mean it's in the Beta or Alpha?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8d2cc0ff-a223-c1da-fc07-1a0f394c465c
Version Independent ID: 120713f7-69de-afd6-65d2-1546e414cc53
Content: Introduction to macOS Mojave - Xamarin
Content Source: docs/mac/platform/introduction-to-macos-mojave/index.md
Product: xamarin
GitHub Login: @lobrien
Microsoft Alias: laobri

@warthenr yes, the mac support shipped in the latest Stable release (earlier this week). Looks like we missed a doc update, but will take care of that ASAP. Thanks for letting us know!


SegFault when using an AQL for loop through edges

My Environment

ArangoDB Version:        3.7.1
Storage Engine:             RocksDB
Deployment Mode:        Single Server
Deployment Strategy:   ArangoDB Starter in Docker
Infrastructure:               AWS
Operating System:       Linux version 4.15.0-1065-aws (buildd@lgw01-amd64-035) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04))
Total RAM in your machine:        4GB
Used Package:              Debian or Ubuntu .deb

Hello, I run into troubles after having updated the arangodb version to 3.7.1.
Each time that I am using the AQL command below, the container stops with a segfault. It is the same with all the edge types and databases.
FOR vertex, edge IN 1 OUTBOUND @_id @edge_name
    return vertex

Here are the logs:
arangodb.1| 2020-08-24T13:34:09Z [1] FATAL [a7902] {crash} ArangoDB 3.7.1 [linux], thread 6 [SchedWorker] caught unexpected signal 11 (SIGSEGV) accessing address 0x0000000000000040: signal handler invoked
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 1 [0x00007f05c02da56d] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 2 [0x00007f05c325a515] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 3 [0x00007f05c0dbe933] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 4 [0x00007f05c0c7b946] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 5 [0x00007f05c0dcf0ea] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 6 [0x00007f05c0dd0c6a] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 7 [0x00007f05c0dd2d02] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 8 [0x00007f05c0fdd4da] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 9 [0x00007f05c0170d1e] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 10 [0x00007f05c0fd6584] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 11 [0x00007f05c12c8bcc] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 12 [0x00007f05c12c9e69] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 13 [0x00007f05c133dfe6] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 14 [0x00007f05c13633ca] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 15 [0x00007f05c1076155] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 16 [0x00007f05c122b579] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 17 [0x00007f05c02d6fdb] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 18 [0x00007f05c025bfbf] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [308c3] {crash} frame 19 [0x00007f05c3261068] *no symbol name available for this frame
arangodb.1| 2020-08-24T13:34:09Z [1] INFO [ded81] {crash} available physical memory:<PHONE_NUMBER>, rss usage: 269983744, vsz usage:<PHONE_NUMBER>, threads: 28
arangodb.1| automatically choosing storage engine
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [e52b0] ArangoDB 3.7.1 [linux] 64bit, using jemalloc, build tags/v3.7.1-0-gdd98295dcc, VPack 0.1.33, RocksDB 6.8.0, ICU 64.2, V8 7.9.317, OpenSSL 1.1.1g  21 Apr 2020
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [75ddc] detected operating system: Linux version 4.15.0-1065-aws (buildd@lgw01-amd64-035) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #69-Ubuntu SMP Thu Mar 26 02:17:29 UTC 2020
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [25362] {memory} Available physical memory:<PHONE_NUMBER> bytes, available cores: 2
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [43396] {authentication} Jwt secret not specified, generating...
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [144fe] using storage engine 'rocksdb'
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [3bb7d] {cluster} Starting up with role SINGLE
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [6ea38] using endpoint 'http+tcp://<IP_ADDRESS>:8529' for non-encrypted requests
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [a1c60] {syscall} file-descriptors (nofiles) hard limit is 1048576, soft limit is 1048576
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [3844e] {authentication} Authentication is turned on (system only), authentication for unix sockets is turned on
arangodb.1| 2020-08-24T13:34:21Z [1] WARNING [ad4b2] found existing lockfile '/var/lib/arangodb3/LOCK' of previous process with pid 1, and that process seems to be still running
arangodb.1| 2020-08-24T13:34:21Z [1] INFO [e6460] created base application directory '/var/lib/arangodb3-apps/_db'
arangodb.1| 2020-08-24T13:34:22Z [1] INFO [cf3f4] ArangoDB (version 3.7.1 [linux]) is ready for business. Have fun!

Thank you very much for your time and experience!
Nicolas

Thanks for the bug report. Will check...

Can you try adjusting the query string so it becomes
FOR vertex, edge IN 1 OUTBOUND @_id @@edge_name
    return vertex

and use a collection name bind parameter named @edge_name?
AFAICS this should work.
Will now try to figure out why the simple bind parameter does not work as expected.

You are right, it does work with a collection name bind.
What are the differences between the two?

It's the internal code path that is different for the two.
It worked in 3.6, so it looks like a regression and I will try to fix it.

Fixed via the above PRs.
The bugfix should be released with either 3.7.2 or 3.7.3. I can't say for sure yet.

Setting milestone to 3.7.3 just so this ticket won't be forgotten.

Thank god somone discovered this i was like wtf does it keep crashing 😄

Hi @KevinAuSon and @insider777,
Version 3.7.3, which includes a fix for this issue, has just been released.
From the Changelog:

Fixed issue #12507: SegFault when using an AQL for loop through edges.

Please comment in case the SegFault still occurs after upgrading.
Thanks


Please add "tag" field to post

Laravel Version: 5.4.22
Voyager Version: 0.11.10
PHP Version: 7.1
Database Driver & Version:

Description:
add tag to post like wordpress
Steps To Reproduce:

Voyager is intended to be a Admin tool for managing your site, not a CMS.  It provides the functionality needed to add this functionality yourself.  The Posts and Pages models that it currently ships with are there as examples, not as finished products.  Due to this, I must deny your request.  We will not be expanding the "CMS-like" functionality of Voyager.
As a side note, there was talk a while ago about someone building a CMS using Voyager, but I haven't heard anything in a while, so I don't know the current status.


Updated tomcat playlist to copy the results from docker container

Updated playlist to copy the results from docker container
issue #578
Signed-off-by: Chandrakala<EMAIL_ADDRESS>

https://ci.adoptopenjdk.net/view/work in progress/job/test_personal/778/console

@chandrams - Any update on this?

Festival of Lights in India, I suspect we will get an update on Thursday or after.  :)

@Mesbah-Alam - Tomcat output logs aren't in the junit format.  I have added the changes to copy the result logs though, let me know if you want to retain them.

What format are they?  Some standard test output format?

Sorry I checked the wrong logs, they are in .txt format and I think they use junit.
cat TEST-org.apache.tomcat.websocket.TestWsSession.NIO.txt
Testsuite: org.apache.tomcat.websocket.TestWsSession
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.073 sec
Testcase: testAppendCloseReasonWithTruncation01 took 0.016 sec
Testcase: testAppendCloseReasonWithTruncation02 took 0 sec
Testcase: testAppendCloseReasonWithTruncation03 took 0.001 sec
Testcase: testAppendCloseReasonWithTruncation04 took 0.001 sec
Testcase: testAppendCloseReasonWithTruncation05 took 0 sec
Testcase: testAppendCloseReasonWithTruncation06 took 0.001 sec
Testcase: testAppendCloseReasonWithTruncation07 took 0.001 sec
Testcase: testAppendCloseReasonWithTruncation08 took 0.001 sec
Testcase: testAppendCloseReasonWithTruncation09 took 0.001 sec

hi @chandrams - would you be able to update this PR to resolve conflicts?  Then we can verify in a Grinder.  Thanks!

Thanks Shelley @smlambert, I have resolved the conflicts.

May I request a review from you @sophia-guo as you have been working on external tests recently?

@chandrams - when you get a chance, please update with @sophia-guo 's suggestions.  Thanks!

@sophia-guo - ready for another review

Thanks @chandrams


Document that this module is not multi process safe.

I had a bad day because I didn't know this.
Pull Request check-list
Please make sure to review and check all of these items:

[ ] Does $ python setup.py test pass with this change (including linting)?
[ ] Does travis tests pass with this change (enable it first in your forked repo and wait for the travis build to finish)?
[ ] Is the new or changed code fully tested?
[ ] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.
Description of change
Please provide a description of the change here.

What version of redis-py are you using? 3.2.0+ should be multi-process safe.

Ah, nope. I am on 2.10.5. I will update and check again. Thank you!

It seems better in 3.2.1. Thanks.


Blacken-docs removes lines at beginning and end of codeblocks, thereby destroying the rst

Python Version
3.10
Package Version
1.13
Description

Probably when the first line is a comment.

No, it happens when the empty line between the code-block and your actual code contains the same amount of spaces as the rest of the code.
In theory, this is allowed by rst. Therefore I think Blacken-docs should handle this.

Thanks for digging into your report, I found a fix in #271.


Parse phone number from a single string

How can I parse and check if is valid the phone number object given a String such as "+380955555555" in Java?

@Ornolfr
You can use our demo to check whether the giben phone number is valid or not.
Please find the  example of the number you provided  which is validated by our [demo]
(http://libphonenumber.appspot.com/phonenumberparser?number=%2B380955555555)

@padmaksha
Thanks for your answer.
I know how to create a phoneNumber object having 2 strings which contain code and number separately.
PhoneNumber phoneNumber = new PhoneNumber().setCountryCode(Integer.valueOf(code)
                .setNationalNumber(Long.valueOf(number));

As I cannot know what substring should I get from a single string, what am I looking for is to create this object from it. Could you include some code into your answer?

From our front page:
String swissNumberStr = "044 668 18 00";
PhoneNumberUtil phoneUtil = PhoneNumberUtil.getInstance();
try {
PhoneNumber swissNumberProto = phoneUtil.parse(swissNumberStr, "CH");
} catch (NumberParseException e) {
System.err.println("NumberParseException was thrown: " + e.toString());
}
In your example, you can replace "swissNumberStr" with your actual string, and you can safely use "ZZ" as the region code if the number always starts with a plus sign, since we can then work out the country.
I'll close this as it's not an issue with the library. Please consider joining
the discussion group if you'd
like to discuss this further.


Support xlsm file type

In its current state openpyxl-templates doesn't support xlsm files.
It's able to correctly open a xlsm file, replace its content but when saving all the VBA macro are lost.
If the file has still the xlsm extension, then Excel will fail to open it.
When the file is renamed to .xslx, Excel can open it but the macro are missing.
A solution is to use the keep_vba=True parameters in the load_workbook method.
Then when saving the file all VBA macros will be added back and it will correctly open in Excel.

I've added the keep_vba argument to the TemplatedWorkbook constuctor and passed it to the underlying workbook. Could you verify that it is working properly before I push to pypi? Prefferably as tests.

Hi @SverkerSbrg , Is this fix working as expected, have you found any issues so far ? Thanks !


Add support for Publisher Common ID Module in Sharethrough bid adapter docs

Related feature PR here
<EMAIL_ADDRESS>

hi @bretg just wanted to check in on this PR now that the related change has been merged into prebid.js repo and released (https://github.com/prebid/Prebid.js/releases/tag/4.14.0, https://github.com/prebid/Prebid.js/pull/5871). thanks!

Thanks for the reminder.


Investigate if the volatile usages are correct

https://www.reddit.com/r/embedded/comments/lqfdvl/yet_another_c_volatile_question/

Looks good: https://godbolt.org/z/48Y8Mr


Upgrade to rustc 1.0.0-nightly (fed12499e 2015-03-03) (built 2015-03-04)

There is one failure left in cargo test because of rust-lang/rand#21

r? @huonw
(rust_highfive has picked a reviewer for you, use r? to override)

I personally like this approach, thanks!


[FEATURE] Turn manuals into books with mdbook

It would be nice to turn Apalache manual, Idiomatic TLA+ and Language manual into books by running mdbook

There are lots of options for generating documentation from markdown.  Should we perhaps survey what's available and what features they offer before picking one?
E.g., (just the first answers in a google search):

https://www.mkdocs.org/
https://docsify.js.org/#/
https://docusaurus.io/
https://dotnet.github.io/docfx/

There are lots of options for generating documentation from markdown.  Should we perhaps survey what's available and what features they offer before picking one?
E.g., (just the first answers in a google search):

https://www.mkdocs.org/
https://docsify.js.org/#/
https://docusaurus.io/
https://dotnet.github.io/docfx/

Nevermind my last comment. MD book looks good.

Nevermind my last comment. MD book looks good.