Automatic Inference of MinGW SDK Directory

The code in:
https://github.com/xmake-io/xmake/blob/c1f1db8e3358255e95afb22b5f16da683ec696e2/xmake/modules/detect/sdks/find_mingw.lua#L30-L43
Supports only macOS and Linux.
On top of this, it doesn't check for existence, it only sets directories (Which might not exist).
I suggest the following assuming MinGW platform was defined (-p mingw):

If on Windows, Look for Environment Variables GCC_BIN_PATH or GCC_LIB_PATH.
In case they exist define minGwSdk = GCC_BIN_PATH/.. or minGwSdk = GCC_LIB_PATH/.. with priority for the BIN folder.
If not on Windows, do as the code above deines.
Check for existence of minGwSdk. If it doesn't exist return an error.

Step (4) is in case the existence isn't in a later step in the program.

Ok, I will consider improving find_mingw()

In case they exist define minGwSdk = GCC_BIN_PATH/.. or minGwSdk = GCC_LIB_PATH/.. with priority for the BIN folder.

Can you let me see your the content of $GCC_BIN_PATH and $GCC_LIB_PATH?
mingwsdk should be the root directory of the bin/lib directory. e.g.
mingwsdk
  - bin
  - lib
  - include

GCC_BIN_PATH is exactly mingwsdk\bin in your example. Hence mingwsdk = GCC_BIN_PATH\..\.

Ok, thanks. BTW, GCC_BIN_PATH these environment variables, are you custom variables, or mingw sdk-specific variables, there are still some standard specifications? Are there any related reference documents?

It might depend on the MinGW distribution.
So maybe a better and more robust method is to scan the %PATH% variable for MINGW*/bin and infer from there?

It might depend on the MinGW distribution.
In other words, are these variables GCC_BIN_PATH set by mingw's specific distribution?

and which mingw distribution did you install? I will look at it.
If it is msys2/mingw, maybe we can infer it from /mingw64 and /mingw32.

So maybe a better and more robust method is to scan the %PATH% variable for MINGW*/bin and infer from there?

If a registry key is set, we can detect it from the registry, of course, find it directly from %PATH, which is also a way to consider.

No, I mean to scan the string of %PATH% (The system environment variable for the system path).
Look for a string match of mingw*/bin or mingw*\bin where it needs to be case insensitive (I can probably create the RegEx for that).
Once you find it, only remove the bin and what's after it and you have the SDK path.
No need for registry keys.

BTW, we can run xmake g --mingw=/xxx to set mingwsdk to global configration. then we only need run xmake f -p mingw; xmake to build project each time.

No, I mean to scan the string of %PATH% (The system environment variable for the system path).
Look for a string match of mingw*/bin or mingw*\bin where it needs to be case insensitive (I can probably create the RegEx for that).
Once you find it, only remove the bin and what's after it and you have the SDK path.
No need for registry keys.

I know what you mean, but I mean, if there are registry keys available, I prefer to use the registry first, because it is more reliable than searching from the %PATH% string. Of course, if not, we can continue to try to find it from the %PATH% string.

Since MinGW distributions are built to be portable (Namely user can change the folder after installation as long as he change the %PATH%) they don't use registry key.
The only thing I saw all of them expect, is the user to add MinGW_HOME_FOLDER to the path.
Where MinGW_HOME_FOLDER is the place it was installed.
It is better not to use registry. Keep your xmake portable and accessible by using system path and not registry.

But users may also change the directory name of mingwsdk, for example: /xxx/yyy, we may not be able to find it reliably from the %PATH% string. Of course, if there is a general MinGW_HOME_FOLDER, it is of course the best. If every user will go to set it.

Advanced use can always do things manually, and then use -p mingw --mingw=<path>.
We're talking on the nominal case. The bin folder will be in path.
In case --mingw= wasn't defined, use the bin folder. Once you extract it, look for gcc.exe in it. If it is there, infer from it the SDK.
I think this is pretty robust and user friendly. It means in most nominal cases using -p mingw will be enough to make all things play well.

By the way, I think a RegEx to capture the mingwsdk from %PATH% should be something like: [;]?([A-Za-z-\\:]*(?i)mingw[A-Za-z\\:-]*)[\\\/]bin.

I have improved it, you can update to the dev version and try it again. https://github.com/xmake-io/xmake/commit/5fb2bcc38583f830e064082024212c061f055b99
xmake update dev

Please download installer.exe to install dev version on github ci (https://github.com/xmake-io/xmake/actions/runs/288765711)
xmake update dev will download installer appveyor ci, but the installation package is not ready yet. (https://ci.appveyor.com/project/waruqi/xmake/builds/35566064)
You can also run xmake update -s dev to only update lua scripts.

Does it work?

The update fails on my machine (I don't have system wide GIT).
Is there a manual way to do so?

you can download install package from action ci.
https://github.com/xmake-io/xmake/actions/runs/292753296

It doesn't work:
xmake f -p mingw -Dv
checking for architecture ... x86_64
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx
error: @programdir\core\main.lua:284: @programdir\core\tool\toolchain.lua:194: stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:803]: in function 'raise'
    [@programdir\toolchains\mingw\check.lua:37]:
    [C]: in function 'load'
    [@programdir\core\tool\toolchain.lua:190]: in function 'check'
    [@programdir\core\platform\platform.lua:287]: in function 'check'
    [...mdir\core\sandbox\modules\import\core\project\config.lua:120]: in function 'check'
    [@programdir\actions\config\main.lua:249]:
    [C]: in function 'load'
    [@programdir\core\base\task.lua:520]: in function 'run'
    [@programdir\core\main.lua:282]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        @programdir\core\main.lua:284: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

My RegEx can extract the Path to MinGW from my %PATH% so I am not sure why it doesn't work.
This is the version I got from your link:
xmake --version
xmake v2.3.7+202010070503, A cross-platform build utility based on Lua
Copyright (C) 2015-2020 Ruki Wang, tboox.org, xmake.io

can you add -c to xmake f to ignore last cached result and try it again.
xmake f -p mingw -Dv -c

I manually deleted .xmake.
But anyhow:
xmake f -p mingw -Dv -c
checking for architecture ... x86_64
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx
error: @programdir\core\main.lua:284: @programdir\core\tool\toolchain.lua:194: stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:803]: in function 'raise'
    [@programdir\toolchains\mingw\check.lua:37]:
    [C]: in function 'load'
    [@programdir\core\tool\toolchain.lua:190]: in function 'check'
    [@programdir\core\platform\platform.lua:287]: in function 'check'
    [...mdir\core\sandbox\modules\import\core\project\config.lua:120]: in function 'check'
    [@programdir\actions\config\main.lua:249]:
    [C]: in function 'load'
    [@programdir\core\base\task.lua:520]: in function 'run'
    [@programdir\core\main.lua:282]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        @programdir\core\main.lua:284: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

Same result.

Can you let me see your %PATH%? I will look at it.

Here is a link to it: https://pastebin.ubuntu.com/p/WFwKtxwDpM/

ok, I  have improved it. You can wait some time, then re-download install package from https://github.com/xmake-io/xmake/actions/runs/292952854

What was the issue? Why not use my RegEx? It should be robust to all cases.

I have fixed the case sensitivity problem. Lua does not support regular expressions, only Lua pattern matching. But it's enough.
Dose it work now?

While the inference worked:
xmake f -p mingw -Dv -c
checking for architecture ... x86_64
checking for mingw directory ... D:\Applications\Programming\MinGW
configure
{
    host = windows
    buildir = build
    kind = static
    cross =
    mingw = D:\Applications\Programming\MinGW
    ccache = true
    mode = release
    bin = D:\Applications\Programming\MinGW\bin
    plat = mingw
    clean = true
    ndk_stdcxx = true
    arch = x86_64
}

The compilation itself didn't:
xmake -v -w
checking for x86_64-w64-mingw32-gcc ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-gcc) ... no
checking for x86_64-w64-mingw32-g++ ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-g++) ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-gcc) ... no
checking for the c++ compiler (cxx: x86_64-w64-mingw32-g++) ... no
error: ...mdir\core\sandbox\modules\import\core\base\scheduler.lua:47: cannot get program for cxx
stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        ...mdir\core\sandbox\modules\import\core\base\scheduler.lua:47: in function 'co_start_named'
        @programdir\modules\private\async\runjobs.lua:180: in function <@programdir\modules\private\async\runjobs.lua:139>
        [C]: in function 'trycall'
        @programdir\core\base\scheduler.lua:423: in function 'co_group_begin'
        ...mdir\core\sandbox\modules\import\core\base\scheduler.lua:85: in function 'co_group_begin'
        @programdir\modules\private\async\runjobs.lua:139: in function 'runjobs'
        @programdir\actions\build\build.lua:222: in function 'build'
        @programdir\actions\build\main.lua:115: in function <@programdir\actions\build\main.lua:110>
        [C]: in function 'trycall'
        @programdir\core\sandbox\modules\try.lua:121: in function 'try'
        @programdir\actions\build\main.lua:109: in function <@programdir\actions\build\main.lua:82>
        [C]: in function 'load'
        @programdir\core\base\task.lua:520: in function 'run'
        @programdir\core\main.lua:282: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

I improved it. you can also run xmake update -s dev to update lua scripts. or goto https://github.com/xmake-io/xmake/actions/runs/293340756

Still errors when compiling:
checking for flags (-fcolor-diagnostics) ... no
> gcc "-fcolor-diagnostics" "-m64"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: gcc: error: unrecognized command line option '-fcolor-diagnostics'

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:792]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:114]: in function 'has_flags'
    [@programdir\modules\core\tools\gcc.lua:358]: in function '_has_color_diagnostics'
    [@programdir\modules\core\tools\gcc.lua:435]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:420]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:75]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:88]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:113]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:
checking for flags (-MMD -MF) ... ok
> gcc "-MMD" "-MF" "C:\Users\Royi\AppData\Local\Temp\.xmake\201007\_A6D04840D4DE40308F60CA3AFE6BEF80"
checking for flags (-MMD -MF) ... ok
> gcc "-MMD" "-MF" "C:\Users\Royi\AppData\Local\Temp\.xmake\201007\_B0A86A555D8B49108FA7AC35DC09F950"
checking for flags (-fcolor-diagnostics) ... no
> gcc "-fcolor-diagnostics"
checkinfo: @programdir\core\sandbox\modules\os.lua:258: gcc: error: unrecognized command line option '-fcolor-diagnostics'

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:792]: in function 'raise'
    [@programdir\core\sandbox\modules\os.lua:258]: in function 'runv'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\detect\tools\gcc\has_flags.lua:42]: in function 'hasflags'
    [@programdir\modules\lib\detect\has_flags.lua:114]: in function 'has_flags'
    [@programdir\modules\core\tools\gcc.lua:358]: in function '_has_color_diagnostics'
    [@programdir\modules\core\tools\gcc.lua:435]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:420]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:75]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:88]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:113]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

