document how to add redux (or an example)

Redux is an essential part of my react development. I like create-react-app, but now I need to find a way to add in redux. Do I "eject" and then add redux or ...? At that point it is more helpful [for me] to use another boiler plate project project. Put another way, create-react-app lowers the barrier to starting a react project, but it does not lower the barrier to starting a react-redux project.

CRA only handles the build process. Redux, or any React components, are regular dependencies. To install them, you run npm install. They have no relation to build process so you use them the same way you used them before.

Also, to clarify, this project is not meant to provide the "boilerplate" code for your app. We think that it is important that you write app code yourself, and understand the libraries you are using, and their APIs.
This project exists to make build process easy. This means you don't have to think about configuring Babel, Webpack or ESLint. Everything needed so you can write JSX and ES6 and have a good development experience.
However it doesn't make choices about which runtime libraries you use, or how you structure your app. So it's not an opinionated "starter kit".
Such starter kits could be built on top of Create React App. In fact all examples in Redux repo use it, so you might want to check them out.

I did not know you had ported the redux examples to CRA, that is very helpful - thanks. I'm finding it hard to grasp the conceptual model of CRA. Not boilerplate, not starter kit, abstracts away webpack and babel complexity, yet build system doesn't seem right either. Having it generate code, while good, is also a bit misleading if it is a build process. Not complaining, just thinking.

Well, tools like this weren't very popular before so I don't think we ever came up with a name. It does a few things:

Creates an empty project for you with a single component. In this case it's sensible to generate some code so people don't have blank page syndrome. Especially important for beginners. Fiddling with a component that already works is easier than trying to create your first component from scratch. We don't include something like Redux because it is pretty opinionated, and you can build React apps without it just fine.

Hides development dependencies behind a single development dependency. I would call this a "tool facade" if this makes sense. It tries to unite several tools into a cohesive experience without burdening you with configuration.

Running "eject" moves all build dependencies and configuration into your project so it becomes more like a build boilerplate, but you can do it at any time, even when you already have an app written.

So yeah, it doesn't cleanly fit those roles, but that's precisely because we think those roles are problematic and didn't work well, and we wanted to try something different.

names:
 - react virtual build environment

 - react integrated tool set

 - react federated build tools.

create-react-app --add_redux --add_whatever --no_app (only generates
index.js) --add api_server
Just speculations, not even suggestions.
:-)
Terry
On 9/12/16 5:55 AM, Dan Abramov wrote:

Well, tools like this weren't very popular before so I don't think we
ever came up with a name. It does a few things:

Creates an empty project for you with a single component. In this
case it's sensible to generate /some/ code so people don't have
blank page syndrome. Especially important for beginners. Fiddling
with a component that already works is easier than trying to
create your first component from scratch. We don't include
something like Redux because it is pretty opinionated, and you can
build React apps without it just fine.
Hides development dependencies behind a single development
dependency. I would call this a "tool facade" if this makes sense.
It tries to unite several tools into a cohesive experience without
burdening you with configuration.
Running "eject" moves all build dependencies and configuration
into your project so it becomes more like a build boilerplate, but
you can do it at any time, even when you already have an app written.

So yeah, it doesn't cleanly fit those roles, but that's precisely
because we think those roles are problematic and didn't work well, and
we wanted to try something different.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/facebookincubator/create-react-app/issues/630#issuecomment-246301376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5Im28mVe6UQQpxhZW3KOkA2u863Iiks5qpSGFgaJpZM4J6ESN.

For now, I feel this is out of scope so closing.
People who just start learning React generally don’t need Redux, and those who do should already be comfortable with installing libraries from npm by that point.


Add uninstall_preflight to Virtualbox 5.2.8,121009

Virtualbox cask installation and uninstallation will fail if the
application or any virtual machines are running. This commit adds an
uninstall_preflight stanza to the cask that saves the state of all
running VMs for all users, then cleanly closes the application with a
ten second timeout, after which it will kill -9 any still-running
VirtualBox binaries.

After making all changes to the cask:

[X] brew cask audit --download {{cask_file}} is error-free.
[X] brew cask style --fix {{cask_file}} reports no offenses.
[X] The commit message includes the cask’s name and version.

This is a fixed version of #44930

Thank you for the submission, but this is really atypical, complex, and flimsy. I can already see predict the bug reports; relying so much on system tools for such a simple thing is unlikely to end well.
I’d rather use an uninstall :quit, if that saves the state. If not and the installation fails when there are open VMs, so be it. I don’t think it’s hard to figure out why it failed and proceed accordingly.
This case also imposes our will on the user by force quitting — in the same situation, I’d rather the installation fails and it lets me do things my way. It’s more likely that I don’t want to risk an upgrade at this point and finish my work. We should err on the side of doing less.
Still, the contribution is appreciated!


New Functionalities Added✨✨✨

  The allemp contract includes a mapping named employees that maps an owner's address to an Employee struct. This mapping allows efficient retrieval of employee details using their owner addresses.

The Employee struct consists of various attributes such as firstName, lastName, walletAddress, country, image, and position.
Event: SalCreated
  The SalCreated event is emitted when a new employee is added and a corresponding Sal contract is deployed.

It includes information such as the employee's first and last name, the contract owner's address, the address of the deployed Sal contract, the image associated with the employee, the timestamp, and the employee's position.
Function: addEmp
    The addEmp function is used to add a new employee.

It creates a new Employee struct with the provided details and maps it to the owner's address in the employees mapping.
It then deploys a new Sal contract, passing the employee details and the owner's address.
Finally, it emits the SalCreated event with relevant details.
Contract: Sal
   The Sal contract represents an employee's salary contract.

It includes attributes such as firstName, lastName, walletAddress, position, country, and image to store the employee's information.
The receivedAmount variable tracks the total amount received as donations.
The owner variable represents the contract owner's address.
The Donated event is emitted when a donation is made, capturing the donor's address, the donated amount, and the timestamp.
Modifier: onlyOwner
       The onlyOwner modifier is applied to functions in the Sal contract to ensure that only the contract owner can call those functions.

It uses the require statement to validate that the sender of the transaction is the owner, and if not, it reverts the transaction with an error message.
Function: donate
      The donate function allows anyone to make a donation to the contract.

It requires the donated amount to be greater than zero.
It transfers the donated amount to the contract owner's address.
It increments the receivedAmount variable to track the total received donations.
It emits the Donated event with the donor's address, the donated amount, and the timestamp.
Function: updateDetails
 The updateDetails function allows the contract owner to update their personal details, such as firstName, lastName, walletAddress, position, country, and image.
  It can only be called by the contract owner due to the onlyOwner modifier.
 These functionalities enable the creation of employees, deployment of corresponding Sal contracts, donation handling, and updating employee details.

@roshangeorge97    Have a look this PR

@Vikash-8090-Yadav @sarthkdobriyal @roshangeorge97 Review this PR

@Vikash-8090-Yadav it's related to smart contract!

@roshangeorge97 Yep!!!

Hey, bro @ikavinkumar  currently am not tsking any issues with the smart contract! Thanks .

Have you review the PR check this out @Vikash-8090-Yadav

Have you review the PR check this out @Vikash-8090-Yadav

Yah i checked and  I will test it by tmrw eod. Thanks for patience.

@Vikash-8090-Yadav can you label PR as level 1


verilator.mk: Add support for PGO

This commit add PGO_CFLAGS and PGO_LDFLAGS when calling verilator to generate Makefile. And add script to build PGO for both GCC and LLVM.
The following is the usage of PGO:
make emu MFC=1 EMU_THREADS=16 NUM_CORES=1 PGO_WORKLOAD=`realpath ready-to-run/coremark-2-iteration.bin` LLVM_PROFDATA=llvm-profdata -j `nproc`

Note: The LLVM_PROFDATA is hard to detect if multiple versions of LLVM are installed. An example is that on Debian, we can install different versions of LLVM and use a version with suffixes like clang++-18. The LLVM_PROFDATA should be set to the correct version like llvm-profdata-18 in this case.
If the compiler of verilator is GCC, we should not use LLVM_PROFDATA:
make emu MFC=1 EMU_THREADS=16 NUM_CORES=1 PGO_WORKLOAD=`realpath ready-to-run/coremark-2-iteration.bin` -j `nproc`

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -205,7 +205,7 @@ idea:

 # verilator simulation
 emu: sim-verilog
-       $(MAKE) -C ./difftest emu SIM_TOP=SimTop DESIGN_DIR=$(NOOP_HOME) NUM_CORES=$(NUM_CORES)
+       $(MAKE) -C ./difftest emu SIM_TOP=SimTop DESIGN_DIR=$(NOOP_HOME) NUM_CORES=$(NUM_CORES) PGO_WORKLOAD=`realpath $(PGO_WORKLOAD) 2>/dev/null`

 # vcs simulation
 simv: sim-verilog

Is it better to move this realpath to separate lines in Makefile?
ifneq ($(PGO_WORKLOAD),)
// update PGO_WORLOAD here with realpath
endif

Do we really need to pass the PGO_WORKLOAD explicitly? I'm assuming all variables are perserved by $(MAKE)

Do you have some simulation performance stats you can share?
And how much time does max-cycle 2M take on an ordinary EPYC 2nd or 3rd gen machine?

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -205,7 +205,7 @@ idea:

 # verilator simulation
 emu: sim-verilog
-       $(MAKE) -C ./difftest emu SIM_TOP=SimTop DESIGN_DIR=$(NOOP_HOME) NUM_CORES=$(NUM_CORES)
+       $(MAKE) -C ./difftest emu SIM_TOP=SimTop DESIGN_DIR=$(NOOP_HOME) NUM_CORES=$(NUM_CORES) PGO_WORKLOAD=`realpath $(PGO_WORKLOAD) 2>/dev/null`

 # vcs simulation
 simv: sim-verilog

Is it better to move this realpath to separate lines in Makefile?
ifneq ($(PGO_WORKLOAD),)
// update PGO_WORLOAD here with realpath
endif

Do we really need to pass the PGO_WORKLOAD explicitly? I'm assuming all variables are perserved by $(MAKE)

It's just for adding the real path and passed to another Makefile.

Do you have some simulation performance stats you can share? And how much time does max-cycle 2M take on an ordinary EPYC 2nd or 3rd gen machine?

