[vcpkg] Fortran: switch from gfortran to ifort?

Since ifort is now basically free we could switch from the gfortran hack to ifort. That would have the benefit that the linkage is no longer limited.

One problem that might come up with Intel Fortran in the future is 32-bit support. From the documentation:

Support for 32-bit targets is deprecated in ifort and may be removed in a future release. ifx does not support 32-bit targets.

So while ifort still supports 32-bit targets at the moment, we do not know when this "future release" will happen. Additionally I do not know whether Intel plans to eventually replace ifort by ifx.
But for the moment ifort could be a good path forward. My question would be whether we should try to implement an automatic download of Intel oneAPI as a replacement to what we currently do with gfortran or whether we should simply leave it to the user to have a Fortran Compiler installed and configured in the triplet, similar to what is currently done on Linux and macOS. We could still point the user to the Intel compilers as a suggestion. What do you think?

One problem that might come up with Intel Fortran in the future is 32-bit support. From the documentation:

Support for 32-bit targets is deprecated in ifort and may be removed in a future release. ifx does not support 32-bit targets.

So while ifort still supports 32-bit targets at the moment, we do not know when this "future release" will happen. Additionally I do not know whether Intel plans to eventually replace ifort by ifx.
But for the moment ifort could be a good path forward. My question would be whether we should try to implement an automatic download of Intel oneAPI as a replacement to what we currently do with gfortran or whether we should simply leave it to the user to have a Fortran Compiler installed and configured in the triplet, similar to what is currently done on Linux and macOS. We could still point the user to the Intel compilers as a suggestion. What do you think?

I pushed a x64-windows-ifort triplet to PR #15053.
One thing i noticed is that we need to install a vcpkg-cmake-wrapper.cmake for blas and probably for lapack to force the BLAS|LAPACK_VENDOR so that cmake is not picking up the now provided mkl libraries by acciedent.

I pushed a x64-windows-ifort triplet to PR #15053.
One thing i noticed is that we need to install a vcpkg-cmake-wrapper.cmake for blas and probably for lapack to force the BLAS|LAPACK_VENDOR so that cmake is not picking up the now provided mkl libraries by acciedent.

hmm having underscore issues with ifort due to intel not adding trailing underscores to fortran libraries on windows. https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-Fortran-External-Library-Linking-Issue/m-p/1181668/highlight/true#M148897

hmm having underscore issues with ifort due to intel not adding trailing underscores to fortran libraries on windows. https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-Fortran-External-Library-Linking-Issue/m-p/1181668/highlight/true#M148897

When I had support for ifort in my first tries to add fortran support to vcpkg, I added the flags -names:lowercase [1] and -assume:underscore [2] to the fortran compile options. Maybe this can solve the problems you are seeing?
[1] https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/language-options/names.html
[2] https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/language-options/assume.html

When I had support for ifort in my first tries to add fortran support to vcpkg, I added the flags -names:lowercase [1] and -assume:underscore [2] to the fortran compile options. Maybe this can solve the problems you are seeing?
[1] https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/language-options/names.html
[2] https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/language-options/assume.html

I tried different settings but the problem is iforts defeault mangling on Windows. Adding the lowercase and underscore flags the error building Lapack is:
[3728/3729] cmd.exe /C "cmd.exe /C ""C:\Program Files\CMake\bin\cmake.exe" -E __create_def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def.objs && cd E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg" && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll --intdir=SRC\CMakeFiles\lapack.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe --manifests  -- xilink /nologo @CMakeFiles\lapack.rsp  /out:bin\lapack.dll /implib:lib\lapack.lib /pdb:bin\lapack.pdb /dll /version:3.9 /machine:x64  /INCREMENTAL /DEBUG:FULL  /DEF:SRC\CMakeFiles\lapack.dir\.\exports.def  && cd ."
FAILED: bin/lapack.dll lib/lapack.lib
cmd.exe /C "cmd.exe /C ""C:\Program Files\CMake\bin\cmake.exe" -E __create_def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def.objs && cd E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg" && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll --intdir=SRC\CMakeFiles\lapack.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe --manifests  -- xilink /nologo @CMakeFiles\lapack.rsp  /out:bin\lapack.dll /implib:lib\lapack.lib /pdb:bin\lapack.pdb /dll /version:3.9 /machine:x64  /INCREMENTAL /DEBUG:FULL  /DEF:SRC\CMakeFiles\lapack.dir\.\exports.def  && cd ."
LINK Pass 1: command "xilink /nologo @CMakeFiles\lapack.rsp /out:bin\lapack.dll /implib:lib\lapack.lib /pdb:bin\lapack.pdb /dll /version:3.9 /machine:x64 /INCREMENTAL /DEBUG:FULL /DEF:SRC\CMakeFiles\lapack.dir\.\exports.def /MANIFEST /MANIFESTFILE:SRC\CMakeFiles\lapack.dir/intermediate.manifest SRC\CMakeFiles\lapack.dir/manifest.res" failed (exit code 1120) with the following output:
   Creating library lib\lapack.lib and object lib\lapack.exp
second_EXT_ETIME.f.obj : error LNK2019: unresolved external symbol etime_ referenced in function second_
dsecnd_EXT_ETIME.f.obj : error LNK2001: unresolved external symbol etime_
bin\lapack.dll : fatal error LNK1120: 1 unresolved externals

ETIME is a Fortran library function and is not exported as etime_ in the fortran libraries intel ships. There everything is uppercase without any trailing underscore. Intel seems to make the built fortran libraries on windows incompatible by design by sticking to their naming convention on windows (which also breaks cmakes detection in FindBLAS and FindLAPACK). The funny thing is that their MKL/LAPACK implementation ships with every possible name mangling (uppercase/lowercase/with&without trailing underscore).

I tried different settings but the problem is iforts defeault mangling on Windows. Adding the lowercase and underscore flags the error building Lapack is:
[3728/3729] cmd.exe /C "cmd.exe /C ""C:\Program Files\CMake\bin\cmake.exe" -E __create_def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def.objs && cd E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg" && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll --intdir=SRC\CMakeFiles\lapack.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe --manifests  -- xilink /nologo @CMakeFiles\lapack.rsp  /out:bin\lapack.dll /implib:lib\lapack.lib /pdb:bin\lapack.pdb /dll /version:3.9 /machine:x64  /INCREMENTAL /DEBUG:FULL  /DEF:SRC\CMakeFiles\lapack.dir\.\exports.def  && cd ."
FAILED: bin/lapack.dll lib/lapack.lib
cmd.exe /C "cmd.exe /C ""C:\Program Files\CMake\bin\cmake.exe" -E __create_def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg\SRC\CMakeFiles\lapack.dir\.\exports.def.objs && cd E:\vcpkg_folders\fortran\buildtrees\lapack-reference\x64-windows-ifort-dbg" && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_dll --intdir=SRC\CMakeFiles\lapack.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe --manifests  -- xilink /nologo @CMakeFiles\lapack.rsp  /out:bin\lapack.dll /implib:lib\lapack.lib /pdb:bin\lapack.pdb /dll /version:3.9 /machine:x64  /INCREMENTAL /DEBUG:FULL  /DEF:SRC\CMakeFiles\lapack.dir\.\exports.def  && cd ."
LINK Pass 1: command "xilink /nologo @CMakeFiles\lapack.rsp /out:bin\lapack.dll /implib:lib\lapack.lib /pdb:bin\lapack.pdb /dll /version:3.9 /machine:x64 /INCREMENTAL /DEBUG:FULL /DEF:SRC\CMakeFiles\lapack.dir\.\exports.def /MANIFEST /MANIFESTFILE:SRC\CMakeFiles\lapack.dir/intermediate.manifest SRC\CMakeFiles\lapack.dir/manifest.res" failed (exit code 1120) with the following output:
   Creating library lib\lapack.lib and object lib\lapack.exp