And:
stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:792]: in function 'raise'
    [@programdir\modules\core\tools\gcc.lua:471]: in function 'catch'
    [@programdir\core\sandbox\modules\try.lua:127]: in function 'try'
    [@programdir\modules\core\tools\gcc.lua:420]:
    [C]: in function 'compile'
    [@programdir\modules\private\action\build\object.lua:75]: in function 'script'
    [@programdir\modules\private\action\build\object.lua:88]: in function '_build_object'
    [@programdir\modules\private\action\build\object.lua:113]: in function 'jobfunc'
    [@programdir\modules\private\async\runjobs.lua:188]:
    [C]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:121]: in function 'try'
    [@programdir\modules\private\async\runjobs.lua:182]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:317]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        @programdir\modules\private\async\runjobs.lua:210: in function 'catch'
        @programdir\core\sandbox\modules\try.lua:127: in function 'try'
        @programdir\modules\private\async\runjobs.lua:182: in function 'cotask'
        @programdir\core\base\scheduler.lua:317: in function <@programdir\core\base\scheduler.lua:315>

checkinfo: @programdir\core\sandbox\modules\os.lua:258: gcc: error: unrecognized command line option '-fcolor-diagnostics'

This is not an error, it is just the flags detection information and does not affect the compilation result. If the "-fcolor-diagnostics" detection fails, xmake will automatically ignore it.
You can remove the -D parameter and show me the final compilation error message.

OK. It seems to work as expected.

It seems the issue us back.
This is my path:
Path=D:\Applications\MinGW\bin;D:\Applications\BuildEnv\CMake\bin\;D:\Applications\BuildEnv\Meson\;D:\Applications\BuildEnv\Ninja;D:\Applications\BuildEnv\Xmake;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\Royi\AppData\Local\Microsoft\WindowsApps;

I run and get:
D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw
checking for architecture ... x86_64
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx

Why doesn't it infer MinGW automatically as it did previously?

I did not change it, you can debug this patch.
https://github.com/xmake-io/xmake/blob/5e4fd84a4dece56d8d542c64d291036c7fb3aabd/xmake/modules/detect/sdks/find_mingw.lua#L48-L59

I don't know how to debug this.
I just know it doesn't work and probably the issue isn't there.
Is there any more information I can add?
This is the main feature of xmake for me.
Easy to configure.

edit your installed xmake/xmake/modules/detect/sdks/find_mingw.lua in c:programdir/xmake
Add some print logs to debug it.
             for _, p in ipairs(path.splitenv(pathenv)) do
                 print(p, os.isdir(p)) ---> debug log
                 if p:find(string.ipattern("mingw[%w%-%_%+]*[\\/]bin")) and path.filename(p) == "bin" and os.isdir(p) then
                     print("found", p) --> debug log
                     sdkdir = path.directory(p)
                     break
                 end
             end

Bu as I wrote above, even if I set the folder path explicitly with --mingw=D:\Applications\MinGW\bin I get the same error.
So I'm not sure it is the path finding but something else.
As I wrote on Gitter, I'm on a computer without Visual Studio installed.
I have no problems compiling the project with CMake.

This is what I get after adding your debug commands:
D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw -Dv -c
checking for architecture ... x86_64
D:\Applications\BuildEnv\Xmake true
D:\Applications\MinGW\bin true
found D:\Applications\MinGW\bin
checking for mingw directory ... no
please run:
    - xmake config --mingw=xxx
or  - xmake global --mingw=xxx
error: @programdir\core\main.lua:279: @programdir\core\tool\toolchain.lua:255: stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:840]: in function 'raise'
    [@programdir\toolchains\mingw\check.lua:49]:
    [C]: in function 'load'
    [@programdir\core\tool\toolchain.lua:251]: in function 'check'
    [@programdir\core\platform\platform.lua:247]: in function 'check'
    [@programdir\actions\config\main.lua:384]:
    [C]: in function 'load'
    [@programdir\core\base\task.lua:519]: in function 'run'
    [@programdir\core\main.lua:277]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:365]:

stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:829: in function 'raise'
        @programdir\core\main.lua:279: in function 'cotask'
        @programdir\core\base\scheduler.lua:365: in function <@programdir\core\base\scheduler.lua:362>

Can you let me see your all mingw bin files list in D:\Applications\MinGW\bin

There you go:
D:\Applications\MinGW\bin>dir
 Volume in drive D has no label.
  Why did you put them in the list of required?
As I wrote, I can easily create the project with CMake and Meson so if XMake requires something extra, it is advised to not.
Moreover, I am no doing cross. I am on Windows and generating native Windows Binary / DLL.

@waruqi Some MinGW distributions don't have x86_64-w64-mingw32-gcc.exe and have gcc.exe instead, I've worked with some in the past. XMake should probably fallback on them

I have improved it, try it again.

Could you tag a release?
Also, those tests were not there when we created this automatic MinGW support. Why did you add them?

Could you tag a release?

Not yet. There are still many issues and features that need to be dealt with. You need to wait for a while.

Also, those tests were not there when we created this automatic MinGW support. Why did you add them?

what tests?

The tests for those file names.
Why did you add them?
Do you have a unit test before release.
You should add the distribution I linked above. It is probably the most used on Windows and XMake fails on it unlike Meson and CMake.

The tests for those file names.
Why did you add them?
Do you have a unit test before release.
You should add the distribution I linked above. It is probably the most used on Windows and XMake fails on it unlike Meson and CMake.

for supporting llvm-mingw and mingw on msys.
On msys, gcc.exe may not be mingw gcc, and llvm-mingw provides other arch support.
The unit test of the tool chain is too heavyweight, and it is impossible to test all tool chains and all cases on ci. And currently, basic tests have been done on the msys/mingw and macos/mingw tool chains on ci.

OK, so it went too far. On Windows, without MSYS2 no need to check those.
For the extreme cases of Cross Compilation you removed support for the basic case of MinGW on Windows.

OK, so it went too far. On Windows, without MSYS2 no need to check those.
For the extreme cases of Cross Compilation you removed support for the basic case of MinGW on Windows.

I did not delete it, because I have never supported gcc.exe for mingw in the previous version

I can assure you that version 2.3.8 worked with the MinGW distribution I am using and did find MinGW correctly.
You may see my comment https://github.com/xmake-io/xmake/issues/977#issuecomment-705341860. It worked.

same code
https://github.com/xmake-io/xmake/blob/965bccf5adee7a4a1c0e55b7c39d5637a3e95c15/xmake/modules/detect/sdks/find_mingw.lua#L83-L100

I think I got you Things are not well tested and hence things break up.
This is 2.3.8:
D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw -v
error: xmake v2.3.8 < v2.5.7, please run `$xmake update` to upgrade xmake!
error: @programdir\core\project\project.lua:1019: xmake v2.3.8 < v2.5.7, please run `$xmake update` to upgrade xmake!
stack traceback:
        [C]: in function 'error'
        @programdir\core\base\os.lua:792: in function 'raise'
        @programdir\core\project\project.lua:1019: in function 'tasks'
        @programdir\core\project\project.lua:1008: in function 'task'
        @programdir\core\main.lua:275: in function <@programdir\core\main.lua:219>

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake f -p mingw -v
checking for architecture ... x86_64
checking for mingw directory ... D:\Applications\MinGW
checking for x86_64-w64-mingw32-g++ ... no
checking for the shared library linker (sh: x86_64-w64-mingw32-g++) ... no
checking for x86_64-w64-mingw32-gcc ... no
checking for the shared library linker (sh: x86_64-w64-mingw32-gcc) ... no
checking for D:\Applications\MinGW\bin\g++ ... ok
checking for the shared library linker (sh) ... g++
configure
{
    cross =
    buildir = build
    ccache = true
    host = windows
    mode = release
    mingw = D:\Applications\MinGW
    kind = static
    ndk_stdcxx = true
    arch = x86_64
    plat = mingw
    bin = D:\Applications\MinGW\bin
}

D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake -v -w
checking for the c compiler (cc: x86_64-w64-mingw32-gcc) ... no
checking for D:\Applications\MinGW\bin\gcc ... ok
checking for the c compiler (cc) ... gcc
checking for flags (-Ofast) ... ok
checking for flags (-mavx2) ... ok
checking for flags (-march=native) ... ok
checking for flags (-mx32) ... ok
checking for ccache ... no
[ 50%]: compiling.release IncompleteCholeskyDecomposition.c
D:\Applications\MinGW\bin\gcc -c -m64 -Wall -Wextra -Weffc++ -Ofast -mavx2 -std=c17 -march=native -mx32 -o build\.objs\IncompleteCholeskyDecomposition\mingw\x86_64\release\IncompleteCholeskyDecomposition.c.obj IncompleteCholeskyDecomposition.c
checking for flags (-MMD -MF) ... ok
checking for flags (-fcolor-diagnostics) ... no
checking for flags (-fdiagnostics-color=always) ... ok
error: cc1.exe: warning: command line option '-Weffc++' is valid for C++/ObjC++ but not for C
cc1.exe: error: '-mabi=ms' not supported with X32 ABI

As you can see, it works (The error has to do with the xmake.lua not written well).
So maybe there are more issues.
It makes XMake look fragile and not well tested as it seems many things are done without measuring all consequences with unit testing.