I haven't tested it on the AMD EPYC Server. On my 13900k machine with 16 threads, with coremark trained PGO and coremark emu benchmark, it gets about 2x faster, which finished the 2 iter coremark in 46s, original emu takes about 120s. This result is about 1x faster than non-PGO emu on 7950X3D, which takes 76s to finish 2 iter coremark. However, I think we may need a better workload as a training workload that uses MMU and RVV.

The PGO commands look good to me except for some minor changes.
I'm suggesting adding a CI test for verify the PGO process. NutShell builds quickly. I'm assuming $(MAKE) will have all variables including PGO_WORKLOAD. That to say, if you make emu PGO_WORKLOAD=../ready-to-run/microbench.bin would work perfectly (given the relative path starting at difftest is correctly pointing to a file).

There are two unresolved comments

It's better to add a CI test.

Better to use build/emu-compile-pgo or build/emu-compile/pgo instead of build/pgo which confuses the user.

Maybe I should add a CI based on NutShell. But I'm not sure I have time to do that recently. I'm figuring out the problem caused by a recent update on the XiangShan master branch, which can not finish C compile with -fprofile-generate and O3 or -Os on llvm-18 in 30 minutes, which makes PGO unusable. But with -O0, there is a lot of performance degradation.

Maybe I should add a CI based on NutShell. But I'm not sure I have time to do that recently. I'm figuring out the problem caused by a recent update on the XiangShan master branch, which can not finish C compile with -fprofile-generate and (O3 or -Os) on llvm-18 in 30 minutes, which makes PGO unusable. But with -O0, there is a lot of performance degradation.

We can leave this PR unmerged until these issues fixed.

It's a very good work. Thanks for the contribution. There are two unresolved comments

It's better to add a CI test.

CI added now.

Better to use build/emu-compile-pgo or build/emu-compile/pgo instead of build/pgo which confuses the user.

I use build/emu-compile/pgo now.

And please don't merge in squash mode; I have some important messages in each commit message.

Maybe I should add a CI based on NutShell. But I'm not sure I have time to do that recently. I'm figuring out the problem caused by a recent update on the XiangShan master branch, which can not finish C compile with -fprofile-generate and (O3 or -Os) on llvm-18 in 30 minutes, which makes PGO unusable. But with -O0, there is a lot of performance degradation.

We can leave this PR unmerged until these issues fixed.

I think we can merge it first and then add a parameter in Makefile to switch the optimization level for difftest without rerunning the verilator. Now clang-18 is broken on the verilator-generated XiangShan RTL. So I can’t provide a fair comparison with different optimization levels. But one thing I can tell is the instruction count on 8 threads coremark is nearly the same on GCC-14 -O3 and LLVM-18 -O3. But if we switched to -O1 on GCC-14, the instruction count on GCC-14 would be 3x compared to -O3. So providing a switch might be a good choice if we ran into a compile-time issue or emu performance issue.


Update group by limit docs

🚀 Deployed on https://675a33ec955faa7131003f28--cozy-fox-0defec.netlify.app


Request to registry not specifying registry port correctly

Hello,
I am following default configurations for everything afaik, but the front end is not specifying the correct port when trying to acces the registry.
Expected behavior
I open the repositories list and it sends a request to  https://localhost:5000/v2/_catalog?n=20&last=
Actual behavior
It sends a request to https://localhost/v2/_catalog?n=20&last=
Steps to reproduce the problem
docker run
-d
-e ENV_DOCKER_REGISTRY_HOST=<IP_ADDRESS>
-e ENV_DOCKER_REGISTRY_PORT=5000
-e ENV_USE_SSL=yes
-v /certs/registry.crt:/etc/apache2/server.crt:ro
-v /certs/registry.key:/etc/apache2/server.key:ro
-p 443:443
konradkleine/docker-registry-frontend:v2
This is a problem for me with and without SSL. If I run the front end specifying I want it on port 8000 it will send a web request to port 8000 expecting the registry service to be there.
I must be configuring something incorrectly!
Thanks
Russ

Take a look at issue #170 or #181, #170 did the trick for me


Add player.SetHealth

player.Hurt exists.

player.Hurt exists.

well I don't think that's what he wants. he wants to either add or remove health from the player depending on the health the player currently has and the health he wants the player to have

You can do that with the Hurt and Heal methods.

in some case, there need to set player's health directly, but if use Heal or Hurt, you have to caculate health delta and it isn't convenient at all.

