which command missing in Windows

Describe the bug
which command is missing on Windows.
To Reproduce
mix igniter.new helpdesk --install ash,ash_postgres --with phx.new --extend postgres --example
* creating helpdesk/lib/helpdesk/application.ex
* creating helpdesk/lib/helpdesk.ex
* creating helpdesk/lib/helpdesk_web/controllers/error_json.ex
* creating helpdesk/lib/helpdesk_web/router.ex
* creating helpdesk/lib/helpdesk_web/telemetry.ex
* creating helpdesk/lib/helpdesk_web.ex
* creating helpdesk/mix.exs
* creating helpdesk/README.md
* creating helpdesk/.formatter.exs
* creating helpdesk/.gitignore
* creating helpdesk/test/support/conn_case.ex
* creating helpdesk/test/test_helper.exs
* creating helpdesk/test/helpdesk_web/controllers/error_json_test.exs
* creating helpdesk/lib/helpdesk/repo.ex
* creating helpdesk/priv/repo/migrations/.formatter.exs
* creating helpdesk/priv/repo/seeds.exs
* creating helpdesk/test/support/data_case.ex
* creating helpdesk/lib/helpdesk_web/controllers/error_html.ex
* creating helpdesk/test/helpdesk_web/controllers/error_html_test.exs
* creating helpdesk/lib/helpdesk_web/components/core_components.ex
* creating helpdesk/lib/helpdesk_web/controllers/page_controller.ex
* creating helpdesk/lib/helpdesk_web/controllers/page_html.ex
* creating helpdesk/lib/helpdesk_web/controllers/page_html/home.html.heex
* creating helpdesk/test/helpdesk_web/controllers/page_controller_test.exs
* creating helpdesk/lib/helpdesk_web/components/layouts/root.html.heex
* creating helpdesk/lib/helpdesk_web/components/layouts/app.html.heex
* creating helpdesk/lib/helpdesk_web/components/layouts.ex
* creating helpdesk/priv/static/images/logo.svg
* creating helpdesk/lib/helpdesk/mailer.ex
* creating helpdesk/lib/helpdesk_web/gettext.ex
* creating helpdesk/priv/gettext/en/LC_MESSAGES/errors.po
* creating helpdesk/priv/gettext/errors.pot
* creating helpdesk/priv/static/robots.txt
* creating helpdesk/priv/static/favicon.ico
* creating helpdesk/assets/js/app.js
* creating helpdesk/assets/vendor/topbar.js
* creating helpdesk/assets/css/app.css
* creating helpdesk/assets/tailwind.config.js

Fetch and install dependencies? [Yn]
* running mix deps.get
* running mix assets.setup
* running mix deps.compile

We are almost there! The following steps are missing:

    $ cd helpdesk
Then configure your database in config/dev.exs and run:

    $ mix ecto.create

Start your Phoenix app with:

    $ mix phx.server

    $ iex -S mix phx.server

==> phoenix_live_view
Compiling 39 files (.ex)
Generated phoenix_live_view app
===> Analyzing applications...
===> Compiling telemetry
===> Compiling telemetry_poller
==> helpdesk
Compiling 15 files (.ex)
warning: defining a Gettext backend by calling

    use Gettext, otp_app: ...

is deprecated. To define a backend, call:

    use Gettext.Backend, otp_app: :my_app

Then, instead of importing your backend, call this in your module:

    use Gettext, backend: MyApp.Gettext

  lib/helpdesk_web/gettext.ex:23: HelpdeskWeb.Gettext (module)

Generated helpdesk app
** (ErlangError) Erlang error: :enoent
    (elixir 1.17.3) lib/system.ex:1114: System.cmd("which", ["git"], [])
    (igniter 0.3.57) lib/igniter.ex:904: Igniter.prompt_on_git_changes/2
    (igniter 0.3.57) lib/igniter.ex:627: Igniter.apply_and_fetch_dependencies/2
    (igniter 0.3.57) lib/igniter/util/info.ex:46: Igniter.Util.Info.compose_install_and_validate!/6
    (igniter 0.3.57) lib/igniter/util/install.ex:77: Igniter.Util.Install.install/4
    (mix 1.17.3) lib/mix/task.ex:495: anonymous fn/3 in Mix.Task.run_task/5
    lib/mix/tasks/igniter.new.ex:178: Mix.Tasks.Igniter.New.run/1
    (mix 1.17.3) lib/mix/task.ex:495: anonymous fn/3 in Mix.Task.run_task/5

Expected behavior
Use where on Windows or documentation to install which with scoop install which.
** Runtime

Elixir version 1.17.3
Erlang version 27.1
OS Windows 10
Igniter version 0.4.2

Whoops! Thank you for pointing this out. It is fixed in 0.3.58


Linux build not always rebuilding

While debugging a plugin issue using a local engine, I was getting runs with stale binaries, for both engine changes and plugin changes. Nuking the build gave correct results. Apparently something is wrong with the new CMake build.

It turns out this was a misunderstanding on my part about how BundleUtilities works. The build artifacts were correct, but not being recopied into the bundle that's run.


Fix navbar alignment on mobile view

CSS and Font Awesome Inclusion: Verified CSS links and added a link for Font Awesome.
Accessibility: Added role="dialog" and aria-hidden attributes to the modal for better accessibility.
Semantic HTML and Consistency: Ensured consistency in the way JavaScript functions and variables are declared.
Improved Modal Behavior: Adjusted the modal display logic to reflect its visibility accurately.
Flexbox for Horizontal Scrolling: The .testimonials-container class uses display: flex with overflow-x: auto to allow horizontal scrolling of the testimonial cards.
Star Rating: The .star-rating class aligns stars in a row and colors them gold.
Scroll Snap: The scroll-snap-type and scroll-snap-align properties create a snapping effect when scrolling through the testimonials.
Responsive and Visually Appealing: Adjustments such as padding and margins enhance the visual appeal while maintaining responsiveness.
Screenshots
If applicable, please attach screenshots of the changes made to the user interface.

Additional Information
Please provide any other information that is relevant to this pull request.

Issue number

#668

you cant work on other peoples issue


MAINT: interpolate: Declare type for a Cython indexing variable.

Fixes the build warning:
warning: _bspl.pyx:449:36: Index should be typed for more efficient access

Thanks Warren.


Hubspot Email rendering issues

Hi,
When sending the email from Hubspot it seems to show the mobile / responsive stacked layout even though the width is set to 600px in HubSpot and the email has a width of 600px. Does anyone know anything about this? I've tested the outputted HTML template in litmus and I don't get any issues.
any help is much appreciated.
Thanks Jake.

Hey @JakeHenshall, thanks for opening this issue. It would really help to have more information as detailed in contributing.md. Can you please at least provide:

MJML used
MJML version used
In which email clients you're seeing the mobile layout

Also, have you tried to compare the HTML outputted by MJML and the HTML sent by HubSpot to see if they might mess with the HTML before sending it?

@ngarnier Thanks for the reply.
MJML - Latest Version
In which email clients you're seeing the mobile layout - Gmail - Browser Version on Chrome is what we are seeing the problem in. Everything else looks brilliant
Now if you remove/comment out the code below this is what makes it go from the 2 column grid to the stacked layout. Do you know if there maybe a fix to this, also is they a way to make it non-responsive for testing purposes?
<style type="text/css">
    @media only screen and (min-width:601px) {
        .mj-column-px-600, * [aria-labelledby="mj-column-px-600"] { width:600px!important; }
        .mj-column-px-300, * [aria-labelledby="mj-column-px-300"] { width:300px!important; }
    }
</style>

Thanks Jake.

Hi @JakeHenshall you can just remove the media query or resize your browser to have the "stacked version" of your email.

My issue seems to be the same as #24 as we are using Gmail for Work, has there been a work around for this?
But for me the email is stacked on my Work Email and also Personal Gmail, but when I look at it in my email app called Newton they are both displaying fine, but are not responsive?

