makedeps fails to generate valid .d files on windows.

There is a failing test:

Left:  test.d: \\?\D:\Users\Hydra\Documents\dev\projects\stm32-rs\svdtools\res\makedeps\sub-tests\inc1.yaml \\?\D:\Users\Hydra\Documents\dev\projects\stm32-rs\svdtools\res\makedeps\sub-tests\inc2.yaml
Right: test.d: D:\Users\Hydra\Documents\dev\projects\stm32-rs\svdtools\res\makedeps\sub-tests/inc1.yaml D:\Users\Hydra\Documents\dev\projects\stm32-rs\svdtools\res\makedeps\sub-tests/inc2.yaml

The use of std::fs::canonicalize is adding \\?\ in addition to removing \.\ path components.
These paths are not valid paths when svdtools is used as part of stm32-rs when running make patch in cygwin.
The resulting error from the command that uses the generated dependencies make svd2rust is as follows:
$ make svd2rust
.deps/stm32c011.d:1: *** target pattern contains no '%'.  Stop.

If you inspect the generated file you see this:
$ more .deps/stm32c011.d
stm32c011.d: \\?\D:\Users\Hydra\Documents\dev\projects\stm32-rs\stm32-rs\devices\common_patches\c0.yaml \\?\D:\Users\Hydra\Documents\dev\projects\stm32-rs\stm32-rs\devices\common_patches\nvic\2_prio_bits.yaml

As a workaround I hacked up abspath as follows:
/// Gets the absolute path of relpath from the point of view of frompath.
fn abspath(frompath: &Path, relpath: &Path) -> Result<PathBuf, std::io::Error> {
    //std::fs::canonicalize(frompath.parent().unwrap().join(relpath))
    let path = frompath.parent().unwrap().join(relpath);

    let path_str = format!("{}", path.display()).replace("\\", "/");

    Result::<_,std::io::Error>::Ok(PathBuf::from(path_str))
}

Branch with that is here: https://github.com/hydra/svdtools/tree/working-windows-makedeps
and now the test fails as follows:
Left:  test.d: D:/Users/Hydra/Documents/dev/projects/stm32-rs/svdtools/res/makedeps/sub-tests/inc1.yaml D:/Users/Hydra/Documents/dev/projects/stm32-rs/svdtools/res/makedeps/sub-tests/inc2.yaml
Right: test.d: D:\Users\Hydra\Documents\dev\projects\stm32-rs\svdtools\res\makedeps\sub-tests/inc1.yaml D:\Users\Hydra\Documents\dev\projects\stm32-rs\svdtools\res\makedeps\sub-tests/inc2.yaml

However, the resulting .d files are now valid, here's the same one from the stm32-rs project from before:
$ more .deps/stm32c011.d
stm32c011.d: devices/./common_patches/c0.yaml devices/./common_patches/nvic/2_prio_bits.yaml

I'm no expert on the String, PathBuf or FS APIs so not sure what a proper cross-platform fix is, but this unblocked me today.

@hydra Could you check #140 ?

@burrbull yes, I will give that a whirl ASAP and report back.

Reopen if still not solved

$ RUST_BACKTRACE=1 cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.08s
     Running unittests src\lib.rs (target\debug\deps\svdtools-79fa8ce3a1e1d116.exe)

running 9 tests
test common::str_utils::tests::correctly_format_address ... ok
test interrupts::interrupt_list::tests::correct_gaps_if_zero_and_two_are_missing ... ok
test interrupts::svd_reader::tests::peripherals_interrupts_are_parsed_correctly ... ok
test mmap::mmap_cli::tests::mmap ... ok
test patch::device::tests::add_peripherals ... ok
test patch::device::tests::copy_peripherals ... ok
test patch::device::tests::modify_device ... ok
test patch::device::tests::delete_peripherals ... ok
test makedeps::makedeps_cli::tests::test_makedeps ... FAILED

failures:

---- makedeps::makedeps_cli::tests::test_makedeps stdout ----
thread 'makedeps::makedeps_cli::tests::test_makedeps' panicked at 'assertion failed: `(left == right)`
  left: `"C:\\cygwin64\\tmp\\.tmpbghyq2\\test.d: \\\\?\\D:\\Users\\Hydra\\Documents\\dev\\projects\\stm32-rs\\svdtools\\res\\makedeps\\sub-tests\\inc1.yaml \\\\?\\D:\\Users\\Hydra\\Documents\\dev\\projects\\stm32-rs\\svdtools\\res\\makedeps\\sub-tests\\inc2.yaml\n"`,
 right: `"C:\\cygwin64\\tmp\\.tmpbghyq2/test.d: D:\\Users\\Hydra\\Documents\\dev\\projects\\stm32-rs\\svdtools\\res\\makedeps\\sub-tests/inc1.yaml D:\\Users\\Hydra\\Documents\\dev\\projects\\stm32-rs\\svdtools\\res\\makedeps\\sub-tests/inc2.yaml\n"`', src\makedeps\makedeps_cli.rs:80:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/065852def0903296da33a9eaf557f230bcf3a61a/library\std\src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/065852def0903296da33a9eaf557f230bcf3a61a/library\core\src/panicking.rs:64:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /rustc/065852def0903296da33a9eaf557f230bcf3a61a\library\core\src/panicking.rs:211:5
   4: svdtools::makedeps::makedeps_cli::tests::test_makedeps
             at .\src\makedeps\makedeps_cli.rs:80:9
   5: svdtools::makedeps::makedeps_cli::tests::test_makedeps::{{closure}}
             at .\src\makedeps\makedeps_cli.rs:62:27
   6: core::ops::function::FnOnce::call_once
             at /rustc/065852def0903296da33a9eaf557f230bcf3a61a\library\core\src\ops/function.rs:250:5
   7: core::ops::function::FnOnce::call_once
             at /rustc/065852def0903296da33a9eaf557f230bcf3a61a/library\core\src\ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

@burrbull test still fails, as above

test fails, you are right.
But have you tried to run svdtools patch?
Also have you tried precompilled release version: https://github.com/stm32-rs/svdtools/releases/download/v0.3.0/svdtools-x86_64-pc-windows-msvc.zip ?

$ more .deps/stm32c011.d
stm32c011.d: \\?\D:\Users\Hydra\Documents\dev\projects\stm32-rs\stm32-rs\devices\common_patches\c0.yaml \\?\D:\Users\Hydra\Documents\dev\projects\stm32-rs\stm32-rs\devices\common_patches\nvic\2_prio_bits.yaml

Those are correct windows pathes.

Those are correct windows pathes

yes, they are windows paths, but I'm running under cygwin, and cygwin make wants cygwin paths.

But have you tried to run svdtools patch?

no, since I know it will fail as the same production code used by the tests will cause the paths to be generated in the same way.

Also have you tried precompilled release version: https://github.com/stm32-rs/svdtools/releases/download/v0.3.0/svdtools-x86_64-pc-windows-msvc.zip ?

No, because past experience has taught me not to mix tools from different ecosystems.   WSL use WSL binaries, cygwin - use cygwin binaries, windows/vscode/powershell/cmdline - use windows binaries.

IMHO the code used to generate paths needs to detect cygwin, and generate cygwin paths, not windows paths.
Cygwin paths are the same as linux paths.
Cygwin detection is usually done by running uname and looking for the CYGWIN string.
$ uname
CYGWIN_NT-10.0-19045

It might also be possible to supply a --cygwin option to the tool, to inform it to generate cygwin/linux style paths instead of windows paths if cygwin detection is done in the Makefile via uname.
A different approach could be to run the generated .d files through a processor which applies cygpath to each path.
$ cygpath --help
Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
       cygpath [-c HANDLE]
       cygpath [-ADHOPSW]
       cygpath [-F ID]

Convert Unix and Windows format paths, or output system path information

Output type options:

  -d, --dos             print DOS (short) form of NAMEs (C:\PROGRA~1\)
  -m, --mixed           like --windows, but with regular slashes (C:/WINNT)
  -M, --mode            report on mode of file (binmode or textmode)
  -u, --unix            (default) print Unix form of NAMEs (/cygdrive/c/winnt)
  -w, --windows         print Windows form of NAMEs (C:\WINNT)
  -t, --type TYPE       print TYPE form: 'dos', 'mixed', 'unix', or 'windows'

Path conversion options:

  -a, --absolute        output absolute path
  -l, --long-name       print Windows long form of NAMEs (with -w, -m only)
  -p, --path            NAME is a PATH list (i.e., '/bin:/usr/bin')
  -U, --proc-cygdrive   Emit /proc/cygdrive path instead of cygdrive prefix
                        when converting Windows path to UNIX path.
  -s, --short-name      print DOS (short) form of NAMEs (with -w, -m only)
  -C, --codepage CP     print DOS, Windows, or mixed pathname in Windows
                        codepage CP.  CP can be a numeric codepage identifier,
                        or one of the reserved words ANSI, OEM, or UTF8.
                        If this option is missing, cygpath defaults to the
                        character set defined by the current locale.

System information:

  -A, --allusers        use `All Users' instead of current user for -D, -O, -P
  -D, --desktop         output `Desktop' directory and exit
  -H, --homeroot        output `Profiles' directory (home root) and exit
  -O, --mydocs          output `My Documents' directory and exit
  -P, --smprograms      output Start Menu `Programs' directory and exit
  -S, --sysdir          output system directory and exit
  -W, --windir          output `Windows' directory and exit
  -F, --folder ID       output special folder with numeric ID and exit