second_EXT_ETIME.f.obj : error LNK2019: unresolved external symbol etime_ referenced in function second_
dsecnd_EXT_ETIME.f.obj : error LNK2001: unresolved external symbol etime_
bin\lapack.dll : fatal error LNK1120: 1 unresolved externals

ETIME is a Fortran library function and is not exported as etime_ in the fortran libraries intel ships. There everything is uppercase without any trailing underscore. Intel seems to make the built fortran libraries on windows incompatible by design by sticking to their naming convention on windows (which also breaks cmakes detection in FindBLAS and FindLAPACK). The funny thing is that their MKL/LAPACK implementation ships with every possible name mangling (uppercase/lowercase/with&without trailing underscore).

@albertziegenhagel ok got it to work in that PR needed to add a small preprocessor patch for lapack.

@albertziegenhagel ok got it to work in that PR needed to add a small preprocessor patch for lapack.

@BillyONeal Will Intel oneAPI be installed on the azure to update MKL in the future? If yes we could also install the intel compilers along with it and switch from gfortran to ifort and ask the user to install ifort if he needs it. The necessary CI scripts can be found in: https://github.com/oneapi-src/oneapi-ci

@BillyONeal Will Intel oneAPI be installed on the azure to update MKL in the future? If yes we could also install the intel compilers along with it and switch from gfortran to ifort and ask the user to install ifort if he needs it. The necessary CI scripts can be found in: https://github.com/oneapi-src/oneapi-ci

Will Intel oneAPI be installed on the azure to update MKL in the future?

If someone creates a PR with the associated edits, sure. The existing MKL bits were all community contributed things.

Will Intel oneAPI be installed on the azure to update MKL in the future?

If someone creates a PR with the associated edits, sure. The existing MKL bits were all community contributed things.

see #15598
question now is if it is acceptable to ask the user to install those bits if they require lapack.
we could also automatically install them if we introduce something like VCPKG_ACCEPT_THIRD_PARTY_EULA which is off by default.

see #15598
question now is if it is acceptable to ask the user to install those bits if they require lapack.
we could also automatically install them if we introduce something like VCPKG_ACCEPT_THIRD_PARTY_EULA which is off by default.

replace ifort by ifx

icx.exe /help
Intel(R) C++ Compiler for applications running on Intel(R) 64

CC="icc -qnextgen"

used through keys
ifx.exe /help
Intel(R) Visual Fortran Compiler for applications running on Intel(R) 64

used through keys

FC="ifort -qnextgen" F77="ifort -qnextgen"

replace ifort by ifx

icx.exe /help
Intel(R) C++ Compiler for applications running on Intel(R) 64

CC="icc -qnextgen"

used through keys
ifx.exe /help
Intel(R) Visual Fortran Compiler for applications running on Intel(R) 64

used through keys

FC="ifort -qnextgen" F77="ifort -qnextgen"

?
clang.exe --version

Intel(R) oneAPI DPC++ Compiler 2021.1 (2<IP_ADDRESS>3)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\bin

?
clang.exe --version

Intel(R) oneAPI DPC++ Compiler 2021.1 (2<IP_ADDRESS>3)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\bin

@MVoz: IntelClang and ifx are not currently supported by CMake so using them is out of question currently. CMake 3.20 should support them but I would probably wait until 3.21 or 3.20.3 to work on something to support them.

Hello, I am interested in submitting a port that requires fortran. I searched for "fortran support" and got here (I read the related issue as well)
I can compile it with intel oneAPI outside of vcpkg and I can also compile it on linux using whatever the default fortran compiler is. After I installed oneAPI and allowed it to integrate, the cmake files from the port picked it up right away and it 'just worked"
https://github.com/joeydumont/complex_bessel
So my main question is can I make a port of this, or is intel fortran support currently broken? For example, would it even pass CI? Comments above suggest it would not.  I am fine keeping this library outside of vcpkg or as a private port - if it has no chance of being merged I wont bother making a PR

Hi everyone,
Can anyone of you help me to find the right link to download  ifort (IFORT) 2021.8.0 20221119 for windows 11.
Thanks in advance.

@Rajainb You need the Intel oneAPI HPC toolkit from: https://www.intel.com/content/www/us/en/developer/tools/oneapi/toolkits.html#hpc-kit
CI scripts to download the stuff can be found here:
https://github.com/oneapi-src/oneapi-ci


Convert to Erlang?

Wondering if this library shouldn't also be Erlang since telemetry is and this is something that will definitely be written again if telemetry catches on with Erlang.
I may ask the same regarding metrics but after discussing more today I'm not sure its use is what I was thinking, so need to think about that one some more.

That would be great, I was planning to implement such a facade for Gleam

I'm nearing completion on this. Should have a PR up within the week.
@josevalim what was the concern you had about needing a facade for Elixir? @arkgil and I were struggling to figure that out.

I am totally fine with the conversion to Erlang for this project. As long as we define a child_spec/1 in telemetry_poller, we are good to go. I wouldn't even define an Elixir module. My other concern is about documentation, but again, the user interface to the telemetry poller is quite limited, so it is fine.
Those concerns are accentuated on Telemetry.Metrics though. It is going to be the main way users interact with Telemetry and it heavily relies on structs, which don't have an equivalent in Erlang. So I wouldn't convert that one to Erlang quite yet, but this one is fine.

For Metrics I'd suggest just using OpenCensus (soon to be OpenTelemetry which will make this nice and confusing -- "In Erlang instead of Telemetry.Metrics you can use OpenTelemetry metrics...") as the suggested tool for the user to use to describe metrics. Assuming there isn't some change that makes it possible to share a Telemetry.Metrics interface.
So really only a matter of if someone is writing docs or a blog post describing how you can instrument your Erlang or Elixir apps with the same libraries they would call out this one case and point to OpenTelemetry.