I think your issue is different,  gmail & g-suite do support media queries now so it won't happens anymore.
Where did you copy the media query from ? it should be min-width: 480px and not 601px

Hi @JakeHenshall any update on this ?

I'm closing this for now, feel free to reopen !

I came across a similar problem with columns not being respected in Hubspot - they were pushing my media queries way down and modifying my HTML.
Discovered the following piece of documentation with resolved the issue for me: http://designers.hubspot.com/docs/cos/email-template-markup
My final recommendation is to take your HTML output and upload as a coded file in HubSpot, instead of trying to insert it in a Custom HTML module - this resolved all isues and stopped HubSpot from modifying the media queries and injecting their ASCII art...


Provision fails if memcached is not to be installed.

If memcached is not to be installed, provisioning fail with the following error message:
TASK: [geerlingguy.memcached | Install Memcached.] ****************************
fatal: [drupaldev] => Failed to template {% if "memcached" in installed_extras %} True {% else %} False {% endif %}: an unexpected type error occurred. Error was argument of type 'NoneType' is not iterable

FATAL: all hosts have already failed -- aborting

@pbuyle - Is you're installed_extras variable empty/blank? If you need to remove all the extras, you need to set the variable to:
installed_extras: []

Otherwise, if you set it to something like '', then Ansible won't see it as an array, and since the memcached role is the first to use the conditional, Ansible will bail out when it hits that step in the playbook.


Show local/docker storage pools in UI

Necessary to allow users to see/delete their volumes.

https://github.com/rancher/rancher/issues/2793


bgtest targets should fail when run on non-bigsim builds

Original issue: https://charm.cs.illinois.edu/redmine/issues/429

Many pieces of code run by make bgtest will work incorrectly in inscrutable ways if run on a build of the runtime without emulation support enabled. They should fail noisily in that case, not behave erratically.

Original date: 2015-01-27 21:11:38

I've looked at a few different ways to determine if we're in a BigSim build, or not.  Various library symbol tests are possible, but the cross platform portability of tools like nm is somewhat questionable.
One approach would be to add CmiArg processing to abort when BigSim arguments are passed to a non-BigSim build.
Downside: this is an ugly solution in that it is definitely weird to add arguments which result in an abort whenever they are present.  It also prevents us from using those arguments for some non-BigSim purpose, or being compatible with something else in the toolchain which would desire to do so.  It has the advantage of being relatively simple to implement.
An alternate avenue is a Make based test of execution testing for the BG> BigSim emulator shutdown gracefully! message that the simulator throws on stderr.  As shown below.  This approach has pretty light platform requirements (shell support, pipe composition, stream redirection and grep) that I believe are already in the requirements necessary to build charm.  It correctly fails in a non-bigsim build. It will also fail if bigsim would fail to get far enough to output its termination line, which is correct.
Downsides: One annoying downside of this approach is that it adds the execution time of however long the test would take without arguments.  This is quite variable, as some tests will abort without arguments, while others will soldier on with minimally functional defaults.  It also requires a change to all of the individual test makefiles, though the nm solution would have the same issue.

isBigSimTest:
	if ! ./charmrun ./pgm 2>&1 | grep '^BG> BigSim' 2>&1 > /dev/null; then  echo "bgtest invalid, not a BigSim build"; exit 2; fi
BG> BigSim emulator shutdown gracefully!

bgtest: isBigSimTest all

Original date: 2015-02-09 19:56:21

This is one example for the class of bugs in 654

Original date: 2015-02-10 17:38:53

This bug was resolved by the fix for bug 654. Now there will be warnings printed out when attempting to use big sim params in a non-bigsim build.


Add HOTKEY functionality and add support in MOS VDU command for semicolon (long) values.

This PR seeks to add the ability to assign a command string to keys F1 to F12. It hooks in to mos_EDITLINE and therefore supports anything that calls on that function for input handling including both MOS itself and BBC BASIC.
Welcome thoughts on the implementation. This works well but relies on creating thirteen more 256 byte-wide strings to store first a preserved, untokenised command line, and then twelve more for each potential hotkey command. That's 3.3K of RAM on top of the 4K we already reserve for command line history. Perhaps that's fine with 512KB to spare, but it seems wasteful. I considered mallocing each buffer as it's used but it's challenging to determine where you'd free them.
It also makes a tweak to the MOS internal VDU command to bring it in line with BASIC notation (; meaning to treat the preceding as a 16-bit value).

How was it implemented in the old BBC micro? Back in the day we certainly did not flat out allocate 10 maximum length buffers for each of the function key definitions we might have.

Good question, not sure. There's really only two camps though - you hold the space or your dynamically allocate it and make sure to free it. I'm sure we could achieve the latter with some fresh eyes.

on the Beeb this was *key <num> <value>
This is described in chapter 25 of the BBC Micro user guide.  The RISC OS command documentation is here: https://www.riscosopen.org/wiki/documentation/show/*Key
Further descriptions of how function keys can be set on RISC OS can be found on this page (search for *Key):
http://www.riscos.com/support/developers/prm/charinput.html
As you'll see from the RISC OS docs, you could also on that platform define keys using for instance *Set Key$7 Hello to set key f7 to insert "Hello" into the input buffer.  *unset key$7 would clear f7, and *unset key$* would clear all the function keys.  they also supported *SetMacro Key$n expression which does something more sophisticated, passing the expression thru the OS_GSTrans OS function - altho I don't think I ever used that.
Control characters could be inserted into the string value by using the pipe character, so |M for instance is equivalent to pressing the return key.
I must admit I've not yet looked properly at this implementation :grin:
my inclination would be to try to follow the Beeb first (i.e. supporting *key n), and RISC OS second (*set key$n and *unset, and probably ignore *setmacro).  Acorn's use of the pipe character could be considered to be a bit odd/idiosyncratic - I might consider changing to use \, but that may also not work quite as expected

Ok, I've:

Switched to dynamic allocation and freeing to save 3K of RAM out of the box.
Added unsetting of hotkeys by specifying only the hotkey number.
Changed to KEY rather than HOTKEY to align with the Beeb.


Revert Rails command change

Rails <= 5.2 dont have this options, the users cannot use this feature without searching in the doc.  I think is better to leave enabled.
If possible, make something to limit the projectile-rails-server-mode @hlissner .  Like, if has more then 1.5k lines, when create new logs, erase the old ones.

If possible, make something to limit the projectile-rails-server-mode

Please request this upstream. I will remove this option once we have a solution in place. I'm currently swamped with other tasks so it'll be a while until I can look at it.

https://github.com/asok/projectile-rails/issues/148

With the suggestion posted upstream we now have a viable solution to this issue and this PR can be merged. Thanks for bringing this to my attention!


Ollama not recognised as a provider using lazyvim opts.

Adding ollama to the config as mentioned in the wiki local-llms results in an error: Failed to load provider: ollama
    {
        "yetone/avante.nvim",
        event = "VeryLazy",
        dependencies = {
            "nvim-tree/nvim-web-devicons", -- or echasnovski/mini.icons
            "stevearc/dressing.nvim",
            "nvim-lua/plenary.nvim",
            "MunifTanjim/nui.nvim",

            --- The below is optional, make sure to setup it properly if you have lazy=true
            {
                'MeanderingProgrammer/render-markdown.nvim',
                opts = {
                    file_types = { "markdown", "Avante" },
                },
                ft = { "markdown", "Avante" },
            },
        },
        opts = {
            provider = "ollama",
            ollama = {
                ["local"] = true,
                endpoint = "<IP_ADDRESS>:11434/v1",
                -- model = "codegemma",
                model = "llama3.1:latest",
                parse_curl_args = function(opts, code_opts)
                    return {
                        url = opts.endpoint .. "/chat/completions",
                        headers = {
                            ["Accept"] = "application/json",
                            ["Content-Type"] = "application/json",
                        },
                        body = {
                            model = opts.model,
                            messages = require("avante.providers").copilot.parse_message(code_opts), -- you can make your own message, but this is very advanced
                            max_tokens = 2048,
                            stream = true,
                        },
                    }
                end,
                parse_response_data = function(data_stream, event_state, opts)
                    require("avante.providers").openai.parse_response(data_stream, event_state, opts)
                end,
            },
        }
    }

