azure: Support sovereign clouds for discovery and remote write features

Azure's Go SDK only has built in support for AzurePublic, AzureChina, and AzureGovernment clouds. Other national/sovereign clouds exist, along with edge scenarios, but they lack built-in SDK support for the time being.
Prometheus users in these environments are unable to use discovery and remote write functionality as the AAD endpoint and various token audiences are unique to those environments. This PR introduces support for users to specify the Azure cloud as AzureCustom, and provide cloud-specific overrides for AAD endpoints and token audiences. The new YAML format is backward compatible for users that are able to use built in AzurePublic, AzureChina, and AzureGovernment support.

Hello from the bug-scrub!  We apologise that nobody looked at your PR before.
@rakshith210, as an Azure expert, are you able to take a look?


#9952 address failing test cesium.com

This PR addresses issue https://github.com/CesiumGS/cesium/issues/9952 requesting tests on the cesium.com branch be able to run 'offline'.
I originally started working on this with pull request #https://github.com/CesiumGS/cesium/pull/10099, but was unable to complete the requested changes before the PR was closed.
I have since addressed the concerns @ggetz mentioned in the previous thread, and created a new thread and new branch.
Current issue: I can't mock the functions in Specs/Core/sampleTerrainSpec.js
If someone has access to the terrain binaries that match the requirements for the tested methods, it would be greatly appreciated.
EDIT: I closed PR #10357 because I sent the branch to cesium.com instead of main and I couldn't edit it.

Thanks for the pull request @TheMagicNacho!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Changes to third party files were made.

Looks like a file in one of our ThirdParty folders (ThirdParty/, Source/ThirdParty/) has been added or modified. Please verify that it has a section in LICENSE.md and that its license information is up to date with this new version.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.

Hi @TheMagicNacho, there appears to be several unrelated changes, and the commit history is showing many unrelated commits from the cesium.com branch.
Your changes should be pushed a branch that is in sync with main, not with cesium.com.
If all of your changes are in the last commit, you may be able to use the git reset command and move your changes to a new branch, offline-tests.
git reset HEAD~
git stash
git checkout main
git checkout -b offline-tests
git stash apply

@ggetz, your instructions make sense.
I'll open a PR from the branch based off the main branch. I just need a little time.
Thanks for your input!

Closing this pull request to address rebase from cesium.com  > main.
new PR


[Autocomplete] Use ul element for the listbox

Closes https://github.com/mui/material-ui/issues/44264
Explanation
The ul element was lost in this PR: https://github.com/mui/material-ui/pull/43994. Previously, it was provided via the as prop:
https://github.com/mui/material-ui/blob/15ea548de803e4602894cae6304a497d7ddaf09c/packages/mui-material/src/Autocomplete/Autocomplete.js#L560-L561
https://github.com/mui/material-ui/blob/15ea548de803e4602894cae6304a497d7ddaf09c/packages/mui-material/src/Autocomplete/Autocomplete.js#L685
But after https://github.com/mui/material-ui/pull/43994 fix, we failed to maintain it:
https://github.com/mui/material-ui/blob/01c5f344628bc66e16f86284ee0fc7107002a5ca/packages/mui-material/src/Autocomplete/Autocomplete.js#L329
https://github.com/mui/material-ui/blob/01c5f344628bc66e16f86284ee0fc7107002a5ca/packages/mui-material/src/Autocomplete/Autocomplete.js#L559-L560
https://github.com/mui/material-ui/blob/01c5f344628bc66e16f86284ee0fc7107002a5ca/packages/mui-material/src/Autocomplete/Autocomplete.js#L686
Solution
This PR brings it back by setting AutocompleteListbox's element to ul, and adds a test for it.
v5: https://codesandbox.io/p/sandbox/pr-44422-v5-x2ff5z
Before: https://codesandbox.io/p/sandbox/pr-44422-before-l66t9p
After: https://codesandbox.io/p/sandbox/pr-44422-after-cx66k3

@aarongarciah any idea when this will be part of a release (6.1.8 perhaps?)

@rathpc we'll probably release 6.2.0 this week and it'll contain this change.

@rathpc we'll probably release 6.2.0 this week and it'll contain this change.

Perfect, thank you for the fast reply!!

A related issue that will likely conflict with this:
https://github.com/mui/material-ui/issues/42782


Enable --afterok_pattern for gridengine

gridengine takes patterns for dependencies already, but let's use --afterok_pattern for this also so that there is a uniform way of specifying dependencies.

It's already there

Oh good. :-)


close img html tag, main.js --> main.ts in contributing part of readme

Already fixed that!

@SpacingBat3 you didn't change the main.js to main.ts in https://github.com/SpacingBat3/electron-discord-webapp#want-to-contribute-to-my-project


Filtering in history page doesn't reset current page

We have 30 tests (for example), they are displayed on 3 pages.
We select page 2 and then select some status to filter tests. Result should be less 10 entries.
We get an empty result, because all tests on page 1, but we currently on page 2 which is not available after selecting page 1

I've broken it again in #1488; haven't noticed that page reload was intended as a fix for this issue.


Poda.cz (Czech ISP, providing service in between Brno and Ostrava)

$ iperf3 -c rychlost.poda.cz -V -R -P 10 -t 60
...
[SUM]   0.00-60.00  sec  1.36 GBytes   194 Mbits/sec  14445             sender
[SUM]   0.00-60.00  sec  1.35 GBytes   193 Mbits/sec                  receiver
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

iperf Done.

My ISP-provided download limit is around 200 Mbit/s (Netserv.cz in the city of Mikulov) so I don't know what's this server's uplink (they don't even advertise at http://rychlost.poda.cz that it supports iperf) but I know that Poda.cz itself provides fiber to subscribers with up to 2 Gbps plans where they have coverage (https://www.poda.cz/2gbps/).

Nice find! I will test and monitor this one a bit before adding it to the list.

FWIW I've been using Poda.cz as my ISP for about 2-3 years, before I moved to another town that doesn't have their coverage. And I remember running iperf3 against this server occasionally. Haven't noticed any downtime on their side.

Server added to the list. Thanks!

@R0GGER the server location is Ostrava. Mikulov is my location, not theirs.

Oops... fixed. Thanks again!


Seems incorrect with deterministic search

Made a quick run and visualization with your code, and it looks like its producing some unexpected results with transition probability set to 1.
I'm getting the results like this, some of the actions, despite transition probability set to 1, still gives questionable solves.
[→, ↑, ↑, ↑]
[→, R, ←, X]
[→, ↓, ←, ↓]
[↓, X, ↓, ↓]

Let me know if you are getting the same or if I'm running something incorrectly, code changes in https://github.com/JunTaoLuo/KotlinMCTS/pull/1 provide the visualization functionality.

As discussed during our meeting, there were issues in the visualization functions which has been fixed as of https://github.com/JunTaoLuo/KotlinMCTS/commit/17b8bbaf46724ab5d2fe46f2cb1fa203107053b4. There still remains some unexplained results which seem to be an artifact of how MCTS works.


Add issue linking to cards

Add issue linking to cards. Not just to closed issues

Thanks for your contribution!
We track displaying links in https://github.com/nikku/wuffle/issues/3 and support a whole set of links under the hood already.
Does it make sense to implement all supported link types at once?

That makes sense. I will add the other and update the PR

We have updated this PR  with all the link types and it now shows all links for each type rather than just the first one.
We have also changed the card link to display the issue title instead of the respositoryName

A lot of work went into this PR and I'd like to better understand when you feel like it is ready to be merged.
Could you share an up-to-date screenshot with some rationale, why you ended up with that particular solution? Which links do you display, which links are implicit?

This PR is to show all links not just closed linked issues
We show all the links that are available in links. This allows us to see which issues have open PR's  and how issues are linked to each other via the parent/child relationship.
We are plan to eventually show the icons for the relationships as well as per #3 . This is the first part of multiple PR's that we plan on raising. The second will be to add Epic linking and icons  and the third will be to add the dependency icons

These changes are ready to be raised but they are all dependent on this issue being merged.

I'll have a look into this PR tonight.
:crossed_fingers:

Brilliant, thanks.

I've squashed your changes and merged them via https://github.com/nikku/wuffle/commit/ae5e064e8aff309f91803d3b763aa28a45c743ba.
I was not exactly sure about these multiple link definitions for embedded links and ended up simplifying the whole logic via https://github.com/nikku/wuffle/commit/fd4a82cfb643db79d4d76a0e0ef465856e9ac160#diff-0e47c330cd1708169843adab601fbc95R37.
From what I understand that should not have broken any behavior.
It probably makes sense to implement link icons before releasing a new Wuffle version. Right now it, without the appropriate context, it is quite confusing to look at a highly linked issue landscape:


How to encrypt using passwords starting with "-"

Bug: qpdf CLI doesn't accept a password that starts with --.
Discussed in https://github.com/qpdf/qpdf/discussions/873

Originally posted by sz5000 January 10, 2023
If password starts with -, qpdf outputs the following error:
unrecognized argument -test (encryption options must be terminated with --)
qpdf is called with @- to read args from stdin.
--encrypt
XXXX
YYYY
256
[options]
--

The question now is how do we use passwords that start with "-"?
Can we quote or otherwise encode them so that qpdf does not treat them as switch?
If either XXXX or YYYY is something like "-test", then the command line error mentioned above is shown.
--encrypt
-test
YYYY
256
[options]
--

using --password-mode=hex-bytes seems to be problematic because of encoding based on used encryption mode.

See #873 for a workaround in the meantime.

I think I'm going to fix this by changing the syntax of --encrypt to be --encrypt --user=x --owner=y --bits=z ... -- and rewrite the positional argument handling for backward compatibility. If I did that, it would be trivial to support what you are doing.

The above may not work. Anyway, I'm still going to try to fix it one way or another.

This will be fixed for 11.7.0. I have it implemented and tested, but I still need to update the documentation.
The existing syntax of --encrypt user owner bits -- will still work (and I have no plans to ever remove it), but the primary syntax will be --encrypt [--user-password=x] [--owner-password=x] --bits={40,128,256} --.
This means you can use qpdf --encrypt --user-password=-test --owner-password=yyyy --bits=256 --, just like any other password. Also, whichever passwords you don't need are optional, so you can just do qpdf --encrypt --owner-password=something --bits=256 to get a file without a user password. You don't have to pass the empty string as an argument anymore. I'll get the docs updated and get this out soon.