The thing is that healing and hurting are simply different things. A SetHealth method breaks that difference and exposes health changing in an 'incomplete' way (can't listen for events) which is not very desirable.

I agree with you Sander, but you can maybe just have such method, then get the current player health and if the health argument is lower than the current player health Hurt them etc.. More of a utility method, so to say.

I agree with you Sander, but you can maybe just have such method, then get the current player health and if the health argument is lower than the current player health Hurt them etc.. More of a utility method, so to say.

I agree with you Sander, but you can maybe just have such method, then get the current player health and if the health argument is lower than the current player health Hurt them etc.. More of a utility method, so to say.

I support this as a balanced approach of SetHealth

There are some complexities with this that we discussed in the Discord server, which we need to figure out.

If there are no other comments on this I will close this and its associated PR.


Love heart inline in Songs view is off centered

The hearts in the song view are not centered.

pls move to iTheme


Simplify build tooling

Switch from home-made esbuild pipeline to vite to simplify config and ensure best-practices for minification etc are being used. Esbuild is still used for the extension backend but just simple node-scripts copied from the vscode extension docs.

/update-snapshots


fix: ensure field directive is mapped to schema on relationship fields

Fixes #1772
This fixes an issue where directives on relationship fields in the model were not added to the generated schema. because Graphback modifies the relationship fields to add extra metadata/filter arguments etc.
Graphback was removing the old field and adding a new one with the same config + some modifications but we were losing the astNode from the field. I found that the better thing to do was to use extendField from GraphQL Compose.
Verification
I have added a test case in this PR. If you want to try it yourself, using the following model:
directive @test on FIELD_DEFINITION
  """ @model """
type Note {
  id: ID!
  title: String!
  description: String
  """
  @oneToMany(field: 'note')
  """
  comments: [Comment]! @test
  """@oneToOne"""
  comment: Comment @test
}
""" @model """
type Comment {
  id: ID!
  text: String
  description: String
  note: Note! @test
}

Could the fix be applied for this issue https://github.com/aerogear/graphback/issues/1767 or it is entirely has to do with grapql-compose?

Could the fix be applied for this issue #1767 too or it is entirely has to do with grapql-compose?

This does not fix that issue unfortunately. I think that is entirely GraphQL Compose but I will do some investigating separate from this PR.

Ouch.. I merged wrong PR! Sorry @craicoverflow

Could the fix be applied for this issue #1767 too or it is entirely has to do with grapql-compose?

This does not fix that issue unfortunately. I think that is entirely GraphQL Compose but I will do some investigating separate from this PR.

Okay I see. It was more a question for my own understanding. Thanks for answering.


Do not overwrite previously imported files

Is this still relevant? What do we mean by that? Accidentally overwriting of files during the import process?
What should be the expected behaviour if there is a name collision? Adding a suffix? Just reporting the collisions?

If the user imports a file with the same filename, the import will overwrite the older one that was there.
Not a big deal, though.

So what is the expected then?

I think the best course of action is to show a dialog asking if they want to overwrite the file

Ok, so if the user does not provide a name don't we skip it, right?

Yep! if they don't want to overwrite, just don't import the file


x/website:

What version of Go are you using (go version)?
The LATEST
Does this issue reproduce with the latest release?
Yes.  You made it the header of your website.
What operating system and processor architecture are you using (go env)?
N/A
What did you do?
What did you expect to see?
I visited https://golang.org expecting to find a Programming Language REFERENCE...
What did you see instead?
I see a website header dealing with the political FEELINGS of a minority group within your organization.
"Black Lives Matter. Support the Equal Justice Initiative."
I expected to see a PROFESSIONAL Programming Language REFERENCE.
Not a POLITICAL PROPAGANDA statement that applies to the USA specifically and certainly NOT to a LARGE PORTION of the world.
Just because your company has a website, DOES NOT mean it should be used for POLITICAL PROPAGANDA.

Duplicate of ##39850


Netlist formatting

Feature Description
Hi ,
Lame question :
write_verilog writes the nets/pins in different lines - is it possible to print in one line ? ( i have a parsing script )
sky130_fd_sc_hd__or2_0 _05_ (
  .A(In2),
  .B(In1),
  .X(_01_)
);
sky130_fd_sc_hd__or2_0 _06_ (
  .A(Cin),
  .B(_01_),
  .X(_02_)
);
sky130_fd_sc_hd__and2_0 _07_ (
  .A(In2),
  .B(In1),
  .X(_03_)
);

What are you trying to do? It would be cleaner to make your parsing script actually parse based on a loose understanding of Verilog syntax, or just dump the design as a JSON and use the JSON libraries that come packaged with virtually every single programming language.

It would be more ideal to dump the design as JSON, using either write_json or write_jny depending on your needs. In the case of JNY, it has a full schema for the format as well, so that would possibly help in writing the parser.


Added python Bogo Sort

I am curious to hear your thoughts on python 2 vs python 3, as discussed in #141

The code is fine, let's wait a bit on the discussion outcome, it will need some adjustments if we go with Python 3.

I noticed that there's not even a code import in bubble_sort.md for Python. The Python implementation never showed up in the actual book. Noone noticed.

There. Think I've fixed it all properly now. The mess I made with bubble-sort ended up in #145 where I both fix that the python implementation didn't show up as well as the indentation.

Alright. Everything is looking pretty good now as far as my change requests go.
I'd still say we wait until #141 is resolved until we merge this PR (and all the other Python PRs for that matter). That should happen during the next day or two.


Possible fix for invalid token file

From the debug information from @drf5n in Anaconda-Server/docs.anaconda.org#145
[DEBUG] Found login token: /Users/drf/Library/Application Support/binstar/https%3A%2F%2Fapi.anaconda.org.token
[DEBUG] (u'This domain requires token authentication', 401)

The only way I could reproduce this error was to create an empty token file. For any other token value you should get [DEBUG] (u'Invalid Token', 401)
This PR introduces a check that the token file is not empty and removes the file after that.

The token file is not empty:
(root)$ cat /Users/drf/Library/Application\ Support/binstar/https%3A%2F%2Fapi.anaconda.org.token
dr-992e266e-92c6-4812-b981-d998bea87120(root)$

Could the space in the file path be confusing something?

@PeterDSteinberg can you review?

:+1: LGTM

As I noted here and on #247, my particular token file is not empty.  From my testing, the token variable contains the contents of the file and I get the error.  This branch/fix does not look harmful, and would solve the problem of an empty token file, but this is not the cause of my #247 issue.

Thanks @drf5n, that is what we understood as well. We are still working on a fix for the underlying issue.


Need ability to add keys later with improved error message

If I skip adding a key (purposely or inadvertently) I don't have an option to add it later on when generating results. I get a non-specific error message that the survey is not being answered.

I think we have a partial fix here with running the "has_api_key_check" at running


Support for Accounts.sendEnrollmentEmail

[WAS:  https://github.com/Differential/accounts-entry/pull/215]
This PR simply adds the required routes and dialogs to leverage Meteor's built-in enrollment features (http://docs.meteor.com/#/full/accounts_sendenrollmentemail)

Hi, can you resubmit against the current master branch, we have made some changes in the failing tests

Awesome! I just merged the newest master into my branch, hopefully we can get this puppy out! Thanks much.

Ok merging, could you update the readme with the few settings added by this feature?


Fix uniqueness of macroable objects on grammars

In my pr #24513 i added the macroable trait to the grammars outermost parent class.
But what i didn't realize is that if one where to try to register the same macro name into two different grammars only the last call to the macro method will be used sense the macro property is static and lives in the outmost parent.
So every call to macro would override another one.

Isn't this a breaking change for people who are using Grammar::macro()?

Yes, that is correct.

But i'm not how would you deal with class identities in enheritance?

See above.

@morloderex This seems to be a reasonable feature, is there any interest to pick this up again?


Set connection timeout for mail transports

Hi,
By sending this PR I want to set connection timeout for drivers that use GuzzleHttp to send request
GuzzleHttp Use 0 to wait indefinitely (the default behavior) for connection timeout and that's really bad for background jobs like queue
it could cause infinite loops.
Regards,

maybe make it a config option?

Maybe make it a config option?

i see it now, in TransportManager they made pussible set guzzle config for driver's that work with guzzle,
'sparkpost' => [
    'secret' => 'c0100484e20bfa12e20632b1d9b4761a51c482c2',
    'guzzle' => [
        'connect_timeout' =>60,
    ],
]

i added the getHttpClient to create http client
and set config's and set default config for connect_timeout
in TransportManager
1be806a

Thanks!


Not working

Once running the python script and loading into the CLI program, the program stalls after entering CC number. Ubuntu most recent OS.

what error it is showing and paste the screenshot too

There is no error. Once I put in a CC number to scan, the program simply stalls out and never runs. I have had limited success. Sometimes it doesnt stall, most of the time it does.

send me the credit card  Number which your using and screenshot too

I'd rather give you the CC number. Not sure why that should matter? Its a standard 12 digit

Contacts me here https://t.me/hackerdestination01

Closing due to inactive

I have the same issue ... So can you please fix it ?

Le sam. 21 nov. 2020 à 23:05, darkhacknet<EMAIL_ADDRESS>a
écrit :

I have the same issue ... So can you please fix it ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/itsmehacker/CardPwn/issues/2#issuecomment-731643562,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO5PMZBV464FXROPS42OC73SRA2TLANCNFSM4HVE3RHA
.

No I’m sorry brother

I have the same issue ... So can you please fix it ?

Please Share Screenshot

Le sam. 21 nov. 2020 à 23:12, Hacker Destination<EMAIL_ADDRESS>a écrit :

I have the same issue ... So can you please fix it ?
Please Share Screenshot
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/itsmehacker/CardPwn/issues/2#issuecomment-731644342,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO5PMZDGEN52C2R7KF4XULTSRA3N5ANCNFSM4HVE3RHA
.


CLI: Warnings are very repetitive

To reproduce:
curl https://opentender.eu/data/files/AT_ocds_data.json.tar.gz
tar xvf AT_ocds_data.json.tar.gz
cat AT_ocds_data.json ocdskit combine-release-packages > release_package.json
spoonbill release_package.json

Output:
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
warning: Detected additional column: /awards/relatedLots in parties table
...

Desired behavior (just warn once):
warning: Detected additional column: /awards/relatedLots in parties table

If there is a use case, we can add a CLI option to change the behavior to warn each time. This is similar to Python's options for warnings filters: https://docs.python.org/3/library/warnings.html#the-warnings-filter
Also, when there is a new warning, it causes the "Processed" progress bar to be repeated.

By the way, do we need these warnings? What happens to the additional column? Is it omitted?

We reduced logging level for this messages to DEBUG, so it should be easier on eyes now. But still could be enabled with --verbosity DEBUG option.


Compiling via Docker fails when using Ubuntu 16.04 container

The current docker/compile/Dockerfile.ubuntu16.04 results in a container that fails to compile Heron as libtool cannot be found. It seems the issue is the wrong package name for libtool in the apt-get install command. It should be libtool-bin not libtool.
I have tested this and with this change it compiles successfully.

@tomncooper  - please send a PR for this fix.


[STORM-2815] UI HTTP server should return 403 if the user is unauthorized (1.x)

Portback of https://github.com/apache/storm/pull/2421

@HeartSaVioR  This is for https://github.com/apache/storm/pull/2421/files for 1.x-branch. Could you review it? Thanks


Add a .bytes() method to HTTP responses

The new .bytes() method returns the body as bytes rather than a string. It is modeled after the .json() method, which parses the body as JSON.
The use case is parsing HTTP requests that return binary data. Certain operations on strings in Starlark don't work correctly with binary (i.e., non-UTF-8 encoded) data. In particular, when strings contain non-UTF-8 binary data, the ord function returns 65533 (the codepoint for the Unicode replacement character) when called on a byte with a value between 0x80 and 0xff. ord functions as expected with bytes values.

Here's the motivation for this in code (an app that parses the binary protobuf data in NYC subway feed directly): https://github.com/benesch/tidbyt-nyc-subway-zoom/pull/1/files


WidgetController.pump use optional duration

Description
WidgetController has two implementation: LiveWidgetController and WidgetTester.
Dart allows subclasses override method with different argument argument tables, as long as the subclass's version can align with the superclass's after using default arguments. For this PR, the pump method in WidgetController is defined with a required argument:
https://github.com/flutter/flutter/blob/b8df8a836823190aebdd1950205ca5cba6f4562a/packages/flutter_test/lib/src/controller.dart#L435
LiveWidgetController.pump implements like:
https://github.com/flutter/flutter/blob/b8df8a836823190aebdd1950205ca5cba6f4562a/packages/flutter_test/lib/src/controller.dart#L712-L718
which looks like designed for an optional (default null) argument.
And for WidgetTester it is optional:
https://github.com/flutter/flutter/blob/b8df8a836823190aebdd1950205ca5cba6f4562a/packages/flutter_test/lib/src/widget_tester.dart#L561-L567
If we respect the design of the if statement for LiveWidgetController.pump, the argument should be optional, which is semantically the same as WidgetTester.pump(). And since LiveWidgetController and WidgetTester are only implementations of WidgetController, I would naturally expect WidgetController to also make the argument optional.
Another justification is that there are a lot of test cases where we write await tester.pump();. Most of the time those codes should be able to be re-used by simply change WidgetTester to WidgetControllor so that they can be more widely used (see #61511).
Related Issues
#61511
Tests
Refactoring. I don't think I need one.
Checklist
Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.

I'm not sure I understand the design logic. The docs for pump may also need to update, and the original version:
https://github.com/flutter/flutter/blob/b8df8a836823190aebdd1950205ca5cba6f4562a/packages/flutter_test/lib/src/controller.dart#L426-L435
is already not a good doc for LiveWidgetController which not only advance time but also schedule a frame.

The change in this PR is fine, but needs tests.

Test added.


[Event Request] codeunit 90 "Purch.-Post" - OnInsertPostedPaymentBeforeInsertPaymentJournalLine

In codeunit 90 "Purch.-Post" (italian localization) please add the following event:
    local procedure CheckAndUpdate(var PurchHeader: Record "Purchase Header")
    var
        ModifyHeader: Boolean;
        RefreshTempLinesNeeded: Boolean;
        ReverseChargeVAT: Boolean;
        IsHandled: Boolean;
    begin
        with PurchHeader do begin
            CheckPurchDocument(PurchHeader, ReverseChargeVAT);

            if GuiAllowed and not HideProgressWindow then
                InitProgressWindow(PurchHeader);

            // Update
            if Invoice then
                CreatePrepmtLines(PurchHeader, true);
...
                            PaymentJournalLine."Due Date Calculation" := PaymentTermsLine."Due Date Calculation";
                            PaymentJournalLine."Discount Date Calculation" := PaymentTermsLine."Discount Date Calculation";
                            PaymentJournalLine."Discount %" := PaymentTermsLine."Discount %";
                            PaymentJournalLine."Due Date" := PaymentTermsLine."Due Date";
                            PaymentJournalLine."Pmt. Discount Date" := PaymentTermsLine."Pmt. Discount Date";
                            // New event
                            OnInsertPostedPaymentBeforeInsertPaymentJournalLine(PurchHeader, PaymentTermsLine, PaymentJournalLine);
                            // New event
                            PaymentJournalLine.Insert();
                        until PaymentTermsLine.Next() = 0
...

    [IntegrationEvent(false, false)]
    local procedure OnInsertPostedPaymentBeforeInsertPaymentJournalLine(PurchHeader: Record "Purchase Header"; PaymentTermsLine: Record "Payment Lines"; var PaymentJournalLine: Record "Payment Lines")
    begin
    end;

Thank you

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Issue/157/io nb

Adding another demo notebook (not sure if examples/core is the correct location for this, thoughts?) with some extra explanation for tables_io, the rail.core.DataStore, and fileIO that will hopefully clarify usage for people just getting started.
@joselotl you mentioned some confusion about fileIO, are we missing anything in this demo that you had questions about?  Can you successfully run this notebook?  Same question for @aimalz and @eacharles, anything we should add/rephrase here?  Should we move to goldenspike directory for better visibility?

I'm going to merge this in, @joselotl or @aimalz if you have further comments on improving the notebook we can open a new issue/PR to fix it up further.

I'm having problems executing the second to last cell:
newens = qp.read("KNNPZ_estimates.hdf5")
The error is
~/local/anaconda3/envs/pz/lib/python3.9/site-packages/qp-0.5.2.dev1+g8f6c2c4-py3.9.egg/qp/factory.py in read(self, filename)
154         data = self._build_data_dict(md_table, data_table)
155
--> 156         pdf_name = data.pop('pdf_name')
157         pdf_version = data.pop('pdf_version')
158         if pdf_name not in self: #pragma: no cover
KeyError: 'pdf_name'
I wonder if it has something to do with the qp version? @sschmidt23

Have you grabbed a fresh copy of qp within the last few days?  Eric just patched a bug in the writing out hdf5 files that causes this error, so if you grab the latest qp this error should go away.

Thank you, it solved my problem


merge Pharo 6.1 dev into master

Need to get the pharo-6.1 work merged into the master branch ... @estebanlm are there additional issues that you are working on? If so perhaps you could outline the issues here? Otherwise let's get the tests passing and merge this puppy into the master branch

@estebanlm, regarding your download failures for pharo 6.x.
Here's the section of the SmalltalkCI download script  where the failure is occurring and according to blame that code has not really changed in two years and it is not causing problems for Pharo5.0 or earlier...
This implies that the pharo6.x zero conf script is the culprit and fails doing the mv.
Sooo either the SmalltalkCI script needs to be changed to rm the file or the zero conf script for pharo6.x needs to be changed...
BTW, GemStone leverages the cache for speedier builds so disabling the cache is not really an option -- it is a feature of travis that is supposed to be supported by SmalltalkCI ...

mmm... but zeroconf has not changed either, AFAIK... unless someone changed it without I know.
(yes, I know cache can not be disabled... not support caching is lame :P)

ah, and to answer original question: no, I'm not working in anything else. I was just cleaning undeclared and making sure tests passed when integrated (there was some tests failing on windows)


Add shortcut getter to first Loop result

store/index.js:
firstLoopItem: state => {
            return _get(state.loop, '[0]', {})
}

Added in 3fd5579 - getter is called post


Error during helm install

Trying to install kuberhealthy using helm. Cluster is running k8s 1.14
Getting the following error,
helm install stable/kuberhealthy

Error: validation failed: error validating "": error validating data: [ValidationError(Deployment.spec.template.spec.containers[0].securityContext): unknown field "fsGroup" in io.k8s.api.core.v1.SecurityContext, ValidationError(Deployment.spec.template.spec.containers[0].securityContext): unknown field "imagePullPolicy" in io.k8s.api.core.v1.SecurityContext]

Just looking at this, it looks like there must be something wrong with the chart.  The spec path referenced does not contain the specified fields, as the error says.
Here is the spec reference for 1.14: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#securitycontext-v1-core
Looks like something is going wrong with the indents and this line: https://github.com/helm/charts/blob/master/stable/kuberhealthy/templates/deployment.yaml#L58


tsserver showing errors in React even after fixing them, corrects only after manual reload

I keep having this issue that whenever I am writing writing jsx code, 5/10 times the errors are not getting refreshed even after saving. The errors were valid before but after I have fixed them it should not keep showing it, some errors are also shown without line indicators, like in the case below (showing 4 errors, but only 2 line indicators):

Also, in this case, I never had this error but still the server showing me this:

All gets fixed after I manually reload in nvim using ':e' command. I am not sure if this issue is coming from vim or tsserver but it seems like the server is not re-analyzing the file once it is written using ':w' or when we come to normal mode from insert. This does not happen all the time but as I said, 5/10 times it happens and I have to manually reload to fix it.

Check your coc.nvim version by :CocInfo, old version have bug with diagnostic refresh.

Output of my ':CocInfo':
versions
vim version: NVIM v0.7.2
node version: v16.17.0
coc.nvim version: 0.0.82-347e33d7 2022-09-09 18:16:50 +0800
coc.nvim directory: /Users/yachintmacbook/.local/share/nvim/plugged/coc.nvim
term: iTerm.app
platform: darwin
I have updated Coc, nvim and also Tsserver to latest version. I have tested also on a Linux machine with similar results, will test a bit more scenarios to confirm. In the event that I still find the issue persisting, just wanted to confirm that nothing is wrong from tsserver end so that I can possibly raise an issue in Coc repo regarding diagnostic refresh.
Thanks

Also, I have found a way to replicate it on both Linux and Mac systems, the version details for the Linux one are:
versions
vim version: NVIM v0.7.2
node version: v18.9.0
coc.nvim version: 0.0.82-b797c032 2022-09-04 21:59:01 +0800
coc.nvim directory: /home/yachint/.local/share/nvim/plugged/coc.nvim
term: alacritty
platform: linux
The replication steps are explained in the video link below:
https://youtu.be/BtzG3WRyy_A
(NOTE: Also tried the same with the .jsx extension and still same results)
Step details:

Create a new file
Add React import
Create a dummy component
Save and reload (':w' and ':e')
Remove the React import
Save and reload (':w' and ':e')
Then attempt to add the import back

After 7th step, no matter how many times we save the file, the incorrect error is still shown. Only when we reload again, the error disappears.
I would be grateful if you could look into this and let me know if this issue is related to tsserver or Coc in general since it is only happening in React based files in my experience.

Confirmed bug of coc.nvim

Thanks for the acknowledgment, let me know if I should open an issue in Coc.nvim regarding the same.

Fixed on latest release branch of coc.nvim.

Thanks for the quick resolution, can confirm it has been fixed!


Check dataset verbs in form endpoints

Once #575 is complete, Backend will have a new dataset.create verb that is checked in the dataset creation endpoint. With that change in place, we could start checking for dataset.create in some cases when a form or form draft is created. We could also check for dataset.update in form endpoints. Specifically:

If a creating a form or form draft would create a dataset (even an unpublished one), and the user cannot dataset.create, then the request should result in a 403 error.
If creating a form or form draft would add a property to an existing dataset (even without publishing the property), and the user cannot dataset.update, then the request should result in a 403 error.
If publishing a form would publish a dataset or property, and the user cannot dataset.update, then the request should result in a 403.

I had been thinking that we already had an endpoint where we checked both a form verb and a dataset verb, and it looks like we do that for /v1/projects/:projectId/forms/:id/draft/dataset-diff. The comments above that endpoint seem relevant to this issue. The last sentence makes it seem like we previously decided not to check for dataset.update during form publish.

Great idea to separate out this issue. Some of the challenges/things to think through:
Text of the 403 message
By default, it would say something like "this user is not authorized to perform this action", which is too cryptic to explain the situation of a person who can publish a form but can't create a dataset uploading a form that creates a dataset.

I have some questions about edge cases:
Say Alice is an admin and Bob is someone who can do a lot of things except create (or update) Datasets.

If Alice uploads a form that makes a draft dataset people, what does that mean for Bob? (Say Bob can only update.)

If Bob uploaded another form referencing that dataset, should it be counted as creating it or updating it, since it's not published?
Say Bob can't create datasets but can update them. Can he update the draft of the form because it's not really creating the dataset? What about when it comes time to publish? Can he publish it because he can update datasets? Even though at some level, we log this as creating a dataset?

What if Bob can only create? He could upload the first version of a form, but then never update it?

If Bob is not allowed to update a dataset, that just means he's not allowed to add new properties to it? (Asking b/c code doesn't have this level of granularity at the moment.)
Is he not allowed to add properties in the context of a form, or overall? Say one version of a form references dataset people and properties first_name and age. Then another property hometown gets added (maybe via API). Can Bob change the form to write to the new property, too, or should he not be editing that form's interface with the dataset?

Some facts about the code right now:

Any form that references an existing dataset is considered "updating" the dataset, even if properties don't change, because the form def / form fields linking to the dataset has updated.


Add "enzo gulp" command

Just in case someone wants it. I feel like webpack is much more powerful but people may yet want to use gulp.

[ ] Add enzo gulp to website

[ ] Add enzo gulp to help command


Dealing with duplications in NHX

To be able to detect rate shifts following duplications we must be able to distinguish these from speciation events. The speciation events we try to place in time (by fossil calibration), the duplication events we then try to characterize in terms of substitution rates following them. To do any of this we need to parse NHX. We can do this with the newick parser by assigning a true value to the optional -ignore_comments flag, then parsing the square bracket statements that are appended to the node and tip labels.

As of commit https://github.com/rvosa/bio-phylo/commit/6636fecd1a0c30ca0c19b7608292309c30788150, Bio::Phylo parses NHX as per TreeFAM's implementation of it.

Mental note: nhx:D is the key/predicate that annotates nodes to specify whether they are duplications (value: T) or speciations (value: F).


Relicense of rsocket-js to ASLv2

In order to move the project to CNCF, we need to
update the license of the library from BSD to
ASLv2.
This PR only modified the license headers of
every file as well as the root LICENSE file.
There was no code modification.

LGTM


task: update bundle to v99.9.2

Created by the ocp-bundle job in maze88/network-operator OCP bundle CI.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

0 of 0   changed or added relevant lines in 0 files are covered.
51 unchanged lines in 7 files lost coverage.
Overall coverage decreased (-0.9%) to 64.561%

Files with Coverage Reduction
New Missed Lines
%

pkg/state/state_ipoib_network.go
4
75.24%

pkg/state/state_macvlan_network.go
4
77.57%

api/v1alpha1/zz_generated.deepcopy.go
4
40.38%

pkg/state/state_skel.go
4
83.63%

controllers/nicclusterpolicy_controller.go
7
75.31%

controllers/ipoibnetwork_controller.go
7
77.38%

controllers/hostdevicenetwork_controller.go
21
68.18%

Totals

Change from base Build<PHONE_NUMBER>4:
-0.9%

Covered Lines:
3281

Relevant Lines:
5082

💛  - Coveralls


Allow font selection for the CTD editor

Currently the CTD editor renders the text using mesfont font only.
Implement a functionality on the UI to allow to switch between the fonts cmdfont, helpfont, numeric and menufont.
I imagine it should be just a drop down list where you can select the font, then in the code the right FontsArc.Font should be passed as a parameter to the CtdDrawHandler.
The change is quite easy and straightforward and it is a good first issue for a newbie.

Are the issues concerning CTDs still present? If so, I may attempt to fix them.

Are the issues concerning CTDs still present? If so, I may attempt to fix them.

No one fixed it so far

No one fixed it so far

Roger that.

Roger that.

Hey, I'm not sure if this issue is still actually available, but if it is could I be assigned to it?

I think it's still up but I have assigned you to it

Appreciate it! Should I look here for any potential issues I run into or would somewhere in the discord be a better place?

For general questions just ask in Discord :)


Web console: making the cell filter menu more functional

The cell filter menu will now let you add to existing filter for that column.
Also remove the old query view (did not care to update it).

Also remove the old query view (did not care to update it).

This seems like a bigger deal than the thing in the title of the PR! Please update the title to include this change.


Update test for EditRole feature

Update test for EditRoleCommand class

Update test for EditRoleCommandParser class

Update test for parserUtil parseDoubleIndexWithContent method

Codecov Report

Merging #120 (c2e18e3) into master (fe0518b) will increase coverage by 1.34%.
The diff coverage is 83.00%.

@@             Coverage Diff              @@
##             master     #120      +/-   ##
============================================
+ Coverage     69.97%   71.31%   +1.34%
- Complexity      554      579      +25
============================================
  Files            90       92       +2
  Lines          1735     1834      +99
  Branches        196      216      +20
============================================
+ Hits           1214     1308      +94
+ Misses          454      446       -8
- Partials         67       80      +13

Impacted Files
Coverage Δ

.../seedu/address/logic/parser/AddressBookParser.java
80.00% <0.00%> (-4.22%)
:arrow_down:

.../seedu/address/logic/commands/EditRoleCommand.java
76.56% <76.56%> (ø)

...in/java/seedu/address/logic/parser/ParserUtil.java
89.87% <85.71%> (+0.83%)
:arrow_up:

...du/address/logic/parser/EditRoleCommandParser.java
100.00% <100.00%> (ø)

src/main/java/seedu/address/model/role/Role.java
87.50% <0.00%> (+2.50%)
:arrow_up:

.../java/seedu/address/model/company/RoleManager.java
63.63% <0.00%> (+9.09%)
:arrow_up:

.../java/seedu/address/model/role/UniqueRoleList.java
53.65% <0.00%> (+9.75%)
:arrow_up:

...ain/java/seedu/address/model/company/RoleList.java
76.00% <0.00%> (+12.00%)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM. Very detailed testing done!

LGTM. Very detailed testing done!

@kerbysoh FYI, only PR review comments (not regular comments like this one) are counted for grading.


Handle Verticle Scrolling

The filter box does not handle verticle scrolling well. Need to add a max height and scrollbar.

Implemented in WFRC's test app, and looks great.


⚠ Bofrost.fr has degraded performance

In 7228e46, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1248 ms

Resolved: Bofrost.fr performance has improved in e944013 after 8 minutes.


example\cli project didn't run at IE11

Hi,
To allow for a faster response, please read carefully:
Please look for an answer in the docs before submitting an issue:
angular2-tree.readme.io.
In case you are reporting a bug, please reproduce it on webpack bin. You can start from here:
https://www.webpackbin.com/bins/-KqGwvVQLknZ-fTXHjCO
Open the left side menu and click copy
Make your changes
Click Save to view results
Share the URL once reproduced
If you are unable to reproduce on webpackbin, please:

paste your package.json
say which browser you are using
paste your nodes and options and whatever code your feel will help reproduce the error

Thank you and happy programming

Hi,
Demo works on IE11 on the docs site


Is this project dead?

Doesn't seem to be any active development going on judging by the lack of updates to the github...

Yeah, the previously active developers have had to step away and I'm not really set up to do development on native windows apps.
I'm currently working on a rewrite that, strictly speaking, is a less ideal choice of language, but will be a lot easier for me to continue to be personally involved, push bug fixes, and add device support.
There are some great alternative projects out there, though most of them are not open source.
More details on similar projects and on the rewrite can be found on the discord in #rewrite-progress and #similar-projects:
https://discord.gg/2NtJnZPVRT

Yeah, the previously active developers have had to step away and I'm not really set up to do development on native windows apps.
I'm currently working on a rewrite that, strictly speaking, is a less ideal choice of language, but will be a lot easier for me to continue to be personally involved, push bug fixes, and add device support.
There are some great alternative projects out there, though most of them are not open source.
More details on similar projects and on the rewrite can be found on the discord in #rewrite-progress and #similar-projects:
https://discord.gg/2NtJnZPVRT

Very interesting, thanks!  Honestly, even though development on this seems to have stopped, i'm just glad to hear that you're working on a rewrite, since the current version has some issues (namely it seems to randomly "forget" programs that i've assigned, after a reboot)

Im using https://www.midi-mixer.com/ as alternative


Basic idea: please mention the versions used for each tool in each release of nf-core/rnaseq.

Description of feature
please mention the versions used for each tool in each release of nf-core/rnaseq. It would be helpful as I found it difficult each time I run nf-core. If you could add in your code page of github if would be helfpul or at least refer to where we can find.

This will help those who need to create STAR index and can't find the STAR version that suits their module version becuase of using their university HPC with sometimes older version.

We mention in the changelog any changes of version of any tools


Phoebemirman/ch14995/polish orderbook styles

https://app.clubhouse.io/augur/story/14995/polish-orderbook-styles
shows up in create market and trading page

Coverage remained the same at 66.502% when pulling 716de3f74903648aa5188e6a979fe4196e6211a3 on phoebemirman/ch14995/polish-orderbook-styles into ec6875d389f5d52c5c862a4d1ac1822e5030f480 on master.

There are 0s when it's tickSize is 0.1 so the prices can only have .1 precision. need to take tickSize (precision) into account.

Just another case of scalar market that has tickSize 1, so there won't be following zeros. Scalars are tricky. :/


Does this feature require an E5 license, or will this work with E3?

Does this feature require an E5 license, or will this work with E3?  Please indicate which licenses are required in order to use advanced eDiscovery reports.

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

ID: 537e7055-af69-4127-7b3b-1d76796c6f40
Version Independent ID: b2827f5d-bf44-474e-442e-22bc101e7681
Content: Advanced eDiscovery reports - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/advanced-ediscovery-reports.md
Service: o365-seccomp
GitHub Login: @markjjo
Microsoft Alias: markjjo

@michaelblumenthal All feature/functionality in Advanced eDiscovery requires E5 or E3 + Advanced Compliance add-on. Please see: https://docs.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-tenantlevel-services-licensing-guidance#office-365-advanced-ediscovery or https://docs.microsoft.com/en-us/office365/servicedescriptions/office-365-platform-service-description/office-365-securitycompliance-center

Re-posting the second URL from above as the URL changed since initial posting:
https://docs.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance#office-365-advanced-ediscovery


Buildkite CI example

This can easily be used in Buildkite too, so I added an example to the README on how folks can achieve this using Buildkite's steps.
I added L4 headers so that folks can link to their relevant CI provider.

Thanks for the suggestion. I'm not sure if this is helpful, since the command isn't any different.


Default charts aren't editable

"Override" chart option isn't available. To change a chart user have to save it as a new one, remove the old one and replace it on a dashboard.
p.s. we can consider it as a feature, not a bug actually.

it was fixed by fixing the import/export.


client: Remove PYTHONPATH from the env before running interop test

If a PYTHONPATH already exists in the environment, it will be used instead of the one we specify, breaking the tests.

LGTM


The FCS_COP.1/KeyEnc Cryptographic operation (Key Encryption) SFR in HCD cPP v1.0 is inconsistent with TPM 2.0 Architecture specification section "26.6 Sensitive Area Encryption"

As noted by Alan, Lexmark stumbled into an issue with the HCD cPP v1.0 for the FCS_COP.1/KeyEnc Cryptographic operation (Key Encryption) SFR on page 62:
The SFR states that:
The TSF shall perform key encryption and decryption in
accordance with a specified cryptographic algorithm [selection:
Case: AES algorithm
• AES used in [[selection: CBC, GCM] mode] and cryptographic key sizes [selection: 128 bits, 192
bits, 256 bits] that meet the following: AES as specified in ISO/IEC 18033-3, [selection: CBC as
specified in ISO/IEC 10116, GCM as specified in ISO/IEC 19772],
However, for this particular Lexmark product the original product design utilized a TPM not to store an encryption key, but to encrypt it utilizing the TPM2_Seal() API and then storing the encrypted key in flash outside the TPM.  While documenting our compliance with FPT_KYP_EXT.1.1 we discovered that while the TPM was compliant with the TPM 2.0 Architecture specification section "26.6 Sensitive Area Encryption", it was violation of the HCD cPP FCS_COP.1.1/KeyEnc requirements, since it did not use it use CBC or GCM mode.
From TPM 2.0 Architecture specification Section 26.6 (Page 172) https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf -"All symmetric encryption of the sensitive area uses Cipher Feedback (CFB) mode." NOTE: CFB is the only AES mode allowed by the TPM 2.0 specification for this activity.
PROPOSAL:
Change the text in A.2.2 FCS_COP.1.1/KeyEnc from:
...
Case: AES algorithm:
• AES used in [[selection: CBC, GCM] mode] and cryptographic key sizes [selection: 128 bits, 192
bits, 256 bits] that meet the following: AES as specified in ISO/IEC 18033-3, [selection: CBC as
specified in ISO/IEC 10116, GCM as specified in ISO/IEC 19772],
...
to:
...
Case: AES algorithm:
• AES used in [[selection: CBC, GCM, CFB] mode] and cryptographic key sizes [selection: 128 bits, 192
bits, 256 bits] that meet the following: AES as specified in ISO/IEC 18033-3, [selection: CBC as
specified in ISO/IEC 10116, GCM as specified in ISO/IEC 19772,  CFB as specified in ISO/IEC 10116],
...
In layman's terms, add CFB as an allowed mode to encrypt a key when using the AES algorithm.

I can accept Graydon-san’s proposal to add CFB in FCS_COP.1/KeyEnc. But, you all might be aware of it, the case which Graydon-san described in the issue might be the one which was exempted to verify the protection method by FCS_KYC_EXT.1.
In brief, we intended to make the key in TPM out of the key chain in FPT_KYP_EXT.1, and to exempt to verify the protection method if the key in TPM is used for key encryption.
Of course, if CFB is used for key encryption with the key which the application can access, then CFB should be added to the selection.
I’d like to know your intention in the discussion we will make.
Exemption of protection method verification in FCS_KYC_EXT.pptx

AES CFB should be an acceptable addition if it is needed.

Kwangwoo asked how the proposed addition of AES-CFB mode as an allowed selection option in FCS_COP.1.1/KeyEnc in the HCD cPP would correspond to changes in draft version 0.1 of the Specification of Functional Requirements for Cryptography [Crypto] from the Crypto Working Group.
[Crypto] does not include an SFR specific to key encryption (e.g., FCS_COP.1/KeyEnc in the HCD cPP), so there is no direct direct correspondence.  [Crypto] includes iterations of FCS_COP.1 for Key Encapsulation (/KeyEncap) and Key Wrapping (/KeyWrap), but neither of those SFRs involve usage of AES in a mode close to CFB.
However, [Crypto] includes FCS_CKM_EXT.3 for Cryptographic Key Access, which does directly reference key encryption:
FCS_CKM_EXT.3.1 The TSF shall use specified cryptographic key access methods [selection: key encapsulation, key wrapping, key encryption] that meets the following: [selection: list of standards] to access keys when performing [selection: cryptographic key usage in cryptographic operations, cryptographic key archival, cryptographic key backup, cryptographic key escrow, cryptographic key recovery, modifications to attributes of cryptographic keys, cryptographic key destruction].
In the Application Note for this SFR, specifically in the section regarding Key Access Operations, typical actions for the life cycle of a key are identified.  The following two actions potentially correspond to our proposed change to FCS_COP.1.1/KeyEnc (with relevant text bolded):
Cryptographic key usage in cryptographic operations – Depending on the application, a cryptographic key could be root key which by virtue of being a root key, cannot be encrypted with another key.  It is often stored in plain sight, sometimes with hardware protections, sometimes obfuscated in clever ways, such as in physically unclonable functions.  Other than root keys, it is expected that other cryptographic keys should be protected with encryption, often using other keys, which leads to a chain or hierarchy of cryptographic keys that encrypt other keys often anchored by a root key.   Additionally, it is expected that an entity authenticate itself self as an authorized user of the key.  This latter requirement is in addition to the recommended requirements of the Common Criteria Part 2 for FCS_CKM.3.
Cryptographic key archival, backup, and escrow – TOEs often perform cryptographic key archival to manage limited memory resources inside its own security boundaries.  Often the TOE encrypts the cryptographic keys prior to saving them to storage that is close by on the same device as the TOE and that can be accessed quickly. TOEs may perform cryptographic key backups into storage that is meant for longer term keeping.  Backup storage is often not on the same device as the TOE and may be physically hundreds of miles away.  In practice, the TOE encrypts the keys using an approved method before sending them to backup storage.  TOEs may perform cryptographic key escrow in which it entrusts a third party with access to the private or secret keys.  In practice, the TOE protects the keys using a cryptographic key access method agreed upon with the escrow agent before sending them.
The Application Note for this SFR, specifically in the section regarding Key Access Methods, states that if Key Encryption is claimed as a method in FCS_CKM_EXT.3.1, then approved methods such as those included in FCS_COP.1/SKC should be used.  FCS_COP.1.1/SKC currently does not include AES-CFB as an allowed mode.  However, it does include SEED-CFB, HIGHT-CFB and LEA-CFB as allowed modes, so adding AES-CFB may be considered reasonable.  Note that this would add AES-CFB mode for all symmetric key operations, not just key encryption as would be the case for FCS_COP.1.1/KeyEnc in the HCD cPP.

In a previous note on Apr 19, @Ryuichiro-Ohya-FX provides a PPT file detailing a method of excluding the TPM encryption of keys from the key chain documented in FCS_KYC_EXT.1 and FCS_KYP_EXT.1.  This methodology is consistent with the HCD cPP and SD, since both documents include clarifying text for crypto operations performed by a TPM.  In my opinion, we should consider resolving this issue via that suggested methodology since it does not require any cPP/SD change.
[Crypto] does not include any requirements addressing key chains.  Therefore, while usage of the suggested methodology for excluding TPM-based crypto does not have any direct impact on [Crypto], it is not possible to analyze how usage of that methodology would impact other PPs/cPPs (which would presumably add SFRs to address key chains).


Outdated Documnetation Site

Although the documentation on github gives the correct instructions, the actual doc site which is linked gives the wrong instructions.
It would be nice for the docs site to be updated with the proper assembly instructions.
On an unrelated note/question: has the cost model of cycles changed, it seems to be removed from the documentation it seemed like a good heuristic to understand the cost of the system.

So, the issue is that docs in the main branch on Github are for v0.2 release while docs on the site are for the next branch. So, if you are using v0.2 (or the main) branch - Github docs are the relevant ones, but if you are using next branch, then the site docs are the relevant ones.
I don't think we explain this anywhere, and I can see how this can be confusing. We'll need to think how to make this more clear and maybe link to the right docs from the right branch.

We now have two documentations:

Stable v.0.2.0 release under https://wiki.polygon.technology/docs/miden/intro/main/
Next branch release under https://miden.polygon.technology/

I will create a PR to change our README to let everyone know.


Merge neighbourhood processing interface into fewer CLIs

As an IMPROVER developer I want a clear neighbourhood processing interface so that it is easy to work with.
This ticket is to merge the "nbhood", "nbhood-iterate-with-mask" and "nbhood-land-and-sea" CLIs into a single "nbhood" CLI, with the following parameters and defaults:

New option "--kernel" to specify circle, circle_weighted, square or square_recursive filtering
Make square_recursive the default for this CLI, with default alphas values

There is a significant amount of code in some of these CLIs, and follow on work may be required to move this into the IMPROVER libraries.
Related issues: #480 (prerequisite), #352 (example behaviour of new CLI)
Acceptance criteria:

A single CLI that preserves existing functionality (after #480), with the additional parameter and default defined above
Rationalise bats test and known good output for these CLIs, removing duplicates and reflecting the new functionality and defaults
Identify follow on work to move code out of this CLI and into IMPROVER plugins or utilities
Fixing the suite to use the new CLI is out of scope and will be covered by IMPRO-589

Superseded by https://github.com/metoppv/mo-blue-team/issues/157


Update Create/Edit Person page

Description

This page currently does not entirely match the desired styling and functionalities, need debugging and error fixing.

Acceptance Criteria

[ ] Styling matches the style guide
[ ] Save functionality works, successfully update a person's information
[ ] Delete functionality works, successfully delete a person and return back
[ ] Create person functionality works, successfully creates a person and forward to create encounter page
[ ] Social media modal handles cases where the input social media platform does not exist
[ ] Change photo functionality works, successfully upload an image and replace the avatar preview image

Implementation details

n/a
Testing notes

Ensure all ACs are checked

Great issue, thanks for raising this


Keyboard Handling bypasses CMD + key shortcuts

Example: CMD + Back Arrow no longer allows user to go back to previous page in browser

fixed with 5ea94106588e95f13f1f4720b871f6d6d3d46416

@erin-dot-io update should be on Chrome Store soon.


Eliminate https://github.com/istio/api/tree/master/common/v1alpha1

Describe the bug
We've recently added https://github.com/istio/api/tree/master/common/v1alpha1 as a stand-alone proto, and it doesn't really fit how we've been organizing protos to date. It looks silly in our docs (https://preliminary.istio.io/docs/reference/config/istio.string.v1alpha1/)
Let's combine this proto with whatever place is trying to use it, instead of having this in a separate file.

@rshriram FYI

It's currently only used in policy.proto, I'll move it to that file.
/cc @diemtvu


Remove React Relay Dependency

Is your feature request related to a problem? Please describe.
As someone that uses Apollo over Relay, I would love to not have the extra weight that the Relay dependency bring weighing down my app.
Describe the solution you'd like
Remove the Relay dependency and handle Relay the same way you currently are for Apollo.

Sure thing, @texpatnyc! We're working on this request currently.


Replace deprecated bundle install with our own task

This removes the deprecated way we ran bundle install (via "bundler/capistrano" and with flags on the bundle install command) with a new task to run bundle install the modern way with config commands set.
This has been done to allow us to deploy apps that use Ruby 3.1 which defaults to a version of Bundler that struggles with the deprecated flags (example failed build: https://deploy.integration.publishing.service.gov.uk/job/Deploy_App/53133/)
I've tried this build out with a Ruby 2.7.6 app, Travel Advice Publisher (build) and a Ruby 3.1.2 app, Publishing API (build - don't worry that it's flagged as unstable it's because I built from a commit)

Thanks for the review Chris. I'm going to wait until Slack is back before merging just incase I missed a project that'll fail with this.


proposal: maps: remove Keys and Values for Go 1.21

Given #61405 and the likelihood of additional operations on those kinds of iterator functions (like Map, Filter, and Reduce), it seems possible that we would want Keys and Values to return iterator functions that can be used with those and do not provoke O(N) storage. I imagine there would also be a slices.Collect that collects values from any iterator into a slice, so existing uses of maps.Keys(m) that still want a slice would become slices.Collect(maps.Keys(m)).
If there's a good chance we're going to want Keys and Values to return iterators in Go 1.22, it seems short-sighted to ship them in Go 1.21 returning slices. I wonder whether we should pull them. It is late in the cycle, but not too late. git grep says there are no mentions of maps.Keys or maps.Values in the standard library.

I'm not clear on the value of using iterators for those methods rather than the normal range loops that exist today. We don't have map, filter, or reduce that work on iterators. Whatever package provides them can also trivially provide a function to adapt any rangeable value to an iterator.

s/Slices/Values/g?

We have relevant experience with something like maps.Keys and its rather unpleasant one, because most of the time you don't need all keys: you likely don't need 90% of them, since the result of maps.Keys in most cases is going into something like slices.Filter with very specific filter pattern.
And the reason it's unpleasant is because you never know how many keys are in the map now - each time there is chance of unbounded memory growth, that could not happened during original code review, but things had changed since then and now instead of 10 keys you constantly filtering from 10000 keys.
But thats our experience anyway.

Instead of slices.Collect(maps.Keys(m)), what if we keep maps.Keys but do something like slices.Collect(maps.KeyIter(m)). This would make the signature reads more clear that Keys returns an slice, but KeyIter returns an iterator?

@jimmyfrasche Yes thank you. Changed Keys and Slices -> Keys and Values.
@zephyrtronium

I'm not clear on the value of using iterators for those methods rather than the normal range loops that exist today. We don't have map, filter, or reduce that work on iterators. Whatever package provides them can also trivially provide a function to adapt any rangeable value to an iterator.

That's true, but if the rangeable value is the current maps.Keys(m), then Keys builds the entire slice in memory even if you only just want to iterate through the keys and look at them. That's O(N) space that could be O(1) space instead, a large and potentially important difference for big maps. I don't think we should lock ourselves into the O(N) iteration strategy for map keys and map values.
@DmitriyMV: Yes, exactly, that's the situation I am concerned about. If Keys returned an iterator instead of a []K, you wouldn't have the memory or latency hit of collecting all the keys. You might still have the latency of filtering if you are going to go through all of them, but you avoid the memory hit with a filtered iterator. And if you stop early, you avoid the latency hit too.
@changkun Yes, if we keep Keys and Values as they are we will have to introduce some other iterator form for efficiency, maybe called KeysIter and ValuesIter. But I suspect most uses for Keys and Values work better with the iterator form (which would fix @DmitriyMV's example), meaning we should save the good names Keys and Values for them instead of giving them second-rate names.

instead of giving them second-rate names

Why is the Iter suffix a second-rate name? Values vs ValuesIter Comparably we already have artifact pairs like Handler vs HandlerFunc etc.

That's true, but if the rangeable value is the current maps.Keys(m), then Keys builds the entire slice in memory even if you only just want to iterate through the keys and look at them. That's O(N) space that could be O(1) space instead, a large and potentially important difference for big maps. I don't think we should lock ourselves into the O(N) iteration strategy for map keys and map values.

I don't see how we would be "locked into" an O(n) space iteration strategy for map keys or values. If I want O(1) space iteration over the keys of a map m, I write for k := range m. I don't see why I would ever use maps.Keys for that. When I use maps.Keys, it is to build a list of all the keys, usually followed by sorting the list. That is the most common purpose for which I use package maps, even. I didn't realize that is unusual.
Of course, I could still do this with a slices.Collect that accepts an iterator. And if that doesn't happen, maps.Keys and maps.Values can of course be added later. It just seems unfortunate to me to revise an already accepted proposal to remove the feature I use most frequently from its experimental version because of a language change that might happen and that might be followed by an API addition that can't even be proposed until that language change is decided.

meaning we should save the good names Keys and Values for them instead of giving them second-rate names.

Another way to provide a "first-class" name for composable map iterators would be to introduce a package iter which might have iter.Map, iter.Keys, iter.Collect, &c. maps.Keys isn't the only option.

More general formulations of algorithms might want to parameterize on something like type Pair[K comparable, V any] struct{Key K, Value V}, to preserve the key:value association. Also, there might be a type OrderedValue[V any] Pair[int, V] for slices and OrderedPair[K comparable, V any] OrderedValue[Pair[K,V]] for ordered map elements.
I'm quickly unsure if or when this is "bad idea" territory, but it's probably not in some languages - it's just that I definitely agree about not getting locked.

@rsc I think we can flip this backwards: instead of talking about leaving the preferred name for iterators, think about how not using a suffix will cause confusion in the rest of the standard library. There are things all over that return slices, and with iterators, it could be valuable to add methods and functions that return them. This won't be the only place. I also think something ThingIter sounds like a name of a thing iterator and Things sounds like I already have those things allocated.

Pretty much everything in the standard library that returns a slice today should return an iterator in a future version. Adding "Iter" suffixes may be OK given the history but it's not where we want to end up. A v2 of those packages might flip the default. Or maybe there are good names available that don't use Iter. Either way, maps and slices are brand new packages. We don't want to go straight to a v2 just to fix this detail. We can avoid making the mistake to begin with if we just leave them out for this release and give ourselves another cycle to get it right. Maybe we'll end up back where we are today, but maybe not. I suspect not.

I don't think it's entirely a mistake though. There are choices all over where we use slices as a return instead of some sort of iterator and have performance that is just fine. Anything that isn't CPU bound won't have a noticeable improvement either way.
However, at any given time, most software developers are fairly junior and the concept of an iterator is more difficult than the concept of a slice. Python has had generators and iterators for quite some time, but most of the time you see people using lists. It's totally unnecessary, but outside shared libraries, it rarely causes a difference. I don't think you'll stop seeing slices used a lot more often than iterators even if we one day have a Go 2 where they are the more common option.
That said, I personally haven't seen much indication that we would ever get to a point where such a big break would be worth it, so using words that are less specific in hopes that you can standardize on that eventually doesn't seem particularly helpful

I think iterators shouldn't be the default choice, in general. They should be something the programmer consciously opts in to when needed. It simply follows the principle of least surprise. It is intuitive and unsurprising that maps.Keys and maps.Values return slices, just as the names imply. I strongly agree with @zephyrtronium 's comment above:

If I want O(1) space iteration over the keys of a map m, I write for k := range m. I don't see why I would ever use maps.Keys for that.

I think iterators shouldn't be the default choice, in general. They should be something the programmer consciously opts in to when needed.

Normally you would want the most costly and specific option to be consciously opted in and clearly returning a slice is more costly than returning an Iterator. having the full slice of elements upfront is usefull only when you are sure that you would need all of them and can justify the memory used. The more generic case is that you would need only some of the values and/or potentially exit early from the loop making Iterators better suited for the default choice.
You can collect the elements of the iterator in a slice if it's needed but while you still can't really get an iterator of the slice. I mean yes you can create an iterator that loops over the slice but the "damage" of the memory use is already done and creating an iterator at that point is almost useless.

But I suspect most uses for Keys and Values work better with the iterator form

I don’t suspect that. Python 3 changed from returning a list to returning an iterator, and it was often a pain because I needed to wrap the keys method in a list conversion. For maps.Keys today, my most frequent operation is to take the keys and sort them, which requires it being a slice. I think there should be an easy to use slice function. If it’s called KeySlice instead of Keys, that’s fine, but it is so frequently used it really is a pain to have to add a collect step in.

If you need sorted map keys maybe you need a sorted map instead? Even without such a thing, if you need to collect the keys in a slice once it's not a lot of code (with or without stdlib changes) and if you need it more than once you can throw that in a function.

if you need it more than once you can throw that in a function.

And that function could be in the standard library. ;-)

I'm not opposed to functions that collects the keys/values in a slice, but I agree with @rsc that is less general than the iterator form and hence the short name should go to the iter form. For the specific use case you bring up, I wonder if a more generally useful way to expose that would be a sorting func that takes an iterator as input and returns a slice.

I agree that this is a release blocker and should be resolved definitively before 1.21 releases, but I also think this is a bit of retreading previous decisions. Iterators were discussed as part of the planning for the maps package. In https://github.com/golang/go/discussions/47330#discussioncomment-1214446 @ianlancetaylor wrote,

A normal map iterator will be over key/value pairs. I don't think that an iterator over just keys or just values will be the common case. While I can imagine adding them (if we ever have iterators), I don't think we need to reserve better names for them.

Did something change to make us rethink that?

Reading the keys of a map to obtain a sorted slice of keys is a use case that I have encountered several times. Without the slices and maps package, I would have written
i := 0
s := make([]T, len(m))
for k := range m {
	s[i] = k
	i++
}
sort.Slice(s, func(i, j int) { return s[i] < s[j] })

With the slices and maps packages, you can write
s := maps.Keys(m)
slices.Sort(s)

but with the change of this proposal I suggest introducing a slices.Sorted function
s := slices.Sorted(maps.Keys(m))

declared as
Sorted[T comparable](iter func(func(T) bool) bool) []T

This would be a good improvement, using only the standard library, compared to the current situation.

A process comment: we say to people that they should write code against release candidates and deploy them to production. At this point these functions have been in RCs for about a month, and I think it's plausible that people have uses functions in their codebase that will break when they update from the last RC to the final release. Are we concerned about the risk of breakage?

The current version of maps.Keys is impl by me. I think https://go-review.googlesource.com/c/go/+/481435 and https://go-review.googlesource.com/c/go/+/481436. I do not know the detail impl of iters. but I think the current version of maps.Keys/Values could be faster that the Iter version.  I think performance is also an important consideration.

As many have already mentioned, the main use of maps.Keys is for sorting.
GitHub Code search results
In this case, what we need is not an iterator, but a slice to be sorted.
(The method proposed by @gazerro does not allow us to make([]T, len(m)) before sorting, which would be inefficient.)

@eihigh the Sorted function could be declared to get an initial cap for the slice
s := slices.Sorted(maps.Keys(m), len(m))

so it would be declared as
Sorted[T comparable](iter func(func(T) bool) bool, n int) []T

For an iterator whose length you don't know in advance, just use 0.

@eihigh the Sorted function could be declared to get an initial cap for the slice
s := slices.Sorted(maps.Keys(m), len(m))

so it would be declared as
Sorted[T comparable](iter func(func(T) bool) bool, n int) []T

For an iterator whose length you don't know in advance, just use 0.

Sorted usually need random access to slice, so I think event use
Sorted[T comparable](iter func(func(T) bool) bool, n int) []T

we still need to get a key slice in Sorted Internal impls.

As many have already mentioned, the main use of maps.Keys is for sorting.

That's a pretty big assumption that many are making. I see this all the time in many new proposed features that people mistake their own use for the common use.

we still need to get a key slice in Sorted Internal impls.

This trivial implementation should be sufficient
func Sorted[T comparable](iter func(func(T) bool) bool, n int) []T {
      s := make([]T, 0, n)
      for k := range m {
              s = append(s, k)
      }
      sort.Slice(s, func(i, j int) { return s[i] < s[j] })
      return s
}

This trivial implementation should be sufficient

A nice thing about a slice of keys is you can use slices.SortFunc to sort it backwards, etc.

To me the question to resolve here should not be whether to have a maps.Keys at all, but whether to give it a short name or a long name. There's just no world in which maps.Keys doesn't pull it own weight. It's an extremely common use, and if we leave it out entirely, people are just going to keep using golang.org/x/exp/maps instead of std/maps.

I'm okay with something maps.KeysSlice and maps.ValuesSlice since they are pretty explicit about what you will get. But I think that we should preserve maps.Keys until iterators arrive, since that is what most people will use.

I'm okay with something maps.KeysSlice and maps.ValuesSlice since they are pretty explicit about what you will get. But I think that we should preserve maps.Keys until iterators arrive, since that is what most people will use.

I'm fine with that, but I would call it maps.KeySlice and maps.ValueSlice (no s).

Instead of adding specific functions to the maps package, we could extend the append and copy builtins:
s := make([]T, 0, len(m))
s = append(s, maps.Keys(m)...)

s := make([]T, len(m))
copy(s, maps.Keys(m))

It sounds like there is enough uncertainty that we should pull these from Go 1.21.
The code there is worth preserving; we can just s/Keys/keys/ and s/Values/values/
in the implementation and not delete any code.

I don't think there is uncertainty about the need for the functions; just uncertainty about the names. It seems unfortunate to have fewer functions in the standard library version than the exp version, leading people to stay on exp for an extra six months.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

We started using exp/maps at work some months ago and Keys and Values are the only functions we're using so far. I'm sure we'll use more of the API later on as more code is written and as we get more acquainted with the package but I do think that Keys and Values represent the bulk of the "expected value" of this package. I don't really see the point of including the maps package in Go 1.21 without these functions.

I tend to agree with @cespare, if there's not enough time to work out Keys/Values before 1.21, perhaps maps should just be held back entirely for the cycle.

For me, I already have PRs open called "Upgrade to Go 1.21" that are made against the RCs that use maps.Keys. It would be more work to take those and have them use std/maps in some places and exp/maps in others than to just back that out and use exp/maps everywhere, but keep the slices/constraints changes.

Apologies to everyone who is disappointed. I want to use these in Go 1.21 too. But I also want to use them in future versions, and I want them to fit into those versions well. In the grand scheme of things, having to wait another 6 months to import "maps" instead of "golang.org/x/exp/maps" will only hurt for 6 months, and really not very much. But if we want something different and land this now, it will hurt for much longer.

@fzipp

I tend to agree with @cespare, if there's not enough time to work out Keys/Values before 1.21, perhaps maps should just be held back entirely for the cycle.

The other functions are useful without these two, I don't see the hard connection. Early adopters who have used x/exp/maps can continue to do so until these functions or alternatives are added.

The main issue is namespace collision: if I type maps. in my editor, gopls will presumably prefer suggestions from the standard library over an external module, especially if I haven't yet added x/exp to my go.mod. If I happen to use maps.Clone before maps.Keys, then I might have to fix my import lines manually. But I agree that it probably won't cause much pain overall.

The concrete thing that confuses me is that it seems like there's general agreement that a (the?) major use of these functions is in the vein of "give me all of the keys of a map so I can sort them and use that slice", e.g. for printing, stable iteration, etc.
I agree that if the goal is to compose multiple iterators together, that you'd want to have a wrapper function that can iterate over the keys or values of a map, such that it can be fed into some other algorithm (filtering and whatnot). But, the previously linked code search seems to imply that people tend to want "the sorted list of keys" to immediately use, and aren't so much applying other transforms.
Of course, if it is iterators that gets added instead, people would write:
keys := slices.Collect(maps.Keys(m))
slices.Sort(keys)

But, I'd worry that this exact code is going to be the majority of uses of maps.Keys, and it doesn't benefit from having used iterators at all.

Well, TIL I can't just read the weekly review notes summary to be involved, because the one from today is the first mention of this and it's already accepted.

@zikaeroh
Not to get too off-topic, but I'm hopeful that there'll be a pair of functions for collecting and sorting in one run. Something like
package iters

func AppendSort[T cmp.Ordered](dst []T, iter Iter[T]) []T
func AppendSortFunc[T any](dst []T, iter Iter[T], less func(v1, v2 T) bool) []T

By using a binary search to find where to insert each element as it goes and allowing preallocation, it should be possible to make it pretty efficient, I think. Then things like
keys := maps.Keys(m)
positiveKeys := iters.Filter(keys, func(v int) bool { return v >= 0 })
sortedPositiveKeys := iters.AppendSort(make([]int, 0, len(m)), positiveKeys)

become possible.

@rsc I 100% agree with everything you wrote in https://github.com/golang/go/issues/61538#issuecomment-1652499360. Waiting an extra 6 months is no big deal. exp/maps works perfectly well for now.
What is slightly annoying is adding the maps package to the stdlib without its most useful functions and creating 6 months of bifurcation because we can't do a one-time switch from exp/maps to maps. At work I expect confusion from users who are now getting accustomed to exp/maps when maps lands without these functions. It's one thing to say "here's maps: it's like exp/maps except Keys and Values are now iterators." It's another to have to explain "here's maps: don't bother using it yet because the functions you need are still only in exp/maps."
Why not just wait for 1.22 to add maps?

Another reason to wait is what if we want maps.Copy to take an iterator for its second argument? Seems like a reasonable thing to have. It could be called Update or something, but if we’re holding back on naming, seems like we should be wholistic.

I'm sad to see that these 2 functions got removed in favour of a more complicated solution. What is the point to remove simple well working functions right before the release?

Reopening because CL 513715 needs to land too.

I opened #61613 to formalize the suggestion from @cespare and @carlmjohnson to hold back the entire package instead of only Keys and Values. I'm not sure how I feel about it personally, but the timeline is very tight, so I think it makes sense to have the discussion now if it will be had.

@perj Sorry for the rush on this proposal.  It was rushed by the nearness of the release.  Deciding not to do something is always safe, if disconcerting.
@zephyrtronium Nobody has seen any trouble with the other functions in the maps package, and they do have support in that they were successfully used in the x/exp/maps package.  I don't see a strong reason to pull them from the 1.21 release.

CL 513715 is landed.

Common cases named map.Keys, maps.Values
for Iter named  maps.KeyAll ,maps.ValueAll

That's true, but if the rangeable value is the current maps.Keys(m), then Keys builds the entire slice in memory even if you only just want to iterate through the keys and look at them. That's O(N) space that could be O(1) space instead, a large and potentially important difference for big maps. I don't think we should lock ourselves into the O(N) iteration strategy for map keys and map values.

I don't see how we would be "locked into" an O(n) space iteration strategy for map keys or values. If I want O(1) space iteration over the keys of a map m, I write for k := range m. I don't see why I would ever use maps.Keys for that. When I use maps.Keys, it is to build a list of all the keys, usually followed by sorting the list. That is the most common purpose for which I use package maps, even. I didn't realize that is unusual.
Of course, I could still do this with a slices.Collect that accepts an iterator. And if that doesn't happen, maps.Keys and maps.Values can of course be added later. It just seems unfortunate to me to revise an already accepted proposal to remove the feature I use most frequently from its experimental version because of a language change that might happen and that might be followed by an API addition that can't even be proposed until that language change is decided.

Can't agree more, please add maps.Keys and maps.Values back to the standard library.

This issue is closed. See https://github.com/golang/go/issues/61900 for the proposal to bring back maps.Keys and maps.Values as iterators.

https://github.com/golang/go/issues/65919

@earthboundkid no, thats not the same thing. your comment presupposes that an iterator implementation is the only option, or the best option, neither of which is true in all cases.

Maybe I have limited information and less knowledge than the members of the go team, but if it is to support the functions of the iter package, why not add two new function names, such as maps.KeysIter and maps.ValuesIter, instead of changing the behavior of the previous method.

Maybe I have limited information and less knowledge than the members of the go team, but if it is to support the functions of the iter package, why not add two new function names, such as maps.KeysIter and maps.ValuesIter, instead of changing the behavior of the previous method.

This was discussed in depth in this thread. I preferred this approach because the implementation of an iterator technically hides complexity that could be expensive if you don’t read the implementation and in most trivial cases an iterator doesn’t actually improve efficiency. However, the consensus was that iterators should be the difficult so that if all you need is iteration, you are less likely to materialize the whole slice somewhere and be able to stream process with good efficiency. Regardless of your opinion, the ship has sailed now and you can try this now. If you need a slice, simply collect it

This was discussed in depth in this thread. I preferred this approach because the implementation of an iterator technically hides complexity that could be expensive if you don’t read the implementation and in most trivial cases an iterator doesn’t actually improve efficiency. However, the consensus was that iterators should be the difficult so that if all you need is iteration, you are less likely to materialize the whole slice somewhere and be able to stream process with good efficiency. Regardless of your opinion, the ship has sailed now and you can try this now. If you need a slice, simply collect it

Thanks for your reply and discussion!


[Bug] Do not fail if a source does not exist

If a source does not exist anymore it is impossible to do anything with mangas you have in your library, would be better to atleast display what information is currently available and will allow for deletion/transfer of said manga

Closed with #12


conf to record immediate deps only, no transitive

We need this in our company b/c we use artifactory to capture "builds" of a particular pom that enumerates versions of various other internal projects as dependencies. We need to be able to grab this list from the artifactory builds API without the transitive dependencies of those projects being included.

maybe @eyalbe4 can review this one?

@tavin - this one has been waiting for a long time. My apologies for this!
I think that the best approach would be to add an indication in the build-info JSON,  for each dependency, whether is a direct or transitive dependency. We can perhaps add a boolean named direct for each dependency.
Please let me know what you think.

@eyalbe4 yes, that makes sense! or maybe transitive: false instead of direct: true. either way it sounds like a good solution.

@eyalbe4 is there something I can follow in an issue tracker for this? so I can close my PR.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@tavin,
This request hasn't been planned yet. Feel free to open a GitHub issue for this request and close this PR. We'll maek sure to update or link this issue when work on this starts.

Resolved by deciding to abandon usage of Artifactory "builds" feature.


HA history graph not loading/working

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (`HA 0.44.0):
up to date for unraid
Python release (python3-3.5.2-x86_64-1.tgz):
up to date for unraid
Component/platform:
unraid  6.3.3
Description of problem:
I seem to be haveing a issue were the history wont load in the sensor window and the history page!

This is a fresh docker install

I have the same issue on my iPad chrome, however it works fine on my desktop chrome

same issue as @wanglingsong, always loading gif on phone chrome, works on desktop chrome

I figured it out that the graphic library used by the front is blocked by the firewall of my country... with a VPN , everything gets smooth.

Since we now use chartjs instead of google charts, can you close this issue ?