Max cap

Pause contract on reaching a max cap threshold
0 means off

If the merged value reaches the cap, it should let the user merge the delta between the cap and the current merged value
We should have the option to set the caps in the other token (not WEWE) - To make it easier to show the user how much of the token can be merged (lower prio)


Various Changes - (refactor console module)

Changes:

wasmstation/src/fb.rs was greater than 1000 lines and quite unreadable with all the tests scattered throughout the file. Because of this, I split the module up into five different sub-modules for blit, line (which includes hline and vline), oval, rect, and text.

All tests related to their function were moved into their own module behind a #[cfg(test)] for faster compile time.

Document public functions and modules.
Re-export all framebuffer functions in the console module and make the framebuffer module private.

This makes using the console module much cleaner.

Make sure all framebuffer module functions utilize core and not std to prepare for potential #![no_std] in wasmstation-core.
Simplify utils::default_framebuffer into constant value.

Note that all the functions in this module could be turned constants/const fns in the future

Make console::Api manage save_cache and needs_write.

This was changed so other Backends in the future can use the same diskw and diskr utilities.
Even still lots of the disk functionality is in WasmerBackend, this should be abstracted more into console::Console or console::Api in the future, but for now it's okay.

Move Source<T>/Sink<T> Vec<T> and [T; N] implementations into crate root.
cargo fmt on the whole crate

I agree, vline and hline should have test coverage, I forgot to add that when I wrote the PR, probably because I was unfamiliar with ArrayScreen.
You're right, this PR is way too big to review at once. While I was writing it I found it hard to make the changes step-by-step. I'll be sure to keep my PRs smaller in the future 👍🏽. If once you get back into the codebase you see that I've butchered some of the code you wrote in the console module I'd be happy to change it back.
I'll merge this PR into main and create another PR today with some tests for vline and hline for you to review.

Sounds great! I also noticed an issue with blit() (probably old).
I opened https://github.com/wasmstation/wasmstation/issues/29. I may be able too look at that in the next couple of days, I assume it's probably something very simple. Also, it appears we're lacking unit tests for that too..


chore(main): release audit 1.50.0

:robot: I have created a release beep boop
1.50.0 (2023-09-04)
Features

better registry api fetch (d60866b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/sandworm-hq/sandworm-audit/releases/tag/audit-v1.50.0 :sunflower:


implicitly sized decimal

Currently you may do =63 and or =601 and it'll use the smallest integer that it can that's still in octets. So 63'd be a u8 and 601 a u16. In talking about hext with someone during an interview, they raised a good point: that is not what you may expect for a binary format. Should we make it so using decimal without a size is a syntax error? Set a default size, but explicitly in the header? Should it error if it overflows?

We could always assume them to be bytes. That seems like a fine solution? Why assume at all though? We'll sleep on it,

bytes, they're bytes. we think this is the best solution. now to implementation!


Add packetEncoding for Hysteria 2

As discussed in https://github.com/v2fly/v2ray-core/pull/3147#discussion_r1749287934, add packetEncoding for hysteria2. The code is almost the same as trojan's.

请问这一项配置是否适用于vmess+hysteria2？


Duplicated actions between PULL REQUESTS view and ISSUES view

For example the Configure and the Reload view could live top level on the Viewlet action bar. Currentyl these actions live both on the PULL REQUEST view and the ISSUES view bringing unneeded details to an already hectic view.

The only action that makes sense to move to the viewlet level is the Refresh. The configure and add actions are both very specific to either issues or PRs. However, splitting the refresh into issues and PRs is nice so that you are only refreshing the ones that you want to refresh (I usually only care about refreshing either issues or PRs, not both at the same time).
@RMacfarlane what do you think here?

My usual use case for refreshing one of the views is that I know some data on GitHub has changed, like I've assigned myself an issue and I want the issues view to be updated. So I think my preference is for keeping them separate, but I don't feel too strongly about it

We will keep them separate then.


fix: use correct button text color on website banner

Closes #
✅ Checklist

[x] I have followed every step in the contributing guide (updated 2022-08-15).
[x] The PR title follows the convention we established conventional-commit
[x] I performed a functional test on my final commit

Changelog
Fixed GitHub button text color in the website banner component. It is supposed to be white.

Screenshots
Before

After

💯

nice catch! :)


Accessing the quick menu more than once each time neovim is started results in error about settings being nil.

WARNING
If this is about Harpoon1, the issue will be closed.  All support and everything of harpoon1 will be frozen on master until 4/20 or 6/9 and then harpoon2 will become master
Please use harpoon2 for branch
This happens both on Mac M1 and Arch Linux.
Running neovim 9.5.
Trying to access the quick menu more than once results in the following error being thrown.

i.e. first time I access everything is fine. Next time I access the quick menu the error is trown.
I can however switch to what is in the list using navigate to file X.
I can swap files around or delete them each time I get to access the list. Something happens the second time I try though.
This is how I set harpoon up.
{ 		-- To be able to mark often used files and easily get back to them 		"ThePrimeagen/harpoon", 		branch = "harpoon2", 		config = function() 			require("harpoon").setup({}) 		end, 		dependencies = { 			"nvim-lua/plenary.nvim", 		}, 	},
I've mapped the following to get quick_menu:
map("n", "<leader>hu", function() 	require("harpoon.ui"):toggle_quick_menu(require("harpoon"):list()) end, { desc = "Harpoon Toggle quick menu" })

I managed to solve this.
Turns out I was mapping incorrectly. I should have mapped:
require("harpoon").ui rather than require("harpoon.ui")


Java注解总结 - Jerry Blog

https://shenchao.me/work/2017/02/11/java-annotation/ Comments is Powered by Gitalk

Test

Aagin

Test


Dependent extension activation

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

VS Code Version:
OS Version:

Steps to Reproduce:

create new extension A
specify activation event on file type *.A for the extension A
create extension B
specify activation event on file type *.B for the extension B
specify depedency in extensionDependencies section of package.json of extension B to depend on extension A
open project with *.B file
Observe activation failure on attempt to run B commands:

Consider either activating dependent extensions prior to activating target extension or not blocking  target extension from activation if dependent extension is not activated.

Who could means   then I cannot use of metamask wallet then introduce a wallet layer 2 support smart contract and my tools and as gove in 3 digital currency have project  FPI FRAX/FPI controler  and etc well look I have. App account  c to awaiting connect wallet. ,why donot cooperating  with me as _github.com  only company that is manager fix abd solve any problems in wallet ,,web  please pull request Auodit  record about compounds  nothing attention  and respect.

Consider either activating dependent extensions prior to activating target extension or not blocking target extension from activation if dependent extension is not activated.

The contract we give out is that if extension B depends on extension A, then extension B will activate iff extension A is installed, enabled and activates correctly.
Is there additional error information in the developer tools?

It is reproducible. Here is the commit with workaround:
https://codereview.qt-project.org/gitweb?p=qt-labs/vscodeext.git;a=commit;h=f4a10cac0158f2b80c61bc87b1b1132fc2423636
Preceding commit:  f1ea453799826ce2e578ed21ea578d78d73ed5bb
Here are STR:

git clone https://codereview.qt-project.org/qt-labs/vscodeext
cd vscodeext
git fetch https://codereview.qt-project.org/qt-labs/vscodeext refs/changes/81/516781/5 && git checkout FETCH_HEAD
open in vscode
f5
install qt
command "Qt: register Qt installation"
open sample qmake .pro project
command 'Qt: Load and Build Qt project'

Hey @alexdima, this issue might need further attention.
@SergMariaDB, you can help us out by closing this issue if the problem no longer exists, or adding more information.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Generate Bash completion scripts

It would be nice to have Bash completion scripts for the s2i binary. This shouldn't be too difficult, given that Cobra is used for the CLI interface and Cobra offers a Bash completion generator.

@elyscape sorry for this to take so long, I will have a look tomorrow and provide bash completetions (we already have that for oc and openshift commands, s2i should be no different).

No worries. Thanks for your help on this!

@elyscape it is being merged now... several options:

Use s2i genbashcompletion will give you up-to-date completion for the current s2i binary
You can download generated completion (see contrib/bash) folder.

Fantastic. Thanks for your help!


Add Rules For Clang-Format [BUILD-305]

