Several changes to support why.init for authenticated users

Add org id and default dataset id support to sessions.
Make sessions depend on the new api key format and update the api key validation to allow for longer api keys that include :orgId.
Remove explicit session type configuration and define a fallback system for selecting session type based on allow* flags, config, and env state.
Allow specifying default dataset directly to the session config as an alternative to env variables, which is how sessions treat api keys.
Add interactive prompt mode for notebook environments that gets api key and related config via input() and saves it to the new whylogs ini config.
Add two new files as pseudo CLIs for setting api key/default model id in the whylogs config. Without this, the only way to set the config is via interactive prompt. Supplying that info via env vars doesn't result in persisting that to the config which would be a strange side effect at best since the env is presumably still around and definitely taking priority over the config value.
Enable interactive log output and url generation for batch profiles, with or without authentication. This output is disabled in local mode since no uploading happens there. The output only happens when using the top level transient logger in why.log. The loggers themselves don't have any output logic at all. It wouldn't make much sense to add output of this sort to the rolling logger running in the background.
Add lots of docs to why.init since that's the main interface to this system for users. The goal with these docs is to make it clear what kind of session you'll be getting since the logic is a little more complicated than before. The upside to this approach is that most notebooks, scripts, and production jobs can just have why.init() and not worry about what arguments to supply, so it can truly be ubiquitous.

Reviewing
To get a sense of the UX introduced here, I recommend running the Guest Session example notebook, as well as running python -m whylogs.api.whylabs.session.why_init from the command line. The first one should be pretty representative of a typical user experience after this change and the second one is a psuedo-cli that users can use to repeat the first UX without having to spin up a notebook. The command is similar to running aws sso configure, it just gets everything it needs from a user and stores it locally in the new whylogs.ini config.

I'm currently working on a doc page for this new auth system on docs.whylabs.ai. I link to it in several places since the logic can be pretty verbose. It will be here when I'm done and we should hold off on merging until I finish https://docs.whylabs.ai/docs/whylabs-whylogs-init

@jamie256 @andyndang Looks like there are 36 different example notebooks that included WHYLABS_API_KEY. All of those will have to be updated. I'm going to hold off on touching those until I know this PR and the new doc page look good though. I have to take an inventory of the things that need to change on the doc site as well.

I just ran the Writing_Regression_Performance_Metrics_to_WhyLabs without any changes on this branch, and some things to note:
* There are some rather spammy messages, when logging:

  * `😭 No active session found because why.init() wasn't used. Skipping reference profile upload. Start a session with why.init(session_type='whylabs_anonymous') writing profiles to whylabs...`

* and also when calling `results.writer("whylabs").write()`:

  * `Initialing session with config /home/felipeadachi/.config/whylogs/config.ini Initialing session with config /home/felipeadachi/.config/whylogs/config.ini No session is initialized. Call whylogs.init(anonymous=True) to create a guest session. No session is initialized. Call whylogs.init(anonymous=True) to create a guest session.`

This feels like something wrong is happening, but I'm just logging the usual way by setting os.environ (and it works normally)
Maybe we could set this as info instead of warning? Or is this now an unrecommended approach, and we always want to call why.init()?

This has been fixed. You'll now only see the warning one time and you won't see any other output unless you actually have a session, so if people run that notebook before we update it with our latest whylogs then they'll just see a warning that they don't have a session set up.


Crate bonus only applies at moment of reloading.

Refill-crate bonuses set a missile's 'time-to-usable' parameter, which means you can't accelerate a reload mid-way.  Change reload timer to a reload accumulator, and increase accumulation rate based on the refill bonus.

Done in eb131d6ed1d503f97da75faeaa3a0267a6d5d21a


index-aware map method

Ref. https://github.com/observablehq/plot/pull/1553#issuecomment-1548266009

I added some tests for custom map methods.


Upgrade to Irmin 2.0 API

Compiles, but the tests fail with: runtime.caml_encore_is_a_sub is not a function
Blocked by https://github.com/mirage/encore/issues/13

Added a work-around for the missing JS functions.


image property added to article posts

Is this related to the Markdown editor? Where is it coming from? Need to investigate.

Looks like EasyMDE appends the last image uploaded to formData:
https://github.com/Ionaru/easy-markdown-editor/blob/f039bae67f62509270aaf4b7e511b338f0f8c0ba/src/js/easymde.js#L2456
Removed this value in 2139877b4710d3c31c2dcdf6a45396a41d750227


Make default_branch nullable?

I noted that GitLab API may return "default_branch": null, for empty repos, which is transforms to the empty string through go-gitlab. It is probably a minor issue, because empty string is probably an invalid value for default_branch, but still - maybe it is better to return nil if it is not set?

@abitrolly the API client is designed like this on purpose. Of course it's always debatable, but I found that having to null check and de-reference everywhere when you are trying to use a value is much more annoying then sometimes having to check a value. And to introduce it only for some fields would make the client much less consistent to use (you would have to check each field to see if it's a pointer or now). So I'm not really open to changing this, sorry!

@svanharmelen does something like https://github.com/guregu/null help?

I usually use https://github.com/gobuffalo/nulls which is a similar package... So I am aware of these solutions, but think they weren't used that much when this package was originally created. And adding that now for all applicable fields would be a very big change which would cause backwards issues for every single user using this client.
I must admit it's an interesting idea, but I'm not sure if I would want to introduce it now...

Fair enough. Maybe next version. )


[MINOR][Core] fix warnings on depreciated methods in MesosClusterSchedulerSuite and DiskBlockObjectWriterSuite