oops, accidentally marked this PR as the unix man page one, though it was closed by the correct commit

The unix man page issue is #1064 in case anyone's looking for it.


Change the old Rspec syntax in the example in README

Rspec is an RSpec pre-3.0 syntax, later replaced with RSpec.

Before submitting the PR make sure the following are checked:

[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[-] Added tests.
[-] Added an entry to the changelog if the new code introduces user-observable changes.
[x] The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

Is there anything else that needs to be made here?


Csv files are not included as resources when exporting project

Godot version:
3.2.1
OS/device including version:
Windows 10 1909
Issue description:
https://godotengine.org/qa/71495/exporting-game-with-external-resources-csv-file
I have a project that parses a csv file. When exporting the project, the csv file is not included with the export. A workaround is to change the file extension to .txt (even renaming it to .tres worked when it came to parsing it, though the editor threw parsing errors when starting the project). Renaming it to .txt hides the file in the godot file tree, for whatever reason (I assume it is because it cannot be directly interacted with via the godot ui, but it is very counter intuitive to have a file tree not reflect it's actual contents, but that is a seperate discussion).
Steps to reproduce:

Open a project
Imprt a .csv file
Change import preset from "CSV Translation" to "CSV"
Open and parse the file content via script
4a. Observe the file being parsed as expected
Export project and include *.csv in the include_filter in the export_presets.cfg file.
Run the exported project
6a. Observe errors in the console stating something similar to

ERROR: File must be opened before use.
At: core/bind/core_bind.cpp:1956

Minimal reproduction project:
https://github.com/oskarious/godot-csv-problems

@oskarious , we do this successfully in our projects which work exported. See repository here. The .csv files are in ivoyager/data/solar_system.
Looking at your repository, I believe the problem is that you shouldn't be thinking of these as resources. If you look at ours, they are in a folder with .gdignore and without any .import files. They are not visible in editor browser, but are available in the export for File.open() (due to inclusion in export_presets.cfg as you have done).

@charliewhitfield
Right, I hear what you are getting at, but even if it is not technically a resource being consumed directly by a node, it should still be included in the export no? My not very qualified guess (since I have only been working with godot actively for 2 or so weeks) is that it wants to treat the csv file as a translation file, since that seem to be the only way csv is used as a resource otherwise, and since I have not started with translations yet it is discarding it? It is of course also entirely possible that the exporter discards unused resources on export, but I have the export_filter set to all_resources.
Again, I have limited experience working with godot, so it is entirely possible I am misunderstanding the ideas behind resources and the file tree/file system.
And yeah, in terms of text editing I am also using an external text editor, so I have no issues interacting with the project, but since it seems like godot wants to be somewhat self contained it seems weird not to list stuff like .txt files. But again, that's not the core of this issue!

This jars my memory of other related problems I've had trying to read contents of directories in exports. Here are two that I remember:

Image files (e.g., res://path/image.jpg) don't "exist" in the export directory. Yes, you can load it with load("res://path/image.jpg"). But it isn't there. The import file "res://path/image.jpg.import" is there.
GDScript files are in the directory, but their extension is changed from ".gd" to ".gdc".

Well, maybe this does make sense after all. You don't want the original source image file in your export file taking up space. And I'm assuming the .gdc is a compressed version of the original.
Here is a function I use for debugging this issue. Just print in both editor run and export project to see differences:
# print(get_dir_path("my_directory_path"))

static func get_dir_files(dir_path: String) -> Array:
	# Use for debugging. Export removes files & changes file names!
	var dir := Directory.new()
	if dir.open(dir_path) != OK:
		print("Could not open dir: ", dir_path)
		return []
	var result := []
	dir.list_dir_begin()
	var file_name := dir.get_next()
	while file_name:
		if !dir.current_is_dir():
			result.append(file_name)
		file_name = dir.get_next()
	return result

Right, that makes sense that it could be some compression/encryption on the resources messing with it. As for GDscript extensions, I would assume that has to do with the script_export_mode which can be Text/Compiled/Encrypted in the GUI, or 0/1/2 in the export_presets.cfg file. Still find it being strange behaviour in terms of imported csv files, but at least it seems to be intended behaviour.

I'll let an expert weigh in after this comment, but I think the bottom line is: Anything imported or with some special "export mode" will likely be missing or altered in an export project's directory.

Yeah, I'd be interested in hearing what someone with more insight has to say as well, but until then I agree with your conclusion. I will also give your method of storing it in a folder with .gdignore a go later as well so I don't have to mess with different file extensions.
Thanks for your input so far though!

I can confirm this, except it's a matter of "import" not "export". Imported files, like textures, audio or CSVs etc. are stored inside the .import directory. When you export project, the source textures/samples are not shipped with the game, but only their imported versions in specific formats (e.g. textures are kept as .stex). Each resource path is remapped to their imported file, so when you (pre)load something, you are actually loading the imported file.
This of course applies only to files with special importers, i.e. textures, audio, models and some other things. Text resources like scenes, scripts or materials are not imported this way (but they are converted to binary equivalents on export. Or most of them at least).

Right, that makes sense that imported resources get's converted into, well, something other than it's source. I guess the confusion initially stems from the fact that one of the import presets for csv is just called "CSV" which sounds like it would be parsable as-is. I probably missed something in the docs, but until I got help from you guys in clearing it up, I had completely missed the distinctions between how the different file types are handled in the editor.

It is possible to write a resource loader for csv, ini and json that converts them to dictionaries. There has been no proposal for it, but it is possible.

I am using a csv file that has the import set to "CSV", and from the sounds of what @KoBeWi wrote I will face the same issue once I actually get around to exporting the project... some solution is needed for data files, definitely.

@Zireael07 , I'm a little puzzled. What's the value of a "CSV data importer"? Is it just to sidestep the use of .gdignore so they show in the file system? Or is there some additional value?

Similar kind of issue #38733

I hope this can be looked at soon. I've been working using an external DB that I save as a csv and then convert at runtime to a dict. It's worked fine in-engine so I didn't realize there'd be any problem with an exported build. I'll try to find some workaround for now.

I hope this can be looked at soon. I've been working using an external DB that I save as a csv and then convert at runtime to a dict. It's worked fine in-engine so I didn't realize there'd be any problem with an exported build. I'll try to find some workaround for now.

Got a simple workaround for anyone here looking who just wants to use CSVs as simple database files:
If you previously did something like opening the CSV and pulling each line as an array, like so: var csv = file.get_csv_line()
You can instead convert the CSV to a TSV (or, just save your actual database file as a TSV instead of a CSV in the first place), then replace the above line with this: var csv = file.get_line().split("\t")
Don't forget to mark *.tsv as an exception in your export templates :) Hope that helps someone out there.

Got a simple workaround for anyone here looking who just wants to use CSVs as simple database files:
If you previously did something like opening the CSV and pulling each line as an array, like so: var csv = file.get_csv_line()
You can instead convert the CSV to a TSV (or, just save your actual database file as a TSV instead of a CSV in the first place), then replace the above line with this: var csv = file.get_line().split("\t")
Don't forget to mark *.tsv as an exception in your export templates :) Hope that helps someone out there.

Fixed by #47268 (and #47300 for 3.3).
You can now configure CSV files not to be imported at all using the "Keep" import mode. The non-functional "CSV" import preset will be removed as it has no use case, it was just a workaround to try to achieve what the new "Keep" mode does (i.e. not import as translations).


Rejecting an alt for skills removes all characters

Rejecting an alt looks like it removes all characters, including the main one.
Steps:

Clear everything, reset all cooldowns
Apply on main, accept main
Apply on alt 1 and alt 2
Reject alt 2 for skills

At this point, Main, alt 1, alt 2, and all other alts are listed as rejected for skills. All characters have been removed from the ACL and are marked as 'insufficient skills' and are on cooldown.

Also, character re-apply cooldown looks like it may be overridden by the most recent reason. I.e., if an alt is removed for skills, all other characters are removed and the cooldown is set to the skills cooldown, regardless of whether the character was removed for a different reason.
I.e.:

Clear everything, reset all cooldowns
Apply on main, accept main
Apply on alts 1, 2 and 3
Accept 1 and 2
Withdraw 3
Remove 2 from ACL
At this point, you should see two rejected applications: alt2 with a 4 week cooldown, alt3 with a 2 day cooldown
Reject alt1 for skills
Now you should see four or more rejected applications, including main and alts 1, 2, and 3. All will have a 5-day skills cooldown.

Are you using the reject button or the kick button?
Reject is on Pending Applications. Kick is on accepted applications
On Sun, Jun 23, 2024, 12:34 AM mome-borogove @.***>
wrote:

Also, character re-apply cooldown looks like it may be overridden by the
most recent reason. I.e., if an alt is removed for skills, all other
characters are removed and the cooldown is set to the skills cooldown,
regardless of whether the character was removed for a different reason.
I.e.:

Clear everything, reset all cooldowns
Apply on main, accept main
Apply on alts 1, 2 and 3
Accept 1 and 2
Withdraw 3
Remove 2 from ACL
At this point, you should see two rejected applications: alt2 with a 4
week cooldown, alt3 with a 2 day cooldown
Reject alt1 for skills
Now you should see four or more rejected applications, including main
and alts 1, 2, and 3. All will have a 5-day skills cooldown.

—
Reply to this email directly, view it on GitHub
https://github.com/EVE-University/whctools/issues/12#issuecomment-2184508417,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADLOBQ6OU53XJVLI25LJZE3ZIZF4JAVCNFSM6AAAAABJYAG5CSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBUGUYDQNBRG4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Are you using the reject button or the kick button? Reject is on Pending Applications. Kick is on accepted applications
Rejecting a pending application (step 4) of an alt for skills removes any other related character, including characters that are still pending and characters that have already been accepted.

So to answer your question directly:
In the first example (the removal), step 4 was rejecting a pending application.
In the second example (the timers), step 6 was removing an alt via the ACL interface, then step 7 was rejecting a pending application.

Ok next question: original requirement was that only one character match for skills. ergo, if a player is being rejected for not having any toons at the minimum required skills, then none of their character should be able to be in the acl
If you are rejecting for skills on an alt, then you are in effect rejecting everyone (though I can accept that the alts probably shouldnt even have that as an option to prevent mistakes)

You're probably right. I guess the confusion here is: if we're requiring all players to have at least one character with required skills, then there should never be a state where an alt should be able to apply without someone already having skills. That would imply a situation where there's already a main and/or more alts already accepted, but none of them have skills. The shouldn't have been there in the first place. If we're not requiring all players to have at least one character with skills, then rejecting all existing characters because of skills doesn't feel right either.
It sounds like the resolution here is either:
(a) always require one character to have skills. If at any point this is no longer true, kick all characters due to skills.
(b) allow players to remove a character with skills. I.e., if someone switches mains and doesn't have the skills, allow them to remain. In this case, rejecting an alt 'due to skills' would be like saying "listen, you used to have the skills, but you don't now, and we were nice enough to let you stay. But now you're trying to add yet more alts without skills. Stop it."
(b) seems easier, since it doesn't require a trigger. Plus, I strongly suspect (a) would need things like a grace period, discord notifications to the player, etc. to make it viable. So let's just go with that for now.

Makes sense. Will adjust
On Mon, Jun 24, 2024, 2:27 PM mome-borogove @.***>
wrote:

You're probably right. I guess the confusion here is: if we're requiring
all players to have at least one character with required skills, then there
should never be a state where an alt should be able to apply without
someone already having skills. That would imply a situation where there's
already a main and/or more alts already accepted, but none of them have
skills. The shouldn't have been there in the first place. If we're not
requiring all players to have at least one character with skills, then
rejecting all existing characters because of skills doesn't feel right
either.
It sounds like the resolution here is either:
(a) always require one character to have skills. If at any point this is
no longer true, kick all characters due to skills.
(b) allow players to remove a character with skills. I.e., if someone
switches mains and doesn't have the skills, allow them to remain. In this
case, rejecting an alt 'due to skills' would be like saying "listen, you
used to have the skills, but you don't now, and we were nice enough to let
you stay. But now you're trying to add yet more alts without skills. Stop
it."
(b) seems easier, since it doesn't require a trigger. Plus, I strongly
suspect (a) would need things like a grace period, discord notifications to
the player, etc. to make it viable. So let's just go with that for now.
—
Reply to this email directly, view it on GitHub
https://github.com/EVE-University/whctools/issues/12#issuecomment-2187161783,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADLOBQ67SL2JBZPYL5C52A3ZJBQINAVCNFSM6AAAAABJYAG5CSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBXGE3DCNZYGM
.
You are receiving this because you commented.Message ID:
@.***>

fixed in current in progress version

Both of the issues listed here seem to be fixed in v0.2.4. Closing.


fix imports to avoid namespace collision

Installing recent head I'm getting following warnings:
R CMD INSTALL sparklyr_0.4.16.tar.gz
#* installing to library ‘/home/jan/R/x86_64-pc-linux-gnu-library/3.2’
#* installing *source* package ‘sparklyr’ ...
#** R
#** inst
#** preparing package for lazy loading
#Warning: replacing previous import by ‘dplyr::copy_to’ when loading ‘sparklyr’
#Warning: replacing previous import by ‘magrittr::%>%’ when loading ‘sparklyr’
#Warning: replacing previous import by ‘tibble::data_frame’ when loading ‘sparklyr’
#** help
#*** installing help indices
#** building package indices
#** testing if installed package can be loaded
#Warning: replacing previous import by ‘dplyr::copy_to’ when loading ‘sparklyr’
#Warning: replacing previous import by ‘magrittr::%>%’ when loading ‘sparklyr’
#Warning: replacing previous import by ‘tibble::data_frame’ when loading ‘sparklyr’
#* DONE (sparklyr)

@kevinushey R 3.2.1

What version of R are you using? I don't see these warnings with R 3.3.1 patched.

Evidently the issue is caused by mixing import and importFrom declarations in a NAMESPACE file in older versions of R: http://stackoverflow.com/questions/8662285/warning-replacing-previous-import-head-when-loading-utils-in-r
Not sure if it's worth fixing in sparklyr since the underlying issue in R has already been resolved. (I repro'ed in R 3.1.3 but not in R 3.2.5)

@kevinushey see https://github.com/jangorecki/sparklyr/commit/b966bdd7d4388563fd140f97783d552c7d44936b it fixed those warning and also pass R CMD check

Ah, didn't realize it was going to be that easy. Thanks!


Update to Go 1.20 and latest KRTE for e2e tests

E2Es broke a few days ago, likely when test-infra upgraded to 1.20. I also couldn't run staticcheck on my Google workstation, which has 1.20, with the same failure message. Upgrading staticcheck fixed the problem; I also took the opportunity to match the test-infra krte image as well as the Golang version (which caused some minor reformatting).
Tested: couldn't build on my workstation on Go 1.20 before this change; can after it.
Fixes #252

/assign @rjbez17

Filed https://github.com/kubernetes/test-infra/pull/28722 to fix presubmit

@adrianludwin
Thank you for your suggestion for #253 !
I tried to run test using your repo as below.(Please let me know if there is anything wrong)
However, make test stil  fails...
$ git clone https://github.com/adrianludwin/hierarchical-namespaces.git -b krte
$ go mod vendor
$ make test
Go version (for logging posterity):
go version go1.20 linux/amd64
...
[BeforeSuite] [FAILED] [10.013 seconds]
[BeforeSuite]
/home/ubuntu-user/go/hnc-test/hierarchical-namespaces/internal/anchor/reconciler_test.go:20

  Begin Captured GinkgoWriter Output >>
    STEP: configuring test environment 02/13/23 15:06:33.363
    STEP: starting test environment 02/13/23 15:06:33.363
    1.6762684033640285e+09	DEBUG	controller-runtime.test-env	starting control plane
    1.676268403373787e+09	ERROR	controller-runtime.test-env	unable to start the controlplane	{"tries": 0, "error": "fork/exec /usr/local/kubebuilder/bin/etcd: no such file or directory"}
    sigs.k8s.io/controller-runtime/pkg/envtest.(*Environment).startControlPlane
    	/home/ubuntu-user/go/hnc-test/hierarchical-namespaces/vendor/sigs.k8s.io/controller-runtime/pkg/envtest/server.go:330
    sigs.k8s.io/controller-runtime/pkg/envtest.(*Environment).Start
    	/home/ubuntu-user/go/hnc-test/hierarchical-namespaces/vendor/sigs.k8s.io/controller-runtime/pkg/envtest/server.go:260
    sigs.k8s.io/hierarchical-namespaces/internal/integtest.HNCBeforeSuite
    	/home/ubuntu-user/go/hnc-test/hierarchical-namespaces/internal/integtest/setup.go:82
    github.com/onsi/ginkgo/v2/internal.(*Suite).runNode.func2
    	/home/ubuntu-user/go/hnc-test/hierarchical-namespaces/vendor/github.com/onsi/ginkgo/v2/internal/suite.go:605
    1.6762684033746772e+09	ERROR	controller-runtime.test-env	unable to start the controlplane	{"tries": 1, "error": "fork/exec /usr/local/kubebuilder/bin/etcd: no such file or directory"}
    ...

/lgtm

/retest
Now that https://github.com/kubernetes/test-infra/pull/28722 is fixed

/retest

cc @rjbez17 can you please re-approve this? I forgot to push my latest changes :P
cc @mochizuki875 sorry about that, please try again, it should be fixed now

/lgtm

@adrianludwin
I tried again and confirmed it was fixed.
Thank you for your work!

Great, thanks!
On Wed, Feb 15, 2023 at 8:52 AM Keita Mochizuki @.***>
wrote:

@adrianludwin https://github.com/adrianludwin
I tried again and confirmed it was fixed.
Thank you for your work!
—
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/hierarchical-namespaces/pull/257#issuecomment-1431403353,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE43PZCLGCC5J6M5PSGSH2LWXTNRXANCNFSM6AAAAAAUYEF2NA
.
You are receiving this because you were mentioned.Message ID:
@.***>


Updates to "How to use the Azure Maps Spatial IO module"

@dubiety

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Fixed typo in DS4Device.cs

Changed "ligtBarColor" to "lightBarColor".
It isn't much but when you would search for "lightBarColor", you would miss on 6 instances where one letter is missing.

I learned this repo is inactive, and there is a more up-to-date version.


Typo "bot Emulator"→"Bot Emulator"

https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-tutorial-orchestrator?view=azure-bot-service-4.0&tabs=cs

#PingMSFTDocs

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

ID: b917a5b0-2fe8-6070-ce27-02543205d078
Version Independent ID: 8a129a06-7836-40db-c4f3-b62eea7d7b52
Content: Use multiple LUIS and QnA models with Orchestrator - Bot Service
Content Source: articles/v4sdk/bot-builder-tutorial-orchestrator.md
Service: bot-service
GitHub Login: @tsuwandy
Microsoft Alias: tiens

Thanks for pointing this out. Closing now that the issue fix has been merged.


[AutoPR] maps/resource-manager

Created to accumulate context: maps/resource-manager

(message created by the CI based on PR content)


Added My Questions, with answers

I created a question for basic practice of loops, conditional statements and functions in python...

Sorry But My PC broke up last night so needed to operate everything using github... therefore  made much more commits than required.


DrupalVM won't spin up on MacBook using M1 chip

Issue Type

Bug Report / Support Request

Your Environment

Vagrant 2.2.18

Your OS

macOS (version)

Full console output
$vagrant up
Bringing machine 'myproject' up with 'vmware_fusion' provider...
==> myproject: Box 'geerlingguy/drupal-vm' could not be found. Attempting to find and install...
    myproject: Box Provider: vmware_desktop, vmware_fusion, vmware_workstation
    myproject: Box Version: >= 0
==> myproject: Loading metadata for box 'geerlingguy/drupal-vm'
    myproject: URL: https://vagrantcloud.com/geerlingguy/drupal-vm
The box you're attempting to add doesn't support the provider
you requested. Please find an alternate box or use an alternate
provider. Double-check your requested provider to verify you didn't
simply misspell it.

If you're adding a box from HashiCorp's Vagrant Cloud, make sure the box is
released.

Name: geerlingguy/drupal-vm
Address: https://vagrantcloud.com/geerlingguy/drupal-vm
Requested provider: ["vmware_desktop", "vmware_fusion", "vmware_workstation"]

Summary
Trying to get existing Acquia BLT/DrupalVM projects running on a new MacBook Pro using the M1 chip (Apple silicon). As Virtual Box won't run on an M1, I'm using VMWare Fusion as a provider. I've added the plugin to box/config.yml:
vagrant_plugins:
  - name: vagrant-vmware-desktop

All relevant dependencies should be met: Vagrant, vmware-desktop plugin. When running vagrant up, I'm met with the above error. Note that these projects were all working on previous (Intel-based) Macs, and were cloned from the same repo, so are in a known good state. The docs for this project seem to indicate that DrupalVM supports VMWare Fusion, but I'm obviously missing something somewhere.
Thanks!

A few years back I stopped building boxes for VMware and Parallels because of the extra licensing requirements (it requires two paid licenses to build for those platforms).
So I standardized on VirtualBox. But now that VirtualBox won't run on M1, I'm not really interested in adapting this project, which is already mostly unmaintained, to work on M1. I would recommend switching to a Docker environment if you need M1 support (that's what I use—in my case a custom one, but I think Docksal or DDEV is good too).

See related: https://github.com/geerlingguy/ansible-for-devops/issues/404

Just dropping a comment to say that I'm moving to an M1 mac soon, and in preparation, have switched to ddev+colima+mutagen (https://ddev.com/ddev-local/docker-desktop-and-colima-benchmarking-on-macos/) for local dev. I have been very happy with it so far.
Also wanted to say a huge thank you to you Jeff (@geerlingguy) for having built/maintained drupalVM all these years. Your contributions are so appreciated!
🙇♀


daemon, ipcache: Plumb root context to IP identity watcher

In the case that the Agent goes down, it can properly signal to the
ipcache package to tear down the IP identity watcher goroutine.
This doesn't resolve any bugs that I'm aware of and just found it via
code inspection.
Signed-off-by: Chris Tarazi<EMAIL_ADDRESS>

/test

/test

Marking ready to merge because CI has passed for all required jobs and we have approving reviews.


Update renderer.lua to use load function instead of loadstring

Be compatible with lua 5.3, lua 5.3 has renamed loadstring to load.

This function is actually unused. In #33 I propose to delete it entirely.

Closed by #33

Closed by #33


Ooth local user verification and password reset

Return updateUser promise chain in ooth-local registered method "generate-verification-token".
Prior to fix, req was getting closed out early.  So registration token generation email was getting sent out, but req was returning error to user.
Ensure that correct password variable was passed to testValue call in registered method "reset-password".
Prior to fix, password resets were not working.

Updated tests are included, but not sure how to handle any versions changes.

This is great, thanks a lot! Congrats for being the first contributor!
I need to give it a closer look at home, will tomorrow.

Thank you again, your pull request was very good. I added nested obfuscation functionality as you mentioned.

Sweet, glad I could help. Thanks again, ooth is a great idea.


How to intergrate it into Google Autotrack

Hello,
I would like to test out this new API, how can I integrate it into Google Autotrack? An example code for AutoTrack looks like this:
<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');

// Replace the following lines with the plugins you want to use.
ga('require', 'eventTracker');
ga('require', 'outboundLinkTracker');
ga('require', 'urlChangeTracker');
// ...

ga('send', 'pageview');
</script>

<script async src="https://www.google-analytics.com/analytics.js"></script>
<script async src="path/to/autotrack.js"></script>

Many thanks.

Sorry, I had an extra bit of code in my Autotrack blocking it, will close this issue - my bad.


Use sandbox to include every user defined PHP files

Since YOURLS 1.9 we have a foolproof sandbox to safely include PHP files, used for plugins : https://github.com/YOURLS/YOURLS/blob/27375bc813f2ddc38030800e466babb72d7a5a66/includes/functions-plugins.php#L682-L696
Rename this function to make it more generic, update tests accordingly, and reuse it for :
Pages:
https://github.com/YOURLS/YOURLS/blob/27375bc813f2ddc38030800e466babb72d7a5a66/includes/functions-html.php#L865
Custom DB error:
https://github.com/YOURLS/YOURLS/blob/27375bc813f2ddc38030800e466babb72d7a5a66/includes/Database/YDB.php#L161
Custom maintenance page:
https://github.com/YOURLS/YOURLS/blob/27375bc813f2ddc38030800e466babb72d7a5a66/includes/functions.php#L1052
Custom DB or cache layer:
https://github.com/YOURLS/YOURLS/blob/27375bc813f2ddc38030800e466babb72d7a5a66/includes/Config/Init.php#L143-L165
(by the way, rename that "cache.php" to something understandable -- must-use-plugin.php? unconditional-use-plugin.php?)

And document those "special files" damnit -- #3045

Keen to PR this if there is no current WIP.

Added PR https://github.com/YOURLS/YOURLS/pull/3478 with changes but did not rename cache.php.   The entire verbiage around 'cache' is confusing to me.  Could this be its own issue with a more apt description of what it is?  Is it a cache layer or an always on plugin, or...?
eg
"// Allow early inclusion of a cache layer"
vs
"// Allow early inclusion of always on plugin layer"

Yeah the wording used for this file is especially poor :-) I think it's more "always-on plugins or custom files"

The case is settled. It's named "cache.php" because it stands for "Custom Additional Code for Hazardous Extensions" :)


Support other programming languages

We could use C++ for Algorithms and Data Structures for the wintersemester 2024/25

Will look into it. Shouldn't be too big a problem since the CPP build tools are readily available and unlike e.g. Java, there are basically no restrictions regarding the project structure


Server Error

I keep getting this Error in console, I thought you might want to know.
http://www.codesend.com/view/3b84500a0fc16d5ee8ba2c2e64893840/
I believe it comes up when someone attacks a Vampirism NPC.

Alice
DragontechMC

Another Error, no idea what this is
http://www.codesend.com/view/b2ae5a89bc1b527679c03b1118e0b028/

Oh look, another one
http://www.codesend.com/view/8c5f76139ec22e03a2be783b73a6bb4d/

And another...
http://www.codesend.com/view/8f0d8458496c63edeedd831ad84808b0/

Fixed in the new code.


Single row, horizontal scroll.

Seems simple/common thing, but I could not figure out how to do it.
Basically, I want to lay out cells from left to right, with horizontal scrolling. Only 1 row.
what is the best way to achieve this?

You'll want to create a custom layout (or subclass one of the layouts) override the - scrollDirection method to return JNWCollectionViewScrollDirectionHorizontal.Then make sure the content size is such that the content height is the bounds of the collection view, and the content width is as wide as you want it to be. That should do the trick.


Broker: brokerDeduplicationSnapshotFrequencyInSeconds default should be 10

Motivation
In the default configuration file conf/broker.conf the entry brokerDeduplicationSnapshotFrequencyInSeconds is 10,
but in the Java code the default is 120.
So if you comment out or you remove that line in broker.conf the behaviour of the broker changes.
Modifications
Change the default value from 120 to 10.
An alternative could be to change broker.conf, but doing so if you upgrade the Pulsar docker image you would see an unexpected behaviour change, so it is better to change the Java value.
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.

LGTM, could you please help add a test to avoid the regression?
This is a very valid point, as we don't have tests for every default value.

I am sorry but I don't have time this week. I could create an issue and follow up in the future.
What do you think ?

I could create an issue and follow up in the future.

This entry is missing in doc too. See https://pulsar.apache.org/docs/en/reference-configuration/

I extended this fix here: https://github.com/apache/pulsar/pull/13272

We'd better keep it 120s, 10s is too short.


Bump to 1.3.4

Pull Request Test Coverage Report for Build 159

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 158:
0.0%

Covered Lines:
947

Relevant Lines:
947

💛  - Coveralls


raftstore: check level 0 files before ingest (#3606)

What have you changed? (mandatory)
cherry pick https://github.com/tikv/tikv/pull/3606

LGTM.


Adding the codeMatch option in LCResourcesHandler

This PR adds the codeMatch option in LCResourcesHandler which defaults to true (previous behavior). When set to false, the codeMatch option disables matching on the code (to only match on the label).

Looks good to me, you can merge!

@ymeine Thank you for your review


addon lifecycle enhancement

Ref: https://github.com/open-cluster-management-io/enhancements/issues/81
https://github.com/open-cluster-management-io/OCM/issues/114
Signed-off-by: haoqing0110<EMAIL_ADDRESS>

/assign @qiujian16 @deads2k

/cc @elgnay @skeeey @zhiweiyin318

Hello @deads2k @qiujian16 @skeeey I append an alternatives ,to treat the version as a variable of config. There are some gaps and concerns listed in the doc, want to know your ideas on that, and any other better suggestion on that?

Sorry for taking so long to refresh the proposal, the new proposal is trying to combine rollout strategy and config based on https://github.com/open-cluster-management-io/enhancements/pull/84 .
It indeed takes some effort to consider, simplify and cover all the cases, now the new API is relatively clear.
@deads2k @qiujian16 @skeeey Looking forward to your comments and feedback.
/cc @zhiweiyin318 @zhujian7

I like the idea and it still lgtm.  I think it composed pretty well with https://github.com/open-cluster-management-io/enhancements/pull/82 .
It will be interesting to learn how many placements are added in practice, whether it is just one or multiple.  That might inform the idea of allowing defining the "install here" separately in the future. But given how well it composed, this looks like a good place to start.

Try to add kustomize examples in the latest commits .
@deads2k see you used HashTransformer in https://github.com/open-cluster-management-io/enhancements/pull/84 , I try to search it, but don't find an example of it in kustomize website. I'm wondering what's it used for? Can it be used in this proposal?

@qiujian16 plz help tag.

/approve
/lgtm


Remove unused

also trigger semantic-release, hopefully

:tada: This PR is included in version 4.9.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Undefined index: standardsTree

On composer update this morning (26/08/2015) composer fails with:
[ErrorException]
Undefined index: standardsTree

This looks to be related to a change last night.
Thanks

Check out the release notes: https://github.com/dingo/api/releases/tag/v1.0.0-beta2

Sorry, I am retarded

All good mate.
On Wed, 26 Aug 2015 18:29 Mark Kendall<EMAIL_ADDRESS>wrote:

Sorry, I am retarded
—
Reply to this email directly or view it on GitHub
https://github.com/dingo/api/issues/604#issuecomment-134896746.


Promise interface of prefs.fetch('key') does not work on Android 4.x.x

Using the following method fails with the error: Error in Success callbackId: ... . It does not call the fail callback.
// fetch the value for a key using promise
prefs.fetch ('key').then (ok, fail);

Instead, I used the non-promised version prefs.fetch (ok, fail, 'key'); and it worked successfully. I reviewed the implementation and it looks it cannot find a valid Promise object in this section. It seems like the global Promise is not supported in Android 4.
Let me know if I'm missing something. Not sure is actually an issue of the library, so feel free to close, but might be useful for reference.
Thanks!

Promise interface will work only if you have a proper promise interface. Android 4.x is quite old and mostly not supports promises. Callback version should work every time.


Indonesian

I translated Elixir Scool to Indonesian language (Bahasa Indonesia).

Wow wow wow @rezaprima!  This is amazing, thank you so much!  I'm going to look over this and make sure everything is good to go and then we can merge.
Do you have a twitter account?

yes, my twitter handle is @rprimar
Thank you very much.
On Tue, May 24, 2016 at 4:50 AM, Sean Callan<EMAIL_ADDRESS>wrote:

Wow wow wow @rezaprima https://github.com/rezaprima! This is amazing,
thank you so much! I'm going to look over this and make sure everything is
good to go and then we can merge.
Do you have a twitter account?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/doomspork/elixir-school/pull/394#issuecomment-221106970

Holy smokes, thanks @rezaprima 😄

I fixed the missing backtick. Thank you very much

Thank you @rezaprima 👍

I didn't want to squash all of your commits so I re-enabled merges just for you 😀

Wow. Thanks a lot. ^_^
On Wed, Jun 1, 2016 at 12:20 AM, Sean Callan<EMAIL_ADDRESS>wrote:

I didn't want to squash all of your commits so I re-enabled merges just
for you 😀
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/doomspork/elixir-school/pull/394#issuecomment-222757919,
or mute the thread
https://github.com/notifications/unsubscribe/AACQuuAE7yhqL9SNUUdBXSme0AeWX1OPks5qHG3ogaJpZM4IkKn5
.


Add missing alt & title attributes to image references.

Addresses #420

Jenkins job istio.github.io/presubmit passed


iota-ipm showing wrong port numbers

My node is behind a router and external ports are transferred to internal ports.
After some time my tcp neighbor sees in iota-pm instead of my external url tcp://x.y.com:13095 my internal port number, tcp://x.y.com:15777. I assume, that the internal portnumber is transported in some transactions and finds its way to the iota-ipm. The effect is letal, because before a restart the operator will save the list of neighbors and copy them into his iota.ini file. After restart the wrong external portnumbers prohibit further communication...

To get it clear: You are operating the node behind a NAT?

yes, because my company network runs a lot of different services, so you have to find free external ports.  The same may be true for datacenters. There is no problem in running iri - its only that the ipm running on my neighbor's node displays after "some time" my internal port numbers instead of my external port numbers.

Hi,
IOTA PM retrieves the list of neighbors from IRI via the APIs. If the ports are changed, it is due to IRI reporting incorrect ports. Could you please raise this issue with IRI repo instead? It would also be helpful to get a curl output in this situation from following API
https://iota.readme.io/reference#getneighborsactivity

raised with iri repo, see: https://github.com/iotaledger/iri/issues/382


Future of schemas in bdg-formats

Thoughts:
(1) We need to make progress towards a 1.0 release
(2) Part, maybe the most important part, of such a release is a clear way where we can commit to supporting certain 'stable' Avro record schemas and data models,
(3) the current models package is a mess, built without Avro (Scala classes mostly) and whose conceptual overlap with the models from bdg-formats is unclear (even to us!)
(4) the current bdg-formats package is also a mess, containing both record schemas that we rely on (AlignmentRecord!) as well as a number of duplicative or more experimental schemas.
Prior to the Amplab retreat last week (and unfortunately, @fnothaft, after you had left for the day) we -- myself, Matt, Uri, Michael, and Justin -- tried to talk through how we might approach some of these problems in a measured way.
Here are some of the ideas we came up with:
(A) bdg-formats will be, post-1.0 release, the "supported" schemas: pared down as much as possible, changing as slowly as possible, and with attention paid to migrations when they change,
(B) some of the more experimental, unused, or redundant schemas will be moved back into the models package in the adam repo,
(C) the models package will become our experimental 'staging' area, with interfaces that we use but aren't committed to supporting in their current form for the long term,
(D) the existing model classes will each be split, into an Avro record schema and (for the class methods that live inside each model class at the moment) a paired "Utils" class containing static methods.
Here's a screenshot of one of the whiteboards from last week's conversation, showing a list of all the record schemas in bdg-formats today and some rough notation as to which schemas we think might stay, disappear, or move back into models:

One of the questions arising from the discussion was "how difficult will (D) be?" That's the question I'm trying to address, with the first PR.
I'll editorialize: I'm not sure this is the right answer, but I think (personally) it's a move in the right direction.  We need to be clear about what models is, which interfaces we're supporting, and how the models stuff interacts with the bdg-formats stuff.  Also, we've got a lot of single-use classes in models (Frank, as you pointed out, SingleReadBucket is mostly used by MarkDuplicates) which seems like a code-smell to me.  At any rate, even if this exercise is impetus to re-evaluate all the schemas that are currently in bdg-formats and to pare down the (unmanageably large) number in there at the moment to something more usable, then I believe it will have been worth it.

I'll try to render that whiteboard as text soon.

feel free to copy from the google doc as necessary

That's a good point, I will. [Rummages through Google docs...] what's it called, again?

Will do.  I mostly want this Issue to be about the Avro records / models issue and designating a core of the bdg-formats schemas as "supported."

Thanks for putting this together, @tdanford!

(3) the current models package is a mess, built without Avro (Scala classes mostly) and whose conceptual overlap with the models from bdg-formats is unclear (even to us!)

I think this is too imprecise to be actionable. Specifically, what is a mess about our current models? E.g.,:

Do we have unused models?
Should some of the models be migrated into another package or made package private? <-- I think this is definitely the case for models like Alphabet, SnpTable, IndelTable, Consensus...
Do we have dead code in some of our models?
Do the data models that our models present not fit their intended use cases?
Should our models do less? I.e., should they just be bean-like?

Also, why an Avro defined class preferable here to Scala classes/case classes?
As for the overlap between org.bdgenomics.adam.models and bdg-formats, I've always conceived the separation as:

bdg-formats: primary genomic datatypes that we expect to store
org.bdgenomics.adam.models: common classes that describe secondaey genomic data (e.g., genomic positions), or metadata (e.g., collections of read groups)
org.bdgenomics.adam.rich: Classes that enrich our basic bdg-formats records

(4) the current bdg-formats package is also a mess, containing both record schemas that we rely on (AlignmentRecord!) as well as a number of duplicative or more experimental schemas.

I would describe the feature, variant annotation, and fragments schemas as experimental. My preference would be to harden important schemas to production quality, instead of making the schemas experimental. For example, we can't do a round trip from annotated VCF --> ADAM --> annotated VCF without a quality DatabaseVariantAnnotation schema.
From my point of view, it is much more important for a 1.0 release to be feature complete and concordant for basic features (like data import and export) than for the 1.0 release to have a maximally clean API. Not that API cleanliness isn't important—it's definitively a high priority—but who cares about what the APIs or schemas look like if we don't have the fundamentals down? Essentially, if we don't have a variant annotation schema that we're going to stand behind, then we can't do annotated VCF --> ADAM --> annotated VCF, and if we can't do that, then we shouldn't be tagging a 1.0.

I'll editorialize: I'm not sure this is the right answer, but I think (personally) it's a move in the right direction. We need to be clear about what models is, which interfaces we're supporting, and how the models stuff interacts with the bdg-formats stuff. Also, we've got a lot of single-use classes in models (Frank, as you pointed out, SingleReadBucket is mostly used by MarkDuplicates) which seems like a code-smell to me.

I think the code smell is that we're exposing these classes as public classes in the models package. IMO, the solution is much simpler than what this issue posits: we make those classes private, and move them to the package where their algorithm lives.

At any rate, even if this exercise is impetus to re-evaluate all the schemas that are currently in bdg-formats and to pare down the (unmanageably large) number in there at the moment to something more usable, then I believe it will have been worth it.

Sorry, that comment posted before it was finished... Part 2 coming shortly.

(D) the existing model classes will each be split, into an Avro record schema and (for the class methods that live inside each model class at the moment) a paired "Utils" class containing static methods.

IMO, this is pretty smelly. I don't understand why this would be preferable to having a case class whose instance methods do what the new Utils class would do. To do this for all model classes would be a major refactor, and I'm just not seeing what we'd gain...?

At any rate, even if this exercise is impetus to re-evaluate all the schemas that are currently in bdg-formats and to pare down the (unmanageably large) number in there at the moment to something more usable, then I believe it will have been worth it.

I think that re-evaluating the schemas is wise and is something we should be doing all the time, but I don't think that we have an unimaginable large set of schemas... 18 individual objects is a bit steep, I suppose, but that's mostly because our schemas are fairly deeply nested. E.g., a VCF line explodes out into something like this:

DatabaseVariantAnnotation
Genotype

Variant

Contig
StructuralVariant

StructuralVariantType

GenotypeAllele
VariantCallingAnnotations

So, 18 schemas is a bit steep I suppose, but I think the number of schemas we have just reflects the complexity of the data we're working with and the way that we've decomposed our data model.

I care about two things:

a version 1.0 of schema should mean that users can leave data around on disk in those formats for long periods of time without worrying that they will become incompatibly out of date.  From that point forward we need to not change things or provide simple conversion tools.

any public APIs in version 1.0 of the code become subject to binary compatibility rules going forward, which makes it more difficult to make changes.  Anything public at that point should be worth committing to.

By some combination of hardening the schema and API we care about and moving to experimental or making private those we don't, we'll get there.

Do we have unused models?

I believe we do.

Should some of the models be migrated into another package or made package private? <-- I think this is definitely the case for models like Alphabet, SnpTable, IndelTable, Consensus...

Yeah, I agree, and I'm not claiming that everything in models should stay there.

Do we have dead code in some of our models?

Yes.

Do the data models that our models present not fit their intended use cases?

Clearly, for two reasons:

It's not clear what the intended use case is, for a lot of the models, and
more importantly, it's not clear to me why some models should be Avro records with schemas in bdg-formats, and some should be classes living in the models package.  It's not clear to me which schemas, and which models, are "supported" and which are "experimental."

Should our models do less? I.e., should they just be bean-like?

This was exactly Matt's claim -- that the models should be more bean-like.  @massie want to elaborate?

One of the reasons that I listed the bullets that I did is because I think we can get a better bang-for-the-buck by doing the small refactoring that these bullets imply, than by doing rewriting our models. I think this issue conflates two issues:

Our models need to be refactored and cleaned up.
It isn't clear what schemas in bdg-formats are supported/experimental.

I don't really support rewriting our models as bean-like classes with singleton objects that provide all of our current functionality via static methods mostly because this seems unnecessarily expansive. Realistically, that would mean rewriting the entire models package. I think we would get better bang-for-the-buck from doing the simple refactoring I suggested above (moving some models out of the model package and cleaning up dead code). Rewriting the models package just doesn't seem like a good use of effort—we've got many other issues to spread our effort across between now and 1.0.0. Perhaps I'm missing the benefits of rewriting our models to follow the bean + singleton pattern?
As for the experimental/supported schema issue, it might be good here to work backwards from a 1.0.0 release. Specifically, what formats do we feel like we would need to support in a 1.0.0? Once we've identified which schemas need to be supported, we can triage any remaining schemas into "supported" and "experimental" based on their maturity.

Okay, sorry, let me say this in a different way:
I believe we need a way to mark some of our Avro schemas as "experimental" or in "development."  We can do this with comments, with annotations (which I don't think are a thing in Avro?) or by putting them in a new, separate place.
I support the third option (new location), and I think the models package is a good place for those experimental schemas.
This is orthogonal to whether some of the existing model classes should move into other, private, tool- or application-specific packages (I believe that that's probably a good idea anyway).  If you accept that models is a good location for experimental Avro schemas, then it seems clear (to me) that some of our current model classes will be (should become) Avro schemas, and then the question is: how hard is it, to make this transition from class -> schema.
That's what the PR was an attempt to explore: how hard is back-porting a class to a schema?
Answer: probably not the worst.
If we decide that SingleReadBucket should just stay a class, but should live in another package, that's fine too.  If we decide that we want the experimental Avro schemas should live somewhere else and not in models, that's fine too (and I think people should start making suggestions as to where that should be).  If we think we'd rather use another method for marking out "experimental" schemas, then let's hear that as well.
Make sense?

I believe we need a way to mark some of our Avro schemas as "experimental" or in "development." We can do this with comments, with annotations (which I don't think are a thing in Avro?) or by putting them in a new, separate place.

Agreed. Sorry, I think I misinterpreted this issue as focusing on:

This is orthogonal to whether some of the existing model classes should move into other, private, tool- or application-specific packages (I believe that that's probably a good idea anyway). If you accept that models is a good location for experimental Avro schemas, then it seems clear (to me) that some of our current model classes will be (should become) Avro schemas, and then the question is: how hard is it, to make this transition from class -> schema.

Again, if the issue is about making a home for experimental schemas, that sounds reasonable to me. I think though—and this may be because I missed the conversation where the original discussion took place—that the correct way to determine which schemas should be supported and which schemas should be experimental is to figure out what data import/export we want to support in a 1.0, and to work backwards from that. As I understand, the image posted with this ticket was us triaging our current schemas into supported/experimental on the basis of current usage/maturity. Since we control the timeline to a 1.0, I think it is preferable to work backwards from what we want to support, instead of working forwards from where we are right now.

This is orthogonal to whether some of the existing model classes should move into other, private, tool- or application-specific packages (I believe that that's probably a good idea anyway). If you accept that models is a good location for experimental Avro schemas, then it seems clear (to me) that some of our current model classes will be (should become) Avro schemas, and then the question is: how hard is it, to make this transition from class -> schema.

It isn't clear to met at all that any of our current model classes should become Avro schemas. What is the advantage of having Avro beans + singleton objects vs. Scala case classes with instance methods?

That's what the PR was an attempt to explore: how hard is back-porting a class to a schema?
Answer: probably not the worst.

I think this is a false extrapolation. SingleReadBucket is easy to rewrite because it is used in one place (MarkDuplicates), while other models (ReferenceRegion/Position, SequenceDictionary, RecordGroupDictionary, etc) are used pervasively throughout our codebase. The models that are used in a single algorithm (SnpTable, IndelTable, Consensus, etc) probably shouldn't be rewritten, they should just be moved to the package that the algorithm that uses them lives in, and be made package private.
To summarize my opinions:

I think marking schemas as experimental/supported is a good idea for a 1.0 release. I am agnostic as to whether they should go in an "experimental package" or be annotated or whatever.
I think we should work backwards from what we plan to support in a 1.0 release to determine which schemas should be supported vs. experimental.
I think we should migrate single purpose models into their appropriate package and make them package private.
I do not think we should rewrite our existing models as Avro schemas + Singleton objects, because I do not understand why this is better than our current approach.

It isn't clear to met at all that any of our current model classes should become Avro schemas. What is
the advantage of having Avro beans + singleton objects vs. Scala case classes with instance methods?
Serialization! SequenceDictionary was, you may recall, originally an Avro schema.  RecordGroupDictionary could be too. Managing and carrying along metadata for things like variants and alignment records and raw reads and features and reference sequence is, I argue, one of the major blind spots in ADAM right now.

I think this is a false extrapolation.

Actually, the question about "how hard is the refactoring" was mostly a question of things like: imports between Avro .avdls, usage of IntelliJ, etc.  The original question was really mechanical, not so much about the particular class that I chose first.

As I understand, the image posted with this ticket was us triaging our current schemas
into supported/experimental on the basis of current usage/maturity. Since we control the
timeline to a 1.0, I think it is preferable to work backwards from what we want to support,
instead of working forwards from where we are right now.

Yeah, that whiteboard image wasn't a final answer, it was an example of what kinds of decisions we might make.  I posted it for completeness.
The priority here is to get moving on 1.0.  We all basically agreed with you, Frank: getting to a 1.0 release is important to a number of us, and no one wants you to be the only person doing any of the work.

SequenceDictionary was, you may recall, originally an Avro schema. RecordGroupDictionary could be too. Managing and carrying along metadata for things like variants and alignment records and raw reads and features and reference sequence is, I argue, one of the major blind spots in ADAM right now.

Both are backed on disk by Avro schemas (from bdg-formats) as of #906. #909 is open to port this exact fix over to RDD[Genotype].

In the interest of moving this issue forward, I'm going to focus on this suggestion

I think we should work backwards from what we plan to support in a 1.0 release to
determine which schemas should be supported vs. experimental.

In the interest of moving this issue forward, I'm going to focus on this suggestion

+1
I'd like to support:

AlignmentRecord <-> SAM, BAM
Genotype and all schemas nested underneath <-> VCF
DatabaseVariantAnnotation and all schemas nested underneath <-> VCF

The red scribbles on the left side of the board were our high-level suggestions

Reference sequence (refactor Contig and NucleotideContigFragment to look more like GA4GH)
Sequence annotations/Features (support GFF3 and BED-like formats)
Variants and Genotypes

Variant annotations (merge DatabaseVariantAnnotation and VCF ANN spec stuff)

Sample tracking/metadata (sampleId might not be enough)

Some of this might be considered new/experimental, though I'm not concerned we couldn't get it all whipped into shape for a version 1.0.

There were also some high level comments, like "factor out all the enums to a separate file and align their values with external ontologies, explicitly noted in teh comments."

+1 to working backwards from what to support in 1.0.  I think @fnothaft's limited selection is a good start.  I'd also support @heuermh's additions, though I don't think they are as crucial.  Since we don't operate actively on those additional data types (AFAIK), we're probably farther from production-readiness there.

With the various refactors we've done on the schemas and the conversion datapaths recently, I don't think this issues is relevant anymore. Does anyone have an objection to closing? CC @heuermh @laserson ?

I'd be ok with closing this.  Those things mentioned here I see as still unresolved are in separate issues on bdg-formats.


array of  QueryParam problem

if I wan to parse a query param  to  string[] . for example:
GET /xxx?p=xx&p=yy

with router:
@Get('/xxx')
fun(@QueryParam('flags') flags: string[]){
}

will be ok, bug When
GET /xxx?p=xx

will cause an error:
Given parameter p is invalid. Value (\"a\") cannot be parsed into JSON.

Arrays are not supported in this way. You should try to do this this way:
class FunQueryParams {
 @Type(() => String)
 flags: string[];
}
// ...
@Get('/xxx')
fun(@QueryParams() { flags }: FunQueryParams) {
}

However I'm not sure if it works in 0.7.x, if not you have to ping @pleerock to take a look at #315 😉


[Feature Request]: Search all history messages

Problem Description
A box as shown in this pr (https://github.com/ChatGPTNextWeb/ChatGPT-Next-Web/pull/1926) to search all old messages.  I see the search part wasn't merged; could it be?
Solution Description
Implement search of history including full text of all discussions.
Alternatives Considered
No response
Additional Context
No response

Because dev use quick switcher as the search box, so i closed this pr before.

is quick switcher something like a command I can use to search the history?

Problem Description
A box as shown in this pr (#1926) to search all old messages. I see the search part wasn't merged; could it be?
Solution Description
Implement search of history including full text of all discussions.
Alternatives Considered
No response
Additional Context
No response

Thank you for your feedback, we will provide a feature for users to search chats by some keywords in messages as same as the great idea  https://github.com/ChatGPTNextWeb/ChatGPT-Next-Web/pull/1926
from Quorafind


/help docs are missing url

Issue
Looking at the .aider.chat.history.md I found that all the relevant docs provided to the LLM do not contain URL's, but that is not correct, the help.py file shows the metadata should contain url for each vector but it's actually blank:
// tail of docstore.json
3a-4446-8d65-6778f534f366", "92ae0bda-5a6b-41cc-8d5a-c399a1f7a474"], "metadata": {"filename": "index.md", "extension": ".md", "url": ""}}, "f2a7307a-8e88-4064-92f7-6b220f9f1dd4": {"node_ids": ["7a715684-a67a-445a-84e8-85a5420fbf99", "e6b59240-de7a-4573-9197-c41822ac1809", "7e9c8bbb-b3d4-4f46-b913-6647a7453bfa", "061b7aa9-0661-497b-8403-f9f4e3be8a19"], "metadata": {"filename": "index.md", "extension": ".md", "url": ""}}}}

Version and model info
aider 0.59.1

Thanks for trying aider and filing this issue.
The fix is available in the main branch. You can get it by installing the latest version from github:
aider --install-main-branch

# or...

python -m pip install --upgrade git+https://github.com/paul-gauthier/aider.git

If you have a chance to try it, let me know if it works better for you.

I'm going to close this issue for now, but feel free to add a comment here and I will re-open. Or feel free to file a new issue any time.


Creating Azure AD Kerberos Object in High Security environments needs instructions

When considering some higher security and zero trust environments, these instructions do not often work.  Most will have the following restrictions:
Domain Controllers - unable to reach the Internet or even Azure Portal
Domain Joined Machines - unable to execute processes as domain admin
Is it possible to outline a manual configuration with the AD User Account and process or even a script to run in Azure with the credentials there and then another on the Domain Controller with domain admin credentials and needed info there?

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

ID: 50b27a01-622e-d980-83f2-1ed27060613b
Version Independent ID: e6472e15-10d7-bd4a-da02-558f2774dbaf
Content: Passwordless security key sign-in to on-premises resources - Microsoft Entra
Content Source: articles/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises.md
Service: active-directory
Sub-service: authentication
GitHub Login: @Justinha
Microsoft Alias: justinha

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

Hi @JCoreMS
I understand your concern. In some higher security and zero trust environments, the instructions provided in the tutorial may not work due to certain restrictions.
Regarding your question, I can provide you with the manual configuration steps to create a Kerberos Server object in Active Directory and publish it to Azure Active Directory. Please note that these steps assume that you have the necessary permissions to perform these actions.
1.Open a PowerShell prompt using the Run as administrator option.
2.Install the Azure AD Kerberos PowerShell module by running the following command:
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
3.Create a new Azure AD Kerberos Server object in Active Directory and publish it to Azure Active Directory by running the following command:
powershell
Set-AzureADKerberosServer -Domain  -CloudCredential  -DomainCredential
Replace  with the name of your on-premises Active Directory domain.  is the credential of an Azure Active Directory global administrator, and  is the credential of a domain administrator.
4.Verify the newly created Azure AD Kerberos Server by running the following command:
Get-AzureADKerberosServer -Domain  -CloudCredential  -DomainCredential
This command outputs the properties of the Azure AD Kerberos Server. You can review the properties to verify that everything is in good order.
Please note that these steps are only for creating a Kerberos Server object in Active Directory and publishing it to Azure Active Directory. You will need to follow the rest of the tutorial to enable passwordless security key sign-in to on-premises resources.
I hope this helps. Let me know if you have any other questions or concerns.

@JCoreMS
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation

Hi @JCoreMS

We are implementing Window Hello for our workstations, and as a pre-requisites we are planning to create Azure AD Kerberos Object in our on-prem Domain controller. Before that I just wanted to confirm that creation of this object will not impact any other functionality of our Active Directory, correct?


Way to line up opposing footers

This is a common occurence:

I would like a way to line these up perfectly.
Alternatively, being able to override HA's default card width would allow this just by having an extra wide view using "-contained" borders, and filling the two columns via horizontal stacks.

That does work! Using the new Masonry (layout-card) and adding width: 800 into the text box does allow me to have one very wide LCARS themed card. Unfortunately for me, the cards I wanted to use are custom HACS cards that have problems like those in issue 48, like so:

Seems any custom HACS card gets funky.

Alternatively, I was able to tweak it slightly to bump the height of the shorter footer:
    card_mod:
      class: footer
      style: |
        ha-card {
          font-size: 1.17em
        }

It lines up differently between devices (still a pixel off on desktop), but that's fine as I only cared about how it looks on my tablet.

I know this is marked as completed, but I have a different solution to line up opposing or indeed multiple footers in row of vertical stacks.  I use this method quite extensively on my tablet dashboard. Here's an example of such a line up

I used the following to change the card height until the footers align. You can apply this to individual entities in an entities card as well:
  - type: custom:power-distribution-card
    card_mod:
      class: middle-left
      style: |
        ha-card {
          height: 368px !important;
        }


psffpp-pin and other commands added

:tada: This PR is included in version 2.38.0 :tada:
Your semantic-release bot :package::rocket:


Add new Topic Subscription does not work

i have used the files for my own web site to test the functionality. Publishing topics works as expected, however Subscribing cannot be tested because when pressing the button "Add New Topic Subscription", no window opens like the one on the demo in the HiveMQ website.

Hi @malebuffy - this isssue has gone stale.  Apologies for the lack of response.
If this is still an issue for you, could you let us know?  We have a new websocket in Beta to be released soon so I suspect this will be a nil issue going forward with the new client.
I'll close this issue out but feel free to open another if it persists.


Build issue with bazel "python_bin_path.sh: No such file or directory"

I've updated my code, and following what is currently listed under https://www.tensorflow.org/versions/master/get_started/os_setup.html#source arrived at this output:
alex@ml1:~/tensorflow$ bazel build -c opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
INFO: Found 1 target...
Target //tensorflow/tools/pip_package:build_pip_package up-to-date:
  bazel-bin/tensorflow/tools/pip_package/build_pip_package
INFO: Elapsed time: 0.793s, Critical Path: 0.00s
alex@ml1:~/tensorflow$ bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
Thu Dec 10 12:13:53 PST 2015 : === Using tmpdir: /tmp/tmp.NqHERREKmr
/tmp/tmp.NqHERREKmr ~/tensorflow
Thu Dec 10 12:13:53 PST 2015 : === Building wheel
bazel-bin/tensorflow/tools/pip_package/build_pip_package: line 45: tensorflow/tools/python_bin_path.sh: No such file or directory

Any idea why the python_bin_path.sh file hasn't been generated?

Did you run ./configure  first?

Sure did. Right now I'm trying updating to bazel 0.1.2 or rebooting.

Hmm, @wicke, this might be related to your change earlier today?

Probably. As a workaround while I look into this, you can edit tensorflow/tools/pip_package/build_pip_package to remove the offending line. Replace
  source tensorflow/tools/python_bin_path.sh
  ${PYTHON_BIN_PATH} setup.py bdist_wheel >/dev/null

with
  python setup.py bdist_wheel >/dev/null

Then rebuild.

worst-case, we could also just do ${PYTHON_BIN_PATH:-python}

Thanks @martinwicke, that did the trick.

It looks like the ./configure script puts python_bin_path.sh into the root tensorflow/tools directory, not tensorflow/tensorflow/tools.
Either util/python/python_config.sh or tensorflow/tools/pip-package/build_pip_package.sh needs to change.

This problem still appears for me for master and bazel 0.1.2
Fri Dec 11 09:27:04 PST 2015 : === Building wheel
bazel-bin/tensorflow/tools/pip_package/build_pip_package: line 45: tools/python_bin_path.sh: No such file or directory

The abovementioned commits are in.

Confirmed. This issue still exists.

Does the change in 7c5c20b2b73c40bb4fd113f26bcda73a5e5bec6d help?

It does. The script was in the wrong directing when trying to source python_bin_path.sh

Also fixed it for me @vrv

Works indeed. Thanks.


Framework7-vue: dynamicNavbar does not respect scoped style and all other attributes defined in page

Framework7 version: 3.5.2
Vue.js version: All
Platform and Target: ios (or android with dynamic navbar enabled)
Live Link or JSFiddle: https://jsfiddle.net/mmis1000/a1mckpyd/1/ (the navbar text color is not applied, toggle theme to android to see the different)

Describe the bug
The dynamic navbar move only inner content of navbar to the top location, but it forgot that the navbar itself can be a target for coloring and apply other attributes.
To Reproduce
Steps to reproduce the behavior:

enable dynamic navnbr in param
make a navbar in page
apply any attribute you like on it

Expected behavior
The attribte applied correctly/ color...etc is displayed as expect
Actual Behavior
It does not work
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
This bug also breaks scoped style of vue, because the scope id attribute is gone due to this situation.

But as you noticed it is detached from component so it will never work will scoped styles, it is just impossible. I would recommend to use inner-class attribute where you can set class on its inner element and style it like here https://jsfiddle.net/aho7cqkg/

And I guess It may work with scoped style if we copy all attribute from original one to the outer wrapper (or even replace the wrapper all together

The bottom border is on the navbar wrapper instead of navbar inner, use scope css to only change theme in certain page is simply impossible.
I can just update them in page:* hooks with DOM7, but I think it isn't really eligible to do so

Yes, can be done with DOM (check About page) https://jsfiddle.net/4ysxoter/

And I guess It may work with scoped style if we copy all attribute from original one to the outer wrapper

This what could probably be done in v4, some classes could be copied

even replace the wrapper all together

this is impossible as it will break dynamic navbar

I believe this is important


feat(ci): publish OpenAPI specs on releases

What this PR changes/adds
This PR lets the release-edc workflow call the apidoc workflow, which publishes the OpenAPI specs to Swaggerhub.
If the apidoc workflow is invoked passing in a non-snapshot version, the API is set to "published" on SwaggerHub, which means it cannot be altered afterwards.
Why it does that
We should publish immutable OpenAPI documents of our release versions.
Further notes
List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.
Linked Issue(s)
Closes #2834
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

\cc @bcronin90 you may be interested as well

Codecov Report
Patch coverage has no change and project coverage change: -61.14 :warning:

Comparison is base (c37de26) 72.41% compared to head (ff815a8) 11.28%.

:exclamation: Current head ff815a8 differs from pull request most recent head a4e8273. Consider uploading reports for the commit a4e8273 to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@              Coverage Diff              @@
##               main    #3296       +/-   ##
=============================================
- Coverage     72.41%   11.28%   -61.14%
- Complexity        0      574      +574
=============================================
  Files           843      843
  Lines         17039    17039
  Branches        949      949
=============================================
- Hits          12339     1922    -10417
- Misses         4306    15063    +10757
+ Partials        394       54      -340

see 585 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Allow the confirmation dialog to be optional & add callback_id param

I've updated to make button confirmations optional. Slack suggests to use confirmations sparingly:
https://api.slack.com/docs/message-buttons#guidelines_and_best_practices
Also, callback_id is a required attachment field:
https://api.slack.com/docs/message-buttons#attachment_fields

@maknz, @benperove - can this please be merged in? I'm wanting to use the Button API, but it needs the callback_id and it is currently missing from this and the PR fixes it for me

Happy to merge if the test suite passes. Unfortuantely I'm low on time so I won't be able to do the necessary work to make a stable release, at least right now.

The code that I added was pretty straightforward, but I was unaware the tests (or lack thereof) were going to cause the build to fail, so my apologies if I've held anyone up because of this. I will try to add the unit tests possibly by this weekend and get everything squared away.

Hi, I know this isn't ready yet, but how do I put a callback_id in my client? Can I just put it in my $slackSettings?
Here is my config.
$slackSettings = [
    'username' => 'foo',
    'link_names' => true
];

$injector->define('Main\Modules\Slack\Slack_Client_Module', [
      ':endpoint' => $arrCfgEnvSettings['slack']['foo']['webhook-url'],
      ':attributes' => $slackSettings,
      ':guzzle' => null
 ]);


Remove logging options --log.api-enabled and --log.keep-logrotate for client tools

Scope & Purpose
Remove logging options --log.api-enabled and --log.keep-logrotate for client tools (arangosh, arangodump, arangorestore etc.), as these options are only meaningful for arangod.

[x] :hankey: Bugfix (requires CHANGELOG entry)
[ ] :pizza: New feature (requires CHANGELOG entry, feature documentation and release notes)
[ ] :fire: Performance improvement
[ ] :hammer: Refactoring/simplification
[x] :book: CHANGELOG entry made

Backports:

[x] No backports required

Testing & Verification

[x] This change is a trivial rework / code cleanup without any test coverage.
[x] The behavior in this PR was manually tested

Link to Jenkins PR run:
http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13831/

Tests blue


Remove fields in plain 'new upload' that look as they are required, but are not

Is your feature request related to a problem? Please describe.
When creating a new record there are fields marked as 'required' but a record can be published without filling these fields.
The 'not' needed fields are 'Date', 'Alternate identifier(s)', 'Related works'

Describe the solution you'd like
Remove these fields as you can do manually:

Additional context

There are two kinds of 'required' fields.

If the star is on the heading it is necessary to create a record

If the star is on a field within a heading it is only needed if you fill out the fields on the same line

Note: the star is not on the heading, but only on two fields that either both are empty or both filled. I haven't seen the difference until @fenekku pointed it out to me.

The removal would might also affect this issue: https://github.com/inveniosoftware/invenio-app-rdm/issues/1407

Case A: "Also, it will complain again about the seemingly required list fields (dates, alternate identifiers, related works)."

I think we had user feedback in the other direction, that it was confusing that the subfields were not marked as required (perhaps @fenekku remembers more). Depending on previous user feedback, I would simply remove the red star from the subfields. The subfields are still displayed to make it immediately clear what you can add (i.e. user doesn't have to first click a button to figure out what is meant with a "related work").

My understanding of that original feedback was indeed that it was confusing for subfields that were required (if line filled) to not be marked as such. Then people (at our institution and at Christina's it seems) were confused by the field hierarchy of what is required (i.e. the problem outlined here).
I think the proposed solution is a good middle-ground that captures both feedback: red stars are only immediately visible for things that are required, and subfield red stars only appear for fields the user is explicitly trying to fill after clicking on the corresponding button. Will that make it less obvious what overall can be deposited if we don't show the first empty field for those cases? Don't know. Would hope not.
Spitballing other possibilities:

have two annotations: * and † to denote always required and conditionally required
contrast the layers of the hierarchy a little more visually and have e.g. Title (required) for always-required and * only for conditionally-required.

That middle-ground still has my vote apriori.

Thanks for the extra info. Ok, sounds like this requires mockup of different possibilities and present to users and collect feedback.


Hang after sending multiple lines to REPL in one block

Start VS
Create new project
Insert the following code in the editor
url <- "https://cran.revolutionanalytics.com/web/packages/packages.rds"
tf <- file.path(tempdir(), "packages.rds")
download.file(url, destfile = tf, mode = "wb")
extra <- readRDS(tf)

Line by line, send to REPL with CTRL-ENTER
Result: everything works as expected
Reset the REPL (IMPORTANT!)
CTRL-A then CTRL-ENTER to send all the lines at once
Result: REPL hangs

Should have a look in 0.3

Turns out you need to have package manager window open, if it has never been opened in this VS instance, then it won't repro.

So likely related to that other hang issue with package manager that you've had?

The one with breakpoints?  Not sure, could be.

Can repro. The hang does not preclude resetting the REPL again, but after reset, any further input will bring it to the same state again, requiring a VS restart.

https://github.com/Microsoft/R-Host/pull/60


feat(config): Make ingestion flush duration configurable

Adds a configuration param to control the duration of time to wait before sending captured logs to the ingestion API. Changes the default value from 250 ms to 5000 ms.
Ref: LOG-19388

The check failures seem to be from some odd timing on the journald tests
[2024-03-29T14:42:44.257Z]         FAIL [   0.738s] journald journalctl::test::stream_gets_new_logs
[2024-03-29T14:42:44.257Z]         FAIL [   0.774s] journald libjournald::stream::tests::stream_gets_new_logs


Small typo

Hi, I think there's a small typo on line 178 of flags.hpp:
flags &operator^=(enum_type e) noexcept {
        val_ &= static_cast<underlying_type>(e); // should be '^=' not '&='
        return *this;
    }

Indeed, thank you. I'm planning to work on this project on next weekend.

Fi91f369d7b094b48caa2318b3506210aca543742f

Fixed via 91f369d7b094b48caa2318b3506210aca543742f.


Slack overflow property not working

Steps to Reproduce

install flutter master 0.8.2-pre.21 ( beta channel 0.8.3 currently has version resolving issue)
git clone flutter gallery app
check out the material card page, the border-radius is overflowed by the image inside.

It seems the overflow property on Slack is not working properly and ignoring the shape property on Card and decoration on Container.
[✓] Flutter (Channel master, v0.8.2-pre.21, on Mac OS X 10.13.6 17G65, locale en-US)
    • Flutter version 0.8.2-pre.21 at /Users/evilcat/development/flutter
    • Framework revision e8fa45c695 (5 hours ago), 2018-09-08 10:20:57 -0700
    • Engine revision e27a2e955b
    • Dart version 2.1.0-dev.4.0.flutter-cd9a42239f

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.2)
    • Android SDK at /Users/evilcat/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.2
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 9.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.4.1, Build version 9F2000
    • ios-deploy 1.9.2
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 28.0.1
    • Dart plugin version 173.4700
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)

[✓] IntelliJ IDEA Ultimate Edition (version 2018.2.2)
    • IntelliJ at /Users/evilcat/Applications/JetBrains Toolbox/IntelliJ IDEA Ultimate.app
    • Flutter plugin version 28.0.4
    • Dart plugin version 182.4129.13

[✓] VS Code (version 1.27.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.18.0

[✓] Connected devices (3 available)
    • Android SDK built for x86 • emulator-5554                            • android-x86 • Android 8.0.0 (API 26) (emulator)
    • Evilcat’s iPhone          • cbf8eaf490fb7cd342317793ae7bd8516cc7d5bd • ios         • iOS 11.4.1
    • iPhone X                  • 96EA51FC-4D4C-4305-8B15-09C6C454D8C2     • ios         • iOS 11.4 (simulator)

• No issues found!

Current work around is to use
Container(
  decoration: BoxDecoration(
    borderRadius: BorderRadius.only(
      topLeft: Radius.circular(8.0),
      topRight: Radius.circular(8.0),
    ),
    image: DecorationImage(
      image: ExactAssetImage('xxxxx'),
      fit: BoxFit.cover,
    ),
  ),
)

This would require both the radius to set on Container and Card.
I'm not sure which is the expected behavoir.
I am trying to follow the example on flutter_gallery, the current app in Google Play is showing that the Image in Stack even without the overflow: Overflow.clip is respecting the shape on Card and clip.

This also happens for containers or any child of the Card for that matter. The child is overflowing the border radius of the card.

@wilburt that is probably #21094


Added how to build source code with devtool(Yocto)

This commit is to explain how to build the source code with devtool in case that
user have to do a self assessment before submitting a source code of Yocto package.
Signed-off-by: Geunsik Lim<EMAIL_ADDRESS>
[Template] PR Description
In general, github system automatically copies your commit message for your convenience.
Please remove unused part of the template after writing your own PR description with this template.
$ git commit -s filename1 filename2 ... [enter]

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical;
various tools like `log`, `shortlog` and `rebase` can get confused
if you run the two together.

Further paragraphs come after blank lines.

**Changes proposed in this PR:**
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
  by a single space, with blank lines in between, but conventions vary here.

Resolves: #123
See also: #456, #789

**Self evaluation:**
1. Build test: [ ]Passed [ ]Failed [*]Skipped
2. Run test: [ ]Passed [ ]Failed [* ]Skipped

**How to evaluate:**
1. Describe how to evaluate in order to be reproduced by reviewer(s).

Add signed-off message automatically by running **$git commit -s ...** command.

$ git push origin <your_branch_name>

:memo: Version: 1.20180820. Thank you for submitting PR #194. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://invain.mooo.com/.

We generate a report if there are dangerous coding constructs in your code. Please read http://invain.mooo.com/TAOS-CI/ci/repo-workers/pr-format/201808301518080.11541891098022-194-48a8cd01027b69c33795d7a05d36639238605db5/report/.


Can be possible to change dd-agent port?

I can try use 80 or 443 for send metrics from another heroku app.

The buildpack is meant to be run inside a dyno, alongside the application.
Can you describe why you'd want to run this alone? We had not designed this to be a aggregator from multiple external sources - one reason is that if we open the listener to port 80/433, anyone could submit metrics to your endpoint and account.

I can replace Hosted Graphite with Datadog and integration with Heroku is hard. Hosted graphite have possibility send statsd directly to service but Datadog not.

I'm going to close out this issue, as the intent of this buildpack is to enable a locally running statsd agent that forwards packets along from the locally running application, not as a relay-only process - this has other implications around application security, app name traceability and others that I cannot think of right now.
This buildback was designed to be simple to start using - add to your current app's buildpacks and then redeploy. If that's not working out, please let me know.


Automated cherry pick of #2451: Update OVS version from 2.14.0 to 2.14.2

Cherry pick of #2451 on release-1.2.
#2451: Update OVS version from 2.14.0 to 2.14.2
For details on the cherry pick process, see the cherry pick requests page.

Codecov Report

Merging #2459 (872641e) into release-1.2 (ea0f640) will decrease coverage by 4.48%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           release-1.2    #2459      +/-   ##
===============================================
- Coverage        59.81%   55.32%   -4.49%
===============================================
  Files              284      284
  Lines            22171    22171
===============================================
- Hits             13262    12267     -995
- Misses            7488     8585    +1097
+ Partials          1421     1319     -102

Flag
Coverage Δ

kind-e2e-tests
38.78% <ø> (-8.22%)
:arrow_down:

unit-tests
42.03% <ø> (+0.01%)
:arrow_up:

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