This PR adds rules for clang-format.
clang-format-check is implemented using the actions API - we can use cache functionality.
In order to check formatting in a repo use: bazel build //... --config clang-format-check
In order to format a repo use: bazel run //bazel/clang_format
explanation:
clang-format-check is defined in the .bazelrc file. Bazel passes all targets (//...) to the clang_format/clang_format_check.bzl:clang_format_check_aspect aspect. Bazel then iterates over files in the target and runs clang-format on it.
The clang format version is searched in the clang_format/choose_clang_format.bzl file. The clang format version is searched only once, and then we use it from the cache.
In order to set up these rules in a project we have to:

import .bazelrc: https://github.com/swift-nav/gnss-converters-bazel/pull/3/files#diff-544556920c45b42cbfe40159b082ce8af6bd929e492d076769226265f215832f
define clang_format_config target with .clang-format file: https://github.com/swift-nav/gnss-converters-bazel/pull/3/files#diff-7fc57714ef13c3325ce2a1130202edced92fcccc0c6db34a72f7b57f60d552a3

PR tested here: https://github.com/swift-nav/gnss-converters-bazel/pull/3

Awesome, a lot of this stuff is new to me too so I'll need a little bit of time to read up on aspects and go over this thoroughly.


adds 'company' & 'revision' tags

correctly reads the 'company' and 'revision' attributes which will then be displayed on the interactiveHTMLbom,
in eagle 7.7 you add user attributes using edit/global attributes/new menu.

Thanks for the PR!  I'm on travel without a computer for a few more days, but will take a closer look as soon as I'm able.

I incorporated your changes, with a couple clerical edits, in the squashed commit a21f00b7b4370b52c641acc2089f18e485d0d527
I rolled the change into main also, because this works with Fusion 360 Electronics as well - with the minor downside that Fusion doesn't currently have any way to access the Global Attributes dialog via the GUI, as Eagle did...  but it can still be invoked by "ATTRIBUTE *" in the command line.
Thanks for contributing!

Great, thanks for that.
Harry

On 20 Dec 2021, at 02:39, Funkenjaeger @.***> wrote:
I incorporated your changes, with a couple clerical edits, in the squashed commit a21f00b https://github.com/Funkenjaeger/brd2json/commit/a21f00b7b4370b52c641acc2089f18e485d0d527
I rolled the change into main also, because this works with Fusion 360 Electronics as well - with the minor downside that Fusion doesn't currently have any way to access the Global Attributes dialog via the GUI, as Eagle did... but it can still be invoked by "ATTRIBUTE *" in the command line.
Thanks for contributing!
—
Reply to this email directly, view it on GitHub https://github.com/Funkenjaeger/brd2json/pull/18#issuecomment-997544022, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHW6AJYVL5SXNXDSQ7K4Z5TUR2JNRANCNFSM5KJVZFJA.
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.


relationship between user/computed BPM for samples and patterns

Hi Matthew,
first of all: bless you for making this app! I think this is going to be very helpful so I salute you for putting your spare time into this. I don't strictly speaking have an issue, but just a confusion.
I simply do not understand how the SP deals with the BPM of samples, how I can affect that in your app, and how this interacts with the BPM of my sequencer patterns. My workflow is as follows:

I compose patterns in Ableton live and export every instrument/loop warped to the same BPM (130)
I assign these loops to different pads, and the SP seems to recognize they're 130BPM in the display
I then sequence the loops in quantized patterns

(Unfortunately, I've been bugged a little bit by how the timing when triggering these loops in a quantized pattern seemed sloppy.)
Being new to your app I was surprised by a couple of behaviors of the SP. Apparently, the machine doesn't precisely compute the tempo: when I read the SD card after it's passed through the machine, I noticed that your app shows the computed BPMs are 129.9 according to the SP. The machine is wrong because the loop lengths are surgically precise to the same length as warped by Ableton.
So what is going on here and what should I be doing? What happens under the hood when I set it to 130 in the BPM fields? What do I do for tempo mode?
Thank you very much for any explanation you might be able to provide.
Cheers,
Rutger

How long are your loops? I can try recreating this this weekend to help better explain it.

8 bars @ 130 bpm. Thanks!

I'm noticing the same issues, I believe it has to do with the internals of the machine and I can't see documented in the manuals- the values are written and read exactly as shown.
I will need to run some tests to figure out exactly what it happening. Thanks for bringing this to my attention, this is actually really interesting.  🧐

My pleasure 🙂 I wonder if this is simply a type of rounding error?


Campaign tracking

#218
I added a method for setting a campaign. This is then sent to Matomo as base params like the user ID.

I'd like to keep the Tracker as non-specific to certain use-cases as possible, meaning as few "set/get XY" methods as possible, hence the whole abstraction through TrackMe's.
Ideally we would add a few helper methods here:
https://github.com/matomo-org/piwik-sdk-android/blob/dev/piwik-sdk/src/main/java/org/piwik/sdk/extra/TrackHelper.java#L114
then it is clear that these two parameters need to be used with a tracked screen view.
In your current solution we also send the campaign fields on every request, but afaik we only need to send the parameter once, with the first tracked screen.
What do you think?

I would keep it as is for two reasons:

Campaign tracking is most commonly used when your app is opened via a deeplink. The deeplink can then open the home screen, a product page etc. What I want to say is that you don't know which screen is opened first and so you don't know where to add a .campaign() like .title() or .dimension().
Under https://developer.matomo.org/api-reference/tracking-api the parameters for campaigns are under Optional User info just like the user ID for example.

This is just my oppinion and if you know how to tackle my first point I'm open for suggestions :)

Campaign tracking is most commonly used when your app is opened via a deeplink.

Is your use-case related to deep linking? AFAIK you usually catch deep-linking directly via an Activity. Where in your code would you call Tracker.setCampaign...?

The deeplink can then open the home screen, a product page etc. What I want to say is that you don't know which screen is opened first and so you don't know where to add a .campaign() like .title() or .dimension().

True, but don't you need to track a screen view in any of the activities anyways? If there is a common pattern to this, we could add a method to TrackHelper that directly takes an intent and checks it for deep-linking, otherwise an extension of TrackHelper for your own usecase sound like the cleanest solution to me.  Something like:
TrackHelper.track()
    .screen(....)
    .tryTrackDeepLink(intent)
    .with(getTracker());

Under https://developer.matomo.org/api-reference/tracking-api the parameters for campaigns are under Optional User info just like the user ID for example.

I don't understand the point, can you elaborate? My issue is that the parameter only needs to be sent once, sending it everytime is wasted traffic.

Sorry for the late answer.

Is your use-case related to deep linking? AFAIK you usually catch deep-linking directly via an Activity. Where in your code would you call Tracker.setCampaign...?

We're following a one Activity, multiple Fragments approach and so we always catch deeplinks in our MainActivity and decide on where they should lead in a separate helper class. That's where I'm calling Tracker.setCampaign().
I agree that sending it everytime creates unnecessary traffic but as I described you don't always track a screen view in the Activity opened by a deeplink and so I don't know if your approach is possible for everyone.

The most clean solution to me would be to give your navigation class a method like setDeepLinkOrigin or so, which is then consumed inside the navigator class or whereever you are calling the actual TrackMe.track.

I like this idea. Then I could go with a solution where the campaign is tracked with a screen like
TrackHelper.track()
    .screen(...)
    .campaign("CampaignName", "CampaignKeyword")
    .with(getTracker());

This could later be extended to work with Intents, too. If this is a good compromise for you I'll make a new PR.

This could later be extended to work with Intents, too. If this is a good compromise for you I'll make a new PR.

Sounds good. Please also add a test for this.


spanner: promote to beta

I think we should resolve #2356 before merging this.

Coverage remained the same at 99.988% when pulling d735cf08c6d9e2fdaacd9eb863ed4634257ff433 on stephenplusplus:spp--spanner-goes-beta into fcffd0e8c2849990d5058e32400a18c1a9063c88 on GoogleCloudPlatform:master.

I'll consider this blocked, unless @lukesneeringer feels otherwise.


Return values displayed

I would suggest for RPROMPT to show the "error returned value", instead of only a single char (⏎), maybe in a red background and white foreground characters? or maybe like this? ⏎127
Unfortunately I'm not very familiar with the zsh syntax / prompt, I was trying to modify the source code but I was unable to do it so

+1

+1

This was actually added as an option a while back: https://github.com/sorin-ionescu/prezto/blob/master/modules/prompt/README.md#display-return-value
It probably won't be on by default for the sorin prompt though.


Add support for containerd

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Trevor Linton seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


SkillAction: When the skill misses, show a "miss" animation/label pop up

It's a little abstract to me right now, I'm not sure what you would be trying to achieve with this setup.
If you want to reuse the animations as resources between the nodes, they can't have different names.
Right now the element that comes up over the character is an animated control node.
You could have anything as a child of it, use aggregation instead of separate base scenes to animate different elements popping up on top of a character.
Regarding localization, let's at least wait until we have the base game's design in place and words or sentences to translate. It's not a problem to add it later.

@godofgrunts I think you can leave with just a single animation and just have a child, hidden, for each scenario, so a child for Miss, another for Stun, another for Damage, another for Healing, Mana...and show/hide them depending on what will be displayed. Since the animation itself will be on the parent, all of its children will be animated as well.


Align tests 602/603/604

Test 601 is aligned with previous ones, 602/603/604 are not, 606 is aligned.
      *** Starting Peripheral tests ***
Operating System View:
 601 : USB CTRL Interface                         : Result:  PASS
 602 : Check SATA CTRL Interface
       Read PCIe_CFG: ECAM Base is zero FF000000     : Result:  PASS
 603 : Check Arm BSA UART register offsets         : Result:  PASS
 604 : Check Arm GENERIC UART Interrupt
    Test Message       : Result:  PASS
 606 : 16550 compatible UART
       Checkpoint --  2                           : Result:  SKIPPED

Hi @hrw,
We are working on the changes.
Thanks,
ACS team


--help complains about cwd and export.json

I've just run lix install https://github.com/go2hx/go2hx --global to install https://github.com/go2hx/go2hx/commit/c6831cbb3f472519df9224734df76f728ee81c22
Then running lix run go2hx --help in my py2many root directory complains about issues that are likely not relevant to running --help:
go get: /Users/john.vandenberg/python/py2many is not within module rooted at /Users/john.vandenberg/haxe/haxe_libraries/go2hx/0.0.1/github/c6831cbb3f472519df9224734df76f728ee81c22
> parser:
Usage of ./go4hx:
  -ident
    	ident json
  -test
    	testing the go library in haxe
src/Main.hx:87: error: export.json not found

when I build from source (same commit) and run in the go2hx directory
❯ haxelib run go2hx --help
go: downloading golang.org/x/tools v0.1.4
go: downloading golang.org/x/sys v0.0.0-20210629170331-7dc0b73dc9fb
go get: upgraded golang.org/x/mod v0.4.1 => v0.4.2
go get: upgraded golang.org/x/sys v0.0.0-20210220050731-9a76102bfb43 => v0.0.0-20210629170331-7dc0b73dc9fb
go get: upgraded golang.org/x/tools v0.1.0 => v0.1.4
> parser:
Usage of ./go4hx:
  -ident
    	ident json
  -test
    	testing the go library in haxe
> typer: 9
Called from ? line 1
Called from Main.hx line 20
Called from Main.hx line 94
Called from Typer.hx line 286
Called from Typer.hx line 2940
Called from Typer.hx line 805
Called from Typer.hx line 834
Called from Typer.hx line 737
Called from Typer.hx line 1441
Called from Typer.hx line 1726
Called from Typer.hx line 2539
Called from Typer.hx line 1978
Called from Typer.hx line 2019
Uncaught exception - unsupported reflect type: pointer(named(go/ast.ImportSpec,struct([{ name => Doc, type => pointer(named(go/ast.CommentGroup,struct([{ name => List, type => slice(pointer(named(go/ast.Comment,struct([{ name => Slash, type => named(go/token.Pos,basic(int_kind)) },{ name => Text, type => basic(string_kind) }])))) }]))) },{ name => Name, type => pointer(named(go/ast.Ident,struct([{ name => NamePos, type => named(go/token.Pos,invalid) },{ name => Name, type => basic(string_kind) },{ name => Obj, type => pointer(named(go/ast.Object,struct([{ name => Kind, type => named(go/ast.ObjKind,basic(int_kind)) },{ name => Name, type => basic(string_kind) },{ name => Decl, type => interfaceValue(0) },{ name => Data, type => interfaceValue(0) },{ name => Type, type => interfaceValue(0) }]))) }]))) },{ name => Path, type => pointer(named(go/ast.BasicLit,struct([{ name => ValuePos, type => named(go/token.Pos,invalid) },{ name => Kind, type => named(go/token.Token,basic(int_kind)) },{ name => Value, type => basic(string_kind) }]))) },{ name => Comment, type => pointer(named(go/ast.CommentGroup,invalid)) },{ name => EndPos, type => named(go/token.Pos,invalid) }])))

My apologies, GoMaps have been revamped and is using the go reflect type system which has not had proper extensive testing, I'll work on supporting reflect type conversion more, and get a proper --help command that doesn't complain about irrelvant things.

Help should now be printed out without running the compiler, it still needs some work as it spits out 2 help sections one from the Go compiler side and the other from the Haxe side, however it shouldn't impact the functionality overall.


Feature request: consider sub commands like export, import, and copy

I was looking for a tool that could help me easily analyze, export all artifacts from a helm, together with all images used, and then import to a desired (private) registry. This is a very common use case when we work with airgapped env.
Unfortunately, I couldn't find one that could best fit into such simple use case.
So I built an incomplete tool for fun: https://github.com/brightzheng100/helm-packager, which is a toy tool and is far away from complete.
I think your tool is a good starting point and I'd suggest to have sub commands, instead of a giant command with configuration file.
For example:
# 1. To export the Helm Charts and their sub Charts to be a local gz file
helmper export [-c <config file>] [-f <exported gz file>] [--dry-run]

# 2. To import the exported gz file to a registry
helmper import [-c <config file>] [-f <exported gz file>] [--dry-run]

# 3. Copy the Helm Charts and their sub Charts to the desired registry -- this is what current helmper does
# But with the --dry-run flag, we can analyze the Helm Charts and their sub Charts without coping the actual artifacts
helmper copy [-c <config file>] [--dry-run]

If you specify
import:
  enabled: false

Helmper will do a dry-run.
The import and export was on my hidden list, so thanks for adding an issue tracking it 👍

I am interested in having a folder with a helm folder (in a git repo) and the use helmper to package that Chart from the folder and push it to oci registry (harbor). Is this relevant to this issue? (eg. is this the issue I should be watching? :) )
Thank you!

I am picking up this feature, and will add commands for:

Extract (Will get a list of charts and a list of images in charts)
Export (Will put images and chart down on local fs)
Import(Will upload images and charts from local fs to oci registry)

Any other suggestions for command specifically related to managing the artifacts on local fs?


nixos/kerberos: update binary folder pointer

${pkg.tcp_wrappers}/sbin does not exist anymore.
Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
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 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)
[ ] Fits CONTRIBUTING.md.