Error executing Lua callback: ...im-custom/lazy/avante.nvim/lua/avante/providers/init.lua:263: Failed to load provider: ollama
stack traceback:
        [C]: in function 'error'
        ...im-custom/lazy/avante.nvim/lua/avante/providers/init.lua:263: in function '__index'
        ...im-custom/lazy/avante.nvim/lua/avante/providers/init.lua:313: in function 'refresh'
        ...im-custom/lazy/avante.nvim/lua/avante/providers/init.lua:324: in function <...im-custom/lazy/avante.nvim/lua/avante/providers/init.lua:322>

Starting with claude as default provider works perfectly, however switching the provider also results in an error
The error is also produced when i want to switch provider via AvanteSwitchProvider ollama

Sorry, our wiki has errors. ollama part should be inside opts.vendors:
opts = {
	vendors = {
		ollama = {...},
	},
},

For anyone that finds this, the following worked for me (In this example vale is a server on my network):

RyanGreenup/dotfiles/5d9afc1

To add different models as separate providers:

RyanGreenup/dotfiles/977f762


Debug print

Cjkcms generates unnecessary prints in project
Version 23.10.6

Resolved in v. 23.12.1


Provide an API to force access to the host

Before this change, one of the biggest limitations of host port exposing
was that the ports had to be exposed before the container starts.
This change allows forcing starting the forwarding container,
so that host listeners can be started/exposed after starting the consumer.

@kiview added a mention to the docs 👍


use cp-kafka.fullname in the headless service name

What changes were proposed in this pull request?
In order to have control over the non-headless kafka service name, I'm changing the "cp-kafka.fullnameOverride", however the kafka pods fail to get into running state because the "cp-kafka-headless.fullname" doesn't follow the "cp-kafka.fullnameOverride" value.
The proposed changes uses the "cp-kafka.fullname" as part of the "cp-kafka-headless.fullname".
Note that the behavior is still the same as before when the "fullnameOverride" is not set because "cp-kafka.fullname" comes out of "printf "%s-%s" .Release.Name $name".
How was this patch tested?
The changes were tested using "helm install/uninstall ..." in a real k8s cluster.

[clabot:check]

@confluentinc It looks like @hugokiehl just signed our Contributor License Agreement. :+1:
Always at your service,
clabot

Closing in order to reopen the PR to kick Jenkins jobs


Partially fixes #10838

The following warnings seem to print for compiling many ops using gcc-4.9.
For example, in cuda_solvers_gpu.cu.cc:
INFO: From Compiling tensorflow/core/kernels/cuda_solvers_gpu.cu.cc:
./tensorflow/core/framework/op_kernel.h(313): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/kernel.h(307): warning: variable "result" is used before its value is set

./tensorflow/stream_executor/device_description.h(85): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/device_description.h(144): warning: type qualifier on return type is meaningless

./tensorflow/core/framework/op_kernel.h(313): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/kernel.h(307): warning: variable "result" is used before its value is set

./tensorflow/stream_executor/device_description.h(85): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/device_description.h(144): warning: type qualifier on return type is meaningless

In beam_search_ops_gpu.cu.cc:
INFO: From Compiling tensorflow/contrib/seq2seq/kernels/beam_search_ops_gpu.cu.cc:
./tensorflow/core/framework/op_kernel.h(313): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/kernel.h(307): warning: variable "result" is used before its value is set

./tensorflow/stream_executor/device_description.h(85): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/device_description.h(144): warning: type qualifier on return type is meaningless

./tensorflow/core/framework/op_kernel.h(313): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/kernel.h(307): warning: variable "result" is used before its value is set

./tensorflow/stream_executor/device_description.h(85): warning: type qualifier on return type is meaningless

./tensorflow/stream_executor/device_description.h(144): warning: type qualifier on return type is meaningless

I believe this fix will address many (but not all) of the warnings during the build.

Can one of the admins verify this patch?

Jenkins, test this please


Default config incorrect?

The example config includes the following resolve config
        'resolver' => [
            'class' => DefaultResolver::class,
            'settings' => [],
        ],

Which causes an error to be thrown. Removing the resolver seems to solve the error.

Namespace?

fixed in Dare 39aecd499ae651daabddf5ad94a2c73d9a8aba2b


Error on import with numpy HEAD

Reporting a bug

[x] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
[ ] I have included a self contained code sample to reproduce the problem.
i.e. it's possible to run as 'python bug.py'.

This will be a somewhat sparse bug report, but putting here early in case anyone recognizes this. We can do more work to replicate the environment if not.
In our upstream tests, xarray tests nightly against unreleased versions of our dependencies to get ahead of any incompatible code. Occasionally it also catches bugs in upstream libraries.
Here, we're getting an error importing some items from numba.np.ufunc, including the somewhat confusing SystemError: initialization of _internal failed without raising an exception at the bottom of the stack trace.
https://github.com/pydata/xarray/issues/7306
Any ideas on what might be causing this?
Thanks in advance!

Thanks for the report @max-sixty. Do you know what version of Python, Numba and NumPy (and where from, e.g. conda-forge or pip or ...) were present when this a) failed and b) was last successful?
I think:
SystemError: initialization of _internal failed without raising an exception

is saying that the module failed to initialize as it returned an error code, but there was no exception raised to go with the failure result (e.g. function PyInit_<module name> returned NULL but an exception wasn't set).

Thanks for the swift response @stuartarchibald !

Do you know what version of Python, Numba and NumPy (and where from, e.g. conda-forge or pip or ...) were present when this a) failed and b) was last successful?

Here's the full version info: https://github.com/pydata/xarray/actions/runs/3519182359/jobs/5906608476#step:8:74
Actually it seems we don't install the upstream version of numba, so this was running on 0.56.4          py310ha5257ce_0. FYI the script we use to install dependencies is at https://github.com/pydata/xarray/blob/main/ci/install-upstream-wheels.sh.
This is the first day it's failed with this error, so it is likely to be a change somewhere in the past day.
Though I realize "somewhere" isn't that helpful, and it now seems that it may not be a numba-specific error given that hasn't changed. Do you possibly have any similar tests which run on the latest branch of numpy etc? If those pass, then this is more likely to be something specific to xarray / numbagg, even though that didn't look likely at first glance.

is saying that the module failed to initialize as it returned an error code, but there was no exception raised to go with the failure result (e.g. function PyInit_<module name> returned NULL but an exception wasn't set).

Ah great, that makes much more sense.

This is the first day it's failed with this error, so it is likely to be a change somewhere in the past day.

That's not quite true, it started failing 4 days ago but there was a bug in our CI which caused that to go unnoticed. Probably doesn't change too much, though.

Thanks for the swift response @stuartarchibald !

No problem!

Do you know what version of Python, Numba and NumPy (and where from, e.g. conda-forge or pip or ...) were present when this a) failed and b) was last successful?

Here's the full version info: https://github.com/pydata/xarray/actions/runs/3519182359/jobs/5906608476#step:8:74
Actually it seems we don't install the upstream version of numba, so this was running on 0.56.4 py310ha5257ce_0. FYI the script we use to install dependencies is at https://github.com/pydata/xarray/blob/main/ci/install-upstream-wheels.sh.
This is the first day it's failed with this error, so it is likely to be a change somewhere in the past day.
Though I realize "somewhere" isn't that helpful, and it now seems that it may not be a numba-specific error given that hasn't changed. Do you possibly have any similar tests which run on the latest branch of numpy etc? If those pass, then this is more likely to be something specific to xarray / numbagg, even though that didn't look likely at first glance.

