nixos/tests/dex-oidc: fix build

change way of getting approval code to parsing query parameter from redirect_url of login request
add 2 minute timeouts to parts that can wait up to 15 minutes by default (timeout defaults to 900)

Description of changes
Fixes build of nixosTests.dex-oidc (fails since 2022-10-07):
https://hydra.nixos.org/job/nixos/trunk-combined/nixos.tests.dex-oidc.x86_64-linux
https://hydra.nixos.org/build/271524163
Error log:
Got state jaixewrwdfpfvsaunthemrc65
machine: must succeed: curl -fs 'localhost:8080/dex/auth/mock/login?back=&state=jaixewrwdfpfvsaunthemrc65' -d 'login=admin&password=password'
machine # [   18.881907] dex[1012]: time=2024-09-05T05:33:45.366Z level=INFO msg="login successful" connector_id=mock username="Kilgore Trout" preferred_username=""<EMAIL_ADDRESS>groups=[] request_id=90fbc233-7fbd-4eb3-8c8d-2af15af2d61c
(finished: must succeed: curl -fs 'localhost:8080/dex/auth/mock/login?back=&state=jaixewrwdfpfvsaunthemrc65' -d 'login=admin&password=password', in 0.08 seconds)
machine: must succeed: curl -fs localhost:8080/dex/approval?req=jaixewrwdfpfvsaunthemrc65 | sed -n 's/.*code=\(.*\)&.*/\1/p'
machine: output:
Test "Login" failed with error: "command `curl -fs localhost:8080/dex/approval?req=jaixewrwdfpfvsaunthemrc65 | sed -n 's/.*code=\(.*\)&.*/\1/p'` failed (exit code 22)"

curl to localhost:8080/dex/approval returns 401
Could not find much upstream about how it is used now or why it changed.
Listed test maintainer:
@Flakebi
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg test dex-oidc


The blog web had been broken: comments not work anymore

I believe the problem was introduced from #205 by @824zzy
Uncaught ReferenceError: MathJax is not defined
    at MathJaxLocal.js:1

In order to make the system more robust, I'd like to suggest the following two rules in the future:

Split the PR into minimum units for each modification, by creating different branches for them.
Test the blog system from localhost by run make serve and make sure everything is ok if you modify any system files.

Run make serve did not give me any warnings or errors. I will fix this error soon.

Thanks!
The make serve did not help because this issue is a javescript error, which could only be found in the browser with the specified feature.
And that's the reason why I said that we should be very careful when modify the system theme files.

Local test does not show comments. So it is very hard to debug. Let me guess where is the bug. LOL

Yeah, that's why we have to be very careful.

It seems that the pagination had also been in inflected.

The pagination and comment are still but functional...

Thanks, @824zzy, this issue had been resolved!


.strip() not stripping \t.

Reporting a bug