tested with:
$ nix-build ./tests/krb5/default.nix
trace: warning: The option krb5.defaultRealm is deprecated, please use
krb5.libdefaults.default_realm.
trace: warning: The option krb5.domainRealm is deprecated, please use krb5.domain_realm.
trace: warning: The option krb5.kdc is deprecated, please pass a kdc attribute to a
realm in krb5.realms.
trace: warning: The option krb5.kerberosAdminServer is deprecated, please pass an
admin_server attribute to a realm in krb5.realms.
/nix/store/cj116myalba1g3wv55sjv9d68ilrq7jn-vm-test-run-krb5-with-deprecated-config
/nix/store/cyb3g5vzrgj5wxkr6mrnn3v4k9cqkxd2-vm-test-run-krb5-with-example-config


Major refactor

Changes:

Reworked to use rich.live for rerendering rather than escape codes
Included options to not raise validation and type conversion issues in prompt

Issue #19

Codecov Report

Merging #26 (6b75894) into master (307d37b) will decrease coverage by 0.35%.
The diff coverage is 95.55%.

@@            Coverage Diff             @@
##           master      #26      +/-   ##
==========================================
- Coverage   97.41%   97.05%   -0.36%
==========================================
  Files           2        2
  Lines         232      238       +6
  Branches       72       74       +2
==========================================
+ Hits          226      231       +5
- Partials        6        7       +1

Flag
Coverage Δ

unittests
97.05% <95.55%> (-0.36%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

beaupy/beaupy.py
96.55% <93.10%> (-0.39%)
:arrow_down:

beaupy/internals.py
100.00% <100.00%> (ø)

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


k3s v1.24.4+k3s1 cann't use custom cni

Environmental Info:
K3s Version:  1.24.4+k3s1

Node(s) CPU architecture, OS, and Version:

os: centos7.9
arch: x86_64
Cluster Configuration:

1 master
Describe the bug:

run server with this command
k3s server  --flannel-backend=none --disable-network-policy
but node won't be ready, then calico can't be installed because node is not ready
E0901 20:27:43.955758    3037 kubelet.go:2349] "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"
Steps To Reproduce:

Installed K3s:

Expected behavior:

Actual behavior:

Additional context / logs:

Have you tried out k3s check-config yet? Perhaps there's a network clash with the CNI driver you're trying to use and another adapter you're running?

How are you installing calico?

calico can't be installed because node is not ready

Calico should tolerate the NotReady taint, since it is the CNI and the node will (by definition) not be ready until after it is installed. I suspect there is a problem in your install process - as @manuelbuil asked, what steps are you following to install calico?

node not ready is because of kernel missing iptables comment module,  not  related with custom cni


Can't install plugin

I am trying to install rust.vim and I have followed the instructions to install Vundle and I added Plugin 'rust-lang/rust.vim' in my vim.rc file before call vundle#end() but when I try to load up Vim I get the following
Error detected while processing /Users/jordanbaron/.vim/bundle/newL9/plugin/l9.vim:
line   40:
E174: Command already exists: add ! to replace it
line   89:
E174: Command already exists: add ! to replace it
line  100:
E174: Command already exists: add ! to replace it
line  104:
E174: Command already exists: add ! to replace it