Thanks for this information. Numba doesn't automatically test against NumPy latest/mainline, but it does test NumPy alphas/pre-releases and provides feedback for these. Once a NumPy package becomes more generally available across a number of distribution mechanisms, support for that release of NumPy is added to Numba. As a result, released versions of Numba have explicit version constraints with respect to packages such as NumPy. As it's quite common for updates to e.g. NumPy to break something in Numba, Numba tries really hard to provide predicable failure modes (e.g. won't install or RuntimeError for unsupported NumPy being found).
Do you think it'd be possible to diff the logs between last working and now? That might hint at the problem?

is saying that the module failed to initialize as it returned an error code, but there was no exception raised to go with the failure result (e.g. function PyInit_<module name> returned NULL but an exception wasn't set).

Ah great, that makes much more sense.

Great, glad that's clearer, it's quite a "low level" problem.

Thanks for checking @keewis. I'm going to make some guesses based on Numba internals... I think the following:

That the issue is unlikely to be glibc, Python or Python C-API related as to get to the point of importing numba.np.ufunc._internal Numba would have had to have imported other C extension modules that would have similar glibc linkage and C-API use and these evidently worked "OK" as errors were not raised.
That whilst Numba guards against using unsupported NumPy versions, current NumPy nightlies are likely to be reporting that they are 1.23 series builds as IIRC 1.24 hasn't been tagged, so Numba is effectively using something that hasn't been tested.
Following some discussion at the weekly triage meeting, @gmarkall noted that there's some potential for susceptibility against changes in NumPy ufunc definitions in the init_ufunc_dispatch function in _internal.c. NumPy has recently merged a change to help with #8538 which may well be the cause of the problem if 2. is also correct.

Numba relies on NumPy infrastructure for e.g. ufunc creation, and so there is a very tight coupling in this respect, between Numba and NumPy (the code is all in C and uses Python/NumPy C-API).
To debug and potentially fix the issue reported, maybe first try installing a supported released version of NumPy? If that fixes it, it narrows the problem down to what is suspected in the above.
Hope this helps.

To debug and potentially fix the issue reported, maybe first try installing a supported released version of NumPy? If that fixes it, it narrows the problem down to what is suspected in the above.

Our tests are still very much passing on the newest released versions of libraries; so this is only an issue with the versions from HEADs. I just tried installing numpy from main — I get the same failure with numba 0.56.3 but it works with numba 0.56.4. I notice that's consistent with the declared dependencies of numba, so it seems numba is doing everything it should be...
Possibly over at xarray, we should at least ensure we're on the latest numba for this test. I did a PR to do that earlier: https://github.com/pydata/xarray/pull/7311#pullrequestreview-1190125481. Let us know if there's some pre-compiled version of dependencies (https://github.com/pydata/xarray/pull/7311#discussion_r1029378003), otherwise we'll just use pip.
Feel free to close, thanks for your attention @stuartarchibald !

I think you're right, I can reproduce locally with the most recent nightly numpy version:
# works
pip install --no-deps -i https://pypi.anaconda.org/scipy-wheels-nightly/simple --pre "numpy==1.24.0.dev0+1068.g6aacc5167"
# fails
pip install --no-deps -i https://pypi.anaconda.org/scipy-wheels-nightly/simple --pre "numpy==1.24.0.dev0+1120.gf30af6acd"

where the new version was uploaded ~6 days ago.

for me numba=0.56.4 from conda-forge fails locally with numpy=1.24.0.dev0+1120.gf30af6acd, so not sure what I'm doing wrong? @max-sixty, was that with the numba head?

Redoing the test; I also get a failure with:

both that nightly wheel command, and pip install . on numpy''s HEAD
both numba 0.56.3 and 0.56.4

So I think my prior success with 0.56.4 must have been a mistake (I notice that pip reinstalls a lower version of numpy when installing a new version of numba, so that may have been it, mea culpa)
...so I'm not sure what we should do from Xarray's POV — I guess we can try running tests without numba? But that misses some of the utility of these upstream tests.

I would anticipate that any issue, of the nature as described above, that is in 0.56.3 would also be in 0.56.4. The changes are here:
https://github.com/numba/numba/blob/3e96339a523b3cf4b737b8fff7dba6ee64927584/CHANGE_LOG#L1-L14
but in summary, it involved adding a couple of lines to fix a regression in <array>.view()-like capabilities on the CUDA hardware target. Something that should not in any way impact the issue above as it's all in JIT code generation and specifically for CUDA users.

The following quick-n-dirty patch gets around the SystemError with NumPy main:
diff --git a/numba/np/ufunc/_internal.c b/numba/np/ufunc/_internal.c
index 98a643788..c83b4f403 100644
--- a/numba/np/ufunc/_internal.c
+++ b/numba/np/ufunc/_internal.c
@@ -326,10 +326,13 @@ init_ufunc_dispatch(int *numpy_uses_fastcall)
             } else if (strncmp(crnt_name, "reduceat", 9) == 0) {
                 ufunc_dispatch.ufunc_reduceat =
                     (PyCFunctionWithKeywords)crnt->ml_meth;
+            } else if (strncmp(crnt_name, "resolve_dtypes", 15) == 0) {
             } else {
                 result = -1;
             }
             break;
+        case '_':
+            break;
         default:
             result = -1; /* Unknown method */
         }

However, I have not tried much beyond that yet!

The following is also needed because the deprecated MachAr is now removed:
diff --git a/numba/np/arraymath.py b/numba/np/arraymath.py
index 7f53c6563..12edd8e38 100644
--- a/numba/np/arraymath.py
+++ b/numba/np/arraymath.py
@@ -3994,7 +3994,7 @@ def _gen_np_machar():
         return impl

-_gen_np_machar()
+# _gen_np_machar()

 def generate_xinfo(np_func, container, attr):

with this I'm able to start running the test suite - as things pass by, everything appears OK so far, but will update here if the test run completes.

I had to cancel my test run as I was working on other things, but it looked like things were generally working with those small changes: https://github.com/gmarkall/numba/tree/np-124 (YMMV, etc!)

Thanks @stuartarchibald — that makes sense. I think we'll explore excluding anything that runs numba in these tests if this crops up again

2. There are simply not the resources (human, packages, or compute) for Numba to track NumPy HEAD.

Totally empathize! FWIW, we've found that the upstream HEAD tests reduce the maintainer burden, since we can solve problems at a slower pace — no need to rush when there's an upstream release that breaks something — and we can provide feedback on breakages where there's a mistaken breaking change. But numba is a more technically complex project than Xarray, so possibly the learning is not transferable.

Thanks @stuartarchibald — that makes sense. I think we'll explore excluding anything that runs numba in these tests if this crops up again

@max-sixty no problem, glad it was helpful.

There are simply not the resources (human, packages, or compute) for Numba to track NumPy HEAD.

Totally empathize! FWIW, we've found that the upstream HEAD tests reduce the maintainer burden, since we can solve problems at a slower pace — no need to rush when there's an upstream release that breaks something — and we can provide feedback on breakages where there's a mistaken breaking change. But numba is a more technically complex project than Xarray, so possibly the learning is not transferable.

Thanks for sharing this. I can see that for some projects, aspects of the described approach would certainly be beneficial in terms of maintenance burden.
The Numba maintainers do track changes to dependencies and work with other projects if issues are anticipated, they also often "try out" the code base against newer versions of projects that impact Numba (cPython, LLVM, NumPy) etc to assess the level of effort needed to do the necessary updates. I think the learning from the Numba side is probably, that in developing a compiler, having a stable and predictable environment in which to develop makes it easier to isolate problems. This is in part due to problems often being very niche e.g. one single Python+NumPy+OS+CPU combination might exhibit a particular issue!

Just a heads up that I think I'm hitting this error in CIs now that NumPy 1.24 has been released:
https://github.com/mne-tools/mne-python/actions/runs/3732610574/jobs/6332287508#step:9:56
I expect others might hit it soon, too.

I expect others might hit it soon, too.

Yup, same story in pandas https://github.com/pandas-dev/pandas/actions/runs/3737292562/jobs/6342364883
________________________ ERROR collecting test session _________________________
../../../micromamba/envs/test/lib/python3.8/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1014: in _gcd_import
    ???
<frozen importlib._bootstrap>:991: in _find_and_load
    ???
<frozen importlib._bootstrap>:975: in _find_and_load_unlocked
    ???
<frozen importlib._bootstrap>:671: in _load_unlocked
    ???
../../../micromamba/envs/test/lib/python3.8/site-packages/_pytest/assertion/rewrite.py:168: in exec_module
    exec(co, module.__dict__)
pandas/tests/window/conftest.py:93: in <module>
    @pytest.fixture(params=[pytest.param("numba", marks=td.skip_if_no("numba")), "cython"])
pandas/util/_test_decorators.py:192: in skip_if_no
    not safe_import(package, min_version=min_version), reason=msg
pandas/util/_test_decorators.py:95: in safe_import
    mod = __import__(mod_name)
../../../micromamba/envs/test/lib/python3.8/site-packages/numba/__init__.py:43: in <module>
    from numba.np.ufunc import (vectorize, guvectorize, threading_layer,
../../../micromamba/envs/test/lib/python3.8/site-packages/numba/np/ufunc/__init__.py:3: in <module>
    from numba.np.ufunc.decorators import Vectorize, GUVectorize, vectorize, guvectorize
../../../micromamba/envs/test/lib/python3.8/site-packages/numba/np/ufunc/decorators.py:3: in <module>
    from numba.np.ufunc import _internal
E   SystemError: initialization of _internal failed without raising an exception

Looks like I forgot to mention in this issue, the PR / branch for NumPy 1.24 support is https://github.com/numba/numba/pull/8620

Having the same issue over here with an old numpy version 😕 rolling back to an old version dindt work for me

I was having the same problem with the librosa library (The reason was that librosa working with different versions of scipy and matplotlib), so I uninstalled numpy, matplotlib, and scipy, installed librosa first which installed its own compatible versions of libraries above and then I installed the necessary libraries. That seems to work for me.

Thank you all for your comments/feedback on this issue. This issue seems to have diverged a little from the originally reported problem and so I'm closing this issue as resolved with some specific follow up issues to subscribe to if they are important to you:

With respect to the originally posted issue, this comment https://github.com/numba/numba/issues/8615#issuecomment-1324810269 (and some discussion immediately after) explains the decisions surrounding Numba not tracking NumPy HEAD.
With respect to the originally posted issue, #8691 is the patch for making Numba compatible with NumPy 1.24.
The NumPy 1.24 related problem that manifests as the error:SystemError: initialization of _internal failed without raising an exception

is tracked in #8718.

what version of numpy should i install?

what version of numpy should i install?

If you're using the last released version of Numba (0.56.4 at time of writing), NumPy 1.18 - 1.23 are supported.

for me numba=0.56.4 from conda-forge fails locally with numpy=1.24.0.dev0+1120.gf30af6acd, so not sure what I'm doing wrong? @max-sixty, was that with the numba head?
Edit: the install would be
pip install -i https://pypi.anaconda.org/scipy-wheels-nightly/simple --pre "numpy==1.24.0.dev0+1120.gf30af6acd" --upgrade

and pip does indeed complain that numba requires numpy<1.24 but installs it anyways (as intended in this case, because we do actually want to test with the most recent version, even if that breaks something). So while point 2 from #8615 (comment) does not apply, point 3 may very well be the cause of the problem.

Thanks. This help a lot. I reinstall numpy by "pip install numpy==1.23.0". Then, the error when "import numba" was solved.

Is it fixed in any version?

Hello everyone, the solutions posted here did not fix the problem for me. I downgraded numpy to v1.23.0 and it did not work with both numpy 1.23.0 and 1.24.0. I installed everything with conda-forge and I am using WSL. Any help is greatly appreciated. Thank you!

Hello everyone, the solutions posted here did not fix the problem for me. I tried numba v0.56.4 and v0.56.3 and both of these versions did not work with either numpy 1.23.0 or 1.24.0. I installed everything with conda-forge and I am using WSL. Any help would be greatly appreciated. Thank you!

I fixed with  conda install cudatoolkit on a cpu only machine


[WIP] Offer some features à la carte

Historically, if you wanted to use only a subset of this repository's functionality, you've had to edit the code to apply your customizations (e.g., removing the require statements for features you don't want). This PR explores one option for providing a more à la carte offering.
It's just an exploration for now. It's too soon to say whether this will be something that's worth merging. 🔮
Approach
The recent 0.9.53 release of Hammerspoon introduced an official mechanism for distributing custom Hammerspoon-based plugins known as Spoons. From the Hammerspoon docs:

Spoons are intended to be pure-Lua plugins for users to use in their Hammerspoon configs. As a community, we have created many great configurations for Hammerspoon, but sharing code between them is hard and fragile. Spoons have been created as a way to address these issues. Users should be able to download a Spoon and quickly integrate it into their config without worrying about what it is doing internally.

If I can extract some of this repository's features into standalone Spoons, and if doing so makes it easier for people to choose the custom subset of features they want, and if it doesn't significantly increase maintenance overhead, then I'd love to make it happen. 🤞
Proof-of-concept
As a starting point, I've extracted a Spoon to provide the functionality that allows you to tap caps lock for escape and hold caps lock for control. Instead of housing that functionality directly in this repository, that functionality is available à la carte as a Spoon (https://github.com/jasonrudolph/ControlEscape.spoon), and this branch includes that Spoon as a submodule. For people that only want that one feature, they have access to it via that standalone Spoon. For people that want all of this repository's features, this branch continues to provide all of the original functionality.
TODO

[ ] Extract features into standalone Spoons:

[x] Access control and escape on the home row
[ ] (S)uper (D)uper Mode
[ ] Window Layout Mode
[ ] Markdown Mode
[ ] Hyper key for quickly launching apps
[ ] Push-to-talk/push-to-mute hotkey

[ ] Update script/setup to symlink all of this repository's Spoons into ~./hammerspoon/Spoons/
[ ] Update README (if needed)
[ ] Release new version with upgrade instructions

I think this is a great idea! Set up an early version of Pust-to-talk here: https://github.com/adamyonk/PushToTalk.spoon

Closing this out for now. I may revisit it at some point in the future.


Location of sensors question

Hi there, your work looks very interesting! I have a question.
I notice there's no transformation lookup on any of the input messages, does it assume that all sensors are located at the base_link?

Hi,
Thanks for your interest in the work. Yes, the package assumed that the
odometries are already transformed.
On Fri, 8 Jul 2022 at 13:24, Oliver Batchelor @.***>
wrote:

Hi there, your work looks very interesting! I have a question.
I notice there's no transformation lookup on any of the input messages,
does it assume that all sensors are located at the base_link?
—
Reply to this email directly, view it on GitHub
https://github.com/MostafaOsman144/moving_horizon_estimation_localization/issues/1,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFN3Y7OJYMRT5X3XLUNPDHLVTAFVVANCNFSM53AVLNLA
.
You are receiving this because you are subscribed to this thread.Message
ID: <MostafaOsman144/moving_horizon_estimation_localization/issues/1@
github.com>

Thanks, that seems relatively easy to configure.
Another question (sorry!) is does the casadi library in the repository have modifications from the public version, it seems relatively easy to install with pip (maybe because originally this used ROS version prior to python3?).
Thanks again,
Oliver

No problem at all.
No, there are no modification in CasADi, it is just included here for
convenience, but you can install it using pip.
On Fri, 8 Jul 2022 at 13:49, Oliver Batchelor @.***>
wrote:

Thanks, that seems relatively easy to configure.
Another question (sorry!) is does the casadi library in the repository
have modifications from the public version, it seems relatively easy to
install with pip (maybe because originally this used ROS version prior to
python3?).
Thanks again,
Oliver
—
Reply to this email directly, view it on GitHub
https://github.com/MostafaOsman144/moving_horizon_estimation_localization/issues/1#issuecomment-1178897437,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFN3Y7KH3SBEIMKA3CBBHOLVTAIVDANCNFSM53AVLNLA
.
You are receiving this because you commented.Message ID:
<MostafaOsman144/moving_horizon_estimation_localization/issues/1/1178897437
@github.com>


Why most javascript function not working?

I try to check a running number function use setInterval and clearInterval, but it not working if I stand on amp "only" mode.
May I now is there any solutions for this?

@NaraTouch JS is not supported on AMP


'Can't set headers after they are sent' error when using Express middleware 'after' request.

import {Middleware, ExpressErrorMiddlewareInterface} from "routing-controllers";

@Middleware({ type: "after" })
export class CustomErrorHandler implements ExpressErrorMiddlewareInterface {

    error(error: any, request: any, response: any, next: (err: any) => any) {
        console.log("do something...");
        next();
    }

}

This example code from the documentation causes a 'Can't set headers after they are sent' error. Changing the type to 'before' fixes the issue.
Error: Can't set headers after they are sent.
    at validateHeader (_http_outgoing.js:504:11)
    at ServerResponse.setHeader (_http_outgoing.js:511:3)
    at dnsPrefetchControl (C:\Programming\pbc\server\auth-server\node_modules\dns-prefetch-control\index.js:9:11)
    at call (C:\Programming\pbc\server\auth-server\node_modules\connect\index.js:239:7)
    at next (C:\Programming\pbc\server\auth-server\node_modules\connect\index.js:183:5)
    at Function.handle (C:\Programming\pbc\server\auth-server\node_modules\connect\index.js:186:3)
    at app (C:\Programming\pbc\server\auth-server\node_modules\connect\index.js:51:37)
    at Layer.handle [as handle_request] (C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\layer.js:95:5)
    at trim_prefix (C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\index.js:317:13)
    at C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\index.js:284:7
    at Function.process_params (C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\index.js:335:12)
    at next (C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\index.js:275:10)
    at compression (C:\Programming\pbc\server\auth-server\node_modules\compression\index.js:220:5)
    at Layer.handle [as handle_request] (C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\layer.js:95:5)
    at trim_prefix (C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\index.js:317:13)
    at C:\Programming\pbc\server\auth-server\node_modules\express\lib\router\index.js:284:7

But then setting type to 'before', the error handler won't catch the error! 😆

You simply needs to left out the next(); call and the error will go away.

Is that the case for just 'after' typed middleware? It makes sense as to why this issue happens now that I've played around with it and I've got working middleware with no issues. I don't think there's any bug here, but the documentation needs to be updated with a working example that won't throw an error 😀

I get this Can't set headers after they are sent even with no `next() method
@Middleware({ type: "after" })
export class CustomErrorHandler implements ExpressErrorMiddlewareInterface {

    error(error: any, request: any, response: any, next: (err: any) => any) {
        console.log("error...");
    }

}

I get this Can't set headers after they are sent even with no `next() method
@Middleware({ type: "after" })
export class CustomErrorHandler implements ExpressErrorMiddlewareInterface {

    error(error: any, request: any, response: any, next: (err: any) => any) {
        console.log("error...");
        response.status(error.status || 500)
            .json({
                name   : error.name,
                message: error.message,
                status : error.httpCode,
                stack  : error.stack,
            })
    }

}

What is sending the headers?

Default error handler.

For people coming here from the internet, from my research it seems like something like class-validators will set the headers for you, hence why you're getting this error.
I was able to work around it by checking for res.headersSent. Here's my full middleware:
import * as express from 'express';
import { ExpressErrorMiddlewareInterface, HttpError, Middleware } from 'routing-controllers';

import { Logger, ILoggerInterface } from '../../decorators/logger';
import { env } from '../../env';

@Middleware({ type: 'after' })
export class ErrorHandlerMiddleware implements ExpressErrorMiddlewareInterface {

  isProduction = env.isProduction;

  constructor(
    @Logger(__filename) private log: ILoggerInterface
  ) { }

  error(error: HttpError, req: express.Request, res: express.Response, next: express.NextFunction): void {
    // It seems like some decorators handle setting the response (i.e. class-validators)
    if (!res.headersSent) {
      res.status(error.httpCode || 500);

      res.json({
        name: error.name,
        message: error.message,
        errors: error['errors'] || [],
      });
    }

    if (this.isProduction) {
      this.log.error(error.name, error.message);
    } else {
      this.log.error(error.name, error.stack);
    }
  }
}

Reopening to clarify this in the docs.

I realize this might be trivial for others, but for me (and, possibly, future Internet searchers), even after reading through this thread and the full intro page for the project, it took a while (and some code-digging) to realize that if you want to use your own error handler middleware, you're probably better off disabling the default one:
createExpressServer({
  defaultErrorHandler: false,
  // ...etc.

That way you can set your error headers and response bodies however you want, without having to worry about the headers being set before your middleware had a chance to do it.


Replace env var filter with something configuration-cache compatible

The filtering approach required enumerating all available environment
variables. This makes all these variables inputs to the configuration
cache so any change will invalidate the cache once the tracking code for
environment variables.
With this commit the enumeration of the variables and name-based
filtering is replaced with the explicit list of variables because of the
limitations of the provider API. Currently, it isn't possible to ask for
a subset of environment variables. Unfortunately, this makes adding new
environment variables a bit harder. However, the new API to request a
subset of variables based on the prefix is currently considered so we
can move to it when it is available.

Triggering again because there was some issue with Windows CI agents yesterday to get a clearer picture of what fails
@bot-gradle test RfR

@bot-gradle test RfR

OK, I've already triggered ReadyForRelease build for you.

@bot-gradle test and merge

OK, I've already triggered a build for you.


False positive when replacing a struct with a pub type alias

Steps to reproduce the bug with the above code
We've found that we can't move things around in a backwards compatible way using pub use since the deprecated attribute doesn't work on use statements, so we've been using pub type to move them around instead. When we do this, cargo-semver-checks reports it as a breaking change:
--- failure struct_missing: pub struct removed or renamed ---

Description:
A publicly-visible struct cannot be imported by its prior path. A `pub use` may have been removed, or the struct itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.24.1/src/lints/struct_missing.ron

To reproduce, have crates A and B, with B depending on A. Leave A empty for now. In B, add a struct:
pub struct Foo;

Then, as part of a patch release for both crates, move Foo into A, and re-export it using a pub type in B.
A:
pub struct Foo;

B:
#[deprecated(note = "Use A::Foo")]
pub type Foo = A::Foo;

There's a real-world repro in https://github.com/smithy-lang/smithy-rs/pull/3318
Actual Behaviour
False positive saying the struct was removed and can't be referenced anymore.
Expected Behaviour
It should recognize that the type alias has the same name and points to the struct. (Actually not sure rustdoc has enough information to make this possible.)
Generated System Information
Software version
cargo-semver-checks 0.26.0
Operating system
macOS 13.6.2 (Darwin 22.6.0)
Command-line
/Users/jdisanti/.cargo/bin/cargo-semver-checks semver-checks --bugreport

cargo version
> cargo -V
cargo 1.70.0 (ec8a8a0ca 2023-04-25)

Compile time information

Profile: release
Target triple: aarch64-apple-darwin
Family: unix
OS: macos
Architecture: aarch64
Pointer width: 64
Endian: little
CPU features: aes,crc,dit,dotprod,dpb,dpb2,fcma,fhm,flagm,fp16,frintts,jsconv,lor,lse,neon,paca,pacg,pan,pmuv3,ras,rcpc,rcpc2,rdm,sb,sha2,sha3,ssbs,vh
Host: aarch64-apple-darwin

Build Configuration
No response
Additional Context
No response

The root cause here is the definition and the type alias being in different crates. For cases when they are in the same crate, we have test cases (one, two, there are more) that make sure we get this right.
Much of the below might already be familiar to you and others — I'm writing it down so I have an easy thing to reference in the future.
Cargo-semver-checks can't currently do cross-crate analysis, so all items from other crates look like they are missing. This is because:

Rustdoc doesn't inline re-exported items across crates. This used to be the case, but was removed because it was causing lots of bugs and other kinds of unpleasantness.
There's currently no reliable way to determine which dependency (including crate and exact version, to distinguish between multiple major versions) a cross-crate item came from. There has been interest in adding such a mechanism, though progress seems to have slowed recently: https://github.com/rust-lang/compiler-team/issues/635
There will still be probably 3 person-months of work needed on the cargo-semver-checks side after such a mechanism is added. Such a large investment of time would require finding a more permanent source of funding for the project — sponsoring me on GitHub is the way to do that. When I can cover rent with cargo-semver-checks, I'll be much more able to work on time-consuming improvements like this.


Update Korean translation to ac2d48f

also change all 깃허브 to Github. (related #145)

'GitHub' is more proper than 'Github', as they says on https://github.com/about.

ㄴ applied.


Fixed iOS 13 crash when accessing statusBar

Wow, thanks for this! Saved me a hot minute, working to get an update out. :)


Ability to save a secret in a secret store

Describe the feature
There are some situations where secrets will need to saved in a secret store and updated over time. I have a use case where I need to store a refresh token in Azure Key Vault using a cron job, which needs to be refreshed every 6 hours.
In C#, this could look like this:
await _daprClient.SaveSecretAsync("secretstore-name", "key-value", tokens);

Release Note

RELEASE NOTE:

@yaron2 recently spoke to this point in Discord about a month ago. This is not planned as a feature at this time because of the security implications of a user gaining access to Dapr and being able to write arbitrarily to your vault (including overwrite existing secrets).
As such, I'm going to close this as not planned, but I might suggest two alternative approaches:

Use the cryptography functionality to encrypt your secret and place it under a key via the state management block. This isn't necessarily recommend (but an option) given that your state management provider presumably requires credentials to read/write values, so you can at least limit access to some degree (perhaps use a scope on your component to limit which apps can read it), and achieve a similar functionality.

The the Azure Key Vault Secrets SDK with an identity that is assigned the Key Vault Secrets Officer (or better) role on the Key Vault and write the secret through this client. Then read via Dapr as you'd like. This is the approach I tend to take in my own applications when I absolutely must write something to the Key Vault.

Please feel free to re-open the issue if you have any follow-up questions, but again, this isn't something likely to change on Dapr itself.

Closed as completed by mistake. Rather, closing as not-planned.


Fix bug #662 - cookies not being maintained correctly over session involving redirects+set-cookie - need to save cookie domain in sessions file

Observed problems using --follow with --session, that on resuming using the saved session but expired authentication cookies stored in the session, httpie was generating duplicated cookies - saving the domain in the session file resolved this.

Codecov Report

Merging #1304 (aa36b0e) into master (4d7d6b6) will decrease coverage by 0.76%.
The diff coverage is 95.08%.

@@            Coverage Diff             @@
##           master    #1304      +/-   ##
==========================================
- Coverage   97.28%   96.52%   -0.77%
==========================================
  Files          67       85      +18
  Lines        4235     6012    +1777
==========================================
+ Hits         4120     5803    +1683
- Misses        115      209      +94

Impacted Files
Coverage Δ

tests/test_binary.py
100.00% <ø> (ø)

httpie/compat.py
31.11% <27.90%> (-68.89%)
:arrow_down:

tests/conftest.py
77.14% <58.33%> (-9.82%)
:arrow_down:

httpie/output/lexers/http.py
59.09% <59.09%> (ø)

tests/test_ssl.py
91.01% <66.66%> (-3.93%)
:arrow_down:

httpie/manager/__main__.py
82.35% <82.35%> (ø)

httpie/output/lexers/metadata.py
82.35% <82.35%> (ø)

httpie/models.py
94.23% <90.00%> (-3.14%)
:arrow_down:

tests/test_uploads.py
97.70% <92.59%> (-2.30%)
:arrow_down:

httpie/manager/core.py
92.85% <92.85%> (ø)

... and 71 more

Continue to review full report at Codecov.

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

Thanks for the PR @barny, but we have decided to take a different approach to fully solve this problem in #1312.


Leftover console.log

https://github.com/Yuliang-Lee/v-smooth-scroll/blob/cb21e3dbcb1afd4a6c9dba14b3b067f931b8e169/src/index.js#L118
It prints out a VNode in the console with every click.

☝ is a PR for that.


Re-introduce the fixes for bag/mix symdif

This time, we don't change any of the set tests.
All of the 'showkv' calls were removed as they are no longer necessary
and several new tests to ensure symmetric behavior on (+) and (.) operators.

How come showkv are no longer needed? Setties/Baggies are unordered so the how they stringify is not predicable, or is it?
I know if the tests are changed to is-deeply instead of is then we won't need showkv for sure....

How come showkv are no longer needed? Setties/Baggies are unordered so the how they stringify is not predicable, or is it?
I know if the tests are changed to is-deeply instead of is then we won't need showkv for sure....


Build(deps-dev): Bump lint-staged from 12.2.0 to 12.2.1 (#2441)

Pull request opened by the merge tool on behalf of #2441

Merged in 079a34aa7b92184bddc9750ab54104aba6ae97f5


Invoice fix

Coverage decreased (-0.02%) to 77.62% when pulling 96a318a16d26cfaeaf5f86b2f4e47244b81bfdb5 on fix-invoice into f6363f538ed59b581eaa50407aa9eb02507ae8a5 on master.


Using loadNro on 3.0.0, get Error: [ 408, 0x80e16 "Not initialized in module RO userland" ]

Am I doing it wrong?
Should I do something like: evalfile loadNro.js .
I've already run SetupNew.js, and it seemed successful.

Use the runnro command.

For anyone who finds this from googling it, the solution is to enable sdbcore (by either running 'enable sdbcore' in pega, or making a config.json in the same folder as start.js and entering "sdbcore": true in the config).
'enable sdbcore' wasn't working for me, so I had to manually add it to the config file. Once sdbcore is enabled, you'll need to disconnect your switch from the wifi connection that pega is running on, and then reconnect it. I did that by turning airplane mode off and on, then going back to wifi and reconnecting.
Anyway, feel free to message me or someone else for help getting your switch set up. Remember. you need either 3.0.0 firmware or 1.0.0.


Internal labels fix

#108 I localized the issue to this method. The problem lies in the way that a component supplies it's name. Basically:

If you register the custom component globally and use it as described in the documentation it works as intended.
If you use script setup and explicity define it using the code below, it works.

If you use script set-up and don't define your component name, then the method is unable to locate the name, returns undefined and therefore useInternalLabels is never set to true.

This fix implements a type check for whether the object evaluates as a component by checking for it's render function. If it's present (Which should be in 99% of the time), it'll return true.
Using my example (without the fix)

<template>
  <q-step
    :name="name"
    :title="title"
    :done="step > name"
    :header-nav="step > name"
  >
    For each ad campaign that you create, you can control how much you're willing to
    spend on clicks and conversions, which networks and geographical locations you want
    your ads to show on, and more.

      <blitz-form v-model="formData" :schema="schema" :internal-labels="true"/>
  </q-step>
</template>

Named test component

<template>

                Test Label

                <q-input
                    :dense="true"
                    :name="name"
                    model-value=""
                    :label="label"
                    :outlined="outlined"
                >
                    <template #append>
                            <q-icon name="help_outline" class="text-blue-grey-6">
                                <q-tooltip>
                                    I'm an useful tooltip!

                                </q-tooltip>
                            </q-icon>
                    </template>
                </q-input>

</template>

unnamed test component

<template>

                Test Label

                <q-input
                    :dense="true"
                    :name="name"
                    model-value=""
                    :label="label"
                    :outlined="outlined"
                >
                    <template #append>
                            <q-icon name="help_outline" class="text-blue-grey-6">
                                <q-tooltip>
                                    I'm an useful tooltip!

                                </q-tooltip>
                            </q-icon>
                    </template>
                </q-input>

</template>

With the output being:

@KazWar thanks!
gonna merge this but then refactor a bit more, and remove trying to get the name at all, because it causes too many issues. : )
we'll loose the css class based on the component name but I think that's ok


Added Italian language

I added the Italian language

Nice, thanks! I'll look through it 😊.

Have you looked at it? I'm an Italian native speaker, there shouldn't be any mistakes. I can also take care of other translations if you want

Sorry, I've been busy this last days. I'm working on it right now 😁


IndexError: list index out of range

I strictly follow your requirements to establish directory structure.  Air_depth (*.mat) seems that there is no download link or data.Watergan can generate synthetic underwater image without air_depth?

IndexError: list index out of range.  I think that depth_batch_files is empty，which means we have no depth data. So, Watergan maybe needs  air_depth.

I can't find image restoration network in your code.It is convenient for your to share these codes?
sorry to ask you so many questions, thanks  a lot !

You should download NYU dataset.Then you can load the nyu_depth_data_labeled by MATLAB.After that,you can check out the variables about the .mat, you will find 2200+images. Next, you could read this images and depth.mat and save it by yourself. I have trained the model sucessfully. But as for the correction model, I have no idea.

@djjandXMU  同学你好，为了方便，我打中文了。我已经下载了NYU RGB-D dataset， 空气中的图像已经放到air_images，深度信息（mat文件）已经放到air_depth当中。   一运行mainjamaica.py，https://github.com/kskin/WaterGAN/blob/3ad47608d20a9651fdf36ecb38b236e0942fae7b/modeljamaica.py#L743 就会报错ValueError: 'arr' does not have a suitable array shape for any mode. 请问你方便分享代码吗

同学你好，我最近正在复现它的后半部分代码，我将会一并公布，请耐心等待一下------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2019年6月11日(星期二) 晚上7:26
收件人<EMAIL_ADDRESS>抄送: "DJJandU"2712316242<EMAIL_ADDRESS>主题: Re: [kskin/WaterGAN] IndexError: list index out of range (#3)
@djjandXMU  同学你好，为了方便，我打中文了。我已经下载了NYU RGB-D dataset， 空气中的图像已经放到air_images，深度信息（mat文件）已经放到air_depth当中。   一运行mainjamaica.py，https://github.com/kskin/WaterGAN/blob/3ad47608d20a9651fdf36ecb38b236e0942fae7b/modeljamaica.py#L743 就会报错ValueError: 'arr' does not have a suitable array shape for any mode. 请问你方便分享代码吗
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

谢谢你了，

请问你是如何配置的这个环境，以及mat咋样生成的


Feature request: severity

I was able to hack a severity level so that a message only prints if its severity is above the min severity level. This is useful when for example you run the program in a verbose vs non-verbose mode.
Here is what worked for me:
const bullet = require("string.bullet");
const { cyan, yellow, red, dim, blue } = require("ansicolor");

var log = require("ololog").configure({
  locate: false,
  infoSeverity: 5,
  tag: (
    lines,
    {
      level = "",
      minSeverity=10,
      severity = 11,
      levelColor = {
        info: cyan,
        warn: yellow,
        error: red.bright.inverse,
        debug: blue
      }
    }
  ) => {
    const levelStr =
      level && (levelColor[level] || (s => s))(level.toUpperCase());
    if (severity >= minSeverity) {
      return bullet(levelStr.padStart(6) + "  ", lines);
    } else return [];
  }
});

log("This prints!");

log
.configure({tag:{severity:12}})
.info("This will print, severity 12!");

log
.configure({tag:{severity:1}})
.info("This will print, severity 1!");

log
.configure({tag:{severity:15}})
.info("This will print, severity 15!");

log = log
.configure({tag:{minSeverity:1000}}); // change severity

log
.configure({tag:{severity:12}})
.info("This will not print, severity 12!");

log
.configure({tag:{severity:1}})
.info("This will not print, severity 1!");

log
.configure({tag:{severity:15}})
.info("This will not print, severity 15!");

However, this is ugly. Ideally, it should be like this:
var log = require("ololog").configure({
  locate: false,
  infoMinSeverity: 5,
  warnMinSeverity: 6,
  debugMinSeverity: 8,
  errorMinSeverity: 10,
  minSeverity: 15, //without tag
});

log.severity(5).info('This is my message');
log.configure({infoMinSeverity:0}).info('This is my message');

@ourarash Have you looked into this: https://github.com/xpl/ololog#adding-custom-helper-methods ?
Try that code:
log = require ('ololog').configure (...).methods ({

    severity (n) { return this.configure ({ tag: { severity: n } }) })
})

This will allow you to do this:
log.severity(5).info('This is my message')


feat: add support for the new map (the fungle)

Add support for the new map that will be released in a few days.

https://www.innersloth.com/new-map-the-fungle-coming-this-october/
https://store.steampowered.com/news/app/945360/view/3725096176277127674

Not sure if it will work as nobody knows if the map id will just be incremented as it has in the past :P

@denverquane
Hi, today's update does not have big changes. Quickly tested and I can confirm that this PR works as expected. Could you please review, merge, and release this PR? Thanks!


Add Relational.exists function, and push it down to Calcite

Add Relational.exists function, which can be used as exists in queries, like this:
from d in scott.dept
where exists (
  from e in scott.emp
  where e.deptno = d.deptno)

Push exists down to Calcite relational algebra (typically as a semi-join). Queries typically have correlating variables (the above query has d.deptno, for an example) so we will need to deal with those also.
Related are the elem and notElem infix operators, which are analogous to SQL's IN and NOT IN (but without SQL's horrible null-semantics). They need to be pushed down to Calcite, too, but we probably won't deal with those in this case.

exists list is a straightforward function: it returns whether the list is non-empty. Adding the built-in function is trivial, but the push-down to Calcite is the hard part.
Note the List.exists and Vector.exists functions are rather different: they check whether an element in a list or vector matches a given predicate. It is unfortunate that the names are similar.
Since Relational.exists operates on a list, it can be used as an aggregate function. It's not very useful, because the set of rows going into an aggregate function in group is always non-empty, and therefore exists will always return true. If we implement the equivalent of SQL's FILTER (filtered aggregate functions) or OVER (windowed aggregate functions), exists may become more useful.

Fixed in d0f9175.


Error:  API Rate Limit Reached. Waiting 10 seconds...

Hi,
Every time I run in continuous mode, I get this waiting message. Do you know how I should resolve this?

Hey @madeleinesnyder. Your OpenAI free trial may have ended. Could you please check?
If you're not running on a paid account:

Upgrade to a paid account: https://platform.openai.com/account/billing/overview
Add a payment method: https://platform.openai.com/account/billing/payment-methods
(optional) set my usage limits: https://platform.openai.com/account/billing/limits
Create a new API key: https://platform.openai.com/account/api-keys
Edit the OpenAI Key

Let me know if this solves your issue


About the results  and the loss convergence

I run your code in 8 V100 GPUs using resnet50 as backbone. But it seems that the loss convergence is unstable in training after the first few epochs. The AP of the last epoch is 0.33, but the AP of the 12th epoch is 0.35.
Could you provide  the loss curve and the APs of every epoch?  It would be very helpful for me as a reference.
Thanks.

@cqg1997 The training of transformer is unstable, it is natural. Sorry I have not saved the log and have no card to train it now.