Disable ui-grid cell edit on the fly.

hi, is there a way to disable/enable cell edit of the grid. for example i have a master-detail form screen. when user wants to analyze a record, i disable all controls of the form with ng-disabled. but i could not prevent editing the grid. i tried "cellEditableCondition" option. But, i runs only when grid is loading. it would be nice if grid have an option like "disableEdit" and accepts a scope variable. when i open my form in edit mode, grid would be editable, and when in view mode grid would be disabled.

I think you can do this on the columnDefs.

thank you for response. yes i tried it on columnDefs but it works only when thr form loading. after that i can not re enable (or disable) the grid. when the form first loaded the grid is in not-editable mode. (cellEditableCondition = false) there is an edit button on the form screen. when edit button clicked i want to make the grid editable (cellEditableCondition = true). i used a scope variable such as $scope.formProperties.isEditing but it didnt worked.

On the columnDef, you want to use enableCellEdit: http://ui-grid.info/docs/#/tutorial/201_editable
I think this is able to be dynamically changed, you may need to call notifyDataChange to make the grid notice that you've changed it.

i tried notifyDataChanged but not worked.
  //on grid initialization i disable cell edit.
  $scope.EntityDetailGrid.enableCellEdit = false;

  //then when i click on update button i set enableCellEdit and call notifyDataChange
  $scope.UpdateDetail = function () {
        $scope.entityProperties.pageProperties.isView = false;
        $scope.EntityDetailGrid.enableCellEdit = $scope.entityProperties.pageProperties.isView;
        $scope.EntityDetailGrid.currentScope.gridApi.core.notifyDataChange($scope.EntityDetailGrid.currentScope.gridApi.grid, uiGridConstants.dataChange.ALL);
    };

what am i doing wrong?
by the way, i found a plunker about a sample similar to my problem. he/she used notifyDataChange function and it isnt working too.
he/she says, found a solution for his/her problem but its sample is not working.
this is the thread about notifyDataChanged:
https://github.com/angular-ui/ng-grid/issues/2598
and this is the plunker:
http://plnkr.co/edit/AzyY6zfB39jFdWl0XhiZ?p=preview
when you click on the item on column menu of Name column (Toggle Color) it must be clear colors and click againg, it must set colors back, but colors not clearing.

enableCellEdit gets set on the columnDef, not on the gridOptions.  Check the tutorial I provided a link to.

hi paul, thank you for your help. i did what you said but still not working. here is what i have done.
first if you look $scope.EntityDetailGrid.columnDefs[0].enableCellEdit it is false..

i set it to "true" and then call notify data change.

i tried uiGridConstants.dataChange.EDIT, uiGridConstants.dataChange.ALL, uiGridConstants.dataChange.COLUMN but nothing happened.

Try this: http://plnkr.co/edit/xit2sdognj9Z01DpFU5N?p=preview
Looking at the code base, I don't think colDef.enableCellEdit is dynamic - it looks to be evaluated once at startup.

thank you so much paul. that was what i want. thank you for your help.

My project uses View-Controller-Model.
In my controller:
function MyController(scope, filter, uiGridConstants)
{
var vm = this;
scope.edit = false;
scope.canEdit = function(){
return scope.edit;
}
    scope.gridOptions = {
        enableSorting: true,
        columnDefs: [
            { field: 'firstName', displayName: "First Name", width: 220, cellEditableCondition : scope.canEdit },
            { field: 'company', cellEditableCondition : scope.canEdit}
        ],
        onRegisterApi: function( gridApi ) {
            scope.gridApi = gridApi;
            scope.gridApi.core.on.sortChanged(scope, function( grid, sort ) {
            scope.gridApi.core.notifyDataChange(uiGridConstants.dataChange.COLUMN );
            })
        },
        data: vm.prop.myData
    };

}
It works fine if I use scope.  However, if I change all scope to vm, the cellEditableCondition stops working.  It means I still have the table display all the data, but I can't turn on/off edit mode.

@tandvu this issue is already closed, furthermore your problem is quite different from the original one. I suggest you to ask this kind of question on a q&a website like Stack Overflow. Remember to tag your question with angular-ui-grid

I have a grid which have multi-select checkbox input field [on clicking input field, i get a dropdown values and after selecting , the value is stored ], I have a edit icon on the right side.
This is CellTemplate:
When the page loads , all the fields are in non-editable mode [page-load_noneditable.png] and when I clicked on edit icon the fields are in edit mode [enablecelledit = true]. This is []
This is enableCellTemplate
In the edit mode when I click on the multidropdown field and select one of the values from the options , that values gets displayed in the field[editable.png]. This is different template []
After this, when I click plus (+) icon to save the edited changes ,  my CellTemplates get rendered for all the fields except the multi-dropdown field. It is still in the edit mode and shows the values.
I have attached some screenshots for reference.


Update scala-library to 2.13.12

About this PR
📦 Updates org.scala-lang:scala-library from 2.13.10 to 2.13.12
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala-library" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-lang", artifactId = "scala-library" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Error is
[error] /home/runner/work/kafka4s/kafka4s/core/src/main/scala/com/banno/kafka/Topics.scala:139:5: match may not be exhaustive.
[error] It would fail on the following input: Impl()
[error]     topics match {
[error]     ^
[error] one error found

I vaguely remember this being hard to fix in a binary compatible way.  Maybe this is our opportunity.  I'll take another look.


🛠 CHORE: Better organise esbuild plugins

Which Cloudflare product(s) does this pertain to?
Wrangler core
What version(s) of the tool(s) are you using?
3.63.1
What version of Node are you using?
18.20.0
What operating system and version are you using?
MacOS Sonoma 14.4.1
Describe the Bug
wrangler uses a bunch of esbuild plugins for bundling & building both Workers proper and Workers for Pages projects. These plugins are spread all over the place, and tend to lack descriptions abt what it is that they do. Furthermore, these plugins tend to be added cumulatively by different internal APIs, at different points in time in the API invocation chain. This makes them

hard to track down
hard to reason abt
hard to understand which plugin was added where and by which API
hard to get an overview of which plugins are used for wrangler proper, and which for wrangler pages

It would be great if we could better organise these plugins in our codebase, in order to gain more insight into what is actually "out there" 🌌, what is used where and for what, and just do some spring cleaning overall :meouw-wow:
Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
No response

@CarmenPopoviciu having a look now these seem to all be in either /deployment-bundle/esbuild-plugins, plus one in pages/functions/buildWorker.ts
Has this been dealt with already, have i missed a bunch of plugins or did you have some other organisation in mind?

Seems like this is mostly an issue with how Pages organises its esbuild plugins. See here and here for example, where some plugins are declared inline. IMO it'd be tidier to extract those under smth like /pages/esbuild-plugins like wrangler proper does in https://github.com/cloudflare/workers-sdk/tree/main/packages/wrangler/src/deployment-bundle/esbuild-plugins


The first method for uploading multipart form data doesn't work

ref: https://github.com/canton7/RestEase/issues/38
When I try the Wrapping other methods technic, and use WireMock.Net to check the request, the request I got had no body content and the request URL is something like:
http://localhost:52099/api/test1?content=System.Net.Http.MultipartFormDataContent

I think the body serializer did not work properly.
The 2nd method Using IRequester directly worked.

Can you post your code that you tried for for the Wrapping other methods? It looks like your body was interpreted as query data rather than a request body, so you probably forgot [Body]

Yes, I just found out I need to add the [Body] attribute to the parameter. I did not add in the first place because the document did not have it. So I guess you forgot it too. :)

Right you are! Opened an issue to fix that.

Nice that you use WireMock.Net to test ;-)


upgrade hive

https://github.com/open-cluster-management/backlog/issues/9948

/retest

/retest

/assign @qiujian16 @zhiweiyin318

do we also need to update the CRD related with Hive in deploy dir?

/lgtm


Bugs in the simulation code

I notice that the simulation code is not compatible with the current pyrirgen.

In tencent_challenge_rirgenerator.py#L75, it calls the function pyrirgen.generateRir, but this API has been refactored to pyrirgen.rir_generator since this commit in phecda-xu/RIR-Generator

Could you update it and also double-check the scripts?

I found the reason. I installed pyrirgen by following the link recommended in https://github.com/ConferencingSpeech/ConferencingSpeech2021/blob/master/ReadMe.md#requirements.
But the simulation code is not built based on the latest version of https://github.com/phecda-xu/RIR-Generator.
So the solution is to directly use the compiled library pyrirgen.cpython-37m-x86_64-linux-gnu.so:
cd simulation
python tencent_challenge_rirgenerator.py

I found the reason. I installed pyrirgen by following the link recommended in https://github.com/ConferencingSpeech/ConferencingSpeech2021/blob/master/ReadMe.md#requirements.
But the simulation code is not built based on the latest version of https://github.com/phecda-xu/RIR-Generator.
So the solution is to directly use the compiled library pyrirgen.cpython-37m-x86_64-linux-gnu.so:
cd simulation
python tencent_challenge_rirgenerator.py

I also found it Wangyou @Emrys365 . But I directly install the pyrirgen from the https://github.com/Marvin182/rir-generator, which solved it.

I found the reason. I installed pyrirgen by following the link recommended in https://github.com/ConferencingSpeech/ConferencingSpeech2021/blob/master/ReadMe.md#requirements.
But the simulation code is not built based on the latest version of https://github.com/phecda-xu/RIR-Generator.
So the solution is to directly use the compiled library pyrirgen.cpython-37m-x86_64-linux-gnu.so:
cd simulation
python tencent_challenge_rirgenerator.py

May I ask how to use the compiled library "pyrirgen.cpython-37m-x86_64-linux-gnu.so"? Thanks in advance.

May I ask how to use the compiled library "pyrirgen.cpython-37m-x86_64-linux-gnu.so"? Thanks in advance.

Sorry for my late reply. I remember it was simply:

Just add the directory of pyrirgen.cpython-37m-x86_64-linux-gnu.so to $PATH

export LD_LIBRARY_PATH="/path/to/ConferencingSpeech2021/simulation":$LD_LIBRARY_PATH
cd "/path/to/ConferencingSpeech2021/simulation"
python ./challenge_rirgenerator.py


[Unix] Move all ELF SDK runtime libraries into their own architecture-specific directories

This is needed for all platforms that don't have multi-architecture libraries like Darwin.
Resolves #63645
I built this with the Feb. 9 source snapshot natively on my Android phone and saw no regressions in the compiler validation suite. I couldn't test the bootstrapping changes on Android because of #60272, so I tried to build a more recent snapshot on linux x86_64 without this pull and that wouldn't build either. I didn't want to look into that issue with bootstrapping the compiler on linux, so I left it.
This pull will require additional small pulls for the corelibs and some SPM products, which I will submit next. In the meantime, let's see if this passes the compiler validation suite first. I've also submitted the swift-driver equivalent, apple/swift-driver#1294.
@Azoy, would you trigger the CI for me?

@al45tair, I see you're up, would you run the CI on this?
@stevapple and @keith, I'd like to get this in before the 5.9 branch in a couple months, appreciate your input.

@swift-ci please test

@buttaface plz ask for CI access now 😛 . I think the value you'd get from having it outweighs the very slim security concern

I +1 the idea for sure

Alright, only one linux-only test from the compiler validation suite failing and macOS/Windows CIs essentially passing (late mac test failure is unrelated, other mac CI runs failed with that same test), good sign that this only affects the Unix toolchain. I will get this test fixed and submit the remaining six small ELF rpath change pulls to the corelibs for the runtime library directory next, so this passes the linux CI.