I fixed the xmake.lua file and everything works:
D:\Applications\Documents\IncompleteCholeskyDecomposition>xmake -v -w
checking for D:\Applications\MinGW\bin\gcc ... ok
checking for flags (-Ofast) ... ok
checking for flags (-mavx2) ... ok
checking for flags (-march=native) ... ok
checking for ccache ... no
[ 50%]: compiling.release IncompleteCholeskyDecomposition.c
D:\Applications\MinGW\bin\gcc -c -m64 -Wall -Wextra -Weffc++ -Ofast -mavx2 -std=c17 -march=native -o build\.objs\IncompleteCholeskyDecomposition\mingw\x86_64\release\IncompleteCholeskyDecomposition.c.obj IncompleteCholeskyDecomposition.c
checking for flags (-MMD -MF) ... ok
checking for flags (-fcolor-diagnostics) ... no
checking for flags (-fdiagnostics-color=always) ... ok
cc1.exe: warning: command line option '-Weffc++' is valid for C++/ObjC++ but not for C
IncompleteCholeskyDecomposition.c: In function '_IncompleteCholDecTColumn':
IncompleteCholeskyDecomposition.c:305:13: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare]
  305 |   while (kk != -1) {
      |             ^~
IncompleteCholeskyDecomposition.c:364:18: warning: pointer targets in passing argument 1 of 'ArrayMergeSort' differ in signedness [-Wpointer-sign]
  364 |   ArrayMergeSort(vIdxCol, n_indices, vBuffer);
      |                  ^~~~~~~
[ 75%]: linking.release IncompleteCholeskyDecomposition.dll
D:\Applications\MinGW\bin\g++ -o build\mingw\x86_64\release\IncompleteCholeskyDecomposition.dll build\.objs\IncompleteCholeskyDecomposition\mingw\x86_64\release\IncompleteCholeskyDecomposition.c.obj -shared -m64 -s -Wl,--out-implib,build\mingw\x86_64\release\IncompleteCholeskyDecomposition.lib
[100%]: build ok!

Now you see you have made changes since 2.3.8 which destroyed this feature?

here. https://github.com/xmake-io/xmake/blob/6708849f5c386a5d16f7be3d568afa10df49bc16/xmake/modules/detect/sdks/find_cross_toolchain.lua#L46
        -- find tool path
+        if not opt.cross then
            toolpath = find_file(toolname, bindirs)
            if toolpath then
                return path.directory(toolpath), ""
            end
        end
+    end

    -- attempt to use the bin directory
    local bindir = opt.bindir or path.join(sdkdir, "bin")
+    if os.isdir(bindir) and not opt.cross then
        return bindir
+    end

Although this change affects mingw, I think this is the correct change.
In addition, the patch submitted in dev should have fixed your problem yesterday, there is no need to modify anything.

I have improved it, try it again.

https://github.com/xmake-io/xmake/commit/3a8aab03b9e615cd0a40a1ed21e9ab4490f6f1c5

By the way, using the flag -Weffc++ on a C project is wrong (I defined set_languages("c17") and all files are .c).

I have removed it.


How to get data-attr on change?

I know how the onChange() works, But how can i get data-attr from the  thanks!

Hi,
did you manage to get the data-attr value from the selected option??

I ended up switching to an alternate lib.

which one? :)


TimeCapsule&FrozenFuture is an unsound API, reliant on users to .await the .freeze(&mut …) future properly in-place

So, well, TimeCapsule<T> can accept a reference of just any lifetime for freeze. It produces a FrozenFuture<'a, 'b, T> that does have some lifetime corresponding to that reference, but all that ensures is that the reference stays alive until that future is polled, nothing else. If you do end up just .awaiting that future in-place (in particular, converting the Poll::pending of FrozenFuture into an immediately propagated Poll::pending of the surrounding future), then all may be well, but who forces you to do this?
That’s an easy exploit: Just poll the future, then invalidate the reference, and only then “propagate” the Poll::pending. Below is a straightforward implementation of this using helper macros from the futures crate family:
use std::marker::PhantomData;
use nolife::{BoxScope, Family, TimeCapsule};
use futures_util::{poll, pending};

struct SingleFamily<T: 'static>(PhantomData<T>);
impl<'a, T: 'static> Family<'a> for SingleFamily<T> {
    type Family = T;
}

fn main() {
    {
        let mut scope = BoxScope::new(
            |mut time_capsule: TimeCapsule<SingleFamily<String>>| async move {
                let mut x = String::from("Hello World!");
                let fut = time_capsule.freeze(&mut x);
                let _ = poll!(fut); // puts reference into state
                drop(x); // then invalidates reference
                pending!(); // then yields
                panic!();
            },
        );
        scope.enter(|s| {
            println!("{s}");
        })
    }
}

outputs garbage data, e.g.:
b����

miri output
error: Undefined Behavior: out-of-bounds pointer use: alloc877 has been freed, so this pointer is dangling
   --> /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/raw.rs:109:9
    |
109 |         &*ptr::slice_from_raw_parts(data, len)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ out-of-bounds pointer use: alloc877 has been freed, so this pointer is dangling
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
help: alloc877 was allocated here:
   --> src/main.rs:14:29
    |
14  |                 let mut x = String::from("Hello World!");
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: alloc877 was deallocated here:
   --> src/main.rs:17:17
    |
17  |                 drop(x); // then invalidates reference
    |                 ^^^^^^^
    = note: BACKTRACE (of the first span):
    = note: inside `std::slice::from_raw_parts::<'_, u8>` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/raw.rs:109:9: 109:47
    = note: inside `<std::vec::Vec<u8> as std::ops::Deref>::deref` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:2709:18: 2709:64
    = note: inside `<std::string::String as std::ops::Deref>::deref` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/string.rs:2539:43: 2539:52
    = note: inside `<std::string::String as std::fmt::Display>::fmt` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/string.rs:2354:28: 2354:34
    = note: inside `<&mut std::string::String as std::fmt::Display>::fmt` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2298:62: 2298:82
    = note: inside `core::fmt::rt::Argument::<'_>::fmt` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/rt.rs:142:9: 142:40
    = note: inside `std::fmt::write` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:1120:17: 1120:40
    = note: inside `<std::io::StdoutLock<'_> as std::io::Write>::write_fmt` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/mod.rs:1846:15: 1846:43
    = note: inside `<&std::io::Stdout as std::io::Write>::write_fmt` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:736:9: 736:36
    = note: inside `<std::io::Stdout as std::io::Write>::write_fmt` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:710:9: 710:33
    = note: inside `std::io::stdio::print_to::<std::io::Stdout>` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:1029:21: 1029:47
    = note: inside `std::io::_print` at /home/frank/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:1106:5: 1106:37
note: inside closure
   --> src/main.rs:23:13
    |
23  |             println!("{s}");
    |             ^^^^^^^^^^^^^^^
    = note: inside `nolife::scope::Scope::<SingleFamily<std::string::String>, {async block@src/main.rs:13:67: 20:14}>::enter::<'_, (), {closure@src/main.rs:22:21: 22:24}>` at /home/frank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/nolife-0.3.3/src/scope.rs:166:22: 166:30
    = note: inside `nolife::BoxScope::<SingleFamily<std::string::String>, {async block@src/main.rs:13:67: 20:14}>::enter::<'_, (), {closure@src/main.rs:22:21: 22:24}>` at /home/frank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/nolife-0.3.3/src/box_scope.rs:117:18: 117:41
note: inside `main`
   --> src/main.rs:22:9
    |
22  | /         scope.enter(|s| {
23  | |             println!("{s}");
24  | |         })
    | |__________^
    = note: this error originates in the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

Unfortunately, I cannot immediately think of straightforward fixes for soundness here.[^2] This might need more thought though. Let’s hope there is some alternative approach out there, and that his doesn’t mean this whole crate’s idea is fundamentally broken.
[^2]: At least without an API that involves some mandatory usage of a macro that calls unsafe, possibly-hidden, API.

Hello @steffahn,
Thank you for taking the time to examine nolife, I'm super happy to see you here :smiley:
I was looking for this kind of reviews earlier, and I thought that announcing the crate through a blogpost would have more chances to give it some visibility, basically as an application of Cunningham's Law.
Now, I'm not super happy with the outcome :sweat_smile: but such are the risks of trying a new approach.
Back to this issue, my understanding of the root cause is that you can decorrelate spawning the FrozenFuture (which setups the executor's  State) from actually yielding back to the executor.
Possible fixes would entail:

Force the returned borrow to live for the duration of the outer future. That's probably limiting the expressivity to a point where nolife wouldn't be useful.
Force yielding back to the executor upon creating the FrozenFuture somehow.

(2) is not even that simple to implement, because there can be multiple levels of future, so a simple freeze!() macro that would compile down to  time_capsule.freeze(&mut x).await() would be insufficient:
use std::marker::PhantomData;
use nolife::{BoxScope, Family, TimeCapsule};
use futures_util::{poll, pending};

struct SingleFamily<T: 'static>(PhantomData<T>);
impl<'a, T: 'static> Family<'a> for SingleFamily<T> {
    type Family = T;
}

async fn inner(time_capsule: TimeCapsule<SingleFamily<String>>, data: &mut String) {
     nolife::freeze!(time_capsule, data);
}

fn main() {
    {
        let mut scope = BoxScope::new(
            |mut time_capsule: TimeCapsule<SingleFamily<String>>| async move {
                let mut x = String::from("Hello World!");
                let fut = inner(time_capsule, &mut x);
                let _ = poll!(fut); // puts reference into state
                drop(x); // then invalidates reference
                pending!(); // then yields
                panic!();
            },
        );
        scope.enter(|s| {
            println!("{s}");
        })
    }
}

Or is it some other macro you had in mind?
Of course we could add a drop impl to FrozenFuture that resets the state, but then I guess the next step would be to forget about the future.

(2) is not even that simple to implement, because there can be multiple levels of future, so a simple freeze!() macro that would compile down to time_capsule.freeze(&mut x).await() would be insufficient:

Yes indeed, that's insufficient, of course. The macro would need to do all of