What changes were proposed in this pull request?
Fixed warnings below after scanning through warnings during build:
[warn] /home/jenkins/workspace/SparkPullRequestBuilder/core/src/test/scala/org/apache/spark/scheduler/cluster/mesos/MesosClusterSchedulerSuite.scala:34: imported `Utils' is permanently hidden by definition of object Utils in package mesos
[warn] import org.apache.spark.scheduler.cluster.mesos.Utils
[warn]                                                 ^

and
[warn] /home/jenkins/workspace/SparkPullRequestBuilder/core/src/test/scala/org/apache/spark/storage/DiskBlockObjectWriterSuite.scala:113: method shuffleBytesWritten in class ShuffleWriteMetrics is deprecated: use bytesWritten instead
[warn]     assert(writeMetrics.shuffleBytesWritten === file.length())
[warn]                         ^
[warn] /home/jenkins/workspace/SparkPullRequestBuilder/core/src/test/scala/org/apache/spark/storage/DiskBlockObjectWriterSuite.scala:119: method shuffleBytesWritten in class ShuffleWriteMetrics is deprecated: use bytesWritten instead
[warn]     assert(writeMetrics.shuffleBytesWritten === file.length())
[warn]                         ^
[warn] /home/jenkins/workspace/SparkPullRequestBuilder/core/src/test/scala/org/apache/spark/storage/DiskBlockObjectWriterSuite.scala:131: method shuffleBytesWritten in class ShuffleWriteMetrics is deprecated: use bytesWritten instead
[warn]     assert(writeMetrics.shuffleBytesWritten === file.length())
[warn]                         ^
[warn] /home/jenkins/workspace/SparkPullRequestBuilder/core/src/test/scala/org/apache/spark/storage/DiskBlockObjectWriterSuite.scala:135: method shuffleBytesWritten in class ShuffleWriteMetrics is deprecated: use bytesWritten instead
[warn]     assert(writeMetrics.shuffleBytesWritten === file.length())
[warn]                         ^

How was this patch tested?
Tested manually on local laptop.

Test build #63638 has started for PR 14609 at commit 9aeadeb.

Test build #63638 has finished for PR 14609 at commit 9aeadeb.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63638/
Test FAILed.

Test build #63650 has started for PR 14609 at commit 75b6c22.

Test build #63650 has finished for PR 14609 at commit 75b6c22.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63650/
Test FAILed.

Test build #63659 has started for PR 14609 at commit c8bab2f.

Test build #63659 has finished for PR 14609 at commit c8bab2f.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class JacksonParser(

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63659/
Test FAILed.

Deprecated methods may still be used in tests because they still need testing. As in the PR, these are not necessarily things to be changed. However I am not sure these usages are for the purpose of testing the deprecated methods, given their descriptions. I think this is OK to change. It does appear to mean things like shuffleBytesWritten has no test as a result, but, it's probably OK as it's clearly going to stay implemented as a simple alias.

Thanks a lot Sean. Actually, I run these tests on my laptop and they all pass. And also, it built several times on Spark Jenkins, and every time it fails at different suites (like random failure).
More is that the failure msg is saying class JacksonParser  is added but what I did is just a tiny touch on the tests.
This patch adds the following public classes (experimental):
class JacksonParser(

Maybe better I just close this one

Test build #63697 has started for PR 14609 at commit d71446d.

I'm quite sure the failure is spurious, as is the MiMa warning (it's just grepping the commit log for "class")

Jenkins retest this please

Test build #63698 has started for PR 14609 at commit d71446d.

Test build #63698 has finished for PR 14609 at commit d71446d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63698/
Test FAILed.

Merged build finished. Test FAILed.

Test build #63697 has finished for PR 14609 at commit d71446d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63697/
Test PASSed.

Merged build finished. Test PASSed.

hi @srowen , above 2 builds are using exactly the code but one failed and the other passed. I checked the failed reason and it's org.apache.spark.sql.hive.HiveSparkSubmitSuite, different from all previous failure reasons.
Maybe this one is beyond my capability to solve...

Yeah it's just a flaky test. Although people try to fix those over time, with thousands of integration tests, a few can be like that.

Merged to master


file.css(.scss).erb causes File to import not found or unreadable

Using the ERB handler breaks reading/importing the files…
This works:
// application.css.scss:
@import 'tester'

// tester.css(.scss)
body { color: #ABC; }

This does not:
// application.css.scss:
@import 'tester'

// tester.css(.scss).erb
body { color: #ABC; }

Sass::SyntaxError: File to import not found or unreadable
At first I thought it was related to #119 or #94, but those fixes don't solve my problem. I do use Rails 4.0.0.beta1 (together with sass-rails 4.0.0.beta1), so perhaps this could be related?

I also have this issue with rails <IP_ADDRESS>. Imports to .scss.erb are found, but not rendered with erb. I tried it with the 'sass_rails_patch' gem/path, but doesn't work. Any hints maybe?

Lol, having the same problem again after 1,5 years...

I;m still having the same issue. sass-rails (5.0.6).  "rails", "~> 5.1.0.beta1"

Yep appears to have been a regression at some point.
ActionView::Template::Error (File to import not found or unreadable: /Users/jrochkind/code/chf-sufia/app/assets/stylesheets/local/chf_image_viewer.scss.erb.
Rails 5.0.6, sass-rails 5.0.6.

same issue, dump https://pastebin.com/iHxpZvzt

It looks like .scss.erb file doesn't work in subfolders, moving it to the assets/stylesheets folder directly worked for me.

a year later and I'm experiencing the same problem - does .scss.erb still not work in subfolders with sprockets 4 manifest? or is my setup wrong somehow?

@elialbert I think the problem is that the ./app/assets/config/manifest.js is set up to try including all of your .scss files as top level CSS files, while some of them are only meant to be included in other SCSS, not as top-level. So you can edit the manifest.js to instead include only those .scss you mean to be top-level.
A confusing thing is that manifest.js has been in Rails apps for a while, but only starts being used once you upgrade to Sprockets 4, due to some conditional logic in sass-rails. Before Sprockets 4, it is ignored.
I tried to write up what I could figure out about what's going on here: https://bibwild.wordpress.com/2019/10/15/sprockets-4-and-your-rails-app/
It is all very confusing; the greatly extended timeframe for the sprockets 3->4 upgrade led to different developers doing different things at different times, not all of which play well together, which became activated only when sprockets 4 was actually released.

haha yeah thanks so much! I will read your blogpost but like, downgrading back to 3.7.2 is working just fine for right now so that's probably where we'll land.
thousands of rails devs all sitting on sprockets 3 waiting for someone else to fix the last things in the upgrade path...

I don't believe the sprockets and sprockets-rails maintainers (who are not me) currently consider it broken. So there is no point in waiting for it to be "fixed" (unless you can change their minds), you just need to figure out the right way to use sprockets 4 with rails as it is.
It is true that upgrading from sprockets 3 to 4 may require some changes in your app to work -- either in the manifest.js, or in where you put your .sccs files on disk.
But you don't have to use sprockets 4, you can keep using sprockets 3, correct.

that was a good blog post


Replace unmaintained/outdated GitHub Actions

The actions-rs/* actions are replaced with dtolnay/rust-toolchain and plain cargo commands.

Thanks! Should be good. (on the main nushell repo we use a fork of the dtolnay actions but this is fine as well as they are in good hands)


fix: Allow singleton channel in convenience functions

Description
Following https://github.com/CAREamics/careamics/issues/159, this PR allows creating a configuration with a singleton channel via the configuration convenience functions.

What: Allow singleton channel in convenience functions.
Why: In some rare cases, a singleton channel might be present in the data.
How: Change the if statements and error raising conditions of the convenience functions.

Changes Made

Modified: configuration_factory.py.

Related Issues

Fixes Allow singleton channel in convenience functions

Please ensure your PR meets the following requirements:

[x] Code builds and passes tests locally, including doctests
[x] New tests have been added (for bug fixes/features)
[x] Pre-commit passes
[x] PR to the documentation exists (for bug fixes / features)

@melisande-c the CLI tests are failing, in case you've encountered that before, could you comment?

@jdeschamps The traceback for the CLI is not the best, not sure how to fix it. What is happening is that the command fails, but all we see is the assertion error that the checkpoint wasn't created. Going through debug mode I found the function call causing the problem which results in the following pydantic error:
Traceback (most recent call last):
  File "/home/melisande.croft/Documents/Repos/careamics/src/careamics/config/configuration_factory.py", line 472, in create_care_configuration
    return _create_supervised_configuration(
  File "/home/melisande.croft/Documents/Repos/careamics/src/careamics/config/configuration_factory.py", line 311, in _create_supervised_configuration
    return _create_configuration(
  File "/home/melisande.croft/Documents/Repos/careamics/src/careamics/config/configuration_factory.py", line 181, in _create_configuration
    unet_model = _create_unet_configuration(
  File "/home/melisande.croft/Documents/Repos/careamics/src/careamics/config/configuration_factory.py", line 112, in _create_unet_configuration
    return UNetModel(
  File "/localscratch/miniforge3/envs/careamics/lib/python3.10/site-packages/pydantic/main.py", line 193, in __init__
    self.__pydantic_validator__.validate_python(data, self_instance=self)
pydantic_core._pydantic_core.ValidationError: 1 validation error for UNetModel
num_classes
  Input should be greater than or equal to 1 [type=greater_than_equal, input_value=-1, input_type=int]
    For further information visit https://errors.pydantic.dev/2.8/v/greater_than_equal

Brilliant, thanks!


Upgrade packages

Upgrade npm dependencies
"babel-eslint": "10.x",
"babel-jest": "24.x",
"jest": "24.x",
"react-cosmos": "4.7.x",
"react-cosmos-test": "4.7.x",

Pull Request Test Coverage Report for Build 1045

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 86.867%

Totals

Change from base Build 835:
0.0%

Covered Lines:
2762

Relevant Lines:
3041

💛  - Coveralls


Backport fix(tsi): clean up FileSet fields to 1.9

Backports https://github.com/influxdata/influxdb/pull/18961 to 1.9

Closed by #22047


Add getServerSnapshot, fix loop on SSR Subscribe

Fixes #305
Something important to keep in mind is that in SSR any children within a Subscribe will not render, because given that components never mount in SSR (including <Subscribe>), it will never get into the stage of rendering the children.
And StateObservable with top-level subscriptions will have their state shared between clients.

Does this means one should not use this in server side components?

Does this means one should not use this in server side components?

At the moment I don't really have an answer for this, I haven't played that much with SSR or server-side components.
It's just important to keep in mind that in server-side:

Anything inside <Subscribe> will not render. <Subscribe> is used to subscribe to a source$ before the children are rendered. If <Subscribe> can't subscribe to the source because it never gets mounted, then it will never render its children.
StateObservables with defaultValue will return their default value (just as normal).
Any StateObservables with a subscription somewhere else (e.g. a top-level subscription) will have their state shared between every render. This could be useful, or it could be annoying to get around.

My best advice (again, without having played that much with SSR/NextJS) is to have every StateObservable with a defaultValue on those components that will run on the Server. It gives the most predictable and simple results: They will return the defaultValue while on the server, and execute the subscription when on the client.
Maybe on a future we can leverage something like https://github.com/reactjs/rfcs/pull/229 so that server components also subscribe to the observables, but there are some serious questions regarding cancellation and state sharing.


[✨] Qwik better DX

Is your feature request related to a problem?
I have problem with ability to create good architecture of app with qwik. Now Qwik give us React-like experience with hooks, state and lifecycle hooks. And do not give us good way of handling big apps.
Describe the solution you'd like
Let's look at some state managers. Reatom give us ability to create Atoms (signals) outside of components and handle data fetching outside of components.
We can do even this:

Effector STM handle logic and data fetching and with Effector we can construct a lot of logic in declarative manner.

With atomic router we can even separate data fetching from lifecycle hooks: for example, on page change event Effector with Atomic Router can call Effect with data fetching and call route change via Atomic Router. And know we do not depend on lifecycle hooks - View of App reacts to the model, but not vice versa
Vue give us ability to separate view from model with templates. Angular give templates, DI. And what give us Qwik? How we can handle big apps? A lot of hooks inside components? But Why? Why we can't create new architecture - new way of app building? Why we using the same principles that React gave us many years ago? Yes Qwik is good performant framework but it's not enough today. We need easy way of working with business logic, easy way of scalability.
Qwik even do not have package for forms - its basic thing for frontend Framework. I wanna have all in one solution if its called 'framework'.
Describe alternatives you've considered
All in one solution for handling big projects.
Additional context
No response

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.


Hardware requirements?

Could we list the hardware requirements or the hardware it's been tested on at the moment?
So I can see it's using the WGPU backend do you know roughly how much VRAM is needed?
Thanks.

I have same question. And does it works on Apple Silicon, M1/M2?

I'm currently getting No CPU device found on M2 when trying to run the convert binary.

I'm currently getting No CPU device found on M2 when trying to run the convert binary.

I'll check with the burn team about this.
Once the burn caching functions are public I'll try benchmarking it.


Add declarators for declaring declarators, and declarator execution system.

Part of the key promise of the way we did the syntax in this language is that users will be able to declare custom declarators. That's the key reason why we have the silly colon symbol at the start of every declaration line instead of baking those declarators as keywords into the parser.
The goal is to enable expressive and powerful DSLs, hopefully without getting too esoteric (though some level of esotericism with metaprogramming is inevitable).
There are two planned layers of customizable metaprogramming: "declarators" and "macros". The key difference is that "declarators" are used and expanded in a top-level declarative context (like type and function declarations), whereas "macros" are used and expanded inline with imperative expressions in an imperative context (like a function body).
The scope of this ticket is handle the former, and the latter will be tackled in a different ticket at a later time.
In general, custom declarators are intended to be used in shorthand declarations for generating longer declarations. For example, one might declare :auto Equatable within a class definition to have it automatically generate a suitable == method for the class for automatic structural equality.
When the compiler is loading the source files in a package, it will read and comprehend the declarations of all types in the package, but it will also read and comprehend any declarations of custom declarators, and load those into the declaration evaluation context. So any package that depends on that package can now use not only the types that package declared, but they can also use the declarators.
When a declaration is encountered, its "head" (the line beginning with the colon) will be matched against the set of all known declarators, based on the following factors:

a valid context (for example, a standard function declaration is only found within the context of a type declaration)
an initial keyword (for example, the word fun in a standard function declaration)
an ordered list of terms, including some optional and some required terms, with some terms matching as a literal keyword and some terms matching an expected type of term (for example, a standard function declaration has an optional capability term, followed by a name term qualified by a parameter list, followed by an optional return type).

Note that it is possible for more than one custom declarator to use the same initial keyword, and have the other factors be used to distinguish them. A custom declarator may even use the same initial keyword as a standard declarator, but in this case it would be best practice to ensure that it is clearly distinguished in some other way, such as with a clear keyword found later in the terms list. In the case of more than one in-scope declarator matching, the one that was declared first will be used, so it is not possible for a custom declarator to shadow a standard declarator.
When all of the factors are matched, we have a valid declaration matched against the matching declarator, and that declarator will then be evaluated to generate one or more declarations.
Inside one of the "generate" declarations of a custom declarator, we will have two new macros present: a generate macro and an inject macro, which will be used in a similar way to the quote and unquote expressions that are used in Elixir macros, so that generated code can be declared inline the context of the meta-code that is generating it. The meta-code is evaluated at compile time during declaration evaluation using a special evaluation engine that only understands certain limited syntax forms, and is not intended to be a full language environment.

To illustrate a proposed design, here are some examples of custom declarators that would automatically generate an == method and an inspect_into method, respectively. Note that they both use the same initial keyword, and they are distinguished by their next term, which is a distinct keyword that happens to match the trait they are generating for.

Generating for the Equatable trait
:declarator auto
  :context type

  :keyword Equatable

  :term field_names IdentifierList
    :default: @terms.field_names

  :generate is Equatable(@)

  :generate fun "=="(other @'box) Bool
    @terms.field_names.each -> (field_name |
      generate (
        return False unless @.(inject field_name) == other.(inject field_name)
      )
    )
    generate True

This would be used as:
:class Person
  :auto Equatable
  // OR
  :auto Equatable (name, age)

And would generate the follow declarations inside Person:
  :is Equatable(@)

  :fun "=="(other @'box) Bool
    return False unless @.name == other.name
    return False unless @.age == other.age
    True

Generating for the Inspectable trait
:declarator auto
  :context type

  :keyword Inspectable

  :term field_names IdentifierList
    :default: @terms.field_names

  :generate is Inspectable

  :generate fun inspect_into(output String'iso) String'iso
    generate (
      output << (
        inject StringLiteral.new(["<", type_name.value]).from(type_name)
      )
    )
    @terms.field_names.each -> (field_name |
      generate (
        output << " "
        output = @.(inject_field_name).inspect_into(--output)
      )
    )
    generate (
      output << ">"
    )
    generate --output

This would be used as:
:class Person
  :auto Inspectable
  // OR
  :auto Inspectable (name, age)

And would generate the follow declarations inside Person:
  :is Inspectable

  :fun inspect_into(output String'iso) String'iso
    output << "<Person"
    output << " "
    output = @.name.inspect_into(--output)
    output << " "
    output = @.age.inspect_into(--output)
    output << ">"
    --output

Note that there are probably ways to better optimize how inspect_into is implemented, but that's not really the scope of thise discussion - this is just an example of some generated code from a declarator. Improving the inspect_into system (including smart markers for line wrapping, similar to the "pretty printing" system in Crystal) is something that can happen in a separate effort.

I'm working on part of the work related to this because it is required to support indentation of the code formatting system.
That is, the formatter needs to be able to know what the nesting level is of a given declarator, and for that, it needs to have access to a system that knows about what declarators exist and what their scope is.
For example, the formatter needs to know that a :fun declarator is nested within a :class declarator that precedes it, and that seeing another :class declarator resets to the top scope of indentation.

This is now partially done in commit https://github.com/savi-lang/savi/commit/ed43dca19b84e63624841cc138d56056f3f65492
What's still missing:

documentation for the standard declarators
adding the :generate declarator and generate macro - this is the major remaining piece for this ticket
some other bits and pieces (see TODO comments in that aforementioned commit)


aggregate calculates wrong time if used with --current

If aggregate is used with --current and it takes more than the current day into account, the calculation of the current aggregated day is wrong.
Example:
$ watson status
Project xy started 2 hours ago (2019.07.04 10:26:45+0200)

$ watson log -dc
Thursday 04 July 2019 (2h 17m 31s)
        current  10:26 to 12:44   2h 17m 31s  xy

$ watson report -dc
Thu 04 July 2019 -> Thu 04 July 2019

xy - 2h 17m 50s

$ watson aggregate -c --from 2019-07-03
Wed 03 July 2019 - 7h 17m 42s
  xy - 7h 17m 42s

Thu 04 July 2019 - 4h 36m 51s
  xy - 4h 36m 51s

Expected result of Thu 04 July 2019: 2h 17m ??s
Expected result of Thu 04 July 2019: 4h 36m 51s

The current frame is added once for every day the report is generated.

Thanks for looking at it!


Compatibility issue with ZodCatch

Describe the bug and the expected behavior
If I add a .catch() to a z.number() schema, parseWithZod() always returns the catch value, even with a valid input that matches the Zod schema.
Conform version
v1.0.0-rc.1
Steps to Reproduce the Bug or Issue
Minimal reproduction: https://stackblitz.com/edit/remix-run-remix-qxwt5m?file=app%2Froutes%2F_index.tsx
Expected behaviour:
const schema = z.object({
  page: z.number().int().min(1).safe().catch(1),
});

expect(
  parseWithZod(new URLSearchParams('page=2'), {
    schema,
  })
).toEqual({
  status: 'success',
  payload: {
    page: '2',
  },
  value: {
    page: 2,
  },
  reply: expect.any(Function),
});

Actual behaviour: value is always equal to { page: 1 }.
What browsers are you seeing the problem on?
No response
Screenshots or Videos
No response
Additional context
The use case here is validating searchParams, where unlike formData you probably just want to fall back to valid values and ignore invalid ones.
If you remove the .catch() from the schema, it works as expected—but of course then you can't fall back to valid values.

Looks like safe and catch is not implemented for the introspection so it is not able to inject the preprocess step to z.number() and fails because "2" is not a number 😅 Feel free to make a PR.

This is release in v1.0.0.


Window.set_visible segfault on Wayland with gtk4_layer_shell

Bug description
Important: Only relevant to Wayland on Linux
Segfault only occurs after using gtk4_layer_shell::init_for_window to setup a
window. Using gtk::Window.set_visible then has a small chance to cause a
segfault. I've included a minimal repro to create a window, initialize it with
layer shell, and then toggle its visibility rapidly in order to make the
segfault occur faster.

Tested on compositors: Sway, Hyprland
Operating system: Arch Linux x86_64
Locally installed libraries:

gtk4 1:4.10.4-1
gtk4-layer-shell 1.0.0-1

Minimal repro
Cargo.toml
[package]
authors = [ "fr33zing" ]
name = "gtk4-layer-shell-segfault-repro"
version = "0.1.0"
edition = "2021"

[dependencies]
gtk4 = "0.6.6"
gtk4-layer-shell = "0.0.3"

main.rs
use std::{
    cell::RefCell,
    io::{self, Write},
    time::Duration,
};

use gtk::{glib, prelude::*, Application, ApplicationWindow};
use gtk4 as gtk;

const TOGGLE_VISIBLE_INTERVAL: Duration = Duration::from_millis(10);

fn main() -> glib::ExitCode {
    let app = Application::builder()
        .application_id("lets.cause.a.segfault")
        .build();

    app.connect_activate(|app| {
        let window = ApplicationWindow::builder().application(app).build();

        println!("calling gtk4_layer_shell::init_for_window");
        gtk4_layer_shell::init_for_window(&window);

        println!("toggling visibility rapidly");
        let count = RefCell::new(0);
        glib::timeout_add_local(TOGGLE_VISIBLE_INTERVAL, move || {
            let visible = !window.get_visible();
            window.set_visible(visible);

            let mut count = count.borrow_mut();
            *count += 1;

            println!("<{count}, {visible}>");
            io::stdout().flush().unwrap();

            Continue(true)
        });
    });

    app.run()
}

cargo log
Command:
RUST_BACKTRACE=full cargo run

Output:
calling gtk4_layer_shell::init_for_window
toggling visibility rapidly
<1, true>
<2, false>
<3, true>
<4, false>

...MANY MORE LINES OF THIS...

<39, true>
<40, false>
<41, true>
<42, false>
<43, true>
malloc(): unaligned fastbin chunk detected
zsh: IOT instruction (core dumped)  RUST_BACKTRACE=full cargo run

rust-gdb log
Command:
cargo build && rust-gdb ./target/debug/gtk4-layer-shell-segfault-repro

Output:
cargo build && rust-gdb ./target/debug/gtk4-layer-shell-segfault-repro
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
GNU gdb (GDB) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./target/debug/gtk4-layer-shell-segfault-repro...
(gdb) r
Starting program: /home/fr33zing/code/gtk4-layer-shell-segfault-repro/target/debug/gtk4-layer-shell-segfault-repro
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff37ff6c0 (LWP 132514)]
[New Thread 0x7ffff2ffe6c0 (LWP 132515)]
[New Thread 0x7ffff27fd6c0 (LWP 132516)]
[New Thread 0x7ffff1ffc6c0 (LWP 132517)]
[New Thread 0x7ffff17fb6c0 (LWP 132518)]
[Thread 0x7ffff1ffc6c0 (LWP 132517) exited]
[New Thread 0x7ffff1ffc6c0 (LWP 132519)]
calling gtk4_layer_shell::init_for_window
toggling visibility rapidly
[Detaching after fork from child process 132520]
[New Thread 0x7fffcf5ff6c0 (LWP 132521)]
[New Thread 0x7fffcedfe6c0 (LWP 132522)]
[New Thread 0x7fffce5fd6c0 (LWP 132523)]
[New Thread 0x7fffcddfc6c0 (LWP 132524)]
[New Thread 0x7fffcd3fb6c0 (LWP 132525)]
[New Thread 0x7fffccbfa6c0 (LWP 132526)]
[New Thread 0x7fffb7fff6c0 (LWP 132527)]
[New Thread 0x7fffb77fe6c0 (LWP 132528)]
[New Thread 0x7fffb6ffd6c0 (LWP 132529)]
[New Thread 0x7fffb67fc6c0 (LWP 132530)]
[New Thread 0x7fffb5ffb6c0 (LWP 132531)]
[New Thread 0x7fffb57fa6c0 (LWP 132532)]
<1, true>
<2, false>
<3, true>
<4, false>
<5, true>

...MANY MORE LINES OF THIS...

<93, true>
<94, false>
<95, true>
<96, false>
<97, true>
malloc(): unaligned tcache chunk detected

Thread 1 "gtk4-layer-shel" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44	     return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) backtrace
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff704d2d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff6ffda08 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff6fe6538 in __GI_abort () at abort.c:79
#4  0x00007ffff6fe72db in __libc_message (fmt=fmt@entry=0x7ffff7161515 "%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5  0x00007ffff70571b7 in malloc_printerr (str=str@entry=0x7ffff7164908 "malloc(): unaligned tcache chunk detected")
    at malloc.c:5651
#6  0x00007ffff705b98c in tcache_get (tc_idx=<optimized out>) at malloc.c:3171
#7  __GI___libc_malloc (bytes=bytes@entry=40) at malloc.c:3289
#8  0x00007ffff7210423 in g_malloc (n_bytes=40) at ../glib/glib/gmem.c:130
#9  0x00007ffff724b832 in g_variant_make_tuple_type (children=0x5555563ed250, n_children=5) at ../glib/glib/gvariant.c:838
#10 0x00007ffff7255c0d in g_variant_builder_end (builder=builder@entry=0x7fffffffc340) at ../glib/glib/gvariant.c:3764
#11 0x00007ffff725627c in g_variant_valist_new (str=0x7fffffffc3f8, app=0x7fffffffc420) at ../glib/glib/gvariant.c:5303
#12 0x00007ffff72567fd in g_variant_new_va (format_string=<optimized out>,
    format_string@entry=0x7ffff7af861e "(siiva{sv})", endptr=endptr@entry=0x0, app=app@entry=0x7fffffffc420)
    at ../glib/glib/gvariant.c:5476
#13 0x00007ffff7256932 in g_variant_new (format_string=format_string@entry=0x7ffff7af861e "(siiva{sv})")
    at ../glib/glib/gvariant.c:5411
#14 0x00007ffff7914c18 in emit_defunct (self=0x55555572bad0) at ../gtk/gtk/a11y/gtkatspicontext.c:780
#15 gtk_at_spi_context_unrealize (context=0x55555572bad0) at ../gtk/gtk/a11y/gtkatspicontext.c:1465
#16 0x00007ffff785d708 in gtk_at_context_unrealize (self=0x55555572bad0) at ../gtk/gtk/gtkatcontext.c:767
#17 gtk_at_context_unrealize (self=0x55555572bad0) at ../gtk/gtk/gtkatcontext.c:761
#18 gtk_widget_unroot_at_context (self=<optimized out>) at ../gtk/gtk/gtkwidget.c:2412
#19 0x00007ffff7871e4a in gtk_window_unmap (widget=0x55555570e8b0) at ../gtk/gtk/gtkwindow.c:3972
#20 0x00007ffff7f3cbc9 in _g_closure_invoke_va
    (param_types=0x0, n_params=<optimized out>, args=0x7fffffffc700, instance=0x55555570e8b0, return_value=0x0, closure=0x555555717460) at ../glib/gobject/gclosure.c:895
#21 g_signal_emit_valist (instance=0x55555570e8b0, signal_id=64, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc700)
    at ../glib/gobject/gsignal.c:3472
#22 0x00007ffff7f3cd34 in g_signal_emit (instance=instance@entry=0x55555570e8b0, signal_id=<optimized out>, detail=detail@entry=0)
    at ../glib/gobject/gsignal.c:3622
#23 0x00007ffff785e7fd in gtk_widget_unmap (widget=0x55555570e8b0) at ../gtk/gtk/gtkwidget.c:2879
#24 gtk_widget_unmap (widget=0x55555570e8b0) at ../gtk/gtk/gtkwidget.c:2867
#25 0x00007ffff7871de7 in gtk_window_hide (widget=0x55555570e8b0) at ../gtk/gtk/gtkwindow.c:3855
#26 0x00007ffff7f3cbc9 in _g_closure_invoke_va
    (param_types=0x0, n_params=<optimized out>, args=0x7fffffffc9a0, instance=0x55555570e8b0, return_value=0x0, closure=0x5555556d57f0) at ../glib/gobject/gclosure.c:895
#27 g_signal_emit_valist (instance=0x55555570e8b0, signal_id=62, detail=<optimized out>, var_args=var_args@entry=0x7fffffffc9a0)
    at ../glib/gobject/gsignal.c:3472
#28 0x00007ffff7f3cd34 in g_signal_emit (instance=instance@entry=0x55555570e8b0, signal_id=<optimized out>, detail=detail@entry=0)
    at ../glib/gobject/gsignal.c:3622
#29 0x00007ffff785eee7 in gtk_widget_hide (widget=0x55555570e8b0) at ../gtk/gtk/gtkwidget.c:2776
#30 0x0000555555562277 in gtk4::auto::widget::{impl#2}::set_visible<gtk4::auto::application_window::ApplicationWindow>
    (self=0x55555568c3c8, visible=false)
    at /home/fr33zing/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gtk4-0.6.6/src/auto/widget.rs:1859
#31 0x0000555555566967 in gtk4_layer_shell_segfault_repro::main::{closure#0}::{closure#0} () at src/main.rs:25
#32 0x0000555555563a04 in glib::source::trampoline_local<gtk4_layer_shell_segfault_repro::main::{closure#0}::{closure_env#0}>
    (func=0x55555568c3b0, func@entry=<error reading variable: value has been optimized out>)
    at /home/fr33zing/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glib-0.17.10/src/source.rs:114
#33 0x00007ffff720921e in g_timeout_dispatch (source=0x55555573f000, callback=<optimized out>, user_data=<optimized out>)
    at ../glib/glib/gmain.c:5054
#34 0x00007ffff7208981 in g_main_dispatch (context=0x555555604350) at ../glib/glib/gmain.c:3460
#35 g_main_context_dispatch (context=0x555555604350) at ../glib/glib/gmain.c:4200
#36 0x00007ffff7265b39 in g_main_context_iterate.isra.0
    (context=context@entry=0x555555604350, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../glib/glib/gmain.c:4276
#37 0x00007ffff7206032 in g_main_context_iteration (context=context@entry=0x555555604350, may_block=may_block@entry=1)
    at ../glib/glib/gmain.c:4343
#38 0x00007ffff73d5ed6 in g_application_run (application=0x5555556011c0, argc=<optimized out>, argv=0x555555603220)
    at ../glib/gio/gapplication.c:2573
#39 0x0000555555564ede in gio::application::{impl#0}::run_with_args<gtk4::auto::application::Application, alloc::string::String>
    (self=0x7fffffffcf90, args=&[alloc::string::String](size=1) = {...})
    at /home/fr33zing/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gio-0.17.10/src/application.rs:37
#40 0x0000555555564ff9 in gio::application::{impl#0}::run<gtk4::auto::application::Application> (self=0x7fffffffcf90)
    at /home/fr33zing/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gio-0.17.10/src/application.rs:30
#41 0x000055555556524c in gtk4_layer_shell_segfault_repro::main () at src/main.rs:37
#42 0x00005555555645fb in core::ops::function::FnOnce::call_once<fn() -> glib::exit_code::ExitCode, ()> ()
    at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/ops/function.rs:250
#43 0x0000555555563c8e in std::sys_common::backtrace::__rust_begin_short_backtrace<fn() -> glib::exit_code::ExitCode, glib::exit_co--Type <RET> for more, q to quit, c to continue without paging--c
de::ExitCode> (f=0x5555555651c0 <gtk4_layer_shell_segfault_repro::main>)
    at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/std/src/sys_common/backtrace.rs:134
#44 0x0000555555563e01 in std::rt::lang_start::{closure#0}<glib::exit_code::ExitCode> ()
    at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/std/src/rt.rs:166
#45 0x000055555559719e in core::ops::function::impls::{impl#2}::call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> () at library/core/src/ops/function.rs:287
#46 std::panicking::try::do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panicking.rs:485
#47 std::panicking::try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> () at library/std/src/panicking.rs:449
#48 std::panic::catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panic.rs:140
#49 std::rt::lang_start_internal::{closure#2} () at library/std/src/rt.rs:148
#50 std::panicking::try::do_call<std::rt::lang_start_internal::{closure_env#2}, isize> () at library/std/src/panicking.rs:485
#51 std::panicking::try<isize, std::rt::lang_start_internal::{closure_env#2}> () at library/std/src/panicking.rs:449
#52 std::panic::catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> () at library/std/src/panic.rs:140
#53 std::rt::lang_start_internal () at library/std/src/rt.rs:148
#54 0x0000555555563dda in std::rt::lang_start<glib::exit_code::ExitCode>
    (main=0x5555555651c0 <gtk4_layer_shell_segfault_repro::main>, argc=1, argv=0x7fffffffd808, sigpipe=0)
    at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/std/src/rt.rs:165
#55 0x00005555555652ae in main ()
#56 0x00007ffff6fe7850 in __libc_start_call_main
    (main=main@entry=0x555555565290 <main>, argc=argc@entry=1, argv=argv@entry=0x7fffffffd808)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#57 0x00007ffff6fe790a in __libc_start_main_impl
    (main=0x555555565290 <main>, argc=1, argv=0x7fffffffd808, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd7f8) at ../csu/libc-start.c:360
#58 0x0000555555561da5 in _start ()

valgrind log
Command:
cargo build && valgrind --track-origins=yes ./target/debug/gtk4-layer-shell-segfault-repro

Output:
==134189== Memcheck, a memory error detector
==134189== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==134189== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==134189== Command: ./target/debug/gtk4-layer-shell-segfault-repro
==134189==
calling gtk4_layer_shell::init_for_window
toggling visibility rapidly
==134189== realloc() with size 0
==134189==    at 0x4846BE0: realloc (vg_replace_malloc.c:1649)
==134189==    by 0xF738BC6: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF73EFCB: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF7511EE: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF75163C: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF74ACCE: NvGlEglApiInit (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xDC356F4: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDC357DA: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDCAE235: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDC336F7: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDC489BC: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDBD7AD8: UnknownInlinedFun (wayland-eglhandle.c:65)
==134189==    by 0xDBD7AD8: loadEGLExternalPlatform (wayland-external-exports.c:109)
==134189==  Address 0xda38dd0 is 0 bytes after a block of size 0 alloc'd
==134189==    at 0x4841848: malloc (vg_replace_malloc.c:431)
==134189==    by 0xF738BB3: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF73EFCB: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF7511EE: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF75163C: ??? (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xF74ACCE: NvGlEglApiInit (in /usr/lib/libnvidia-eglcore.so.530.41.03)
==134189==    by 0xDC356F4: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDC357DA: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDCAE235: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDC336F7: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDC489BC: ??? (in /usr/lib/libEGL_nvidia.so.530.41.03)
==134189==    by 0xDBD7AD8: UnknownInlinedFun (wayland-eglhandle.c:65)
==134189==    by 0xDBD7AD8: loadEGLExternalPlatform (wayland-external-exports.c:109)
==134189==
<1, true>
==134189== Invalid write of size 8
==134189==    at 0x5829B5F: wl_list_remove (wayland-util.c:56)
==134189==    by 0x582A5B8: proxy_destroy (wayland-client.c:550)
==134189==    by 0x582C131: UnknownInlinedFun (wayland-client.c:562)
==134189==    by 0x582C131: wl_proxy_marshal_array_flags (wayland-client.c:900)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEFD8F: UnknownInlinedFun (text-input-unstable-v3-client-protocol.h:562)
==134189==    by 0x4CEFD8F: gdk_wayland_surface_hide_surface (gdksurface-wayland.c:1005)
==134189==    by 0x4CEFE9C: gdk_wayland_surface_hide (gdksurface-wayland.c:1032)
==134189==    by 0x4D434E7: UnknownInlinedFun (gdksurface.c:1797)
==134189==    by 0x4D434E7: gdk_surface_hide (gdksurface.c:1747)
==134189==    by 0x4B7DE41: gtk_window_unmap (gtkwindow.c:3970)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6A7FC: UnknownInlinedFun (gtkwidget.c:2879)
==134189==    by 0x4B6A7FC: gtk_widget_unmap (gtkwidget.c:2867)
==134189==    by 0x4B7DDE6: gtk_window_hide.lto_priv.0 (gtkwindow.c:3855)
==134189==  Address 0xc84ad78 is 88 bytes inside a block of size 120 free'd
==134189==    at 0x484412F: free (vg_replace_malloc.c:974)
==134189==    by 0x48A3D6D: wl_proxy_marshal_array_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEFCE6: UnknownInlinedFun (text-input-unstable-v3-client-protocol.h:562)
==134189==    by 0x4CEFCE6: gdk_wayland_surface_hide_surface (gdksurface-wayland.c:989)
==134189==    by 0x4CEFE9C: gdk_wayland_surface_hide (gdksurface-wayland.c:1032)
==134189==    by 0x4D434E7: UnknownInlinedFun (gdksurface.c:1797)
==134189==    by 0x4D434E7: gdk_surface_hide (gdksurface.c:1747)
==134189==    by 0x4B7DE41: gtk_window_unmap (gtkwindow.c:3970)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6A7FC: UnknownInlinedFun (gtkwidget.c:2879)
==134189==    by 0x4B6A7FC: gtk_widget_unmap (gtkwidget.c:2867)
==134189==    by 0x4B7DDE6: gtk_window_hide.lto_priv.0 (gtkwindow.c:3855)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==  Block was alloc'd at
==134189==    at 0x48469B3: calloc (vg_replace_malloc.c:1554)
==134189==    by 0x552AF5A: g_malloc0 (gmem.c:163)
==134189==    by 0x48A3B50: libwayland_shim_create_client_proxy (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A52BD: layer_surface_handle_request (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEEE3B: UnknownInlinedFun (xdg-shell-client-protocol.h:534)
==134189==    by 0x4CEEE3B: gdk_wayland_surface_create_xdg_surface_resources (gdksurface-wayland.c:920)
==134189==    by 0x4CF233B: UnknownInlinedFun (gdktoplevel-wayland.c:766)
==134189==    by 0x4CF233B: UnknownInlinedFun (gdktoplevel-wayland.c:1535)
==134189==    by 0x4CF233B: gdk_wayland_toplevel_present (gdktoplevel-wayland.c:1582)
==134189==    by 0x4B82CD5: gtk_window_present_toplevel (gtkwindow.c:3884)
==134189==    by 0x4B84EC4: gtk_window_show (gtkwindow.c:3837)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6ADB1: gtk_widget_show (gtkwidget.c:2709)
==134189==
<2, false>
==134189== Invalid write of size 8
==134189==    at 0x5829AB8: wl_list_insert (wayland-util.c:50)
==134189==    by 0x5829BBB: wl_proxy_set_queue (wayland-client.c:2383)
==134189==    by 0x4CEED51: gdk_wayland_surface_create_wl_surface (gdksurface-wayland.c:834)
==134189==    by 0x4CF26F7: UnknownInlinedFun (gdktoplevel-wayland.c:1530)
==134189==    by 0x4CF26F7: gdk_wayland_toplevel_present (gdktoplevel-wayland.c:1582)
==134189==    by 0x4B82CD5: gtk_window_present_toplevel (gtkwindow.c:3884)
==134189==    by 0x4B84EC4: gtk_window_show (gtkwindow.c:3837)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6ADB1: gtk_widget_show (gtkwidget.c:2709)
==134189==    by 0x116276: <O as gtk4::auto::widget::WidgetExt>::set_visible (widget.rs:1859)
==134189==    by 0x11A966: gtk4_layer_shell_segfault_repro::main::{{closure}}::{{closure}} (main.rs:25)
==134189==    by 0x117A03: glib::source::trampoline_local (source.rs:114)
==134189==  Address 0xc84ad70 is 80 bytes inside a block of size 120 free'd
==134189==    at 0x484412F: free (vg_replace_malloc.c:974)
==134189==    by 0x48A3D6D: wl_proxy_marshal_array_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEFCE6: UnknownInlinedFun (text-input-unstable-v3-client-protocol.h:562)
==134189==    by 0x4CEFCE6: gdk_wayland_surface_hide_surface (gdksurface-wayland.c:989)
==134189==    by 0x4CEFE9C: gdk_wayland_surface_hide (gdksurface-wayland.c:1032)
==134189==    by 0x4D434E7: UnknownInlinedFun (gdksurface.c:1797)
==134189==    by 0x4D434E7: gdk_surface_hide (gdksurface.c:1747)
==134189==    by 0x4B7DE41: gtk_window_unmap (gtkwindow.c:3970)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6A7FC: UnknownInlinedFun (gtkwidget.c:2879)
==134189==    by 0x4B6A7FC: gtk_widget_unmap (gtkwidget.c:2867)
==134189==    by 0x4B7DDE6: gtk_window_hide.lto_priv.0 (gtkwindow.c:3855)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==  Block was alloc'd at
==134189==    at 0x48469B3: calloc (vg_replace_malloc.c:1554)
==134189==    by 0x552AF5A: g_malloc0 (gmem.c:163)
==134189==    by 0x48A3B50: libwayland_shim_create_client_proxy (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A52BD: layer_surface_handle_request (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEEE3B: UnknownInlinedFun (xdg-shell-client-protocol.h:534)
==134189==    by 0x4CEEE3B: gdk_wayland_surface_create_xdg_surface_resources (gdksurface-wayland.c:920)
==134189==    by 0x4CF233B: UnknownInlinedFun (gdktoplevel-wayland.c:766)
==134189==    by 0x4CF233B: UnknownInlinedFun (gdktoplevel-wayland.c:1535)
==134189==    by 0x4CF233B: gdk_wayland_toplevel_present (gdktoplevel-wayland.c:1582)
==134189==    by 0x4B82CD5: gtk_window_present_toplevel (gtkwindow.c:3884)
==134189==    by 0x4B84EC4: gtk_window_show (gtkwindow.c:3837)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6ADB1: gtk_widget_show (gtkwidget.c:2709)
==134189==
<3, true>
==134189== Invalid write of size 8
==134189==    at 0x5829B63: wl_list_remove (wayland-util.c:57)
==134189==    by 0x582A5B8: proxy_destroy (wayland-client.c:550)
==134189==    by 0x582C131: UnknownInlinedFun (wayland-client.c:562)
==134189==    by 0x582C131: wl_proxy_marshal_array_flags (wayland-client.c:900)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEFD8F: UnknownInlinedFun (text-input-unstable-v3-client-protocol.h:562)
==134189==    by 0x4CEFD8F: gdk_wayland_surface_hide_surface (gdksurface-wayland.c:1005)
==134189==    by 0x4CEFE9C: gdk_wayland_surface_hide (gdksurface-wayland.c:1032)
==134189==    by 0x4D434E7: UnknownInlinedFun (gdksurface.c:1797)
==134189==    by 0x4D434E7: gdk_surface_hide (gdksurface.c:1747)
==134189==    by 0x4B7DE41: gtk_window_unmap (gtkwindow.c:3970)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6A7FC: UnknownInlinedFun (gtkwidget.c:2879)
==134189==    by 0x4B6A7FC: gtk_widget_unmap (gtkwidget.c:2867)
==134189==    by 0x4B7DDE6: gtk_window_hide.lto_priv.0 (gtkwindow.c:3855)
==134189==  Address 0xc84ad70 is 80 bytes inside a block of size 120 free'd
==134189==    at 0x484412F: free (vg_replace_malloc.c:974)
==134189==    by 0x48A3D6D: wl_proxy_marshal_array_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEFCE6: UnknownInlinedFun (text-input-unstable-v3-client-protocol.h:562)
==134189==    by 0x4CEFCE6: gdk_wayland_surface_hide_surface (gdksurface-wayland.c:989)
==134189==    by 0x4CEFE9C: gdk_wayland_surface_hide (gdksurface-wayland.c:1032)
==134189==    by 0x4D434E7: UnknownInlinedFun (gdksurface.c:1797)
==134189==    by 0x4D434E7: gdk_surface_hide (gdksurface.c:1747)
==134189==    by 0x4B7DE41: gtk_window_unmap (gtkwindow.c:3970)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6A7FC: UnknownInlinedFun (gtkwidget.c:2879)
==134189==    by 0x4B6A7FC: gtk_widget_unmap (gtkwidget.c:2867)
==134189==    by 0x4B7DDE6: gtk_window_hide.lto_priv.0 (gtkwindow.c:3855)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==  Block was alloc'd at
==134189==    at 0x48469B3: calloc (vg_replace_malloc.c:1554)
==134189==    by 0x552AF5A: g_malloc0 (gmem.c:163)
==134189==    by 0x48A3B50: libwayland_shim_create_client_proxy (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A52BD: layer_surface_handle_request (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x48A3E77: wl_proxy_marshal_flags (in /usr/lib/libgtk4-layer-shell.so.1.0.0)
==134189==    by 0x4CEEE3B: UnknownInlinedFun (xdg-shell-client-protocol.h:534)
==134189==    by 0x4CEEE3B: gdk_wayland_surface_create_xdg_surface_resources (gdksurface-wayland.c:920)
==134189==    by 0x4CF233B: UnknownInlinedFun (gdktoplevel-wayland.c:766)
==134189==    by 0x4CF233B: UnknownInlinedFun (gdktoplevel-wayland.c:1535)
==134189==    by 0x4CF233B: gdk_wayland_toplevel_present (gdktoplevel-wayland.c:1582)
==134189==    by 0x4B82CD5: gtk_window_present_toplevel (gtkwindow.c:3884)
==134189==    by 0x4B84EC4: gtk_window_show (gtkwindow.c:3837)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4B6ADB1: gtk_widget_show (gtkwidget.c:2709)
==134189==
<4, false>
<5, true>
<6, false>
<7, true>
<8, false>
<9, true>
<10, false>
<11, true>
<12, false>
<13, true>

...MANY MORE LINES OF THIS...

<962, false>
<963, true>
<964, false>
<965, true>
<966, false>
<967, true>
<968, false>
<969, true>
==134189== Conditional jump or move depends on uninitialised value(s)
==134189==    at 0x4D8C735: UnknownInlinedFun (gskglrenderjob.c:4367)
==134189==    by 0x4D8C735: gsk_gl_render_job_new (gskglrenderjob.c:4416)
==134189==    by 0x4D6D53D: gsk_gl_renderer_render (gskglrenderer.c:309)
==134189==    by 0x4D4E13C: gsk_renderer_render (gskrenderer.c:465)
==134189==    by 0x4B7ADD7: gtk_widget_render (gtkwidget.c:11895)
==134189==    by 0x4B7BCF8: surface_render (gtkwindow.c:4731)
==134189==    by 0x4CD4E38: _gdk_marshal_BOOLEAN__BOXEDv (gdkmarshalers.c:130)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4D3DB60: UnknownInlinedFun (gdksurface.c:1334)
==134189==    by 0x4D3DB60: UnknownInlinedFun (gdksurface.c:1422)
==134189==    by 0x4D3DB60: gdk_surface_paint_on_clock (gdksurface.c:1401)
==134189==    by 0x48DDBC8: UnknownInlinedFun (gclosure.c:895)
==134189==    by 0x48DDBC8: g_signal_emit_valist (gsignal.c:3472)
==134189==    by 0x48DDD33: g_signal_emit (gsignal.c:3622)
==134189==    by 0x4D32558: UnknownInlinedFun (gdkframeclock.c:708)
==134189==    by 0x4D32558: gdk_frame_clock_paint_idle (gdkframeclockidle.c:609)
==134189==  Uninitialised value was created by a stack allocation
==134189==    at 0x4D8C554: gsk_gl_render_job_new (gskglrenderjob.c:4382)
==134189==
<970, false>
<971, true>
<972, false>
<973, true>
<974, false>

...MANY MORE LINES OF THIS...

<1931, true>
<1932, false>
<1933, true>
<1934, false>
<1935, true>
<1936, false>
<1937, true>
Gdk-Message: 21:19:45.686: Error 22 (Invalid argument) dispatching to Wayland display.
==134189==
==134189== HEAP SUMMARY:
==134189==     in use at exit: 34,231,190 bytes in 126,336 blocks
==134189==   total heap usage: 1,185,003 allocs, 1,058,667 frees, 160,414,220 bytes allocated
==134189==
==134189== LEAK SUMMARY:
==134189==    definitely lost: 40 bytes in 1 blocks
==134189==    indirectly lost: 0 bytes in 0 blocks
==134189==      possibly lost: 14,404,220 bytes in 52,730 blocks
==134189==    still reachable: 19,747,466 bytes in 72,894 blocks
==134189==                       of which reachable via heuristic:
==134189==                         newarray           : 769,636 bytes in 12 blocks
==134189==                         multipleinheritance: 46,176 bytes in 92 blocks
==134189==         suppressed: 0 bytes in 0 blocks
==134189== Rerun with --leak-check=full to see details of leaked memory
==134189==
==134189== For lists of detected and suppressed errors, rerun with: -s
==134189== ERROR SUMMARY: 2906 errors from 5 contexts (suppressed: 0 from 0)

This sounds like a bug in either GTK itself or gtk4-layer-shell, not so much in the GTK4 Rust bindings.
Can you translate this test case to C and confirm?

Good idea. You're right, this is not an issue with gtk4-rs.
#include <gtk/gtk.h>
#include <gtk4-layer-shell/gtk4-layer-shell.h>
#include <stdio.h>

#define PROJECT_NAME "gtk4-layer-shell-segfault-repro-c"
#define TOGGLE_VISIBILITY_INTERVAL_MS 100

GtkWidget *window;
int count = 0;

static gboolean toggle_visible(gpointer user_data) {
  bool visible = !gtk_widget_get_visible(window);
  gtk_widget_set_visible(window, visible);
  count++;
  printf("<%d, %s>\n", count, visible ? "true" : "false");

  return true;
}

static void activate(GtkApplication *app, gpointer user_data) {
  window = gtk_application_window_new(app);

  printf("calling gtk_layer_init_for_window\n");
  gtk_layer_init_for_window(GTK_WINDOW(window));

  printf("toggling visibility rapidly\n");
  g_timeout_add(TOGGLE_VISIBILITY_INTERVAL_MS, toggle_visible, user_data);
}

int main(int argc, char **argv) {
  GtkApplication *app =
      gtk_application_new("lets.cause.a.segfault", G_APPLICATION_DEFAULT_FLAGS);
  g_signal_connect(app, "activate", G_CALLBACK(activate), NULL);

  int status = g_application_run(G_APPLICATION(app), argc, argv);
  g_object_unref(app);

  return status;
}

result:
calling gtk_layer_init_for_window
toggling visibility rapidly
<1, true>
<2, false>
<3, true>
<4, false>
<5, true>
<6, false>
<7, true>
<8, false>
<9, true>
<10, false>
<11, true>
<12, false>
<13, true>
<14, false>
<15, true>
<16, false>
<17, true>
<18, false>
<19, true>
<20, false>
<21, true>
<22, false>
<23, true>
<24, false>
<25, true>
<26, false>
<27, true>
<28, false>
malloc(): unaligned tcache chunk detected
zsh: IOT instruction (core dumped)  ./gtk4_layer_shell_segfault_repro_c


can't check out

When I cloned this repository,  There were some errors.
Maybe the dicrectory name should be changed to English?
$ git clone git@github.com:imfht/fanhaodaquan.git
Cloning into 'fanhaodaquan'...
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 22945 (delta 2), reused 10 (delta 0), pack-reused 22932
Receiving objects: 100% (22945/22945), 23.75 MiB | 14.00 KiB/s, done.
Resolving deltas: 100% (290/290), done.
error: invalid path '鐣彿澶у叏/铔燂\闄㈠埞閭ｆ渶鏂扮暘鍙?txt'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

要不试试https clone？


Filter Tests Added

Describe your changes

Test Added for Filter Resource ( Resource Test + Data Source Test )

Comment Triggers

PR Check triggers

Build: trigger build
Sub Category Field Check: trigger subcategoryfieldcheck

Please add changelog.


sending message to a registered process via it's name does not work.

running the pgm
-module(pr).
-export([start/0, ping/1, pong/0]).
ping(0) ->
pong ! finished,
erlang:display("ping finished");
ping(N) ->
erlang:display("ping started"),
pong ! {ping, self()},
erlang:display("ping sent"),
receive
pong ->
erlang:display("Ping received pong")
end,
ping(N - 1).
pong() ->
erlang:display("pong started"),
receive
finished ->
erlang:display("Pong finished");
{ping, Ping_PID} ->
erlang:display("Pong received ping"),
Ping_PID ! pong,
pong()
end.
start() ->
register(pong, spawn(pr, pong, [])),
spawn(pr, ping, [3]).
results in:
"pong started"
"ping started"
term is not a pid: a4b
"ping sent"
Hang detected
after replacing
pong ! Msg,
by
P = whereis(pong), P ! Msg,
the expected output
"pong started"
"ping started"
"ping sent"
"Pong received ping"
"pong started"
"Ping received pong"
"ping started"
"ping sent"
"Pong received ping"
"pong started"
"Ping received pong"
"ping started"
"ping sent"
"Pong received ping"
"pong started"
"Ping received pong"
"ping finished"
"Pong finished"
Return value: <0.3.0>
is displayed.

Update: this bug is still here (tested on 1939abfaad3faf64f982eee39d5db5bd146f279e)

still unresolved

This issue is still open, if you consider the send operator (!), which the original poster used.  #631 addresses the Erlang:send nif, not the OP_SEND opcode.
Here is a simpler example to reproduce the error:
-module(test).

-export([start/0]).

start() ->
    Pid = spawn_opt(fun loop/0, []),
    register(foo, Pid),
    foo ! {ping, self()},
    receive
        pong ->
            ok
    after 1000 ->
        timeout
    end.

loop() ->
    receive
        {ping, Pid} ->
            Pid ! pong,
            loop()
    end.

On OTP:
Eshell V<IP_ADDRESS>  (abort with ^G)
1> test:start().
ok

On AtomVM:
> atomvm test.beam
Unsupported line_ref tag: 0
Return value: timeout

I believe the issue may relate to the current implementation of the send opcode:
            case OP_SEND: {
                #ifdef IMPL_CODE_LOADER
                    TRACE("send/0\n");
                #endif

                #ifdef IMPL_EXECUTE_LOOP
                    int local_process_id = term_to_local_process_id(x_regs[0]);
                    TRACE("send/0 target_pid=%i\n", local_process_id);
                    TRACE_SEND(ctx, x_regs[0], x_regs[1]);
                    globalcontext_send_message(ctx->global, local_process_id, x_regs[1]);

                    x_regs[0] = x_regs[1];
                #endif
                break;
            }

As you can see, we are assuming the term in the 0th x-register is a Pid, when in fact it could be an atom.

The oversight of missing OP_SEND opcode is finally addressed in #1047.


Guard against possible nil before the actual nil inevitably stops execution

What are you trying to accomplish?

This commit addresses type issue that the introduction of type has brought about.
The PR #9929 has introduced a regression in which the type check stops execution. It is apparently unexpected as the final message results in "unknown_error" and the backtrace appended to this message is the only clue to debug with.
However once you take a look inside the root of the error is rather expectable so let's not overwhelm those who might encounter from this time on.
2024/08/09 12:24:28 INFO Checking if faraday-httpclient 1.0.1 needs updating
2024/08/09 12:24:28 INFO Latest version is 2.0.1
2024/08/09 12:24:39 INFO Requirements to unlock all
2024/08/09 12:24:39 INFO Requirements update strategy bump_versions
2024/08/09 12:24:39 ERROR Passed `nil` into T.must
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/_types.rb:222:in `must'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/group_update_creation.rb:92:in `block in compile_all_dependency_changes_for'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/group_update_creation.rb:56:in `each'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/group_update_creation.rb:56:in `compile_all_dependency_changes_for'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:968:in `bind_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:968:in `block in create_validator_method_medium1'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/create_group_update_pull_request.rb:97:in `dependency_change'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:919:in `bind_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:919:in `block in create_validator_method_medium0'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/create_group_update_pull_request.rb:61:in `perform'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:919:in `bind_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:919:in `block in create_validator_method_medium0'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:117:in `run_grouped_update_for'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:968:in `bind_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation_2_7.rb:968:in `block in create_validator_method_medium1'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:103:in `block in run_grouped_dependency_updates'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:102:in `each'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:102:in `run_grouped_dependency_updates'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `bind_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `validate_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:64:in `perform'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `bind_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/call_validation.rb:270:in `validate_call'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/sorbet-runtime-0.5.11444/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:45:in `run'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:44:in `block in perform_job'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/opentelemetry-api-1.2.3/lib/opentelemetry/trace/tracer.rb:37:in `block in in_span'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/opentelemetry-api-1.2.3/lib/opentelemetry/trace.rb:70:in `block in with_span'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/opentelemetry-api-1.2.3/lib/opentelemetry/context.rb:87:in `with_value'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/opentelemetry-api-1.2.3/lib/opentelemetry/trace.rb:70:in `with_span'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/opentelemetry-api-1.2.3/lib/opentelemetry/trace/tracer.rb:37:in `in_span'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:18:in `perform_job'
2024/08/09 12:24:39 ERROR /home/dependabot/dependabot-updater/lib/dependabot/base_command.rb:37:in `run'
2024/08/09 12:24:39 ERROR bin/update_files.rb:46:in `<main>'
2024/08/09 12:24:39 INFO Results:
Dependabot encountered '1' error(s) during execution, please check the logs for more details.
+---------------+
|    Errors     |
+---------------+
| unknown_error |
+---------------+