[x] I am using the latest released version of Numba (most recent is visible in
the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[x] I have included below a minimal working reproducer (if you are unsure how
to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

>>> from numba import njit
>>> s = '  \t bbcd\t '
>>> s.strip()
'bbcd'
>>> @njit
... def foo(s):
...     return s.strip()
...
>>> foo(s)
'\t bbcd\t'
>>>

Need to fix these 2 lines
https://github.com/numba/numba/blob/ad3303c25133d57127abf8be1cd72d6048f45813/numba/unicode.py#L890
https://github.com/numba/numba/blob/ad3303c25133d57127abf8be1cd72d6048f45813/numba/unicode.py#L879
Perhaps replacing ' ' with https://docs.python.org/3.7/library/string.html#string.whitespace

duplicate of #4188.

I'd like to take a look at this as my first issue. Is this okay even though the issue is marked as duplicate or should I resolve the original issue instead?

@shimst3r great, thanks for wanting to contribute. I'd go for resolving the issue reported here with \t and extending the testing for cover that, and then if you are happy with that move on to cover the contents of #4188. Hows that sound?
As a new contributor, some instructions for getting set up for development are here and are a great place to start.
Thanks!

Sounds great to me and thank you for the link. 👍

@shimst3r @stuartarchibald took this one home


Is there a way to know whether the photo was shot or taken from the library ?

I need to do different things depending on how the image is loaded

Unfortunately, nothing in the callback indicates which source it came from. I don't plan on adding that feature, but I have some alternatives for you...

Fork the repo and include the source in the response callback - this would be a super easy addition
Build your own Alert dialog for Take Photo/Choose From Library, and use ImagePickerManager.launchCamera() or ImagePickerManager. launchImageLibrary() to fire them off directly. Then, you'll have to ability to know which they selected from your JS code.

Thanks a lot ! I added the source in the response, it was very easy indeed ! cheers


show "changeset tags" to the user before saving changes.

related to #2449  ( + privacy )
For  greater transparency,  it would be useful showing to the user  the  "changeset tags" before saving changes.  ( or create an options to see )
statistics:

https://gist.github.com/ImreSamu/0fc3b8015e6dd16595c5

I'd like to be able to add changeset tags so we can properly tag changesets in iD, but believe the privacy issue is a red herring. Presumably the full changeset tags aren't going to be shown by the standard workflow, only if a user decides to add/remove tags, vaguely similar to the JOSM way of not showing changeset tags by default. Most users won't see them, so it doesn't change their awareness of the details of what is uploaded.

@ImreSamu very cool!
I do see in the report that we should probably be more consistent with the locale (e.g. having both 'en-us' and 'en-US' in the results is sloppy, so I can just lowercase them all).
Agree, @pnorman  I think we addressed the privacy concerns already in #2559.  Maybe I can find  a way to put a collapsed raw tag editor on the save screen, so users can actually add their own changeset tags.

My latest osm changeset statistics : https://gist.github.com/ImreSamu/2b31315ef2328cb482c7


bos rebalance --max-fee-rate seems to be ignored

Even though I put a maximum fee rate of 100, bos is still trying to use nodes with much higher fee rates. I would expect it to do what I set and keep trying until it finds a route with nodes that have a fee rate of <100. Instead I have to manually set the --avoid flag on nodes with a fee >100 and run the rebalance again and again, which is very time consuming.

this is by design

, bos is still trying to use nodes with much higher fee rates. I would expect it to do what I set and keep trying until it finds a ro

may i ask why this is by design?

the max fee rate is the rate to auto-accept, the fee rate tried shows you the fee rate to opt-in to

alexbosworth

and the idea is that the Lnd path-finding algo is presenting the lowest fee routes first?

yeah that's correct

yeah that's correct

it seems the lnd routing algorithm may have been updated, as I don't think it is presenting the lowest fee option first. they're maybe doing some weighting by channel size too or something
example output of a bos rebalance --out CoinGate command with lnd 0.14.2-beta
(note a higher fee route is presented first)
outgoing_peer_to_increase_inbound: CoinGate 0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3
incoming_peer_to_decrease_inbound: <REDACTED> <REDACTED>
rebalance_target_amount:           0.04294967

circular_rebalance_for: deezy 024bfaf0cabe7f874fd33ebf7c6f4e5385971fc504ef3f492432e9e3ec77e1b5cf

evaluating:
  - 676038x1275x0 ★ ★ ☆ ☆
  - CoinGate 0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3. Fee rate: 0.00% (3)
  - 724289x1527x1
  - coinhodler04108 0299797daa21faa6e4151517b286c41d4c7a8cb21fbfba59ca3bcd21a9f8392bd4. Fee rate: 0.04% (433)
  - 724069x1574x0
  - <REDACTED> <REDACTED> Fee rate: 0.00% (3)
  - <REDACTED>

failure: TemporaryChannelFailure at 724289x1527x1 from CoinGate

evaluating:
  - 676038x1275x0 ★ ★ ☆ ☆
  - CoinGate 0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3. Fee rate: 0.00% (3)
  - 638350x612x0
  - LNBIG.com [lnd-10] 02bb24da3d0fb0793f4918c7599f973cc402f0912ec3fb530470f1fc08bdd6ecb5. Fee rate: 0.02% (242)
  - 667410x56x0
  - <REDACTED> <REDACTED>. Fee rate: 0.00% (3)
  - <REDACTED>

failure: TemporaryChannelFailure at 638350x612x0 from CoinGate

Yeah it is relative to the confidence which is factored into the cost
You can see the confidence as those stars at the top: ★ ★ ☆ ☆
This behavior can be adjusted in lnd.conf routerrpc settings

sweet thanks i will check that out. i'm trying to find a good way to constantly monitor for possible cheap rebalance paths

there's an option now to avoid max fee rate routes


feat: Adds shape visitors for local service

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The more I digest this the more I like it.
If you could do a once-over to add some single-line comments inside some of the longer functions to help explain what's going on, that would help others understand it more quickly.
I would really like to see some generated code in context before I approve this but it seems reasonable.

Added some comments, renamed some variables to make it self explanatory, and did some better formatting to ease readability - our java formatter is really aggressive and breaks line more than what is generally done in Java. This hinders readability and makes method longer than what it actually should be.
Avoided adding lots of comments since it again gets stale and pollutes code (I favor self explanatory code than comments). Let me know if you think we can do few things better.


some errors for latest version of swift

i just install it to my project and there are many errors in frameworks
private let YearUnit = NSCalendarUnit.CalendarUnitYear
private let MonthUnit = NSCalendarUnit.CalendarUnitMonth
private let WeekUnit = NSCalendarUnit.CalendarUnitWeekOfMonth
private let WeekOfYearUnit = NSCalendarUnit.CalendarUnitWeekOfYear
private let WeekdayUnit = NSCalendarUnit.CalendarUnitWeekday
private let DayUnit = NSCalendarUnit.CalendarUnitDay
private let AllUnits = YearUnit | MonthUnit | WeekUnit | WeekOfYearUnit | WeekdayUnit | DayUnit
// MARK: - DateUnit operators overload
public func + (lhs: DateUnit, rhs: Int) -> NSDate {
return dateUnitOffset(lhs, rhs, { x, y in x + y })
}
public func - (lhs: DateUnit, rhs: Int) -> NSDate {
return dateUnitOffset(lhs, rhs, { x, y in x - y })
}
public func * (lhs: DateUnit, rhs: Int) -> NSDate {
return dateUnitOffset(lhs, rhs, { x, y in x * y })
}
public func / (lhs: DateUnit, rhs: Int) -> NSDate {
return dateUnitOffset(lhs, rhs, { x, y in x / y })
}
public func == (lhs: DateUnit, rhs: Int) -> NSDate {
return dateUnitOffset(lhs, rhs, { _, y in y })
}
// MARK: - NSDate operators overload
public func == (lhs: NSDate, rhs: NSDate) -> Bool {
return compareWithOperation({ $0 == $1 }, { $0 && $1 && $2 })(lhs, rhs)
}
public func > (lhs: NSDate, rhs: NSDate) -> Bool {
return compareWithOperation({ $0 > $1 }, { $0 || $1 || $2 })(lhs, rhs)
}
public func >= (lhs: NSDate, rhs: NSDate) -> Bool {
return compareWithOperation({ $0 > $1 || lhs == rhs }, { $0 || $1 || $2 })(lhs, rhs)
}
public func < (lhs: NSDate, rhs: NSDate) -> Bool {
return compareWithOperation({ $0 < $1 }, { $0 || $1 || $2 })(lhs, rhs)
}
public func <= (lhs: NSDate, rhs: NSDate) -> Bool {
return compareWithOperation({ $0 < $1 || lhs == rhs }, { $0 || $1 || $2 })(lhs, rhs)
}
public func != (lhs: NSDate, rhs: NSDate) -> Bool {
return !(lhs == rhs)
}

@zsw12abc I don't have any, can you please give me some information on how to reproduce it?

i just installed it again this morning and it worked well.
i don't know what happened last time.
but now, everything is good

Alright, thus -> closed


signing job on windows is failing

What are you trying to do? Run the sign_tool job within the nightly pipelines on Windows
Expected behaviour: Success of the job
Observed behaviour: Failure of the job - looks to be failing on any operation that contacts the timestamp server
find: 'basename' terminated by signal 13
find: 'basename' terminated by signal 13
Signing Windows release
Signing ./hotspot/jtreg/native/FPRegs.exe
Done Adding Additional Store

Number of errors: 1

SignTool Error: The specified timestamp server either could not be reached or
returned an invalid response.
SignTool Error: An error occurred while attempting to sign: ./hotspot/jtreg/native/FPRegs.exe

RETRYWARNING: Failed to sign ./hotspot/jtreg/native/FPRegs.exe at 22:16:56: Possible timestamp server error - RC 0 ... Retrying in 10 seconds
Done Adding Additional Store

Number of errors: 1

SignTool Error: The specified timestamp server either could not be reached or
returned an invalid response.
SignTool Error: An error occurred while attempting to sign: ./hotspot/jtreg/native/FPRegs.exe

Any other comments:

https://stackoverflow.com/questions/65541786/is-the-verisign-timestamp-server-down - we need a new timestamp server.  Checking alternatives...

https://stackoverflow.com/questions/65541786/is-the-verisign-timestamp-server-down - we need a new timestamp server.  Checking alternatives...

@karianna Might make sense to align with https://github.com/AdoptOpenJDK/openjdk-installer/blob/master/wix/serverTimestamp.config and use the same logic incl. retry after doing the quick fix.

@karianna Might make sense to align with https://github.com/AdoptOpenJDK/openjdk-installer/blob/master/wix/serverTimestamp.config and use the same logic incl. retry after doing the quick fix.

@aahlenst - Agreed - I'll leave this open so I can enhance it with the list (it'll take me a while because looping over a data structure in shell scripting takes time for this inexperienced shell scripter :-)).  In the mean time can you review/approve the interim PR - just so we can get the builds back up fro tonight?

@aahlenst - Agreed - I'll leave this open so I can enhance it with the list (it'll take me a while because looping over a data structure in shell scripting takes time for this inexperienced shell scripter :-)).  In the mean time can you review/approve the interim PR - just so we can get the builds back up fro tonight?


slashcommands: force NSFW to false if not present

Currently, if a command has previously been set to NSFW when the bot is run, subsequently removing the NSFW flag does NOT update the slash command's NSFW status in Discord. This results in said command continually being restricted to NSFW channels exclusively by Discord.
I have tested this to the best of my ability, and I have personally concluded that removing omitempty from the CreateApplicationCommandRequest struct seems not to make a difference. I am open to being proven wrong.
My tests involved setting a command to NSFW, running the bot and testing the command, then removing the NSFW from the command, running the bot, restarting Discord client, logging in and out of Discord client to be 100% certain, and running the command again. These tests concluded that removing omitempty did not affect Discord's limiting of the slash command to NSFW channels.
This commit simply forces the NSFW flag to be set to false during conversion to CreateApplicationCommandRequest if the command doesn't have the NSFW flag set. Similar testing has concluded this to be effective.

Totally agree with you. Even printf'ing it with %v and %T shows that even if the flag is not set, it's .
Des is of the impression that it's totally coincidental and caused by Discord not handling their own NSFW slash commands properly. I believe that my testing results were correlational at best, but not cause and effect :)


Feature/corenlp server options