make sure the time_capsule.freeze…APIs are only available at the top-level of the block and only in a way immediately followed byawait`
wrap that block in an async (or at least parse an async { } a user wrote) so that it knows what counts as “top-level” to begin with
pass that async on to the actual BoxScope::new call, so that the future itself  couldn’t otherwise be polled, then dropped, before yield

Even then, I’m not 100% sure yet what the best design could be to allow time_capsule.freeze…().await calls at the top-level. Searching for literal occurrences of “time_capsule” seems tedious (and not even necessarily sound in the presence of other macros that could piece together such an identifier; though I’d need to double check what guarantees / protection hygiene could offer). Having a helper macro available (or defined) inside of the async block might be able to once again couple the call with the .await, but does little to enforce this top-level-ness, either.
Perhaps, ultimately, the outer macro would need to generate the .freeze().await/.freeze_forever().await calls itself. A minimally flexible (but maximally simple) API would just name have you name an identifier foo and have the macro insert a time_capsule. Ultimately I think there are many ways to structure such a macro, with different levels of difficulty in terms of parsing the contents of a block, and different flexibility of API that can be offered.

Oh, I’m having some interesting macro ideas now…

Just a thought, could we make the situation better by marking the FrozenFuture as !Unpin?
A !Unpin future cannot be poll!ed. Now, that's not sufficient, because one could just Box::pin the FrozenFuture, but that's a step in a desirable direction: make it unsound to pin the FrozenFuture by anyone else than the top-level executor.

Oh, I’m having some interesting macro ideas now…

use nolife::Family;
use std::marker::PhantomData;

struct SingleFamily<T: 'static>(PhantomData<T>);
impl<'a, T: 'static> Family<'a> for SingleFamily<T> {
    type Family = T;
}

macro_rules! scope {
    {$($t:tt)*} => {{
        ::nolife::BoxScope::new(|mut time_capsule: ::nolife::TimeCapsule<SingleFamily<String>>| async move {
            'check_freeze_scope: {
                #[allow(unused_macros)]
                macro_rules! freeze {
                    ($e:expr) => {{
                        #[allow(unreachable_code)]
                        if false {
                            break 'check_freeze_scope (loop {});
                        }
                        ::nolife::TimeCapsule::freeze(&mut time_capsule, $e).await
                    }};
                }
                #[allow(unused_macros)]
                macro_rules! freeze_forever {
                    ($e:expr) => {{
                        #[allow(unreachable_code)]
                        if false {
                            break 'check_freeze_scope (loop {});
                        }
                        ::nolife::TimeCapsule::freeze_forever(&mut time_capsule, $e).await
                    }};
                }
                {
                    $($t)*
                }
            }
        })
    }}
}

fn main() {
    let mut sc = scope! {
        let mut x = String::from("Hello World!");
        let _fut = async {
            // freeze!(&mut x); // usage in nested future errors
            #[allow(unused_labels)]
            'check_freeze_scope: {
                // freeze!(&mut x); // even here, thanks to hygiene
            }
        };

        freeze_forever!(&mut x)
    };
    sc.enter(|s| {
        println!("{s}");
    })
}

In case you don’t want to include the BoxScope::new call with the macro, e.g. to also allow for alternative choices like ::pin, then you could have scope! return some ScopeProducer<P> wrapper that’s otherwise unsafe to construct, and make new and pin expect such a wrapped producer: ScopeProducer<P> instead of producer: P as argument.

Hmmm, that looks like a very smart solution, I also like the resulting interface a lot! I really, truly, appreciate you taking of reviewing this crate and providing helpful solutions this way :heart:
Am I correct that this obviously limits the ability to factor the scope in multiple functions?
Consider a more complex example including error handling like this gist. Do we need to write macros for subscopes now :D ?

(I haven’t tested to what extend replacing the ::nolife prefixes with $crate:: works for macros defined inside of macros, or whether $crate then refers to the using crate, not to nolife itself).

I just tested this: $crate resolves to the crate of the outer macro definition, meaning you can use $crate everywhere in your macro definitions there, even the inner macros, and it will do the right thing (e.g. resolve to nolife).

Consider a more complex example including error handling like this gist. Do we need to write macros for subscopes now :D ?

I wonder if there’s a way to create some PropagatePendingToScope<F> wrapper for futures. And a macro to create an async block in which other PropagatePendingToScope<F> blocks could be executed. And the scope takes a TimeCapsule<…> -> PropagatePendingToScope<F> argument, whereas freeze isn’t an async fn but an fn(…) -> PropagatePendingToScope<impl Future<…>>.
I think that doesn’t prevent “time capsule juggling” where you could smuggle the time capsule of an outer scope into an inner scope, in order to write to it (to the outer scope) without propagating the Pending after all. This in turn could probably be solved by introducing a unique invariant lifetime, in order to tag both the TimeCapsule and the PropagatePendingToScope so that they must always correspond.
I don’t have the time today to turn this into a concrete implementation, but I believe it could possibly be sound (and not much worse in UX than the macros above), whilst allowing factoring out helper functions as desired.

Alright I think I'm starting to see a bit clearer how that would work at multiple levels.

At the top level there is a BoxScope::new(ScopeProducer<P>).
The scope! macro accepts a tt and turns it into a ScopeProducer.
In the scope! macro, you get 3 superpowers:

freeze!(e) that checks it is not in an inner future using your scope trick, then TimeCapsule::freeze(&mut input_time_capsule, $e)
freeze_forever!(e), same but wrapped in a loop.
sub_scope!(e), that checks it is not at a lower level, checks that e is a ScopeProducer and then unwraps it and awaits it.

Would that work? I'm not sure we need to brand the timecapsule with a tag lifetime, because in this variant it remains implicit to the scope! and sub_scope! macro, so can't be snuggled.
I have an implementation in #11, but in a very rough state.

readme, docs, counterexamples to update
I would like to try porting the gist linked above
Naming gets confusing because I introduced yet another type called Scope (the result of the scope! macro)
That type should probably have a trait counterpart so that the signature of BoxScope::new become S: Scope rather than `Scope<??P??,

3. sub_scope!(e), that checks it is not at a lower level, checks that e is a ScopeProducer and then unwraps it and awaits it.

Ah, wrap the whole producer and never expose the actual time_capsule variable, that might work, I’ll think about this (no earlier than) tomorrow.

I would like to try porting the gist linked above

There’s likely going to be some “fun extra challenge” in the form of getting the impl Future to capture the lifetime of the &mut TimeCapsule when writing the signature of e.g. zip_files.

Oh… that doesn’t even work at all:
use core::future::Future;

struct Wrap<P>(P);
struct Capsule;

enum Never {}

fn f(x: String) -> Wrap<impl for<'a> FnOnce(&'a mut Capsule) -> (impl Future<Output = Never> + 'a)> {
    Wrap(|t: &mut _| async move {
        let _x = t;
        async {}.await;
        loop {}
    })
}

error[E0562]: `impl Trait` is not allowed in the return type of `Fn` trait bounds
 --> src/lib.rs:8:66
  |
8 | fn f(x: String) -> Wrap<impl for<'a> FnOnce(&'a mut Capsule) -> (impl Future<Output = Never> + 'a)> {
  |                                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `impl Trait` is only allowed in arguments and return types of functions and methods
  = note: see issue #99697 <https://github.com/rust-lang/rust/issues/99697> for more information
  = help: add `#![feature(impl_trait_in_fn_trait_return)]` to the crate attributes to enable
  = note: this compiler was built on 2024-03-02; consider upgrading it if it is out of date

For more information about this error, try `rustc --explain E0562`.
error: could not compile `playground` (lib) due to 1 previous error

and even with the nightly feature…
error: higher kinded lifetime bounds on nested opaque types are not supported yet
 --> src/lib.rs:9:96
  |
9 | fn f(x: String) -> Wrap<impl for<'a> FnOnce(&'a mut Capsule) -> (impl Future<Output = Never> + 'a)> {
  |                                                                                ^^
  |
note: lifetime declared here
 --> src/lib.rs:9:34
  |
9 | fn f(x: String) -> Wrap<impl for<'a> FnOnce(&'a mut Capsule) -> (impl Future<Output = Never> + 'a)> {
  |                                  ^^

So either use dyn Future, or it’s probably better to try wrapping not the closure but just the future, and using lifetimes to enforce the connection.

and even with the nightly feature…

Ah, the closure needn’t be generic over the lifetime, I suppose… so at least on nightly this actually compiles:
#![feature(impl_trait_in_fn_trait_return)]
use core::future::Future;

struct Wrap<P>(P);
struct Capsule;

enum Never {}

fn f<'a>(x: String) -> Wrap<impl FnOnce(&'a mut Capsule) -> (impl Future<Output = Never> + 'a)> {
    Wrap(|t| async move {
        let _x = t;
        async {}.await;
        loop {}
    })
}

but that doesn’t help stable much, still.

Wait… wait!… a trait can help, actually!
use core::future::Future;

struct Wrap<P>(P);
struct Capsule;

enum Never {}