Anything you want to highlight for special attention from reviewers?

How will you know you've accomplished your goal?

Feeding the consistent job description file to dependabot-cli, the problem was reproducible and fixable. Thanks for providing the great tools to make things easier!
Checklist

[x] I have run the complete test suite to ensure all tests and linters pass.
[x] I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
[x] I have written clear and descriptive commit messages.
[x] I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
[x] I have ensured that the code is well-documented and easy to understand.

Thank you so much @sato11 ! Please, can you add a unit test so this doesn't regress in the future? And then I can try to get it merged and deployed!
Thanks once again for fixing this!!

Thanks for the comment, @abdulapopoola. Let me leave a comment before I proceed with whatever next action since I might not be able to finish it very soon.
In general I'm for writing tests, but in this case I'm afraid I must admit that adding a persuasive test is going be a non-easy task, taking into consideration the issue has stemmed from our particular Gemfile.lock and our particular job definition, which I am not supposed to share on this public occasion because of NDA. It is possible to write a test stubbing them in an arbitrary manner, but I am not inclined to believe writing a test with arbitrary stubs will surely prevent future regressions. In short, I'm in a dilemma.
I acknowledge that my initial argument might have sounded quite immature like "hey I found a bug that only reproduces in my environment and I cannot add a test but I would like it get merged," but unfortunately this is the type of situation I have found myself in. My apologies. But let me be clear that the problem was not virtual and my intention was to make it better.
I believe that this patch has a potential to solve a problem that anyone might encounter. But to satisfy the testing requirement would likely take more time during which the problem unfortunately remains. If you still think a test is a must, will you please give me a hint or a helping hand so that we can finish it before I might take forever? 😢