I've submitted all the smaller pulls for other Swift repos, with which I was able to build a full Swift toolchain natively on Android with these runtime libraries moved to an architecture-specific directory.
@keith, if you would run the CI with these seven pulls applied, let's see if it passes:
apple/swift-corelibs-libdispatch#780
apple/swift-corelibs-foundation#4709
apple/swift-corelibs-xctest#430
apple/swift-llbuild#868
apple/swift-package-manager#6179
apple/swift-driver#1294
apple/sourcekit-lsp#717

@MaxDesiatov, mind running the CI on all the pulls listed in the last comment together?
These pulls affect all non-Darwin platforms, so please test them with WASM and let me know if they work for you. Same for @3405691582 with OpenBSD and @mhjacobson with FreeBSD, try them out and let me know if I missed anything.

Would be good to get input from those packaging for linux also: @tachoknight, @soloturn, @Bo98, @stephank, if any of you are building Swift trunk too, please apply these pulls and test them out.
@kateinoigakukun, let me know if you have any problems with wasm, which I rolled into this pull as we discussed before, and please run the CI here, including the 7 pulls listed above.

@egorzhdan, need another CI run here, could you trigger it again, as done with all 8 pulls a couple days ago?

Alright, passed mac CI and only one integration test failure on linux CI, which I will update next. Single test failure on Windows CI is probably spurious, since essentially the same pull passed on Windows a couple days ago.
@compnerd and @gottesmm, this is ready for review, let me know what you think.

Added a fix for the linux integration test, one last CI run with all 9 of these pulls and it should pass:
https://github.com/apple/swift-corelibs-libdispatch/pull/780
https://github.com/apple/swift-corelibs-foundation/pull/4709
https://github.com/apple/swift-corelibs-xctest/pull/430
https://github.com/apple/swift-llbuild/pull/868
https://github.com/apple/swift-package-manager/pull/6179
https://github.com/apple/swift-driver/pull/1294
https://github.com/apple/sourcekit-lsp/pull/717
apple/swift-integration-tests#113

@0xTim, @ktoso, if you would get SSWG people to try this out, would be good to get more people testing this.