Other options:

  -f, --file FILE       read FILE for input; use - to read from STDIN
  -o, --option          read options from FILE as well (for use with --file)
  -c, --close HANDLE    close HANDLE (for use in captured process)
  -i, --ignore          ignore missing argument
  -h, --help            output usage information and exit
  -V, --version         output version information and exit

My preference would be for the former, not the latter.

cargo make works fine on native windows. I don't plan to support cygwin.


fix #370: bulkcopy: slice bounds out of range

Fix for #370:
There are cases when we sequentially call buf.Write, buf.WriteByte, buf.Write. In some of such cases buf.WriteByte doesn't Flush which leads to panic about "slice bounds out of range" on following buf.Write:

buf.Write before: (wpos: 3666, packetSize:4096, data len: 430) after: (wpos: 4096, packetSize:4096)
buf.WriteByte before: (wpos: 4096, packetSize:4096) after: (wpos: 4097, packetSize:4096)
buf.Write: before: (wpos: 4097, packetSize:4096, data len: 2)

Above the second call of buf.Write will try to slice wbuf with [4097:4096] which produces the panic.

Merged, thanks!


Trails

@jaumard , that's true. I wanted to use as much of the framework as possible to get to know it better, but we don't want to waste resources. I'll move it to the frontend.

Maybe the DefaultController/UserModel and DefaultService can be remove because they are not useful
Instead of this all is good for me. I don't know react at all so I have to learn it :) this repo can be a start for this ^^

OK, done. Also note that until we've published trailpack-webpack to npm, I've pulled out a webpack.config.temp.js that you can manually use to bundle with webpack --config webpack.config.temp.js.
@yejodido do you want to review and merge if suitable?

@yejodido are we good to merge?

Looks good to me :)


Update gitignore to exclude the vcpkg binary

When you run ./bootstrap-cvpkg.sh, the binary isn't excluded from the git repo
I have updated the gitignore to ignore the vcpkg binary.

Good catch, thanks!


YETUS-1202. plug-ins cannot use filefilter to build lists of files

In addition to what I wrote in the JIRA, my hunch is that longer term, individual plug-ins doing their own filename caching is likely a mistake.  For example, I'm not sure what happens if a project's personality file adds files into CHANGED_FILES.  There is also the general memory usage, code complexity, etc.
I realize this PR doesn't really fix shellcheck and shelldocs to match the rest.  But fixing those is a much bigger problem that I don't want to take on right now.


[wip] CLI

This PR provides a CLI to meteor, currently a single script:

meteor.diffmap

As this PR has already swollen beyond what is utterly reasonable, the second script

meteor.phaseboost

will come in a future PR.

@alisiafadini maybe you can give this a review, sorry it's so huge. At least giving the test a spin from a user-experience point of view would be great.
Notes:

codecov is complaining about a few missed lines, but coverage is very high... I vote we proceed
we still need to work on optimizing the TV weight scanning


Support Bearer tokens

While at it:

ensure absolute names are indeed absolute
fix error handling

Fixes #10

Yes,
@n-g  : I'd like to to test your PR with caddy webserver, but I can't solve this error.
Any idea how to go further ?
$ go version
go version go1.21.3 linux/amd64

 $ ~/go/bin/xcaddy build v2.7.5 --with github.com/n-g/libdns-gandi
...
2023/10/16 21:07:33 [INFO] exec (timeout=0s): /usr/bin/go get -d -v github.com/n-g/libdns-gandi<EMAIL_ADDRESS>go<EMAIL_ADDRESS>found: parsing go.mod:
	module declares its path as: github.com/libdns/gandi
	        but was required as: github.com/n-g/libdns-gandi
go: github.com/n-g/libdns-gandi@upgrade (v0.0.0-20231012081002-090df437d112) requires<EMAIL_ADDRESS>parsing go.mod:
	module declares its path as: github.com/libdns/gandi
	        but was required as: github.com/n-g/libdns-gandi
...

Yes,
@n-g : I'd like to to test your PR with caddy webserver, but I can't solve this error. Any idea how to go further ?
$ go version
go version go1.21.3 linux/amd64

 $ ~/go/bin/xcaddy build v2.7.5 --with github.com/n-g/libdns-gandi
...
2023/10/16 21:07:33 [INFO] exec (timeout=0s): /usr/bin/go get -d -v github.com/n-g/libdns-gandi<EMAIL_ADDRESS>go<EMAIL_ADDRESS>found: parsing go.mod:
	module declares its path as: github.com/libdns/gandi
	        but was required as: github.com/n-g/libdns-gandi
go: github.com/n-g/libdns-gandi@upgrade (v0.0.0-20231012081002-090df437d112) requires<EMAIL_ADDRESS>parsing go.mod:
	module declares its path as: github.com/libdns/gandi
	        but was required as: github.com/n-g/libdns-gandi
...

Right, I didn't change the go.mod to make the PR clean.
The best way to test this change is to check out github.com/n-g/libdns-gandi and then run
xcaddy build v2.7.5 --with github.com/libdns/gandi=. from that dir.

Alright, just released recently the fix for the legacy certbot plugin, will work on this one asap.


feat: add precommit hook

Description

Linked Issues
Additional context

conflicting

@productdevbook conflict resolved

Is it right to fix just before commit? What if it changes all the code we wrote?

Is it right to fix just before commit? What if it changes all the code we wrote?

I think applying a fix before committing is okay. No, it won't change the code we wrote since the same eslint config applies to all.


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 09:27:29 on 2023.05.30
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 6, errors out: 0
Original problem ID: 22943
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=22943

Problem has been resolved in 6m 0s at 09:33:29 on 2023.05.30
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 22943


Add --oldest-first argument and reverse default download order

Rationale
When you first connect you watch you normally care about the newest activities. The issue is that the script starts by download the oldest ones and it can take quite a long time until you reach the activities you care about.
What this PR does

Reverts the default ordering of the download (download the newest activity first)
Adds an --oldest-first flag if you want the older behavior

This should resolve the issues pointed in #147

@Tigge You probably need to rerun the tests. It seems that coverals had a server error.


Cleaned up spurious folder removing

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.973%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
289

Relevant Lines:
292

💛  - Coveralls


Duplicate parameter  and partial method

I'm working on this swagger: Partnercenter Insights
The clean swagger is here: s.txt
The json contains identical tags on paths, but fixing those makes it possible to generate autorest for csharp without errors. Running autorest for PowerShell causes some issues, though.
Opening the generated files in VS Code reviles the following errors:

What would be the best way to proceed to rat out the errors?

There should be a property called operationId for each API. Please refer to https://github.com/Azure/azure-rest-api-specs/blob/master/specification/databricks/resource-manager/Microsoft.Databricks/stable/2018-04-01/databricks.json#L42 for an example


Latoken - Client - time_synchronizer - Error getting server time.