Thanks @sato11 ; getting this merged to unblock folks asap.

@sato11 Can you clarify this PR a little more?
I see that in the case of lead_dependency being nil, it skips trying to update it. However, there's already a nil check just a few lines above that guarantees there should be some dependency that needs updating:
https://github.com/dependabot/dependabot-core/blob/f7608a2d0f06dca6b59785618bbeda8ef60665f0/updater/lib/dependabot/updater/group_update_creation.rb#L86
Given that we have a depenency, the only way we should hit nil for this check is if we fail to parse it somehow here:
https://github.com/dependabot/dependabot-core/blob/f7608a2d0f06dca6b59785618bbeda8ef60665f0/updater/lib/dependabot/updater/group_update_creation.rb#L88-L90
Allowing the job to continue even if one dependency breaks makes sense... no point in blocking processing of the rest of the dependencies, but shouldn't we at least log that we failed to process this dependency? Otherwise the failure is getting silently swallowed...
Or am I misunderstanding something here?
Wanted to doublecheck with you before I open a PR to add logging of the failure here.

Hello @jeffwidman. I am completely fine with you enhancing the logs. It was only that I did not think I would want a log to debug it when I sent a patch. I am fine without logs, but I have no reason to object to adding it to make it easier for you to do your work. Thank you for trying to keep it available!