@buttaface the build is still failing after adding https://github.com/apple/swift-integration-tests/pull/113
https://ci.swiftlang.xyz/job/swift-main-ubuntu-jammy/329/console. This a different failure from before indicating there may be a problem with the patch.
Apart from this test failure I am not seeing any other problems. I have uploaded  a .deb package for `ubuntu/22.04/jammy to a test repo.
You can install and test from here - swiftlang_5.9-1.0.0-dev-ubuntu-jammy_arm64.deb

@futurejones, thanks for trying this out. That updated integration test is correctly flagging that I missed modifying the runpath for the REPL and I also see that I missed Docc and liblldb.so in your toolchain. I will add those two pulls next.

@futurejones, added apple/llvm-project#6383 and apple/swift-docc#500 and updated the swift-integration-tests and swift-driver pulls, including adding more rpath integration tests. If you want to update those four pulls on your tester, should pass now.

@egorzhdan, would you run the CI with these 10 additional pulls? That should finally pass the CI:
https://github.com/apple/llvm-project/pull/6383
https://github.com/apple/swift-corelibs-libdispatch/pull/780
https://github.com/apple/swift-corelibs-foundation/pull/4709
https://github.com/apple/swift-corelibs-xctest/pull/430
https://github.com/apple/swift-llbuild/pull/868
https://github.com/apple/swift-package-manager/pull/6179
https://github.com/apple/swift-driver/pull/1294
https://github.com/apple/sourcekit-lsp/pull/717
https://github.com/apple/swift-docc/pull/500
https://github.com/apple/swift-integration-tests/pull/113

@compnerd, these pulls have passed CI, mind reviewing them?

@egorzhdan, one last request: please build the toolchain for linux with these 11 pulls, that would be good for some more testing locally.

https://github.com/apple/llvm-project/pull/6383
https://github.com/apple/swift-corelibs-libdispatch/pull/780
https://github.com/apple/swift-corelibs-foundation/pull/4709
https://github.com/apple/swift-corelibs-xctest/pull/430
https://github.com/apple/swift-llbuild/pull/868
https://github.com/apple/swift-package-manager/pull/6179
https://github.com/apple/swift-driver/pull/1294
https://github.com/apple/sourcekit-lsp/pull/717
https://github.com/apple/swift-docc/pull/500
https://github.com/apple/swift-integration-tests/pull/113
@swift-ci build toolchain

Linux toolchain built from these pulls is up on download.swift.org, works well in my testing so far. Please download and try it out yourself.

@al45tair, it's been a week, any consensus reached on this? I'd like to get this in before the 5.9 branch on Monday, which is why I'm asking.
Is there some concrete case this approach doesn't handle or is it more that some are worried about unknown issues that may pop up? If the latter, I think the best way to flush those out is to merge this earlier, so we have more time to flush those out, especially since these pulls passed the full CI and produced a linux toolchain that works well.

Alright, thanks for approving.
@shahmishal, all 11 pulls will have to be merged together, 6 have already been approved. Would you get these in now, or is there anything else to be done?

Went through and checked all 11 pulls: two had to be updated for merge conflicts so I fixed and pushed those, while the rest rebased fine.
I think one last CI run with all 11 pulls and we can get this in.

@egorzhdan, one last CI run with these 10 pulls should verify that this can go in now:
https://github.com/apple/llvm-project/pull/6383
https://github.com/apple/swift-corelibs-libdispatch/pull/780
https://github.com/apple/swift-corelibs-foundation/pull/4709
https://github.com/apple/swift-corelibs-xctest/pull/430
https://github.com/apple/swift-llbuild/pull/868
https://github.com/apple/swift-package-manager/pull/6179
https://github.com/apple/swift-driver/pull/1294
https://github.com/apple/sourcekit-lsp/pull/717
https://github.com/apple/swift-docc/pull/500
https://github.com/apple/swift-integration-tests/pull/113

https://github.com/apple/llvm-project/pull/6383
https://github.com/apple/swift-corelibs-libdispatch/pull/780
https://github.com/apple/swift-corelibs-foundation/pull/4709
https://github.com/apple/swift-corelibs-xctest/pull/430
https://github.com/apple/swift-llbuild/pull/868
https://github.com/apple/swift-package-manager/pull/6179
https://github.com/apple/swift-driver/pull/1294
https://github.com/apple/sourcekit-lsp/pull/717
https://github.com/apple/swift-docc/pull/500
https://github.com/apple/swift-integration-tests/pull/113
@swift-ci please smoke test

Linux and mac CI passed, single test failure on Windows is unrelated and was failing on all other pulls' Windows CI runs this morning.
This is ready to go in, just need someone to merge.

@egorzhdan, now that passing the Windows CI is required, please rerun the 11 pulls on the Windows CI alone, should pass as before.

@bnbarham, would you trigger one last CI run with these 10 pulls only on the Windows CI?
https://github.com/apple/llvm-project/pull/6383
https://github.com/apple/swift-corelibs-libdispatch/pull/780
https://github.com/apple/swift-corelibs-foundation/pull/4709
https://github.com/apple/swift-corelibs-xctest/pull/430
https://github.com/apple/swift-llbuild/pull/868
https://github.com/apple/swift-package-manager/pull/6179
https://github.com/apple/swift-driver/pull/1294
https://github.com/apple/sourcekit-lsp/pull/717
https://github.com/apple/swift-docc/pull/500
https://github.com/apple/swift-integration-tests/pull/113
@egorzhdan
Collaborator
egorzhdan commented

https://github.com/apple/llvm-project/pull/6383
https://github.com/apple/swift-corelibs-libdispatch/pull/780
https://github.com/apple/swift-corelibs-foundation/pull/4709
https://github.com/apple/swift-corelibs-xctest/pull/430
https://github.com/apple/swift-llbuild/pull/868
https://github.com/apple/swift-package-manager/pull/6179
https://github.com/apple/swift-driver/pull/1294
https://github.com/apple/sourcekit-lsp/pull/717
https://github.com/apple/swift-docc/pull/500
https://github.com/apple/swift-integration-tests/pull/113
@swift-ci please test Windows platform

@shahmishal, these 11 pulls can be merged now. I don't know if that requires special privileges that only you have to merge multiple pulls together, or if any committer can do that, which is why I'm asking you.

Ping @al45tair, @shahmishal, can these 11 pulls go in before the branch?

Interesting, so Apple is also going to move from macosx/, ios/, and so on to runtime directories like lib/swift/arm64-apple-darwin11.1.0/? That is a more substantial change than this one, particularly if you want to maintain backwards compatibility with the old directory naming for a few releases too.
I think it would be a good idea to include the version numbering too in the triple-named directories, as one could distribute SDKs for different versioned triples like on macOS, Android, and the BSDs. Obviously, somebody at Apple would have to implement this larger change, but it would benefit all platforms.
In the meantime, I don't see any problem with getting this in for now, as it creates no such new directories, and merely modifies around a dozen lines in the Swift compiler to reuse the existing architecture-specific directories. Whenever someone at Apple implements the triple-named directories, we can shift everything over to that.

Interesting, so Apple is also going to move from macosx/, ios/, and so on to runtime directories like lib/swift/arm64-apple-darwin11.1.0/?

Our directory layout doesn't look like that. The runtimes on the various platforms are all installed in /usr/lib/swift (no architecture specifics), which we can do because Mach-O supports fat binaries and we don't install libraries in that location for compile-time linking. When we're building programs, we don't use the files in that directory — rather, we use the files from the SDKs in Xcode.

In the meantime, I don't see any problem with getting this in for now, as it creates no such new directories, and merely modifies around a dozen lines in the Swift compiler to reuse the existing architecture-specific directories. Whenever someone at Apple implements the triple-named directories, we can shift everything over to that.

I think the suggestion is that these PRs should be updated to use triples before they are merged.

When we're building programs, we don't use the files in that directory — rather, we use the files from the SDKs in Xcode.

Yes, I meant the SDK runtime directories from Xcode that contain those dylibs, not the system runtime libraries in /usr/lib/swift/.

I think the suggestion is that these PRs should be updated to use triples before they are merged.

That would be done in ToolChain::getResourceDirPath() here, which currently invokes swift::getPlatformNameForTriple() to get the OS name, and modifying it would change it for every OS, including Apple platforms.
Of course, we could put in some platform-specific logic to only shift the Unix toolchain over to triple-named module directories and see how that works on Unix first, before shifting other platforms to triple-named resource directories.
If whoever is in charge of this is willing to commit to shifting Unix alone to triple-named directories, I'm willing to spend a couple days changing these pull to implement that, just let me know.

Yes, I meant the SDK runtime directories from Xcode that contain those dylibs, not the system runtime libraries in /usr/lib/swift/.

FWIW, they're in <sdkroot>/usr/lib/swift there too. (Actually these days you'll find .tbd files rather than .dylibs per se, but same deal.)
The only time they're in a directory with a platform name is in the build directory.
@compnerd Windows also has a similar SDK-based approach, I believe?

FWIW, they're in <sdkroot>/usr/lib/swift there too. (Actually these days you'll find .tbd files rather than .dylibs per se, but same deal.)

The only time they're in a directory with a platform name is in the build directory.

So you're saying all the different SDK dylibs for different Darwin platforms are placed directly in <sdkroot>/usr/lib/swift/, not in <sdkroot>/usr/lib/swift/macosx/ and so on? I can only go by what the OSS Swift compiler is doing, and as my source links show, the OSS compiler looks in platform-specific directories for those runtime libraries on all platforms, including macOS and Windows.

So you're saying all the different SDK dylibs for different Darwin platforms are placed directly in /usr/lib/swift/, not in /usr/lib/swift/macosx/ and so on?

Yes. If you look at one of the SDKs, you'll see that the .tbd files are in <sdkroot>/usr/lib/swift, as I said. There wouldn't be much point in putting things in <macOS SDK>/usr/lib/swift/macosx/ or <iOS SDK>/usr/lib/swift/ios/, for example, and indeed we don't.
OTOH I don't know exactly what Windows does (@compnerd?), but I believe it has an SDK-like mechanism and in any case linking on Windows requires that you link against the .lib import libraries as you can't link .dlls directly.

When cross-compiling to another platform, you use the tbd file in the SDK to link,

OK, so switching to triples wouldn't affect Darwin platforms then, but my question remains, are we going to switch all other platforms to triple-named module directories, like Windows and wasm? If just Unix platforms for now, I'll implement it if it's pre-approved in principle (obviously the work can still be held up for implementation problems or other issues, just not because somebody changed their mind above moving to triples).

I do have some questions about using triple. The first problem is by doing so we’re diverging with Clang, while Clang libraries are available to Swift through /usr/lib/swift/clang. So I doubt that, if Clang doesn’t go in the same direction, simply changing this for Swift cannot have so many benefits.
Another problem is, if we still use strict triple matching in Swift, associating libraries with triples will make bigger troubles. eg., now we have x86_64-unknown-windows-msvc as default, but what about x86_64-pc-windows-msvc, which is Clang’s default? What about the x86_64-windows shorthand? What about versioned triple like x86_64-pc-windows-msvc19 and even x86_64-pc-windows-msvc19.0.0-elf? We need to decide concrete rules for triple parsing, transforming, and matching first.

I do have some questions about using triple. The first problem is by doing so we’re diverging with Clang, while Clang libraries are available to Swift through /usr/lib/swift/clang. So I doubt that, if Clang doesn’t go in the same direction, simply changing this for Swift cannot have so many benefits.

If something somewhere is done that's unsuitable for us and prevents us from supporting more platforms in a clean way, it doesn't mean we have to perpetuate that decision and reimplement in our build system without ever questioning it.

Another problem is, if we still use strict triple matching in Swift, associating libraries with triples will make bigger troubles. eg., now we have x86_64-unknown-windows-msvc as default, but what about x86_64-pc-windows-msvc, which is Clang’s default? What about the x86_64-windows shorthand? What about versioned triple like x86_64-pc-windows-msvc19 and even x86_64-pc-windows-msvc19.0.0-elf? We need to decide concrete rules for triple parsing, transforming, and matching first.

The amount of triples Swift supports is fixed and these triples are known upfront and encoded in the build system. A random triple appearing out of the blue in /usr/lib/swift is not something we support right now, nor it is something that blocks a transition to triple-base layout in the future.

I do have some questions about using triple. The first problem is by doing so we’re diverging with Clang, while Clang libraries are available to Swift through /usr/lib/swift/clang. So I doubt that, if Clang doesn’t go in the same direction, simply changing this for Swift cannot have so many benefits.

So first, we've already diverged from Clang/normal runtime layouts. The expected place for your libraries is generally /usr/lib or /usr/local/lib (or whatever the distro sets LD_LIBRARY_PATH to) on a unix-y platform. Shoving a copy of the clang libraries under /usr/lib/swift/clang instead is weird, though works in the narrow sense for providing the clang runtime/intrinsic headers aligned with the clang in the clang-importer. There are exceptions on where things go of course (/opt/rh/devtoolset-11/root/ on some redhats), but even those have the normal usr/lib/usr/local/lib structure under that root directory. Windows is another story, which I will defer to @compnerd for details, but from my understanding, we aren't doing ourselves any favors over there either. Ideally, I would like us to end up in a place that is "normal" for the thing we're on. If I'm installing a swift runtime package on my ubuntu device for my ubuntu device so I can run Swift programs, libswiftCore.so should eventually live under /usr/lib like the other language runtimes. The machine you're at isn't going to magically change triples. Note that this aligns with macOS, with the exception that the dylib actually ends up living in the shared cache, the lookup path is /usr/lib/libswiftCore.dylib. Cross-compiling is where things get a little trickier, but I'll get to that in a second.
Second, it doesn't actually diverge that far from some uses of clang, and adding a triple certainly doesn't diverge from gcc where the cross-compiling toolchain is built for a specific triple. Looking at the Android NDK layout, you have android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/, containing
./aarch64-linux-android
./arm-linux-androideabi
./x86_64-linux-android
./i686-linux-android

Then inside of those you have your NDK-specific, non-ABI-stable libraries that don't ship on a given Android API-level (libstdc++.a, libc++_static.a, libc++abi.a, etc...), then directories for each Android API-level
The android NDKs these days ship with clang, which means that they do work with that structure.
So the question is, are we building stand-alone cross-compiling toolchains + sysroots, or are we augmenting an existing toolchain + sysroot? If we're augmenting, staying consistent with the layouts of the toolchain we're augmenting. For android, this means using a full triple. For the gcc toolchains I've worked with, this also means full triples. Going back to android for a sec, I think the only piece we're missing is that we do link the C++ stdlib for parts of the Swift runtime, so that unfortunately ties the built library to a specific NDK version because the C++ runtime symbols are versioned on the NDK, which isn't tracked in this scheme. I think technically we should be tracking the API level and NDK version, but I don't know how we would want to do that for this case. It's sort of specialized. Maybe the answer is that we have an augmented NDK with the Swift pieces? Then we don't have to worry about the different ABIs of each NDK. I don't know.
If we're building a standalone toolchain(s), we have a bit more flexibility in the layout. The Xcode SDKs layout is pretty deep, but works reasonably well for preventing collisions between platforms and triples. You have the platform.sdk and then we have fat binaries and fat tbds, but if we didn't there would be a full triple for each slice, as we see with the swiftmodule directory structure. A triple alone is unfortunately not sufficient for preventing all of the collisions. x86_64-linux-gnu could either be built for Ubuntu or Fedora and things won't necessarily run if you mix them (different runtime library versions, ABI differences, etc...). You'd probably want something like Ubuntu.sdk/usr/lib/x86_64-linux-gnu/libswiftCore.so and Fedora.sdk/usr/lib/x86_64-linux-gnu/libswiftCore.so, for example. Then you could keep the swiftmodules associated with each platform in each SDK as well. e.g. Fedora.sdk/usr/lib/swift/Swift.swiftmodule/x86_64-linux-gnu.swiftmodule.
I haven't had time to fully formalize, propose, or implement all of this, but I think this ends up covering most of our requirements, with the exception of version numbers.

Correction, for Ubuntu and Debian based things Ubuntu.sdk/usr/lib/x86_64-linux-gnu/libswiftCore.so is not the right path. We'd want Ubuntu.sdk/usr/x86_64-linux-gnu/lib/... and Ubuntu.sdk/usr/x86_64-linux-gnu/include/... to be consistent.

https://wiki.debian.org/CrossBuildPackagingGuidelines.

Ideally, I would like us to end up in a place that is "normal" for the thing we're on. If I'm installing a swift runtime package on my ubuntu device for my ubuntu device so I can run Swift programs, libswiftCore.so should eventually live under /usr/lib like the other language runtimes.

Interesting, I'm looking into adding separate Swift runtime library packages on Android, which is why I recently rolled these patches into the upcoming 5.8 release, so that one <sysroot>/usr/lib/swift/android/ resource directory could contain runtime libraries for multiple architectures, allowing cross-compilation too. I will instead look into installing the native Swift runtime libraries directly into <sysroot>/usr/lib/ now.

Looking at the Android NDK layout, you have android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/, containing

./aarch64-linux-android
./arm-linux-androideabi
./x86_64-linux-android
./i686-linux-android

The Termux app that I package Swift for uses a similar layout for cross-compilation, ie <sysroot>/usr/arm-linux-androideabi/lib and so on, I may be able to install the Swift cross-compilation libraries there instead of in <sysroot>/usr/lib/swift/android/ as I was planning.
Of course, these install path changes are only relevant for "system" installs, not for standalone toolchains, though they could one day be upstreamed as a separate build option for system installers to use.
Given the various issues you point out for linux triples, I'm not going to implement that either, as I suggested a couple days ago, as I don't even use Swift on linux, whereas these 11 pulls I proposed were just reusing the existing layout so they worked on all currently supported non-Darwin platforms.
What I can do is rework these pulls to only use triple-named directories for Android, and we can use that to test out such a move, before devs on other platforms like linux, Windows, and Wasm submit their own separate pulls when they are ready to move to triples.
One further issue when moving to triples, should I move all 13 files in lib/swift/os/arch/ to lib/swift/triple?
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/Foundation.swiftdoc
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/FoundationXML.swiftmodule
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/FoundationXML.swiftdoc
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/Foundation.swiftmodule
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/Dispatch.swiftmodule
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/Dispatch.swiftdoc
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/glibc.modulemap
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/XCTest.swiftmodule
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/SwiftGlibc.h
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/swiftrt.o
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/FoundationNetworking.swiftdoc
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/XCTest.swiftdoc
swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux/x86_64/FoundationNetworking.swiftmodule

It wouldn't make much sense to put them in lib/swift/aarch64-unknown-linux-android24/aarch64/.
@etcwilde, let me know what you think.

Closing since the Swift devs apparently want to take a different approach, but it has not been decided what that approach will be. I simply moved these libraries to different locations for my Android SDK and native toolchain, which required further configuration since the current defaults that I tried to change with these pulls do not allow multi-arch setups.
Whenever the Swift devs figure out how you want to implement this instead, I will check your work on Android.


add Darwin support for bind mount of ssh-agent socket

revised
what
Docker for Mac v <IP_ADDRESS> allows forwarding ssh-agent and docker Unix sockets to containers, allowing people to access the ssh-agent and docker agents on their Mac host from inside the Docker container. Previously, Geodesic automatically forwarded the SSH_AUTH_SOCK and optionally forwarded the Docker agent socket (enabled by export WITH_DOCKER=true) only on Linux hosts. With this release, that behavior is extended to Mac OS hosts when export GEODESIC_MAC_FORWARD_SOCKET=true is run before starting Geodesic.
why
Among other things, this allows ssh credentials to be securely stored on the Mac host, taking advantage of the OS X Keychain, and still be used from inside the Docker container, for example to access a private Github or Docker repository.
original
@tamsky  wrote:
Newly available on Docker for Mac (Edge) release.
https://docs.docker.com/docker-for-mac/edge-release-notes/
Someone should test that this doesn't break on non-Edge Docker-for-Mac releases.

Thank you @aknysh for the review, and @nuru for completing this!


Great! do you mind add sample form data and associated button to fetch it!

They are on their way , amazingly I thought of that too!

Done! @houmanhadian, rest now buddy!!


Rich preview scheme container too narrow

The rich preview's scheme container should be wider, like here: http://petstore.swagger.io/

We've decided to remove the white background completely.


Entire type literal is marked as a type

Check out the section of the following file:
https://github.com/leebyron/testcheck-js/blob/55074483905139642bdaeca816b2bb725f77cba9/dist/testcheck.d.ts#L113-L418
Right now even comments within the type literal are marked as types.

Closing this as Microsoft/vscode#13046 should fix this.


[Translation] Update Ukrainian translations

It will be more convenient to use some Localization as a service.
Non-technical translators can easily provide translations on some web-based UI and there will be one source of truth for all the platforms.
There is a LaaS provided by i18next authors: https://locize.com/
For now I've just copy-pasted jsons from here into flutter app repo.

@koral-- I agree. They are in state of flux however, plus I suspect there will be some disparity anyway thanks to the mobile nature and different audience of the frontend & mobile apps. But that's definitely something we should think of in the future. Calling @unjello to make a note, as this is more like architecture / infrastructure task, which probably will also touch backend.


Issue with Expanding Language Value Set on tx.fhir.org

Dear HL7 Team,
I am encountering an issue with the tx.fhir.org FHIR terminology server while trying to validate a C-CDA document. I am using the latest validator_cli.jar file, which I downloaded from https://validator.fhir.org/, and I am performing validations locally because the online validator at https://validator.fhir.org/ has been non-operational for several days.
The specific error I receive is as follows:
“The value provided ('en') was not found in the value set 'Language codes with language and optionally a region modifier' (http://hl7.org/fhir/us/core/ValueSet/simple-language|7.0.0). Error from http://tx.fhir.org/r4: Exception expanding value set in order to infer system: Language valuesets cannot be expanded as they are based on a grammar.”
According to the US Core Simple Language ValueSet, the “en” code is valid for two-character English codes. However, the terminology server seems to be struggling with the expansion of grammar-based value sets, leading to this validation error.
Could you please look into this issue or guide me on how to fix it?
Thank you for your time and assistance.
Best regards,
Krasimir Kolarov
QA
Object Systems International

Are you still getting this error? I'm pretty sure it's something that I actually fixed a few days before you posted this issue

Hi Grahame,
Thank you for your response!
When I validate the CCDA document online at https://validator.fhir.org/,
the language error does not appear. Thank you for addressing that!
However, after downloading the latest CLI file from (Validator GUI
(fhir.org) https://validator.fhir.org/) and running the validation
locally, I still encounter the language error:
"The value provided ('en') was not found in the value set 'Language codes
with language and optionally a region modifier' (
http://hl7.org/fhir/us/core/ValueSet/simple-language|7.0.0), and a code is
required from this value set (error message = Error from
http://tx.fhir.org/r4: Exception expanding value set in order to infer
system: Language valuesets cannot be expanded as they are based on a
grammar)"
Could you please address this issue in the latest CLI file as well?
Kind regards,
Krasi
QA
Object Systems International
On Thu, Oct 17, 2024 at 2:13 AM Grahame Grieve @.***>
wrote:

Are you still getting this error? I'm pretty sure it's something that I
actually fixed a few days before you posted this issue
—
Reply to this email directly, view it on GitHub
https://github.com/hapifhir/org.hl7.fhir.validator-wrapper/issues/189#issuecomment-2418121757,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A25V3VBYK3PKPSIFQG3RP53Z33XJPAVCNFSM6AAAAABPY3TC5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJYGEZDCNZVG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

it's the same code. Probably you have a caching issue - run it again with -clear-tx-cache

Thank you for the suggestion! I will work with a developer on this.
Could you please also look into the following issues:
FHIR Validation tool Version 6.3.27 (Git# 102e7552832d). Built
2024-09-22T17:53:20.171Z (24 days old)
Error fetching https://packages.fhir.org/hl7.cda.us.ccda: Not Found
On Thu, Oct 17, 2024 at 7:03 AM Grahame Grieve @.***>
wrote:

it's the same code. Probably you have a caching issue - run it again with
-clear-tx-cache
—
Reply to this email directly, view it on GitHub
https://github.com/hapifhir/org.hl7.fhir.validator-wrapper/issues/189#issuecomment-2418451623,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A25V3VGG2V6SJ2JKZVHJKPLZ34ZJ5AVCNFSM6AAAAABPY3TC5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJYGQ2TCNRSGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

That one won't be easily resolved, and I can't resolve it, but nor does it matter - it's a todo for me to resolve that depends on someone else

No problem, I understand.
Thank you for your responses! Wish you all the best!
On Thu, Oct 17, 2024 at 10:56 AM Grahame Grieve @.***>
wrote:

That one won't be easily resolved, and I can't resolve it, but nor does it
matter - it's a todo for me to resolve that depends on someone else
—
Reply to this email directly, view it on GitHub
https://github.com/hapifhir/org.hl7.fhir.validator-wrapper/issues/189#issuecomment-2418826611,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A25V3VBFBI5DAK6GAOWSLV3Z35URNAVCNFSM6AAAAABPY3TC5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJYHAZDMNRRGE
.
You are receiving this because you authored the thread.Message ID:
@.***>


Chapter 1: eslint 6.5.1 is incompatible with node 10.5.0

error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "^8.10.0 || ^10.13.0 || >=11.10.1". Got "10.5.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
The text says to ignore warnings about upgrading, but this appears to be an error.  Is it?
I will make an attempt to use node version 10.13.0 and will let you know the result

@callahanp Thanks for reporting!
When using Node version 10.5.0 (as currently stated in Chapter 1 of Builder Book), I see the error you describe.
I tested 8-end using the latest Node version that is recommended for most users: 12.14.0. I don't see any issue, so I will update the book to use 12.14.0.


Decode function axiom ensures clause

See also: kframework/k#923

Reviewer checklist

[ ] Test coverage: stack test --coverage
[ ] Public API documentation: stack haddock

Is this what I was supposed to do instead of #1271 ?

No, the plan was always to leave the error in place until someone reported a problem. That just happened much sooner than expected. :sweat_smile: It looks like there is some simplification rule (which we already rely on) from the frontend that uses an ensures clause.


Balance becomes negative when using CLOSURE()->subtract

Not sure if this is only me, but using BedrockEconomyAPI::CLOSURE()->subtract() with bigger amount than the player's balance makes their balance negative, instead of firing InsufficientFundsException.

Just confirmed that even when my balance is negative, I'm able to use /pay and other commands.
Currently on PM 5.8.1

Doesn't happen on latest release.

What data provider were you using?

What data provider were you using?

Sqlite

I've just tested it and it seems like I can't reproduce it, can you try this build

I've just tested it and it seems like I can't reproduce it, can you try this build

Hmm, then it could probably be just me. It's still happening on my end.

Can you send me both your config and database file (players.db) on Discord @cooldogedev


Noticing some wonkiness with rendering

Mod Version:
1.12.2-<IP_ADDRESS>
Forge Version:
<IP_ADDRESS>1
Link to crash log (if applicable):
Description:

Notes: Albedo is installed, not sure if that has any effect on this. Hardcore Darkness is installed too. I also have Zombie Awareness installed.

Disable albedo and see if it disappears. :)  If it does it would be an albedo problem I think.  DS responds to lighting events from albedo so it can do the rendering.  DS doesn't do the rendering.

I can confirm it's albedo.

I can confirm with 100% certainty it's an albedo issue. I'd advise updating against the latest build of it. Removing Hardcore Darkness did not end the issue.

Sorry if I'm bugging you @OreCruncher, but any news on this?

It's an Albedo issue I would think.  DS just supplies light point information to Albedo and it does its's magic.  I am assuming that this is Elucents version of Albedo correct?

It appears an installation with just albedo + dynamic surroundings still causes the issue to an extent.

Forge version used is <IP_ADDRESS>2

I'm getting white squares for the splash particles on waterfalls, unsure if its related but thought I might mention.

Yep.  Noticed the same thing.  While the client is active, disable Albedo, run  the game a little bit, and re-enable.  It usually "fixes" until it goes wonky again.


Fix http outbound to get correct TLS negotiated protocol when "stats" setting exists

Sorry to open a new pull request, because I forgot to do some change in the old one (#73)

Thanks a lot for fixing this issue!

Thank you for your work, but seems it's not necessary to delete line 135; 145-147; 169-171; 277-288, could you please do some adjustments? ("Fix http outbound" is OK

@rprx
The deleted lines are indeed safe to delete. And actually I'm the one who added the original code :)
The ctx within http.Request in L135 is never used in v2ray. And the original https://github.com/v2fly/v2ray-core/blob/cfbb875546e66d448409fbbebd3e9076f2b90c60/proxy/http/client.go (before my last patch) doesn't have it either.
L145-147 and L169-171 have no effect in a client request, according to https://github.com/golang/go/blob/2cd2ff6f564dce5be0c4fb7f06338ff7af3fc9a9/src/net/http/request.go#L128-L133
L277-288 are engaged also only at server side in golang's codebase, which is not the case of an "outbound".

@darhwa
I see, and thanks again for your work.


AttributeError when using HaystackSerializerMixin with a ModelSerializer with only 'exclude' specified

Trying to use a class that extends drf's ModelSerializer with HaystackSerializerMixin caused issues
when some fields on the meta class were omitted.
Here is a minimal example of the issue:
from drf_haystack.serializers import HaystackSerializerMixin
from drf_haystack.viewsets import HaystackViewSet
from rest_framework.serializers import ModelSerializer

class ProjectSerializer(ModelSerializer):
  class Meta:
    model = Project
    exclude = ('last_edit_timestamp', )
    read_only_fields = ('status', 'slug', )

class ProjectSearchSerializer(HaystackSerializerMixin, ProjectSerializer):
  class Meta(ProjectSerializer.Meta):
      field_aliases = {
          'dateCreated': 'date_created',
      }
      search_fields = ('text', 'status', 'category', 'location', 'author', 'date_created', )

class ProjectSearchViewSet(HaystackViewSet):
    index_models = [Project]
    serializer_class = ProjectSearchSerializer

When calling the HaystackViewSet with filters specified in the query parameters, the following error
would occur:
Traceback (most recent call last):
File "/home/dlab/git/project/env/lib/python3.5/site-packages/django/core/handlers/base.py", line 149, in get_response
  response = self.process_exception_by_middleware(e, request)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/django/core/handlers/base.py", line 147, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/lib64/python3.5/contextlib.py", line 30, in inner
  return func(*args, **kwds)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/django/views/decorators/csrf.py", line 58, in wrapped_view
  return view_func(*args, **kwargs)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/rest_framework/viewsets.py", line 83, in view
  return self.dispatch(request, *args, **kwargs)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/rest_framework/views.py", line 477, in dispatch
  response = self.handle_exception(exc)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/rest_framework/views.py", line 437, in handle_exception
  self.raise_uncaught_exception(exc)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/rest_framework/views.py", line 474, in dispatch
  response = handler(request, *args, **kwargs)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/rest_framework/mixins.py", line 40, in list
  queryset = self.filter_queryset(self.get_queryset())
File "/home/dlab/git/project/env/lib/python3.5/site-packages/drf_haystack/generics.py", line 98, in filter_queryset
  queryset = super(HaystackGenericAPIView, self).filter_queryset(queryset)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/rest_framework/generics.py", line 151, in filter_queryset
  queryset = backend().filter_queryset(self.request, queryset, self)
File "/home/dlab/git/project/env/lib/python3.5/site-packages/drf_haystack/filters.py", line 58, in filter_queryset
  applicable_filters, applicable_exclusions = self.build_filters(view, filters=self.get_request_filters(request))
File "/home/dlab/git/project/env/lib/python3.5/site-packages/drf_haystack/filters.py", line 45, in build_filters
  return query_builder.build_query(**(filters if filters else {}))
File "/home/dlab/git/project/env/lib/python3.5/site-packages/drf_haystack/query.py", line 121, in build_query
  fields = self.view.serializer_class.Meta.fields
AttributeError: type object 'Meta' has no attribute 'fields'

I tried to fix the issue with this commit.
It fixed the issue in my project and the drf-haystack tests ran with no failures locally.
I the fix is judged adequate, I can submit a pull request.

I guess you get the error because it seems like you're not using the HaystackSerializer but a ModelSerializer which has a slightly different Meta class. Usually, the HaystackSerializer class is constructed with this Meta class.
This is really not the intended usage for the HaystackSerializerMixin class, so you're likely to encounter more issues down the road. If this is a requested feature case, please feel free to do a proper implementation with tests and submit a PR =)

I see!
I was following this example on reusing a ModelSerializer http://drf-haystack.readthedocs.io/en/latest/10_tips_n_tricks.html#drf_haystack.serializers.HaystackSerializerMixin
So I thought that's how the mixin was meant to be used.

To add to this issue, here is a commit with a new test that reproduces the AttributeError on a HaystackViewSet. I copied the HaystackSerializerMixin and HaystackViewSet code from the serializer tests.
The test tests.test_viewsets.HaystackViewSetTestCaseWithHaystackSerializerMixin.test_viewset_list_with_query_params reproduces the AttributeError.
When applying this fix the test passes. It's quite possible this isn't the best way to fix this particular issue, however (if it is even an issue rather than the result of HaystackSerializerMixin being used in an unintended way).

Thank you lavoiedn.
I had to define field_aliases and exclude on my. Here's my working example:
# contrib
from drf_haystack.serializers import HaystackSerializerMixin
from rest_framework import serializers

# app
from . import models

class ProjectSerializer(
    serializers.ModelSerializer,
):
    class Meta:
        model = models.Project

        fields = [
            'id',
            'title',
            'url',
        ]

class SearchSerializer(
    HaystackSerializerMixin,
    ProjectSerializer,
):
    class Meta(Project.Meta):
        search_fields = [
            'text',
        ]

        field_aliases = {}
        exclude = tuple()


RUM-790 Fix PendingTrace ConcurrentModificationException

What does this PR do?
Add some thread safe guards for PendingTrace, and prevent ConcurrentModificationException.
Additional Notes
Fixes #1570
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Codecov Report

Merging #1623 (c8fe700) into develop (2903002) will increase coverage by 0.16%.
Report is 5 commits behind head on develop.
The diff coverage is 46.15%.

@@             Coverage Diff             @@
##           develop    #1623      +/-   ##
===========================================
+ Coverage    83.57%   83.73%   +0.16%
===========================================
  Files          452      452
  Lines        15652    15656       +4
  Branches      2324     2323       -1
===========================================
+ Hits         13081    13109      +28
+ Misses        1950     1932      -18
+ Partials       621      615       -6

Files Changed
Coverage Δ

...ain/java/com/datadog/opentracing/PendingTrace.java
70.73% <46.15%> (+11.25%)
:arrow_up:

... and 20 files with indirect coverage changes


How to give more than one color?

We need to give different colors every day.

Hi, right now this visualization supports single color heatmaps meaning that intensity of a given color is used to represent a value.
I remember using d3 category20 colors for testing before (http://bl.ocks.org/aaizemberg/78bd3dade9593896a59d) but the result was not as clear a visualization as it is using a single color gradient. In addition, using multiple colors would definitely require a legend to explain what each color means.
What is your use case for using different colors every day?

I would like to show different jobs during the day. Holiday, Work, Off-Work, Leave, Half Day Leave etc. I have species. I have made the following example, but in this example I have a similar need.

Nice! Thanks for providing an example of what you're after 🙂
If I understand correctly the colors represent different type of jobs/projects on each of the days.
As of today, the colors are based on total value for each day regardless of the job/project type.
This functionality would have to be extended to support multiple colors.


Add correlation_id support similar to python powertools

Is your feature request related to a problem? Please describe.
Similar to python version, add support for capturing correlation id https://github.com/awslabs/aws-lambda-powertools-python/pull/321
https://github.com/awslabs/aws-lambda-powertools-python/issues/9
Describe the solution you'd like

Describe alternatives you've considered

Additional context

I believe correlation_id will also help adding feature similar to stop infinite loop middleware


Druid gRPC-json server extension

This is a minimally functional gRPC implementation for Druid. The specific thing this was implemented for was query cancellation. A 0.12 compliant version is used internally in a production environment.

[x] gRPC server creation
[x] Retain json polymorphic api spec
[x] Stand-alone module (designed to be loaded on the brokers only)
[x] Example clients for go and python
[x] Server announcing
[ ] Druid website docs
[ ] Figure out how to handle auth

This is opened as a discussion piece since a question was asked in the dev forum
I didn't want to invest in making the README stuff until people wanted this to be a full contribution. If it looks interesting let me know and I'll write up more stuff on it.

For RAT I'm getting
Files with unapproved licenses:

  /Users/charles.allen/src/druid/extensions-core/grpc/target/rat.txt
  /Users/charles.allen/src/druid/extensions-core/grpc/target/imports.xml
  /Users/charles.allen/src/druid/extensions-core/grpc/target/checkstyle-cachefile
  /Users/charles.allen/src/druid/extensions-core/grpc/target/checkstyle-result.xml
  /Users/charles.allen/src/druid/extensions-core/grpc/target/pmd.xml
  /Users/charles.allen/src/druid/extensions-core/grpc/target/maven-status/maven-compiler-plugin/testCompile/default-testCompile/inputFiles.lst
  /Users/charles.allen/src/druid/extensions-core/grpc/target/maven-status/maven-compiler-plugin/testCompile/default-testCompile/createdFiles.lst
  /Users/charles.allen/src/druid/extensions-core/grpc/target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst
  /Users/charles.allen/src/druid/extensions-core/grpc/target/maven-status/maven-compiler-plugin/compile/default-compile/createdFiles.lst
  /Users/charles.allen/src/druid/extensions-core/grpc/target/maven-archiver/pom.properties
  /Users/charles.allen/src/druid/extensions-core/grpc/target/dependency-reduced-pom.xml
  /Users/charles.allen/src/druid/extensions-core/grpc/target/git.version
  /Users/charles.allen/src/druid/extensions-core/grpc/target/.plxarc

when I do it locally. But it thinks it is excluding target

useDefaultExcludes for the rat properties should be excluding the target directory but it is not for some reason.

@drcrallen For a moment I was scared my little PoC (https://github.com/ndolgov/gruid) was unnecessary.  But then I noticed that your extension is not only of production quality but also goes in a different direction. I have borrowed you Guava workaround though.


Things we need to test when the Artifact expansion implementation is done

I know we are testing cards as we go, but in order to make sure all of the special cases are working well, let's build a list of special cases to test before we are ready to launch the Artifacts expansion. Please add things to this list!

[x] Test that the remaining player wins if all other players are eliminated.
[x] Test that if a player has "Battleship Yamato" as a top card and they activate "Plush Beweglich Rod Bear" that 11 is given as an option to select.
[ ] Test that there isn't an error when "Ark of the Covenant" is played and at least one opponent has zero cards on their board.
[x] Test that the missing icons on "Battleship Yamato" doesn't mistakenly trigger an Artifact being dug.
[x] Test that the right conditions can trigger an infinite scoring loop using "Pride and Prejudice" and end the game.
[x] Test that compel effects don't give other players sharing bonuses.
[x] Test that a player cannot dig an Artifact if the Artifact deck that would be drawn from is empty.
[x] Test that the logic to seize relics works as expected (there are a lot of cases to test).
[ ] Test that "Mass Media" is able to return Artifacts from a score pile.
[x] Test that the game progression estimate seems reasonable (when playing both with and without the expansion).
[ ] Test that the base game still works well (we probably want to test every card quickly)
[ ] Test that the game behaves correctly when the Fission card is triggered (since our updates to the nesting logic affected this card).
[x] Confirm that the cards are spaced apart correctly during splaying. This is a good thing to check because of the graphic refresh we are releasing at the same time.
[x] Test "The Daily Courant" and "Self Service" infinite loop.
[ ] Test Self Service -> Fission (since Fission has weird logic to abort the dogma, we need to confirm that the database isn't left in a weird state).
[x] Meld a card on top of Battleship Yamato with a symbol in the same place. There shouldn't be a dig event.
[x] Test spectator mode

I think we've done enough testing! Marking this as closed.


on_stderr does not mean error

Job can complete successfully even if printing out on stderr

This should be fixed by #64


GitHub Actions on development branch do not complete

Describe the bug
Sine #101 was merged GitHub Actions on the development branch no longer succeed.
To Reproduce
Look at the GitHub actions of development.
Expected behaviour
All actions successfully execute

Can this be closed?

Yes i think so


Readcomiconline.li Java.lang error

Source information
Readcomiconline.li
Source language
English
Steps to reproduce
Click on chapter after the latest update to the extension 1.4.22
Expected behavior
Chapter should open normally
Actual behavior
Failing with error after the new update to v1.4.22
Fails with error - "Java.lang.integer cannot be cast to Java.lang"

Mihon/Tachiyomi version
0.16.5(6)
Android version
11
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.15.3.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

They are intentionally breaking it. Migrate to better sources.

They are intentionally breaking it. Migrate to better sources.

Name some better sources bro ? Most of the sources have very bad quality of comics


Loss value doesn't decrease while finetuning

Tried training the model with the dense fine-tuning on this dataset :- https://huggingface.co/datasets/mteb/scidocs-reranking/viewer/default/validation
With 1 positive and 3 negative sample for each step, and these are the training arguments passed for fine-tuning:-
torchrun --nproc_per_node 1 \ -m FlagEmbedding.baai_general_embedding.finetune.run \ --output_dir ./output \ --model_name_or_path BAAI/bge-large-zh-v1.5 \ --train_data /content/train_data.json \ --learning_rate 5e-5 \ --fp16 \ --max_steps 200 \ --per_device_train_batch_size 1 \ --dataloader_drop_last True \ --normlized True \ --temperature 1 \ --query_max_len 80 \ --passage_max_len 280 \ --train_group_size 4 \ --logging_steps 5 \ --save_steps 200 \ --query_instruction_for_retrieval ""
The training loss doesn't seem to decrease for this and a few other similar datasets, what could be the reason for this and is there any way to make this model work well?
Here is the loss fluctuation for reference:-

Thanks for the response, the performance did improve after considering your suggestions.


Provide stage-in cwl example for each download_type value

stage-in cwl examples exist in this branch https://github.com/unity-sds/unity-data-services/tree/cwl-examples/cwl
GRANULES_DOWNLOAD_TYPE is obsolete as described in https://github.com/unity-sds/unity-data-services/issues/462


Update dependency node to v20

This PR contains the following updates:

Package
Type
Update
Change
Pending

node

major
v18 -> 20

@types/node (source)
devDependencies
major
18.19.18 -> 20.14.13
20.14.14

Release Notes

nodejs/node (node)
v20.16.0: 2024-07-24, Version 20.16.0 'Iron' (LTS), @marco-ippolito
Compare Source
process: add process.getBuiltinModule(id)
process.getBuiltinModule(id) provides a way to load built-in modules
in a globally available function. ES Modules that need to support
other environments can use it to conditionally load a Node.js built-in
when it is run in Node.js, without having to deal with the resolution
error that can be thrown by import in a non-Node.js environment or
having to use dynamic import() which either turns the module into
an asynchronous module, or turns a synchronous API into an asynchronous one.
if (globalThis.process?.getBuiltinModule) {
  // Run in Node.js, use the Node.js fs module.
  const fs = globalThis.process.getBuiltinModule('fs');
  // If `require()` is needed to load user-modules, use createRequire()
  const module = globalThis.process.getBuiltinModule('module');
  const require = module.createRequire(import.meta.url);
  const foo = require('foo');
}

If id specifies a built-in module available in the current Node.js process,
process.getBuiltinModule(id) method returns the corresponding built-in
module. If id does not correspond to any built-in module, undefined
is returned.
process.getBuiltinModule(id) accepts built-in module IDs that are recognized
by module.isBuiltin(id).
The references returned by process.getBuiltinModule(id) always point to
the built-in module corresponding to id even if users modify
require.cache so that require(id) returns something else.
Contributed by Joyee Cheung in #52762
doc: doc-only deprecate OpenSSL engine-based APIs
OpenSSL 3 deprecated support for custom engines with a recommendation to switch to its new provider model.
The clientCertEngine option for https.request(), tls.createSecureContext(), and tls.createServer(); the privateKeyEngine and privateKeyIdentifier for tls.createSecureContext(); and crypto.setEngine() all depend on this functionality from OpenSSL.
Contributed by Richard Lau in #53329
inspector: fix disable async hooks on Debugger.setAsyncCallStackDepth
Debugger.setAsyncCallStackDepth was previously calling the enable function by mistake. As a result, when profiling using Chrome DevTools, the async hooks won't be turned off properly after receiving Debugger.setAsyncCallStackDepth with depth 0.
Contributed by Joyee Cheung in #53473
Other Notable Changes

[09e2191432] - (SEMVER-MINOR) buffer: add .bytes() method to Blob (Matthew Aitken) #53221
[394e00f41c] - (SEMVER-MINOR) doc: add context.assert docs (Colin Ihrig) #53169
[a8601efa5e] - (SEMVER-MINOR) doc: improve explanation about built-in modules (Joyee Cheung) #52762
[5e76c258f7] - doc: add StefanStojanovic to collaborators (StefanStojanovic) #53118
[5e694026f1] - doc: add Marco Ippolito to TSC (Rafael Gonzaga) #53008
[f3ba1eb72f] - (SEMVER-MINOR) net: add new net.server.listen tracing channel (Paolo Insogna) #53136
[2bcce3255b] - (SEMVER-MINOR) src,permission: --allow-wasi & prevent WASI exec (Rafael Gonzaga) #53124
[a03a4c7bdd] - (SEMVER-MINOR) test_runner: add context.fullName (Colin Ihrig) #53169
[69b828f5a5] - (SEMVER-MINOR) util: support --no- for argument with boolean type for parseArgs (Zhenwei Jin) #53107

Commits

[76fd0ea92e] - assert,util: correct comparison when both contain same reference (Daniel Lemire) #53431
[65308b6692] - benchmark: fix api restriction for the permission category (Ryan Tsien) #51528
[1e2bc2c2d0] - benchmark: fix napi/ref addon (Michaël Zasso) #53233
[09e2191432] - (SEMVER-MINOR) buffer: add .bytes() method to Blob (Matthew Aitken) #53221
[e1951a4804] - build: fix spacing before NINJA_ARGS (jakecastelli) #53181
[76f3bb3460] - build: generate binlog in out directories (Chengzhong Wu) #53325
[eded0c187b] - build: support python 3.13 (Chengzhong Wu) #53190
[1e57c67fdb] - build: update ruff to v0.4.5 (Yagiz Nizipli) #53180
[28e71ede63] - build: add --skip-tests to test-ci-js target (Antoine du Hamel) #53105
[bb06778a65] - build: fix building embedtest in GN build (Cheng) #53145
[117ff5f139] - build: use broader detection for 'help' (Aviv Keller) #53045
[9aa896e7f5] - build: fix -j propagation to ninja (Tobias Nießen) #53088
[acdbc78955] - build: exit on unsupported host OS for Android (Mohammed Keyvanzadeh) #52882
[bf3d94478e] - build: fix --enable-d8 builds (Richard Lau) #53106
[99da7d7237] - build: set "clang" in config.gypi in GN build (Cheng) #53004
[9446278f03] - crypto: improve GetECGroupBits signature (Tobias Nießen) #53364
[dc2a4af68d] - crypto: fix propagation of "memory limit exceeded" (Tobias Nießen) #53300
[c5174f5e60] - deps: update c-ares to v1.31.0 (Node.js GitHub Bot) #53554
[28e932dc7a] - deps: update undici to 6.19.2 (Node.js GitHub Bot) #53468
[e4f9c663c4] - deps: update undici to 6.19.1 (Node.js GitHub Bot) #53468
[171dc50fdc] - deps: update undici to 6.19.1 (Node.js GitHub Bot) #53468
[6bb6a9100d] - deps: update undici to 6.19.0 (Node.js GitHub Bot) #53468
[815d71b4cd] - deps: update acorn-walk to 8.3.3 (Node.js GitHub Bot) #53466
[8b5f1d765a] - deps: update zlib to <IP_ADDRESS>-motley-209717d (Node.js GitHub Bot) #53156
[fc73da6f50] - deps: update c-ares to v1.30.0 (Node.js GitHub Bot) #53416
[a6b803abd6] - deps: update undici to 6.18.2 (Node.js GitHub Bot) #53255
[0f235535bb] - deps: update ada to 2.8.0 (Node.js GitHub Bot) #53254
[63407269a8] - deps: update corepack to 0.28.2 (Node.js GitHub Bot) #53253
[7a126e8773] - deps: update c-ares to 1.29.0 (Node.js GitHub Bot) #53155
[0c8fcceefa] - deps: upgrade npm to 10.8.1 (npm team) #53207
[23866979f2] - deps: update undici to 6.18.1 (Node.js GitHub Bot) #53073
[4987a00142] - deps: update undici to 6.18.0 (Node.js GitHub Bot) #53073
[af226d0d9c] - deps: update undici to 6.17.0 (Node.js GitHub Bot) #53034
[c9c6bf8bfb] - deps: update undici to 6.16.1 (Node.js GitHub Bot) #52948
[b32b62d590] - deps: update undici to 6.15.0 (Matthew Aitken) #52763
[6e6641bea2] - deps: update googletest to 33af80a (Node.js GitHub Bot) #53053
[aa96fbe03e] - deps: update zlib to <IP_ADDRESS>-motley-4f653ff (Node.js GitHub Bot) #53052
[ba3310ded5] - deps: upgrade npm to 10.8.0 (npm team) #53014
[8537a2aecf] - doc: recommend not using libuv node-api function (Michael Dawson) #53521
[c13600f0db] - doc: add additional guidance for PRs to deps (Michael Dawson) #53499
[7c3edd952e] - doc: only apply content-visibility on all.html (Filip Skokan) #53510
[ac5be14ed8] - doc: update the description of the return type for options.filter (Zhenwei Jin) #52742
[cac300e351] - doc: remove first timer badge (Aviv Keller) #53338
[feb61459fd] - doc: add Buffer.from(string) to functions that use buffer pool (Christian Bates-White) #52801
[9e0a6e938b] - doc: add initial text for ambassadors program (Michael Dawson) #52857
[55ac53cb0b] - doc: define more cases for stream event emissions (Aviv Keller) #53317
[7128e0f9c9] - doc: remove mentions of policy model from security info (Aviv Keller) #53249
[3e290433df] - doc: fix mistakes in the module load hook api (István Donkó) #53349
[3445c08144] - doc: doc-only deprecate OpenSSL engine-based APIs (Richard Lau) #53329
[a3e8cda019] - doc: mark --heap-prof and related flags stable (Joyee Cheung) #53343
[0b9daaae4d] - doc: mark --cpu-prof and related flags stable (Joyee Cheung) #53343
[daf91834f6] - doc: remove IRC from man page (Tobias Nießen) #53344
[4246c8fa31] - doc: fix broken link in static-analysis.md (Richard Lau) #53345
[955b98a0e4] - doc: remove cases for keys not containing "*" in PATTERN_KEY_COMPARE (Maarten Zuidhoorn) #53215
[7832b1815f] - doc: add err param to fs.cp callback (Feng Yu) #53234
[01533df87f] - doc: add err param to fs.copyFile callback (Feng Yu) #53234
[b081bc7d5e] - doc: reserve 128 for Electron 32 (Keeley Hammond) #53203
[6b8460b560] - doc: add note to ninjia build for macOS using -jn flag (jakecastelli) #53187
[394e00f41c] - (SEMVER-MINOR) doc: add context.assert docs (Colin Ihrig) #53169
[c143d61d0e] - doc: include ESM import for HTTP (Aviv Keller) #53165
[a8601efa5e] - (SEMVER-MINOR) doc: improve explanation about built-in modules (Joyee Cheung) #52762
[560392de3d] - doc: fix minor grammar and style issues in SECURITY.md (Rich Trott) #53168
[9f8e34323d] - doc: mention pm is not enforced when using fd (Rafael Gonzaga) #53125
[3ac775b015] - doc: fix format in esm.md (Pop Moore) #53170
[41b08bdcf7] - doc: fix wrong variable name in example of timers.tick() (Deokjin Kim) #53147
[698ea7aa5a] - doc: fix wrong function name in example of context.plan() (Deokjin Kim) #53140
[a99359d79d] - doc: add note for windows users and symlinks (Aviv Keller) #53117
[61ec2af292] - doc: move all TLS-PSK documentation to its section (Alba Mendez) #35717
[5e76c258f7] - doc: add StefanStojanovic to collaborators (StefanStojanovic) #53118
[1dc406ba62] - doc: improve ninja build for --built-in-modules-path (jakecastelli) #53007
[2854585662] - doc: avoid hiding by navigation bar in anchor jumping (Cloyd Lau) #45131
[3f432f829f] - doc: remove unavailable youtube link in pull requests (Deokjin Kim) #52982
[5e694026f1] - doc: add Marco Ippolito to TSC (Rafael Gonzaga) #53008
[231e44043e] - doc: add missing supported timer values in timers.enable() (Deokjin Kim) #52969
[b8944f6938] - doc, http: add rejectNonStandardBodyWrites option, clear its behaviour (jakecastelli) #53396
[0354584738] - doc, meta: organize contributing to Node-API guide (Aviv Keller) #53243
[9ae3719c4e] - doc, meta: use markdown rather than HTML in CONTRIBUTING.md (Aviv Keller) #53235
[621e073c96] - fs: do not crash if the watched file is removed while setting up watch (Matteo Collina) #53452
[f00ee1c377] - fs: fix cp dir/non-dir mismatch error messages (Mathis Wiehl) #53150
[655b960418] - http2: reject failed http2.connect when used with promisify (ehsankhfr) #53475
[eb0b68bb29] - inspector: fix disable async hooks on Debugger.setAsyncCallStackDepth (Joyee Cheung) #53473
[1c0b89be4c] - lib: fix typo in comment (codediverdev) #53543
[55922d9cb0] - lib: remove the unused code (theanarkh) #53463
[06374ef96b] - lib: fix naming convention of Symbol (Deokjin Kim) #53387
[d1a780039a] - lib: fix timer leak (theanarkh) #53337
[8689ce4b41] - lib: fix misleading argument of validateUint32 (Tobias Nießen) #53307
[57d7bbf624] - lib: fix the name of the fetch global function (Gabriel Bota) #53227
[23f086c363] - lib: do not call callback if socket is closed (theanarkh) #52829
[f325c54c80] - meta: use correct source for workflow in PR (Aviv Keller) #53490
[8172412dbe] - meta: move one or more collaborators to emeritus (Node.js GitHub Bot) #53480
[01b61d65d3] - meta: fix typo in dependency updates (Aviv Keller) #53471
[12f5737cd3] - meta: bump step-security/harden-runner from 2.7.1 to 2.8.0 (dependabot[bot]) #53245
[102e4eee3c] - meta: bump ossf/scorecard-action from 2.3.1 to 2.3.3 (dependabot[bot]) #53248
[5ba185580d] - meta: bump actions/checkout from 4.1.4 to 4.1.6 (dependabot[bot]) #53247
[9d186cce2b] - meta: bump github/codeql-action from 3.25.3 to 3.25.7 (dependabot[bot]) #53246
[29ab74009e] - meta: bump codecov/codecov-action from 4.3.1 to 4.4.1 (dependabot[bot]) #53244
[bd4b593f30] - meta: remove initializeCommand from devcontainer (Aviv Keller) #53137
[61b1f573cf] - meta: move one or more collaborators to emeritus (Node.js GitHub Bot) #53065
[f3ba1eb72f] - (SEMVER-MINOR) net: add new net.server.listen tracing channel (Paolo Insogna) #53136
[67333a5796] - (SEMVER-MINOR) process: add process.getBuiltinModule(id) (Joyee Cheung) #52762
[092aa09eb3] - repl: fix await object patterns without values (Luke Haas) #53331
[554d25f526] - src: reset process.versions during pre-execution (Richard Lau) #53444
[a0879ad628] - src: fix dynamically linked OpenSSL version (Richard Lau) #53456
[91c05f34de] - src: remove SetEncoding from StringEncoder (Yagiz Nizipli) #53441
[4f49384be5] - src: fix typo in env.cc (EhsanKhaki) #53418
[9730d1e186] - src: avoid strcmp in favor of operator== (Tobias Nießen) #53439
[436ad8ceb9] - src: print v8::OOMDetails::detail when it's available (Joyee Cheung) #53360
[f773b289eb] - src: fix IsIPAddress for IPv6 (Hüseyin Açacak) #53400
[7705efd860] - src: fix permission inspector crash (theanarkh) #53389
[260d8d9ae1] - src: use __FUNCSIG__ on Windows in backtrace (Joyee Cheung) #53135
[3b79e9c24e] - src: fix external module env and kDisableNodeOptionsEnv (Rafael Gonzaga) #52905
[32839c63cb] - src: reduce unnecessary GetCwd calls (Yagiz Nizipli) #53064
[840dd092ce] - src: improve node::Dotenv declarations (Tobias Nießen) #52973
[2bcce3255b] - (SEMVER-MINOR) src,permission: --allow-wasi & prevent WASI exec (Rafael Gonzaga) #53124
[e092c62a22] - stream: update outdated highwatermark doc (Jay Kim) #53494
[71af3e8172] - stream: support dispose in writable (Benjamin Gruenbaum) #48547
[33a15be32f] - stream: callback should be called when pendingcb is 0 (jakecastelli) #53438
[1b46ebbf69] - stream: make sure _destroy is called (jakecastelli) #53213
[9f95d41947] - stream: prevent stream unexpected pause when highWaterMark set to 0 (jakecastelli) #53261
[d02651c9d6] - stream: micro-optimize writable condition (Orgad Shaneh) #53189
[324070c410] - stream: fix memory usage regression in writable (Orgad Shaneh) #53188
[48138afd35] - stream: fixes for webstreams (Mattias Buelens) #51168
[24f078a22b] - test: mark test-benchmark-crypto as flaky (Antoine du Hamel) #52955
[0d69ce3474] - test: extend env for test-node-output-errors (Richard Lau) #53535
[1aaaad8518] - test: update encoding web-platform tests (Yagiz Nizipli) #53477
[54e0ba8771] - test: check against run-time OpenSSL version (Richard Lau) #53456
[059e47c320] - test: update tests for OpenSSL 3.0.14 (Richard Lau) #53373
[49e6f33021] - test: fix test-http-server-keepalive-req-gc (Etienne Pierre-doray) #53292
[292d13a289] - test: update TLS tests for OpenSSL 3.2 (Richard Lau) #53384
[82017c90bb] - test: fix test when compiled without engine support (Richard Lau) #53232
[a54090b385] - test: update TLS trace tests for OpenSSL >= 3.2 (Richard Lau) #53229
[3a1693421d] - test: fix Windows native test suites (Stefan Stojanovic) #53173
[2b07d01272] - test: skip test-setproctitle when ps is not available (Antoine du Hamel) #53104
[0051d1c83d] - test: increase allocation so it fails for the test (Adam Majer) #53099
[048cbe3304] - test: remove timers from test-tls-socket-close (Luigi Pinca) #53019
[8653d9223e] - test: replace .substr with .slice (Antoine du Hamel) #53070
[d74bda4241] - test: add AbortController to knownGlobals (Luigi Pinca) #53020
[f29e1e9838] - test: skip unstable shadow realm gc tests (Chengzhong Wu) #52855
[dfa498697e] - test,doc: enable running embedtest for Windows (Vladimir Morozov) #52646
[0381817f1d] - test_runner: calculate executed lines using source map (Moshe Atlow) #53315
[9d3699b5b0] - test_runner: handle file rename and deletion under watch mode (jakecastelli) #53114
[9a36258ca0] - test_runner: refactor to use min/max of validateInteger (Deokjin Kim) #53148
[a03a4c7bdd] - (SEMVER-MINOR) test_runner: add context.fullName (Colin Ihrig) #53169
[a72157077a] - test_runner: fix t.assert methods (Colin Ihrig) #53049
[ba764db9ab] - test_runner: avoid error when coverage line not found (Moshe Atlow) #53000
[3a4a0ebd06] - test_runner,doc: align documentation with actual stdout/stderr behavior (Moshe Atlow) #53131
[6e6646bdd5] - tls: check result of SSL_CTX_set_*_proto_version (Tobias Nießen) #53459
[2aceed4297] - tls: avoid taking ownership of OpenSSL objects (Tobias Nießen) #53436
[faa5cac18c] - tls: use SSL_get_peer_tmp_key (Tobias Nießen) #53366
[68fcbb635e] - tls: fix negative sessionTimeout handling (Tobias Nießen) #53002
[61a1c43ef1] - tools: fix skip detection of test runner output (Richard Lau) #53545
[53a7b6e1c0] - tools: fix c-ares update script (Marco Ippolito) #53414
[3bd5f46a15] - tools: update lint-md-dependencies (Node.js GitHub Bot) #53158
[daab9e170f] - tools: do not run Corepack code before it's reviewed (Antoine du Hamel) #53405
[d18a67f937] - tools: use Ubuntu 24.04 and Clang on GitHub actions (Michaël Zasso) #53212
[e9b7a52848] - tools: add stream label on PR when related files being changed in lib (jakecastelli) #53269
[04d78dd56d] - tools: remove no-goma arg from make-v8 script (Michaël Zasso) #53336
[37e725a500] - tools: use sccache Github action (Moshe Atlow) #53316
[2a1fde7e32] - tools: update error message for Type Error (Aviv Keller) #53047
[8f5fb4192d] - Revert "tools: add --certify-safe to nci-ci" (Antoine du Hamel) #53098
[69b828f5a5] - (SEMVER-MINOR) util: support --no- for argument with boolean type for parseArgs (Zhenwei Jin) #53107
[1a2f3ab4f5] - watch: fix variable naming (jakecastelli) #53101

v20.15.1: 2024-07-08, Version 20.15.1 'Iron' (LTS), @RafaelGSS
Compare Source
This is a security release.
Notable Changes

CVE-2024-36138 - Bypass incomplete fix of CVE-2024-27980 (High)
CVE-2024-22020 - Bypass network import restriction via data URL (Medium)
CVE-2024-22018 - fs.lstat bypasses permission model (Low)
CVE-2024-36137 - fs.fchown/fchmod bypasses permission model (Low)
CVE-2024-37372 - Permission model improperly processes UNC paths (Low)

Commits

[60e184a6e4] - lib,esm: handle bypass network-import via data: (RafaelGSS) nodejs-private/node-private#522
[025cbd6936] - lib,permission: support fs.lstat (RafaelGSS) nodejs-private/node-private#486
[d38ea17341] - lib,permission: disable fchmod/fchown when pm enabled (RafaelGSS) nodejs-private/node-private#584
[1ba624cd3b] - src: handle permissive extension on cmd check (RafaelGSS) nodejs-private/node-private#596
[2524d00c3d] - src,permission: fix UNC path resolution (RafaelGSS) nodejs-private/node-private#581
[484cb0f13c] - src,permission: resolve path on fs_permission (Rafael Gonzaga) #52761

v20.15.0: 2024-06-20, Version 20.15.0 'Iron' (LTS), @marco-ippolito
Compare Source
test_runner: support test plans
It is now possible to count the number of assertions and subtests that are expected to run within a test. If the number of assertions and subtests that run does not match the expected count, the test will fail.
test('top level test', (t) => {
  t.plan(2);
  t.assert.ok('some relevant assertion here');
  t.subtest('subtest', () => {});
});

Contributed by Colin Ihrig in #52860
inspector: introduce the --inspect-wait flag
This release introduces the --inspect-wait flag, which allows debugger to wait for attachement. This flag is useful when you want to debug the code from the beginning. Unlike --inspect-brk, which breaks on the first line, this flag waits for debugger to be connected and then runs the code as soon as a session is established.
Contributed by Kohei Ueno in #52734
zlib: expose zlib.crc32()
This release exposes the crc32() function from zlib to user-land.
It computes a 32-bit Cyclic Redundancy Check checksum of data. If
value is specified, it is used as the starting value of the checksum,
otherwise, 0 is used as the starting value.
The CRC algorithm is designed to compute checksums and to detect error
in data transmission. It's not suitable for cryptographic authentication.
const zlib = require('node:zlib');
const { Buffer } = require('node:buffer');

let crc = zlib.crc32('hello');  // 907060870
crc = zlib.crc32('world', crc);  //<PHONE_NUMBER>

crc = zlib.crc32(Buffer.from('hello', 'utf16le'));  //<PHONE_NUMBER>
crc = zlib.crc32(Buffer.from('world', 'utf16le'), crc);  //<PHONE_NUMBER>

Contributed by Joyee Cheung in #52692
cli: allow running wasm in limited vmem with --disable-wasm-trap-handler
By default, Node.js enables trap-handler-based WebAssembly bound
checks. As a result, V8 does not need to insert inline bound checks
int the code compiled from WebAssembly which may speedup WebAssembly
execution significantly, but this optimization requires allocating
a big virtual memory cage (currently 10GB). If the Node.js process
does not have access to a large enough virtual memory address space
due to system configurations or hardware limitations, users won't
be able to run any WebAssembly that involves allocation in this
virtual memory cage and will see an out-of-memory error.
$ ulimit -v 5000000
$ node -p "new WebAssembly.Memory({ initial: 10, maximum: 100 });"
[eval]:1
new WebAssembly.Memory({ initial: 10, maximum: 100 });
^

RangeError: WebAssembly.Memory(): could not allocate memory
    at [eval]:1:1
    at runScriptInThisContext (node:internal/vm:209:10)
    at node:internal/process/execution:118:14
    at [eval]-wrapper:6:24
    at runScript (node:internal/process/execution:101:62)
    at evalScript (node:internal/process/execution:136:3)
    at node:internal/main/eval_string:49:3

--disable-wasm-trap-handler disables this optimization so that
users can at least run WebAssembly (with a less optimial performance)
when the virtual memory address space available to their Node.js
process is lower than what the V8 WebAssembly memory cage needs.
Contributed by Joyee Cheung in #52766
Other Notable Changes

[12512c3d0e] - doc: add pimterry to collaborators (Tim Perry) #52874
[9d485b40bb] - (SEMVER-MINOR) tools: fix get_asan_state() in tools/test.py (Joyee Cheung) #52766
[e98c305f52] - (SEMVER-MINOR) tools: support max_virtual_memory test configuration (Joyee Cheung) #52766
[dce0300896] - (SEMVER-MINOR) tools: support != in test status files (Joyee Cheung) #52766

Commits

[227093bfec] - assert: add deep equal check for more Error type (Zhenwei Jin) #51805
[184cfe5a71] - benchmark: filter non-present deps from start-cli-version (Adam Majer) #51746
[8b3e83bb53] - buffer: even faster atob (Daniel Lemire) #52443
[8d628c3255] - buffer: use size_t instead of uint32_t to avoid segmentation fault (Xavier Stouder) #48033
[16ae2b2933] - buffer: remove lines setting indexes to integer value (Zhenwei Jin) #52588
[48c15d0dcd] - build: remove deprecated calls for argument groups (Mohammed Keyvanzadeh) #52913
[1be8232d17] - build: drop base64 dep in GN build (Cheng) #52856
[918962d6e7] - build: make simdjson a public dep in GN build (Cheng) #52755
[5215b6fd8e] - build, tools: copy release assets to staging R2 bucket once built (flakey5) #51394
[473fa73857] - (SEMVER-MINOR) cli: allow running wasm in limited vmem with --disable-wasm-trap-handler (Joyee Cheung) #52766
[954d2aded4] - cluster: replace forEach with for-of loop (Jérôme Benoit) #50317
[794e450ea7] - console: colorize console error and warn (Jithil P Ponnan) #51629
[0fb7c18f10] - crypto: fix duplicated switch-case return values (Mustafa Ateş UZUN) #49030
[cd1415c8b2] - Revert "crypto: make timingSafeEqual faster for Uint8Array" (Tobias Nießen) #53390
[b774544bb1] - deps: enable unbundling of simdjson, simdutf, ada (Daniel Lemire) #52924
[da4dbfc5fd] - doc: remove reference to AUTHORS file (Marco Ippolito) #52960
[2f3f2ff8af] - doc: update hljs with the latest styles (Aviv Keller) #52911
[3a1d17a9b1] - doc: mention quicker way to build docs (Alex Crawford) #52937
[be309bd19d] - doc: mention push.followTags config (Rafael Gonzaga) #52906
[e62c6e2684] - doc: document pipeline with end option (Alois Klink) #48970
[af27225cf6] - doc: add example for execFileSync method and ref to stdio (Evan Shortiss) #39412
[086626f9b1] - doc: add examples and notes to http server.close et al (mary marchini) #49091
[3aa3337a00] - doc: fix dns.lookup family 0 and all descriptions (Adam Jones) #51653
[585f2a2e7f] - doc: update fs.realpath documentation (sinkhaha) #48170
[4bf3d44e1d] - doc: update fs read documentation for clarity (Mert Can Altin) #52453
[ae5d47dde3] - doc: watermark string behavior (Benjamin Gruenbaum) #52842
[1e429d10d3] - doc: exclude commits with baking-for-lts (Marco Ippolito) #52896
[3df3e37cdb] - doc: add names next to release key bash commands (Aviv Keller) #52878
[12512c3d0e] - doc: add pimterry to collaborators (Tim Perry) #52874
[97e0fef019] - doc: add more definitions to GLOSSARY.md (Aviv Keller) #52798
[91fadac162] - doc: make docs more welcoming and descriptive for newcomers (Serkan Özel) #38056
[a3b20126fd] - doc: add OpenSSL errors to API docs (John Lamp) #34213
[9587ae9b5b] - doc: simplify copy-pasting of branch-diff commands (Antoine du Hamel) #52757
[6ea72a53c3] - doc: add test_runner to subsystem (Raz Luvaton) #52774
[972eafd983] - events: update MaxListenersExceededWarning message log (sinkhaha) #51921
[74753ed1fe] - events: add stop propagation flag to Event.stopImmediatePropagation (Mickael Meausoone) #39463
[75dd009649] - events: replace NodeCustomEvent with CustomEvent (Feng Yu) #43876
[7d38c2e012] - fs: keep fs.promises.readFile read until EOF is reached (Zhenwei Jin) #52178
[8cb13120d3] - (SEMVER-MINOR) inspector: introduce the --inspect-wait flag (Kohei Ueno) #52734
[d5ab1de1fd] - meta: move @anonrig to TSC regular member (Yagiz Nizipli) #52932
[f82d086e90] - path: fix toNamespacedPath on Windows (Hüseyin Açacak) #52915
[121ea13b50] - process: improve event-loop (Aras Abbasi) #52108
[eceac784aa] - repl: fix disruptive autocomplete without inspector (Nitzan Uziely) #40661
[89a910be82] - src: fix Worker termination in inspector.waitForDebugger (Daeyeon Jeong) #52527
[033f985e8a] - src: use S_ISDIR to check if the file is a directory (theanarkh) #52164
[95128399f8] - src: allow preventing debug signal handler start (Shelley Vohr) #46681
[b162aeae9e] - src: fix typo Unabled -> Unable (Simon Siefke) #52820
[2dcbf1894a] - src: avoid unused variable 'error' warning (Michaël Zasso) #52886
[978ee0a635] - src: only apply fix in main thread (Paolo Insogna) #52702
[8fc52b38c6] - src: fix test local edge case (Paolo Insogna) #52702
[d02907ecc4] - src: remove misplaced windows code under posix guard in node.cc (Ali Hassan) #52545
[af29120fa7] - stream: use ByteLengthQueuingStrategy when not in objectMode (Jason) #48847
[a5f3dd137c] - string_decoder: throw an error when writing a too long buffer (zhenweijin) #52215
[65fa95d57d] - test: add Debugger.setInstrumentationBreakpoint known issue (Konstantin Ulitin) #31137
[0513e07805] - test: use for-of instead of forEach (Gibby Free) #49790
[1d01325928] - test: verify request payload is uploaded consistently (Austin Wright) #34066
[7dda156872] - test: add fuzzer for native/js string conversion (Adam Korczynski) #51120
[5fb829b340] - test: add fuzzer for ClientHelloParser (AdamKorcz) #51088
[cc74bf789f] - test: fix broken env fuzzer by initializing process (AdamKorcz) #51080
[800b6f65cf] - test: replace forEach() in test-stream-pipe-unpipe-stream (Dario) #50786
[d08c9a6a31] - test: test pipeline end on transform streams (Alois Klink) #48970
[0be8123ede] - test: improve coverage of lib/readline.js (Rongjian Zhang) #38646
[410224415c] - test: updated for each to for of in test file (lyannel) #50308
[556e9a2127] - test: move test-http-server-request-timeouts-mixed to sequential (Madhuri) #45722
[0638274c07] - test: fix DNS cancel tests (Szymon Marczak) #44432
[311bdc62bd] - test: add http agent to executionAsyncResource (psj-tar-gz) #34966
[6001b164ab] - test: reduce memory usage of test-worker-stdio (Adam Majer) #37769
[986bfa26e9] - test: add common.expectRequiredModule() (Joyee Cheung) #52868
[2246d4fd1e] - test: crypto-rsa-dsa testing for dynamic openssl (Michael Dawson) #52781
[1dce5dea0b] - test: skip some console tests on dumb terminal (Adam Majer) #37770
[0addeb240c] - test: skip v8-updates/test-linux-perf-logger (Michaël Zasso) #52821
[56e19e38f3] - test: drop test-crypto-ti

Configuration
📅 Schedule: Branch creation - "before 4am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Self-Hosted Renovate Bot. Find all logs here.

 You will not get PRs for any future 20.x releases. But if you manually upgrade to 20.x then Renovate will re-enable minor and patch updates automatically.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.


all: switch to using a custom Reader interface

This PR switches to using a custom Reader interface instead of bytes.Reader to avoid extra copying of data when loading a WASM file.

Thanks @orsinium for review.


Add CI validation to ensure sample links use absolute links

Sample readme pages defined in the repo get uploaded to the docs sample site. However the corresponding sample md files are not uploaded to the docs site. Thus using relative links results in broken links on the docs site:
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azuresecuritykeyvaultkeys-samples/
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azurestoragecommon-samples/
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azurestorageblobs-samples/
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azurestoragequeues-samples/
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azurestoragefilesshares-samples/
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azure-app-configuration-client-sdk-samples/
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azuremessagingservicebus-samples/
https://docs.microsoft.com/en-us/samples/azure/azure-sdk-for-net/azurecore-samples/
It would be great if we have a CI step that enforces absolute links in these sample readme files.

The issue has been addressed. Closed it


Cool project

I opened this issue just to let you know I am developing a similar solution called dokz, it would be cool to join the efforts if you want
It also has a playground to preview react components
I would love to have your opinion on the project
Thank you for your awesome work at @vercel

@remorses wow I didn't know that dokz exists, great project!
I created Nextra because I wanted to make a docs site for my own open source projects and use Next.js of course. It seems dokz covers almost all the features that I need, I think I can contribute to dokz instead :)

@shuding would you still recommend using Nextra then, or would dokz be a better pick for the long term?

Use what you like the most

@hunvreus dokz will be a better pick, since this project is more like an experiment and I don’t have bandwidth to actively maintain it for now.

Thanks for the follow up @shuding, cheers.


Supported response types should be configured on a per-client basis

Right now we only have a global config value
oauth2:
   responseTypes: ["code", "token", "id_token"]

This should be local to the client
staticClients:
- id: example-app
  redirectURIs:
  - 'http://<IP_ADDRESS>:5555/callback'
  name: 'Example App'
  secret: ZXhhbXBsZS1hcHAtc2VjcmV0
  responseTypes: ["code", "token"]

Piggy-backing this, what would you think about per-connector id_token expiries?
The use case would be, for example, using both LDAP (allows for refresh_tokens) and SAML (no refresh), you could set the LDAP connector's expiry much lower than the SAML connector's. Currently, as soon as SAML is among your connectors, it's limitations dictate longer-lived tokens.


Update README to clarify getting started steps

The wording in the README leads you to believe that the --create-principal and --fetch-role will be created when running the docker command given. However, those two roles need to exist already in the user's account.

+1
I've just stuck with the same issue.


Fix anchor links in README

Question #2 & #7 had broken links, this fixes that.

Thanks!

Actually, I reverted this since it's no longer needed as I also reverted https://github.com/philipwalton/flexbugs/pull/203.

Ah no worries 😄


Use common functions to wrap nodes in document node

This pull request derives from #382. So needs to be handled after that.

generate-tests-utils.xsl and generate-xspec-tests.xsl in src/compiler/ does similar things:

Checks to see if items are nodes which can be wrapped in a document node.
Wraps nodes in a document node.

This pull request consolidates them into common functions.

@cirulls
Merged this internal improvement.