I hit enter and when I use ``:PluginInstall`' It says done with errors, here's what the log says:
[2017-03-14 17:16:10]                                                          |
[2017-03-14 17:16:10] Plugin file:///home/gmarik/path/to/plugin                |~
[2017-03-14 17:16:10] $ git clone --recursive 'file:///home/gmarik/path/to/plug|~
in' '/Users/jordanbaron/.vim/bundle/plugin'                                    |~
[2017-03-14 17:16:10] > Cloning into '/Users/jordanbaron/.vim/bundle/plugin'...|~
[2017-03-14 17:16:10] > fatal: '/home/gmarik/path/to/plugin' does not appear to|~
 be a git repository                                                           |~
[2017-03-14 17:16:10] > fatal: Could not read from remote repository.          |~
[2017-03-14 17:16:10] >                                                        |~
[2017-03-14 17:16:10] > Please make sure you have the correct access rights    |~
[2017-03-14 17:16:10] > and the repository exists.                             |~
[2017-03-14 17:16:10] >                                                        |~
[2017-03-14 17:16:11]                                                          |~
[2017-03-14 17:16:11] Helptags:                                                |~
[2017-03-14 17:16:11] :helptags /Users/jordanbaron/.vim/bundle/Vundle.vim/doc  |~
[2017-03-14 17:16:11] :helptags /Users/jordanbaron/.vim/bundle/vim-fugitive/doc|~
[2017-03-14 17:16:11] :helptags /Users/jordanbaron/.vim/bundle/L9/doc          |~
[2017-03-14 17:16:11] :helptags /Users/jordanbaron/.vim/bundle/command-t/doc   |~
[2017-03-14 17:16:11] :helptags /Users/jordanbaron/.vim/bundle/newL9/doc       |~
[2017-03-14 17:16:11] :helptags /Users/jordanbaron/.vim/bundle/rust.vim/doc    |~
[2017-03-14 17:16:11] Helptags: 6 plugins processed

@jmbaron Can you post or link to a minimal vimrc ?
At first glance please try to not  install l9 plugin

I also encountered the same problem

Please see: https://github.com/VundleVim/Vundle.vim/issues/713#issuecomment-206899770

If you meet problem such as "fatal: '/home/gmarik/path/to/plugin' does not appear to|~
be a git repository", you can comment or delete the corresponding row related to the error. In fact , you only need to retain the setting as follows:
`
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')
" let Vundle manage Vundle, required
Plugin 'VundleVim/Vundle.vim'
" The following are examples of different formats supported.
" Keep Plugin commands between vundle#begin/end.
" plugin on GitHub repo
Plugin 'tpope/vim-fugitive'
" plugin from http://vim-scripts.org/vim/scripts.html
" Plugin 'L9'
" Git plugin not hosted on GitHub
"Plugin 'git://git.wincent.com/command-t.git'
" git repos on your local machine (i.e. when working on your own plugin)
"Plugin 'file:///home/gmarik/path/to/plugin'
" The sparkup vim script is in a subdirectory of this repo called vim.
" Pass the path to set the runtimepath properly.
Plugin 'rstacruz/sparkup', {'rtp': 'vim/'}
" Install L9 and avoid a Naming conflict if you've already installed a
" different version somewhere else.
" Plugin 'ascenator/L9', {'name': 'newL9'}
" All of your Plugins must be added before the following line
call vundle#end()            " required
`


Unittest for aqua.evaluation

Description
This PR covers test cases for aqua.evaluation except for CREATE. Increased the coverage to

TODO
Add test case for CREATE EVAL from @lu-ohai
Change

New test dependency: pydantic will be used to validate response format.

Test

can we revert the changes in evaluation.py and add the changes separately later on? This PR will change the current behavior in production even if the intention is to fix bugs. All these changes can go as a part of the next set of improvements/bug fixes later on.

These changes as I commented, are worthwhile to be fixed. They didn't touch the main logic. I believe it is the reason for writing test: to find the bug and fix them. I will keep this PR open to be merged later.
I also prepared another PR: https://github.com/oracle/accelerated-data-science/pull/763 which is the version that adding test without the change in evaluation.py. In case @mayoor prefer to merge those first.


Documentation icon within teams returns "Not Found"

In GitLab by @jasonpagetas on Jul 10, 2024, 05:54
Attempting to navigate to docs using the ? icon returns "Not found"

mentioned in commit aab94431a9d3864ace91af70e29b5dc59b61fd6f

added 1m of time spent

what was the url for both the page the docs?? provide path only, not hostname.

added 2m of time spent

In GitLab by @jasonpagetas on Jul 10, 2024, 08:09
https://nofusscomputing.com/projects/django-template/user/access/organization/
navigating to works. So just need to fix up the url link
https://nofusscomputing.com/projects/centurion_erp/user/access/organization/

In GitLab by @jasonpagetas on Jul 10, 2024, 05:54
marked this issue as related to #74


Make release script accessible for plugins

The release script could be used to a commons folder and used by the library as well as the Yarn and the Rollup plugin.

Move the release script and verify that it still works as expected
Add release instructions for the Yarn and the Rollup plugin (see Contributing file of the library)

Will not be fixed, since we plan to move the two plugin to separate repositories.


Is it possible to use Endroid Twitter with just an access token?

I already have an access token to use and I want to use Endroid Twitter, with the access token I have, to create a Tweet

Hi @sterichards you can see in the readme how you can use the library and your token. Please let me know if you miss something.


Vaadin 24.2 error in Demo

Running the add-on demo in Vaadin 24.2, the "Navigation Error" button fails with:
java.lang.NoSuchMethodError: 'void com.vaadin.flow.component.UI.navigate(java.lang.Class)'
	at com.flowingcode.vaadin.addons.errorwindow.ErrorwindowDemo.lambda$new$9b1b5227$2(ErrorwindowDemo.java:127)

Seems to be a binary compatibility issue. Add-on is compiled using Vaadin version 14, in that version method returns void. In Vaadin 24.2 navigate method changed its return type .


Bump to 2.10.0-SNAPSHOT

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Run mvn clean install apache-rat:check to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] If you have a group of commits related to the same change, please squash your commits into one and force push your branch using git rebase -i.
[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

[x] I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004
[x] In any other case, please file an Apache Individual Contributor License Agreement.

@xdelox could you in the future reference the ticket number in your commit. if you add fixes or closes #3983 they get linked and closed automatically


Support for get_many and get_many_mut functions for Assets<T>

Part of #16244
Objective
Add functions for Assets<T> to retrieve multiple references similar to Query<...>
Solution
The Query type has the get_many and get_many_mut methods to get around this limitation, allowing multiple Entities to be looked up at once, with a dynamic check to prevent the same entity from being accessed multiple times. A similar pattern can be followed here.

For retrieving mutable references, what do you think is an appropriate way?


Naturally trained network gives 78% test accuracy on pgd attack.

Hi,
Thank you very much for this repo. It's very helpful. I could reproduce the performance in your paper for the adversarially trained network. However, I observed that the naturally trained network has 78% accuracy on pgd attack. First, I used fetch_model.py to download naturally trained model and ran run_attack.py on attack.npy which is generated using adv_trained network. I got 78%. In case of an issue with the released model, I trained another model on only natural images from scratch using your implementation and again got 78% test accuracy on pgd adversarial images. I used the default config file. Standard test performance is around 95%. There is still a drop, but I was expecting the test performance on pgd attack to be around 3%. Am I doing something wrong?
Thank you so much in advance.

I found my mistake. Closing this issue.


support

Unsloth Question do you support omnigen?

Shitao/OmniGen-v1

Unsloth Question do you support
nvidia/Llama-3.1-Nemotron-70B-Instruct
??????

@werruww Yes we support Nemotron 70B
@Qarqor5555555 I don't think so sorry


Interested to be in the team

Hi All,
I am planning to work with few ontologists on mapping schema for various CDM mapping. I'd like to contribute or coordinate with this group.
Thanks,
Asiyah

Thats great! yeah, we are open to suggestions of any kind! What exactly are you planning to do? CDM = Common Data Model? Does this mean you are working to map clinical ontologies primarily? Which ones?

Our initial thought is to align some CDM harmonization work done here: https://www.fda.gov/drugs/coronavirus-covid-19-drugs/covid-19-real-world-data-rwd-data-elements-harmonization-project
There are some other works mapping OMOP to OBO, and we'd like to see if there is a process to assess the quality of terminology alignment in some text mining or terminology mapping work.
We are still in planning phase, and will keep you updated. Please let us know if you have similar thoughts from your group.

Great! I can see a lot of cool work in the CDM area when following your link, but I could not, on first glance, see any concrete thoughts on terminology mapping - I saw the mapping spreadsheet of course, which appears to be mapping data model fields across various CDMs.. I will wait for more concrete thoughts from you, and looking forward to working together :)

I have added you to the team @linikujp
https://github.com/orgs/mapping-commons/teams/sssom-core


Update Current Track

is there a way to Update current track Title, Artist, and Image ?

Duplicate of #93. This is already being worked on #465

Thanks @Guichaguri , the pull Request work for Android. but how about ios ?

The PR is still in the works, it won't be merged until we have iOS support fully working too.


added groq models for faster inference

Added Groq as a model option

@john-adeojo . Thanks for a great project. I added Groq and created a pull request. Groq has fast inference speeds and responses will be returned much quicker. Hope it's useful.


not working

this library does not work with the last version of three.js. Is it dead?

Hey @acx70 check out cannon-es, it's a maintained fork

Hey @acx70 check out cannon-es, it's a maintained fork

Great, thank you !


Default to platformed = true and introduce withPlatformed(...)

Motivation
Scala.js and Scala Native libraries need to be compiled and published separately from the Scala JVM.
The Scala.js and Scala Native libraries use a specific suffix to distinguish themselves from JVM counterparts, _sjs1 for Scala.js, where 1 is the binary version of Scala.js, and _native0.4 for Scala Native.
The official Sbt plugins defined a new syntax to define Scala.js (which then was adopted by Scala Native as well) dependencies:
"com.github.foo" %%% "bar" % "1.0.0"

that the Scala.js plugin converts to:
"com.github.foo" %% "bar_sjs1" % "1.0.0"

which gets converted then by Sbt to:
"com.github.foo" % "bar_sjs1_2.13" % "1.0.0"

given that the scalaVersion is 2.13.x.
Mill adopted a similar convention by creating a second pair of colons:
ivy"com.github.foo::bar::1.0.0"

in a Scala.js module, is equivalent to:
ivy"com.github.foo::bar_sjs1:1.0.0"

and in a Scala Native module to:
ivy"com.github.foo::bar_native0.4:1.0.0"

What's the problem with it?
The fact you need a special syntax for Scala.js projects is problematic because it can create bugs. If you load a testing library on Scala.js with a JVM artifact, the tests don't run because the Scala.js tooling is not able to find the Scala.js specific files in the dependency jar and assumes it is an empty dependency. Very often people (also very experienced people in Scala.js and Scala Native) get confused and waste time because of this.
Even a website was created to raise awareness on this issue: https://youforgotapercentagesignoracolon.com/
Scala.js/Scala Native dependencies without the platform suffix (_sjs1, _native0.4)
There are rare cases, like scalajs-library from the Scala.js runtime, where a Scala.js library doesn't have the sjs_1 suffix. Also, sometimes it is also useful to have Scala JVM compile-time dependency in a Scala.js project that is used only at compile time by a macro but doesn't end in the runtime classpath.
Are we optimizing for the most common case?
Even if there are times when dependencies without platform suffix are needed, most of the times what you want is to add the platform suffix (_sjs1, _native0.4).
Proposed solution
The proposed solution is to deprecate the ivy"com.github.foo::bar::1.0.0" syntax with the second double colon and add the platform suffix by default. To cover the rare cases when you don't want a platformed dependency, this introduces a new method in Dep called withPlatformed which allows you to remove the platform suffix with:
`ivy"com.github.foo::bar:1.0.0".withPlatformed(false)`

will generate bar_2.13 as artifact name.
Proposed behaviour
Input: ivy"com.github.foo::bar:1.0.0"
Output:

JVM
Scala.js
Scala Native

Before
bar_2.13
bar_2.13
bar_2.13

After
bar_2.13
bar_sjs1_2.13
bar_native0.4_2.13

Input: ivy"com.github.foo::bar::1.0.0" (deprecated after this PR)
Output:

JVM
Scala.js
Scala Native

Before
bar_2.13
bar_sjs1_2.13
bar_native0.4_2.13

After
bar_2.13
bar_sjs1_2.13
bar_native0.4_2.13

Input: ivy"com.github.foo::bar:1.0.0".withPlatformed(false)
Output:

JVM
Scala.js
Scala Native

After
bar_2.13
bar_2.13
bar_2.13

The idea is good and I fully support it, but I think, before we can this be an simple change, we need properly handle another open issue, transitive module dependencies. This is an open issue in Mill and

@lefou I don't know if the two problems are related.
First of all this change is only syntactical, to make the old ivy"a::b:c" become ivy"a::b:c".withPlatformed(false) and ivy"a::b::c" become ivy"a::b:c".
Second I think that issue relates more to the Scala versioning of dependencies, which helps in Scala 2.13 / Scala 3 sandwiches.
In the case of platformed, the story is different and I think that the current behavior is the best we can get with the current model of using Scala traits to share code in the build.
There is a common pattern currently used in Mill which is to define a common trait extending ScalaModule and then having different objects of different platforms with the platform-specific code.
Example:
trait Common extends ScalaModule {
  def ivyDeps = super.ivyDeps() ++ Seq(
    ivy"com.lihaoyi::geny::0.7.1"
  )
}

object js extends Common with ScalaJSModule {
  // ...
}
object jvm extends Common {
  // ...
}
object native extends Common with ScalaNativeModule {
  // ...
}

In the code snippet above, the geny defined in the Common ivyDeps is correctly resolved as geny_3 in jvm, geny_sjs1_3 in js and as geny_native0.4_3. If we resolve the platform suffix in the Common trait we brake the js and native.

Although I said I support the idea, I'm not yet sure, I like this proposal. I'm still in a thinking process. I mean yes, we probably want to optimize for the common case, but we also need to make sure we keep it understandable. I don't like the fact, that the same dependency notation can mean different things in different contexts/modules. We already know, that by using two or three colons, we depend on some context of the module (Scala version, Platform version), but when we use a single colon, we are more or less exact. With your proposal/pr, we loosen this safety, which is IMHO not good.
Sure, the use of the additional colons is also problematic, but it's also the the status quo.
Please note, we use the platform suffix also for Mill plugin, e.g. when importing them into scripts. Once, we deprecate the second platform colon marker, we either need to always write .withPlatformed(true) when importing plugins or withPlatformed(false) when importing regular libs. There is no clear more common case.
An alternative could be the introduction of a new dependency declaration like platformIvyDeps, which does this conversion you proposed. But this has downsides too (e.g. we probabably also want the dual for runIvyDeps). I still find it hard to come up with a satisfying solution.
Your change is rather fundamental, so I think we really should agree about the best option before making such change. Maybe, we need further discussions. Also, speaking with with other tool developers and user like sbt or Scala-CLI won't hurt.

I'm going through open PRs and re-reading old comments.

I can safely detect Scala.js and Scala Native modules, but I can't detect pure Scala modules (targeting the JVM). Obviously, each Scala.js module is also a ScalaModule, but in some way it isn't. Maybe, we should introduce a ScalaBaseModule or a ScalaJvmModule?

It's not the best experience ever, but what I did to solve this particular issue was this:
module match {
  case _: ScalaJSModule => "js"
  case _: ScalaNativeModule => "native"
  case _: ScalaModule => "jvm"
}

It's ugly but it does the job, so we don't need to create a new ScalaJvmModule (which I don't like since JVM is the "default" platform for Scala and people using Mill for the first time don't need to know that a Js and a Native platform also exist. ScalaBaseModule could work, but I don't see this big need to justify the change.

I'm having second thoughts as well about this change.
What I would do instead is to standardize use:
// for java deps
ivy"groupId:artifactId:version"
// for scala deps
ivy"groupId::artifactId::version"

And leave the other syntaxes to power users.
ivy"groupid::artifactid:version" is "needed" only for some specific Scala.js dependencies (specifically when Scala.js uses a JVM artifact) in any other case a platformed dependency works.
Probably after you added platformSuffix to JavaModule it's also possible to do this for java:
ivy"groupId:artifactId::version"

but this doesn't please my eye 😃

I would like to restart discussion here and get it. So far, a lot of the points raised against this proposal are orthogonal and not related to this proposal:

How easy it is to distinguish Scala-JVM/JS/Native modules is not affected by which kind of ivyDep is the default

Mill plugins are all on Scala-JVM, and are also not going to be affected to what kind of ivyDep is the default for non-JVM Scala modules

This proposal is the right thing to do because:

The default thing should be the correct thing. In this case, the correct thing 99.999% of the time is to have a Scala ivyDep that is for the platform your module is

You want support for the 0.001% of the time you don't want the default: in this case we have withPlatformed(false) as an easy fallback if people don't want the default behavior

The change should be backwards compatible: in this case, we can trivially leave the old foo::bar::qux syntax in place, and make it equivalent to foo::bar:qux, which will work for 99.999% of existing builds

The use case of "I want to depend on Scala-JVM when running on Scala-JS or Scala-Native" is a niche use case and should have niche syntax. The original idea was for things like Scala-Async that were not cross-published for JS, but at this point even that library is cross-published (https://search.maven.org/search?q=a:scala-async_sjs1_2.13). I struggle to come up with a single current example where someone would want a Scala-JVM dependency on Scala-JS and Scala-Native to be the default. In contrast, every single ivyDep wants the dep to be of the same Scala platform as the current module.
Given that, this PR is clearly the right thing to do. Any further improvements we want to make to the ScalaModule trait hierarchy or other things can be discussed separately

@lefou @lolgab I have merged this into latest master and added a unit test to verify that the old syntax continues to work unchanged (for backwards compat)

Ok, we definitely need to add this to our Mill 0.11 migration guide, so this info is present to anyone who is slightly interested in what's changed.
@lihaoyi Can you please send a PR with updates to the documentation, which is now outdated, esp. the library dependencies section? Ideally, we keep a NOTE block which explains the "old" :: notation, so users are able to understand and handle found in build.scs or on pages like scaladex.

@lefou I'll merge this first and submit a follow up PR with a tentative 0.11.0-M8 changelog and updates the documentation with the user-facing changes so far, including https://github.com/com-lihaoyi/mill/pull/2427. Having those in place first should make it easier to put together a migration guide for all these changes

@lihaoyi In the context of imports into Mill build scripts: How do you think we should handle Mill plugins (which target a scala version and a Mill platform, e.g. group::mill-foo::0.1.0) vs. normal libraries (which target a scala version but are not Mill specific, e.g. group::some-lib:1.0.1). I'd rather have a consistent notation, as these could also be ivyDeps in a meta build, which should currently look like this (I'm not sure whether the RootModule already propertly sets the correct platformSuffix):
// meta-build

trait FooBuild extends RootModule {
  def ivyDeps = Agg(
    ivy"group::mill-foo::0.1.0",
    ivy"group:some-lib:1.0.1"
  )
}

@lefou don't mill plugins use group::mill-foo:$MILL_VERSION? I don't recall seeing the double colon syntax used in the context of mill plugins before

@lefou don't mill plugins use group::mill-foo:$MILL_VERSION? I don't recall seeing the double colon syntax used in the context of mill plugins before

What you describe are the contrib plugins that are maintained in Mill's monorepo and released together with Mill.
External plugins are released with _mill0.10 suffix for binary compatibility and @lefou used the groupId::artifactId::version syntax that gets lowered to groupId:artifactId_mill0.10_2.13:version. It's how all external plugins work these days.
This allows to easily backport changes to older Mill versions (by cross-compiling plugins).

We can kee the syntax for importing Mill plugins, or we can change it from import $ivy to import $plugin to distinguish them, with a correspondingmillPluginIvyDeps target in the MillBuildRootModule.. I'd say we keep the syntax for now, and if we'd like we can change the magic import in a follow up PR if we want

What about some new settings target to control whether "normal" deps should resolve to platformed by default? We could make it default to true in ScalaJSModule and ScalaNativeModule, but in MillBuildModule and alike, we probably want default to false.
With a reasonable default, we make all common use cases easy, but with the option to change that value (per module), we allow for all possible cases that we allow currently.
I know this is not failure proof (esp. when trying to help in the chats with wrong assumptions), but it would solve the current issue (make default case easy and less error-prone) and keep flexibility at the same time.

Best location for application of that setting is probably CoursierModule.bindDependency, which is IMHO a better place than the various places where the conversion happens currently in this PR.

@lefou sure, happy to postpone this till after 0.11.0-M8

Two things that might influence the discussion:

Sbt 2.0 is designing a solution for this same problem now. It's worth checking what they are doing, even though they have different constraints since the Scala Native and Scala.js plugins live in different repositories and are maintained by different organizations.
This problem is particularly annoying with Scala.js and Scala Native because if you forget the second :: it doesn't fail to resolve the artifact since most libs have JVM counterparts. With Mill plugins, it fails to resolve since there is a mill-mima_mill0.10_2.13 but there isn't any mill-mima_2.13. It's still problematic but you have a failure instead of a success with silent empty test suites passing (in case of test frameworks).

I think if we know in some special task, that we only want dependencies of a special kind, e.g. platform only or non-platform only, we should check early and just fail. With a nice error messages, users would be even ok with adding that extra colon. As @lolgab said, it's mostly about awareness and failure reporting.

I don't think I can accept the "we provide two syntax options, one is always wrong, and we know which one and provide an error message if you give the wrong syntax" approach. It just seems so silly, especially if we can just provide one syntax option and it "always" does the right thing.
It definitely seems like that is possible to automate all of this, even if we have to scatter some constants throughout the core Mill libraries. It's vastly better to have e.g. ~20 decision points in Mill library code rather than to having ~20,000 decision points (one for every single ivy expression)  scattered throughout hundreds of different user build.sc files

I don't think I can accept the "we provide two syntax options, one is always wrong, and we know which one and provide an error message if you give the wrong syntax" approach. It just seems so silly, especially if we can just provide one syntax option and it "always" does the right thing.
It definitely seems like that is possible to automate all of this, even if we have to scatter some constants throughout the core Mill libraries. It's vastly better to have e.g. ~20 decision points in Mill library code rather than to having ~20,000 decision points (one for every single ivy expression) scattered throughout hundreds of different user build.sc files

I see it likewise. But I wanted to point out, we should move some decision points into the respective special modules rather that the generic implementations. Esp. as not all platform-specific modules behave equal (Native vs. Mill).
We should start with asserting at those positions if something illegal is provided.
If we can provide nice default behavior, we definitely should. But it must be understandable from the outside. And sometimes, less magic in favor of more explicitness is the right thing to do. A clear eror can be more that some magic implicit behavior hard to reason about. TBH, I never saw the need to have a JVM dependency in a native/js build, so I don't know whether we need that support at all (does that mean we can default to use platformed ivyDeps?, probably yes.). I know, in a Mill plugin module, we do have both (we should default to non-platformed ivyDeps).

OK, I think there isn't any more disagreement. The PR as written already satisfies everything brought up so far:

MillBuildModule has non-platformed deps as a default
Everyone else has platformed-deps as a default
Platform/no-platform decision is made as close to resolveDeps as possible given the current code infrastructure

I'm working on getting CI green, then we can probably merge this

OK, I think there isn't any more disagreement. The PR as written already satisfies everything brought up so far:
1. `MillBuildModule` has non-platformed deps as a default

2. Everyone else has platformed-deps as a default

3. Platform/no-platform decision is made as close to `resolveDeps` as possible given the current code infrastructure

I'm working on getting CI green, then we can probably merge this

I still strive towards a bindDependency without flags.

The basic logic is that scala compiler classpaths always have to be non-platformed, runtime code always has to be platformed, with special cases for special libraries.
This is actually exactly the same way the cross-scala-version suffixes like _2.13 works: scala-compiler is non-platformed, most libraries are platformed, scala-library is a special library and non-platformed.
The vast majority of macros have to be platformed, unless the macro has zero runtime support. This used to be the case with Scala-Async, for example. But even that is now cross-published (as I have linked above).
That's about it. In the end, the goal of this is not to change any behavior - we just replicate the behavior we already expect people to follow, except automatically.

We should probably drop the resolveCoursierDependency compatibility shim (which is called from bindDependency) at this point, as it makes understanding override strategies unnecessary hard.

I still strive towards a bindDependency without flags.

There isn't such an option unless we remove bindDependency from the code path transforming Deps to BoundDeps. We're effectively already passing in flags to bindDependency anywhere, except the flag is called :: and it's scattered throughout all sorts of user build files and targets

bindDependency is essentially injection platform bindings when requested.
Why scatter the platform decision to all bindDependency call sites, if it is only needed in some places and could be perfectly done by adapting the Dep] we pass to bindDependency?
To my understanding, we can derive the decision whether to platform or not, from the location of a dependency. If it comes from ivyDeps or runIvyDeps, then they need to be platformed.

Why scatter the platform decision to all bindDependency call sites, if it is only needed in some places and could be perfectly done by adapting the Dep we pass to bindDependency?

That's exactly what this PR did in https://github.com/com-lihaoyi/mill/pull/1916/commits/6a1af1264134ddabda51cf8b4c0431f5f7e9a96b. You requested to move the logic into bindDependency, so I did.
If you'd prefer the call to be made on the arguments that we pass to bindDependency instead of within bindDependency itself controlled by a flag, I can revert this PR to 6a1af1264134ddabda51cf8b4c0431f5f7e9a96b and proceed from there

Ok, will revert


In report "95 PCT. RESP. TIME 97.0 Ms" should be "95 PCT. RESP. TIME 97.0 ms", customer may get confused, we may get challenged by customer for the "Ms"

https://public.getcarrier.io/report/backend?report_id=12
According to International Bureau of Weights and Measures stander https://www.bipm.org/en/measurement-units/prefixes.html
The Ms means mega second (1 000 000 sedond), not milli second (0.001 second)
This will make customer get confused and customer may lose some trust on us if we show interface with this "Ms" to customer.
Is's just a suggestion, would you like to change it to ms?
Thanks


Use gmock after catkin

https://answers.ros.org/question/199680/catkin-doesnt-play-nice-with-google-mock/?answer=221147

@gaschler this is not a good fix for #776. I submitted a proper fix, https://github.com/ros/catkin/pull/927, and it has been merged. I asked if they can make a release so we can get cartographer_ros CI unstuck.

@ojura, I'm on it. My latest plan is to use cmake's ExternalProject_Add to build it reproducibly. We cannot wait for upstream changes.
(Abandoning this PR.)

Maybe consider just applying that patch in the Docker instance?


WIP nodeserver: Improve idempotency in ephemeral volume creation

This is WIP as it needs a change on testing code side which fixes repeating of idempotency testing.
The current changes are result of improvements I made during debugging an issue
that occured thanks to kubelet repeating PublishVolume requests, which
seems happens due to some kubelet internal issue.

The check for existing file system before mkfs was made on
one call path only, but ephemeral took another path when creating
an inline volume. Due to 2 additional side effects: incomplete
idempotency testing, and issue in kubelet that caused repeated
publishVolume requests, it was exposed that nodeserver attempts
to mkfs a device with existing file system, which fails,
and there is no useful error information.
The use of dax=always allows comparing of mount flags to work
correctly, as otherwise there would be mismatch:
"no dax found in dax=always"
According to docs, -o dax is legacy stiyle which could become
deprecated in the future.

This is WIP as it needs a change on testing code side which fixes repeating of idempotency testing.

You can simply copy my commit into this PR.

The change seems to work as planned as I see repeated:
nodeserver.go:641 Skip mkfs as ext4 file system already exists on /dev/ndbus0region0fsdax/fake-e-318fbab89545328222eec8ca23590e972be8d2fcf27908ac3316cdbe
nodeserver.go:233 NodePublishVolume[fake-ephemeral-volume-id]: Existing mountFlags:'[rw seclabel relatime dax=always]', fsTyp: 'ext4'
nodeserver.go:235 NodePublishVolume[fake-ephemeral-volume-id]: parameters match existing, return OK

Most recent run however failed, but seems for unrelated reason, I will re-trigger.
P.S. what is your opinion about code that tried to match text output. I commented it out with TODO marking now, is it ok to delete? I believe the check before mkfs coves this scenario already, and string match is not reliable.

updated commit msg to reflect dax=always change correctly

The latest run failed with unrelated error, "operator.API.updating all in default deployment while running", any ideas?
I had rebased hoping recent commit helps with  those, but seems not

The latest run failed with unrelated error, "operator.API.updating all in default deployment while running", any ideas?

@avalluri: ^^^

I had rebased hoping recent commit helps with those, but seems not

Testing happens against a merge with the target branch. It is not necessary to rebase to pick up changes in that branch.


MobileCore.getSDKIdentities is missing Target Ids

The result should also contain target Ids populated from Target shared state.
https://github.com/adobe/aepsdk-core-ios/blob/main/AEPIdentity/Sources/MobileIdentities.swift#L85

Created pr with the fix here - https://github.com/adobe/aepsdk-core-ios/pull/848


[Suggestion] Add a CLI option to only test stories with a play function

I would like to propose the addition of a new CLI option that would allow users to test only stories that contain a "play" function. This would be particularly helpful for those of us who are working with large Storybook projects and want to quickly test those stories.
Thank you

Hey there! This sounds like a good idea, in fact it should already be possible with the following ejected test-runner config:
// test-runner-jest.config.js
const { getJestConfig } = require('@storybook/test-runner')
/**
 * @type {import('@jest/types').Config.InitialOptions}
 */
module.exports = {
  // The default configuration comes from @storybook/test-runner
  ...getJestConfig(),
  testNamePattern: 'play-test', // only runs tests with play function
}

However...
This seems to break the test-runner, and I believe it's a bug in jest-playwright as I noticed here. If anyone would like to take a look into why the bug happens and is willing to open a PR, that is very welcome!

Just for the record: I'm trying to add test-runner to a Storybook I maintain and for several days I'm struggling with the problem of unstable tests
For some of them I narrowed the problem down to "They touch document so without jsdom it may be a no-go" (and test-runner doesn't allow to switch to jest-environment-jsdom - I hope to have time later today to write down my findings in a distinct issue which I will link here) so I went for "let's have something than nothing" and started looking for options to skip tests by name pattern. I ended up finding this issue
Other options I considered to detect it's the runner and render fake instead of problematic story (if smoke-test fails) or a blank play if it's play-test, but it seems like not that good idea as hinting Jest to skip directly (which I imagine will also produce better report: not "all ok, won't tell which ones were actual and which ones were faked" but "some OK, other skipped")

hi @jrencz, i made a PR to the emotion about the issue. Also there is a suggested way for test-runner config

@panvourtsis great news!
I see that package @storybook/theming uses emotion (@emotion/use-insertion-effect-with-fallbacks), but I don't quite get how is that related to the test runner?
Do I get it right that after your PR gets merged, then released, new version of @emotion/use-insertion-effect-with-fallbacks needs to be adopted in Storybook and only then I, as end user of test-runner may benefit from it, right?

@JReinhold What is happening about planned changes in Storybook's test-runner (testing stories with Vitest): https://youtu.be/veCxKeLl35A?feature=shared&t=9209, do we have to wait for Storybook 8.0?

Hey everyone! We just released a test filtering feature in the test-runner v0.15.0, which you can read here.
Stories with a play function automatically have a play-fn tag, so for running tests against only those stories, you can do like this:
yarn test-storybook --includeTags="play-fn"

And if you only want to run smoke tests instead, you can do the inverse:
yarn test-storybook --excludeTags="play-fn"

# or this

yarn test-storybook --skipTags="play-fn"

Thank you Storybook team ❤


[Installation]: How to install vLLM on Jetson

Your current environment
The output of `python collect_env.py`

How you are installing vllm
pip install -vvv vllm

Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

I have the same question，do you deal it ?

Looking to add Jetson support in #9735


Adjust the default location during cortical area creation

Current cortical area 3D position default is 0,0,0 which falls under the red 3D axis indicator. User has to always remember to change the location and the green location indicator is at first invisible due to such overlap.
Set the default position to 40, 0 , 0 instead

resolved


Add disk space, CPU and load metrics to the Elastic Cloud integration

This is tested enough to be good for merging.


ZEPPELIN 228 - Add unit tests for angular controllers

Looks good to me!

Thanks, Overall looks good.
It's a good starting point

Happy to see people writing tests after it is been fixed.
@r-kamath : How is the test coverage for controllers?
It is good to have plugging for grunt to see the test coverage. It will reduce the test duplication.


[ACR] Add attributes commands and detail flag under acr repository group

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[x] I adhere to the Command Guidelines.

/cc @sajayantony @yuwaMSFT2


[dv] usb clk measurement fails

@matutem
I enabled the clock measurement in chip-level tests.  Looks like 1/3 usb clk measurement fails. We expect the cnt range to be ee-f0, but it may get to f1. Should we relax the max threshold a bit?

Here is the waveform:

ot_debug -j smart:d1419ead-09b6-4024-980d-5790feb4aa2e

Hmm, are you running with calibrated usb clock? Background: the AST starts up with uncalibrated USB, so it will be off. Rather than relaxing the measurement requirements we pass a runtime plusargs to simv so the AST will run with calibrated clocks, which is done with
run_opts: ["+calibrate_usb_clk=1"]
in your test's json entry.

Hmm, are you running with calibrated usb clock? Background: the AST starts up with uncalibrated USB, so it will be off. Rather than relaxing the measurement requirements we pass a runtime plusargs to simv so the AST will run with calibrated clocks, which is done with run_opts: ["+calibrate_usb_clk=1"] in your test's json entry.

I see. Thanks. Let me have a try

By the way, setting the clock to be calibrated may seem too aggressive, but USB calibration is a very specific step and involves the vendor. It is best to run specific tests for calibration separately, and assume it has already been done for the bulk of tests.

Thanks @matutem. +calibrate_usb_clk works.
Looks like you and Tim have discussed the usb calibration test offline. Closing this issue now


geo2rdr and azimuth time interpolation

Unfortunately, a bug for SET interpolation has cropped up for ~1/3 of jobs on track 106. This error did not show up previously on track 4 at all. Both had approximately 10k jobs. Here are some sample inputs and logs.
{'job_id': 'a72f7873-5011-42ae-af28-300dc44cbee5',
  'job_type': 'INSAR_ISCE_TEST',
  'request_time': '2023-08-25T03:36:55+00:00',
  'status_code': 'FAILED',
  'user_id': 'access_cloud_based_insar',
  'name': 'track106-n3',
  'job_parameters': {'compute_solid_earth_tide': True,
   'estimate_ionosphere_delay': True,
   'frame_id': 16420,
   'granules': ['S1A_IW_SLC__1SDV_20230615T225929_20230615T225956_049003_05E492_C8D9',
    'S1A_IW_SLC__1SDV_20230615T225954_20230615T230021_049003_05E492_3D08'],
   'secondary_granules': ['S1A_IW_SLC__1SDV_20230522T225928_20230522T225955_048653_05DA0B_720C',
    'S1A_IW_SLC__1SDV_20230522T225953_20230522T230020_048653_05DA0B_80AB'],
   'weather_model': 'HRRR'},
  'logs': ['https://hyp3-tibet-jpl-contentbucket-81rn23hp7ppf.s3.us-west-2.amazonaws.com/a72f7873-5011-42ae-af28-300dc44cbee5/a72f7873-5011-42ae-af28-300dc44cbee5.log'],
  'expiration_time': '2023-10-25T00:00:00+00:00',
  'processing_times': [8633.635]}

and
{'job_id': '0519162c-6f33-48b4-ae64-e53b62ab7bf7',
  'job_type': 'INSAR_ISCE_TEST',
  'request_time': '2023-08-25T03:36:55+00:00',
  'status_code': 'FAILED',
  'user_id': 'access_cloud_based_insar',
  'name': 'track106-n3',
  'job_parameters': {'compute_solid_earth_tide': True,
   'estimate_ionosphere_delay': True,
   'frame_id': 16420,
   'granules': ['S1A_IW_SLC__1SDV_20230603T225929_20230603T225956_048828_05DF3F_96A6',
    'S1A_IW_SLC__1SDV_20230603T225954_20230603T230020_048828_05DF3F_9974'],
   'secondary_granules': ['S1A_IW_SLC__1SDV_20230522T225928_20230522T225955_048653_05DA0B_720C',
    'S1A_IW_SLC__1SDV_20230522T225953_20230522T230020_048653_05DA0B_80AB'],
   'weather_model': 'HRRR'},
  'logs': ['https://hyp3-tibet-jpl-contentbucket-81rn23hp7ppf.s3.us-west-2.amazonaws.com/0519162c-6f33-48b4-ae64-e53b62ab7bf7/0519162c-6f33-48b4-ae64-e53b62ab7bf7.log'],
  'expiration_time': '2023-10-25T00:00:00+00:00',
  'processing_times': [8577.53]}

The relevant error shows up as
Traceback (most recent call last):
  File "/opt/conda/envs/topsapp_env/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/conda/envs/topsapp_env/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce2_topsapp/__main__.py", line 365, in <module>
    main()
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce2_topsapp/__main__.py", line 361, in main
    sys.exit(process_entry_point.load()())
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce2_topsapp/__main__.py", line 232, in gunw_slc
    nc_path = update_gunw_with_solid_earth_tide(nc_path, "reference", loc_data['reference_orbits'])
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce2_topsapp/solid_earth_tides.py", line 457, in update_gunw_with_solid_earth_tide
    solid_earth_tide_ds = compute_solid_earth_tide_from_gunw(gunw_path=gunw_path,
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce2_topsapp/solid_earth_tides.py", line 187, in compute_solid_earth_tide_from_gunw
    tide_e, tide_n, tide_u = compute_enu_solid_earth_tide(orbit_xmls=orbit_xmls,
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce2_topsapp/solid_earth_tides.py", line 355, in compute_enu_solid_earth_tide
    azimuth_time_arr = get_azimuth_time_array(orbit_xmls,
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce2_topsapp/solid_earth_tides.py", line 253, in get_azimuth_time_array
    datetime_isce, rng = orb.geo2rdr([lat, lon, hgt])
  File "/opt/conda/envs/topsapp_env/lib/python3.9/site-packages/isce/components/isceobj/Orbit/Orbit.py", line 1048, in geo2rdr
    tguess = tguess - datetime.timedelta(seconds = fn/fnprime)
ValueError: cannot convert float NaN to integer

This error previously came up when we had #131, in which duplicate orbit xmls was causing the job to fail. However, as I will demonstrate below, this is coming likely due to something more nuanced.

Please view the following looking at the first job.
https://gist.github.com/cmarshak/6c4f8acbb6466ed4ce8fe13f14de78e2
As you can see for the input granules, there are two orbit files obtained.
ref_orb_paths  = list(set(list(map(lambda g: get_orb.downloadSentinelOrbitFile(g)[0], ref_granules))))
ref_orb_paths

['S1A_OPER_AUX_POEORB_OPOD_20230705T080713_V20230614T225942_20230616T005942.EOF',
'S1A_OPER_AUX_POEORB_OPOD_20230706T080750_V20230615T225942_20230617T005942.EOF']

When I pass both orbits into geo2rdr, I get the error reported. When I pass just the first, same error. When I pass just the second, I get an error.
I do not understand the precise issue here. It would be good to understand what is happening from @dbekaert and @sssangha.
Let's resume this on Monday.


Will this work?

opened via imdone.io from a code comment on dd922bf4 by Jesse

https://github.com/imdone/imdone-atom/blob/fd67cec7d91a2e672df487908878de90b0226833/lib/plugins/plugin-view.coffee#L103-L108

Issue closed with imdone.io by removing a comment.

https://github.com/imdone/imdone-atom/blob/4e5ff54c1e82e119e8d13227461ae3ef732df495/lib/plugins/plugin-view.coffee#L103-L108


General Issue: Updates tests with Partial Dates for compute_duration()

Hi @pharmaverse/admiral
I noticed while reviewing https://github.com/pharmaverse/admiral/pull/2075 that there is no "funny business" happening within this function's test, e.g. bad dates or missing dates.
Is is worth it to include a few of these in this function test?  I think so, but maybe I'm missing some key information.
Reference Material
Originally posted by @bms63 in https://github.com/pharmaverse/admiral/pull/2075#discussion_r1307444314
compute_duration(
      ymd("2000-02-01"),
      ymd("2001-02"),
      out_unit = "weeks",
      add_one = FALSE,
      type = "duration"
    )

Definition of Done

[ ] Investigate if additional tests are needed for compute durations, e.g. bad dates, user error, etc.
[ ] Implement tests for function.

Hey @bms63 !
What kind of funny business do you want to test? The lubridate::ymd() function certainly has some funny behavior here, but that is independent from our compute_duration() function...
lubridate::ymd("2001-02")
#> [1] "2020-01-02"

Created on 2023-08-29 with reprex v2.0.2

Date imputation is handled separately from compute_duration()


Fix naming

Fixes #116 and #166.
This PR fixes the following naming issues uncovered in v1.3 wrap-up and PE-D.

Unstandardised help messages
Window name (still using "Address App")
User guide url is using the link to a markdown file, not the Jekyll site

Codecov Report

Merging #167 (c59bb4c) into master (e0c5405) will increase coverage by 0.40%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #167      +/-   ##
============================================
+ Coverage     71.56%   71.96%   +0.40%
+ Complexity      724      716       -8
============================================
  Files            99       99
  Lines          2110     2051      -59
  Branches        277      262      -15
============================================
- Hits           1510     1476      -34
+ Misses          501      476      -25
  Partials         99       99

Impacted Files
Coverage Δ

.../java/seedu/address/logic/commands/AddCommand.java
85.10% <ø> (ø)

...eedu/address/logic/commands/AddToOrderCommand.java
87.50% <ø> (ø)

...va/seedu/address/logic/commands/DeleteCommand.java
100.00% <ø> (ø)

...java/seedu/address/logic/commands/EditCommand.java
95.00% <ø> (ø)

...ess/logic/commands/EndAndTransactOrderCommand.java
81.81% <ø> (ø)

...java/seedu/address/logic/commands/FindCommand.java
75.00% <ø> (+3.57%)
:arrow_up:

...address/logic/commands/ListTransactionCommand.java
60.86% <ø> (ø)

...va/seedu/address/logic/commands/RemoveCommand.java
93.54% <ø> (ø)

...address/logic/commands/RemoveFromOrderCommand.java
81.81% <ø> (ø)

...java/seedu/address/logic/commands/SortCommand.java
72.22% <ø> (ø)

... and 16 more

Continue to review full report at Codecov.

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


Research whether it's possible to highlight sub-matches within a match

The regular expression engine within JavaScript doesn't provide information about the position of sub-matches within a match. That's one reason why in previous versions Java was used for this if it was available, because Java allows to get that information.
As the use of Java should be avoided in future versions, it needs to be researched whether the information about sub-match positions can be retrieved in a different way.
Example
Regular expression: /a(([bc]+)d)/
Search text: aaabcdaaa
Output: ["abcd", "bcd", "bc"]
=> There's no info about the position of the matches within the search text.

I found the following tools trying to achieve this:

HiFi Regex Tool
regexplained

Though both of them fail to get the positions right for expressions like /a(a)(a)/.
Also there was an ECMAScript discussion about adding a way to get the sub-match positions.
Sebastian


[binance] add order book orders timestamp

fix limitorder null timestamp

If no timestamp from server, we set it to null.


openjdk junit results only showing for failing test targets

We used to keep and display all junit results.  This behaviour seems to have changed (which is undesirable, in my opinion).
Seen on mac & windows builds (where all 8 test targets ran, but only failed junit results showing):
windows example:
https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.openjdk_x86-64_windows/7/tapResults/
jdk_util fails: https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.openjdk_x86-64_windows/7/testReport/  shows only the 665 tests in that target
mac example:
jdk_rmi fails: https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.openjdk_x86-64_mac/8/testReport/ shows only the jdk_rmi 137 tests junit results
testReport view used to show all targets (around 2500 for sanity.openjdk for jdk8, and around 3300 for jdk11)

The auto generated test jobs set KEEP_REPORTDIR as false https://github.com/AdoptOpenJDK/openjdk-tests/blob/master/buildenv/jenkins/testJobTemplate#L160, which delete all passing test results and junit would say
...
05:44:25  KEEP_REPORTDIR=false
...
[Pipeline] junit
06:39:33  Recording test results
06:39:36  None of the test reports contained any result
[Pipeline] echo

The output of https://ci.adoptopenjdk.net/view/Test_openjdk/job/Test_openjdk8_hs_sanity.openjdk_x86-64_linux/21/, which passed and hence no any result at all.
Grinder passing build with test output as KEEP_REPORTDIR=true and get the passing test results https://ci.adoptopenjdk.net/view/work in progress/job/Grinder_Sandbox/550/testReport/
If we'd like to keep and display all junit results we need to re-run auto gen with KEEP_REPORTDIR=true. @llxia

I will regenerate the all jobs with KEEP_REPORTDIR=true

testReport shows up for jdk8 openjdk test builds.
https://ci.adoptopenjdk.net/view/Test_grinder/job/Test_openjdk8_j9_sanity.openjdk_x86-64_linux/19/testReport/
I just regenerated jdk11 openjdk jobs. We should see testReport in next build in jdk11.
https://ci.adoptopenjdk.net/view/Test_grinder/job/Test_Job_Auto_Gen/44/


🚧 sequin.yml

#485  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @RTLS and the rest of your teammates on  Graphite


[Ethylene Glycol] The Map Layers in the Legend in the English version do not display on initial load and the Layers button is non-functional

Found in Dev Environment (RAMP Storyline Release)
Affected site:
National Pollutant Release Inventory Substance Overview: Ethylene Glycol - Canada.ca (https://ecdc-webmappingappsstoryramp-asv.azurewebsites.net/index-ca-en.html#/en/ea24000c-7dc3-49a9-baac-c55d28dcaeb9/)
Platforms:
Issue has been observed on MS Edge and Firefox
Summary:
When a Map loads, the Layers in the Map Legend should appear. However, currently they do not load and the "Layers" button is non-functional. This affects the following maps:
Total releases of ethylene glycol per facility for 2019
Disposals and recycling of Ethylene Glycol reported to the NPRI

Steps to Reproduce:

Open National Pollutant Release Inventory Substance Overview: Ethylene Glycol - Canada.ca (ecdc-webmappingappsstoryramp-asv.azurewebsites.net) and navigate to the Chapter "Total releases of ethylene glycol per facility for 2019"

Wait for the Map to Load.

⚠Notice that the Layers Legend does not display

Image

Believe this has already been resolved by https://github.com/ramp4-pcar4/story-ramp/pull/201, but let's discuss.

Title field needs to be populated to fix this in the short-term.
Medium-term, title can be a mandatory field.

Fixed, after doing a little digging, it seems this was patched awhile ago but that build hadn't gone anywhere yet. This will be resolved in Production automatically after the next push.


Accessories detail refactor

Refactored accessories details per new spec:
Fix #29
Test URLs:

Before: https://main--airlessco--hlxsites.hlx.page/na/en/products/accessories/sprayguns

After: https://accessories-detail-refactor--airlessco--hlxsites.hlx.page/na/en/products/accessories/sprayguns

Before: https://main--airlessco--hlxsites.hlx.page/na/en/products/accessories/striping

After: https://accessories-detail-refactor--airlessco--hlxsites.hlx.page/na/en/products/accessories/striping

Before: https://main--airlessco--hlxsites.hlx.page/na/en/products/accessories/revtipspraytips

After: https://accessories-detail-refactor--airlessco--hlxsites.hlx.page/na/en/products/accessories/revtipspraytips

This is ready for review.  Thanks.


Hybrid confusion.

The documentation is extremely confusing about whether you need to implement a SfB hybrid or not.
Co-existence modes only apply to chat and calls. In every co-existence mode except "Teams Only", chat and calls go to the SfB client. Hybrid implementation is not required for this (see page on Meetings First

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

ID: d53d0cb0-90a6-5932-f78e-7de6fcc4d481
Version Independent ID: 3d468027-cc37-5199-32ec-819bf62b2caa
Content: Interoperability between Skype for business and Microsoft Teams - Microsoft Teams
Content Source: Teams/teams-and-skypeforbusiness-coexistence-and-interoperability.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

@Air-Git  Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

@Air-Git I guess you are refering to this statement, right?

Interop experiences with an on-premises deployment of Skype for Business require that the on-premises environment is in hybrid mode with Office 365 Skype for Business. For details, see Migration and interoperability guidance.

If you go to the mentioned link, the hybrid requirement is explained in detail:

If you have an on-premises deployment of either Skype for Business or Lync, and you want those users to be Teams users, you must at a minimum ensure that Azure AD Connect is syncing the msRTCSIP-DeploymentLocator attribute into AAD, so that Teams/Skype for Business Online properly detects your on-premises environment. Furthermore, to move any users to Teams-only mode (i.e., upgrade a user), you must first configure Skype for Business hybrid mode. For more details, see Configure Azure AD Connect for Skype for Business and Teams.

Interop between Teams and Skype for Business users is only possible if the Teams user is homed online in Skype for Business. The recipient Skype for Business user can be homed either on-premises (and requires configuring Skype for Business Hybrid) or online. Users who are homed in Skype for Business on-premises can use Teams in Islands mode (defined later in this doc), but they cannot use Teams to interop or federate with other users who are using Skype for Business.

I think the issue is that you might assume that a hybrid is in some way a requirement to begin to migrate from SfB on-premise to Teams. Only a very close reading of the documents would tell you that this is not the case.
The second sentence of this page is: "Setting up hybrid connectivity is the first step in moving your on-premises environment to the cloud." In fact it is one of the last steps, and only required to maintain interoperability when people move to Teams Only.
In a lot of cases this may not matter. If a business has open federation in SfB, then the step to create a hybrid is very small. If, however, a business has no federation and no external access, then setting up the hybrid is quite a big step. It is not required to implement SfB with Teams Collaboration and Meetings. It is only required later, when users migrate to Teams Only. At least, that's my understanding of it.

@Air-Git I think the confussion comes from not making a distinction between coexistence and interoperability, which are covered in the article you mentioned when oppening this issue, and federation, which is mentioned in other articles, in relation to Skype for Busines and transitioning to Teams.

I think this statement from the video linked in the article sums it up well:

So as you correctly said, hybrid is not a must but it becomes a must if you want Teams users to talk to your onpremises SfB people or you want to migrate from onpremises SfB Server to SfBO/Teams.
To be honest, i don't know what to add to the article to make it better. In my opinion, the article containes all the useful information and links, it's just a matter of going through it all, which i have to admit will involve a lot of hours.

I agree. If you go through the documents carefully, then you can work out that hybrid is not required until the final step of migrating to Teams Only; and only if you don't just move everyone at once, when again you don't need it.
I'd suggest perhaps amending this statement: "Read this topic to learn how to plan hybrid connectivity between Skype for Business Server and Teams or Skype for Business Online. Setting up hybrid connectivity is the first step in moving your on-premises environment to the cloud." from this page.
If you read the documents with that assumption, then only a very close reading will indicate it is not accurate.
I am assuming that the majority of organisations will have an edge server and public DNS, in which case setting up the hybrid is trivial. But if you have no SfB internet presence at all, then the overall impression is that you need to create it in order to migrate, which is not really the case.

@Air-Git Thank you for this feedback. We can definitely amend that, but i would have one ask:
Since the article referenced when you opened this issue is a diferent one, could you please create a new issue for that specific article, which we should amend?

Done

@Air-Git Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


incorrect value assignment rectified

was always setting the point to itself, so the default value of 0,0

Thanx for the catch.


In-occur additional charges if you move from free-tier to Pay as you Go

[Enter feedback here]
As per documentation :
Azure subscriptions with credit such as Free Trial and Visual Studio Enterprise have spending limits on them. You can only use services up to the included credit. When your usage reaches the spending limit, Azure disables your subscription for the rest of that billing period . Azure subscriptions with credit such as Free Trial and Visual Studio Enterprise have spending limits on them. You can only use services up to the included credit. When your usage reaches the spending limit, Azure disables your subscription for the rest of that billing period
**But what about charges , on upgrading to Pay as You after free tier subscription is disabled ??? , this is not clearly mentioned over here **
I have recently faced this issue , my free tier subscription was disabled and there were resources created in my Free tier account . I upgraded to Pay as You go subscription
What is Expected ?
When as my free tier account is disabled resources should also be disabled / deleted and should not in-occur any additional charges if I move to Pay as You Go
What Actually Happened ?
Resources were present in my Free tier subscription, even though it was disabled  and when I upgraded to Pay as you Go they were transferred to new subscription automatically without intimating or consenting for permission and I was charged for them .
Nowhere in Documentation I can find such use-case . I believe this should not be a case as free tier subscription is intended for Newbie to azure , who could experiment with services and this is the reason they are provided with free credits

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

ID: 0bffdd7e-ea18-32e8-6aa3-1f24e531414f
Version Independent ID: 053c490b-4078-a18c-cc22-38e8e3329dc1
Content: Reactivate a disabled Azure subscription
Content Source: articles/cost-management-billing/manage/subscription-disabled.md
Service: cost-management-billing
Sub-service: billing
GitHub Login: @bandersmsft
Microsoft Alias: banders

@anurag4516  - Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can update the document accordingly.

@anurag4516 Thanks for letting us know about this issue. I'm investigating it with the Billing enginnering team. I'll reply here when I have more info.

https://github.com/MicrosoftDocs/azure-docs-pr/pull/165750

@anurag4516 Hi there. Sorry you ran into this issue. You’re absolutely right, the situation you ran into can occur and it should have been documented appropriately. I’ve updated the following articles to describe the situation.
You might qualify for a refund request. Please open a billing support request to submit your request.
The articles updated are:

https://docs.microsoft.com/azure/cost-management-billing/manage/subscription-disabled
https://docs.microsoft.com/azure/cost-management-billing/manage/upgrade-azure-subscription

#please-close