Release 3.12.0

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Replaced by #44


[bug] Health checks displaying incorrect response

Both the format and message of non-standard health checks (ones that use bash scripts instead of the standard JS health checks) appear incorrect.

fixed in https://github.com/Start9Labs/start-os/pull/2759


[SPARK-40772][SQL] Improve spark.sql.adaptive.skewJoin.skewedPartitionFactor to support Double values

What changes were proposed in this pull request?
This PR aims to improve spark.sql.adaptive.skewJoin.skewedPartitionFactor to support float values by converging to doubleConf from intConf.
Why are the changes needed?
Like spark.sql.adaptive.rebalancePartitionsSmallPartitionFactor, this allows users to use the configuration more flexibly.
Does this PR introduce any user-facing change?
Yes, but it will accept all previous Integer configuration values.
How was this patch tested?
Pass the CIs with the changed default value, 5.0.

Could you review this please, @viirya  ?

Thank you, @viirya . Merged to master for Apache Spark 3.4.0.


Problem with initiating crash

CrateDB version:
1.2
JVM version:
1.8.0_121
OS version / environment description:
Ubuntu 16.04
Problem description:
We were trying to initiate crash terminal, but we were getting a syntax error

Steps to reproduce:
Step 1: start crate service
Step 2: run crash
Step 3 : See the error