trait Producer<'a>: FnOnce(&'a mut Capsule) -> Self::Fut {
    type Fut: Future<Output = Never>;
}
impl<'a, P: ?Sized, Fut> Producer<'a> for P
where
    P: FnOnce(&'a mut Capsule) -> Fut,
    Fut: Future<Output = Never>,
{
    type Fut = Fut;
}

fn f<'a>(x: String) -> Wrap<impl Producer<'a>> {
    Wrap(|t| async move {
        let _x = t;
        async {}.await;
        loop {}
    })
}

And the way to write a function with additional lifetime-having arguments would probably look something like this
use core::future::Future;

struct Wrap<P>(P);
struct Capsule;

enum Never {}

trait Producer<'a>: FnOnce(&'a mut Capsule) -> Self::Fut {
    type Fut: Future<Output = Never>;
}
impl<'a, P: ?Sized, Fut> Producer<'a> for P
where
    P: FnOnce(&'a mut Capsule) -> Fut,
    Fut: Future<Output = Never>,
{
    type Fut = Fut;
}

fn f<'prod, 'a: 'prod, 'b: 'prod>(x1: &'a str, x2: &'b str) -> Wrap<impl Producer<'prod>> {
    Wrap(move |t| async move {
        let _x = t;
        let _y1 = x1;
        let _y2 = x2;
        async {}.await;
        loop {}
    })
}

Yes that's similar to what I had in mind (but I think the Wrapper itself should implement the trait, so that we can have a(n unsafe) trait function to inject the time capsule).
Basically as long as we can't name a lambda/future type, this is going to be pain.
The closest to the finish line seems to be ATPIT, so hopefully in a few Rust versions we're going to have a much more ergonomic way of expressing this API :smiley:

Hello,
I updated #11 and it now contains a Scope trait that allows erasing the inner type more easily.
I hope the syntax isn't too alien :disappointed_relieved:
Using this new syntax, the more complex example that uses subscopes now looks like this
I still need to update the counterexamples and add your counterexample to the mix (not sure how, now that we cannot access a TimeCapsule directly)

You sure are working this out quickly. I'll try to review #11 tomorrow.


composer install

I'm using the advanced extended template where all sources are held in _protected and therefore the vendor folder is _protected/vendor.
Your composer definition is trying to install into just /vendor and is therefore not accessible to any of the source code.
Is this due to the Type: yii2-extension
rather than type: library that most other extensions seem to use?

Do not understand. How can type affect of installation? You some kind of modified installation process?
p.s. I'm sorry for the long answer. Missed notice.

Hi Revin
Actually, I figured out the problem.  I’ve been using the Advanced enhanced Yii template which puts the vendor directory under _protected/vendor but I did not update my composer.json, which was still pointing to /vendor.
Thanks for your reply
Chris

On 2 Dec 2015, at 17:01, Revin Roman<EMAIL_ADDRESS>wrote:
Do not understand. How can type affect of installation? You some kind of modified installation process?
p.s. I'm sorry for the long answer. Missed notice.
—
Reply to this email directly or view it on GitHub https://github.com/rmrevin/yii2-minify-view/issues/23#issuecomment-161344830.

I am pleased that the problem was solved.


Failing installation to GKE driver ver 440.64

Hey, I tried to install new version of nvidia driver but got next:
COS_DOWNLOAD_GCS=https://storage.googleapis.com/cos-tools
+ COS_KERNEL_SRC_GIT=https://chromium.googlesource.com/chromiumos/third_party/kernel
+ COS_KERNEL_SRC_ARCHIVE=kernel-src.tar.gz
+ TOOLCHAIN_URL_FILENAME=toolchain_url
+ TOOLCHAIN_ARCHIVE=toolchain.tar.xz
+ TOOLCHAIN_ENV_FILENAME=toolchain_env
+ TOOLCHAIN_PKG_DIR=/build/cos-tools
+ CHROMIUMOS_SDK_GCS=https://storage.googleapis.com/chromiumos-sdk
+ ROOT_OS_RELEASE=/root/etc/os-release
+ KERNEL_SRC_DIR=/build/usr/src/linux
+ NVIDIA_DRIVER_VERSION=440.64
+ NVIDIA_DRIVER_MD5SUM=
+ NVIDIA_INSTALL_DIR_HOST=/home/kubernetes/bin/nvidia
+ NVIDIA_INSTALL_DIR_CONTAINER=/usr/local/nvidia
+ ROOT_MOUNT_DIR=/root
+ CACHE_FILE=/usr/local/nvidia/.cache
+ LOCK_FILE=/root/tmp/cos_gpu_installer_lock
+ LOCK_FILE_FD=20
+ set +x
[INFO    2020-05-27 21:20:11 UTC] PRELOAD: false
[INFO    2020-05-27 21:20:11 UTC] Checking if this is the only cos-gpu-installer that is running.
[INFO    2020-05-27 21:20:11 UTC] Running on COS build id 12371.175.0
[INFO    2020-05-27 21:20:11 UTC] Checking if third party kernel modules can be installed
[INFO    2020-05-27 21:20:11 UTC] Checking cached version
[INFO    2020-05-27 21:20:11 UTC] Did not find cached version, building the drivers...
[INFO    2020-05-27 21:20:11 UTC] Downloading GPU installer ...
/usr/local/nvidia /
[INFO    2020-05-27 21:20:11 UTC] Downloading from https://storage.googleapis.com/nvidia-drivers-us-public/tesla/440.64/NVIDIA-Linux-x86_64-440.64.run
/
ls: cannot access '/build/usr/src/linux': No such file or directory
[INFO    2020-05-27 21:20:11 UTC] Kernel sources not found locally, downloading
[INFO    2020-05-27 21:20:11 UTC] Kernel source archive download URL: https://storage.googleapis.com/cos-tools/12371.175.0/kernel-src.tar.gz
/build/usr/src/linux /
/
/build/usr/src/linux /

real	0m0.694s
user	0m0.178s
sys	0m0.334s
/
[INFO    2020-05-27 21:20:18 UTC] Setting up compilation environment
[INFO    2020-05-27 21:20:18 UTC] Obtaining toolchain_env file from https://storage.googleapis.com/cos-tools/12371.175.0/toolchain_env

real	0m0.025s
user	0m0.016s
sys	0m0.002s
[INFO    2020-05-27 21:20:18 UTC] /build/cos-tools: bin
lib
toolchain.tar.xz
usr
[INFO    2020-05-27 21:20:18 UTC] Found existing toolchain package. Skipping download and installation
[INFO    2020-05-27 21:20:18 UTC] Configuring environment variables for cross-compilation
[INFO    2020-05-27 21:20:18 UTC] Configuring installation directories
/usr/local/nvidia /
[INFO    2020-05-27 21:20:18 UTC] Updating container's ld cache
/
[INFO    2020-05-27 21:20:18 UTC] Configuring kernel sources
/build/usr/src/linux /
/bin/sh: 1: x86_64-cros-linux-gnu-clang: Permission denied
  HOSTCC  scripts/basic/fixdep
/bin/sh: 1: x86_64-cros-linux-gnu-clang: Permission denied
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --olddefconfig Kconfig
./scripts/gcc-version.sh: 26: ./scripts/gcc-version.sh: x86_64-cros-linux-gnu-clang: Permission denied
./scripts/gcc-version.sh: 27: ./scripts/gcc-version.sh: x86_64-cros-linux-gnu-clang: Permission denied
./scripts/gcc-version.sh: 29: ./scripts/gcc-version.sh: x86_64-cros-linux-gnu-clang: Permission denied
./scripts/gcc-version.sh: 26: ./scripts/gcc-version.sh: x86_64-cros-linux-gnu-clang: Permission denied
./scripts/gcc-version.sh: 27: ./scripts/gcc-version.sh: x86_64-cros-linux-gnu-clang: Permission denied
./scripts/gcc-version.sh: 29: ./scripts/gcc-version.sh: x86_64-cros-linux-gnu-clang: Permission denied
init/Kconfig:17: syntax error
init/Kconfig:16: invalid option
./scripts/clang-version.sh: 15: ./scripts/clang-version.sh: x86_64-cros-linux-gnu-clang: Permission denied
./scripts/gcc-plugin.sh: 11: ./scripts/gcc-plugin.sh: x86_64-cros-linux-gnu-clang: Permission denied
make[1]: *** [olddefconfig] Error 1
scripts/kconfig/Makefile:69: recipe for target 'olddefconfig' failed
make: *** [olddefconfig] Error 2
Makefile:531: recipe for target 'olddefconfig' failed

I use this manifest
https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/nvidia-driver-installer/cos/daemonset-preloaded.yaml

Have you had any luck with this?

(In case anyone comes across the same problem)
Solved it by updating the image to gcr.io/cos-cloud/cos-gpu-installer@sha256:8d86a652759f80595cafed7d3dcde3dc53f57f9bc1e33b27bc3cfa7afea8d483:
kubectl patch daemonset nvidia-driver-installer --namespace kube-system --patch '{"spec":{"template":{"spec":{"initContainers":[{"name":"nvidia-driver-installer","image":"gcr.io/cos-cloud/cos-gpu-installer@sha256:8d86a652759f80595cafed7d3dcde3dc53f57f9bc1e33b27bc3cfa7afea8d483","imagePullPolicy":"IfNotPresent","env":[{"name":"NVIDIA_DRIVER_VERSION","value":"450.51.06"}]}]}}}}'


Incorrect setup instruction in the Readme file

The Readme file instructions do not work, links do not work like in Step 3, the current documentation does not have instructions about Web API.

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

ID: 976c73ce-6915-43a0-d862-2c05465341f8
Version Independent ID: f4f562c1-8a77-4e36-4815-14533492e52d
Content: Quickstart: Set up sign-in for an ASP.NET web app - Azure AD B2C
Content Source: articles/active-directory-b2c/quickstart-web-app-dotnet.md
Service: active-directory
Sub-service: b2c
GitHub Login: @kengaderdus
Microsoft Alias: kengaderdus

@dulfe
Thanks for your feedback! We will investigate and update as appropriate.

Hi @dulfe,
Thank you for your feedback and patience. The article Quickstart: Set up sign in for an ASP.NET application using Azure Active Directory B2C intends to give you a quick feel of how app authentication looks like with Azure AD B2C. I've reviewed and everything works as expected.
If the instructions in the sample app repository's README file aren't clear, please raise an issue against the repository (https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi) itself, and it'll be resolved.
Thanks

#please-close

@dulfe
I see and sorry about that. Can you please raise an issue against the repository (https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi) itself.


SAML updates

Rename SSO page
Add SSO page as required reading for integration guides
Edit guides

Signed-off-by: bermudezmt<EMAIL_ADDRESS>
Proposed changes

Unreleased product version (optional)

Related issues (optional)
Relates to #1322

@joeduffy @ericrudder would love your eyes on http://content-bucket-1ddffb8.s3-website-us-east-1.amazonaws.com/docs/guides/ as I suspect you can "fluff" the text up. :smile:

This should address #1608 as well.


feature: Merge extra input attributes

RichEditor doesn't have this?
Is there any way currently I can tell trix to use ring-primary-400 instead of ring-primary-500?

Its being introduced gradually as people need it, feel free to PR it in for the rich editor.


docs: fix example pvecsictl cloud-config

Pull Request

What? (description)
Added region to example usage docs of pvecsictl
Why? (reasoning)
Using current example without region variable causes error:
ERROR Error: failed to read config: cluster #1: region is required

Adding variable fixes that error
Acceptance
Please use the following checklist:

[ ] you linked an issue (if applicable)
[ ] you included tests (if applicable)
[ ] you ran conformance (make conformance)
[ ] you linted your code (make lint)
[ ] you linted your code (make unit)

See make help for a description of the available targets.

Hello, can you add Commit Body and we will merge it )
Thanks 👍

Sure, but I didn't have this problem yet. Can I do this without local clone, via github editor or something? I'm not at git 😅

Thanks 👍


WebSpoon does not show the run options for server or cluster.

WebSpoon does not show the run options for server or cluster.
At first, I should admit WebSpoon is really what I dream!  Thanks a lot.
I can not find  run options with run with remote server, or clusters.  but according to the 11th PPT in
https://www.slideshare.net/HiromuHota/handson-demo-of-pdi-using-webspoon, webspoon has the function. By the way, I have use the Spoon for many years.
the version i build with docker is <IP_ADDRESS> , and my environments are:

OS (e.g., Mac OS X 10.12.3):
Browser (e.g., Google Chrome & Safari)

Thanks again.

Seems like you figured it out on your own, but for those who have the same question, I'll post my answer below.
Pentaho introduced the concept of "Run Configuration" at 7.1 before when the slide deck was created. http://pedroalves-bi.blogspot.com/2017/05/pentaho-7.1.html
By default, only a Run Configuration for local is available.
You have to manually create a Run Configuration for a remote server and/or clusters.


contains.text() fails when text is there

So I usually use text() to see if a string exists in output.
This time, it doesn't work:
it.only('contains filters', () => {
    headerSearch.find('.sh-filter').simulate('click');
    expect(headerSearch.find('.ft-search-filter').text()).to.contain('Most Recent');
    expect(headerSearch.find('.ft-search-filter').text()).to.contain('Full Episode');
});