@tsloughter doesn't OpenCensus bring everything related to a reporting backend though? I am fine with establishing a lower-level API that Telemetry.Metrics can call in to, but whatever that API is, it should be only data structures and no knowledge of any reporter.

@josevalim yes, it does. I'm suggesting it since there isn't an Erlang alternative in the Telemetry ecosystem so might as well call out something that does exist and can integrate with Telemetry. If a lower-level API gets made that is another story.
Will note this on the WG meeting agenda, and finally get out a doodle with some possible times to meet.

Oh, just noticed @bryannaegele says he has done the conversion already, nevermind about me working on it this weekend :)

Oh, I see what you mean. Yes, going directly to the reporter without the Telemetry.Metrics bit is always an option too!

@tsloughter I added discussing the direction of and a status update on the OpenCensus -> OpenTelemetry roadmap to the agenda. Let's join that discussion with this one.

Yeah, I wanted to add that to this thread before anyone got ambitious this weekend lol. Only @arkgil knew I'd started it.


Added flag to disable SSL certificate checking

Closes #30

@stuartmccoll Thanks for adding this! However, --ssl=False does not work, but it worked for me with --ssl=None. I think this is unexpected as the counterpart is True.
Additonally, this flag does not enable / disable SSL, it only enables/disables the certificate verification, so the documentation is maybe a little misleading here.


Validate JSON value

There have been several improvements to support JSON values in the Azure Portal:

support for application/json in the first place
multiline edit box
larger edit box

What's missing is JSON validation on save. It has happened to us a couple of times that we added a JSON property to an existing JSON value and we created invalid JSON by leaving a trailing comma.
Invalid JSON values will be ignored in the final Microsoft extensions configuration on the client.
The problem is that your Azure App Service might fail to start due to incomplete configuration. This is a costly op failure and you're looking for a needle in a haystack trying to debug the problem.
A simple solution would be to validate the JSON value on save in the Azure Portal.

@theo-albers that's a good suggestion. App Config Azure portal should have better JSON support including validation. Thanks!

Yes, it works, fantastic!


Issues with spectest

I have seen three issues with the use of spectest:

It generates a deprecation warning under Elixir 1.17.
    warning: ExUnit.Case.register_test/4 is deprecated. Use register_test/6 instead
     │
 169 │             ExUnit.Case.register_test(env, :spectest, "#{TypeCheck.Inspect.inspect(spec)}", [
     │             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     │
     └─ deps/type_check/lib/type_check/ex_unit.ex:169: Ilox.TokenTest (module)

spectest should be exported in .formatter.exs (and it doesn't really look like .formatter.exs is included with the package on hex.pm, which means that importing :typecheck will result in no impact).

Given sufficiently long type combinations without aliasing (I’m doing a check that a whole bunch of atoms being used for context keys is valid),  spectest will generate tests that will not compile, failing (variously) with one of the two errors below:
 Function: 'spectest new(\n  type\n  ::\n  Ilox.Token.lox_standalone | Ilox.Token.lox_compound | Ilox.Token.lox_literal |\n   Ilox.Token.lox_keyword | Ilox.Token.lox_terminal, \n  line :: non_neg_integer(), \n  lexeme :: binary(), \n  literal :: any()\n)\n::\nIlox.Token.t'/1

 == Compilation error in file test/ilox/token_test.exs ==
 ** (SystemLimitError) a system limit has been reached
     :erlang.list_to_atom(~c"-spectest new(\n  type\n  ::\n  Ilox.Token.lox_standalone | Ilox.Token.lox_compound | Ilox.Token.lox_literal |\n   Ilox.Token.lox_keyword | Ilox.Token.lox_terminal, \n  line :: non_neg_integer(), \n  lexeme :: binary(), \n  literal :: any()\n)\n::\nIlox.Token.t/1-fun-0-")
 (compiler 8.5.1) v3_core.erl:2374: :v3_core.new_fun_name/1
 …

== Compilation error in file test/ilox/token_test.exs ==
** (SystemLimitError) the computed name of a test (which includes its type, the name of its parent describe block if present, and the test name itself) must be shorter than 255 characters, got: "spectest type(\n  Ilox.Token.lox_standalone | Ilox.Token.lox_compound | Ilox.Token.lox_literal |\n   Ilox.Token.lox_keyword | Ilox.Token.lox_terminal\n)\n::\nIlox.Token.lox_standalone | Ilox.Token.lox_compound | Ilox.Token.lox_literal |\n Ilox.Token.lox_keyword | Ilox.Token.lox_terminal"

I haven't yet pushed up the code that is using TypeCheck, but you can find what I’m doing at https://github.com/halostatue/blob/main/lib/ilox/token.ex.

It's worth noting that in the case described, where I call Ilox.Token.new(:foo, 0, "", nil) as a test, I get a 189-line exception message:
* (TypeCheck.TypeError) At lib/ilox/token.ex:1:
    The call to `new/4` failed,
    because parameter no. 1 does not adhere to the spec `type :: Ilox.Token.lox_tokens`.
    Rather, its value is: `:foo`.
    Details:
      The call `new(:foo, 0, "", nil)`
      does not adhere to spec `new(
      type :: Ilox.Token.lox_tokens,
      line :: non_neg_integer(),
      lexeme :: binary(),
      literal :: any()
    )
    ::
    Ilox.Token.t`. Reason:
        parameter no. 1:
          `:foo` does not match the definition of the named type `type`
          which is: `type :: Ilox.Token.lox_tokens`. Reason:
            `:foo` does not match the definition of the named type `Ilox.Token.lox_tokens`
            which is: `Ilox.Token.lox_tokens
            ::
            Ilox.Token.lox_standalone | Ilox.Token.lox_compound | Ilox.Token.lox_literal |
             Ilox.Token.lox_keyword | Ilox.Token.lox_terminal`. Reason:
              `:foo` does not check against `Ilox.Token.lox_standalone | Ilox.Token.lox_compound | Ilox.Token.lox_literal |
               Ilox.Token.lox_keyword | Ilox.Token.lox_terminal`. Reason:
                all possibilities failed:
                  0)
                    `:foo` does not match the definition of the named type `Ilox.Token.lox_standalone`
                    which is: `Ilox.Token.lox_standalone
                    ::
                    :left_paren | :right_paren | :left_brace | :right_brace | :comma | :dot |
                     :minus | :plus | :semicolon | :slash | :star`. Reason:
                      `:foo` does not check against `:left_paren | :right_paren | :left_brace | :right_brace | :comma | :dot |
                       :minus | :plus | :semicolon | :slash | :star`. Reason:
                        all possibilities failed:
                          0)
                            `:foo` is not the same value as `:left_paren`.

                          1)
                            `:foo` is not the same value as `:right_paren`.

                          2)
                            `:foo` is not the same value as `:left_brace`.

                          3)
                            `:foo` is not the same value as `:right_brace`.

                          4)
                            `:foo` is not the same value as `:comma`.

                          5)
                            `:foo` is not the same value as `:dot`.

                          6)
                            `:foo` is not the same value as `:minus`.

                          7)
                            `:foo` is not the same value as `:plus`.

                          8)
                            `:foo` is not the same value as `:semicolon`.

                          9)
                            `:foo` is not the same value as `:slash`.

                          10)
                            `:foo` is not the same value as `:star`.

                  1)
                    `:foo` does not match the definition of the named type `Ilox.Token.lox_compound`
                    which is: `Ilox.Token.lox_compound
                    ::
                    :bang | :bang_equal | :equal | :equal_equal | :greater | :greater_equal |
                     :less | :less_equal`. Reason:
                      `:foo` does not check against `:bang | :bang_equal | :equal | :equal_equal | :greater | :greater_equal |
                       :less | :less_equal`. Reason:
                        all possibilities failed:
                          0)
                            `:foo` is not the same value as `:bang`.

                          1)
                            `:foo` is not the same value as `:bang_equal`.

                          2)
                            `:foo` is not the same value as `:equal`.

                          3)
                            `:foo` is not the same value as `:equal_equal`.

                          4)
                            `:foo` is not the same value as `:greater`.

                          5)
                            `:foo` is not the same value as `:greater_equal`.

                          6)
                            `:foo` is not the same value as `:less`.

                          7)
                            `:foo` is not the same value as `:less_equal`.

                  2)
                    `:foo` does not match the definition of the named type `Ilox.Token.lox_literal`
                    which is: `Ilox.Token.lox_literal :: :identifier | :string | :number`. Reason:
                      `:foo` does not check against `:identifier | :string | :number`. Reason:
                        all possibilities failed:
                          0)
                            `:foo` is not the same value as `:identifier`.

                          1)
                            `:foo` is not the same value as `:string`.

                          2)
                            `:foo` is not the same value as `:number`.

                  3)
                    `:foo` does not match the definition of the named type `Ilox.Token.lox_keyword`
                    which is: `Ilox.Token.lox_keyword
                    ::
                    :and | :class | :else | :Qfalse | :fun | :for | :if | :Qnil | :or | :print |
                     :return | :super | :this | :Qtrue | :var | :while`. Reason:
                      `:foo` does not check against `:and | :class | :else | :Qfalse | :fun | :for | :if | :Qnil | :or | :print |
                       :return | :super | :this | :Qtrue | :var | :while`. Reason:
                        all possibilities failed:
                          0)
                            `:foo` is not the same value as `:and`.

                          1)
                            `:foo` is not the same value as `:class`.

                          2)
                            `:foo` is not the same value as `:else`.

                          3)
                            `:foo` is not the same value as `:Qfalse`.

                          4)
                            `:foo` is not the same value as `:fun`.

                          5)
                            `:foo` is not the same value as `:for`.

                          6)
                            `:foo` is not the same value as `:if`.

                          7)
                            `:foo` is not the same value as `:Qnil`.

                          8)
                            `:foo` is not the same value as `:or`.

                          9)
                            `:foo` is not the same value as `:print`.

                          10)
                            `:foo` is not the same value as `:return`.

                          11)
                            `:foo` is not the same value as `:super`.

                          12)
                            `:foo` is not the same value as `:this`.

                          13)
                            `:foo` is not the same value as `:Qtrue`.

                          14)
                            `:foo` is not the same value as `:var`.

                          15)
                            `:foo` is not the same value as `:while`.

                  4)
                    `:foo` does not match the definition of the named type `Ilox.Token.lox_terminal`
                    which is: `Ilox.Token.lox_terminal :: :eof`. Reason:
                      `:foo` is not the same value as `:eof`.
    (lox 0.1.0) deps/type_check/lib/type_check/spec.ex:243: anonymous fn/5 in Ilox.Token.new/4
    iex:1: (file)