Due to the stdout and stderr params being 'pipe' when creating a CoreNLP server, the server would become unresponsive and each request to it will timeout once the pipe has been filled (As was stated in a #TODO by @dimazest 2 years ago).
So I have added made those params configureable :D

Does anyone know why the tests failed on 3.7?

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
It's worth re-running the build to see if it will pass. The issue could be on Travis end, but it could also be code related.

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
It's worth re-running the build to see if it will pass. The issue could be on Travis end, but it could also be code related.

How do I re-run it? its my first nltk contribution

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
It's worth re-running the build to see if it will pass. The issue could be on Travis end, but it could also be code related.

How do I re-run it? its my first nltk contribution

I would suggest running the build on your fork of nltk through Travis. Make an account on Travis and it should pick up your fork and allow running this build for your branch. Alternatively an admin can comment on this PR with [CI: retest] which will trigger a rebuild, this is a custom feature of nltk repo.

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
It's worth re-running the build to see if it will pass. The issue could be on Travis end, but it could also be code related.

How do I re-run it? its my first nltk contribution

I would suggest running the build on your fork of nltk through Travis. Make an account on Travis and it should pick up your fork and allow running this build for your branch. Alternatively an admin can comment on this PR with [CI:retest] which will trigger a rebuild, this is a custom feature of nltk repo.

Running it now :D
https://travis-ci.org/matanrak/nltk/builds/492575604

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
It's worth re-running the build to see if it will pass. The issue could be on Travis end, but it could also be code related.

How do I re-run it? its my first nltk contribution

I would suggest running the build on your fork of nltk through Travis. Make an account on Travis and it should pick up your fork and allow running this build for your branch. Alternatively an admin can comment on this PR with [CI:retest] which will trigger a rebuild, this is a custom feature of nltk repo.

It all passed 😃
https://travis-ci.org/matanrak/nltk/builds/492575604

Thanks @dimazest, @purificant, @matanrak


added from_generator method to IterableDataset class.

Hello,
This resolves issues #4988.
I added a method from_generator to class IterableDataset.
I modified the read method of input stream generator to also return Iterable_dataset.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

I added a test and moved the streaming param from read to __init_. Then, I also decided to update the read method of the rest of the packaged modules to account for this param.
@hamid-vakilzadeh Are you OK with these changes?


[WIP] Generate direct call bindings

@ShadowApex not intended for merge, just an idea I'm playing around with - pre-generating all calls to GDNative C API methods to avoid using reflection at runtime.  It's mostly a straight rip-off of how the CPP bindings are done:
classes.go
func (o *AStar) AddPoint(id int64, position *Vector3, weightScale float64) {
        GodotCall_void_int_Vector3_float(o, "add_point", id, position, weightScale)
}

godotcalls.go
func GodotCall_void_int_Vector3_float(o Class, methodName string, arg0 int64, arg1 *Vector3, arg2 float64) {

	methodBind := getGodotMethod(o.baseClass(), methodName)
	cArgsArray := C.build_array(C.int(3))
	cArg0 := arg0 // TODO convert arg based on type
	C.add_element(cArgsArray, cArg0, C.int(0))
	cArg1 := arg1 // TODO convert arg based on type
	C.add_element(cArgsArray, cArg1, C.int(1))
	cArg2 := arg2 // TODO convert arg based on type
	C.add_element(cArgsArray, cArg2, C.int(2))

	objectOwner := unsafe.Pointer(o.getOwner())

	C.godot_method_bind_ptrcall(
		methodBind,
		objectOwner,
		cArgsArray, // void**
		nil,        // void*
	)
}

Still TBD is the Go<->Godot type conversions on either side of the C calls.  I expect it will be similar to the existing conversion code but executed at code-gen time.
Let me know if you'd entertain using this approach - I suspect it's slightly faster but I haven't benchmarked.  Right now it's actually 40K fewer generated LOC than the dynamic call approach, but that delta will shrink when I add the type conversion bits.

And yes, it currently doesn't build, but it's close :-P

Hi @worrel
I think this would be a great approach! The more we can avoid using reflection, the better.
The one thing I'm unsure about it is the names of the methods in godotcalls.go. They should probably be unexported, and use camelCase (e.g. godotCallVoidIntVector3Float) to keep with the Go naming conventions. There's a few methods that are in snake_case, but those names are required to be exported as C functions to Godot. In generate.go, there are some functions to convert snake case to camel case that could be used.
Related to this, I'm actually working on a significant refactor of the code in the rewrite branch, where I'm working on writing a thin wrapper around the GDNative methods and types. That thin wrapper will end up being a gdnative Go package that we can use to write the godot package in pure Go. Doing it that way will allow others to be more flexible in writing their own Go package to interface with Godot. As an example, right now we are generating the classes for all Godot class types (AStar, Node2D, etc.), but someone might not use all of those types, which just bloats the size of their library.
Right now I'm specifically writing a code generator/parser that will parse the Godot header files for all type definitions (e.g. godot_bool, godot_variant, etc.). From that, I hope to generate Go types for all of the discovered Godot types, along with conversion functions for every basic type so they can be passed to functions like C.godot_method_bind_ptrcall.
Here's an example of the base types I'm trying to generate:
type Variant struct {
    base *C.godot_variant
}

func (v *Variant) getBase() *C.godot_variant {
    return v.base
}

Once we have the code for generating all of the base types, we can write code to generate all of the methods defined in the Godot headers as Go wrappers. So, we might get something like this as an example wrapper:
func MethodBindGetMethod(classname, methodname *GodotString) *MethodBind {
    methodBind := godot_method_bind_get_method(classname.getBase(), methodname.getBase())
    return &MethodBind{base: methodBind}
}

@ShadowApex generating the godot types would make things way easier for me.

@ShadowApex yup, good point on the name exporting - I've changed it to camelCase.  I found a godotCallVoidRidRect2Rect2RidVector2Vector2IntIntBoolColorRid and I never want to see anything but generated code using that :-D
The rewrite branch looks interesting.  In particular, while the code in this PR now builds, it segfaults on the godot_method_bind_get_method calls.  I'm finding navigating the cgo rock face tricky so anything that eases that would be great.  Right now I'm debugging this by creating the equivalent GDNative calls in pure C & comparing to the generated bindings.
I'll ping when I have this branch successfully running the Pong example, or maybe the Dodge the Creeps game from the tutorial.

HYPE. You guys are awesome.

it now runs the the Pong example w/o crashing & the tiniest beginnings Dodge The Creeps (I haven't ported the whole thing yet).  But basic stuff GetViewportRect() and GetNode() seem to work.  Sure there are plenty of bugs lurking.

Comparing to my C examples, I see I'll need to track when I allocate godot_string arguments:
cArg0 := unsafe.Pointer(stringAsGodotString(arg0))

so I can
C.godot_string_destroy(...)

before leaving the godotCallXXX to not leak memory.  That's tomorrow's problem :-)

I'm a bit stuck now.  Many common calls work, but some segfault - notably AnimatedSprite.SetAnimation("someanim") or AnimatedSprite.Play("").  I've checked and SetAnimation also fails on master, though there the error is SIGBUS not SIGSEGV.
What's odd is that certain "similar" calls succeed.  i.e. godot.Input.IsActionPressed("someaction") (func with String arg), or AnimatedSprite.Stop() (void func) do work.  Also, Node.GetNode("nodename") works (func with object return type), since I'm able to call stop() on the AnimatedSprite that's returned.  All this seems to rule out issues with arg passing via CGO or void/return value handling.
I have a separate C-only example and it's able to call "set_animation", "play" etc fine on an AnimatedSprite, so the issue appears to come from the Go side.  I've tried replicating the C-only example in pure Go (i.e. without godot-go classes), but I can't get that to run (I've replicated cgateway.go etc from godot-go but Godot can't find my constructor func O_o).
Anyway, if someone has time to pull this branch, try a minimal example & report back, that would be cool. I'll push my test code somewhere now.

Comparing to my C examples, I see I'll need to track when I allocate godot_string arguments before leaving the godotCallXXX to not leak memory.

I've found this has been tricky. Sometimes Godot will call godot_free or godot_string_destroy for you, in which case, if you free it again, it will crash.

I'm a bit stuck now. Many common calls work, but some segfault - notably AnimatedSprite.SetAnimation("someanim") or AnimatedSprite.Play(""). I've checked and SetAnimation also fails on master, though there the error is SIGBUS not SIGSEGV.

Yeah, I've also encountered those issues, and haven't had the opportunity to fully debug those. We may need to dig into exactly what is different about the calls that work and the calls that don't work. Looking at the differences between Node.GetNode("nodename") and AnimatedSprite.SetAnimation("someanim") might lead us to why it's segfaulting.

I made some progress debugging the segfaults.  I added a few variations of pure C calls for GetNode and SetAnimation (see classes.go on debug-failures branch) and then tested out combinations to find ones that worked (see my test Go shared lib).
I didn't spend too much time trying to narrow down exactly why certain combinations failed, but rather implemented a version of this branch using generated pure C calls (see godotcalls.go on direct-c-calls branch).  I quite like the separation of responsibilities here:

classes.go provides the Go API structure and doesn't call any C.* methods
godotcalls.go has Go and C functions:
-- godotCallsXXX Go funcs are responsible just for marshalling C<->Go types
-- godot_call_XXX C functions are responsible for interacting with the GDNative API

One of the advantages of using pure C interaction for GDNative is it's easier to compare with existing GDNative examples or solicit help since there aren't any distracting Go/Cgo details.  A second advantage appears to be library size:  a build of my test code using master results in a 53mb .dylib on OSX, while the same code built against the direct-c-calls branch is only 11mb!
I'm still working out the kinks in the generated C code.  It's already more functional than this branch, but I need to fix allocation of the core type structs.  There's no GDNative example code on this, it appears you have to malloc/new any godot_vector2, godot_node_path etc structs that are return types prior to calling godot_method_bind_ptrcall.  This is probably obvious to a seasoned C coder, which is something that I am not :-P

Any movement on this?

i'm going to attempt a rewrite on top of c-for-go. will post updates once i reach a milestone


Akamai fix

https://github.com/blackjack4494/yt-dlc/pull/274 by @nixxo

@nixxo Could you please resolve the conflicts?

@nixxo Could you please resolve the conflicts?

@nixxo thanks

@nixxo thanks


FEAT: Iterable dataset

What do these changes do?
Implement an iterable dataset to read export dataset, it contains these features.

[x] prefetch
[x] retry and timeout
[x] distributed shuffle
[x] handle rank, world size for distributed dataset
[x] handle worker id, num workers for multi workers dataset

Related issue number

Fixes #xxxx
Check code requirements

[ ] tests added / passed (if needed)
[ ] Ensure all linting tests pass

Have you tested on cloud storage like s3?

Have you tested on cloud storage like s3?

Not yet.  Do we have a test bucket?

Have you tested on cloud storage like s3?

I have tested export to and read from s3. It works OK.


Removal of curried function declaration syntax

I imagine we'd want to update generator.swift in response to this change: https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md

Related: https://twitter.com/jckarter/status/675854346123280389

Yep, we need to do this. I've been meaning to get to this, but haven't had time. I'm going to add the help wanted label.

Damn! I was so proud of this too. Oh well, as long as currying isn't going away then I'm happy.

Made this change in #19


fix(v2): Fix Hebrew translations

Motivation
Following https://github.com/facebook/docusaurus/pull/4587#discussion_r634415102 comment - This PR removes the Hebrew string for the number 2, and use it directly.
Example for English speakers:
Two posts => 2 posts
because "post" in Hebrew does not have a special form for two (unlike other Hebrew words like "day" יום / יומיים / ימים).
Also - after running it locally I fix other inconsistent translations I found.

Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Test it locally
Related PRs
https://github.com/facebook/docusaurus/pull/4811

Thanks !
It's not like I'm able to review the changes, so let's merge 😅


ApplyLayer gzip invalid header stdout for dockerfiles/centos-lamp

I have created a very simple github repo https://github.com/alberto56/test20150715091543 which contains only a Dockerfile FROM dockerfiles/centos-lamp, and a circle.yml file which builds it. I ran this locally on the latest version of CoreOS (738.1.0) and I get an "invalid header":
core@core-01 ~/share/test20150715091543 $ docker build .
Sending build context to Docker daemon 3.072 kB
Sending build context to Docker daemon
Step 0 : FROM dockerfiles/centos-lamp
Pulling repository dockerfiles/centos-lamp
666d59f8429d: Error pulling image (latest) from dockerfiles/centos-lamp, endpoin666d59f8429d: Error pulling image (latest) from dockerfiles/centos-lamp, ApplyLayer gzip: invalid header stdout: {"layerSize":300550566}
INFO[0058]  stderr:

I know that this image worked 5 days ago (see, for example, https://circleci.com/gh/dcycleproject/dcyclebox/57), so this is a Docker hub issue. Do you know of a way to "rebuild" this image on Docker hub so that it works again?

This might have to do with the tag 6.4 no longer available for centos:
See the output at https://circleci.com/gh/alberto56/test20150715091543/2


[Feature Request]: Modify code in quickfix, write it to file

I don't know if it would be possible to add something that is similar to the functionality of stefandtw/quickfix-reflector.vim. Where a command like :vimgrep could populate the quickfix list, and then a %s/<search>/<replace> command could be ran on the quickfix list, causing each change to be written to the corresponding file.
This would need to involve checking whether or not the item in the quickfix list is a note or an actual line in a file.
Just as a note, an issue I had with the plugin mentioned above is that it does not always work very well with nvim-bqf. The preview window from bqf will not always close, and your plugin seems to work wonderfully with bqf.

I don't know if it would be possible to add something that is similar to the functionality of stefandtw/quickfix-reflector.vim. Where a command like :vimgrep could populate the quickfix list, and then a %s/<search>/<replace> command could be ran on the quickfix list, causing each change to be written to the corresponding file.

I never thought about doing this. I usually use cdo for these types of operation. But I can look into that option.

This would need to involve checking whether or not the item in the quickfix list is a note or an actual line in a file.

Good point! It is totally doable.

Just as a note, an issue I had with the plugin mentioned above is that it does not always work very well with nvim-bqf. The preview window from bqf will not always close, and your plugin seems to work wonderfully with bqf.

Thanks! I'm a big fan of the nvim-bqf plugin. Glad to hear your are using these two together.

Having looked at the code of the plugin, I understand it sets the modifiable flag on the local/qf lists. I'm not comfortable doing this because it will cause any autocmds to react to changes on the buffer.
I can think of two feasible solution:

Leave it as is. A cdo with substitution would work as expected. However it would error out if the term is not on the line due to the Notes or manual addition of lines with <leader>qq, <leader>ww, etc.
Provide a command to clean up the list, removing any notes created by this plugin. This will let user use the cdo command without any errors.

What do you reckon?

I've never used cdo, but I am going to start. For whatever it is worth, another plugin that makes the quickfix list modifiable is replacer.nvim.
I think the second option wouldn't be bad. Add a command that would be able to filter out quickfix items that do not correspond to lines in a file. So then it would be easier when using cdo or whatever other command to modify the buffer.
Since I wasn't aware of the cdo command, I don't think that making the buffer modifiable is that important. The only reason I could ever see use for that would be to go through and modify each line individually.
Something else that could possibly be done is to create a command that is similar to cdo but allow for something like quickfix-reflector.vim's qf_join_changes, where all changes could be undone with a single undo command

Something else I might add, just as a suggestion. For your library you have arshlib.nvim, perhaps the UI part of it could somehow be integrated with dressing.nvim. All it would need to do is call vim.ui.input, and then the user could choose between telescope, fzf, fzf-lua, nui, or the builtin, and wouldn't necessarily have to have nui as a dependency for the library.

The cdo, ldo, cfdo and lfdo commands are awesome, give them a try. You can also run the update and undo on them which is handy.
Just a note: the note you create actually have the necessary information on the file and the line. Therefore any operation you do with cdo/ldo, cfdo/lfdo commands will still work.
Regarding the ui, I totally agree with you. It's worth creating a new issue because it is unrelated to this conversation.
Thanks for all the ideas, I appreciate it.

I'd say that this could be closed now that there have been commits referencing this and that cdo and such will act on lines actually referencing spots in files. And making the quickfix list modifiable doesn't seem to be wanted or necessary.

Thanks mate. If you have any other suggestions please feel free to make an issue.
I have a few other tiny plugins that might interest you.
Thank you for your support!


All Kinds Of Problems--Not Working

I've gotten through most of the steps, but having multiple problems:

After doing the server/client registration, when navigating back to the Consent page, there is no "accept" option, it's still asking me to do the server/client registration.
I moved on, but there is no "Windows Virtual Desktop" option in the Enterprise Apps list (there is a Windows Virtual Desktop client" option, but I doubt that's the same thing).
Moving even further on, when executing the final PS command to create the tenant, I get the following error: "user is not authorized to query the management service"

Lots of problems, have no idea what's going on since there are no errors during the process until the end. We have been eagerly awaiting this preview, and are dead in the water before we even jumped off the boat.

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

ID: eab4b2c4-29d9-d759-066f-f7cf633260ca
Version Independent ID: 05c8b237-2c9e-6453-9cbf-9c7a3b7f8b07
Content: Create a tenant in Windows Virtual Desktop (preview)  - Azure
Content Source: articles/virtual-desktop/tenant-setup-azure-active-directory.md
Service: virtual-desktop
GitHub Login: @Heidilohr
Microsoft Alias: helohr

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

I get the same problems

After doing the server/client registration, when navigating back to the Consent page, there is no "accept" option, it's still asking me to do the server/client registration.

I have the "Windows Virtual Desktop" option in the Enterprise Apps list

But this still gives me the same error when executing the final PS command to create the tenant, I get the following error: "user is not authorized to query the management service"

Nevermind.
If I go into the Enterprise Application and manually change my user to TenantCreator, then the PS script runs successfully.
If you don't have the Windows Virtual Desktop option in Enterprise Applications it probably because you didn't run through the consent page twice, once for the Server and once for Client option. Or because your user isn't global admin.

Thank you Martin for taking the time to reply with your fix to manually change update your user role to TenantCreator.
For those who need a little extra guidance, as mentioned by julesman101 there should be a 7th step.  After you assign your user account under users and groups, select your account and then click Edit.  Click Select Role >> TenantCreator.  This will allow you to run the PS command to create a new tenant.

@jaypatrick @bonksnp Thanks for the feedback !  I have assigned this issue to content author to investigate and update the document as appropriate.

Added additional screenshots since issue was created, which should mitigate this issue. Please re-open as appropriate.
#please-close


Duplicate Grid Component in PDF

Description of the bug
A Summary2 component that references a Grid component gets duplicated in the PDF.
The first one is in the old style where all the components are displayed as a list, and the second one is displayed in the new style as a full grid.
The second one also appear at the end of the PDF, after other components.
Ideally the first one should be removed and be replaced with the second one so that only the grid version is visible.
Steps To Reproduce
Create a Grid component
Create a Summary2 that references the Grid
In the summary page it looks correct, but in the PDF the Summary component is duplicated
Additional Information
This behavior can be displayed in this repo: https://altinn.studio/repos/krt/krt-1189a-1
The frontend version used was  v4.9.0-preview.3.

@MagnusMolaugFinans Dette skyldes nok at du ikke har aktivert Summary2, men alikevel bruker Summary2 komponenten manuelt. Da vil den gamle summary funksjonaliteten primært rendre summaries.
Prøve å sette dette i index.cshtml:
<script>
     window.featureToggles = {
          betaPDFenabled: true
      };
</script>

Du vil da kun bruke Summary2 for å vise oppsummering, det burde nå fungere bra.


[ISSUE #4028] Enhanced Comparison using reference equality instead of value equality

Fixes #4028 .
Motivation
Enhanced Comparison using reference equality instead of value equality
Modifications
Replaced == with .equals()
Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

@kyooosukedn please solve the conflicts.


Exclude private package files from auto import

I work on a mono repo and I would like vscode to stop auto importing from private, non-built files of my packages. Some of my packages are just package-prototypes (without their own package.json file)
For example if I have
packages/foo/src/tool.js
packages/foo/index.js

I would like to import tool from packages/foo and not packages/foo/src/tool.
The most similar issue is https://github.com/microsoft/vscode/issues/52087 which was closed as a duplicate of https://github.com/microsoft/vscode/issues/35350, but I am not sure how they compare or how https://github.com/microsoft/vscode/issues/35350 could solve this
Ideally some option with a pattern list to exclude import suggestions. In my case it could be exclude: ['**/src/*']

Actually this is a duplicate of https://github.com/microsoft/TypeScript/issues/35395
We are still waiting for more feedback upstream so please upvote that issue


Pandas' requirements will not get installed automatically.

tests4py :: INFO     :: Checking whether Tests4Py project
tests4py :: INFO     :: Loading projects
tests4py :: INFO     :: Checking for platform darwin
tests4py :: INFO     :: Check for activated python version
tests4py :: INFO     :: Using pyenv python 3.8.4
tests4py :: INFO     :: Creating virtual env
tests4py :: INFO     :: Activating virtual env
tests4py :: INFO     :: Installing utilities
tests4py :: INFO     :: Installing requirements
  Running command git clone --filter=blob:none --quiet https://github.com/pandas-dev/pandas /Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/src/pandas
  Running command git rev-parse -q --verify 'sha^e41ee47a90bb1d8a1fa28fcefcd45ed8ef5cb946'
  Running command git fetch -q https://github.com/pandas-dev/pandas e41ee47a90bb1d8a1fa28fcefcd45ed8ef5cb946
  Running command git checkout -q e41ee47a90bb1d8a1fa28fcefcd45ed8ef5cb946
  error: subprocess-exited-with-error

  × Getting requirements to build editable did not run successfully.
  │ exit code: 1
  ╰─> [320 lines of output]
      <string>:19: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
      <string>:45: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
      <string>:453: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
      <string>:489: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
      warning: pandas/_libs/algos_take_helper.pxi:51:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:178:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:305:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:432:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:559:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:686:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:813:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:940:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1067:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1194:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1321:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1448:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1575:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1702:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1829:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1956:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:2083:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:2210:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:2337:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos.pyx:141:42: Unknown type declaration 'bint' in annotation, ignoring
      warning: pandas/_libs/groupby.pyx:1099:26: Unreachable code
      performance hint: pandas/_libs/hashing.pyx:109:5: Exception check on 'u32to8_le' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'u32to8_le' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'u32to8_le' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:127:5: Exception check on '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:171:21: Exception check after calling '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:182:17: Exception check after calling '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:188:17: Exception check after calling '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:22:5: Exception check on 'append_data_float64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_float64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_float64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:31:5: Exception check on 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:44:5: Exception check on 'append_data_string' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_string' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_string' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:57:5: Exception check on 'append_data_uint64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_uint64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_uint64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:558:39: Exception check after calling 'append_data_float64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_float64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_float64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:675:39: Exception check after calling 'append_data_float64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_float64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_float64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:882:38: Exception check after calling 'append_data_uint64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_uint64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_uint64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:996:38: Exception check after calling 'append_data_uint64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_uint64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_uint64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:1203:37: Exception check after calling 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:1320:37: Exception check after calling 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable.pyx:191:33: Exception check after calling 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/parsers.pyx:1581:5: Exception check on '_to_fw_string_nogil' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_to_fw_string_nogil' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_to_fw_string_nogil' to allow an error code to be returned.
      performance hint: pandas/_libs/parsers.pyx:1576:27: Exception check after calling '_to_fw_string_nogil' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_to_fw_string_nogil' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_to_fw_string_nogil' to allow an error code to be returned.
      performance hint: pandas/_libs/parsers.pyx:1665:42: Exception check after calling 'double_converter' will always require the GIL to be acquired. Declare 'double_converter' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: pandas/_libs/parsers.pyx:1689:38: Exception check after calling 'double_converter' will always require the GIL to be acquired. Declare 'double_converter' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                  object cached_typ = None

              arr = self.arr
              chunk = self.dummy
              dummy_buf = chunk.data
              chunk.data = arr.data
                   ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:105:13: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                          # On the first pass, we check the output shape to see
                          #  if this looks like a reduction.
                          _check_result_array(res, len(self.dummy))

                      PyArray_SETITEM(result, PyArray_ITER_DATA(it), res)
                      chunk.data = chunk.data + self.increment
                           ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:144:21: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                      PyArray_SETITEM(result, PyArray_ITER_DATA(it), res)
                      chunk.data = chunk.data + self.increment
                      PyArray_ITER_NEXT(it)
              finally:
                  # so we don't free the wrong memory
                  chunk.data = dummy_buf
                       ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:148:17: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                      PyArray_SETITEM(result, PyArray_ITER_DATA(it), res)
                      chunk.data = chunk.data + self.increment
                      PyArray_ITER_NEXT(it)
              finally:
                  # so we don't free the wrong memory
                  chunk.data = dummy_buf
                       ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:148:17: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...

              self.orig_data = self.buf.data
              self.orig_len = self.buf.shape[0]
              self.orig_stride = self.buf.strides[0]

              self.buf.data = self.values.data
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:443:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...

              self.buf.data = self.values.data
              self.buf.strides[0] = self.stride

          cdef advance(self, Py_ssize_t k):
              self.buf.data = <char*>self.buf.data + self.stride * k
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:447:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...

          cdef move(self, int start, int end):
              """
              For slicing
              """
              self.buf.data = self.values.data + self.stride * start
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:453:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
              self.buf.shape[0] = length

          cdef reset(self):

              self.buf.shape[0] = self.orig_len
              self.buf.data = self.orig_data
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:462:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
              # move blocks
              for i in range(self.nblocks):
                  arr = self.blocks[i]

                  # axis=1 is the frame's axis=0
                  arr.data = self.base_ptrs[i] + arr.strides[1] * start
                     ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:583:15: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
              # reset blocks
              for i in range(self.nblocks):
                  arr = self.blocks[i]

                  # axis=1 is the frame's axis=0
                  arr.data = self.base_ptrs[i]
                     ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:602:15: Assignment to a read-only property
      Compiling pandas/_libs/algos.pyx because it changed.
      Compiling pandas/_libs/groupby.pyx because it changed.
      Compiling pandas/_libs/hashing.pyx because it changed.
      Compiling pandas/_libs/hashtable.pyx because it changed.
      Compiling pandas/_libs/index.pyx because it changed.
      Compiling pandas/_libs/indexing.pyx because it changed.
      Compiling pandas/_libs/internals.pyx because it changed.
      Compiling pandas/_libs/interval.pyx because it changed.
      Compiling pandas/_libs/join.pyx because it changed.
      Compiling pandas/_libs/lib.pyx because it changed.
      Compiling pandas/_libs/missing.pyx because it changed.
      Compiling pandas/_libs/parsers.pyx because it changed.
      Compiling pandas/_libs/reduction.pyx because it changed.
      Compiling pandas/_libs/ops.pyx because it changed.
      Compiling pandas/_libs/ops_dispatch.pyx because it changed.
      Compiling pandas/_libs/properties.pyx because it changed.
      Compiling pandas/_libs/reshape.pyx because it changed.
      Compiling pandas/_libs/sparse.pyx because it changed.
      Compiling pandas/_libs/tslib.pyx because it changed.
      Compiling pandas/_libs/tslibs/base.pyx because it changed.
      Compiling pandas/_libs/tslibs/ccalendar.pyx because it changed.
      Compiling pandas/_libs/tslibs/conversion.pyx because it changed.
      Compiling pandas/_libs/tslibs/fields.pyx because it changed.
      Compiling pandas/_libs/tslibs/frequencies.pyx because it changed.
      Compiling pandas/_libs/tslibs/nattype.pyx because it changed.
      Compiling pandas/_libs/tslibs/np_datetime.pyx because it changed.
      Compiling pandas/_libs/tslibs/offsets.pyx because it changed.
      Compiling pandas/_libs/tslibs/parsing.pyx because it changed.
      Compiling pandas/_libs/tslibs/period.pyx because it changed.
      Compiling pandas/_libs/tslibs/resolution.pyx because it changed.
      Compiling pandas/_libs/tslibs/strptime.pyx because it changed.
      Compiling pandas/_libs/tslibs/timedeltas.pyx because it changed.
      Compiling pandas/_libs/tslibs/timestamps.pyx because it changed.
      Compiling pandas/_libs/tslibs/timezones.pyx because it changed.
      Compiling pandas/_libs/tslibs/tzconversion.pyx because it changed.
      Compiling pandas/_libs/testing.pyx because it changed.
      Compiling pandas/_libs/window/aggregations.pyx because it changed.
      Compiling pandas/_libs/window/indexers.pyx because it changed.
      Compiling pandas/_libs/writers.pyx because it changed.
      Compiling pandas/io/sas/sas.pyx because it changed.
      [ 1/40] Cythonizing pandas/_libs/algos.pyx
      [ 2/40] Cythonizing pandas/_libs/groupby.pyx
      [ 3/40] Cythonizing pandas/_libs/hashing.pyx
      [ 4/40] Cythonizing pandas/_libs/hashtable.pyx
      [ 5/40] Cythonizing pandas/_libs/index.pyx
      [ 6/40] Cythonizing pandas/_libs/indexing.pyx
      [ 7/40] Cythonizing pandas/_libs/internals.pyx
      [ 8/40] Cythonizing pandas/_libs/interval.pyx
      [ 9/40] Cythonizing pandas/_libs/join.pyx
      [10/40] Cythonizing pandas/_libs/lib.pyx
      [11/40] Cythonizing pandas/_libs/missing.pyx
      [12/40] Cythonizing pandas/_libs/ops.pyx
      [13/40] Cythonizing pandas/_libs/ops_dispatch.pyx
      [14/40] Cythonizing pandas/_libs/parsers.pyx
      [15/40] Cythonizing pandas/_libs/properties.pyx
      [16/40] Cythonizing pandas/_libs/reduction.pyx
      Traceback (most recent call last):
        File "/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 132, in get_requires_for_build_editable
          return hook(config_settings)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-_vgzkir2/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 441, in get_requires_for_build_editable
          return self.get_requires_for_build_wheel(config_settings)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-_vgzkir2/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 325, in get_requires_for_build_wheel
          return self._get_build_requires(config_settings, requirements=['wheel'])
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-_vgzkir2/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 295, in _get_build_requires
          self.run_setup()
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-_vgzkir2/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 480, in run_setup
          super(_BuildMetaLegacyBackend, self).run_setup(setup_script=setup_script)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-_vgzkir2/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 311, in run_setup
          exec(code, locals())
        File "<string>", line 792, in <module>
        File "<string>", line 762, in setup_package
        File "<string>", line 538, in maybe_cythonize
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-_vgzkir2/overlay/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 1154, in cythonize
          cythonize_one(*args)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-_vgzkir2/overlay/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 1321, in cythonize_one
          raise CompileError(None, pyx_file)
      Cython.Compiler.Errors.CompileError: pandas/_libs/reduction.pyx
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build editable did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.
Traceback (most recent call last):
  File "/Users/batuhanserce/PycharmProjects/Tests4Py/venv/bin/t4p", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/Users/batuhanserce/PycharmProjects/Tests4Py/src/tests4py/cli.py", line 609, in main
    raise report.raised
  File "/Users/batuhanserce/PycharmProjects/Tests4Py/src/tests4py/api/default.py", line 314, in compile_project
    subprocess.check_call(
  File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['python', '-m', 'pip', 'install', '-r', PosixPath('/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_requirements.txt')]' returned non-zero exit status 1.

I should have fixed this. I will merge it.
@sonradanfransiz can you verify it before closing this issue?

I have tried it on windows, i still get the error. I will try it on mac on monday.

On Unix' i still get the error. I will continue with spacy for now.
(venv)  batuhanserce@Batuhans-MacBook-Pro  ~/PycharmProjects/Tests4Py  ↱ project  t4p build -w tmp/pandas_1
tests4py :: INFO     :: Loading projects
tests4py :: INFO     :: Checking whether Tests4Py project
tests4py :: INFO     :: Loading projects
tests4py :: INFO     :: Checking for platform darwin
tests4py :: INFO     :: Check for activated python version
tests4py :: INFO     :: Using pyenv python 3.8.4
tests4py :: INFO     :: Creating virtual env
tests4py :: INFO     :: Activating virtual env
tests4py :: INFO     :: Installing utilities
tests4py :: INFO     :: Installing requirements
  Running command git clone --filter=blob:none --quiet https://github.com/pandas-dev/pandas /Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/src/pandas
  Running command git rev-parse -q --verify 'sha^e41ee47a90bb1d8a1fa28fcefcd45ed8ef5cb946'
  Running command git fetch -q https://github.com/pandas-dev/pandas e41ee47a90bb1d8a1fa28fcefcd45ed8ef5cb946
  Running command git checkout -q e41ee47a90bb1d8a1fa28fcefcd45ed8ef5cb946
  error: subprocess-exited-with-error

  × Getting requirements to build editable did not run successfully.
  │ exit code: 1
  ╰─> [320 lines of output]
      <string>:19: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
      <string>:45: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
      <string>:453: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
      <string>:489: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
      warning: pandas/_libs/algos_take_helper.pxi:51:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:178:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:305:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:432:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:559:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:686:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:813:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:940:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1067:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1194:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1321:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1448:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1575:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1702:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1829:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:1956:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:2083:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:2210:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos_take_helper.pxi:2337:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310
      warning: pandas/_libs/algos.pyx:141:42: Unknown type declaration 'bint' in annotation, ignoring
      warning: pandas/_libs/groupby.pyx:1099:26: Unreachable code
      performance hint: pandas/_libs/hashing.pyx:109:5: Exception check on 'u32to8_le' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'u32to8_le' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'u32to8_le' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:127:5: Exception check on '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:171:21: Exception check after calling '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:182:17: Exception check after calling '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashing.pyx:188:17: Exception check after calling '_sipround' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_sipround' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_sipround' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:22:5: Exception check on 'append_data_float64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_float64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_float64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:31:5: Exception check on 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:44:5: Exception check on 'append_data_string' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_string' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_string' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:57:5: Exception check on 'append_data_uint64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_uint64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_uint64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:558:39: Exception check after calling 'append_data_float64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_float64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_float64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:675:39: Exception check after calling 'append_data_float64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_float64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_float64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:882:38: Exception check after calling 'append_data_uint64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_uint64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_uint64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:996:38: Exception check after calling 'append_data_uint64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_uint64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_uint64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:1203:37: Exception check after calling 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable_class_helper.pxi:1320:37: Exception check after calling 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/hashtable.pyx:191:33: Exception check after calling 'append_data_int64' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare 'append_data_int64' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on 'append_data_int64' to allow an error code to be returned.
      performance hint: pandas/_libs/parsers.pyx:1581:5: Exception check on '_to_fw_string_nogil' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_to_fw_string_nogil' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_to_fw_string_nogil' to allow an error code to be returned.
      performance hint: pandas/_libs/parsers.pyx:1576:27: Exception check after calling '_to_fw_string_nogil' will always require the GIL to be acquired.
      Possible solutions:
          1. Declare '_to_fw_string_nogil' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
          2. Use an 'int' return type on '_to_fw_string_nogil' to allow an error code to be returned.
      performance hint: pandas/_libs/parsers.pyx:1665:42: Exception check after calling 'double_converter' will always require the GIL to be acquired. Declare 'double_converter' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      performance hint: pandas/_libs/parsers.pyx:1689:38: Exception check after calling 'double_converter' will always require the GIL to be acquired. Declare 'double_converter' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                  object cached_typ = None

              arr = self.arr
              chunk = self.dummy
              dummy_buf = chunk.data
              chunk.data = arr.data
                   ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:105:13: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                          # On the first pass, we check the output shape to see
                          #  if this looks like a reduction.
                          _check_result_array(res, len(self.dummy))

                      PyArray_SETITEM(result, PyArray_ITER_DATA(it), res)
                      chunk.data = chunk.data + self.increment
                           ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:144:21: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                      PyArray_SETITEM(result, PyArray_ITER_DATA(it), res)
                      chunk.data = chunk.data + self.increment
                      PyArray_ITER_NEXT(it)
              finally:
                  # so we don't free the wrong memory
                  chunk.data = dummy_buf
                       ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:148:17: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
                      PyArray_SETITEM(result, PyArray_ITER_DATA(it), res)
                      chunk.data = chunk.data + self.increment
                      PyArray_ITER_NEXT(it)
              finally:
                  # so we don't free the wrong memory
                  chunk.data = dummy_buf
                       ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:148:17: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...

              self.orig_data = self.buf.data
              self.orig_len = self.buf.shape[0]
              self.orig_stride = self.buf.strides[0]

              self.buf.data = self.values.data
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:443:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...

              self.buf.data = self.values.data
              self.buf.strides[0] = self.stride

          cdef advance(self, Py_ssize_t k):
              self.buf.data = <char*>self.buf.data + self.stride * k
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:447:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...

          cdef move(self, int start, int end):
              """
              For slicing
              """
              self.buf.data = self.values.data + self.stride * start
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:453:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
              self.buf.shape[0] = length

          cdef reset(self):

              self.buf.shape[0] = self.orig_len
              self.buf.data = self.orig_data
                      ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:462:16: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
              # move blocks
              for i in range(self.nblocks):
                  arr = self.blocks[i]

                  # axis=1 is the frame's axis=0
                  arr.data = self.base_ptrs[i] + arr.strides[1] * start
                     ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:583:15: Assignment to a read-only property

      Error compiling Cython file:
      ------------------------------------------------------------
      ...
              # reset blocks
              for i in range(self.nblocks):
                  arr = self.blocks[i]

                  # axis=1 is the frame's axis=0
                  arr.data = self.base_ptrs[i]
                     ^
      ------------------------------------------------------------

      pandas/_libs/reduction.pyx:602:15: Assignment to a read-only property
      Compiling pandas/_libs/algos.pyx because it changed.
      Compiling pandas/_libs/groupby.pyx because it changed.
      Compiling pandas/_libs/hashing.pyx because it changed.
      Compiling pandas/_libs/hashtable.pyx because it changed.
      Compiling pandas/_libs/index.pyx because it changed.
      Compiling pandas/_libs/indexing.pyx because it changed.
      Compiling pandas/_libs/internals.pyx because it changed.
      Compiling pandas/_libs/interval.pyx because it changed.
      Compiling pandas/_libs/join.pyx because it changed.
      Compiling pandas/_libs/lib.pyx because it changed.
      Compiling pandas/_libs/missing.pyx because it changed.
      Compiling pandas/_libs/parsers.pyx because it changed.
      Compiling pandas/_libs/reduction.pyx because it changed.
      Compiling pandas/_libs/ops.pyx because it changed.
      Compiling pandas/_libs/ops_dispatch.pyx because it changed.
      Compiling pandas/_libs/properties.pyx because it changed.
      Compiling pandas/_libs/reshape.pyx because it changed.
      Compiling pandas/_libs/sparse.pyx because it changed.
      Compiling pandas/_libs/tslib.pyx because it changed.
      Compiling pandas/_libs/tslibs/base.pyx because it changed.
      Compiling pandas/_libs/tslibs/ccalendar.pyx because it changed.
      Compiling pandas/_libs/tslibs/conversion.pyx because it changed.
      Compiling pandas/_libs/tslibs/fields.pyx because it changed.
      Compiling pandas/_libs/tslibs/frequencies.pyx because it changed.
      Compiling pandas/_libs/tslibs/nattype.pyx because it changed.
      Compiling pandas/_libs/tslibs/np_datetime.pyx because it changed.
      Compiling pandas/_libs/tslibs/offsets.pyx because it changed.
      Compiling pandas/_libs/tslibs/parsing.pyx because it changed.
      Compiling pandas/_libs/tslibs/period.pyx because it changed.
      Compiling pandas/_libs/tslibs/resolution.pyx because it changed.
      Compiling pandas/_libs/tslibs/strptime.pyx because it changed.
      Compiling pandas/_libs/tslibs/timedeltas.pyx because it changed.
      Compiling pandas/_libs/tslibs/timestamps.pyx because it changed.
      Compiling pandas/_libs/tslibs/timezones.pyx because it changed.
      Compiling pandas/_libs/tslibs/tzconversion.pyx because it changed.
      Compiling pandas/_libs/testing.pyx because it changed.
      Compiling pandas/_libs/window/aggregations.pyx because it changed.
      Compiling pandas/_libs/window/indexers.pyx because it changed.
      Compiling pandas/_libs/writers.pyx because it changed.
      Compiling pandas/io/sas/sas.pyx because it changed.
      [ 1/40] Cythonizing pandas/_libs/algos.pyx
      [ 2/40] Cythonizing pandas/_libs/groupby.pyx
      [ 3/40] Cythonizing pandas/_libs/hashing.pyx
      [ 4/40] Cythonizing pandas/_libs/hashtable.pyx
      [ 5/40] Cythonizing pandas/_libs/index.pyx
      [ 6/40] Cythonizing pandas/_libs/indexing.pyx
      [ 7/40] Cythonizing pandas/_libs/internals.pyx
      [ 8/40] Cythonizing pandas/_libs/interval.pyx
      [ 9/40] Cythonizing pandas/_libs/join.pyx
      [10/40] Cythonizing pandas/_libs/lib.pyx
      [11/40] Cythonizing pandas/_libs/missing.pyx
      [12/40] Cythonizing pandas/_libs/ops.pyx
      [13/40] Cythonizing pandas/_libs/ops_dispatch.pyx
      [14/40] Cythonizing pandas/_libs/parsers.pyx
      [15/40] Cythonizing pandas/_libs/properties.pyx
      [16/40] Cythonizing pandas/_libs/reduction.pyx
      Traceback (most recent call last):
        File "/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_venv/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 132, in get_requires_for_build_editable
          return hook(config_settings)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-9_rt0pyj/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 441, in get_requires_for_build_editable
          return self.get_requires_for_build_wheel(config_settings)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-9_rt0pyj/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 325, in get_requires_for_build_wheel
          return self._get_build_requires(config_settings, requirements=['wheel'])
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-9_rt0pyj/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 295, in _get_build_requires
          self.run_setup()
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-9_rt0pyj/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 480, in run_setup
          super(_BuildMetaLegacyBackend, self).run_setup(setup_script=setup_script)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-9_rt0pyj/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 311, in run_setup
          exec(code, locals())
        File "<string>", line 792, in <module>
        File "<string>", line 762, in setup_package
        File "<string>", line 538, in maybe_cythonize
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-9_rt0pyj/overlay/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 1154, in cythonize
          cythonize_one(*args)
        File "/private/var/folders/f6/z7tvzpnx0wsckql3wh8837s00000gn/T/pip-build-env-9_rt0pyj/overlay/lib/python3.8/site-packages/Cython/Build/Dependencies.py", line 1321, in cythonize_one
          raise CompileError(None, pyx_file)
      Cython.Compiler.Errors.CompileError: pandas/_libs/reduction.pyx
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build editable did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.
Traceback (most recent call last):
  File "/Users/batuhanserce/PycharmProjects/Tests4Py/venv/bin/t4p", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/Users/batuhanserce/PycharmProjects/Tests4Py/src/tests4py/cli/__init__.py", line 608, in main
    raise report.raised
  File "/Users/batuhanserce/PycharmProjects/Tests4Py/src/tests4py/api/default.py", line 314, in build
    subprocess.check_call(
  File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['python', '-m', 'pip', 'install', '-r', PosixPath('/Users/batuhanserce/PycharmProjects/Tests4Py/tmp/pandas_1/tests4py_requirements.txt')]' returned non-zero exit status 1.


Not working with prettierd

Dependency information
prettierd, neovim
Steps to reproduce
run it with prettierd
The current behavior
Log file: /Users/premkumarsinha/.local/state/nvim/conform.log
additional information: expected '}'
      00:40:38[ERROR] Formatter 'prettierd' error:
      00:44:34[ERROR] Formatter 'prettierd' error:
      16:20:21[ERROR] Formatter 'prettierd' error:
      16:58:24[ERROR] Formatter 'prettierd' error:
      17:23:14[ERROR] Formatter 'prettierd' error:
      22:55:44[ERROR] Formatter 'stylua' error: error: could not format from stdin: failed to format from stdin: error parsing: error occurred while creating ast: unexpected token `he`. (starting from line 86, character 1 and ending on line 86, character 3)
      additional information: leftover token

      08:25:10[ERROR] Formatter 'prettierd' error:
      16:50:31[ERROR] Formatter 'prettierd' error:
      17:11:30[ERROR] Formatter 'prettierd' error:
      17:11:38[ERROR] Formatter 'prettierd' error:
      17:11:42[ERROR] Formatter 'prettierd' error:
      17:17:05[ERROR] Formatter 'prettierd' error:
      17:17:15[ERROR] Formatter 'prettierd' error:
      17:19:49[ERROR] Formatter 'prettierd' error:
      17:22:18[ERROR] Formatter 'prettierd' error:
      17:24:54[ERROR] Formatter 'prettierd' error:

Hey, I haven't used prettierd and neovim yet.
Could you please provide more details on how to reproduce it?
To investigate the problem, I also need information such as what prettier-related dependencies are being used and how the prettier configuration is set up.


Component | Axis: Adding css vars for axis line widths

Adds --vis-axis-tick-line-width and --vis-axis-grid-line-width to set their respective properties

CLA submitted 👍

@yanneves I've just release version 1.1.2-beta.1 with your changes.


Communications link failure during commit(). Transaction resolution unknown.

2014 12:13:56] com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Communications link failure during commit(). Transaction resolution unknown.
    at com.nhl.link.framework.etl.runtime.jdbc.JdbcRowReader.close(JdbcRowReader.java:50)

I guess that's a MySQL connection timeout and is a function of MySQL DataSource settings and the duration of the job. So while not directly related to link-etl, perhaps this should give us a motivation to read source data in chunks.

Not a LinkETL issue. Should be fixed on the app end. If newest Cayenne 4.0.M3 DataSourceBuilder is in use, the problem should go away.