When I debug in WebStorm I see that headerSearch.find('.ft-search-filter').text() outputs Most RecentMost RecentFull EpisodeAll (A-Z)Action.  But not sure why this would fail as Full Episode is clearly there.
Then I read about text() more and it says:

Returns a string of the rendered text of the current render tree. This function should be looked at with skepticism if being used to test what the actual HTML output of the component will be. If that is what you would like to test, use enzyme's render function instead.

Hmm so should I use render here?  I don't think so because I get the output I expect in the find, but it's all one string.  This is finding all the text of each item in a dropdown basically and somehow concats each list item's value into one string above...

Hey, @dschinkel! If .text() is outputting the expected result then the issue isn't likely with Enzyme. What exactly is the error you're getting? What assertion library are you using?

Damn it.  It works.  rubber ducking again.  I swear when I ran my test last it failed.  Sorry.


Add a test runner in module mode

The current analyzer only support GOPATH-style set-up.
As highlighted in https://github.com/golang/go/issues/37054, this is an issue especially when writing modules against local packages.
This changes introduces a new function that does not force a GOPATH set-up.

Closing in favor of https://go-review.googlesource.com/c/tools/+/318709 .


Reaper Dawntrail Rotation issues

1 - Rotation does not include PERFECTIO when all conditions are met (Plentiful Harvest+Communio used)
2 - Rotation does not Prioritize EXECUTIONERS (Gallows/GIBBET - Guillotine) when Gluttony is used Which is respectively 200 potency HIGHER then base (500).

Also noticed it does not seem to prioritize applying Deaths Design

Looks like its doing soul slice and discarding the gibbet/gallows executioner following Gluttony

Fixed in #21


class methods vs. instance methods

Hi,
currently am trying to set up a connection between the renderer and main process, in particular sending an async event from renderer to main process. Calling Ipc.send seems to work fine, but how to add the listener to that class for the callback since 'on' and 'addListener' are instance methods?
Trying to add a constructor function to the ipc class and instantiate the ipcrender results in an error.
Thanks in advance!
Best
Chris

I found a work around for it, which is basically the same stuff which is done in hxnodejs. To get around the issue that you have to deal with some instance and class methods, i created a helper class for the required modules which has static class members. An example can be found below:
@:native("global) extern class Electron {    static var ipcRenderer(get,never):Ipc;    private static inline function get_ipcRenderer():Ipc return untyped __js__("require(\"electron\").ipcRenderer");
Additionally i removed the static keyword for the functions 'send', 'sendSync' and sendToHost which is not needed. You are able to use the ipcRenderer module by Electron.ipcRenderer.
I read about the other issue which was mentioned #17 regarding the jsRequire and inheritance. I think by using this kind of helper class, you can easily define another static member with another code require injection and you are fine, e.g.
`
@:native("global)
extern class Electron {
static var ipcRenderer(get,never):Ipc;
private static inline function get_ipcRenderer():Ipc return untyped js("require("electron").ipcRenderer");
static var ipcMain(get,never):Ipc;
private static inline function get_ipcMain():Ipc return untyped js("require("electron").ipcMain");
`
So you are not using the @:jsRequire of the Ipc class (which could be removed if you didn't use them directly), instead you define your import here. Didn't tested it but i think i should work fine. :)


Frame.pdu_* properties should be considered for a tuple

[x ] This contribution adheres to CONTRIBUTING.md.
[ ] New tests have been created for any new features or regression tests for bugfixes.
[x ] tox successfully runs, including unit tests and style checks (see CONTRIBUTING.md).

TODO: Check the above boxes with an 'x' to indicate what steps you have taken in preparing this Pull Request.
What does this Pull Request accomplish?
This PR implements issue #53  by removing the pdu_* properties with a single pdu properties. The old interface required parallel lists, this implementation uses a single list of namedtuples.
Why should this Pull Request be merged?
#53
What testing has been done?
I tested this with my CAN device by creating a PDU that met the requirements of PDUs Required?. I verified I could configure and take measurements without any warnings. If I didn't conform to PDUs required, I got either a warning or error depending on the case.

Since CAN/LIN currently only supports a subset of PDU features (one PDU per frame, a start bit of 0, and an update bit of -1), an alternative implementation would be to only have a pdu_ref function which takes a PDU item. We could assume the start bit of 0 and update bit of -1. However, this would be a departure from the XNET C interface, and we'd need to switch back to something like namedtuples if CAN/LIN ever supported more types of PDUs.

Coverage increased (+9.5%) to 68.172% when pulling f52ce6c08d7defb9f72fb05a40dab1d91db3aec0 on trstamper:pdu into 4004cd38d60fbe8e73d90b4b906b0497a56676bb on ni:master.

Coverage increased (+9.5%) to 68.172% when pulling f52ce6c08d7defb9f72fb05a40dab1d91db3aec0 on trstamper:pdu into 4004cd38d60fbe8e73d90b4b906b0497a56676bb on ni:master.

Updated review to address comments.

Updated description to add BREKAING CHANGE tag

For future reference, you can add Fixes #issue in the commit description and it will automatically close the issue when the commit is pulled into mainline.


Interface robustness improvments

Very small PR that removes the assumption on the order of the dimensions in TimeData and DenseData thagt was hard-coded to t,x,y,z

This fixes part of the problems of #337

OK this needs to be rebased on latest master (many things can now be dropped, I think, as part of the latest bug fixes in master). Then we can start thinking about how to improve it

As agreed with @FabioLuporini I will put back mandatory time as first dimension as the loop scheduling is too messy to handle with random dimensions ordering

Ok, for discussion's sake, I'm not a fan of hard-coding all the "space dimensions" specifically either, but as long as we have no clear abstractions to separate Time/Space/Misc dimensions there is little we can do. This sort of separation has a long dependency chain as well though, since it directly affects how we sanity-check and default things should we ever build a generic "grid" abstraction. In fact, I think the two features are very tightly coupled, since a grid can only ever provide/check/know about "space dimensions", while things like time and misc should be optional additions for individual fields. Just my 2 cents' worth though...

which is why there is a new test.

I cannot find it

This PR is touching a piece of code that was already quite awful

Let's make it clear, this piece of code is not supposed to be pretty CS, it is supposed to be the math link between Devito and whatever people want to do with it.

What features are you exactly trying to get

Not enforcing our specific setup to any PDE people may want to solve

WHy do you need a time dimension different than t/time

I don't there is just no way to know wether it's time or t, we can force it to be one or the other

this needs to be rebased on master

It;s like 5 times less commits than most of you guys PR, common

it is supposed to be the math link between Devito and whatever people want to do with it

so it's even more important

Not enforcing our specific setup to any PDE people may want to solve

Concrete examples would be useful so that I can understand what generalisation you are looking for. Is it just to allow people to use dims different than x/y/z ?

It;s like 5 times less commits than most of you guys PR, common

It's not that. Being on top of master makes the diff simpler to read

Is it just to allow people to use dims different than x/y/z
no just to allow any order including time

so it's even more important
It's important to be readable for non-CS people, not fancy

It's not that. Being on top of master makes the diff simpler to read

only diff is interfaces and the laplacian in the test, waste of time for the exact same diff

It's important to be readable for non-CS people, not fancy

Yeah, I should stop making observations only to make the code fancier :)

@mloubout and I discussed about this offline and we agreed this needs first a wider discussion with the rest of the development team to be done properly

Needs a fresh start from recent updates, closing.


doppyo for climpred

all metrics in skill.py work with xr.DataArray and xr.Datasets as input and return the same: if previously xr.dataset with multiple data_vars was created now moved to new dimension
add runthrough tests as in docstring
diagnostics.py only imports as extra dependencies

closes #1

further steps:

enable travis ci
check how tutorials under bin are modified due to this PR
check possibility to use xhistogram https://github.com/xgcm/xhistogram or xrft https://github.com/xgcm/xrft

All of doppyo's skill metrics are being ported to xskillscore, with the changes requested/implemented here being made in the process (https://github.com/raybellwaves/xskillscore)


Bug Report: No "Needs Voices" option on the new chart system.

This is pretty self explanatory, as there is no Needs Voices option for charts, songs like tutorial always try to load in Voices.ogg.
[ X ] Windows
[ X ] Linux
[ ] Mac
Image of the engine trying to load in Voices.ogg in a voiceless song

Also another thing i find weird is the incapability of opening the chart editor, but i assume that's related to the chart system still being re-made so Yoshi will probably remake the chart editor when he finishes it, just wanted to leave that note here

This should be fixed with ae01d8ae8390c7effec58375ca85e64df156454f, if it isnt, please reopen this issue


potential broken test workaround for RekeyTest

there's little risk here
this might fix the broken test on windows when the clock is bad
CC: @zanderz and @jzila

Unsure of the context/import, but LGTM - test looks better so far at https://ci.keyba.se/job/client/job/PR-5014/ :thumbsup:


Please merge revision #4ad37a6 into dev channel

@ricowind @whesse @kasperl
Fixes #23853: a dart2js bug with deferred loading where a type was put in the wrong hunk because the main program only used it in a type argument. This breaks angular1 apps that use DI + codegeneration + deferred loading.
I was able to cherry-pick 4ad37a6107fac443b5229713e4a56fbd66f1b6d5 into dev cleanly.

This is not merged by itself, but it is in 1.12.0-dev.4.0 so marking this as fixed


Allow manual suspension of window state saving

For if you'd like to take control of the window's position and no longer wish to have its state managed.
I.e. window is a fixed-size in a specific state, but resizable in another state.

Thanks for the contribution. Happy to add this 😄

Thanks for making!


Improve code completion for Zoomy's contextual types

When you type
Zoomy.
it should give autocompletion options for:

Delegate
Settings
ContentState
Action

Closed in This commit


Feature Request: option to update source code with generated methods.

Would be great if there was an option to make lombok, on each compile, actually save the generated methods in the source code. I prefer being able to read the methods that exist for a certain class, but I hate writing the boilerplate. there are generators that help with this, but I forget to run them.
It would be great if lombok could be configured to generate boilerplate according to annotations(as it already does), but then actually update the source code with that boilerplate.
This would mitigate the one common argument I hear against using lombok.

Disclaimer: Not a member of the lombok team, just an interested observer.
That being said:
This sounds sensible .. but it really isn't.

Generated code is not going to be readable. It was never meant to be.