Again, this isn't yet pushed, and not related to spectest, but I suspect that I am pushing TypeCheck to some fairly irrational limits, but it still seems better than writing my own validation for these same values.


Fix listing branches to include current highlighted branch

In git --no-pager branch --list "release-*", the current branch is highlighted with a star and the parser is not handling that case:
$ git --no-pager branch --list "release-*"
  release-1.33
  release-1.34
* release-1.35

/hold

/unhold


GET providers/Microsoft.Web/functions/<FUNCTION_NAME>?api-version=2015-08-01 Not Found

Looks like when you use the 'resource group' flavored functions API (noted at https://github.com/projectkudu/kudu/wiki/Functions-API) it doesn't find any functions, (even though they exist) .
However if you use the 'web apps' flavored functions API (also noted at https://github.com/projectkudu/kudu/wiki/Functions-API) such as:
GET providers/Microsoft.Web/sitename/functions/<FUNCTION_NAME>?api-version=2015-08-01 -> Returns <FUNCTION_NAME>.
This is with the current version of Kudu deployed with an 'Azure Functions' creation via portal.azure.com.

Yes, the resource group flavored one is only meant to be used if the Functions App was created using the RG flavored API in the first place. So if you created the app via portal, you would not see it.


feat: chapter 1 - your first android application

Chapter 1: Your First Android Application
This pull request adds a new feature to the application.
Topics Covered

App Basics
Creating an Android Project
Navigating in Android Studio
Laying Out the UI
From Layout XML to View Objects
Wiring Up Views
Making Toasts
Running on the Emulator

How to Test
To test the new feature, you can do the following:

Clone the repository.
Install the dependencies.
Run the application.
The new feature should be available.

Screenshots

Known Issues
There are no known issues with this pull request.
References
Reviewers
Thanks!

Looks good to me.

Looks good to me.


Refactor variable naming and simplify IP retrieval

The 'render_download' function in 'renderer.py' now uses 'type_of_download' instead of 'type' for clearer comprehension. For 'ratelimiting.py', the process of obtaining client IP has been simplified for better readability and performance. This change uses a shorter syntax with the same functionality.

Thanks! The renderer file should be removed altogether, it's a leftover from the previous project I worked on. The IP change looks fine!


Fix #6664: HTTP request cancels the request properly.

NetJavaImpl#cancelHttpRequest cancels pending downloads by canceling the submitted executor service HTTP request task.

This only works if the request hasn't yet started connecting (for instance when cancelling right after sending the request).
However, when canceling after the connection process has already begun (which is the more realistic use case imho), it won't do anything. To try this, just comment out removeFromConnectionsAndListeners(httpRequest) in cancelHttpRequest (so you'll still receive listener events even after "cancelling") and then call a slow website (e.g., http://www.fakeresponse.com/api/?sleep=1). After a couple seconds the request times out and HttpResponseListener#failed is called.

Since the HttpURLConnection is using blocking socket implementation there is no way to interrupt the connect() in sendHttpRequest. Calling Future#cancel(true) does not to the job, since HttpURLConnection connect cannot be interrupted. To fix this behavior the HttpURLConnection would have to be replaced with some other implementation (NIO). But this is a big change (and probably not welcome).
The bugfix is still very useful from my point of view as it cancels all pending requests. For me personally I found this very useful when loading map tiles together with maxThreads set (many queued requests).  On map zoom change it allows me to cancel downloading of tiles which are not longer needed.


Add frontend nginx container for logging and plausible proxying

Fixes

Related to #536 by @sarayourfriend
Related to #2996 by @obulat
Fixes #2993
The issue will only be fixed, if we take this approach, after adding the new service to the live deployments.
Description

Adds a new Nginx image for us to publish and use as a reverse-proxy to the frontend service. This enables two things:

Per-request logging in a format identical to the API logging. There are improvements we can make here with respect to configuration sharing, but that adds complexity that we can push off for now while we validate this approach.
Plausible request proxying that is testable locally.

This PR is still a draft because I need to add building and publishing the image to CI.
Testing Instructions

Run just frontend/up which will automatically build the new frontend_nginx service, then just frontend/run dev. Afterwards, to be able to test Plausible locally, run just frontend/init. Run just ps and visit the frontend_nginx URL and confirm you can visit the site and browse it as normal. Audit the nginx logs using just logs frontend_nginx. Next, test Plausible by visiting it using the instructions from the Openverse documentation. Confirm that you see the page views as expected.
To test that upstream proxying works, modify OPENVERSE_NGINX_PLAUSIBLE_EVENT_URL to point to upstream (https://plausible.io/api/event) and confirm the requests are forwarded by Nginx.
Note that in the Plausible documentation for Nginx proxying they also have you proxy the script. However, we bundle the script into the app via the vue plugin, so this isn't necessary for us to do (as you can see from the original configuration, we were not proxying the script).
Edit: I (@obulat) added the issue that this PR fixes
Checklist

[x] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[N/A] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.
[N/A] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Is there a way to see the normal frontend access logs

What do you mean by "the normal frontend access logs"? The Nginx container is the "logging" entrypoint, in production it would front Nuxt. You can view those logs using just logs frontend_nginx as mentioned in the testing instructions.

Is there a way to see the normal frontend access logs

Can you clarify what you mean by "the normal frontend access logs"? The Nginx container is the "logging" entrypoint, in production it would front Nuxt. You can view those logs using just logs frontend_nginx as mentioned in the testing instructions.

When I tested this PR, I only saw the POST requests sent for analytics. I did not see the logs for requests of the frontend pages when I visited them. So, nothing for a GET request to "localhost:8443" or a server-rendered "localhost:8443/image/?q=cat", for instance. Are those requests supposed to be logged in the frontend_nginx logs?

Are those requests supposed to be logged in the frontend_nginx logs?

Yes, the idea is that in production the Nginx container would proxy the Nuxt container and provide us with access logs (and Plausible proxying). To test the logs in this PR you have to access the frontend through the frontend_nginx service, not directly at localhost:8443, and tail the logs for frontend_nginx.
I'm realising the testing instructions aren't clear about this, it just says "visit the frontend_nginx URL", which isn't obvious. You should test it by accessing the frontend at localhost:50290 and tailing the nginx logs. You need to have the frontend running locally though, otherwise the Nginx service won't have anything to send the requests to.

Thank you for clarifications, @sarayourfriend !
Is there a way to remove duplicated logging:

<IP_ADDRESS> - - [06/Oct/2023:07:23:42 +0000] "GET /_nuxt/pages/index.modern.js HTTP/1.1" 200 6006 "http://<IP_ADDRESS>:50290/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"
{"time_local":"06/Oct/2023:07:23:42 +0000","remote_addr":"x.x.x.x","remote_user":"","request":"GET /_nuxt/pages/index.modern.js HTTP/1.1","status": "200","host_header": "<IP_ADDRESS>","body_bytes_sent":6006,"request_time":"0.006","http_referrer":"http://<IP_ADDRESS>:50290/","http_user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36","upstream_response_time":0.006,"http_x_forwarded_for":""}
<IP_ADDRESS> - - [06/Oct/2023:07:23:42 +0000] "GET /_nuxt/9c7bd6e0532911068731cb497475a9a5.svg HTTP/1.1" 200 11886 "http://<IP_ADDRESS>:50290/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"
{"time_local":"06/Oct/2023:07:23:42 +0000","remote_addr":"x.x.x.x","remote_user":"","request":"GET /_nuxt/9c7bd6e0532911068731cb497475a9a5.svg HTTP/1.1","status": "200","host_header": "<IP_ADDRESS>","body_bytes_sent":11886,"request_time":"0.010","http_referrer":"http://<IP_ADDRESS>:50290/","http_user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36","upstream_response_time":0.010,"http_x_forwarded_for":""}

Also, it seems that these logs will be pretty noisy if we log every request for every JS file...

Those are great changes, Olga. We should apply them to the API configuration as well. I guess it would just about cut the size of our Nginx logs by at least a third, if not closer to a half! Talk about a real cost saver, especially as we're adding new logging for the frontend.
Filtering the _nuxt requests out could be good too, I hadn't considered how noisy they are; however, those are also requests that Nuxt is needing to handle, having visibility into them could be important (maybe they're particularly slow, sometimes, for example). Theoretically those resources are cached in production, and we wouldn't see more than a single log per-resource per-release, provided our caching works the way we think it should. And if it doesn't, by chance, what a great way to find out, by seeing more logs here than we expect! Do you think it's worth keeping them? If we see them clogging up production request logs then it would be a great signal for us to check our caching configuration :slightly_smiling_face:

Filtering the _nuxt requests out could be good too, I hadn't considered how noisy they are; however, those are also requests that Nuxt is needing to handle, having visibility into them could be important (maybe they're particularly slow, sometimes, for example). Theoretically those resources are cached in production, and we wouldn't see more than a single log per-resource per-release, provided our caching works the way we think it should. And if it doesn't, by chance, what a great way to find out, by seeing more logs here than we expect! Do you think it's worth keeping them? If we see them clogging up production request logs then it would be a great signal for us to check our caching configuration 🙂

I hadn't considered how the _nuxt/ requests are cached, and yes, I think it's best to keep those. If they show that the caching configuration isn't set up correctly, then we can fix the caching and they will stop clogging the logs :)


Remove "or email" from search field at https://www.inaturalist.org/people

We don't actually search users' email addresses (which is a good thing, IMO) so that text should be removed.

Hi! I'll love to collaborate on the issue. Can you assign me?

@JoseChavez98 go for it. This would should be pretty straightforward. Since I'm not sure you've committed any code to iNat before, check out https://github.com/inaturalist/inaturalist/blob/master/CONTRIBUTING.md.


NUOPC Cap Improvements

Description
This pull requests maintains the cap by cleaning up the code for better maintainability and enhancements. Enhancements were made to the documentation, the import and export state initialization, and the import state checking
Resolves #1644
Testcase
Uses NASA Land Coupler for testing
https://github.com/esmf-org/NASA-Land-Coupler/tree/feature/lisf_upgrade
bit-for-bit results for coupled tuolumne cases
SUCCESS: coupled_tuolumne.ens020.noahmp_v4.0.1_da.nldas2 LIS_HIST_201403020000.d01.nc
SUCCESS: coupled_tuolumne.ens020.noahmp_v4.0.1_da.nldas2 LIS_HIST_201403030000.d01.nc
SUCCESS: coupled_tuolumne.noahmp.nldas2 LIS_HIST_201510020000.d01.nc
SUCCESS: coupled_tuolumne.noahmp.nldas2 LIS_HIST_201510030000.d01.nc

@jvgeiger @dmocko @emkemp
Hi all,
I'm submitting updates to the NUOPC coupling infrastructure (NUOPC Cap). It's going to come in a few separate different pull requests to isolate the changes. This first change is NUOPC cap only changes. I ran testing in a coupled configuration but it will need some offline regression tests.

@sujayvkumar
I'm including Sujay in this conversation.


How to loop future infinitely, what happened to loop_fn?

I want to build rust program that supervises child process, logs its stdin/out and restarts it with delay if program dies.
I'm using nightly version + futures-core-{preview, util} 0.3.0-alpha.18
I had no problems writing spawning and waiting function:
async fn start_process(
    &self
) -> () {
    let mut command = self.command_build(); // returns tokio_net::process::Command (also pipes std{out,err} and nulls stdin)
    let mut child = command.spawn().unwrap(); // tokio_net::process::Child

    let stdout = tokio::codec::FramedRead::new(
        child.stdout().take().unwrap(),
        tokio::codec::LinesCodec::default(),
    ).for_each(|message| {
        // log message
        return futures_util::future::ready(());
    });

    let stderr = tokio::codec::FramedRead::new(
        child.stderr().take().unwrap(),
        tokio::codec::LinesCodec::default(),
    ).for_each(|message| {
        // log message
        return futures_util::future::ready(());
    });

    // wait for process to finish
    child.await.unwrap();
    stdout.await;
    stderr.await;

    return ();
}

The next step is to build a loop that will restart the process if it ends (it should be long-running and dies only on fatal errors).
I'm pretty sure that setting up tokio delay timer (resolves future after certain amount of time) is fine, however I'm not sure how to build an inifinite loop for that.
While doing something like
pub async fn start_process_watch(
    &self
) -> () {
    loop {
        self.start_process().await;
        tokio_timer::delay_for(std::time::Duration::from_secs(15)).await;
    }
    return ();
}

may work, I'm not pretty sure if it's correct. What i'm worried about is the process of canceling this thing, for example when I'm not longer interested (or want to stop) in the process.
The IDE also warns me about unreachable code - the return statement.
What I want to achieve is to have function that:

runs the process and waits 15s if it dies, then restarts it.
stops the process / kills the timer if caller (future owner?) is not longer interested in it (future is dropeed)
never resolves, returns nothing

In the past I saw loop_fn / tail_fn, but I'm not sure what happened to this.
What is the correct way to do this on 29.09.19?
Best regards.

I think this question is more appropriate for stackoverflow than here, since it's not in particular about futures-rs.
What you want is:

A signal whether the process exists - likely in the form of a Future - That might be provided by Tokio.
A mechanism to wait at max 15s - that is provided e.g. by tokio timers
A mechanism to wait on either condition to happen first. You can use the select! macro from this library to do that.

Indeed, will move this to stackoverflow


Uses hatch and update releaser

@hbcarlos will this PR fix the integration test timeout issue?

Thanks @hbcarlos!


Change the opacity of some dashboard elements and permit customizations of background textures (fixes #183)

This PR:

Changes the opacity of some dashboard elements (https://github.com/ArkEcosystem/ark-desktop/issues/183)
Permits customizations of background textures
Customizes some background textures that are too pale for highlighting the main menu bar buttons

As a reference of the changes, this is the main toolbar before and after:

Since some things have changed (https://github.com/ArkEcosystem/ark-desktop/pull/294) I'll update this PR after some of the others that are pending that could provoke conflicts.

Hey @j-a-m-l, it was very good! so I preferred to use the class for any background.
merged manually +5 👍🏻


No 'Access-Control-Allow-Origin' to valhalla.mapzen.com

Hi, I began to use mapzen to do the routing, in this case without using the control
I am not able to do this because the not Allowed origin message. The weird thing is that it works when it is used with the leaflet routing machine control. This is the code and the message.
Thanks in advance
function rutaAB(latA, latB)  //
{
    var waypoints = [];
    var coords = [];
    var waysp = [];

    waypoints.length = 0;
    coords.length = 0;
    waysp.length = 0;
    if ((latA != null) && (latB != null))
    {

        var latlngA = L.Routing.waypoint(latA);
        var latlngB = L.Routing.waypoint(latB);

        waypoints.push(latlngA);
        waypoints.push(latlngB);

        var routes = null;

        routes = L.Routing.mapzen({addWaypoints: false});

        routes.route(waypoints, function(err, routes) {
             if (line) {
                 mapa.removeLayer(line);
             }

             if (err) {
                 console.log(err);
             }
             else {

                 coords = routes[0].coordinates;
                 waysp = routes[0].waypoints;
                 line = L.Routing.line(routes[0],{styles:[{color: 'black', opacity: 0.15, weight: 7}, {color: 'white', opacity: 0.8, weight: 4}, {color: '#1652F4', opacity: 1, weight: 3}]}).addTo(mapa);

                 var distanciaCerc = convertirKM(routes[0].summary.totalDistance);
                 popup = L.popup({offset: L.point(0, -30)})
                        .setLatLng(latB)
                        .setContent('
Distancia: ' + distanciaCerc + '
')
                        .openOn(mapa);

             }
       });

    }
    else
    {
        alert("Se necesita el par Origen-Destino para calcular la ruta");

    }

}

Hey, I am not sure why cors error is happening, but I can see the url for httprequest is not well formatted. (which makes 403 error) There is only one location in query (more than one location should be passed to route between points), and also api key is wrapped as object. (api key should be string)
This is well formatted one. (Replace your-api-key part to your actual api key to see it working)
https://valhalla.mapzen.com/route?json={%22locations%22:[{%22lat%22:37.752,%22lon%22:-122.418,%22type%22:%22break%22},{%22lat%22:37.779,%22lon%22:-122.391,%22type%22:%22break%22}],%22costing%22:%22auto%22,%22directions_options%22:{%22language%22:%22es%22}}&api_key='your-api-key'

yes we have an issue in which when the 403 comes back, it actually comes back from a different server than those who actually compute the routes, this server who sends the 403s doesnt send cors headers. this issue is being tracked here: https://github.com/kevinkreiser/prime_server/issues/28

Oh that makes sense. Thanks @kevinkreiser !

@hanbyul-here I tested the link after replacing my own key, the message:
KeyError''valhalla-A4rESty'' is not a valid key.

@rossanag your key shouldnt include the single quote character. it should just be api_key=valhalla-A4rESty

@kevinkreiser thanks, it works, it returns a json file. I will try the whole code later to see if the 503 error is gone.

@rossanag If you could solve your problem, would you close the issue?


Add snippet for formatSeconds

Good

inthecode

Thanks 🙏🏽
On Sat, May 15, 2021 at 7:30 PM, hugo105 @.***> wrote:

@.**** approved this pull request.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/30-seconds/30-seconds-of-code/pull/1791#pullrequestreview-660383610,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUBMNZ6AC7BAPFZYEORUSKLTN3DVFANCNFSM44O2DSKQ
.


Better function serialization

https://github.com/kblok/puppeteer/pull/13/commits/3596c5f7e2686de355249b23b26615d9a11f6e5f

We don't need to implement this in C#


Feature request: support $callers

Currently this project supports $ancestors which means that process tracking across Task.async works great. But if you use Task.Supervisor.async (or async_nolink) then the ex_unit test is not in the ancestor tree at all and the environment cannot be injected at all. I have a PoC for adding $callers support but I wanted to raise this as an issue first before creating the PR.
And thank you for this project, it has really helped clean up a bunch of our tests at Felt! :heart:

Hey that's cool you're finding value from the project - thanks for sharing! Definitely open to adding support for $callers if there's a way to do it reasonably. I haven't thought through the issues, though it sounds like maybe you have :-) Seems like the main question is, for a process whose lineage might (or might not) include $callers and $ancestors, is there a way to discover the true lineage and preserve correct ordering?  If you've got a POC, happy to see it - thank you!

I don't think there's really the concept of a "true lineage". I'd look at it more as the process having two separate lineages. I was planning to lookup values via $ancestors first, and then look in $callers. I've pushed up the PoC as #3, let me know what you think!

Another question is if we want to always look at $callers or if it should be configurable. For our use-case we'd want to always look at $callers because we're using process_tree solely for testing.

Thanks Jason! I'm intrigued by your approach and hope to get something along those lines into the project. First I need to understand the wrinkles around $callers and how people use Task.Supervisor.
To that end, I wonder if you could help me out a bit by showing me the scenarios you have in which "the ex_unit test is not in the ancestor tree at all", as you pointed out in your original post.
I've pushed a branch called callers-investigation that has a test called "$callers test":
    test "$callers test" do
      dbg(self())

      {:ok, supervisor} = Task.Supervisor.start_link()

      Task.Supervisor.async_nolink(supervisor, fn ->
        dbg(Process.get(:"$callers"))
        parent = ProcessTree.parent(self())
        dbg(parent)
        grandparent = ProcessTree.parent(parent)
        dbg(grandparent)
      end)

      :timer.sleep 1000
    end

In this scenario, the ex_unit test is in the ancestor tree, as seen by the output from the test:
jb ~/projects/process_tree (main) % mix test test/process_tree_test.exs:353
Running ExUnit with seed: 749369, max_cases: 16
Excluding tags: [:test]
Including tags: [location: {"test/process_tree_test.exs", 353}]

[test/process_tree_test.exs:353: ProcessTreeTest."test $callers callers"/1]
self() #=> #PID<0.180.0>

[test/process_tree_test.exs:358: ProcessTreeTest."test $callers callers"/1]
Process.get(:"$callers") #=> [#PID<0.180.0>]

[test/process_tree_test.exs:360: ProcessTreeTest."test $callers callers"/1]
parent #=> #PID<0.181.0>

[test/process_tree_test.exs:362: ProcessTreeTest."test $callers callers"/1]
grandparent #=> #PID<0.180.0>

Clearly your real-life scenario is doing something different, and if you have time to show me, I'd love to understand what that is. Thank you!!

I'm guessing you're using a Supervisor that isn't started in your test? Would love to see the details. Thanks!

Check out the callers-implementation branch and take it for a spin in your environment. Let me know if it does the trick!
You can see the changes here: https://github.com/jbsf2/process-tree/pull/4

Clearly your real-life scenario is doing something different, and if you have time to show me, I'd love to understand what that is. Thank you!!

Yeah the main difference is that Task.Supervisor is started as part of the application supervision tree. I was surprised to notice that the Task.Supervisor docs didn't give any specific guidance on how to start the supervisor, but especially if you want to use Task.Supervisor.async_nolink then you will want to start the supervisor as part of your supervision tree. Here's a blog post I found that covers it decently:
https://dev.to/felipearaujos/the-power-of-elixir-task-module-into-task-supervisor-5365

Check out the callers-implementation branch and take it for a spin in your environment. Let me know if it does the trick!

Nice! 🙌
I'm happy to report that it works in my test setup! 🎉
Also I like how you look up the entire tree, that makes a lot of sense now that I think about it.

@jbsf2 Is it possible to cut a release with $callers support? We've been using it for a couple months now and it's been stable but it would be nice to move back to a tagged release instead of running main

Hey for sure, my apologies for not taking care of this earlier. Would love your thoughts on how to incorporate $callers into a release, given that it's technically a change in behavior (though doubtful it would actually impact anyone).
Options include:

Keep the code as it currently is on @main and bump the major version.
Make usage of $callers optional and default it to false, thereby preserving backward compatibility. Support opt-in to $callers via a :use_callers option in ProcessTree.get()
Make $callers optional and default to true. Allow opt-out via a :use_callers option. Bump the major version.

Want to avoid a config-based opt-in/opt-out per the discussion here: https://hexdocs.pm/elixir/main/design-anti-patterns.html#using-application-configuration-for-libraries
Suppose we went with #2, then users who always want $callers could maybe just wrap their calls to get() with their own code, so that they don't need to pass the :use_callers option every time they access the tree.
Thanks very much!

Maybe just start with #1 and if it negatively impacts anyone, then add the option. Seems silly to bump a major version for a lib with essentially one function!

Yeah my vote would be for option 1. I'd probably also bump the version number to 0.2 and list the change in the changelog as a breaking change. Since process tree is still below 1.0 this technically satisfies semver as well since all changes before 1.0 are allowed to be breaking. And I doubt it is a major breaking change for anyone.

Ahh cool thanks man, I did not know that about breaking changes pre-1.0. That makes things easy! I expect to cut the release on Friday.


Installed ok but errors on run

Traceback (most recent call last):
File "/home/$USER/.local/bin/pinterest", line 8, in
sys.exit(main())
File "/home/$USER/.local/lib/python3.8/site-packages/src/init.py", line 300, in main
boards = [get_board_info(path) for path in paths]
File "/home/$USER/.local/lib/python3.8/site-packages/src/init.py", line 300, in
boards = [get_board_info(path) for path in paths]
File "/home/$USER/.local/lib/python3.8/site-packages/src/init.py", line 148, in get_board_info
initial_data
AttributeError: 'NoneType' object has no attribute 'get'

Same issue.
Got this during install if it helps:
Installing collected packages: urllib3, idna, chardet, requests, lxml, pinterest-downloader
Attempting uninstall: urllib3
Found existing installation: urllib3 1.26.2
Not uninstalling urllib3 at /usr/lib/python3/dist-packages, outside environment /usr
Can't uninstall 'urllib3'. No files were found to uninstall.
Attempting uninstall: idna
Found existing installation: idna 2.10
Not uninstalling idna at /usr/lib/python3/dist-packages, outside environment /usr
Can't uninstall 'idna'. No files were found to uninstall.
Attempting uninstall: chardet
Found existing installation: chardet 4.0.0
Not uninstalling chardet at /usr/lib/python3/dist-packages, outside environment /usr
Can't uninstall 'chardet'. No files were found to uninstall.
Attempting uninstall: requests
Found existing installation: requests 2.25.1
Not uninstalling requests at /usr/lib/python3/dist-packages, outside environment /usr
Can't uninstall 'requests'. No files were found to uninstall.

Having an error as well:
IndexError: list index out of range


.NET core .exe doesn't show an error message when the runtime isn't installed

I'm building a .NET Core 3 desktop application and I'm publishing it as "Framework dependent" (i.e. the .NET core 3 framework must be installed on the computer).
When I run the application on a computer without the .NET core runtime installed, nothing happens. I obviously didn't expect the application to work, but I did expect some kind of error. But the application simply quits without any user feedback whatsoever.
Is it possible to add some kind of check to the native executable and show an error message to the user that the .NET core runtime is missing? Preferably a message that includes a download link (like the full .NET Framework does).
For completeness, it's a WPF application that I'm testing on a 32-bit Windows 8.1. I don't think this is relevant, but in any case...

As an additional note, when you install the .NET core runtime but you don't install the Windows Desktop pack, the executable also quits without any user feedback. When I use "dotnet run" from the console, I do get an error message...

There's discussion happening about this over at https://github.com/dotnet/core-setup/issues/8222, we're looking at fixing it in 3.1. Yeah, this is particularly painful for WPF/WinForms apps since there's nowhere for stderr to show up.

Duplicate of https://github.com/dotnet/core-setup/issues/8222


How to use azure feature flag in asp.net core Blazor

How to use azure feature flag in asp.net core Blazor

@ajai1109 thanks for contacting us.
Can you provide a bit more details on what you are trying to achieve? We're not sure what "azure feature flag" means in this context.

I am trying to implement azure feature flags in asp.net core blazor project. Please go through this link https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-feature-flag-aspnet-core for your reference

@ajai1109 There's no specific support on Blazor to do that, and that's not something that the ASP.NET Core team works on.
@bradygaster Can you loop in the right people here so that we can provide guidance or improve the experience for Blazor users?
To get a faster response we suggest posting your questions to StackOverflow using the asp.net-core-blazor tag.

This issue was moved to Azure/AppConfiguration#170


Fix the match criteria of the static file routes

In #112 simplified the URL matching to always have the URI without query string in the uri key of the match criteria...
But in #110 I had still used the old key uri_without_query_string which is why the routes didn't work (I am actually surprised that any of the static files worked - if they did 🙈 )
This should work now ;)

Closed in favor of #116


Switched to latest 1.x CoffeeScript version

I think this dependency specification is more practical.

Definitely, thanks!


Allow to customize or localize instructions

We support 3 languages in our app and we would like to show the instructions but to be able to translate the instructions according to the app language.

That would be nice if we could provide our own bottom widget for this.

Yeah, I can do that. I don't work much with localized apps atm, so I'm not up-to-date on best practices. Would a good solution be adding something like this that would be passed to CommandPaletteConfig:
Default options shown, but all of those could be configured.
CommandPaletteInstructionConfig(
  confirmLabel: "to confirm",
  selectLabel: "to select",
  navigationLabel: "to navigate",
  cancelSelectedLabel: "to cancel selected action",
  closeLabel: "to close",
),

Let me know what you think!

Hi! This solution would work for us!

A new version has been published to pub.dev. Version 0.7.6, it will have the syntax described above with with further addition: CommandPaletteConfig.showInstructions has been deprecated in favor of CommandPaletteInstructionConfig.showInstructions


UniSpec with QE charge 1 predictions not supported

Hello,
Thanks for supporting UniSpec, I'm very excited to try it! I ran into an issue where peptides with charge 1 and instrument QE  are not supported. Sending it via curl results in the following error:
{"error":"Failed to process the request(s) for model instance 'UniSpec', message: UnboundLocalError: local variable 'cf' referenced before assignment\n\nAt:\n  /models/repo/UniSpec/1/model.py(38): NCE2eV\n  /models/repo/UniSpec/1/model.py(308): rawinp2tsr\n  /models/repo/UniSpec/1/model.py(496): execute\n
What is the reason charge 1 cannot be predicted on QE? Would you recommend setting peptides with charge 1 to have instrument = NONE as a workaround?
Best,
Kevin

Hi Kevin,
Thank you for trying out UniSpeci! @jlapin1 worked on the implementation of UniSpec. He can tell you if it's a bug in Koina or if there is a reason why Charge 1 is not supported.
As far as I know adding instrument=None would turn off NCE calibration and use raw eV values directly. You should be cautious with that.

Hey Kevin, its Joel. Very glad you are already trying to use the model. I had intended to contact you directly about it because I knew it was potentially of interest to you and your work.
Our model is trained to to take input of eV, since NCE is inconsistent between machines. Qian Dong (@qdong3161) originally did the painstaking work in finding the regression equations to convert NCE to eV, based on machine and charge. She does not have an equation for charge +1 on machines QE, QEHFX, and ELITE, probably because there was not enough data to find such an equation (there is a regression equation for +1 LUMOS though). My advice is to just set the instrument to None, and accept that the energy being input is likely not ideal.
In case you are interested, the code that does the NCE -> eV conversion is in the file Koina/models/UniSpec/UniSpec/1/model.py in the subroutine NCE2eV on line 8.


release notes: Mention the Nix update in 23.05

Links to the corresponding release notes, and mentions https://github.com/NixOS/nix/issues/8259 which isn't included in it (and is somewhat important since it's a language semantics change)
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Fixed conflicts and re-ordered the notes such that those core components appear first.

Included in #235183. Thanks for the reminder.