Use case:
Feature description:

hi @varshithr what python version is installed?

Its Python 2.7.13
Thanks and Regards
Varshith Ramachandra Manchikanti
Mob : +91- 7416-760-120
On Mon, Feb 20, 2017 at 2:50 PM, Christian Haudum<EMAIL_ADDRESS>wrote:

hi @varshithr https://github.com/varshithr what python version is
installed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/crate/crate/issues/4930#issuecomment-281026646, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFT0vNIZl59aaFhVI75qfA5m2eGDsXBSks5reVrmgaJpZM4MF69s
.

thanks, we'll have a look!

@varshithr thanks for reporting. This issue has been fixed and it will be available on the next upcoming release of CrateDB.


Defer Dust access to IDP

Description

If a user has been revoked, they cannot access the app unless they receive a valid invitation from an admin. This is the standard procedure for most scenarios. However, there is an exception for Enterprise connections (SSO) where Dust's permissions are superseded by the Identity Provider (IDP). Therefore, access to Dust should be managed through the IDP instead of directly through Dust.
Risk

Deploy Plan

As discussed IRL, great if we can prevent SSO-enabled workspaces from revoking from the dust UI

As discussed IRL, great if we can prevent SSO-enabled workspaces from revoking from the dust UI

Done.

@philipperolet merging to unblock customers but happy to address any other feedback. PMRR.