If there is some kind of bug in that generated code, how are you going to
know, and how are you ever going to update?
Once it's generated, changing it becomes your problem, whereas if it is
done on the fly you can keep your source current with the latest lombok.

If it's customised in some manner, whomever reads it later is not going
to know unless it is very well documented (in the source code itself).

If you are going to do this the next logical step would be to also put
the generated code for jackson annotations, spring annotations, hibernate
annotations, and mockito annotations inside the class itself. Ditto for
generated proxies. And while we're at it, we probably should get rid of the
concept of interfaces altogether and just put implementations everywhere...
see where this is going?

Examining the generated code is easily possible using delombok or any other
decompiler. Feel free to do so, but making it the preferred form for
modifications .. that way lies insanity.
On Thu, Sep 6, 2018 at 1:33 PM Anders Martini<EMAIL_ADDRESS>wrote:

Would be great if there was an option to make lombok, on each compile,
actually save the generated methods in the source code. I prefer being able
to read the methods that exist for a certain class, but I hate writing the
boilerplate. there are generators that help with this, but I forget to run
them.
It would be great if lombok could be configured to generate boilerplate
according to annotations(as it already does), but then actually update the
source code with that boilerplate.
This would mitigate the one common argument I hear against using lombok.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1854, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRWxyp2LtQ5hDliowZwINxvGgh7Elks5uYQfugaJpZM4WcwEG
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

@randakar generated methods could, for example, be annotated with a @generated annotation, and so lombok could regenerate it on next compile, and update as needed. Also this way if you want to change some behaviour in a generated method, you'd just have to remove the said annotation and lombok would not overwrite it .
about readabillity of generated methods, I'm sure that could be mitigated. (this request just doubled in size though...)
At least now people cant complain that your code wont compile unless you have a compilator plugin (which is a valid concern, methinks)
about the "logical next steps" you talk about, I disagree that they are logical next steps at all, and even if they were, it wouldn't be an argument against this particular step :)

Disclaimer: another interested observer here.
@andersmartini This might be somewhat useful, however:

Would you expect a compiler to mess with your sources?
What if you have unsaved changes in your editor?
For this to be useful, you'd need a plugin for your IDE, otherwise you can just add a few lines to your gradle/maven/whatever build file calling delombok.
The generated code may be long, so it's easy to miss the @Generated annotation and edit it by mistake.
Lombok uses the annotation processor API and there's no support for overwriting the sources there.

Most people don't want to read the generated code. Personally, I'm happy, it's not there. I'd be even more happy, if there was an option to hide it from the outline (or gray it out).

At least now people cant complain that your code wont compile unless you have a compilator plugin (which is a valid concern, methinks)

Not really. With my source code, all you need is javac and gradle. Lombok gets downloaded the same way as the other 20+ dependencies. Sure, for an IDE, you need to do something (e.g., java -jar $(find ~/.gradle -name 'lombok*.jar') ).

Ok, the generated annotation makes that case a little better.
I still think it is not going to help readability, and it's not just about
how readable the generated bits are. The fact that that code shows up at
all already increases the cognitive load necessary trying to understand the
class in question.
The whole reason Lombok exists in the first place is as a way to showcase
features the java language could have - but isn't. It's not about
generating code at all. If it was the compiler doing this, would you still
want to see what it was generating? Even if it's the generated bytecode?
Because that's the level we're talking about here.
If at some point in the future the Lombok implementation changed to
generate bytecode directly, or lean on new compiler features, or change in
another way, and it has this feature, this could complicate matters. I know
delombok exists but still, the less the internal implementation is visible
the better.
Op do 6 sep. 2018 16:07 schreef Maaartinus<EMAIL_ADDRESS>
Disclaimer: another interested observer here.
@andersmartini https://github.com/andersmartini This might be somewhat
useful, however:

Would you expect a compiler to mess with your sources?
What if you have unsaved changes in your editor?
For this to be useful, you'd need a plugin for your IDE, otherwise
you can just add a few lines to your gradle/maven/whatever build file
calling delombok.
The generated code may be long, so it's easy to miss the @Generated
annotation and edit it by mistake.
Lombok uses the annotation processor API and there's no support for
overwriting the sources there.

Most people don't want to read the generated code. Personally, I'm happy,
it's not there. I'd be even more happy, if there was an option to hide it
from the outline (or gray it out).
At least now people cant complain that your code wont compile unless you
have a compilator plugin (which is a valid concern, methinks)
Not really. With my source code, all you need is javac and gradle. Lombok
gets downloaded the same way as the other 20+ dependencies. Sure, for an
IDE, you need to do something (e.g., java -jar $(find ~/.gradle -name
'lombok*.jar')).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1854#issuecomment-419106276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRY7vGaUpI37cseH5gUznqBXxrOj0ks5uYSwdgaJpZM4WcwEG
.

No, we're not going to generate source code.


Release Candidate for 1.0.0 (RC1)

Changes

Adjusted naming of hack_merge variable
Added information to the deprecation warning
Adjusted the deprecation to be fired last after the final hook (so it is easily noticed)
More tests to assure we avoid breaking changes to the CLI params and arguments

Features

A new set-values: {} key in the chart config to use for settings --set for helm