Upon crosschecking with the QA team.
Currently have the time_synchronizer - Error getting server time. and also WARNING - Could not refresh server time. messages on the initial start
This issue not showed yesterday when checking latest development branch.
Environment: AWS Ubuntu Source, dev-1.7.0, also showing on the master branch (1.6.0) for same AWS
Steps To Reproduce
set up on AWS Ubuntu source
clone and install latest master or development branch
start the bot
Expected:
No error showing
Actual:
Bot showing time_synchronizer - WARNING - Could not refresh server time. Check network connection.
Traceback:
logs_hummingbot(master branch).log
2022-08-02 04:56:45,255 - 2948 - hummingbot.connector.time_synchronizer - NETWORK - Error getting server time.
Traceback (most recent call last):
  File "/home/ubuntu/master/hummingbot/connector/time_synchronizer.py", line 59, in update_server_time_offset_with_time_provider
    server_time_ms: float = await time_provider
  File "/home/ubuntu/master/hummingbot/connector/exchange/latoken/latoken_web_utils.py", line 197, in get_current_server_time
    response = await rest_assistant.execute_request(
  File "/home/ubuntu/master/hummingbot/core/web_assistant/rest_assistant.py", line 71, in execute_request
    error_response = await response.json()
  File "/home/ubuntu/master/hummingbot/core/web_assistant/connections/data_types.py", line 114, in json
    json_ = await self._aiohttp_response.json()
  File "/home/ubuntu/miniconda3/envs/hummingbot/lib/python3.8/site-packages/aiohttp/client_reqrep.py", line 1097, in json
    raise ContentTypeError(
aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: text/html; charset=utf-8', url=URL('https://api.latoken.com/v2/time')
2022-08-02 04:56:45,256 - 2948 - hummingbot.connector.time_synchronizer - WARNING - Could not refresh server time. Check network connection.

Upon checking logs issue could be related to latoken exchange. Not showing now, so close that issue for now

This is happening again on the dev-1.20.0 branch

hi @zethereumGmail the issue not related to the exchange, but most likely related to the restricted area to get data.
Anyway, upon checking before bot should be able to place orders anyway


does not work

AFter days of banging my head against the wall. Followed the instructions to the letter but It SIMPLY DOES NOT WORK.

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

ID: 83c47bef-6351-3ab4-41e0-0abec261278f
Version Independent ID: 332d0d0f-6d57-93d2-49b4-98a29e21eac2
Content: Consume the Microsoft Graph in the SharePoint Framework
Content Source: docs/spfx/use-aad-tutorial.md
Product: sharepoint
Technology: sharepoint-framework
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

Please provide with the issues you are facing while following the steps to help you better.

Unfortunately, you haven't provided enough information to assist. Without some context, repro steps, screen captures, code, errors, etc... , there's not much we can do to help you.

@andrewconnell
I had the same issue today.
In a nutshell, the current example uses components that are not more working for the latest fabric and SPx version. For example, autobind is a deprecated component. I just upgraded the solution and created a pull request.
If you want, I can go and update also the documentation to reflect the new changes.

Always interested in contributions on the docs if there are issues.
What I suggest is creating a NEW issue on this doc as the OP is not responding and this will eventually get closed without their response. In the new issue, explain what's wrong and what needs to be fixed. Feel free to submit a PR against the doc and we'll review & merge it if helps!


Multiple data store with Delivery history

How does it work when both Cosmos DB and Azure Data Lake Store are used for query and data insertion?
For example, how to tell which store for query, and which store for data insertion?
Is there other challenges raised?
"Therefore, the Delivery History service also stores a subset of the historical data in Cosmos DB for quicker lookup."
https://docs.microsoft.com/en-gb/azure/architecture/microservices/design/data-considerations#example-choosing-data-stores-for-the-drone-delivery-application

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

ID: eb25545c-958f-99b0-b321-74e556ad4557
Version Independent ID: ebe36da6-a15f-f981-787d-8aa4307451a2
Content: Data considerations for microservices
Content Source: docs/microservices/design/data-considerations.md
Service: architecture-center
Sub-service: reference-architecture
GitHub Login: @MikeWasson
Microsoft Alias: pnp

@PingPongSet Thank you for your feedback! We will review and provide an update as appropriate.

@PingPongSet this is logic that would need to be built into the service.


Not remembering login details

macOS 10.13.6 (17G5019)
Safari 11.1.2 (13605.3.8)
Alfred 3.8 [959]
PinPlus workflow 1.4.1
PinPlus app 1.1.1

Run :pinplusupdateapp (and wait a minute or so, for it to finish). Should be fixed.


[WIP] InMemory: Copy values to/from store

Still need to address #13085 & #13098 and investigate failures

Closing. We'll sort all this out as part of #13098.


server collaboration command list

Ignore collab folder: rewrite needed
Ensure moderation folder is working
ensure owner folder is working

addrole command needs rewrite


Host autoregistered in zabbix  with IP <IP_ADDRESS> when ListenIP sets to <IP_ADDRESS>

I'm use autoregistartion in zabbix. If agent have ListenIP <IP_ADDRESS>  , host in zabbix also have <IP_ADDRESS>, so zabbix server cant connect to agent.  Need to comment ListenIP  in agent conf to fix it. How I can do it from playbook?

Need to fix zabbix_agentd.conf.j2:
{% if zabbix_agent_listenip  !='<IP_ADDRESS>' %}
ListenIP={{ zabbix_agent_listenip }}
{% endif %}

I proved a fix in the zabbix-agent role.


IPROTO-275 Handle unicode escapes in annotations

https://issues.redhat.com/browse/IPROTO-275

@tristantarrant merged


TypeScript intellisense for i18next not working anymore sinc VSCode update

Type: Bug

Clone https://github.com/i18next/i18next
Navigate to: https://github.com/i18next/i18next/tree/master/examples/typescript
npm i
open index.ts
check intelisense for => i18next.t('')

On VSCode v1.78.2 it works.
On VSCode v1.79.1/v1.79.2 it does not work anymore.
See also: https://github.com/i18next/i18next/issues/1956#issuecomment-1595258734
VS Code version: Code 1.79.2 (695af097c7bd098fbf017ce3ac85e09bbc5dda06, 2023-06-14T08:58:33.551Z)
OS version: Darwin arm64 22.5.0
Modes:

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.79.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Still the same with v1.79.2

v1.78.2

v1.79.2

Same here, using VSCode v1.79.2 on Windows, not only the intellisense for i18next has stopped working, the autocompletion for react-navigation has also stopped working to me. The suggestions only appear when I Ctrl + Space without inserting anything inside the parenthesis:

The moment I input any string, it stops working

Yes, you're right @Risovas

I don't know, I just know that I've downgraded to v1.78.2 (April Update) and it started working again, both react-navigation and i18next suggestions as I type. Just hope this is fixed soon so that I don't have to stay with an old version or give up on the intellisense for these two libs


Support more analysis visualizations

[ ] Pairwise analysis
[ ] System combiner

@neubig Makes sense, let me create another issue for system combination and convert this one to pairwise analysis.
I've been working on pairwise analysis yesterday, and it's almost done! Will be pushing a PR today. 😃

Closing. #84 merged.


[BUG] holetp doesnt work

like it does absolutely nothing, doesnt even work on nonstrict servers

It does work it's just not made for servers with anti-cheat. Try it out in singleplayer and you will see.

who doesnt hack in single player

Newgen 7b/2y2c mains don't have rights to talk

Newgen 7b/2y2c mains don't have rights to talk

u have 2b2t in ur name incel

Don’t mess with zane he plays 1.12 German skywars

LOL SINGEPLAYER HACK
3arthqu4ke u can close it now

newgen 7b/2y players dont have rights to tlak

LOL STFU


Need to generate and copy setkin_chem_mech.txt___.rc into EXPDIR/RC

GMI needs the file, setkin_chem_mech.txt___.rc, in its EXPDIR/RC. In the old GNU make version, it gets generated in GMIchem_GridComp/ and then copied to Linux/etc, and then the setup script copies it into RC.
In the new approach, it winds up in build/src/Components/<EMAIL_ADDRESS>but it never gets copied to RC by the setup script. It should probably go into install/etc.

Mike Manyin noted the following:
The missing file (setkin_chem_mech.txt___.rc) is just a copy of the file setkin_chem_mech.txt and it appears that it needed to be renamed to be an .rc file, so whoever did it decided to add ___ in the name too. The name with ___ does not need to be preserved. It would be most clear if the filename setkin_chem_mech.txt were used, but it would also be ok to swap in .rc for .txt.

@gmao-esherman It wasn't too difficult I think because of hard work @tclune did before hand. You need to do:
foreach (file ${first_stage_files})
   install(
      FILES ${CMAKE_CURRENT_BINARY_DIR}/${file}
      DESTINATION etc
      )
endforeach ()

This installs:
Deposition_Registry___.rc
Reactions_Registry___.rc
GMI_Tendency_Registry___.rc
setkin_chem_mech.txt___.rc

into install/etc.

What file does this need to be written to?

This goes into the CMakeLists.txt file in the top directory of the GMI grid comp.
Towards the bottom, you'll see similar lines of code for other .rc files.

Got it, thanks!


HBASE-25937: Clarify UnknownRegionException

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 35s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 49s
master passed

+1 :green_heart:
compile
4m  9s
master passed

+1 :green_heart:
checkstyle
1m 31s
master passed

+1 :green_heart:
spotbugs
2m 58s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 36s
the patch passed

+1 :green_heart:
compile
4m  6s
the patch passed

+1 :green_heart:
javac
4m  6s
the patch passed

+1 :green_heart:
checkstyle
1m 28s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
18m 10s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0.

+1 :green_heart:
spotbugs
3m 24s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 27s
The patch does not generate ASF License warnings.

52m 53s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3330

JIRA Issue
HBASE-25937

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux f5f9c4af2391 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 479ae88be3

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 34s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 37s
master passed

+1 :green_heart:
compile
1m 45s
master passed

+1 :green_heart:
shadedjars
8m 20s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  2s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 39s
the patch passed

+1 :green_heart:
compile
1m 27s
the patch passed

+1 :green_heart:
javac
1m 27s
the patch passed

+1 :green_heart:
shadedjars
8m 18s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 18s
hbase-client in the patch passed.

+1 :green_heart:
unit
155m 36s
hbase-server in the patch passed.

190m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3330

JIRA Issue
HBASE-25937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux fd862e82fdfe 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 479ae88be3

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/testReport/

Max. process+thread count
4365 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 15s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m  6s
master passed

+1 :green_heart:
compile
1m 50s
master passed

+1 :green_heart:
shadedjars
9m  5s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 11s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 50s
the patch passed

+1 :green_heart:
compile
1m 50s
the patch passed

+1 :green_heart:
javac
1m 50s
the patch passed

+1 :green_heart:
shadedjars
9m 14s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  7s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 40s
hbase-client in the patch passed.

+1 :green_heart:
unit
204m 30s
hbase-server in the patch passed.

244m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3330

JIRA Issue
HBASE-25937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 1403c57e7a15 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 479ae88be3

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/testReport/

Max. process+thread count
2833 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 31s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 32s
master passed

+1 :green_heart:
compile
1m 55s
master passed

+1 :green_heart:
shadedjars
8m 48s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 14s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 36s
the patch passed

+1 :green_heart:
compile
1m 48s
the patch passed

+1 :green_heart:
javac
1m 48s
the patch passed

+1 :green_heart:
shadedjars
8m 29s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 12s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 21s
hbase-client in the patch passed.

+1 :green_heart:
unit
138m 42s
hbase-server in the patch passed.

176m  9s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3330

JIRA Issue
HBASE-25937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux d4aeaa68f367 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 3f7d2897a1

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/2/testReport/

Max. process+thread count
3701 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 27s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 48s
master passed

+1 :green_heart:
compile
4m  4s
master passed

+1 :green_heart:
checkstyle
1m 30s
master passed

+1 :green_heart:
spotbugs
3m  2s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 34s
the patch passed

+1 :green_heart:
compile
4m  1s
the patch passed

+1 :green_heart:
javac
4m  1s
the patch passed

+1 :green_heart:
checkstyle
1m 30s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
18m 11s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0.

+1 :green_heart:
spotbugs
3m 26s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 26s
The patch does not generate ASF License warnings.

52m 41s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3330

JIRA Issue
HBASE-25937

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 604f336a1993 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / be14605898

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 22s
master passed

+1 :green_heart:
compile
1m 43s
master passed

+1 :green_heart:
shadedjars
8m 19s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 10s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 15s
the patch passed

+1 :green_heart:
compile
1m 44s
the patch passed

+1 :green_heart:
javac
1m 44s
the patch passed

+1 :green_heart:
shadedjars
8m 12s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  8s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 25s
hbase-client in the patch passed.

+1 :green_heart:
unit
140m 10s
hbase-server in the patch passed.

176m  7s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3330

JIRA Issue
HBASE-25937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 83e9bdb9a47e 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / be14605898

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/testReport/

Max. process+thread count
3892 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 30s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 49s
master passed

+1 :green_heart:
compile
1m 27s
master passed

+1 :green_heart:
shadedjars
8m 28s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  4s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 54s
the patch passed

+1 :green_heart:
compile
1m 30s
the patch passed

+1 :green_heart:
javac
1m 30s
the patch passed

+1 :green_heart:
shadedjars
8m 30s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  1s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 18s
hbase-client in the patch passed.

+1 :green_heart:
unit
148m  0s
hbase-server in the patch passed.

182m 37s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3330

JIRA Issue
HBASE-25937

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux d74d67388295 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / be14605898

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/testReport/

Max. process+thread count
3669 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3330/3/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

@busbey @Apache9  Are you able to take a look at this once more?
Thanks!


Remove hbase 1.7

Apache HBase 1.7 EOL was in 2022/08, can we remove it?
via https://endoflife.date/hbase
@illustris

Hey. Thanks for reminding me. I have a WIP PR for this:
https://github.com/NixOS/nixpkgs/pull/193740
I'm not sure why I left it as a draft... I'll go over it again and open it if it's ready.


Launch Config sometimes fails to attach Instance Profile to new instances

And it causes the instances fail to connect to ECS cluster (because they don't have access).
Guessing this is some delays for the newly created Instance Profile become fully available, but, not sure. Need to investigate.

If it's difficult to guarantee availability of Instance Profile for the initial instances, CLI can check the new instances to see if they do have Instance Profile attached or not. Kill them if they're not attached. ASG will launch new ones.


eth: mcux: Add an option for randomized, but stable MAC address

The previous default, CONFIG_ETH_MCUX_0_RANDOM_MAC, result in a random
MAC address changed each reboot. As reboots happen quite often during
development, while Ethernet peers usually cache existing MAC addresses
in ARP cache, this led to situation when a board after reboot didn't
respond to pings or any other connection attempts for random amount of
time (upo to 10-20s). This was quite confusing and looked like some
problem in driver/hardware/connection/whatever.
Instead, introduce new option, CONFIG_ETH_MCUX_0_UNIQUE_MAC, to make
MAC address from MCU unique identification register. This results in
randomized/unique MAC address which is also stable over reboots and
avoids the situation described above.
Fixes: #3187
Signed-off-by: Paul Sokolovsky<EMAIL_ADDRESS>

Codecov Report

Merging #8685 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8685   +/-   ##
=======================================
  Coverage   52.22%   52.22%
=======================================
  Files         195      195
  Lines       24662    24662
  Branches     5125     5125
=======================================
  Hits        12880    12880
  Misses       9716     9716
  Partials     2066     2066

Continue to review full report at Codecov.

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

FYI, it's interesting the way UID* registers seem to work.
I compared 2 K64F's and looked at the 4 UID* registers [UIDH, UIDMH, UIDML, UIDL]:
K64F-01: 0001FFFF FFFFFFFF 4E453693 20100014
K64F-02: 0026FFFF FFFFFFFF 4E453117 10160010
It seems the 80 bits @MaureenHelm mentioned are not sequential.  It's the first 16 bits of UIDH, then 32 bits from UIDML and UIDL.

@pfalcon probably a good thing you are using all 128 bits now from the examination above.


feat: range control

Adds a new range type control which should be Storybook compatible.
Tests, updated docs, and changelog included. Hopefully, I didn't forget anything, if so let me know.

Great work. Thanks!


Add VueXpress to wiki::Home.md ## Template Engines

A server side rendering engine for express.js. Use .vue files as your express.js templates.
https://github.com/vuexpress/vuexpress

Thanks for this! I added it for now to the Wiki, but eventually this will move to expressjs.com. This will likely be dropped in the process, because using it will break res.render using any other template engines, as it overrides that for Vue-only.


Color-coding of points in layers

Similar to #137, it would be nice to be able to be able to define the color-coding of points in layers by specifying a column (currently colorMapColumn) but also colorMapMin and colorMapMax such that:
colorFloat = (parseFloat(row[this.colorMapColumn]) - this.colorMapMin) / (this.colorMapMax - this.colorMapMin);

and then colorFloat would get mapped to a colormap. Until this is present in the JS, we will need to do this in Python and then update the data every time colorMapMin and colorMapMax are changed.

Just for the record, this is how WWT currently handles layer colors:
            switch (this.get__colorMap()) {
              case 0:
                pointColor = colorLocal;
                break;
              case 3:
                if (this.get_colorMapColumn() > -1) {
                  pointColor = this._parseColor$1(row[this.get_colorMapColumn()], colorLocal);
                }
                else {
                  pointColor = colorLocal;
                }
                break;
              default:
                break;
            }

So for now we need to include a column with the list of colors (one for each point).


OS X: No release of 0.11F for Mac

The release list doesn't show a Mac .dmg for the 0.11F release.

11E for Mac is not working. Need update.

Closing because F is obsolete.  Mac binaries are still a to-do though.


Enable additionalparams for the exasol connection

At the moment it's not possible to use "addtitionalparams" for Exasol connection, such as (for example) encryption or -enableSystemTablesSnapshotMode (for solving possible issues in the future) or even queryTimeout (when using WebSocket API ).
It would be very helpful if it would be possible to pass such kind of paramether to the provider for connection.

Probably want to upgrade to Exasol Go module first.


polkadot: 0.2.17 -> 0.8.24

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg eval

Just adding in that I've synced a full, archival node to be in sync with the network - works fine

ping

@GrahamcOfBorg build polkadot

@andresilva Very nice for getting this going, I am maintaining a similar derivation here which also builds the wasm runtime. I will give this a review Monday.

@FlorianFranzen the initial version of this PR was also building the runtime, but this required pulling nightly rustc with wasm environment from Mozilla overlay, and I'm not sure if this would be accepted here. In the end anyone that cares about building the runtime should probably be building from source, this is mostly for regular users that just want to sync the chain.

Substrate has had multiple bumps to master since I have opened this PR. The way cargo works is that you define some source for a dependency in the Cargo.toml file and the specific source is fixed in the Cargo.lock file. So even though in the Cargo.toml we are referencing master, the Cargo.lock fixes a specific commit so that everyone builds the same thing every time.
You can have a look at how dependencies are defined in polkadot for example (https://github.com/paritytech/polkadot/blob/master/service/Cargo.toml#L21) where substrate master is also referenced, but the specific commit that they point to is defined in the Cargo.lock.
As far as this PR goes I had to patch one cargo dependency in order to use a more recent version, I did this by pointing a dependency to the git master branch version https://github.com/NixOS/nixpkgs/blob/5bafcbf7c184e93b6898c5faf5b2f8bde8455027/pkgs/applications/blockchains/polkadot/substrate-wasm-builder-runner.patch#L25 in the Cargo.toml file, but the exact commit that will be checked out is defined here https://github.com/NixOS/nixpkgs/blob/5bafcbf7c184e93b6898c5faf5b2f8bde8455027/pkgs/applications/blockchains/polkadot/substrate-wasm-builder-runner.patch#L11 in the Cargo.lock file.

oh yea, forgot about the lock file nullifying the toml

ping

This looks good, thank you.


Provide a better error message when trying to authenticate with URL that returns 404

Describe the bug
If you enter a publication URL that doesn’t exist, we return the message Request failed with status code 404. That’s not very clear what has 404’d – is it the token endpoint, the publication URL, some other resource?
Expected behaviour
An error message that at least returns the name of the resource that has 404’d.
Screenshots or logs

Environment

Indiekit version: v0.2.0

Fixed in c37ed28a9eebbcdac625edb06062f0b515a63441


How classic is compatible with core?

I'm looking for a reliable source that describes when and how bitcoin classic will activate 2 MB blocksizes, and for how long it will be compatible with core clients. I've been looking around for an official source, but can't find any.

take a look at
https://bitcoinclassic.com/devel/Blocksize.html
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Let us know if there are any open questions!


Valeria/default bubble

Purpose
We want to set the bubble correction as default.
Closes #1313
Content
This PR:

Sets bubble correction as default
Removes the previous specification of bubble CLI option from CI jobs

Review checklist
I have:

followed the codebase contribution guide: https://clima.github.io/ClimateMachine.jl/latest/Contributing/
followed the style guide: https://clima.github.io/ClimateMachine.jl/latest/DevDocs/CodeStyle/
followed the documentation policy: https://github.com/CliMA/policies/wiki/Documentation-Policy
checked that this PR does not duplicate an open PR.

In the Content, I have included

relevant unit tests, and integration tests,
appropriate docstrings on all functions, structs, and modules, and included relevant documentation.

[x] I have read and checked the items on the review checklist.

I'm not sure why the MPI restart test would fail. The other ones appear to be MSE table changes.
@szy21 what do you think?

The MPI restart test had problems recently, and we changed it to soft fail, so don't worry about it. The other simulations look good to me.

bors r+


[SDC-SyN] Generate a fieldmap template on MNI152NLin2009cAsym space to replace current prior

Calculate a new fieldmap average pooling datasets from OpenNeuro that have either fieldmaps or PEPOLAR acquisitions.
The fieldmap average should NOT be masked within the brain.
Then, upload the average to TemplateFlow and remove the old atlas.

Would it make sense to also include fieldmaps from pepolar b=0 acquisitions? We could get many of these from HCP or ABCD.

Update: this seems still pertinent, and we could ensure smoothness by averaging B-Spline coefficients (which is a lot less data, and do not need interpolation when mapping on to the target space because they are kept on the same grid). If we generate this template (edited the title of the issue for appropriateness), then we will be able to remove one transformation hop (and hence a potential point of failure) here https://github.com/nipreps/sdcflows/blob/aa1ff974429d245c8c7f76f886f7de27e8650865/sdcflows/workflows/fit/syn.py#L156-L161.

@mattcieslak
Would it make sense to also include fieldmaps from pepolar b=0 acquisitions? We could get many of these from HCP or ABCD.

That would be convenient for dMRIPrep in general, the same way we generated a "boldref" template for fMRIPrep a while ago. I'll open an issue there.
In the context of this PR, the idea is to create an average of fieldmaps (i.e., to get a sense of where most of the distortion is happening).

Is there also a source of GRE fieldmaps? We're finding that the pepolar fieldmaps don't match very well with GRE fieldmaps even with the same shim settings

We're finding that the pepolar fieldmaps don't match very well with GRE fieldmaps even with the same shim settings

This is not surprising - the smoothing/despiking of GRE fieldmaps make them "underfit", however PEPOLAR fieldmaps tend to overfit, actually.
With the work towards 1.4.0, we'll be able to regularize both GRE and PEPOLAR fieldmaps with B-Splines and bring them closer to one another.
That said, I think for this average we can pool in both types of fieldmap.

This doesn't seem like a current need - please correct me if I'm wrong, @effigies (and reopen)

This is not surprising - the smoothing/despiking of GRE fieldmaps make them "underfit", however PEPOLAR fieldmaps tend to overfit, actually.

The differences were fairly big. For example the entire OFC would be displaced in opposite directions in the SyN SDC and B0 fieldmap estimates. In our experiment the B0 and PEPOLAR always had the same direction of displacements but minor differences in the displacement distance.


[FEATURE] Release binaries in AppImage format

Pre-built binaries has compatiblity issues accross glibc versions, package them in AppImage to avoid this issue

Done as #258


There is no way to delete a tool that was added to a thread using "Add Tools"

We have the ability to "Add Tools" dynamically when we are chatting with an assistant.
There is no option available to delete the tools that was added using "Add Tools" if the user wants to remove this tool from this thread.
We should provide this ability to delete the tools that was added using "Add Tools"

You can remove tools: click the green checkmark and the tool will be removed.

I have seen this work in previous build but with latest build this seems to be broken and tracked in https://github.com/gptscript-ai/desktop/issues/221.
Will close this issue once i am able to validate this workflow.

Tested with latest build with commit id - 731700663e
I am able to click on the tools that have been added to get it removed. But i see the tool calls continue to work even after tool is removed.
Steps to reproduce the problem:

Start a chat with Tildy and using Add tools and  add outllook mail tool.
Ask for information about the mail and we see it work.
Using "Add Tool" option , click on the selected outllook mail` tool and wait for it to be unselected and close the tool catalog.
We get a confirmation message about tool being removed in the chat window.
Ask for information about the mail and we see it continue to work.

Expected Behavior
This should not have succeeded since we dont have access to the mail tool anymore.

Quit the thread and relaunch the thread.

Ask for information about the mail and we see it fail with this error:

Is all this  because of LLM halucinating this call ?

PR: https://github.com/gptscript-ai/desktop/pull/245

Tested with electron build - b4977d0
I am able to remove the tools from chat thread by unselecting the tool from tool catalog page.
Even after the tool gets removed , LLM keeps calling the tool when there is some queries relating to the deleted tool's expertise. In my case I added outlook mail tool and then removed it.
If i ask any question relating to mail, I see a call being made to email tool call and it fails to fetch any information as expected.

Why would LLM be making the tool call to email if this was not even available to it at this time ?
Can we prevent the call from being made to the deleted tools ?

The LLM sees the tool call in the chat history and tries to use it again. I don't know if there is a way we can tell the LLM not to do that.


Python 3.6 date time zone parsing issue

https://github.com/napalm-automation-community/napalm-srlinux/blob/8b7f5359ad87605bd1c2a5d311c83992efdf28c8/napalm_srl/srl.py#L295
Up to and including Python 3.6, 'strptime' has an issue with time zone parsing. Suggest to use python-dateutil (https://dateutil.readthedocs.io/en/stable/) instead

With https://github.com/napalm-automation-community/napalm-srlinux/pull/18 minimum supported Python version is 3.7, which parses time zone correctly. Closing


rename   ATG1/ULK1 kinase complex

Hi
Continuation of requests following review of Autophagy paper
I think that GO:1990316 ATG1/ULK1 kinase complex should be renamed 'Atg1/ULK kinase complex'.  ie 'ULK1' replaced with 'ULK'
Several papers describe the ULK1/2 complex as the mammalian ortholog of the yeast Atg1 complex.
eg: PMID: 28976798: The ULK1/2 complex is the mammalian ortholog of the yeast Atg1 complex.
PMID:27765496:  The ULK complex is composed of protein kinases ULK1 and ULK2 in association with....
PMID: 26921696: calls the complex the ULK1 complex but also points out that: ULK1 and ULK2 show high functional redundancy; both must be knocked out in mouse embryonic fibroblasts to robustly inhibit nutrient-dependent autophagy [17].
Also the other GO terms with 'ATG' use the format 'Atg'
Then the definition would need revising too
A protein complex consisting of Atg1/ULK and Atg13 along with other proteins that regulate its function (e.g. Atg17 in yeast or RB1CC1(FIP200) in mammals). This complex has serine/threonine protein kinase activity and is involved in autophagosome formation.
Unfortunately if you agree there are 4 other terms name to rename, and term definitions.
GO:1904745 ATG1/ULK1 kinase complex assembly
GO:1905864 regulation of ATG1/ULK1 kinase complex assembly
GO:1905866 positive regulation of ATG1/ULK1 kinase complex assembly
GO:1905865 negative regulation of ATG1/ULK1 kinase complex assembly
What do you think?
Ruth

We should use the name that is most commonly used in the community as the primary name, as long as it does not conflate terms. We can add the others as exact synonyms. This is standard GO policy.

Thanks David
Looking at this
ATG1/ULK1 kinase complex 34 papers
ATG1/ULK kinase complex 8 papers (at least on using term above too)
ATG1/ULK1 complex 38 papers
ULK1 complex 209 papers
ULK1 kinase complex 22 papers
ULK complex 39 papers
There are also lots of other variations on this ;(
Let's leave the ULK part of the name as it is, but I think the ATGs need to change to Atg as this is definately being used more in both GO and literature.
And add aliases:
ULK1 complex
ULK complex
Will you have time to do this before your holiday?
Best
Ruth

new definition:
A protein complex consisting of Atg1 (or Atg1 homologs e.g. ULK1, ULK2 in mammals) and Atg13 along with other proteins that regulate its function (e.g. Atg17 in yeast or RB1CC1(FIP200) in mammals). This complex has serine/threonine protein kinase activity and is involved in autophagosome formation.
It isn't clear to me that all complexes have ULK2 or ULK1, as there is functional redundancy. So I have left the definition rather vague. Will that be ok?

I actually thought I got all of the ATG-->Atg changes yesterday, but I will double-check. I will add the aliases as you suggest. I think the suggested definition is fine. I will do these edits this afternoon.

excellent
I hadn't realise you had done the Atgs, I was looking at QuickGO which is probably out of sync with you
Ruth


Compile into static svg and integrate with iconify?

🥰 需求描述 | Feature Description
Now lobe-icons can only be used in react components (or astro of course), if the icons can be built into static svgs, they can be used in more ways, like iconify.
🧐 解决方案 | Proposed Solution
Maybe build svgs in CI?
📝 补充信息 | Additional Information
If these icons got integrated with iconify's ecosystem, then people can use web-components or unocss's css icons to use these icons in other frameworks.

todo


delete dist/* files from repository

AFAIK it should not be tracked (and make the git tree cluttered)

That sounds like a good plan. I also wanted to clean up and refactor something at some point, but haven't found the time yet to look more closely at JS/TS and VSCode extensions.

I would love to help refactoring everything to TS. For me, it is a pain to write with plain JS.

That is my plan to. Im not shure if @jgclark will support this and since I do not have time currently I have not asked yet. (And # 38 is not merged, which is important, however, as you just pointed out.)
I set up a local dev container, but never got further, since I've only written small TS scripts in ready-made environments so far, I still have to learn how the whole thing works with environments exactly and a few language specifics.

Thanks for the comments, and I'm happy to support your suggestions about TS.
When I took on maintaining this I hardly knew JS, but I've since learned more of that, and now use flow for typing in another project. That was chosen over TS, partly because of the additional complexity of setting up TS for non-professionals (like me). It just means you might need to guide me to how to get going with TS in VSCode, so I can build and test.


Avoid Address serialisation roundtrip

Addresses of TxOut in blocks are in a CompactAddress form. We deserialise this format and store it in Generic.txOutAddress. Later we serialise it again 2 times before storing it to the db. We can probably avoid these roundtrips.

When we serialize it again its not as a CompactAddress but as a regular Address right?

Maybe we could expand the Generic.Tx struct to contain both the Bech32 encoded version and the far ByteString.

When we serialize it again its not as a CompactAddress but as a regular Address right?

Yes, we serialise the Address, however  CompactAddress is just a serialized address in the form of a ShortByteString https://github.com/input-output-hk/cardano-ledger-specs/blob/master/shelley/chain-and-ledger/executable-spec/src/Shelley/Spec/Ledger/CompactAddr.hs#L46

Maybe we could expand the Generic.Tx struct to contain both the Bech32 encoded version and the far ByteString.

I think the node doesn't use Bech32/Base58 anywhere, we will have to do this rendering for all addresses (which is quite expensive). However a serialised address is one step closer to this format than an Address

It looks like there hasn't been any activity on this issue for a some time. We're closing it for now. If you're still experiencing this problem or have any updates, please reopen or create a new issue. Your feedback is valuable, thank you!


(35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <IP_ADDRESS>:8090

We are running cardano-sl in a Docker container. Portforwarding is working but cURL is failing.
cURL on host:
root@server-1:/home/cardano# curl --cacert /home/cardano/.cardano/tls/client/ca.crt --cert /home/cardano/.cardano/tls/client/client.crt --key /home/cardano/.cardano/tls/client/client.key --url https://<IP_ADDRESS>:8090/api/v1/node-info --verbose
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8090 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /home/cardano/.cardano/tls/client/ca.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <IP_ADDRESS>:8090
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to <IP_ADDRESS>:8090

cURL inside docker:
cardano@36741093271e:~/cardano-sl$ curl --cacert state-wallet-mainnet/tls/client/ca.crt --cert state-wallet-mainnet/tls/client/client.crt --key state-wallet-mainnet/tls/client/client.key --url https://<IP_ADDRESS>:8090/api/v1/node-info --verbose
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8090 (#0)
* found 1 certificates in state-wallet-mainnet/tls/client/ca.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: Cardano SL Server Node (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: O=Input Output HK,CN=Cardano SL Server Node
* 	 start date: Sun, 04 Nov 2018 00:11:13 GMT
* 	 expire date: Mon, 04 Nov 2019 00:12:13 GMT
* 	 issuer: O=Input Output HK,CN=Cardano SL Self-Signed Root CA
* 	 compression: NULL
* ALPN, server accepted to use http/1.1
> GET /api/v1/node-info HTTP/1.1
> Host: <IP_ADDRESS>:8090
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Date: Sun, 04 Nov 2018 17:25:28 GMT
< Server: Warp/3.2.22
< Content-Type: application/json;charset=utf-8
<
* Connection #0 to host <IP_ADDRESS> left intact
{"data":{"syncProgress":{"quantity":100,"unit":"percent"},"blockchainHeight":{"quantity":1756978,"unit":"blocks"},"localBlockchainHeight":{"quantity":1756978,"unit":"blocks"},"localTimeInformation":{"differenceFromNtpServer":{"quantity":53,"unit":"microseconds"}},"subscriptionStatus":{"<IP_ADDRESS>:3000:0":"subscribed"}},"status":"success","meta":{"pagination":{"totalPages":1,"page":1,"perPage":1,"totalEntries":1}}}

Any idea how we can solve this?

Solved by allowing connection from any host, editing connect-to-mainnet:
  --wallet-address <IP_ADDRESS>:8090


100.15 with workflow change

Build for original PR failed due to https://stackoverflow.com/questions/73374893/nuget-restore-issue-xamarin-ios-csharp-targets-was-not-found
This PR updates the github actions build workflow to install the Xamarin VS component, because that is no longer installed on the Windows-latest build runner by default.

@pMaske Microsoft has apparently fixed the problem in the last ~5 hours. I retested the original branch and now it builds without issue. I'm closing this PR in favor of the original PR.


dutch language

i want the countdown in dutch so how do i change Day%!d so i get 5 Dagen instead of 5 Days

Would also appreciate this feature!


Update values.yaml

Changed image tag to latest version.

Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [stable/mychartname])

New Sysdig Helm Chart available this method is deprecated.


TypeError: Cannot destructure property cmcPriceUsd of 'undefined' or 'null'.

After logging in to my portfolio I'm presented with the below message. The app does not continue.
This is on Windows 10
Unhandled Promise Rejection
TypeError: Cannot destructure property cmcPriceUsd of 'undefined' or 'null'.
at ActivityItem (app://-/bundle.js:82430:89)
at beginWork (app://-/bundle.js:111900:36)
at e (app://-/bundle.js:111939:105)
at f (app://-/bundle.js:111939:379)
at G (app://-/bundle.js:111945:329)
at x (app://-/bundle.js:111944:378)
at n (app://-/bundle.js:111944:221)
at B (app://-/bundle.js:111943:117)
at v (app://-/bundle.js:111942:51)
at Object.enqueueSetState (app://-/bundle.js:111873:32)

HyperDEX Nightly 0.0.0-a36030c-<IP_ADDRESS>9
Electron 2.0.1
win32 10.0.16299
Locale: en-US

I think we fixed this a while back. @CHMEX Do you still see this in the latest alpha version?


This page is obsolete

This page shows the old Power BI interface.  The Analytics button is not there anymore.

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

ID: fbbf6763-4952-5335-cefb-ae4e85fd9028
Version Independent ID: cb734eb1-fb6d-b7aa-735a-17b5ba8ca7fd
Content: Use the Analytics pane in Power BI Desktop - Power BI
Content Source: powerbi-docs/transform-model/desktop-analytics-pane.md
Service: powerbi
Sub-service: pbi-transform-model
GitHub Login: @davidiseminger
Microsoft Alias: davidi

yes it is!  (oops)


Add table aws_secrets_manager_secrets. closes #311

Integration test logs

Logs
No env file present for the current environment:  staging
 Falling back to .env config
No env file present for the current environment:  staging
customEnv TURBOT_TEST_EXPECTED_TIMEOUT undefined

SETUP: tests/aws_secrets_manager_secret []

PRETEST: tests/aws_secrets_manager_secret

TEST: tests/aws_secrets_manager_secret
Running terraform
aws_secretsmanager_secret.named_test_resource: Creating...
aws_secretsmanager_secret.named_test_resource: Creation complete after 6s [id=arn:aws:secretsmanager:us-east-1:388460667113:secret:turbottest93948-ZZ2Wmt]

Warning: Deprecated Resource

The null_data_source was historically used to construct intermediate values to
re-use elsewhere in configuration, the same can now be achieved using locals

Warning: Deprecated Attribute

  on variables.tf line 49, in resource "aws_secretsmanager_secret" "named_test_resource":
  49: resource "aws_secretsmanager_secret" "named_test_resource" {

Use the aws_secretsmanager_secret_rotation resource instead

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

account_id = "388460667113"
aws_partition = "aws"
aws_region = "us-east-1"
resource_aka = "arn:aws:secretsmanager:us-east-1:388460667113:secret:turbottest93948-ZZ2Wmt"
resource_name = "turbottest93948"

Running SQL query: test-get-query.sql
[
  {
    "account_id": "388460667113",
    "akas": [
      "arn:aws:secretsmanager:us-east-1:388460667113:secret:turbottest93948-ZZ2Wmt"
    ],
    "arn": "arn:aws:secretsmanager:us-east-1:388460667113:secret:turbottest93948-ZZ2Wmt",
    "deleted_date": null,
    "description": "Test secret.",
    "kms_key_id": null,
    "last_accessed_date": null,
    "last_rotated_date": null,
    "name": "turbottest93948",
    "owning_service": null,
    "partition": "aws",
    "primary_region": null,
    "region": "us-east-1",
    "replication_status": null,
    "rotation_enabled": null,
    "rotation_lambda_arn": null,
    "rotation_rules": null,
    "secret_versions_to_stages": null,
    "tags": {
      "foo": "bar"
    },
    "tags_src": [
      {
        "Key": "foo",
        "Value": "bar"
      }
    ],
    "title": "turbottest93948"
  }
]
✔ PASSED

Running SQL query: test-list-query.sql
[
  {
    "arn": "arn:aws:secretsmanager:us-east-1:388460667113:secret:turbottest93948-ZZ2Wmt",
    "name": "turbottest93948",
    "region": "us-east-1"
  }
]
✔ PASSED

Running SQL query: test-notfound-query.sql
null
✔ PASSED

Running SQL query: test-turbot-query.sql
[
  {
    "account_id": "388460667113",
    "akas": [
      "arn:aws:secretsmanager:us-east-1:388460667113:secret:turbottest93948-ZZ2Wmt"
    ],
    "arn": "arn:aws:secretsmanager:us-east-1:388460667113:secret:turbottest93948-ZZ2Wmt",
    "name": "turbottest93948",
    "region": "us-east-1",
    "tags": {
      "foo": "bar"
    },
    "title": "turbottest93948"
  }
]
✔ PASSED

POSTTEST: tests/aws_secrets_manager_secret

TEARDOWN: tests/aws_secrets_manager_secret

SUMMARY:

1/1 passed.

Example query results

Results
Basic info
select
  name,
  created_date,
  description,
  last_accessed_date
from
  aws_secrets_manager_secret;

+-----------+---------------------+-----------------+---------------------+
| name      | created_date        | description     | last_accessed_date  |
+-----------+---------------------+-----------------+---------------------+
| stmp      | 2021-04-20 14:07:58 | Test secret     | <null>              |
| test-stmp | 2021-04-20 06:26:24 | testing secret. | 2021-04-20 00:00:00 |
+-----------+---------------------+-----------------+---------------------+

List secrets whose automatic rotation is not enabled
select
  name,
  created_date,
  description,
  rotation_enabled
from
  aws_secrets_manager_secret
where
  rotation_enabled = 'false';

+-----------+---------------------+-----------------+------------------+
| name      | created_date        | description     | rotation_enabled |
+-----------+---------------------+-----------------+------------------+
| test-stmp | 2021-04-20 06:26:24 | testing secret. | false            |
+-----------+---------------------+-----------------+------------------+

List secrets whose automatic rotation interval is greater tha 7 days
select
  name,
  created_date,
  description,
  rotation_enabled,
  rotation_rules
from
  aws_secrets_manager_secret
where
  rotation_rules -> 'AutomaticallyAfterDays' > '7';

+-----------+---------------------+-----------------+------------------+-------------------------------+
| name      | created_date        | description     | rotation_enabled | rotation_rules                |
+-----------+---------------------+-----------------+------------------+-------------------------------+
| stmp      | 2021-04-20 14:07:58 | Test secret     | true             | {"AutomaticallyAfterDays":30} |
| test-stmp | 2021-04-20 06:26:24 | testing secret. | false            | {"AutomaticallyAfterDays":30} |
+-----------+---------------------+-----------------+------------------+-------------------------------+

List secrets which are not replicated in other regions
select
  name,
  created_date,
  description,
  replication_status
from
  aws_secrets_manager_secret
where
  replication_status is NULL;

+------+---------------------+-------------+--------------------+
| name | created_date        | description | replication_status |
+------+---------------------+-------------+--------------------+
| stmp | 2021-04-20 14:07:58 | Test secret | <null>             |
+------+---------------------+-------------+--------------------+

Logs

SETUP: tests/aws_secretsmanager_secret []

PRETEST: tests/aws_secretsmanager_secret

TEST: tests/aws_secretsmanager_secret
Running terraform
data.aws_region.alternate: Refreshing state...
data.aws_caller_identity.current: Refreshing state...
data.aws_partition.current: Refreshing state...
data.aws_region.primary: Refreshing state...
data.null_data_source.resource: Refreshing state...
aws_secretsmanager_secret.named_test_resource: Creating...
aws_secretsmanager_secret.named_test_resource: Creation complete after 4s [id=arn:aws:secretsmanager:us-east-1:986325076436:secret:turbottest8741-hFxx9U]

Warning: Deprecated Resource

The null_data_source was historically used to construct intermediate values to
re-use elsewhere in configuration, the same can now be achieved using locals

Warning: Deprecated Attribute

  on variables.tf line 49, in resource "aws_secretsmanager_secret" "named_test_resource":
  49: resource "aws_secretsmanager_secret" "named_test_resource" {

Use the aws_secretsmanager_secret_rotation resource instead

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

account_id =<PHONE_NUMBER>36
aws_partition = aws
aws_region = us-east-1
resource_aka = arn:aws:secretsmanager:us-east-1:986325076436:secret:turbottest8741-hFxx9U
resource_name = turbottest8741

Running SQL query: test-get-query.sql
[
  {
    "account_id": "986325076436",
    "akas": [
      "arn:aws:secretsmanager:us-east-1:986325076436:secret:turbottest8741-hFxx9U"
    ],
    "arn": "arn:aws:secretsmanager:us-east-1:986325076436:secret:turbottest8741-hFxx9U",
    "deleted_date": null,
    "description": "Test secret.",
    "kms_key_id": null,
    "last_accessed_date": null,
    "last_rotated_date": null,
    "name": "turbottest8741",
    "owning_service": null,
    "partition": "aws",
    "primary_region": null,
    "region": "us-east-1",
    "replication_status": null,
    "rotation_enabled": null,
    "rotation_lambda_arn": null,
    "rotation_rules": null,
    "secret_versions_to_stages": null,
    "tags": {
      "foo": "bar"
    },
    "tags_src": [
      {
        "Key": "foo",
        "Value": "bar"
      }
    ],
    "title": "turbottest8741"
  }
]
✔ PASSED

Running SQL query: test-list-query.sql
[
  {
    "arn": "arn:aws:secretsmanager:us-east-1:986325076436:secret:turbottest8741-hFxx9U",
    "name": "turbottest8741",
    "region": "us-east-1"
  }
]
✔ PASSED

Running SQL query: test-notfound-query.sql
null
✔ PASSED

Running SQL query: test-turbot-query.sql
[
  {
    "account_id": "986325076436",
    "akas": [
      "arn:aws:secretsmanager:us-east-1:986325076436:secret:turbottest8741-hFxx9U"
    ],
    "arn": "arn:aws:secretsmanager:us-east-1:986325076436:secret:turbottest8741-hFxx9U",
    "name": "turbottest8741",
    "region": "us-east-1",
    "tags": {
      "foo": "bar"
    },
    "title": "turbottest8741"
  }
]
✔ PASSED

POSTTEST: tests/aws_secretsmanager_secret

TEARDOWN: tests/aws_secretsmanager_secret

SUMMARY:

1/1 passed.

@sayan133 I think this table should be called aws_secretsmanager_secret, as this is the name that Terraform uses (https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/secretsmanager_secret).


Not ready yet Qt5

This is an attempt to get @mingwandroid's recipe from qttesting in conda-forge. I got this to build on Linux locally, let us see how it goes here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Should this be on a separate branch? We might need to build both Qt4 and Qt5 for a while until all software is ported over. Apologies if it is that already...
Thanks for pushing on with this @ocefpaf

@gillins is right, this needs to be in a different branch in case there's need to make new packages for Qt4.

But great work at making this pass!

So typically master is the latest version of the package and we add branches to the main feedstock for old versions still in maintenance (e.g. Qt4). As all branches on the main feedstock are designed to deploy, this works flawlessly.
That being said, it would be nice if we could finish up PR ( https://github.com/conda-forge/qt-feedstock/pull/23 ) before this goes in master. Though it is not strictly necessary.

So we need to create a qt4 branch for the old package?

Should this be on a separate branch? We might need to build both Qt4 and Qt5 for a while until all software is ported over. Apologies if it is that already...

I prefer to put Qt4 in a branch and use master for Qt5, this is usually what we do. Do you guys agree?
PS: I will wait for #23 to be merged to do so.

So we need to create a qt4 branch for the old package?

Done! @gillins I would like to merge #23 before this one, but if that does not happen would you mind re-directing #23 to the qt4 branch?

would you mind re-directing #23 to the qt4 branch?

Done. Let me know if/when you want me to look at the Windows build for Qt5. I think we are still waiting for a patch to use webkit for py<35?

I think we are still waiting for a patch to use webkit for py<35?

Those patches were created by @mingwandroid and they are part of our package too.

IMHO you should use Webkit on all Windows versions.

IMHO you should use Webkit on all Windows versions.

Agreed. Just to have the same Web backend for all VS versions.

Done. Let me know if/when you want me to look at the Windows build for Qt5. I think we are still waiting for a patch to use webkit for py<35?

Thanks @gillins!
@ccordoba12 and @mingwandroid let's merge this and my next PR will add the Windows stuff.

Great job @ocefpaf!

Great job @ocefpaf!

Only possible with great reviewers and my amazing copy-n-paste abilities from your's and @mingwandroid's work :stuck_out_tongue_winking_eye:

Great job at moving the ball then ;-) I'm so swamped that I'd have never done this!

Great job at moving the ball

That credit I can take :smile:

I'm so swamped that I'd have never done this!

But I will bug you in pyqt soon :wink:

But I will bug you in pyqt soon

No prob, but PyQt is very easy compared to Qt ;-)

Nice work here guys !
Do you plan to add a 5.7 (and 5.8?) build ?

Qt 5.7+ needs a C++ 11 capable compiler, something that leaves Python 2.7 on Windows out of the picture.
So I guess that's a no, but I can't answer for all maintainers.

Ok. But do you think it could be compiled on Python > 3 (for Linux first and then OSX and Windows) ?
That would be good to have those 5.7 and 5.8 versions here.
Wheels are provided for PyQt5 on pypi (only 5.7 at the moment). So there is no rush as it's a good alternative. It would just more convenient to have everything on conda-forge. But I know how difficult it is to compile Qt :-)

Ok. But do you think it could be compiled on Python > 3

You could give it try with the current recipe, but I think @ocefpaf wants PyQt 5.6 packages first.


Add Windows Calm port.

This is a small change to add the Windows "check login" port that Calm uses to the security policy.

Wrong button.


alsa-{oss,tools}: 1.1.6 -> 1.1.8

Motivation for this change
alsa-oss and alsa-tools were outdated. They were probably outdated because the version was not a variable that automated updaters could pick up.
This PR also separates version from name and updates the version.
EDIT: In the meantime alsa-oss was updated to 1.1.8. There is no version bump for this package in this PR, but this PR does split name from version.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build alsaOss alsaPlugins alsaPluginWrapper mar1d

@GrahamcOfBorg build alsaOss alsaPlugins alsaPluginWrapper mar1d


Update http4s-async-http-client to 0.23.2

Updates org.http4s:http4s-async-http-client from 0.23.0-RC1 to 0.23.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s", artifactId = "http4s-async-http-client" } ]

labels: library-update, semver-pre-release

Superseded by #210.


Doubt

Hi!
Thanks so much for making this resource available, it is very useful as  a quick benchmark for new ideas. I was wondering if you used in your papers (v1 and v2) resnets trained started from Imagenet weights? It seems from your code that the default is False, so they would be trained from scratch, but the papers do not mention this detail, I think, and I just wanted to double-check with you..
Thanks!

Hi @agaldran,
We don’t use pretraining to avoid any confounders in analysis. We have also tried the pretraining, there seems no significant difference (but we don’t have statistic analysis). It should be very easy to use.
cc: @ThreeSRR
Cheers,
Jiancheng

That's alright, thanks Jiancheng for the quick reply and the info, and thanks again for the resource.


How to get public key stored in enclave?

Hi, I'm very confused understanding this code
I understood as follows

when we boot encalve, it create a key pair (public key and private key)
public key and private key is stored inside of encalve
private key never leaves from enclave.

In this case, I want to know what is public key stored in enclave.

Attestation Doc contains public key of enclave (is it correct?)

Now, As you can see here, It requires me to enter public key
But, I don't know... I want to know the public key stored in encalve
It's confused.. please somone help me
let public_key = ByteBuf::from("my super secret key");
let hello = ByteBuf::from("hello, world!");

let request = Request::Attestation {
        public_key: Some(public_key),
        user_data: Some(hello),
        nonce: None,
};

the attestation process is documented here: https://github.com/aws/aws-nitro-enclaves-nsm-api/blob/main/docs/attestation_process.md . You can create a Key Pair and supply the Public key to the attestation api. This Public key will be then included in the attestation document, which the receiver of the attestation doc can use to encrypt the responses back to the enclave. This ensures, only the enclave from where the request originated can decrypt the response.


[menu] Highlight is slow

I can feel a delay when moving through the items with the mouse:
https://github.com/user-attachments/assets/67707aa4-9d4f-408f-95f6-9360e0f14f8d
Radix:
https://github.com/user-attachments/assets/5d14aeaf-cd23-4f18-8352-0d763b3dcfb1

Looks more pronounced in Safari in dev mode - in Chrome using React dev mode, it's speedy even with 4-6x slowdown, and Safari seems ok (but not as good) in prod mode.
To solve this fully even with long lists, useListNavigation needs to offer DOM highlights (activeIndex change) without any re-renders, which has to go through React's diffing/memo comparisons of each item before highlighting. There may be some other optimizations to make as well. This is not fully trivial so I removed it from the first alpha milestone but is solvable soon

I'm happy to try to optimize it, but likely after I'm back from my PTO (in January)

I've created an experiment here https://github.com/mui/base-ui/pull/1128 (demo) and the Base UI Menu highlights are much faster on Safari in the experiments' "isolated" context. This, along with it being so different to Chrome, suggests that something in the docs' CSS may be causing a perf slowdown in Safari specifically?

It turns out this is caused by our auto-modality pointer-events: none, which "scales" negatively in terms of performance the larger the page is. Chrome is unaffected, but Safari/Firefox are.
That method also isn't fully robust for modality, as the parent that receives it could be visually collapsed compared to any children (as what happened with the side nav).
We'll need to find an alternative (probably the internal backdrop idea, or a runtime error if Backdrop is missing).


Hook revm and inspectors into gwyneth

Currently does not builds because of:

But when i use a local revm-inspector to remove the hacky uncommenting:

I ran into multiple issues with trait bound violation.

@Brechtpd
If you did the make install (from packages/protocol) - currently smart contract verification for L1 is commented out - you can then do the:

deploy xERC20 (same as in revm repo's https://github.com/taikoxyz/revm/blob/gwyneth-debug-shit/bins/revm-test/contracts/ERC20.sol ) both on L2A and L2B
verify those contracts so easier to see in the explorer
fire away an xTransfer()
with the script ./scripts/deploy_and_xtransfer.sh (from packages/protocol directory, right after make install started the rbuilder)

Currently it fails with Awaiting internal transactions for reason, but you will be able to see it in the explorer - maybe the logs in EL or rbuilder gives more insights, but currently this is where i am at.


Flickering div on chrome

Hello,
First of all congrats on this useful project.
I've a problem that only happens on chrome. Basically when i scroll down using chrome  the top of the site flickers. I've removed the skrollr instructions and it still happens. i'll post a link with a screenshot:
http://d.pr/i/ZDxQ
If you need any other information, just let me know.
Thanks in advance,
Rúben

I had the same issue as @burbanczyk , and when I added an maps-iframe the scroll is smooth. How can that be?

I had the same issue as @burbanczyk and when I add a maps iframe the scroll becomes smooth. Strange solution, how can that be?


can't run huntlabs/hunt-skeleton

hunt 1.6.1: target for configuration "library" is up to date.
hunt-extra 1.0.0: building configuration "library"...
../../../../.dub/packages/hunt-extra-1.0.0/hunt-extra/source/hunt/concurrency/Executors.d(402,12): Error: interface hunt.util.Common.Callable(V) at ../../../../.dub/packages/hunt-extra-1.0.0/hunt-extra/source/hunt/util/Common.d(110,1) conflicts with struct core.thread.context.Callable at /usr/include/dmd/druntime/import/core/thread/context.d(26,1)
/usr/bin/dmd failed with exit code 1.
may need to add the line
"import hunt.util.Common:Callable;"
to hunt-extra-1.0.0/hunt-extra/source/hunt/concurrency/
FutureTask.d
and
Executors.d
?

it only on dmd 2.093
on dmd 2.0921 is no problem

Thanks. It's fixed in commit https://github.com/huntlabs/hunt-extra/commit/37a2e9cde7fe728f3181ea9e44da97577712b01d.


respond only work when it's in the first state that receiving the EVENT

Description
When using respond to send events to parent/actors, the respond action has to be put in the state that first receives the EVENT.
If I use an always to transition state to another one, then the respond will not work as my expected (the respond-ed EVENT will be lost)
Does this behavior is expected?
Expected Result
The respond can send the EVENT to the latest valid eventOrigin.
if the current behavior is expected, then I'd like to ask for adding a new feature to support this.
Actual Result
The EVENT with respond is lost.
Reproduction
https://codesandbox.io/s/optimistic-river-epqlm?file=/src/index.ts
    selecting: {
      entry: respond("TOKEN1"),
      always: [
        {
          target: "waitingForCode",
          actions: respond("TOKEN2")
        }
      ]
    }

In the above transition, only "TOKEN1" will be sent successfully, but the "TOKEN2" will be lost:

Additional context
According to the source code of respond:
https://github.com/statelyai/xstate/blob/2e126cb54f8f99ba3478774b6777ab9a8d8dd6b6/packages/core/src/actions.ts#L327-L341
I think the eventOrigin can be reused if the user wants.
For me, I have to write a workaround helper function named respondLastOrigin to fulfill my requirement:
import {
  actions,
}                 from 'xstate'

interface ContextLastOrigin {
  lastOrigin?: string,
}

const respondLastOrigin = (
  event: Parameters<typeof actions.send>[0],
) => actions.send(
  event,
  {
    to: (
      ctx: ContextLastOrigin,
    ) => ctx.lastOrigin!,
  },
)

export {
  type ContextLastOrigin,
  respondLastOrigin,
}

It will be great if the official respond can support this kind of scenario: the machine can always respond to the latest event origin.

This is something that we’ve recently fixed on the next branch - we prepare a v5 release there. Unfortunately, it’s not possible to change the behavior in v4 - unless we’d introduce an opt-in flag for that

Awesome, it is great to know that we have fixed it in the v5 release!
Is there any plan for publishing the v5 alpha/RC/next version for the community for now? I read a lot about the coming v5 and I'd like to try it as soon as possible.
Thank you very much!

We'll think about publishing a prerelease version sometime soon.

Thank you very much for letting me know that the ?v
5 prerelease will be published soon!
Close this issue and looking forward to it!


Sample Tasks Docs Improvements

Is there an existing issue for this?

[X] I have searched the existing issues

Issue summary
The steps for the lung example model detailed in sample_tasks.md are currently broken - running the dataset conversion gives the following error:
System.AggregateException: One or more errors occurred. ---> System.Exception: Folder contained multiple series.

What documentation should be provided?
New steps that outline how to run the dataset conversion without issue.
AB#6571

This was caused by me running the command in the wrong folder. This documentation requires updating and clarifying, similar to this:
.\InnerEye.CreateDataset.Runner.exe dataset --datasetRootDirectory=C:\Users\a-phessey\Datasets\lung_dicom --niftiDatasetDirectory=lung_nifti --dicomDatasetDirectory=LCTSC --geoNorm 1 1 3 --groundTruthDescendingPriority esophagus spinalcord lung_r lung_l heart