docs: improve quickstart

This PR improves the clarity of the quickstart guide, helping to prevent issues like #137.


Update README to point out diffFunc synchronous limitation.

See https://github.com/pouchdb/upsert/issues/16
I spend about an hour trying to make this work before finding the issue.

Sorry about that, and thanks for the PR! It's failing because of Node 6 sadness, so I'll merge with [skip ci].

Nothing to be sorry about. Without pouchdb, I would have spent months :-)
Thanks for the quick merge.


Cache AgentVersion and PeerData in network globals

Motivation
Currently we read AgentVersion and ClientKind from the peerstore everytime it's needed. In the libp2p bump https://github.com/ChainSafe/lodestar/pull/3661 this can trigger disk reads. This data is not necessary to persist besides the lifetime of the peer.
This PR extends https://github.com/ChainSafe/lodestar/pull/3838 adding agentVersion and clientKind to the ephemeral data attached to connected peers, which is dropped on disconnection.
In the future we should do a PR upstream to libp2p to emit the response of the identity protocol to prevent having to poll agentVersions from the peerstore
Description

Cache AgentVersion and PeerData in network globals
Move encodingPreference to PeerData

There's an event emitted from the peerstore.
'change:metadata', {peerId, metadata}: {peerId: PeerId; metadata: Map<string, Uint8Array>}


even square bracket is not allowed???

everyday im finding some new things banned in cs2030... is it really necessary to even ban the square bracket to select the element in an array??

try to use sc.next() bah

I guess you cannot use the split() method

use next()
for eg,
String studentId = sc.next();

i think u can try using the next()

Try use sc.next();

No arrays at all.

You can try use sc.next()!

because square brackets would mean that you have created a new array construct which is not allowed ;-;
just use sc.next()!

.next() works brother