Deprecation Notice
In the future, the values: {} configuration of a chart will change it's
behavior (see Issue #7). The current behavior translates any values:{} into
--set for the command line helm. This makes certain object types lose their
type fidelity. This means true becomes string("true") when pushed through
--set values=true. To maintain the same behavior for your settings please
change values:{} to set-values:{}. This behavior deprecaton will start to
be enforces in later versions of Reckoner.

Previous discussion located here: https://github.com/reactiveops/reckoner/pull/56


How could I set 'json ensure_ascii = false' when resp.media is Japanese or Chinese?

When resp.media = {'error': '错误的数据类型'}, I'll get {"error":  "\\u9519\\u8bef\\u7684\\u6570\\u636e\\u7c7b\\u578b"}. I know I should set json ensure_ascii = false in json.dumps, but I don't know how to do that in responder.
like that:
@api.route('/{errorcode}')
async def error(req, resp, *, errorcode):
    resp.media = {
            'errorcode': errorcode,
            'message': '错误的数据类型'
    }

Sorry about my English, I really not good at that.
Thanks a lot!

https://github.com/kennethreitz/responder/blob/00211c8f03b24b19aeb70a855d84fab298f0ae9a/responder/formats.py#L24
You'd have to redo that function I guess..

responder/responder/formats.py
Line 24 in 00211c8
async def format_json(r, encode=False):
You'd have to redo that function I guess..

Thanks for your reply!
Actually, I did this:
async def format_json(r, encode=False):
    if encode:
        r.headers.update({"Content-Type": "application/json"})
        return json.dumps(r.media, ensure_ascii=False)
    else:
        return json.loads(await r.content)

api = responder.API(secret_key=os.urandom(16))
api.formats['json'] = format_json

It works well.
I think it is excellent that if there is a more "official" solution in the future.


Sonoff Issue - when it "reloads"

Hi All,
not sure why but everytime Sonoff on my home assistant "reloads" or connects to the cloud for something it reloads the modules and then automation related to get triggered.
So for example I have Home Assistant notify me when the gate opens, or my sonoff bridge has buttons on a remote that switches on and off lights.
So every now and again - I am finding for some reason sonoff integration is "reloading" or doing something, then it updates and checks state or activates all the buttons on my remote on the sonoff RF433 brifge - causing my lights to go on and off... and for me to get false notifications. Some of my sonoff smart breakers go off and on as well which causes other issues. IF I remove Sonoff from HA the problem goes away but then I have to manage items outside of HA which defeats the purpose of why I put these in.
How can I fix this.
WIFI - good - and I have reconnected and replace WIFI
Interenet is excellent - 1GB Fibre line and its has no issues.
HA - is up to date
All the Sonoff devices has the latest firmware
Sonoff integration on HA seems to be the latest.
Any help would be appreciated.

I am having the same issue. The state of the bridge changes to unavailable then each button paired to the bridge changes to unavailable then the buttons change to unknown. Shortly after the bridge changes to "on".
it's during this cycle that the automation triggers. I have my automation disabled because of this problem otherwise I'd have been able to capture it. My automation is related to training my dogs so to have it falsely trigger causes a problem so I'm reluctant to enable it again.

Same issue here.

Any one have a fix for this. I was thinking of writing an automation that when the Sonoff becomes unavailable the button automations are not to work or something like that.

@AlexxIT - any update? Encountering this issue as well.

I was able to solve this for now by adding a condition in my automation to ensure the entity was not in a state of Unknown or Unavailable.  This stopped the automation firing when the sonoff entities are reloaded - which is what seems to trigger this.  In my case the logging was showing the automation being triggered due to the entities being in one of these states.

I was able to solve this for now by adding a condition in my automation to ensure the entity was not in a state of Unknown or Unavailable. This stopped the automation firing when the sonoff entities are reloaded - which is what seems to trigger this. In my case the logging was showing the automation being triggered due to the entities being in one of these states.

Can you share how you wrote that condition so I can add it myself and test whether it works for me?

I was able to solve this for now by adding a condition in my automation to ensure the entity was not in a state of Unknown or Unavailable. This stopped the automation firing when the sonoff entities are reloaded - which is what seems to trigger this. In my case the logging was showing the automation being triggered due to the entities being in one of these states.

Can you share how you wrote that condition so I can add it myself and test whether it works for me?

I would, but there is a side effect - none of my automations will no longer work until a activate all the buttons in my rf bridge integration.
So did a bit more digging, then tried implementing my automation as shown here:
https://github.com/AlexxIT/SonoffLAN/wiki/RF-Bridge
Implemented this way - when reloading the configuration for my sonoff bridge - it no longer triggers the automations.

https://github.com/AlexxIT/SonoffLAN/wiki/RF-Bridge
Implemented this way - when reloading the configuration for my sonoff bridge - it no longer triggers the automations.

This actually seems to be working for me too. I've built the automation off of the events and have reloaded configs as well as done a full restart and the automation does not trigger erroneously.


chore(deps): update react-scripts

This is a replacement for #1932
github merge instructions are borked for CLI.. I didn't guess pushing to main would automatically update the PR.. and it didn't. it pushed to main, and closed the PR.
I reverted those changes and updated many things necessary for upgrading react-scripts. Build finally succeeds, but tests are failing. Build, tests, and CI checks are all passing

Kicked off a test of all node versions, https://github.com/ipfs/ipfs-webui/actions/runs/2709349231, so we can see how these changes impact builds across node versions and platforms.


Removed default profiles

Please, go through these steps before you submit a PR.

[x] My Pod Leader knows I'm working on this Pull Request
[x] I've explained what the Pull Request is adding.
[x] I've explained why this is important.

Removed Default images for better UI

This looks amazing, just don't forget to change Will, Amanda, Mike and Aaron's cards to our pods


wg set doesn't work, wg setconf works

For some reason, wg set doesn't work, I am having to resort to using wg setconf in /usr/bin/namespaced-wireguard-vpn-interface file -
wg setconf "$WIREGUARD_NAME" /home/user/Projects/wgns/wgns.conf
       # wg set "$WIREGUARD_NAME" \
       #     private-key <(echo "$WIREGUARD_PRIVATE_KEY") \
       #     peer "$WIREGUARD_VPN_PUBLIC_KEY" \
       #         endpoint "$WIREGUARD_ENDPOINT" \
       #         allowed-ips "$WIREGUARD_ALLOWED_IPS" || die

By 'doesn't work', I mean I cannot ping other wireguard clients using sudo ip netns exec vpn ping <IP_ADDRESS>
To clarify, I have properly filled in env variables in /etc/namespaced-wireguard-vpn/namespaced-wireguard-vpn.conf file
Following is my wgns.conf file -
 [Interface]
 PrivateKey = ****

 [Peer]
 PublicKey = ****
 PresharedKey = ****
 Endpoint = ****
 AllowedIPs = <IP_ADDRESS>/0,::/0

OS - Arch Linux 5.16.2-arch1-1
Wireguard version - wireguard-tools v1.0.20210914
I don't know how to debug/check logs.

That's odd. I don't know any particular reason setconf should work differently from the equivalent set call.
You can check if the systemd unit has any useful log output with
$ journalctl -eu namespaced-wireguard-vpn-interface.service

in case there's an error running the set command. But if the interface comes up and just doesn't work, that sounds like the command was successful and just didn't do what we expected.

@chrisbouchard I'm seeing problems myself trying to set this up too. On some testing of the actual wg set command I get
"fopen: No such file or directory"


Add Kotlin DSL improvements to 8.1 release notes

See https://github.com/gradle/gradle/pulls?page=1&q=is%3Apr+milestone%3A"8.1+RC1"+label%3Ain%3Akotlin-dsl+is%3Aclosed+sort%3Aupdated-asc
Rendered preview
https://builds.gradle.org/repository/download/Gradle_Master_Check_BuildDistributions/62533835:id/distributions/gradle-8.1-docs.zip!/gradle-8.1-20230303113425%2B0000/docs/release-notes.html

@bot-gradle test BD

Your PR is queued. See the queue page for details.

I've triggered a build for you.


Enhancement: remove body parser

Enhancement Description:

Express already includes body-parser functions inside it, so there is no need to install and import it and use body-parser explicitly.
After making necessary changes, It will reduce 1 package from dependencies.

I would like to work on this issue under GSSOC`22. Please assign it to me. I will make PR after 1st March.

@naveen8801 Review Requested.


Dashboard -- JWT Authentication

Added Authentication using JWT authentication
Implemented a mock dashboard
Added a Unit Test for the JWT authentication process

The pull requests has no conflicts but the unit tests will need to be reconfigured on the server side when being run on Github to resolve any CI/CD conflicts.


⚠ Bofrost.de has degraded performance

In de35372, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 892 ms

Resolved: Bofrost.de performance has improved in 88c0178.


[v1.x] Merge MKLDNN adaptive pooling with traditional pooling implementation

Merged MKLDNN adaptive pooling with traditional pooling implementation,
so that the code redundancy is fixed

@szha Please help with the merge.

Generally, it looks good! This pull request should solve a one-specific problem. Please don't sort headers and don't re-format files here.

Generally, it looks good! [v1.x] has not been re-formatted yet. Please don't sort headers and don't re-format files here

@mxnet-bot run ci [unix-cpu]

@szha Could you help with review/merge?


torchvision.utils.draw_bounding_boxes set font_size

🚀 The feature
font_ The size setting must be specified at the same time as the font to be valid, otherwise it is invalid.
I think utils.py in torchvision Line 239 can be improved.Make font settings and font size settings separate.
utils.py Line 239:
"txt_font = ImageFont.load_default() if font is None else ImageFont.truetype(font=font, size=font_size)"
Motivation, pitch
Improve the experience of torchvision.draw_bounding_boxes
Alternatives
No response
Additional context
No response

If I understand correctly, You want font_size to work for default font right?
But I believe the PIL Does not have this functionality to load default font with a given font size
See https://github.com/python-pillow/Pillow/issues/2695

Thank you. I see.

Given that this is just a small utility that we provide and PIL does not have this option, I don't think there is much that we can do for now. Still, thanks for the request @haozhihang123 and @oke-aditya for linking the relevant issue!

Although one way is to Have a default font from torchvision side and not rely on OS. Which would allow to set font_size
I won't recommend this fix. As the current API works.
It might be wiser to throw a warning if user supplies font_size without specifying font.

It might be wiser to throw a warning if user supplies font_size without specifying font.

Yes, that is indeed a good change. Whenever user input gets ignore for any reason, we should warn about it. @oke-aditya do you want to send a PR?

I believe some new contributor could take this. As it's a good first issue :)
(Of course I can submit a PR. But will feel more happy to see a new contributor)

feel free to have a go


Add MessageType.Debug

This fixes #1255 by adding MessageType.Debug (along with RevealOutputChannelOn.Debug) for debug messages.
The new enum cases are added in a backwards-comaptible way that shouldn't break any assumptions about ordering (e.g. debug level is conceptually "more fine-grained" than info/warn/error).

Besides a PR for the implementation we also need one for the spec which is hosted here: https://github.com/microsoft/language-server-protocol. The branch to make the modifications in is gh-pgaes. Can you please provide a corresponding PR as well.


Update build-and-test.yaml

Type
enhancement

Description

Removed the trigger for pull_request events in the build-and-test.yaml workflow to simplify the workflow triggers.

Changes walkthrough
Relevant filesEnhancement

build-and-test.yamlSimplify Build-and-Test Workflow Triggers

.github/workflows/build-and-test.yaml

Removed trigger for pull_request events.

+0/-2

✨ PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

/analyze

/help


Add preview param to Contentful queries

Contentful requires queries to have preview=true in order to get entries in draft mode, even if you're using the Preview API token.  It would be nice for Cloak to have this by default.

Thanks for this.  I ended up rolling some this functionality into Cloak: https://github.com/BKWLD/cloak/commit/c6da8c6bb27c4aee29578b698812a6e3360b11ee
I wanted the application of the preview token and variable to be invisible from components; I think the service should just take care of it automatically.


Optional Columns Types Not Being Inferred

On 1.3 + Dropbox Stubs, mypy allowed me to assign None to this field:
my_int = Column(Integer, nullable=True, index=True)

however on 1.4 + the new stubs, I need to annotate:
my_int: Column[Optional[int]] = Column(Integer, nullable=True, index=True

otherwise it complains about assigning None to an int

hi again -
works fine here, can you please ensure you are on the latest mypy  / stubs / SQLAlchemy, thanks
from sqlalchemy import Column
from sqlalchemy import Integer
from sqlalchemy import MetaData
from sqlalchemy.orm import declarative_base

Base = declarative_base(metadata=MetaData())

class U(Base):
    __tablename__ = "x"
    id = Column(Integer, primary_key=True)
    my_int = Column(Integer, nullable=True, index=True)

u1 = U(my_int = None)

u1.my_int = None

$ mypy test3.py
Success: no issues found in 1 source file


Add sample macros for moving head away from model

What would you like to see added?
See macros from icoderus

Added macros from coderus, no idea why they were missing.


Replace heim with sysinfo

heim apparently died around the same time we paused work on Alan. sysinfo appears to be the current and maintained way to get this information.
This'll help us revive Windows support and also unblock updating other libs that heim used that are stuck in 2 year old versions.

Mostly done, but sysinfo is missing some system information heim provides.
Closing this, though, because it's not clear if we actually need it.


Optimize CIOS for moduli with spare bits

Optimize CIOS for moduli with spare bits
Description
Solves Issue #506

Type of change

[ ] New feature
[ ] Bug fix
[x] Optimization

Checklist

[x] This change is an Optimization

[x] Benchmarks added/run

Codecov Report

Merging #517 (f8fc936) into main (af0a479) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #517      +/-   ##
==========================================
+ Coverage   94.46%   94.51%   +0.05%
==========================================
  Files          62       62
  Lines        8863     8949      +86
==========================================
+ Hits         8372     8458      +86
  Misses        491      491

Files Changed
Coverage Δ

...src/field/fields/montgomery_backed_prime_fields.rs
93.54% <100.00%> (+0.08%)
:arrow_up:

math/src/unsigned_integer/montgomery.rs
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


bpf skip rpf fix

Description

Related issues/PRs

Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

TBD

Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one docs-* label.

docs-pr-required: This change requires a change to the documentation that has not been completed yet.
docs-completed: This change has all necessary documentation completed.
docs-not-required: This change has no user-facing impact and requires no docs.

Every PR needs one release-note-* label.

release-note-required: This PR has user-facing changes. Most PRs should have this label.
release-note-not-required: This PR has no user-facing changes.

Other optional labels:

cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.

The only failure is due to https://github.com/projectcalico/calico/pull/6121


Upgrade our slf4j dependencies from 1.7.24 to 1.7.30

Task Description
We need to upgrade our slf4j dependencies from 1.7.24 to 1.7.30.
Tasks
The following tasks will need to be carried out:

[ ] Update the version in the strongbox-parent project.
[ ] Apply any required code changes, or dependency excludes.
[ ] Test and confirm that there are no issues with the core projects (strongbox, strongbox-web-integration-tests, etc) after upgrading.

Help

Check our article on how to upgrade dependencies and plugins.
Our chat
Points of contact:

@carlspring
@sbespalov
@steve-todorov

Hi @carlspring , I would like to take this up. Please assign it to me. I will raise the PR after 1st October.

Hi @Baibhab97 ,
Thanks for offering to help! If no one else has picked it up during the Grace Hopper Celebration (Opensource Day), which will be on October 1st, then feel free to look into it.

Hello! I am a Grace Hopper attendee. Can I work on this?

Sure you can @shravyags! :)


Add the 'all' flag when installing components through DISM in 2012 and a...

...bove.

Fixes #102

:+1:


Auto post updates

Automatically fetch, update, and release posts to the site

Not going to implement. Instead going for a static deployment with #232