has_many :through associations filter problem

Hi ,I have a problem with adding has many through association to filter . When I try to add this code :
list do
    field :model ,:has_many_association do
          searchable :name
     end
end'

and then I add choose filter on the view I give the exception :
Unknown column 'model.name' in 'where clause': SELECT  another_model.* FROM another_model  WHERE (((model.name_en LIKE '%test%')))
The same problem I found on the StackOVerflow but it has no answer :(
http://stackoverflow.com/questions/13529634/rails-admin-searchable-association.
Could you help me to resolve it?

Is the issue still there? there seems to be an easy fix as per the blog of @barsukov (issue opener): http://blog.endpoint.com/2013/07/hasmany-filter-in-railsadmin.html

Yes if it imlements you can close but I do not remember this issue it has been 2 years ago :smile:

The issue is still there. Just had a try with master.
I have implemented the solution on that blog post as well, more specifically the one in the comments. The solution in the post does not work for master.

@sferik any interest in addressing this issue? seems to be a pretty useful feature to have

@vincentwoo Of course, as long as it does not break existing functionality.
Please refer to the note in https://github.com/sferik/rails_admin/pull/2349#issuecomment-118215266.

@mshibuya It seems simple enough to only search has_many associations where the programmer has explicitly enabled searchable on, with a disclaimer about the performance tradeoffs. In the case that I'm interested in, most records will have 1-4 objects in the association, which is fine for performance.

Sounds good, could you submit a PR, along with tests?

@mshibuya Unfortunately I don't think I have the time/expertise to tackle this right now, but if anyone wants to I'm happy to kick the tires!

@rafaelgonzalez, it still does not work for me, even with your solution,
RA , master or 0.7
class Order < AR
 has_many :order_clients
 has_many :clients, through: :order_clients
 rails_admin do
   field :clients do
          searchable :last_name
      end
 end
end

Mysql2::Error: Unknown column 'people.last_name' in 'where clause': SELECT `orders`.*  It happened to me and the fix was to restart the server. I don't know why but it happens from time to time and restarting the server works

mysql, and i'm in dev mode,

@robertdolca , effectively, it does not work every time, maybe a cache issue !

@fmh with postgresql in production works without any issue. Could you try with MySQL in production and unicorn?

It make no sense !, it should work in all cases.

From this thread, I followed Nick Roosevelt's suggestion and it worked for my case.
class Room < ActiveRecord:Base
  has_many :time_slots
end

class TimeSlot < ActiveRecord::Base
  belongs_to :room

  rails_admin do
    list do
      field :day do
        searchable true
      end
      # field :room do
      #   searchable room: :name
      # end
      field :room do
        searchable [{Room => :name}]
        queryable true
      end
    end
  end
end

I tried searchable room: :name and it was not working, but searchable [{Room => :name}] seem to make it work.

I've been having this same problem but with has_one through: ... associations. I'm planning to turn this into a PR at some point, but in the mean time this is a monkey patch I've used to get it working:
require 'rails_admin/adapters/active_record'

module RailsAdmin::Adapters::ActiveRecord
  module WhereBuilderExtension
    def initialize(scope)
      @includes = []
      super(scope)
    end

    def add(field, value, operator)
      @includes.push(field.name) if field.is_a?  I've even used it for a third-order :through association (D => C => B => A, search A from D) and it worked.

@vergenzt Thanks for your solution, it helped me a lot!!!
But it introduced for me an error on all other queries.

NoMethodError (undefined method `page' for nil:NilClass):

Finally I found that the problem was in the build method of your patch.
def build
  super.includes(*(@includes.uniq)) if @includes.any?
end

This method returns nil if includes is empty without calling the super method and that fires the no method exception, when pagination is invoked on the result, e.g. in https://github.com/sferik/rails_admin/blob/master/lib/rails_admin/adapters/active_record.rb:36
scope = scope.send(Kaminari.config.page_method_name, options[:page]).per(options[:per])
I think the correct solution should be this
def build
  @includes.any? ? super.includes(*(@includes.uniq)) : super
end

So, the complete working patch is now:
require 'rails_admin/adapters/active_record'

module RailsAdmin::Adapters::ActiveRecord
  module WhereBuilderExtension
    def initialize(scope)
      @includes = []
      super(scope)
    end

    def add(field, value, operator)
      @includes.push(field.name) if field.association?
      super(field, value, operator)
    end

    def build
      @includes.any? ? super.includes(*(@includes.uniq)) : super
    end
  end

  class WhereBuilder
    prepend WhereBuilderExtension
  end
end

Thanks @domangi! Yeah I ended up discovering that in my own testing but forgot to update my comment here. I'll edit the original comment so no one gets confused. :)

Thank you very much @domangi and @vergenzt. You solved my problem.
Though only partially. The provided solution does not work with
field :model_a do
  searchable [:id, :name]
end

only within a configure block as you guys provided.

@asishallab I don't use a configure block. Give more details about your setup (models and rails_admin) and about the error/misfunction

Dear @domagi,
the following works with the provided solution WhereBuilderExtension
rails_admin do
list do
  configure :id
  configure :taxon do
    searchable [ :family, :genus, :species, :subspecies_or_strain ]
  end
end

and this does not work
rails_admin do
field :taxon do
  searchable [ :family, :genus, :species, :subspecies_or_strain ]
end
end

No error is raised in the second non working case taxon is simply not searched. In older versions of rails_admin it has been searched, indeed.
Does this answer your question?
Cheers!

@asishallab I use a field block and it's working:
field :location do
      searchable [:address]
end

Try looking in your logs how your search is transformed in SQL in both cases. From there you could find why you are getting no results.

Why @domangi 's solution is not injected yet in this project?

@nallwhy Because we have alternative solution in the master branch: b92a4d1a30b706d08df2aee4d0a59dad698a0552

@mshibuya What is the 'eager_load'? How can I use it?


Feature Request: func (s *Session) GuildBan(guildID string, userID string) (*GuildBan, error)

I believe the functionality to get a ban by user ID is missing from this library.
See: https://discord.com/developers/docs/resources/guild#get-guild-ban

This was added, so I guess this issue can be closed now.


Development: Fix leaks in exam-participation-cover test

Checklist
General

[x] I chose a title conforming to the naming conventions for pull requests.
[x] I followed the coding and design guidelines.

Motivation and Context

exam-participation-cover.component.spec.ts consistently leaked in 10 test runs on my machine (while the other one I promised to look at in the dev meeting did not show any signs of leaks on my machine ...?).
I first thought this would fix the leak, but it does not (instead it decided to simply not run some tests).
It also doesn't seem to be consistent anymore.
If I remove a few random tests from the file, the leak warning disappears. It doesn't matter which tests I remove.
I'm not sure how this happens.
Steps for Testing

Run the test and check that no warnings appear:
ng test --log-heap-usage --detect-leaks exam-participation-cover.component.spec.ts
Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

This is fixed by #4480


Make an option to create PDB for cluster

I think we should add an option to create PDB for cluster.
 ---
 apiVersion: etcd.aenix.io/v1alpha1
 kind: EtcdCluster
 metadata:
   name: test
   namespace: ns1
 spec:
   image: "quay.io/coreos/etcd:v3.5.12"
   replicas: 3
  storage:
    persistence: true # default: true, immutable
    storageClass: local-path
    size: 10Gi
+ enablePDB:  true
 status:
   conditions:
   - lastProbeTime: null
 	lastTransitionTime: "2024-03-06T18:39:45Z"
 	status: "True"
 	type: Ready

By default it should be true meaning that PDB resource will be created with maxUnavailable field equal to the maximum number of members can die without losing quorum

Shouldn't it be created automatically?

Should we focus on the alpha2 version of the specification and stop expanding alpha1? Writing and rewriting code can be uncomfortable for developers.

@AlexGluck We need to create next API version only in case if some field get removed or renamed

@AlexGluck Creating next api version will force us to update both old and new CRD leading to even more uncomfortable development :)
See kubebuilder docs

In Kubernetes, all versions must be safely round-tripable through each other. This means that if we convert from version 1 to version 2, and then back to version 1, we must not lose information. Thus, any change we make to our API must be compatible with whatever we supported in v1, and also need to make sure anything we add in v2 is supported in v1. In some cases, this means we need to add new fields to v1, but in our case, we won’t have to, since we’re not adding new functionality.

While we don't accepted PR #63 we can be on time move key.

For now we can use this specification https://github.com/aenix-io/etcd-operator/issues/62#issuecomment-2018438298 for PDB and extend it later if required


MariaDB TIME datatype loss of information

System information:

Arch Linux
7.2.4

Connection specification:

MariaDB 10.5.8-MariaDB
MariaDB Connector/J 2.4.3

Describe the problem you're observing:
When visualizing data sets with TIME columns, time values are wrapped at 24hrs, while MariaDB specifically supports time values in the range '-838:59:59.999999' to '838:59:59.999999'.
This is a limitation of the JDBC API, as explained by the MariaDB JDBC driver maintainer here. However, there exists the workaround of getting the value out of JDBC as a string, so this limitation can definitely be addressed.
Note that the driver from MySQL exhibits the different behaviour of returning null.
Steps to reproduce, if exist:
Execute the following query using the standard MariaDB client and DBeaver, and observe the different results:
SEC_TO_TIME(257394)

verified


getProduct - not receiving specific variant option type  (only "MultipleChoiceOption")

on backend we can set variant option type as rectangle, dropdown, swatch, radio
but  "__typename" property  is always set to "MultipleChoiceOption" and not the specific type we specified
how can we get it?

Hi @rahulguptacs1, here is where we're asking for product variants:
https://github.com/bigcommerce/storefront-data-hooks/blob/517a65789c4c8a09daa7add3068e010c79a179d0/src/api/fragments/product.ts#L66-L76
As you see, you should receive an array of the variants with the entityId and the defaultImage of each one.
Can you write what you are receiving?

I have come to understand what you mean. And you are right, there is no way to differentiate between the different types. It's a behaviour that is inherited from the API and that this package cannot change, so I'm closing this issue.


Possible approaches for automating the updation of the get_info function

Objective
Devising an efficient way to automatically update the get_info function in the _nx_parallel/__init__.py file for all PRs and/or commits(to the main branch) modifying/adding any documentation.
Current approach
Manually run script.sh to update the __init__.py and then make a PR/commit to the main branch.
Approach 1
Adding a pre-commit hook that runs script.sh and updates the __init__.py file (ref. PR https://github.com/networkx/nx-parallel/pull/55)
Issue with this approach:
if we merge a PR that updates the __init__.py then this will cause all the previously made non-doc or doc-related PRs to have merge conflicts for the _nx_parallel/__init__.py file.
ref. https://github.com/networkx/nx-parallel/pull/55#issuecomment-2026804506
Approach 2
Trigger a GitHub workflow when the maintainer initiates the "merge" action on a PR, which will run the script.sh and then check if __init__.py file has changed and accordingly push a commit at the end of the PR before running all the other tests before merging.
Issue with this approach:
The merge action was not actually available in GitHub wf. (ref. https://stackoverflow.com/questions/60710209/trigger-github-actions-only-when-pr-is-merged). In the referred question one of the answers says to use :
on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        sh _nx_parallel/script.sh

But, then where will that "Update __init__.py" commit go, after script.sh is run? In the main branch? because the PR is already closed(merged) and pushing it to main will overpopulate the repository's commit history with a lot of "Update __init__.py" commits.

Issue with this approach:

here(https://github.com/Schefflera-Arboricola/nx-parallel/pull/2) I tried to implement this. And the test is triggered only at the time of approval, so the maintainer(s) would have to make sure to approve the PR just before they merge, in case there were any doc change suggestions in the previous approval's comment.
Adding this additional commit at the end of PR could either be done by a maintainer's account or using a GitHub bot account. I'd prefer a bot account since we can use it in the future like for maintaining the timings folder, by automatically running the heatmap on the VM and adding that to the timing folder. or should we update all the heatmaps with benchmarks? I think this approach might be good but I wanted to know your thoughts before I start looking into how GitHub bots are set up.

Other approaches
Another approach could be that every time a PR gets merged a wf is triggered and an update commit is added to the main branch but that will probably overpopulate the repository's commit history with a lot of "Update init.py" commits. or have a scheduled wf that runs the script.sh and updates the get_info, like a nightly wheel. Or trigger it manually for specific PRs only.
Let me know what you think of all this and what will be the best thing to do here.
@dschult @MridulS
Thank you :)

Nice summary! Thanks --
Each time I look at this problem I feel like the solutions are "tricky" (using tricks to get around fundamental issues). I find myself wishing there was a simpler way.  This time I connected those thoughts to other recent discussions like "caching". I think the goal of this effort to update the get_info function could be done without storing the info in the get_info function. We could import nx-parallel and step through each function, collecting the info we need. Instead we are trying to gather that information and "cache" it in python code within the get_info function.
Why are we building get_info as reporting stored literal string info rather than collecting that info directly by importing the package? This is similar to the question of "why are we storing the object rather than constructing it directly?" or "why are we caching?"
The advantages of caching are speed (you don't have to construct/collect anything) and sometimes memory. The disadvantages are keeping the cached version up-to-date with the primary object. In this case, we have two "sources of truth": the get_info function itself and the functions in the package. How do we keep them synchronized without causing pain like merge conflicts, knowing when it is time to update the get_info function, creating and updating a bot script.
All this makes me want to take a step back and see if there is another approach. Here are some thoughts. Do you have others?

can we just have the get_info import the library and collect the info directly in real time? What are the disadvatanges of this approach?
If we stored the two packages in two separate repositories, would that help? _nx_parallel could get updated without changes occurring in the nx_parallel package. Would separation help here?
When is get_info used? If it is only used when building the networkx docs, the benefits of caching the info is not as important because building the published docs happens less often than importing nx_parallel.
How do nx-cugraph and graphblas-algorithms handle their get_info functions?

How do nx-cugraph and graphblas-algorithms handle their get_info functions?

nx-cugraph automates this:

all dispatched algorithms are decorated with @networkx_algorithm that collects metadata and adds the function to the backend interface (here). get_info uses extra_doc and extra_params from networkx_algorithm objects.
our get_info function (here) is updated via make plugin-info

See Makefile
See update script that gets run

this gets run as a pre-commit hook

previously (i.e., before this pre-commit hook), we ran the update scripts in CI and would fail CI if it changed anything (git diff --exit-code)

This has worked well for us, and setting up automation has been well worth the effort. Merge conflicts resulting from multiple PRs that touch the file have been trivial to handle--simply checkout the file that has the generated data, then rerun the script.
CC @rlratzel who may be interested in this discussion
graphblas-algorithms does not yet automate this and would be interested in using a shared "recommended" approach.

I'm not sure how caching could help here because there is no input to the get_info function. We import the nx_parallel package and then extract the docstrings of all the algorithms in it and do string manipulation stuff to make the function dictionary.

can we just have the get_info import the library and collect the info directly in real-time? What are the disadvantages of this approach?

The reason why the nx-parallel docs were not appearing in the additional backend section under the function's docs page was that get_info was extracting docstrings in real time and that was giving that circular import error. So to resolve the issue all I did was copy-paste the output of get_info and make it an independent function. and also I moved it in _nx_parallel from nx_parallel folder. I think @eriknw can explain it better, why entry points can't do real-time extraction of docstrings. Is it just so that we don't have to import the whole backend? or is there something else too?

How do nx-cugraph and graphblas-algorithms handle their get_info functions?

Thank you very much @eriknw for answering this! I'll look into how nx-cugraph does it and ask if I have any questions :)
Thanks!

Thanks @eriknw for that great summary -- and for the links to the code. I had found much of that but not all of it. I had not explored which parts are done in pre-commit at all.
It seems like having it in pre-commit is a convenience, but if someone makes a PR and they don't have pre-commit installed the pre-commit will not run. So don't we also need to have a CI check that the get_info function is accurate?

@Schefflera-Arboricola, there seems to be a difference between importing the library and getting the info using python's inspect tools vs walking the repo and getting the info by pulling it out of the python code/doc_strings. I guess the inspect tools get the info as python sees it after importing the function, while walking the repo gets it as it is specified in the code. Those should normally be the same, but might be different if some mutation of the info occurs during the import process.
Do you have any intuition about which approach is better, or a reason to choose one over the other?


How to deploy an app to githubpages

Please provide us with the following information:

OS?  Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
Mac OSX El Capitan
Versions. Please run ng --version. If there's nothing outputted, please run
in a Terminal: node --version and paste the result here:
angular-cli: 1.0.0-beta.11-webpack.8
node: 6.4.0
os: darwin x64
Repro steps. Was this an app that wasn't created using the CLI? What change did you
do on your code? etc.
Just made a fresh project using ng new
I tried ng github-pages:deploy but error says no angular-cli-build.js was found.
if i run ng build --prod same error
Then in the docs i saw that  angular-cli-build.js was removed
In the docs i saw to run npm install --save-dev angular-cli@webpack after ng new so i did it and now it gives me error Cannot find module './models/config

Please guide how to make a fresh project and deploy to github

Pls check #1854 workaround

I am getting this error after giving token and username
Failed to create GitHub repo. Error: 422 Unprocessable Entity

I get the very same error with:
angular-cli: 1.0.0-beta.10
node: 6.5.0
os: win32 x64
Failed to create GitHub repo. Error: 422 Unprocessable Entity

@jasugh , I got it working by following these steps

After facing this issue i opened my github and there was a repository created for this project
I followed the steps on that readme file by running commands on my project terminal
I tried again g github-pages:deploy and this solved my problem.
The code was in the repository and was accessible on live url.

Ok, thanks. I got it working also.
I wrote instructions to myself:
create a repository ex. test-repository
on command line:
ng new test-repository
cd project
npm install
ng build –prod  (this will create gh-pages branch)
git remote add origin https://github.com/xxxx/test-repository.git
git push -u origin master
ng github-pages:deploy --skip-build
after all that, you will end up with two branches:
master
and
gh-pages

is used to create working github-pages stuff

gh-pages branch can be seen on settings tab of the repository

Fixed in https://github.com/angular/angular-cli/pull/1633/files#diff-a7ba0adbb6fe6918c418062849f4f412

It was removed from angular-cli.
Use https://github.com/angular-buch/angular-cli-ghpages :
Install:
npm i -g angular-cli-ghpages

Deploy:
ng build --prod
ngh


Update ajax headers continously

In environments where the ajaxHeaders property needs to get updated every n minutes, there's no way to invalidate existing tiles except calling TiledImage.reset() which just removes all tiles (from cache and visually) and reloads them.
This behaviour is not too nice, as it just steals away tiles from the user's field of view for some short amount of time. Authorization tokens are often refreshed in less than 1 minute which would yield many forced and visually conceived redraws.
By relying on the tiledImage.ajaxHeaders property instead of the tile.ajaxHeaders we'd be able to change ajax headers constantly while always considering the most up to date ones. What would be the counter arguments against the following approach?
function loadTile( tiledImage, tile, time ) {
    tile.loading = true;
    tiledImage._imageLoader.addJob({
        src: tile.url,
        loadWithAjax: tile.loadWithAjax,
        ajaxHeaders: tiledImage.ajaxHeaders, // Changed from tile.ajaxHeaders
        crossOriginPolicy: tiledImage.crossOriginPolicy,
        ajaxWithCredentials: tiledImage.ajaxWithCredentials,
        callback: function( image, errorMsg, tileRequest ){
            onTileLoad( tiledImage, tile, time, image, errorMsg, tileRequest );
        },
        abort: function() {
            tile.loading = false;
        }
    });
}

Also I didn't get what it's all about to include the token as part of the cache key. Does anyone know why it's done like this?
// Existing code:
if (this.ajaxHeaders) {
    this.cacheKey = this.url + "+" + JSON.stringify(this.ajaxHeaders);
} else {
    this.cacheKey = this.url;
}
// Don't consider ajax headers as part of cache keys at all.
// With this small change, caching, viewing and updating did work just fine:
this.cacheKey = this.url;

Thanks in advance for any information on the topic!

They both sound like good improvements to me. Probably we just didn't think about this scenario at the time.
I believe @seanich did the original Ajax headers work… Sean, any thoughts on these refinements?
@JoFrMueller would you be up for writing a patch?

Thanks for taking the time to review.
Patch could be provided, yes.

Great! Please do :-)


Feature - compose and json serdes

Add JSON support, request by @karimacherradi

Require new IMAGE release @fredrikhgrelland , but first, check #30


"GitHub Time Tracking" data source

Would be really neat to integrate similar style of time tracking that i had built for GitHub Time Tracking: https://github.com/StephenOTT/GitHub-Time-Tracking
Use the GitHub issues as the data source for the time tracking information and use Hours as the data storage and reporting layer

gonna close this one as well, see #349


[ai-form-recognizer] Improve samples

A short list of improvements to samples we can make before GA:

[x] Make return-value length checks simpler (recognizeContent.ts:33)
[x] not necessary to print "First receipt" (et al.) when only one object is expected in the output
[x] Replace uses of for ... in v with for [name, value] of Object.entries(v) or similar
[ ] Make sure the process for labeling data in the containers is clear in the README/samples instructions
[x] Consider removing index trackers such as let i = 0; before iterating over arrays unless they are needed
[x] Consider using type-only coercion in strongly typed receipt sample.

See #10386


Logging not working during dependency graph creation

Logs of level Info (and probably below) not working during dependency graph creation phase, with other words logs which are written within BaseTask.register_required().
Note: Logs of level Error do work.

Background
Even with the new logging implementation in the integration-test-docker-environment this issue has not been resolved.
The reason is that the logging configuration is given to luigi during luigi.build(), which occurs after the register_required() of all tasks have been processed.
Possible Solution
We would need to change the log configuration in the integration-test-docker-environment and use a standard configuration file (not only for logging) as described here: https://luigi.readthedocs.io/en/stable/configuration.html

To solve this, we need to move the task = task_creator() to into the with _configure_logging.
https://github.com/exasol/integration-test-docker-environment/blob/bb462d63abfa2a07c484519b3874da89dfb90198/exasol_integration_test_docker_environment/lib/api/common.py#LL125C5-L125C26
https://github.com/exasol/integration-test-docker-environment/blob/bb462d63abfa2a07c484519b3874da89dfb90198/exasol_integration_test_docker_environment/lib/api/common.py#L151


error while building on CPU backend

I am trying to build flashlight on CPU backend, and there is always an issue when building
I am currently using the older version of MKL-DNN which is 0.18 (since 0.20 is not currently work)
scnhxy@ubuntu:/flashlight/build$ cmake .. -DCMAKE_BUILD_TYPE=Release -DFLASHLIGHT_BACKEND=CPU
-- ArrayFire found (include: /opt/arrayfire/include, library: ArrayFire::afcuda)
-- Checking for [mkl_gf_lp64 - mkl_gnu_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_gf_lp64: /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so
-- Library mkl_gnu_thread: /opt/intel/mkl/lib/intel64/libmkl_gnu_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library iomp5: not found
-- Checking for [mkl_gf_lp64 - mkl_intel_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_gf_lp64: /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so
-- Library mkl_intel_thread: /opt/intel/mkl/lib/intel64/libmkl_intel_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library iomp5: not found
-- Checking for [mkl_gf - mkl_gnu_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_gf: not found
-- Checking for [mkl_gf - mkl_intel_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_gf: not found
-- Checking for [mkl_intel_lp64 - mkl_gnu_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_intel_lp64: /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so
-- Library mkl_gnu_thread: /opt/intel/mkl/lib/intel64/libmkl_gnu_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library iomp5: not found
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_intel_lp64: /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so
-- Library mkl_intel_thread: /opt/intel/mkl/lib/intel64/libmkl_intel_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library iomp5: not found
-- Checking for [mkl_intel - mkl_gnu_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_intel: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core - iomp5 - pthread - m]
-- Library mkl_intel: not found
-- Checking for [mkl_gf_lp64 - mkl_gnu_thread - mkl_core - pthread - m]
-- Library mkl_gf_lp64: /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so
-- Library mkl_gnu_thread: /opt/intel/mkl/lib/intel64/libmkl_gnu_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library pthread: /usr/lib/x86_64-linux-gnu/libpthread.so
-- Library m: /usr/lib/x86_64-linux-gnu/libm.so
-- Checking for [mkl_gf_lp64 - mkl_intel_thread - mkl_core - pthread - m]
-- Library mkl_gf_lp64: /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so
-- Library mkl_intel_thread: /opt/intel/mkl/lib/intel64/libmkl_intel_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library pthread: /usr/lib/x86_64-linux-gnu/libpthread.so
-- Library m: /usr/lib/x86_64-linux-gnu/libm.so
-- Checking for [mkl_gf - mkl_gnu_thread - mkl_core - pthread - m]
-- Library mkl_gf: not found
-- Checking for [mkl_gf - mkl_intel_thread - mkl_core - pthread - m]
-- Library mkl_gf: not found
-- Checking for [mkl_intel_lp64 - mkl_gnu_thread - mkl_core - pthread - m]
-- Library mkl_intel_lp64: /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so
-- Library mkl_gnu_thread: /opt/intel/mkl/lib/intel64/libmkl_gnu_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library pthread: /usr/lib/x86_64-linux-gnu/libpthread.so
-- Library m: /usr/lib/x86_64-linux-gnu/libm.so
-- Checking for [mkl_intel_lp64 - mkl_intel_thread - mkl_core - pthread - m]
-- Library mkl_intel_lp64: /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.so
-- Library mkl_intel_thread: /opt/intel/mkl/lib/intel64/libmkl_intel_thread.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library pthread: /usr/lib/x86_64-linux-gnu/libpthread.so
-- Library m: /usr/lib/x86_64-linux-gnu/libm.so
-- Checking for [mkl_intel - mkl_gnu_thread - mkl_core - pthread - m]
-- Library mkl_intel: not found
-- Checking for [mkl_intel - mkl_intel_thread - mkl_core - pthread - m]
-- Library mkl_intel: not found
-- Checking for [mkl_gf_lp64 - mkl_sequential - mkl_core - m]
-- Library mkl_gf_lp64: /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so
-- Library mkl_sequential: /opt/intel/mkl/lib/intel64/libmkl_sequential.so
-- Library mkl_core: /opt/intel/mkl/lib/intel64/libmkl_core.so
-- Library m: /usr/lib/x86_64-linux-gnu/libm.so
-- MKL found
-- A library with BLAS API found.
-- MKLDNN headers found in /usr/local/include
-- Using MKLDNN library found in /usr/local/lib/libmkldnn.so
-- Using MKL with MKL-DNN
-- MKLDNN found
-- Gloo found
-- NCCL not found
-- MPI_CXX found
-- MPI_CXX compile flags: -pthread
-- MPI_CXX include path: /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include/usr/lib/x86_64-linux-gnu/openmpi/include
-- MPI_CXX LINK flags path: -pthread
-- MPI_CXX libraries: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
-- MPI_C found
-- MPI_C compile flags: -pthread
-- MPI_C include path: /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include/usr/lib/x86_64-linux-gnu/openmpi/include
-- MPI_C LINK flags path: -pthread
-- MPI_C libraries: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/scnhxy/flashlight/build
scnhxy@ubuntu:~/flashlight/build$ sudo make
Scanning dependencies of target cereal
[ 0%] Creating directories for 'cereal'
[ 0%] Performing download step (git clone) for 'cereal'
Cloning into 'cereal'...
Note: checking out '319ce5f5ee5b76cb80617156bf7c95474a2938b1'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b
HEAD is now at 319ce5f Merge pull request #520 from uentity/fix-dll-export
[ 1%] No patch step for 'cereal'
[ 1%] Performing update step for 'cereal'
[ 1%] Performing configure step for 'cereal'
loading initial cache file /home/scnhxy/flashlight/build/cereal/tmp/cereal-cache-Release.cmake
-- The C compiler identification is GNU 7.4.0
-- The CXX compiler identification is GNU 7.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/scnhxy/flashlight/build/cereal/src/cereal
[ 1%] Performing build step for 'cereal'
[ 1%] No install step for 'cereal'
[ 1%] Completed 'cereal'
[ 1%] Built target cereal
Scanning dependencies of target flashlight
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/Variable.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/Functions.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/Utils.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/backend/cpu/Conv2D.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/backend/cpu/Pool2D.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/backend/cpu/RNN.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/backend/cpu/BatchNorm.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/autograd/backend/cpu/MkldnnUtils.cpp.o
[ 1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/common/Utils.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/common/DevicePtr.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/common/Defines.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/BatchDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/BlobDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/ConcatDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/FileBlobDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/MergeDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/PrefetchDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/ResampleDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/ShuffleDataset.cpp.o
[ 2%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/TensorDataset.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/dataset/TransformDataset.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/distributed/DistributedApi.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/distributed/backend/utils/FileStore.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/distributed/reducers/InlineReducer.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/distributed/reducers/CoalescingReducer.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/distributed/backend/cpu/DistributedBackend.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/meter/AverageValueMeter.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/meter/CountMeter.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/meter/EditDistanceMeter.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/meter/FrameErrorMeter.cpp.o
[ 3%] Building CXX object CMakeFiles/flashlight.dir/flashlight/meter/MSEMeter.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/meter/TimeMeter.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/DistributedUtils.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/Init.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/Utils.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Activations.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/AdaptiveSoftMax.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/BatchNorm.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Container.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Conv2D.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Dropout.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Embedding.cpp.o
[ 4%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/LayerNorm.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Linear.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Loss.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Module.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Padding.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Pool2D.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Reorder.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/RNN.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/Transform.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/View.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/nn/modules/WeightNorm.cpp.o
[ 5%] Building CXX object CMakeFiles/flashlight.dir/flashlight/optim/Optimizers.cpp.o
[ 6%] Building CXX object CMakeFiles/flashlight.dir/flashlight/optim/Utils.cpp.o
[ 6%] Building CXX object CMakeFiles/flashlight.dir/flashlight/contrib/modules/Residual.cpp.o
[ 6%] Building CXX object CMakeFiles/flashlight.dir/flashlight/contrib/modules/AsymmetricConv1D.cpp.o
[ 6%] Linking CXX static library libflashlight.a
[ 6%] Built target flashlight
Scanning dependencies of target gtest
[ 6%] Creating directories for 'gtest'
[ 6%] Performing download step (git clone) for 'gtest'
Cloning into 'gtest'...
Note: checking out '2fe3bd994b3189899d93f1d5a881e725e046fdc2'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b
HEAD is now at 2fe3bd99 Merge pull request #1433 from dsacre/fix-clang-warnings
[ 6%] No patch step for 'gtest'
[ 6%] Performing update step for 'gtest'
[ 6%] Performing configure step for 'gtest'
loading initial cache file /home/scnhxy/flashlight/build/tests/googletest/tmp/gtest-cache-Release.cmake
-- The C compiler identification is GNU 7.4.0
-- The CXX compiler identification is GNU 7.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.15")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /home/scnhxy/flashlight/build/tests/googletest/src/gtest
[ 7%] Performing build step for 'gtest'
Scanning dependencies of target gtest
[ 25%] Building CXX object googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
[ 50%] Linking CXX static library libgtest.a
[ 50%] Built target gtest
Scanning dependencies of target gtest_main
[ 75%] Building CXX object googletest/CMakeFiles/gtest_main.dir/src/gtest_main.cc.o
[100%] Linking CXX static library libgtest_main.a
[100%] Built target gtest_main
[ 7%] No install step for 'gtest'
[ 7%] Completed 'gtest'
[ 7%] Built target gtest
Scanning dependencies of target SerializationTest
[ 7%] Building CXX object tests/CMakeFiles/SerializationTest.dir/nn/SerializationTest.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/Variable.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/Functions.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/Utils.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/backend/cpu/Conv2D.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/backend/cpu/Pool2D.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/backend/cpu/RNN.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/backend/cpu/BatchNorm.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/autograd/backend/cpu/MkldnnUtils.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/common/Utils.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/common/DevicePtr.cpp.o
[ 8%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/common/Defines.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/BatchDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/BlobDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/ConcatDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/FileBlobDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/MergeDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/PrefetchDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/ResampleDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/ShuffleDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/TensorDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/dataset/TransformDataset.cpp.o
[ 9%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/distributed/DistributedApi.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/distributed/backend/utils/FileStore.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/distributed/reducers/InlineReducer.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/distributed/reducers/CoalescingReducer.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/distributed/backend/cpu/DistributedBackend.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/meter/AverageValueMeter.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/meter/CountMeter.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/meter/EditDistanceMeter.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/meter/FrameErrorMeter.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/meter/MSEMeter.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/meter/TimeMeter.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/DistributedUtils.cpp.o
[ 10%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/Init.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/Utils.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Activations.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/AdaptiveSoftMax.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/BatchNorm.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Container.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Conv2D.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Dropout.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Embedding.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/LayerNorm.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Linear.cpp.o
[ 11%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Loss.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Module.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Padding.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Pool2D.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Reorder.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/RNN.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/Transform.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/View.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/nn/modules/WeightNorm.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/optim/Optimizers.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/optim/Utils.cpp.o
[ 12%] Building CXX object tests/CMakeFiles/SerializationTest.dir//flashlight/contrib/modules/Residual.cpp.o
[ 13%] Building CXX object tests/CMakeFiles/SerializationTest.dir/__/flashlight/contrib/modules/AsymmetricConv1D.cpp.o
[ 13%] Linking CXX executable SerializationTest
/usr/bin/ld: warning: libiomp5.so, needed by /usr/local/lib/libmkldnn.so, not found (try using -rpath or -rpath-link)
/usr/local/lib/libmkldnn.so: undefined reference to omp_in_parallel@VERSION' /usr/local/lib/libmkldnn.so: undefined reference to GOMP_barrier@VERSION'
/usr/local/lib/libmkldnn.so: undefined reference to omp_get_num_threads@VERSION' /usr/local/lib/libmkldnn.so: undefined reference to GOMP_parallel@VERSION'
/usr/local/lib/libmkldnn.so: undefined reference to omp_get_max_threads@VERSION' /usr/local/lib/libmkldnn.so: undefined reference to omp_get_thread_num@VERSION'
collect2: error: ld returned 1 exit status
tests/CMakeFiles/SerializationTest.dir/build.make:1588: recipe for target 'tests/SerializationTest' failed
make[2]: *** [tests/SerializationTest] Error 1
CMakeFiles/Makefile2:1077: recipe for target 'tests/CMakeFiles/SerializationTest.dir/all' failed
make[1]: *** [tests/CMakeFiles/SerializationTest.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

@wujinxuwu — you'll see CMake has -- Library iomp5: not found, it needs that to link with MKL-DNN if you're using the MKL backend.
You should be able to reproduce this same issue if you build the MKL-DNN tests - can you try building and running those and see if you have the same problem?


Fix docker-compose - Depecrated

🗣 Description
GitHub deprecated v1 of Docker compose which used the docker-compose command. The updated version uses "docker compose" instead.
Updated all uses in github actions and the npm aliases.
Reference:
https://github.com/orgs/community/discussions/116610
💭 Motivation and context
Docker-compose command is breaking in github actions.
🧪 Testing
Tested full build locally and passes pre-commits and github checks.

✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All future TODOs are captured in issues, which are referenced
in code comments.
[x] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[x] Tests have been added and/or modified to cover the changes in this PR.
[x] All new and existing tests pass.

✅ Pre-merge checklist

[x] Revert dependencies to default branches.
[x] Finalize version.

✅ Post-merge checklist

[x] Create a release.

@dav3r  or @jsf9k - Looks like we need your approval on this one. Thanks


feat: add horizontal headers

Refs: VIZ-2530

Just a quick question about the Thick borders, I believe you kept it for another PR right?

I'm quite sure that we discussed about this scenario, probably you kept for next one right?
https://github.com/qlik-oss/sn-pivot-table/assets/29652890/cc9189f7-a6b6-4765-a66e-543481176423

Just a quick question about the Thick borders, I believe you kept it for another PR right?

Correct. I will do styling later

I believe we have fixed this issue in one of the prs, but it's good to keep and eye on it to not re-introduce it
https://github.com/qlik-oss/sn-pivot-table/assets/29652890/d822710a-256b-4fee-a5b0-0fc27993055d

If i try to move all dims into columns (in order to make them all stacked on top of each other), I will get some problem while resizing and there will be free space in Headers grid
https://github.com/qlik-oss/sn-pivot-table/assets/29652890/d974fc5c-ca13-4340-98dc-11ef0e139c87

I think (maybe) the free row scenario also causes another issue on scrolling -> it makes left grid and data grid to be out of sync when it comes to the end of page
https://github.com/qlik-oss/sn-pivot-table/assets/29652890/2ef00d83-a75e-4e6e-9a9e-8d38e6d1b6be

I noticed a small issue:
when you resize the last column in x axis, first it tries to show label fully and avoids to set the width to the min width (30px), but then if i do it again, it sets properly
https://github.com/qlik-oss/sn-pivot-table/assets/29652890/123110f6-461d-4c77-9eaa-ad0048ee8099

:tada: This PR is included in version 2.5.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Build full and incremental artifacts

I can provide you copies of the artifacts I have buit

yea sorry for the misunderstanding, its a technical term describing the "something" that  can be deployed.


I get the Fiber but what's Stack?

Hey React Fiber Seems super fast from the example. However, I am not very aware with the Stack, is it the name of the technology behind the previous version of react? Any pointers will be very appreciated. Thanks a lot that's a cool triangle example.

Hi @abdulhannanali, yes that's correct. Stack is a posthumous name given to the pre-existing implementation of React's reconciler. Watch this recording by Kent C. Dodds for further details. Thanks for stopping by and taking the time to comment!

Thanks a lot for answering the query @claudiopro Seems really exciting


git-sweep freezes up

When I run the latest git-sweep on a large repo w/ python 3.6 and Windows 10 it freezes up and doesn't give any progress.
Bug: the freeze
Feature request: provide progress indicator
Command: git-sweep preview --master=dev

Actually, looks like this project is no longer maintained and is not compatible with python 3 :(

I added a print(ref) to merged_refs in inspector.py and the git-sweep does actually make progress - but each ref takes several seconds! It's not actually the fault of git sweep, either. The git cherry command takes up a ridiculously long time:
caleb@DESKTOP-AE53KE4:~/work/fifteen5$ time git cherry origin/dev origin/1-on-1-metrics-tables-draft
+ f72f4fcffd79188ea498a89cd779d1d2335429f6
+ 658f2ac3fc925d164b6da14b3150ee52ffdb11f4

real    0m4.315s
user    0m0.929s
sys     0m0.403s


kube-router document is moved (dead link)

NG: https://github.com/cloudnativelabs/kube-router/tree/master/Documentation#try-kube-router-with-cluster-installers
OK https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers
For example, this page contain dead link.
https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/
Note:
China page don't have this link.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 1.11 Features: set Milestone to 1.11 and Base Branch to release-1.11
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: After opening the PR, please un-check and re-check the "Allow edits from maintainers" box so that maintainers can work on your patch and speed up the review process. This is a temporary workaround to address a known issue with GitHub.>
Please delete this note before submitting the pull request.

Hello bradtopol.
Please approve :)
I have already checked my changes at deployed staging now.
https://deploy-preview-8741--kubernetes-io-master-staging.netlify.com/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/
NG page now: https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/
/assign @bradtopol

I heard from mistyhacks, HUGO migration is checked by you.
Thank you for your help!
/assign @steveperry-53
/assign @Bradamant3

/lgtm
/approve


Add support for strings as list

Addresses #853. Adds support for map, filter, at, and fold on strings. It treats chars as singleton strings. Note that filter on a string returns a list of singleton strings instead of a filtered string.

Closing in favor of #874


Implement follow-up text/email/reminder feature

Tasks (not exhaustive)
Content
Implementation

https://github.com/SuffolkLITLab/docassemble-AssemblyLine/pull/643

Important dates, how do we calculate those dates

We have the reminder feature, but am not sure if this references something else @nonprofittechy

I think we only remind people to file their documents the next day right now. We should consider adding in court date reminders if we already have those as dates we know. Possibly a reminder to follow up on discovery.

Testing the eviction interview on 6/25, said the hearing date was 6/28
Added updating or adding reminders to the documentation

#627


Show state borders in national view (S)

Involves design decision about coloring - should current background get to be lighter or even transparent, in favor of just showing borders? Should the borders themselves be white, leaving the grey states background?

For now, let’s add a white stroke to the currently grey polygons. It would be good to lump these style properties (fill and stroke colors) in the same spot in css or be able to easily find in js so we can try various map styles.

Sounds good. As noted on a recent call, maybe someday we can figure out a better place for these (for starters, could move them to their own .js file if that would help)...but in the meantime, i hope editing these properties is relatively straightforward for anyone with this link: https://github.com/USGS-VIZLAB/water-use-15/blob/8c3c20f604388f8c68bd0e917919334e6b7e6871/js/map_utils.js#L6-L32

So is this task still to make the background grey and the state boarders white? Or, are we sticking with white background, black boarders, and a grey fill for the hovered county?


Ruby build not defaulting to using the Mise host to fetch versions

Describe the bug
Looking at the documentation over here:
https://mise.jdx.dev/configuration.html#mise-use-versions-host
Describes that this setting is default and should use the mise host instead of Github to fetch the current versions list and understand what to download.
Locally I am testing this and not seeing this behaviour, its constantly going to Githubs API to fetch the available versions. Reason this has come up is because we have been getting rate limited on the API and this seems to be the cause.
I looked into the code base to try and understand deeper and can only see this path being the only function that does not early return or use the fetch_remote_versions_from_mise function, so would be going to Github by default:
https://github.com/jdx/mise/blob/f8ce139c1d0b41006dbbf1707801bf665f201ec6/src/plugins/core/ruby.rs#L355
I am not a Rust developer so this is as far as my skillset will allow me to debug further unfortunately.
I even tried to override the environment variable MISE_USE_VERSIONS_HOST=true to see if the default wasn't working, but this had the same result.
To Reproduce
Install a version of ruby on your machine with --verbose mode and see mise fetching the version from Github instead of the mise URL.
λ mise install --verbose
[DEBUG] ARGS: /opt/homebrew/bin/mise install --verbose
[DEBUG] Config {
    Config Files: [
        "~/.mise.toml",
    ],
    Env: {
        "MISE_USE_VERSIONS_HOST": "true",
    },
}
[DEBUG] Toolset<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>[DEBUG] $ /Users/lucasteligiordis/Library/Caches/mise/ruby/ruby-build/bin/ruby-build --version
[DEBUG] GET https://api.github.com/repos/rbenv/ruby-build/releases/latest
[DEBUG] starting new connection: https://api.github.com/
[DEBUG] GET https://api.github.com/repos/rbenv/ruby-build/releases/latest 200 OK
running ruby-build

Expected behavior
Use the mise host instead of Github to prevent being rate limited.
mise doctor output
version: 2024.4.12 macos-arm64 (2024-04-30)
activated: yes
shims_on_path: no

build_info:
  Target: aarch64-apple-darwin
  Features: DEFAULT, NATIVE_TLS
  Built: Tue, 30 Apr 2024 23:30:07 +0000
  Rust Version: rustc 1.77.2 (25ef9e3d8 2024-04-09) (Homebrew)
  Profile: release

shell:
  /opt/homebrew/bin/bash
  GNU bash, version 5.2.26(1)-release (aarch64-apple-darwin23.2.0)
  Copyright (C) 2022 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.

dirs:
  data: ~/.config/mise
  config: ~/.config/mise
  cache: ~/Library/Caches/mise
  state: ~/.local/state/mise
  shims: ~/.config/mise/shims

config_files:
  ~/.mise.toml

backends:
  cargo
  go
  npm
  pipx
  ubi

plugins:
  bun        (core)
  deno       (core)
  gcloud     https://github.com/jthegedus/asdf-gcloud.git#00cdf06
  go         (core)
  java       (core)
  kubectl    https://github.com/asdf-community/asdf-kubectl.git#cbe6df4
  node       (core)
  packer     https://github.com/asdf-community/asdf-hashicorp.git#197e3ec
  postgres   https://github.com/smashedtoatoms/asdf-postgres.git#4592b64
  python     (core)
  redis      https://github.com/smashedtoatoms/asdf-redis.git#d5a67c5
  ruby       (core)
  terraform  https://github.com/asdf-community/asdf-hashicorp.git#197e3ec
  yarn       https://github.com/twuni/asdf-yarn.git#376c540

toolset:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>          (missing)
<EMAIL_ADDRESS><EMAIL_ADDRESS>
env_vars:
  MISE_USE_VERSIONS_HOST=true
  MISE_SHELL=bash

settings:
  activate_aggressive = true
  all_compile = false
  always_keep_download = false
  always_keep_install = false
  asdf_compat = false
  cargo_binstall = true
  color = true
  disable_default_shorthands = false
  disable_tools = []
  experimental = false
  go_default_packages_file = "~/.default-go-packages"
  go_download_mirror = "https://dl.google.com/go"
  go_repo = "https://github.com/golang/go"
  go_set_gopath = false
  go_set_goroot = true
  go_skip_checksum = false
  jobs = 4
  legacy_version_file = true
  legacy_version_file_disable_tools = []
  node_compile = false
  not_found_auto_install = true
  paranoid = false
  plugin_autoupdate_last_check_duration = "7d"
  python_compile = false
  python_default_packages_file = "/Users/lucasteligiordis/.default-python-packages"
  python_pyenv_repo = "https://github.com/pyenv/pyenv.git"
  raw = false
  trusted_config_paths = []
  quiet = false
  verbose = false
  yes = true
  ci = false
  debug = false
  trace = false
  log_level = "info"
  python_venv_auto_create = false

  [status]
  missing_tools = "if_other_versions_installed"
  show_env = false
  show_tools = false

No warnings found
No problems found

Additional context
This might be intended behaviour here in which case, any suggestions are welcomed!
I know I can fall back to using the asdf plugin which just has the build version hard coded and does a git fetch instead of using the API at all, but would rather keep the core plugin here and see what can be done before doing that. Appreciate any help! :)

It uses the version host to check for new ruby versions but what you're seeing is it checking for new versions of ruby-build which the versions host does not track.

Is there anyway we can force this to use non-github requests here somehow? The rate limit kills us.
If I can't change this I'll have to go back to using the asdf ruby plugin in mise, but I'd rather use the core ruby plugin here.

it just shouldn't crash if it can't detect the ruby-build version

Crash? Nothing is crashing, everything is working as expected. Its just when we have mise running on our CI hosts, we get smashed with the rate limit due to the huge concurrency so its a bit of a deal breaker for that network.
Just has a large impact.

in this case ruby-build is already installed, it just is throwing an error not allowing anything to proceed because it can't check if that version isn't the latest. In that case we can probably still use ruby-build just fine and should.

in other words, this is an error that should just be a warning

Does this code change you just made mean that calls to Github are only made when necessary?
Not sure if there is a bug, but it looks like somewhere in our chain even though we have ruby updated and ruby build installed, Github calls are being made constantly. (we check the ruby version on practically every CI run to ensure it has the right version installed)

Ah I see the code change won't make a difference with calls to Github as the call to latest_ruby_build_version is made unconditionally to check the latest version against the installed one.
The core of the issue I raised is to see how we can avoid that call to Github entirely, without caching the version list like mise does with all the other core versions, is there a way I can force mise to not look for a latest release anywhere with an env var or something? Pretty much if I have a version of ruby-build installed I am happy to use that until I deem it necessary to update.
I'd prefer to have a cached version on the mise endpoint like the others and have it auto-update but don't know what the effort that is to get ruby-build there as well.

what is it you're running exactly that is causing this check? it should only be checking the ruby-build version if it is about to actually install a new version of ruby-build or if it's configured not to use the versions host.
Another solution is you could create a github token (doesn't need any roles) and assign it to GITHUB_API_TOKEN which will get around the rate limit problem and that's a convention used throughout both mise and asdf.

Here is an output to the API on the network we have this mise ruby install happening:
x-github-media-type: github.v3; format=json
x-ratelimit-limit: 60
x-ratelimit-remaining: 0
x-ratelimit-reset:<PHONE_NUMBER>
x-ratelimit-resource: core
x-ratelimit-used: 60
content-length: 280

Even though ruby is already installed, in CI we run a mise install ruby to ensure CI is kept up to sync with the Git repo. 99/100 its a no-op as our ruby version rarely changes.
But I guess somewhere in the code there is still a call being made somewhere to the Github API even though there is actually no ruby to install? So then we get rate limited etc... and engineers (non CI) is impacted when they need to have ruby installed on their machines with the rate limit error. (might be a fresh machine)

anything using that ip address may be hitting github, how do you know it's mise?

when I run mise install ruby it definitely doesn't connect to the github api:
mise  main   ❯ mise install ruby --verbose
[DEBUG] ARGS: mise install ruby --verbose
[DEBUG] Config {
    Config Files: [
        "~/src/mise/.mise.local.toml",
        "~/src/mise/.mise.toml",
        "~/src/mise/.mise/config.toml",
        "~/src/mise/.tool-versions",
        "~/src/mise/.node-version",
        "~/.config/mise/config.toml",
        "~/.tool-versions",
    ],
    Env: {
        "FOO_FROM_FILE": "foo_from_file",
        "FOO": ".mise.local.toml",
        "FOO_NUM": "1",
        "THIS_PROJECT": "/Users/jdx/src/mise-/Users/jdx/src/mise",
    },
    Path Dirs: [
        "/Users/jdx/src/mise/target/debug",
    ],
    Aliases: {
        ForgeArg("tiny"): {
            "abc": "1",
        },
    },
}
[DEBUG] GET http://mise-versions.jdx.dev/go
[DEBUG] starting new connection: http://mise-versions.jdx.dev/
[DEBUG] GET http://mise-versions.jdx.dev/go 200 OK
[DEBUG] Toolset: tiny@1, go@prefix:1.21, python@latest, <EMAIL_ADDRESS>shfmt@3, cargo:cargo-edit@latest, cargo:cargo-show@latest, cargo:git-cliff@latest, <EMAIL_ADDRESS>npm:prettier@3, jq@latest, node@lts/hydrogen, ruby@latest, java@22

Because I just migrated mise to the machines and replaced it from asdf and thats when we started seeing the issue.
Also your output above is exactly what I experienced locally as well (on my machine). So perhaps it was still catching up over the migration and doing the initial load of ruby.
This still means without the GITHUB_API_TOKEN I'll get rate limited whenever we do a ruby update/install.

yes, but it shouldn't cause a real problem. Unless you're connecting to github for other things, but then those other things would probably be hitting rate limits anyways.

in the asdf plugin this isn't a problem because they hardcode the ruby-build version—the downside of that is anytime a new version of ruby comes out you have to update the plugin before you will see the new version of ruby. If you want that behavior though you can just install asdf-ruby into mise.

The real problem is that unfortunately these CI machines run from our "main" office, which is under a single public IP.
So when these machines do a ruby update due to a new version that we've likely bumped, means all our engineers will need this same update, anyone in the office will be rate limited and not able to install ruby etc...
That was the actual problem that we faced.

anyone in the office will be rate limited and not able to install ruby etc

but this is what my patch fixes

you can just install asdf-ruby into mise

totally get it, looked at their source code and saw that its hard coded, just wanting to initially avoid that as I'd rather support the core mise plugins initially.

thinking it through just now, I suppose there is an edge case that I can sort out. If it can't detect the ruby-build version right now it just uses the old one but it's probably better to just attempt to update if it can't get the version

but this is what my patch fixes

Yeah so the patch would mean that if we have people who have bootstrapped already and have a version of ruby-build then it wouldn't block them and it would carry on right? Unless its a new machine entirely.

then it wouldn't block them and it would carry on right

yes, with the old version of ruby-build, but I'm going to change this slightly to attempt to update anyways

Unless its a new machine entirely.

new machines don't need to check the version, it's assumed to be out of date

new machines don't need to check the version, it's assumed to be out of date

Oh right, okay so maybe now that we're all up and running and updated and everything is migrated over and there is no mass onboarding of it. In theory we should have reduced hits to Github's API and even a new machine shouldn't be impacted?

slightly to attempt to update anyways

No worries, happy to test out as well if you want some test-cases.

while you wait for a fix you could delete ~/.cache/mise/ruby/ruby-build before installing ruby which would prevent it from attempting to check the version

Okay thats not a bad workaround! Can you TL;DR me in that case how it understand what version to even install without hitting the Github API to check what to download?

lol: https://github.com/jdx/mise/blob/main/src/plugins/core/ruby.rs#L108-L109
lmk if you don't get it

Oh haha, yeah thats obvious now that I think about it 🙃


Register callbacks

Fixes #1

@Positive07 Would you mind squashing your commits and maybe rebasing on top of master?

Yeah sure... will make a new PR though (my git skills are not that great)

@Positive07 I can do it through the web interface too if it's too much of a hassle for you :)

I think that may be easier than deleting my fork, reforking, create a branch, clone, commit changes, pushing and making a PR... hahahaha go for it!

@Positive07 Done 🎉
Git can be complicated as f*ck sometimes ^^ When I update my PRs on github I usually use:
git add . # Stages all changes
git commit -a --amend --no-edit # Merge the changes into the last commit
git push --force # Force push to update history (this should never be done on branches like master or develop though)

Knowledge acquired!
Note on docs: performChanges should have an advice telling that user doesn't need to normally call that since it's called after draw internally

Hahaha I just looked at performChanges and thought that we could simply make it local xD
The documentation on gh-pages was created automatically with doclua. Last time I tried to use that I had some issues, but I'll see what I can do.

It could be local... but there is a small benefit on making it public and that is that people who complain about changes not being immediate can call performChanges themselves and there they go...
Have never used documentation from comments really. I know that there was one that was deprecated and one that succeed it... I think LDoc is the updated one? don't remember

Woops ... already changed it with the latest commit :P
I'll look for LDoc.


DC-funded affordable housing units on opendata.dc.gov

Add the DC-funded buildings to our list of all affordable buildings and subsidies using the Affordable Housing dataset on opendata.dc.gov. See notes on what is in this data set in #137 .
Current related data:
Our current database contains a 'projects' table, which is pulled from the Preservation Catalog. In addition, it has a 'subsidy' table, where project -> subsidy is one->many.  This catalog aggregates all the subsidized buildings from the lists published by the federal government; therefore it only contains buildings federally subsidized buildings. It does not systematically include buildings that have only received subsidies from the DC Government;
Data adding
We want to create a row in the project table and in the subsidy table corresponding to each additional building in the opendata.dc.gov dataset.
There are several ways that a duplicate record could be created, which we want to avoid:

LIHTC funding is distributed by DHCD; the PresCat includes data from the federal list of LIHTC recipients, so we would expect most of these buildings to be duplicated (and would like to flag any that are not in the federal list but are in the DHCD list.
A federally subsidized building can get an additional subsidy/rehab loan from DHCD. In this case, we want to add a record only to the 'subsidy' table and link it to the proper 'project' row using NLHIC_ID
Occasionally buildings are manually added to the PresCat, so these may already be in the catalog. We want to update any fields in the 'project' table if better data is available from DHCD.
There a large number of subsidy records (and corresponding project records) that have the subsidy source "DC/AFFPIPELINE". These are at least 8 years old (though the data for the subsidy is likely still valid) - there may be a few overlapping buildings but for the most part new buildings are not being added to the Preservation Catalog currently.

Methodology

[x] Create a DCHousingApiConn class based on the MarApiConn class currently in the code. Use this to add raw data files to /data/raw/tax_assessment/opendata/YYYYMMDD when the python/cmd/data.py script is run with the appropriate arguments. Write a demo command to run at the command line to create this file with the appropriate datestamp.
(pull request after step 1)
[x] Adjust the relevant meta.json and manifest.csv to add both this new flat file and the most recent preservation_catalog file to the projects table in the database. You'll likely need to use the newly-created 'optional' fields. Related guidance is here:  adding a new dataset. In the DCHousingCleaner, you'll need to supply duplicate entity matching to not duplicate buildings we already know about.
[x] For every building in the source data set (whether or not a duplicate entry was found), create a new entry in the subsidy table. We'll need to figure out best way to do this - likely by creating a second flat file during the cleaning stage. The easiest way to do this without big alterations to our current ingestion process is assume that the newly created subsidy file will be available to the ingestion code by placing the subsidy file in the list after the affordable housing file.

@jkwening you should also know about this work that has already been done on some de-duplication scripts. It has not been merged in so it is not in the current code base - I will ask Louis to do a pull request. But, you won't want to use it directly - instead you can pull from it as needed to incorporate into the object-oriented approach we're using now.

PR 233 is merged in! Next up: combining the dchousing table with the projects table. @jkwening let's discuss tonight.

Hey @jkwening Flagging a future issue we'll run into using the endpoint you set up for this. ESRI by default limits the API calls to 1,000 records, as we found in #198 . Using the geojson endpoint but swapping .geojson for .csv will return the full api data already formatted as .csv. We should switch to this data download method - though you can maybe wait to convert the code until we do another api endpoint, as we might end up making an opendata conn base class that does stuff like this.

@jkwening In case it's helpful, here's a basic diagram of the Preservation Catalog file schema.
https://urbanorg.box.com/s/t1t8cg9228agxdvvqpg61uxdo7qj8gwe

Cleaning up related data ingestion issues - closing because it looks like this has been completed. Note - there are some outstanding issues related to cleaning up encoded data for the project table fields ( #373)

Note, I moved the flagged issue in my May 12 comment into its own issue #374


Compilation error

Hey,
I tried to compile your program, but I always get the same error. I tried to solve it myself, but all the solutions I found on stackoverflow did not work. Do you have any idea what is going wrong? I'm running Ubuntu 22.04.
$ make exact
gcc -g -std=gnu17 -O3 -march=native -I include -D _GNU_SOURCE -static -mssse3  -MMD -c src/tiny_solver.c -o bin/tiny_solver.o
src/tiny_solver.c: In function ‘fill_dp_avx’:
src/tiny_solver.c:24:21: warning: AVX vector return without AVX enabled changes the ABI [-Wpsabi]
   24 |             __m256i m0 = _mm256_load_si256((__m256i *)(i_vec + 0));
      |                     ^~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:536:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_extract_epi32’: target specific option mismatch
  536 | _mm256_extract_epi32 (__m256i __X, int const __N)
      | ^~~~~~~~~~~~~~~~~~~~
src/tiny_solver.c:42:51: note: called from here
   42 |             int c = _mm256_extract_epi32(w0, 0) + _mm256_extract_epi32(w0, 4);
      |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:536:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_extract_epi32’: target specific option mismatch
  536 | _mm256_extract_epi32 (__m256i __X, int const __N)
      | ^~~~~~~~~~~~~~~~~~~~
src/tiny_solver.c:42:21: note: called from here
   42 |             int c = _mm256_extract_epi32(w0, 0) + _mm256_extract_epi32(w0, 4);
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:47,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx2intrin.h:295:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_epi32’: target specific option mismatch
  295 | _mm256_hadd_epi32 (__m256i __X, __m256i __Y)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:40:18: note: called from here
   40 |             w0 = _mm256_hadd_epi32(w0, w0);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:47,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx2intrin.h:295:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_epi32’: target specific option mismatch
  295 | _mm256_hadd_epi32 (__m256i __X, __m256i __Y)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:39:18: note: called from here
   39 |             w0 = _mm256_hadd_epi32(w0, w0);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:47,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx2intrin.h:295:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_epi32’: target specific option mismatch
  295 | _mm256_hadd_epi32 (__m256i __X, __m256i __Y)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:37:18: note: called from here
   37 |             w0 = _mm256_hadd_epi32(w0, w2);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:47,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx2intrin.h:295:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_epi32’: target specific option mismatch
  295 | _mm256_hadd_epi32 (__m256i __X, __m256i __Y)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:36:18: note: called from here
   36 |             w0 = _mm256_hadd_epi32(w0, w1);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:47,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx2intrin.h:179:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_and_si256’: target specific option mismatch
  179 | _mm256_and_si256 (__m256i __A, __m256i __B)
      | ^~~~~~~~~~~~~~~~
src/tiny_solver.c:34:18: note: called from here
   34 |             w2 = _mm256_and_si256(m2, w2);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:47,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx2intrin.h:179:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_and_si256’: target specific option mismatch
  179 | _mm256_and_si256 (__m256i __A, __m256i __B)
      | ^~~~~~~~~~~~~~~~
src/tiny_solver.c:33:18: note: called from here
   33 |             w1 = _mm256_and_si256(m1, w1);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:47,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx2intrin.h:179:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_and_si256’: target specific option mismatch
  179 | _mm256_and_si256 (__m256i __A, __m256i __B)
      | ^~~~~~~~~~~~~~~~
src/tiny_solver.c:32:18: note: called from here
   32 |             w0 = _mm256_and_si256(m0, w0);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:915:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_load_si256’: target specific option mismatch
  915 | _mm256_load_si256 (__m256i const *__P)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:30:26: note: called from here
   30 |             __m256i w2 = _mm256_load_si256((__m256i *)(W[j] + 16));
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:915:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_load_si256’: target specific option mismatch
  915 | _mm256_load_si256 (__m256i const *__P)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:29:26: note: called from here
   29 |             __m256i w1 = _mm256_load_si256((__m256i *)(W[j] + 8));
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:915:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_load_si256’: target specific option mismatch
  915 | _mm256_load_si256 (__m256i const *__P)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:28:26: note: called from here
   28 |             __m256i w0 = _mm256_load_si256((__m256i *)(W[j] + 0));
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:915:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_load_si256’: target specific option mismatch
  915 | _mm256_load_si256 (__m256i const *__P)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:26:26: note: called from here
   26 |             __m256i m2 = _mm256_load_si256((__m256i *)(i_vec + 16));
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:915:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_load_si256’: target specific option mismatch
  915 | _mm256_load_si256 (__m256i const *__P)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:25:26: note: called from here
   25 |             __m256i m1 = _mm256_load_si256((__m256i *)(i_vec + 8));
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:43,
                 from src/tiny_solver.c:4:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avxintrin.h:915:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_load_si256’: target specific option mismatch
  915 | _mm256_load_si256 (__m256i const *__P)
      | ^~~~~~~~~~~~~~~~~
src/tiny_solver.c:24:26: note: called from here
   24 |             __m256i m0 = _mm256_load_si256((__m256i *)(i_vec + 0));
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:30: bin/tiny_solver.o] Error 1

Hi,
When compiling for Optil, I'd always use -march=haswell (instead of native). My first try would be to change that to -march=icelake-server now, assuming that's the correct cpu architecture you're using. Otherwise, trying -mavx2 could also work. The problem seems to be the few AVX instructions we use to solve small instances fast (<20 vertices). They should be supported on both the CPU's you mentioned, but I apology for the issues.

Thanks for the fast reply! Compiling with -march=icelake-server indeed worked.


NEXT: Improved dark mode support

This will act as a hub to centralize for this information.
See Also

https://github.com/skeletonlabs/skeleton/issues/2360
https://github.com/skeletonlabs/skeleton/issues/1142
https://github.com/skeletonlabs/skeleton/discussions/951
https://tailwindcss.com/docs/dark-mode

Maintainer Requests
The following requests are coming straight from the Skeleton team. These are highly likely be implemented:

[x] Support both the OS and Class-based strategies from Tailwind
[x] @AdrianGonz97 believes this technique may make it easier to author custom classes

Community Requests
The following requests have come from the community and are under consideration:

...

Bugs and Issues

[x] https://github.com/skeletonlabs/skeleton/issues/1657

Feedback
If you have additional updates or requests for this feature, please do so in the comments section below.

@AdrianGonz97 I shared this on Discord, but to echo here for future reference:

@cokakoala so I've finally had a chance to sit down and look through the CSS compile scripts and I think I've found where our OS strategy dark mode bug is coming from. It seems you use a local Tailwind Config to determine the way the styles are processed:
https://github.com/skeletonlabs/skeleton/blob/feat/next-tailwind-plugin/packages/skeleton/scripts/compile-css-to-js.ts#L32
If I update both the doc site TW config AND this script TW config to remove the darkMode: class option, then all styles suddenly start working with the OS toggle. BUT, the two configs have to be in sync. If I try OS+Class or Class+OS things are out of sync and we get the weird style issues. Do we maybe need to pass that setting down to the plugin in some fashion?
Here's what class-based generates:

Here's what OS-based generates:

So ideally we need some way for our plugin to capture the same darkMode setting the users are using in their local project. It's the only way to ensure this matches up. Zero clue how we handle this though!

With #2431 we can now consider this task done as well. Closing this out!
Per the Lightswitch feature - this will likely take the form of a guide rather than a single component, so I'm going to move that over to the Documentation ticket for now. The instructions for setting this up may differ framework to framework (especially meta frameworks like Astro) so we'll handle this in a dedicated section.


Contributing docs develop

Should be merged along with https://github.com/divio/django-cms/pull/3553

Coverage decreased (-0.1%) to 90.704% when pulling 4872297a363640789a6f3cd774201fdc8c39aeed on evildmp:contributing-docs-develop into 6c3cdfccbe08fc3ed7c9b7ea3b365ed7c0c432b4 on divio:develop.


[Single] Remove gst dependency from single-shot

Remove gst dependency from singlep-shot.
*After: https://github.com/nnstreamer/nnstreamer/pull/3652
Self evaluation:
Build test: [ *]Passed [ ]Failed [ ]Skipped
Run test: [ *]Passed [ ]Failed [ ]Skipped
Signed-off-by: gichan<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #133. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnstreamer.mooo.com/.

:octocat: cibot: @gichan-jang, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnstreamer.mooo.com/nnstreamer-api/ci/repo-workers/pr-checker/133-202201282053080.51714611053467-e95f2e7e72b395762edf29169d28a0600debc149/.

If we have ml-api-inference-single.so and ml-api-inference-pipeline.so, what does ml-api-inference.so do? What's the dependency relation between the three?
For the purpose of ml-api-inference-single.so (minimal dependency) and the backward compatibility, you might need to make ml-api-inference.so as a dummy .so (w/o actual contents in it) with dependency information only. And the dependency should be "ml-api-inference.so depends on ml-api-inference-single.so & ml-api-inference-pipeline.so" and "ml-api-inference-*.so does NOT depend on the other two".

If we have ml-api-inference-single.so and ml-api-inference-pipeline.so, what does ml-api-inference.so do? What's the dependency relation between the three?
For the purpose of ml-api-inference-single.so (minimal dependency) and the backward compatibility, you might need to make ml-api-inference.so as a dummy .so (w/o actual contents in it) with dependency information only. And the dependency should be "ml-api-inference.so depends on ml-api-inference-single.so & ml-api-inference-pipeline.so" and "ml-api-inference-*.so does NOT depend on the other two".

Right. As you mentioned, capi-nnstreamer.so is dummy .so link with capi-nnstreamer-single.so and capi-nnstreamer-pipeline.so for backward compatibility.

:octocat: cibot: @gichan-jang, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnstreamer.mooo.com/nnstreamer-api/ci/repo-workers/pr-checker/133-202202071651550.8371639251709-bcd02de9c3eaf165194d707790a384b47dc7da63/.

$ ldd libcapi-ml-inference-single.so
	linux-vdso.so.1 (0x00007ffe395fa000)
	libcapi-ml-common.so.1 (0x00007fb37f954000)
	libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fb37f804000)
	libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fb37f7fe000)
	libnnstreamer-single.so (0x00007fb37f7de000)
	libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fb37f77e000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb37f75b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb37f567000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb37f4f4000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb37f4ee000)
	libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007fb37f4e2000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb37f971000)


Fixes #4037. IN operator contains space and \n \t \r

Fixes #4037.
Changes proposed in this pull request:

parse the IN operator bracket's index for encrypt rewirte
fixes encrypt statement IN operator  contains space and \n \t \r

Can you submit a pull request to master as well?

Can you submit a pull request to master as well?

I have fixed it by this PR https://github.com/apache/incubator-shardingsphere/pull/4193

Codecov Report

:exclamation: No coverage uploaded for pull request base (4.0.1@c82eb0a). Click here to learn what that means.
The diff coverage is 8.33%.

@@           Coverage Diff            @@
##             4.0.1    #4193   +/-   ##
========================================
  Coverage         ?   63.33%
  Complexity       ?      876
========================================
  Files            ?     1057
  Lines            ?    17001
  Branches         ?     2739
========================================
  Hits             ?    10767
  Misses           ?     5631
  Partials         ?      603

Impacted Files
Coverage Δ
Complexity Δ

...ardingsphere/sql/parser/core/constant/Bracket.java
0% <0%> (ø)
0 <0> (?)

...dml/predicate/value/PredicateLeftBracketValue.java
0% <0%> (ø)
0 <0> (?)

...ent/dml/predicate/value/PredicateInRightValue.java
0% <0%> (ø)
0 <0> (?)

...ent/dml/predicate/value/PredicateBracketValue.java
0% <0%> (ø)
0 <0> (?)

...ml/predicate/value/PredicateRightBracketValue.java
0% <0%> (ø)
0 <0> (?)

...er/core/extractor/impl/dml/PredicateExtractor.java
2.25% <0%> (ø)
0 <0> (?)

...impl/EncryptPredicateRightValueTokenGenerator.java
92.85% <100%> (ø)
2 <0> (?)

...sphere/encrypt/rewrite/EncryptConditionEngine.java
61.22% <66.66%> (ø)
1 <0> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c82eb0a...d380b78. Read the comment docs.


[Feature] Support cluster manage statements in new RBAC privilege framework

What type of PR is this：

[ ] BugFix
[x] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #13107
Problem Summary(Required) ：

PrivilegeCheckerV2 support cluster manage statements

show backends, show frontends, show broker statements.
show tablet, show transaction.

Support upgrading the privilege of system.
Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[FE PR Coverage Check]
:heart_eyes: pass : 8 / 9 (88.89%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/PrivilegeCheckerV2.java
6
7
85.71%
[220]

:large_blue_circle:
com/starrocks/privilege/PrivilegeType.java
2
2
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 11 / 14 (78.57%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/PrivilegeCheckerV2.java
9
12
75.00%
[222, 231, 243]

:large_blue_circle:
com/starrocks/privilege/PrivilegeType.java
2
2
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 28 / 31 (90.32%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/PrivilegeCheckerV2.java
17
20
85.00%
[230, 239, 294]

:large_blue_circle:
com/starrocks/mysql/privilege/AuthUpgrader.java
9
9
100.00%
[]

:large_blue_circle:
com/starrocks/privilege/PrivilegeType.java
2
2
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 19 / 22 (86.36%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/PrivilegeCheckerV2.java
17
20
85.00%
[230, 239, 294]

:large_blue_circle:
com/starrocks/privilege/PrivilegeType.java
2
2
100.00%
[]

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 55 / 70 (78.57%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/StmtExecutor.java
0
4
00.00%
[670, 673, 674, 676]

:large_blue_circle:
com/starrocks/catalog/ResourceMgr.java
4
5
80.00%
[308]

:large_blue_circle:
com/starrocks/sql/analyzer/PrivilegeCheckerV2.java
49
59
83.05%
[155, 161, 356, 596, 689, 690, 694, 699, 700, 702]

:large_blue_circle:
com/starrocks/privilege/PrivilegeType.java
2
2
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 60 / 77 (77.92%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/StmtExecutor.java
0
4
00.00%
[670, 673, 674, 676]

:large_blue_circle:
com/starrocks/sql/ast/SetPassVar.java
2
3
66.67%
[76]

:large_blue_circle:
com/starrocks/sql/ast/SetVar.java
3
4
75.00%
[98]

:large_blue_circle:
com/starrocks/catalog/ResourceMgr.java
4
5
80.00%
[308]

:large_blue_circle:
com/starrocks/sql/analyzer/PrivilegeCheckerV2.java
49
59
83.05%
[155, 161, 356, 596, 689, 690, 694, 699, 700, 702]

:large_blue_circle:
com/starrocks/privilege/PrivilegeType.java
2
2
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 60 / 77 (77.92%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/StmtExecutor.java
0
4
00.00%
[670, 673, 674, 676]

:large_blue_circle:
com/starrocks/sql/ast/SetPassVar.java
2
3
66.67%
[76]

:large_blue_circle:
com/starrocks/sql/ast/SetVar.java
3
4
75.00%
[98]

:large_blue_circle:
com/starrocks/catalog/ResourceMgr.java
4
5
80.00%
[308]

:large_blue_circle:
com/starrocks/sql/analyzer/PrivilegeCheckerV2.java
49
59
83.05%
[155, 161, 356, 596, 689, 690, 694, 699, 700, 702]

:large_blue_circle:
com/starrocks/privilege/PrivilegeType.java
2
2
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test


feat: improve next.js experience

https://github.com/tolgee/tolgee-js/issues/3334

I have to confess that I don't know what's all about, but I approve it.