Possible way out of dependency hell?

I thought about way to get out of the current "dependency hell" (#378, #506, ...) - my apologies if this approach has been considered (and found wanting) already:

We move the DifferentiationInterface API definitions into a package DifferentiationInterfaceAPI (or similar name).

We create one package per AD backend, e.g. DIForwardDiff and so on. These packages are basically empty, they only depend on DifferentiationInterfaceAPI, and they implement the DifferentiationInterface API for "their" backend via a single extension (in each backend-implementation package). So DIForwardDiff has a weak dependency on ForwardDiff and an extension DIForwardDiffForwardDiffExt, but DIForwardDiff itself is basically empty. These backend-implementation packages can quicky adapt to breaking changes in the AD package they interface to, while only make a patch-increment of their own version number.

DifferentiationInterface depends on DifferentiationInterfaceAPI and all of the backend implementation packages - but they will only extremely rarely have breaking version changes. (Breaking changes in DifferentiationInterfaceAPI, however, will obviously have a ripple effect). DifferentiationInterface would be mostly empty then.

This way, users can load AD-backends, and combinations of AD-backends, with much wider version combinations, because the backend-implementations are decoupled, version-wise. So ideally, as long as a set of AD backends can be loaded together at all, in some version combination, it should also be accessible via DifferentiationInterface.
I realize that this approach would introduce a not insignificant management overhead ... but there should basically be no adverse effect on load and compile times. Also, tests would run decoupled for each backend.

Thanks for this suggestion! To be honest I hadn't thought that far ahead.
I understand the need for DifferentiationInterfaceAPI (or DifferentiationInterfaceInterface ^^), because that would allow people to write code using our API without bringing in the compatibility conflicts.
I'm struggling a bit more with the second part of the proposal. Essentially, version compatibility would be improved because instead of a single DI version number that has all the backends in lockstep, one would have a set of version numbers (one for DIForwardDiff, one for DIZygote, etc) which can be combined in different ways?

I'm struggling a bit more with the second part of the proposal. Essentially, version compatibility would be improved because instead of a single DI version number that has all the backends in lockstep, one would have a set of version numbers (one for DIForwardDiff, one for DIZygote, etc) which can be combined in different ways?

Yes, that's the idea. By having DifferentiationInterface hard-depend on the separate (almost) empty backend-implementation packages, which all soft-depends on one backend each, we can decouple it from the AD-Backend versions. Since those backend-implementation packages will do everything in their extension, they will have zero load time as long as the AD-Backend is not loaded., so DifferentiationInterface can depend on all of them without load-time penalties.

Also, if we do this big split, do we really need the DifferentiationInterfaceAPI?

I think, so, yes - because all the the backend-implementation packages need to get the DifferentiationInterface API from somewhere. DifferentiationInterfaceAPI wouldn't be a user-facing package, just a "helper" package. No one except for packages like DIForwardDiff, DIZygote, and so on (maybe not the best names) should use it directly. DifferentiationInterface would re-export the API, of course.
So the dependency order would be (with ForwardDiff as an example backend):
DifferentiationInterface depends on DIForwardDiff, DIZygoteDiff, ... which all depend on DifferentiationInterfaceAPI.
And DIForwardDiff has no main code, but a weak dependency on ForwardDiff, and it implements the DifferentiationInterface API in it's DIForwardDiffForwardDiffExt extension. But to do that, I needs to depend on a package that defines that API, so we need DifferentiationInterfaceAPI as a separate package.
Longer term we can hope to convince the AD-backend maintainers to support DifferentiationInterface via an extension, instead of the other way round. That would result in exactly the same version-decoupling across backends. But it will take time, and will never happen for all of them, I fear. So for now, the scheme above would give us that decoupling - and when backends start to provide native support for DifferentiationInterface, we can retire the "implementation packages" like DIForwardDiff one-by-one.

Can you explain in concrete terms how this would have prevented e.g. #506?
For lower bound testing (#378), our conclusion was that the Julia tooling itself is not up to the task, so that's gonna have to wait.

Can you explain in concrete terms how this would have prevented e.g.  #506

Not at all, it turns out, I should have used SciMLSensitivity instead of DiffEqSensitivity (which is now incompatible with recent Zygote versions in itself). :-)
But having fairly tight compatibility version ranges for the backends in DifferentiationInterface will likely result in other cases where packages require version combinations of AD-backends that DifferentiationInterface doesn't offer, right?

For lower bound testing (https://github.com/gdalle/DifferentiationInterface.jl/issues/378), our conclusion was that the Julia tooling itself is not up to the task, so that's gonna have to wait.

Well, with separate packages for each backend, that should be easy (since there's only one dependency to worry about)?

But having fairly tight compatibility version ranges for the backends in DifferentiationInterface will likely result in other cases where packages require version combinations of AD-backends that DifferentiationInterface doesn't offer, right?

On second though I'm not sure this interpretation is correct. The compat bounds in DifferentiationInterface correspond to the minimal versions of AD backends where (1) the features I need are present and (2) incorrectness bugs have been fixed.
Therefore, if you try to instantiate an environment with an AD backend version that DI "doesn't offer", you run the risk of getting errors or incorrect derivatives when you try to query them.
To make things concrete, imagine you have two backends, A and B, each with versions 1 and 2.
Further imagine that DI has evolved through the following versions with their respective compats, which more or less reflects what actually goes on in the package:

DI v1: A=v1
DI v2: A=v1, B=v2
DI v3: A=v2, B=v2

Can you give me a concrete combination where you don't get what you want?

Can you give me a concrete combination where you don't get what you want?

That would happen when you also (possibly indirectly) depends on a package that requires A=2 and on another package that still requires B=1. Or even when depending on a single other package that requires A=2 but has not been updated to B=2 yet. So one would either not be able to install these/this package(s) at all together with DifferentiationInterface, or at best get old versions of them/it.
In a perfect world, algorithm packages would of course not depend on AD-backends directly or indirectly at all, but currently quite a few of them do (SciMLSensitivity being one of the more extreme examples, though it can't cause trouble with DifferentiationInterface anymore because it now indirectly depends on it).

So one would either not be able to install these/this package(s) at all together with DifferentiationInterface, or at best get old versions of them/it.

But this situation wouldn't be any different in the scenario you're proposing, right? Except that what the user gets are old versions of the DI backend subpackages

But this situation wouldn't be any different in the scenario you're proposing, right? Except that what the user gets are old versions of the DI backend subpackages

Yes, but that would be fine - the user would get the current version of the algorithmic packages they need, with their latest features. Getting the old versions of the DI backend subpackages would just mean compatibility with the older version of the AD-backend in question, but not that the older DI backend subpackage is "worse" (assuming it's implementation was already decent).

the user would get the current version of the algorithmic packages they need, with their latest features.

Sorry to press on but I'm really trying to understand. So here the underlying assumption is that "algorithmic packages" (like SciML) need the latest DI to function well, and that keeping DI in lockstep with AD backend implementations somehow hinders updates?
The thing is, DI is mostly AD backend implementations. Between breaking releases of the interface like the one I just tagged, the main thing that evolves is the backend extensions.

So here the underlying assumption is that "algorithmic packages" (like SciML) need the latest DI to function well

Not quite - I rather have the following situation in mind:

It's hard for DifferentationInterface to support a wide version range of all of it's AD-backends without lot's of @static if, also this is hard to test properly. So let's say different versions of DifferentationInterface will support: A=1&B=1, A=1&B=2 and A=2&B=2. Let's assume DI was updated to B=2 first, and then to A=2.

There's a package Dep1 that requires A=2 in it's latest version, which the user needs (directly or indirectly) because of features, or because older versions of it would hold lot's of other packages back.

Another package Dep2, that the user needs directly or indirectly, requires B=1, and is not available for B=2 yet.

Now the user won't be able to install the latest (maybe not even a recent) version of Dep1 (needs A=2) and Dep2 (needs B=1) together with DifferentiationInterface at all: no version of DI would support A=2&B=1.
But if DifferentiationInterface uses separate backend-implementation packages, the DI backend package for A will offer A=1 and A=2 (in it's different versions) and the backend package for B will support B=1 and B=2 (in it's different versions). And DifferentiationInterface can combine arbitrary versions of the backend-implementation packages, as long as they there have been no breaking changes in the DifferentiationInterface API between their versions.
So now the user could install recent/latest versions of Dep1 and Dep2 together with DifferentiationInterface (latest version, though that might not even be so important) - but of course B=1 and the DI backend version for B that supports B=1 would be used (but that would be fine).

I don't think you're entirely right about B=1 being possible in your new configuration. Even if backend functionality is in DI subpackages, these extensions will need to specify compatibility bounds. So DIB will have a lower bound B=2 on package B, and it will automatically kick in whenever the environment in question contains B. Since I'm not gonna go back in time and implement support for B=1, even with your proposal I don't see how B=1 could ever be possible in an environment that contains any version of DI

Since I'm not gonna go back in time and implement support for B=1, even with your proposal I don't see how B=1 could ever be possible in an environment that contains any version of DI

Ah, no, I was assuming that DifferentiationInterface (in it's current scheme) did support B=1 once, but was updated to B=2 (dropping the B=1 compatibility because supporting both would have made the code a hard-to-test mess), and then later was updated to A=2.
So with backend-implementation packages, there would be an older one for B that supports B=1 and that can still be used just fine (assuming no breaking changes in the DifferentiationInterface API). The new DIB with B=2 would then not kick in, the package version solver would see that it can pick the older DIB to satisfy other direct or indirect package requirements.

Alright, that is a bit different from the scenario I initially outlined in my table.
But if we go with your scenario, where B=1 was supported and then dropped, then with the current configuration the user would just get an older version of (all of) DI, the last one before B=1 was dropped. How is that a problem?

with the current configuration the user would just get an older version of (all of) DI, the last one before B=1 was dropped. How is that a problem?

Because that version would not support A=2, which the user might really need because of another package (which would either not support A=1, or only in an old version that would hold a lot of other packages back, meaning some other requirement would not be fulfilled).

Okay, I think I get it. Essentially, with the way things are now, the possible combinations of AD package versions in an environment containing DI will always look somewhat like this:

A \ B
v1
v2
v3
v4
v5

v1
❌
✅
✅
✅
✅

v2
❌
❌
✅
✅
✅

v3
❌
❌
❌
❌
✅

v4
❌
❌
❌
❌
✅

In this table, no matter what we'll never recover the first column. But with your proposal we could complete the rectangle starting at the second column. Do I have that right?

Okay, I think I'm starting to get it. Consider the following release sequence for DI and its backends (I've labeled DI versions with lowercase letters to simplify):

DI
A
B
event

a
1
-
add A

b
2
-
bump A

c
2
2
add B

d
2
3
bump B

e
3
3
bump A

f
4
3
bump A

g
4
4
bump B

Then, depending on the versions of A and B, this is which version of DI would be installed (or none if the environment cannot be resolved):

A \ B
1
2
3
4

1
a
-
-
-

2
b
c
d
-

3
-
-
e
-

4
-
-
f
g

By keeping all the backends in a single package, we essentially force this snake-like evolution through the table of version pairs. And with your suggestion, we could fill all the remaining squares?


chore(main): release 1.4.0

:robot: I have created a release beep boop
1.4.0 (2023-09-30)
Features

auto play song after download (a8fedc2)
rip that auto play feature (413622e)
support spotify uri (0f786cb)

Bug Fixes

progress bar works better now & fixed bitrate (efddd43)

Performance Improvements

album: increase download speed (#274) (99b317c)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/EvolutionX-10/Ariaa/releases/tag/v1.4.0 :sunflower:


[FEATURE REQUEST] - Access to fields in pivot model

Currently when defining a many-to-many relationship, one does not have direct access to all the fields in the pivot model, from the entity.

Hi @go4cas
I don’t know what you want to do.
Please give me example code?

@kkyouhei ... something like this:
Employee model:
static fields () {
   return {
     id: this.increment(),
     name: this.string(''),
     apps: this.belongsToMany(App, EmployeeApp, 'employeeId', 'appId')
   }
 }

App model:
static fields () {
   return {
     id: this.increment(),
     name: this.string(''),
   }
 }

EmployeeApp model (pivot table):
 static fields () {
   return {
     id: this.increment(),
     employeeId: this.number(),
     appId: this.number(),
     appUser: this.string()
   }
 }

I can easily get all the Apps assigned to an Employee, but how do I get to appUser (which is on the pivot model)?

@go4cas You can map the pivot table as you would with any model:
Employee model:
static fields () {
   return {
     id: this.increment(),
     name: this.string(''),
     apps: this.belongsToMany(App, EmployeeApp, 'employeeId', 'appId')
     employeeApps: this.hasMany(EmployeeApp, 'employeeId')
   }
 }

EmployeeApp mode:
 static fields () {
   return {
     id: this.increment(),
     employee: this.belongsTo(Employee, 'employeeId'),
     employeeId: this.number(),
     app: this.belongsTo(App, 'appId'),
     appId: this.number(),
     appUser: this.string()
   }
 }

... Something like this, might not be 100% but you get the idea.
And then you can access the many to many relations through the pivot model

I've got the same problem. Here is my models :
Team model
export default class Team extends Model {
  static entity = 'teams';

  static fields() {
    return {
      id: this.uid(() => uid()),
      name: this.attr(''),
      players: this.hasMany(Player, 'team_id'),
    };
  }
}

Game model
export default class Game extends Model {
  static entity = 'games';

  static fields() {
    return {
      id: this.uid(() => uid()),
      round_id: this.attr(null),
      teams: this.belongsToMany(Team, GameTeam, 'game_id', 'team_id'),
    };
  }
}

GameTeam pivot model
export default class GameTeam extends Model {
  static entity = 'gameTeams'

  static primaryKey = ['game_id', 'team_id']

  static fields() {
    return {
      game_id: this.attr(null),
      team_id: this.attr(null),
      score: this.attr(0),
    };
  }
}

I need to put scores by teams and by games. How should I do that ?

@go4cas You can map the pivot table as you would with any model:
Employee model:
static fields () {
   return {
     id: this.increment(),
     name: this.string(''),
     apps: this.belongsToMany(App, EmployeeApp, 'employeeId', 'appId')
     employeeApps: this.hasMany(EmployeeApp, 'employeeId')
   }
 }

EmployeeApp mode:
 static fields () {
   return {
     id: this.increment(),
     employee: this.belongsTo(Employee, 'employeeId'),
     employeeId: this.number(),
     app: this.belongsTo(App, 'appId'),
     appId: this.number(),
     appUser: this.string()
   }
 }

... Something like this, might not be 100% but you get the idea.
And then you can access the many to many relations through the pivot model

Hi @malinushj ,
We have used this in our app and everything worked as expected. So that's the good news.
But after we have updated the vuex-orm package, we now have duplicate entries.
This is since v0.33.0 - https://github.com/vuex-orm/vuex-orm/releases/tag/v0.33.0
This is an output of the vuex-plugin in Chrome.

We have 3 unique entities, but it looks like the primary key of our pivot table gets mixed as well. Each item has been added twice now.
Here pieces of our code. It should look like the code of your example.
User.js
`export default class User extends Model {
static get entity () {
return 'users'
}
static fields () {
    return {
        id: this.attr(null),

        companies: this.belongsToMany(Company, CompanyUser, 'user_id', 'company_id'),
        companyUsers: this.hasMany(CompanyUser, 'user_id'),
    }
}

}`
CompanyUser.js
`export default class CompanyUser extends Model {
static get entity () {
return 'company_users'
}
static get primaryKey () {
    return ['user_id', 'company_id'];
}

static fields () {
    return {
        id: this.attr(null),
        company_id: this.attr(null),
        user_id: this.attr(null),
        role_id: this.attr(null),

        //relationships
        company: this.belongsTo(Company, 'company_id'),
        role: this.belongsTo(Role, 'role_id'),
        user: this.belongsTo(User, 'user_id'),
    }
}

}`
We have added the "companyUsers" relationship so we can query the role from our pivot table. Before that version, everything worked as expected.
Do you have any idea what could be the problem?
Thanks!

Hi @kiaking, could I ask, what's the best way to get additional field data inserted into the pivot model? For example in my case I have the additional fields in a pivot property in an API response for one of my models. Does vuex-orm have any way of automatically putting some additional fields into a pivot model or do I need to do it myself, whether in a insertOrUpdate or in the beforeCreate hook of my model?


Chore/compliance summary db setup

This PR just addresses the database models/initial data needed for https://github.com/bcgov/cas-reporting/issues/146

superseded by #2504


add flash/sound on full magic (hack)

I'm now at a stage where I often wait for magic to refill. It's nice to have a flash and a sound for that. I've hacked it together here, reusing the reindeer sound. It may want a new option or a few, I dunno, works for me. Thoughts?

Interesting idea to add that as a sound effect.  Hmm... I'll take a look.

This should be accompanied with a config-option for this sound.

sorry, this is well old, I'm unlikely to come back to it

Understandable, closing this PR and re-issuing the add-in.


How i can make another language?

Good afternoon, can you tell me how you can implement the work in other languages? Russian, Turkish, French?

#14


Confusing representation of empty string in array

Godot version: 3.2.2.stable & d30c3d0 (current master)
OS/device including version: not graphics related
Issue description:
Can't distinguish between [] and [""] by printing them out. The output shows [] for both of them.
print([])
print([""])
print(["A","B"])
print(["A","", "B"])

# The corresponding output:
[]
[]
[A, B]
[A, , B]

I expect the strings in the array to be quoted. Or, at least, make the representations of [] and [""] different, as there are commas to make the empty string "visible" in other cases.
This also affects editor debugging, the tooltip of a variable shows [] for [""]:

The same goes for keyframes in a call method track.
Steps to reproduce:
Run the code above.
Minimal reproduction project: Copy & pasting the four lines of code is easier.

Related to https://github.com/godotengine/godot-proposals/issues/538.


The runtime stack is inconsistent between the Germany/China account and Azure account

OS: Windows 10
Build Version: 20210609.5
Repro Steps:

Sign in with Azure Germany/China account.
F1 -> Create New Web App(Basic) -> Enter a name -> Check runtime stack list.
Sign in with Azure account and check runtime stack list.
Check Whether the runtime stack is consistent between the Germany/China account and Azure account.

Expect:
The runtime stack is consistent between the Germany/China account and Azure account.
Actual:
The runtime stack is inconsistent between the Germany/China account and Azure account.

More Info:
The runtime stack is consistent between the portal of the Germany/China account and Azure account.

Yeah this will happen from time to time until Azure Germany/China supports the ARM Stacks api. I can update the backup stacks


Experimental solution for HREACT-34

https://hibernate.atlassian.net/browse/HREACT-34

We've decided to go with the minimal solution.
We will work on adding assertions and more advance checks as a separate issue.


Physical coordinates and id of hanging nodes

Is there a way to retrieve the physical coordinates and ID of hanging nodes using P4estTypes.jl functionalities? I am interested in obtaining the physical coordinates of nodes obtained from P4estTypes.unsafe_element_nodes(lnodes(forest)).
Additionally, the ID numbers for each corner are not unique, as shown in the vtk file created by P4estTypes.savevtk. I plan to use this package for my FEM implementation.
Thank you so much in advance.

The physical coordinates are not directly available.  You need to compute them yourself.  An example doing that can be found here https://github.com/HorribleSanity/Raven.jl/blob/971310fdb4a691281b33b0a6114f8cd2c4d1f01f/src/lobattocells.jl#L288-L359C3.
The ids given in P4estTypes.savevtk duplicate the points at the corners.  To get the mapping to the unique node numbers you need to use P4estTypes.unsafe_element_nodes(lnodes(forest)).


What should the structure of the repo be?

Thoughts.

CC @springdo @pabrahamsson

If this is going to be a super repo, i'd expect a dir per lib, i.e.:

yaml-json-manipulation (https://github.com/redhat-cop/rego-policies/blob/master/_test/_helpers.bash#L1-L52)
error-handling (https://github.com/redhat-cop/rego-policies/blob/master/_test/_helpers.bash#L54-L56)
helm-template (https://github.com/redhat-cop/containers-quickstarts/blob/master/_test/_helpers.bash#L1-L8)

Or do we follow a file per lib? like:

https://github.com/bats-core/bats-assert/tree/master/src

Answered via: https://github.com/redhat-cop/bats-library/pull/11


perf(graphql): cache attribute hashes

This is to reduce memory consumption by this tracer when running GraphQL queries. In my benchmark (below), this resulted in a 97% reduction in this library's footprint and a 10% reduction overall (~7% of objects).
- Total allocated: 1809805 bytes (15888 objects)
+ Total allocated: 1625269 bytes (14794 objects)

  Total retained:  0 bytes (0 objects)

  allocated memory by gem
  -----------------------------------
   1003824  opentelemetry-sdk-1.3.1
    381029  graphql-2.1.6
    194512  opentelemetry-api-1.2.3
-   189656  opentelemetry-instrumentation-graphql-0.26.7
     35952  other
+     4880  graphql/lib
      4288  racc-1.7.3
       368  logger
       136  monitor
        40  set

otel_bench.rb

require "bundler/inline"

gemfile(false) do
  source "https://rubygems.org"
  gem "graphql", "2.1.6"
  gem "opentelemetry-sdk" # , path: "~/code/opentelemetry-ruby/sdk"
  gem "opentelemetry-api" # , path: "~/code/opentelemetry-ruby/api"
  gem "opentelemetry-instrumentation-graphql", path: "~/code/opentelemetry-ruby-contrib/instrumentation/graphql"
  gem "benchmark-ips"
  gem "memory_profiler"
  gem "stackprof"
end

class MySchema < GraphQL::Schema
  DATA = {
    "5" => {
      name: "Beatrix Potter",
    },
    "6" => {
      name: "J.R.R. Tolkien"
    },
    "10" => {
      title: "The Tale of Squirrel Nutkin",
      author_id: "5",
      recommended_book_ids: ["11", "12"],
    },
    "11" => {
      title: "The Tale of Ginger and Pickles",
      author_id: "5",
      recommended_book_ids: ["10", "12"],
    },
    "12" => {
      title: "The Tale of Mr. Tod",
      author_id: "5",
      recommended_book_ids: ["11", "10"],
    },
    "21" => {
      title: "The Hobbit",
      author_id: "6",
      recommended_book_ids: ["22", "23", "24", "25", "26", "27"],
    },
    "22" => {
      title: "The Fellowship of the Ring",
      author_id: "6",
      recommended_book_ids: ["21", "23", "24", "25", "26", "27"],
    },
    "23" => {
      title: "The Two Towers",
      author_id: "6",
      recommended_book_ids: ["22", "21", "24", "25", "26", "27"],
    },
    "24" => {
      title: "The Return of the King",
      author_id: "6",
      recommended_book_ids: ["22", "23", "21", "25", "26", "27"],
    },
    "25" => {
      title: "The Silmarillion",
      author_id: "6",
      recommended_book_ids: ["22", "23", "24", "21", "26", "27"],
    },
    "26" => {
      title: "The Adventures of Tom Bombadil",
      author_id: "6",
      recommended_book_ids: ["21", "22", "23", "24", "25", "27"]
    },
    "27" => {
      title: "Leaf by Niggle",
      author_id: "6",
      recommended_book_ids: ["21", "22", "23", "24", "25", "26"]
    }
  }

  module Node
    include GraphQL::Schema::Interface
    field :id, ID
  end

  class Author < GraphQL::Schema::Object
    def self.authorized?(obj, ctx)
      -> { true }
    end
    implements Node
    field :name, String
    field :books, ["MySchema::Book"]

    def books
      author_id = DATA.find { |(id, auth)| auth == object }.first
      DATA.each_value.select { |d| d[:author_id] == author_id }
    end
  end

  class Book < GraphQL::Schema::Object
    implements Node
    field :title, String
    field :author, Author
    field :recommended_books, [Book]

    def author
      DATA[object[:author_id]]
    end

    def recommended_books
      object[:recommended_book_ids].map { |id| -> { DATA[id] } }
    end
  end

  class Query < GraphQL::Schema::Object
    field :node, Node do
      argument :id, ID
    end

    def node(id:)
      DATA[id]
    end
  end

  query(Query)

  orphan_types(Book, Author)

  def self.resolve_type(type, obj, ctx)
    if obj.key?(:name)
      Author
    elsif obj.key?(:title)
      Book
    else
      raise "Unknown object: #{obj.inspect}"
    end
  end

  lazy_resolve(Proc, :call)
end

OpenTelemetry::SDK.configure do |c|
  c.use 'OpenTelemetry::Instrumentation::GraphQL', {
    schemas: [MySchema],
    # enable_platform_field maps to the execute_field and execute_field_lazy keys
    enable_platform_field: true,
    # enable_platform_authorized maps to the authorized and authorized_lazy keys
    enable_platform_authorized: true,
    # enable_platform_resolve_type maps to the resolve_type and resolve_type_lazy keys
    enable_platform_resolve_type: true,
  }
end

# puts MySchema.to_definition

small_query_str = <<-GRAPHQL
query {
  node(id: "10") {
    __typename
    ... on Book {
      title
      author {
        __typename
        name
      }
      recommendedBooks {
        __typename
        title
      }
    }
  }
}
GRAPHQL

large_query_str = <<-GRAPHQL
{
  node(id: "6") {
    ... on Author {
      name
      books {
        title
        recommendedBooks {
          title
          author { name }
          recommendedBooks { title }
        }
      }
    }
  }
}
GRAPHQL

# pp MySchema.execute(small_query_str).to_h
# pp MySchema.execute(large_query_str).to_h

Benchmark.ips do |x|
  x.report("small query") { MySchema.execute(small_query_str) }
  x.report("large query") { MySchema.execute(large_query_str) }
end

query_str = large_query_str

puts "\n\n\n"

result = StackProf.run(mode: :wall, interval: 1) do
  MySchema.execute(query_str)
end
report = StackProf::Report.new(result)
File.open("tmp/otel_query.dump", "wb+") { |f| report.print_dump(f) }
report.print_text

report = MemoryProfiler.report do
  MySchema.execute(query_str)
end
puts "\n\n\n"
report.pretty_print

I also added .compare_by_identity to these caches because they always receive the same objects -- GraphQL definition objects -- as keys.

@rmosolgo TIL about Hash#compare_by_identity.
Is this allocation problem specific to OTel or have you also identified this problem with the existing Tracers that included in the graphql gem?
I would like to confirm with you that these types will not change at runtime, i.e. there isn't any logic that would result in dynamically generated types or Module instances that would result in the hashes growing out of control. Is that correct?
Also, do you have any concerns about thread safe access to these cache Hashes in JRuby?
Is there a way to eagerly seed the hashes at startup as opposed to using lazy initialization?

existing Tracers

Broadly speaking, it's definitely a general problem. The reason I re-wrote GraphQL-Ruby's tracing to use methods with keyword arguments was to avoid allocating hashes for the old data argument. Those hashes were created  regardless of whether or not they were actually used and, since tracing calls grow with the size of the execution result set, the overhead really grows for large responses.
As for the built-in tracers, I definitely try to keep allocations in these paths to a minimum, although I know the datadog one is not so great 🙈 .

hashes growing out of control

It is technically possible to create GraphQL types on-the-fly (https://graphql-ruby.org/schema/dynamic_types.html), but in any case, these hashes only live for the duration of a single query. The Trace object they belong to is created at the start of the query and isn't used after that. (This object lifetime was another reason for rewriting the trace system!) In this way, it's similar to GraphQL-Ruby's own per-query caches of types, arguments, fields, etc, in GraphQL::Schema::Warden.

thread safe access

I don't have specific insight into this, but GraphQL-Ruby uses tons of caches just like this:

(read_through)[https://github.com/rmosolgo/graphql-ruby/blob/565b62f13d3cdd7d2cd880e82d189ab64278b1e8/lib/graphql/schema/warden.rb#L379-L383]  in Schema::Warden
https://github.com/rmosolgo/graphql-ruby/blob/565b62f13d3cdd7d2cd880e82d189ab64278b1e8/lib/graphql/execution/interpreter/runtime.rb#L52-L54
https://github.com/rmosolgo/graphql-ruby/blob/565b62f13d3cdd7d2cd880e82d189ab64278b1e8/lib/graphql/execution/interpreter/arguments_cache.rb#L10-L26

And of course, the existing platform_*_key hashes work this way, too. Since those work properly, I'm guessing these will too!

eagerly seed the hashes

It might be possible to do this via context.query.types, but I don't think it's desirable, because most queries use less than the full set of types. Creating them as-needed and then discarding them at the end of the query seems like a sweet spot between creating instances for every call (which creates a lot of duplicate objects) and making a "master cache" at the schema level (which would be fewer allocations, but we'd have to think through issues like thread safety or permissions between different queries).

compare_by_identity

Yes, it's new to me too, but I've started using it all over GraphQL-Ruby for this kind of cache! It ends up saving a good bit of time on hot paths, when you know the keys will be exactly the same object (eg https://github.com/rmosolgo/graphql-ruby/pull/4431#discussion_r1163159395, https://github.com/rmosolgo/graphql-ruby/pull/4443)

I appreciate the context and explanations. I'll take a look in later today if I have enough time.
I'll be OOO until Monday. This review will be at the top of my list if I am unable to get to it today.

similar optimization

There is, I pushed it in 92ad82f
I also noticed that, since authorized and resolve_type create the same kind of attributes hash, they could share a cache. (Same thing for authorized_lazy and resolve_type_lazy.) I updated both implementations in e65ef47.

Derp -- I'll revert those changes. It looks like that tracer expects a slightly different behavior when tracing fields that are defined in an interface module.


docker: temp fix for deps

Description
fix build issue
Metadata
Fixes

Fixes # [Link to Issue]

Contributing Agreement

[x] I have read and understood the Optimism Contributing Guide and Code of Conduct and am following those guidelines in this pull request.

operation save CI


handle bad response

Gestita risposta HTTP con status code 429 nel file Builder.py

Sorry Albi, the code went on and I'll open a new merge request. You are always welcome to contribute ;)
Sorry again...it's just a usefull feature that now i really want


website icon sometimes visible, sometimes not

I have 2 folders which contains several feeds from the same website. When I click to the folder I always can see the website icons left of the title of the article. Sometimes when I click from the folder to a separate feed I can see the website icon, but sometimes not.

This is a separate feed in iCloud. I cannot do it with every feed, just a few.
NNW 6.04d, macOS Big Sur

This is by design.  We don't show the icons for individual feeds unless they contain additional author information.  This is to help increase information density in the Timeline when the feed icon would just all be the same thing for all entries.

This is by design.  We don't show the icons for individual feeds unless they contain additional author information.  This is to help increase information density in the Timeline when the feed icon would just all be the same thing for all entries.


ci: Update actions.

This replaces the actions-rs/toolchain action with dtolnay/rust-toolchain as that is maintained.
Version numbers on other actions are bumped to the current versions.

@dfrg Checking in on this...

Sorry, I have too many GitHub notifications and don’t tend to follow this repo closely. Feel free to ping me for swash PRs in the future.
LGTM, thanks!


More flexible selection of subset of variable, like .select(y=1)

Sometimes it is convenient to be able to choose the part of a multi-dimensional variable that corresponds to one single value of one dimension.
For instance, if the variable I_py is defined over "p", "y", and "t", to be able to do
self.model.constr_1 = I_py.select(y=2) == 1.

Done with .filter().
        """
        Creates a new expression with only a subset of the data.
        Filtering uses the same syntax as polars.DataFrame.filter.

        Examples
        --------
        >>> from pyoframe import Variable
        >>> time = [1, 2, 3]
        >>> city = ["Toronto", "Berlin"]
        >>> var = Variable({"time": time}, {"city": city})
        >>> expr = 2 * var
        >>> expr
        <Expression size=6 dimensions={'time': 3, 'city': 2} terms=6>
        [1,Toronto]: 2.0 x1
        [1,Berlin]: 2.0 x2
        [2,Toronto]: 2.0 x3
        [2,Berlin]: 2.0 x4
        [3,Toronto]: 2.0 x5
        [3,Berlin]: 2.0 x6
        >>> expr.filter(city="Toronto", time=2)
        <Expression size=1 dimensions={'time': 1, 'city': 1} terms=1>
        [2,Toronto]: 2.0 x3
        """


Remove old references

Attempting to reduce duplication in features by removing support for old style reference syntax.

Nice one!


Can't place construction ghosts on top of exposed floor rods

Description

You can't place construction ghosts on top of exposed floor rods due to an "obstruction." This is a problem for fixing breaches or building walls on the edges of grids (shuttles and station).
Notably you can build furniture or wall girders on valid tiles (hull or floor plating), unanchor them, then move and anchor them on top of exposed floor rods.
Reproduction

Find an exposed floor rod (either by spacing or placing rods into space)
Try to place construction ghost

Screenshots

Unsuccessful construction ghost

Successful construction ghost

Intentional by my recollection.
Walls need to be on plating.
The fact you can even anchor a girder onto lattice is the realer issue here.

Just make plating for the lattice chief..

Yes, this is a serious problem. This is especially annoying when making radiators or lights


Needs automatic update mechanism

Code from oggcamp's hosting is to have a script in $HOME with the following content:
#!/bin/bash
cd $HOME/jekyll
git fetch origin
reslog=$(git log HEAD..origin/master --oneline)
if [[ "${reslog}" != "" ]] ; then
# there are new changes: completing the pull
  git merge origin/master
  jekyll build -d $HOME/public_html
fi

This then is scheduled via crontab, however, if there's any reason you can't reach the origin (via git pull) then it gets noisy very quickly. We could do with some sort of failure detection and threshold. Perhaps this untested bash script (to replace the single "git fetch origin" line above) covers it?
if ! git fetch origin 2>/tmp/tempfile ; then
  if [ -e $HOME/.failure_status ]; then
    source $HOME/.failure_status
  else
    FAILURE_STATUS=0
  fi
  if [ -z "$FAILURE_THRESHOLD" ]; then
    FAILURE_THRESHOLD=5
  fi
  if [ $FAILURE_STATUS -gt $FAILURE_THRESHOLD ]; then
    cat /tmp/tempfile
    rm /tmp/tempfile
    FAILURE_STATUS=0
  else
    FAILURE_STATUS=$((FAILURE_STATUS+1))
  fi
  echo "FAILURE_STATUS=$FAILURE_STATUS" > $HOME/.failure_status
fi
rm -f /tmp/tempfile

For the short-term, I have copied into the testsite path the update_site script, and tweaked it to change "$HOME" for "BASEDIR". I've then created a crontab entry for root, showing the following:
*/5 *  *   *   *     BASEDIR=/home/groups/testsite.lug.org.uk /home/groups/testsite.lug.org.uk/update_site 2>&1 | mail<EMAIL_ADDRESS>-E -s update_site testsite.lug.org.uk
This will tide us over for the next few days, until I figure out something a little more permanant!

Considering using this instead: https://github.com/JonTheNiceGuy/git-autoupdate - thoughts?

Sounds perfect.


Reset password broken when using Laravel's default users

Package
filament/filament
Package Version
v1.10.12
Laravel Version
v8.61.0
Livewire Version
v2.6.5
PHP Version
8.0.10
Bug description
Once configured the app to use Laravel's default user table per the documentation, when trying to reset a user's password it fails with:
Illuminate\Database\QueryException
SQLSTATE[42S02]: Base table or view not found: 1146 Table '[table].filament_users' doesn't exist (SQL: select * from `filament_users` where `email` = [user@email] limit 1)

I tracked it down to src\Http\Livewire\Auth\RequestPassword.php using filament_users broker to send the reset link (line 39):
        $requestStatus = Password::broker('filament_users')->sendResetLink($this->validate());

This also happens on src\Http\Livewire\Auth\ResetPassword.php line 46.
This can be solved by changing that lines with something like:
        $broker = config('filament.auth.guard') === 'filament' ? 'filament_users' : null;
        $requestStatus = Password::broker($broker)->sendResetLink($this->validate());

That way, we use filament_users table when using the default filament guard, and whatever is setup as the default otherwise.
For the request password to fully work we also need to add the function sendPasswordResetNotification to our User model from fillament's one, to be sure we're sending filament's signed url on the notification and not Laravel's one (which may also fail if we don't have the default Laravel's auth routes published). Maybe it's better to move that function to a trait and use that trait on the User model (filament's or custom one).
Anyway, this is missing on the documentation.
I can make a PR if you think this is the correct approach.
Steps to reproduce
Configure filament to use the default Laravel User model and authentication. Create a new user and try to reset his password.
Relevant log output
No response

Yes please, make a PR.

I'm on it.
For the sendPasswordResetNotification issue on User model, do you prefer a new trait (and add it to the documentation) or maybe we can move that function to src\Models\Concerns\IsFilamentUser.php?
What would be your preffered approach?

Can you use the existing trait please, thanks!

Fixed by #606.


Function request: put a sound or bip when scanning, please

The app is great.  I just would like you to add the option that instead of vibrating also a beep or sound option is the most important thing that I put emphasis on, a beep or sound.
In addition, the scanner field or scan box is allowed to change its size for more complex codes or for better comfort, apart from the zoom option that it already has and is useful.
Thanks for listening.

Por mucho que personalmente prefiera el silencio, tener la opción de retroalimentación de audio es bueno para dispositivos que no tienen vibración (como una tableta).

Yes, it would be great, and for those who do not want it to sound, have the option to deactivate it, I hope and implement it soon


⚠ SceneTime has degraded performance

In 4aee2e8, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1377 ms

Resolved: SceneTime performance has improved in 32eff75 after 6 minutes.


[chore][test] add testcase for recycle bin

What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
add multiple drop and multiple insert overwrite cases for recycle bin feature.
Release note
None
Check List (For Author)

Test

[X] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[ ] No.
[ ] Yes.

Does this need documentation?

[ ] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

run buildall


fix: disable penalization until we got it right

let's disable until properly fixed
ref #2014

Codecov Report

Merging #2016 (22672a3) into main (3810548) will decrease coverage by 55.68%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main    #2016       +/-   ##
===========================================
- Coverage   73.02%   17.34%   -55.68%
===========================================
  Files         427      427
  Lines       52306    52307        +1
===========================================
- Hits        38195     9074    -29121
- Misses      14111    43233    +29122

Flag
Coverage Δ

integration-tests
17.34% <0.00%> (-2.11%)
:arrow_down:

unit-tests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

crates/net/network/src/transactions.rs
0.00% <0.00%> (-18.50%)
:arrow_down:

... and 307 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


meaningless benchmark

I just did a blake3 hash of over 16,000 movies file and databased them into a sqlite database.
size:<PHONE_NUMBER>839
time: 54555.376517945s
2.3 TB
in about 15 hours
Mb / sec 41.6
async fn file_hash(pth: &Path) -> Result<String, Box> {
let mut hasher = Hasher::new();
hasher.update_mmap_rayon(pth)?;

Ok(hasher.finalize().to_hex().to_ascii_lowercase())

}

I'm afraid in that use case you're almost certainly benchmarking your disk read speed and not how fast your CPU can hash the data.


Should BaseController inherit from ControllerBase, not Controller?

"Don't create a web API controller by deriving from the Controller class. Controller derives from ControllerBase and adds support for views, so it's for handling web pages, not web API requests. There's an exception to this rule: if you plan to use the same controller for both views and APIs, derive it from Controller."
https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-2.2

Thanks @ltjerry, much appreciated - fixed.