BUG: Iteration count in scipy.sparse.linalg._eigen.arpack greater than maxiters

Describe your issue.
I'm trying to get a number of iterations needed until convergence for finding the k smallest eigenvalues of a matrix. While scipy can find the eigenvalues without much difficulty, there's no way that I see to easily get out the number of iterations needed. In the code block as shown, my thought was that the addition of the counter in variable i would be a quick fix, but I believe I have run into a bug as i can be greater than maxiters, which shouldn't be right.
Am I misreading something?
Reproducing Code Example
import scipy.sparse.linalg._eigen.arpack as bark
import numpy as np
#%%
def ct(v):
    return np.conj(v.T)

def eigsb(A, k=6, M=None, sigma=None, which='LM', v0=None,
         ncv=None, maxiter=None, tol=0, return_eigenvectors=True,
         Minv=None, OPinv=None, OPpart=None):
        n = A.shape[0]
        mode = 1
        M_matvec = None
        Minv_matvec = None
        matvec = bark._aslinearoperator_with_dtype(A).matvec
        params = bark._UnsymmetricArpackParams(n, k, A.dtype.char, matvec, mode,
                                      M_matvec, Minv_matvec, sigma,
                                      ncv, v0, maxiter, which, tol)

        i=0
        while not params.converged:
            params.iterate()
            i=i+1
        return i,params.extract(return_eigenvectors)

###Make Herimtian Matrix
d = 50
mat = np.random.rand(d,d)+ 1j * (np.random.rand(d,d))
mat = mat - (np.random.rand(d,d)+ 1j * (np.random.rand(d,d)))
mat = mat + ct(mat)

i, (vals, vecs) = eigsb(mat, k=1, which='SR', ncv=6, maxiter=50)

Error message
N/A

SciPy/NumPy/Python version and system information
import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info); scipy.show_config()
1.9.3 1.23.5 sys.version_info(major=3, minor=10, micro=8, releaselevel='final', serial=0)
lapack_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
  NOT AVAILABLE
openblas_clapack_info:
  NOT AVAILABLE
flame_info:
  NOT AVAILABLE
accelerate_info:
  NOT AVAILABLE
atlas_3_10_threads_info:
  NOT AVAILABLE
atlas_3_10_info:
  NOT AVAILABLE
atlas_threads_info:
  NOT AVAILABLE
atlas_info:
  NOT AVAILABLE
lapack_info:
    libraries = ['lapack', 'blas', 'lapack', 'blas']
    library_dirs = ['/Users/andrewprojansky/opt/anaconda3/envs/spyder-env/lib']
    language = f77
blas_mkl_info:
  NOT AVAILABLE
blis_info:
  NOT AVAILABLE
openblas_info:
  NOT AVAILABLE
atlas_3_10_blas_threads_info:
  NOT AVAILABLE
atlas_3_10_blas_info:
  NOT AVAILABLE
atlas_blas_threads_info:
  NOT AVAILABLE
atlas_blas_info:
  NOT AVAILABLE
blas_info:
    libraries = ['cblas', 'blas', 'cblas', 'blas']
    library_dirs = ['/Users/andrewprojansky/opt/anaconda3/envs/spyder-env/lib']
    include_dirs = ['/Users/andrewprojansky/opt/anaconda3/envs/spyder-env/include']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
blas_opt_info:
    define_macros = [('NO_ATLAS_INFO', 1), ('HAVE_CBLAS', None)]
    libraries = ['cblas', 'blas', 'cblas', 'blas']
    library_dirs = ['/Users/andrewprojansky/opt/anaconda3/envs/spyder-env/lib']
    include_dirs = ['/Users/andrewprojansky/opt/anaconda3/envs/spyder-env/include']
    language = c
lapack_opt_info:
    libraries = ['lapack', 'blas', 'lapack', 'blas', 'cblas', 'blas', 'cblas', 'blas']
    library_dirs = ['/Users/andrewprojansky/opt/anaconda3/envs/spyder-env/lib']
    language = c
    define_macros = [('NO_ATLAS_INFO', 1), ('HAVE_CBLAS', None)]
    include_dirs = ['/Users/andrewprojansky/opt/anaconda3/envs/spyder-env/include']
Supported SIMD extensions in this NumPy install:
    baseline = SSE,SSE2,SSE3
    found = SSSE3,SSE41,POPCNT,SSE42
    not found = AVX,F16C,FMA3,AVX2,AVX512F,AVX512CD,AVX512_KNL,AVX512_SKX,AVX512_CLX,AVX512_CNL,AVX512_ICL

To fix this issue, you should change the while loop condition to check for convergence.
you can try increasing the number of iterations maxiter and/or increasing the number of Arnoldi vectors ncv. Additionally, you can also try changing the which parameter to a different value such as 'LM' or 'LA'.
import scipy.sparse.linalg._eigen.arpack as bark
import numpy as np

def ct(v):
    return np.conj(v.T)

def eigsb(A, k=6, M=None, sigma=None, which='LM', v0=None,
         ncv=None, maxiter=None, tol=0, return_eigenvectors=True,
         Minv=None, OPinv=None, OPpart=None):
    n = A.shape[0]
    mode = 1
    M_matvec = None
    Minv_matvec = None
    matvec = bark._aslinearoperator_with_dtype(A).matvec
    params = bark._UnsymmetricArpackParams(n, k, A.dtype.char, matvec, mode,
                                      M_matvec, Minv_matvec, sigma,
                                      ncv, v0, maxiter, which, tol)

    i = 0
    while not params.converged and i < maxiter:
        params.iterate()
        i += 1
    return i, params.extract(return_eigenvectors)

###Make Herimtian Matrix
d = 50
mat = np.random.rand(d,d)+ 1j * (np.random.rand(d,d))
mat = mat - (np.random.rand(d,d)+ 1j * (np.random.rand(d,d)))
mat = mat + ct(mat)

i, (vals, vecs) = eigsb(mat, k=1, which='LM', ncv=20, maxiter=100)
print("Number of iterations:", i)
print("Eigenvalues:", vals)

OUTPUT
Number of iterations: 61
Eigenvalues: [10.84675179+8.23738226e-17j]


Make use of mvn for OpenJCEPlus test execution

This update allows for the test infrastructure to make use of mvn directly for testing OpenJCEPlus. This allows for mvn to control dependency usage along with using the same test infrastructure and plugins in use within the open source project.
Signed-off-by: Jason Katonica<EMAIL_ADDRESS>

This update is dependent upon https://github.com/adoptium/TKG/pull/591

Did we test this on Windows? If so, could you provide the Grinder link? Thanks

Hi @llxia I did need to make an update using https://github.com/adoptium/aqa-tests/pull/5479/commits/929b0e4f04855621f0bcd6cf8ddd60cd8c6faf6d to get this to work on windows. The code now uses fully qualified paths to mvn and to the pom.xml file in order to work. Setting the path to mvn on windows had some issues. I ran this on the various platforms using the following grinder jobs with this new code:

Windows
https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/42859/
ppcle linux
https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/42860/
s390x linux
https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/42864/
AIX
https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/42862/
x86 linux
https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/42863/


[Communication - Identity] CommunicationIdentityClient [Playback/Live] [AAD] successfully revokes tokens issued for a user failing in nightly runs

Communication - Identity nightly test runs are failing with:

Error message:
Internal server error.
Stack trace:
RestError: Internal server error.
at handleErrorResponse (/mnt/vss/_work/1/s/sdk/core/core-http/src/policies/deserializationPolicy.ts:274:17)
at /mnt/vss/_work/1/s/sdk/core/core-http/src/policies/deserializationPolicy.ts:179:47
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at IdentityRestClient.sendOperationRequest (/mnt/vss/_work/1/s/sdk/core/core-http/src/serviceClient.ts:521:23)
at CommunicationIdentityClient.revokeTokens (/mnt/vss/_work/1/s/sdk/communication/communication-identity/src/communicationIdentityClient.ts:155:7)
at Context. (/mnt/vss/_work/1/s/sdk/communication/communication-identity/test/public/communicationIdentityClient.spec.ts:71:7)

For more details check here:

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1266362&view=results
https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1268913&view=results

no changes were done to the SDK code prior to these failures + the service returns correct status codes. there must have been some intermittent problem with the core library. the builds are succeeding now.


[Enhancement]: 'Whack a Mole' Game Boxes Design Enhancement

Is your enhancement request related to a problem? Please describe.➕
No. It's an enhancement in the existing design.
Describe the solution you'd like
Working on the styling of the boxes.
Current Design

Expected Updated Design

Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @iamRabia-N !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Assign me this issue

@gurjeetsinghvirdee Kindly closed this issue as done so that I can rise next issue.

Hey @iamRabia-N ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


error with url launcher for send email

Hello, I have problem only on iOS simulator to send email with url launcher.
It's works with android but not for iOS simulator.
I tried this simple example

  String<EMAIL_ADDRESS>  _launchEmail() async {
    if (await canLaunch("mailto:$email")) {
      await launch("mailto:$email");
    } else {
      throw 'Could not launch';
    }
  }

  @override
  Widget build(BuildContext context) {

    return MaterialApp(
      theme: ThemeData(primaryColor: Colors.red),
      home: Scaffold(
        appBar: AppBar(
          title: Text('test mail'),
          actions: <Widget>[
            IconButton(
              onPressed: _launchEmail,
              icon: Icon(Icons.send),
            )
          ],
        ),
      ),
    );
  }

I have this issue

[VERBOSE-2:ui_dart_state.cc(148)] Unhandled Exception: MissingPluginException(No implementation found for method canLaunch on channel plugins.flutter.io/url_launcher)
#0      MethodChannel.invokeMethod (package:flutter/src/services/platform_channel.dart:314:7)
<asynchronous suspension>
#1      canLaunch (package:url_launcher/url_launcher.dart:112:25)
<asynchronous suspension>
#2      _MyAppState._launchEmail (package:testmail/main.dart:20:15)
<asynchronous suspension>
#3      _InkResponseState._handleTap (package:flutter/src/material/ink_well.dart:654:14)
#4      _InkResponseState.build.<anonymous closure> (package:flutter/src/material/ink_well.dart:729:32)
#5      GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:182:24)
#6      TapGestureRecognizer._checkUp (package:flutter/src/gestures/tap.dart:365:11)
#7      TapGestureRecognizer.handlePrimaryPointer (package:flutter/src/gestures/tap.dart:275:7)
#8      PrimaryPointerGestureRecognizer.handleEvent (package:flutter/src/<…>

There is no Email App installed on the iOS Simulator you only can test this on a real device. Could you try on a real iPhone?
Although I have to admit the exception seems to signal another problem.

Thank you. no device to test, but this answer save my times :)
Le mer. 18 sept. 2019 à 18:30, escamoteur<EMAIL_ADDRESS>a
écrit :

There is no Email App installed on the iOS Simulator you only can test
this on a real device. Could you try on a real iPhone?
Although I have to admit the exception seems to signal another problem.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/40756?email_source=notifications&email_token=AGSYLSYSRJSG2HJ3OOB2UVDQKJJRTA5CNFSM4IX7KICKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7AU6GI#issuecomment-532762393,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGSYLS5I7CREUUYIUCCN4TTQKJJRTANCNFSM4IX7KICA
.

Hi @nitneuq33
Are you still experiencing this issue?
Thank you

It’s ok 👌
Le mer. 26 févr. 2020 à 11:14, Taha Tesser<EMAIL_ADDRESS>a
écrit :

Hi @nitneuq33 https://github.com/nitneuq33
Are you still experiencing this issue?
Thank you
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/40756?email_source=notifications&email_token=AGSYLS2QXAVLIR3DTDPXGRDREY6HJA5CNFSM4IX7KICKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM7UAJA#issuecomment-591347748,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGSYLS7HICJ3ATO3IUWNM2LREY6HJANCNFSM4IX7KICA
.

Hey @nitneuq33
given your last message I feel safe to close this issue,
if you disagree please write in the comments and I will reopen it.
Thank you


Document prefill

Hello!
I use the latest 1.6 version of library.
I create envelope by template and define TemplateRole for each recipient.  My question: Is there any way to set in code some of tab values for recipient?

@karpenberg I think I didn't get this question before. Usually, when using templates the tabs are already defined by the template. I guess you want to add/change tabs using the API after the fact, right?
I'll need to play with it and see, I don't know off hand. Logically this should be supported unless the template restricts it. Did you try it and get some error? I can look into it later in the day and get back to you.

Thank you for feedback!
"I guess you want to add/change tabs using the API after the fact, right?"
I want to set value for one of tab and this value I get from my system for each recipient (each value for each recipient). As a result this value should be default value for field on document.
"Did you try it and get some error?"
I was playing with TemplateRole tabs field but there was no any effect.

I figured out what the problem was.
I set value to text tab but this tab is type "Company" in template.
Sorry for inconvenience

no trouble at all. I'm glad you got it working and I hope maybe future people reading this would find it useful for them. If you have any other questions - feel free to post here.


Solutions and gradients of convex quadratic

Just a nitpicking detail. The formulas for the solution and gradient of the convex quadratic aren't quite right. The solution given is only true if, in addition to the quadratic being convex, the matrix A is also symmetric. The symmetry assumption isn't stated up to this point. Without it, the solution to that quadratic is actually w^* = 1/2(A + A^T)^{-1}b.
And, without symmetry, the gradient of the quadratic is 1/2(A + A^T)w - b.
I think just stating that the formulas only hold if A is symmetric would be sufficient.

This is true, I do think this i is worth dotting. Will change this, thanks!


Add unistd::close_range()

What does this PR do
This adds close_range(2) on Linux which allows efficiently closing (or marking "close on exec") many file descriptors at once without needing procfs.
I have added comments, but am unsure if new tests are warranted.  I have manually tested and used test programs and strace to validate that it is working as intended (both with and without various CLOSE_RANGE_* flag permutations.
Checklist:

[X] I have read CONTRIBUTING.md
[ ] I have written necessary tests and rustdoc comments
[X] A change log has been added if this PR modifies nix's API

Thanks for your contribution to nix!
I have left some comments :)

but am unsure if new tests are warranted

It would be great to test if this binding is properly working, we can test it with a single file descriptor with both first and last set to it

BTW, the CI failure is because an unsafe function needs a # Safety section, it can be added right above this doc:
/// Be aware that many Rust types implicitly close-on-drop, including
/// `std::fs::File`.  Explicitly closing them with this method too can result in
/// a double-close condition, which can cause confusing `EBADF` errors in
/// seemingly unrelated code.  Caveat programmer.

At this point it looks like I'd need to push the same syscall code down into libc and the resulting wrapper up here would still be (appropriately) unsafe.
This would leave very little benefit for my case for having the code in nix/libc and so I believe I'll just call syscall from my code and avoid another round of pull requests across the two crates.
Thank you both for taking the time to review this pull request, it was very pleasant to work with you for a moment and interact with the project.

Allright, @cpick .  I'll close this PR for now.  Feel free to reopen if you ever change your mind.


Add custom output path in show-dependencies

Add support for custom output path for the show-dependencies command
Motivation:
The command show-dependencies by default loads the missing packages and prints to the stdout the logging of download activities. The default output for the show-dependencies command is also stdout. This does not allow on automatic processing of the output, to separate the dependencies output from the log of loading the packages.
Modifications:
Added a new option to the show-dependencies command that allows to redirect the dependencies output to a separate file.
The changes only affect the show dependencies command setup, once the output stream of the dependencies was already customisable through an optional parameter.
Result:
No existing behaviour will be affected. There will be a new optional argument (-o | --output-path) on the show-dependencies command which will allow to send the dependencies graph output to a local file.

thanks for the PR @ismaelvb stdout can be fairly easily redirected to a file with swift package show-dependencies > <path> for example. is that not good enough for the use case you have in mind?

thanks for the PR @ismaelvb stdout can be fairly easily redirected to a file with swift package show-dependencies > <path> for example. is that not good enough for the use case you have in mind?

It is enough when the dependencies are already downloaded, but on the first attempt like when it is done right after the clone,  calling the to show-dependencies prints also log entries from the fetching to stdout which then are also redirected.
Example below of current latest on main:

% swift package show-dependencies
Fetching https://github.com/apple/swift-llbuild.git from cache
Fetching https://github.com/apple/swift-tools-support-core.git from cache
Fetching https://github.com/apple/swift-driver.git from cache
Fetching https://github.com/apple/swift-argument-parser.git from cache
Fetching https://github.com/apple/swift-crypto.git from cache
Fetching https://github.com/jpsim/Yams.git from cache
Cloning https://github.com/apple/swift-crypto.git
Resolving https://github.com/apple/swift-crypto.git at 1.1.6
Cloning https://github.com/apple/swift-tools-support-core.git
Resolving https://github.com/apple/swift-tools-support-core.git at main
Cloning https://github.com/apple/swift-argument-parser.git
Resolving https://github.com/apple/swift-argument-parser.git at 0.4.3
Cloning https://github.com/jpsim/Yams.git
Resolving https://github.com/jpsim/Yams.git at 4.0.6
Cloning https://github.com/apple/swift-llbuild.git
Resolving https://github.com/apple/swift-llbuild.git at main
Cloning https://github.com/apple/swift-driver.git
Resolving https://github.com/apple/swift-driver.git at main
.
├── llbuildhttps://github.com/apple/swift-llbuild.git@unspecified
├── swift-tools-support-corehttps://github.com/apple/swift-tools-support-core.git@unspecified
├──<EMAIL_ADDRESS>├── swift-driverhttps://github.com/apple/swift-driver.git@unspecified
│   ├── llbuildhttps://github.com/apple/swift-llbuild.git@unspecified
│   ├── swift-tools-support-corehttps://github.com/apple/swift-tools-support-core.git@unspecified
│   ├──<EMAIL_ADDRESS>│   └── swift-argument-parser<https://github.com/apple/swift-argum

Where the graph load fetch logs are also redirected to the log.

I see. @neonichu @abertelrud wdyt?

@abertelrud @neonichu @elsh wdyt?

This does make sense to me, especially when combined with the option to dump .json files or GraphViz .dot files, which are most useful when emitted to separate files.

It might be good to add a unit test here to check that the right file gets created and stdout doesn't contain the output that now goes into the file, just to make sure this doesn't break in the future.

+1 to add a test, see "testShowDependencies" for example you can use to "seed" such test

Thanks for the PR, @ismaelvb.
I think, separately, we should also think about making sure that informational output and logging generally goes to stderr and not to stdout, as making redirects work properly is the main reason for why stderr exists at all.

@abertelrud, @eish: Unit test added.
I added the json context to the UT and also checked the correct output with one dependent package.
Used "seed" context from testSymlinkedDependency.
@neonichu, I agree, although the --output-path option is also useful in some contexts.

@swift-ci please smoke test

@ismaelvb Yep, agreed. I think both are useful, the option and also the pursuit to make redirection of stdout work as expected.

thanks @ismaelvb


dump: change dump service to non template version

upstream commit link
https://gerrit.openbmc.org/c/openbmc/openpower-debug-collector/+/42328
Tested:
root@p10bmc:~# systemctl status org.open_power.Dump.Manager.service

org.open_power.Dump.Manager.service - OpenPOWER Dump Manager Host Loaded: loaded (/lib/systemd/system/org.open_power.Dump.Manager.service; enabled; preset: enabled)
Active: active (running) since Thu 2023-02-23 07:38:42 UTC; 26s ago
Main PID: 997 (openpower-dump-)
CGroup: /system.slice/org.open_power.Dump.Manager.service
`-997 /usr/bin/openpower-dump-manager

Feb 23 07:38:42 p10bmc systemd[1]: Starting OpenPOWER Dump Manager Host...
Feb 23 07:38:42 p10bmc systemd[1]: Started OpenPOWER Dump Manager Host.
Change-Id: I13e4b18ce23746b882598a5f0d93faa108b4761f

Can one of the admins verify this patch?


Startup Manger Fix [Client]

Changed CurrentUser to LocalMachine
As these values located in LocalMachine NOT CurrentUser

Ops, my fault. :D

no problem you have attentive soldiers hehehe :laughing:


Fix version numbers

The version numbers refer to akka, not pekko versions, making the examples not compile.

merged - thanks

https://github.com/apache/pekko-management/issues/28 covers why the marathon test is not being built in CI - I presume the mesos one has a similar backstory.


Add function signatures into tasks

For all tasks, add function signatures to help users how they should define these functions. There are two possible ways to solve this issue:

add the signatures to tasks descriptions directly
use hints sections to provide students the ability to see the signatures by clicks

Fixed in the course update


POST org_root_domains() Convert to API Endpoint

💡 Summary
Replace the existing TSQL function with a new REST endpoint that does the same thing
Specifically: Convert "org_root_domains()" TSQL query to an API endpoint
Motivation and context
There are two major reasons to use endpoints in place of sql queries.

Replace the need to know t-sql
Off load data aggregation to fastapi parallel workers

Implementation notes

Gather existing queries from code.
Create new endpoints at fastapi.
Secure new endpoints in same fashion as existing endpoint.

Acceptance criteria

[X] home/models.py model created
[X] dataAPI/schemas.py schema created
[X] dataAPI/views.py functions created
[X] dataAPI/tasks.py function created (if applicable)
[ ] Verified endpoint is working
[ ] pushed to api extended/staging branch

Closing s all endpoint testing has moved to this https://github.com/cisagov/pe-reports/issues/705.


Update index.htm

adding my interest to join

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Create logging-to-filesystem system

Create a function which can log strings to log files
Rotate log files, deleting old ones, and avoiding files getting to large

Logs should include:

Timestamp
System uptime
Message
Log level, maybe

For now, just consider each log a string. Future consideration: we may want to store certain common logs as structs (maybe even CBOR) to optimize storage space.

We should take a look at uLog: https://github.com/rdpoor/ulog
It's very light-weight, minimal dependencies, and it's intended for embedded systems. Supports creating our own custom log adapter, and could be used to change the verbosities of various different logs.
The biggest benefit above rolling our own logger imo is that it supports printf-style arguments, so we don't need to write to a temporary CString array before calling the logger

We should take a look at uLog: https://github.com/rdpoor/ulog
It's very light-weight, minimal dependencies, and it's intended for embedded systems. Supports creating our own custom log adapter, and could be used to change the verbosities of various different logs.
The biggest benefit above rolling our own logger imo is that it supports printf-style arguments, so we don't need to write to a temporary CString array before calling the logger

Drafted something based on uLog on this branch. Not issuing a pull request pending a decision about uLog, and implementing log rotation.
uLog unfortunately breaks some of the NASA coding guidelines, such as using elaborate macros, and using function pointers. It does look promising otherwise, and we can adapt it to FrontierSat needs. Both macros and function pointers could be replaced if warranted.
Maybe have dedicated log files like syslog, say in /logs/obc.log, '/logs/gpc.log', /logs/camera.log, etc.

Hmm I saw a few different logging options. An informal trade study looking at a few options might be waranted. Thanks for looking into the uLog internals!
I think the main benefit of these logging options is mostly just getting the printf-like syntax for forming strings from variables. If they're way more complicated than just making our own system and using temporary buffers, that might just be better.

Just edited the initial comment with a description of the places the log messages should go!

I reviewed the entirety of the code, and had these thoughts:

The use of function pointers/macros appear rather standard and easy-to-reason-about.  If we choose to in the future, it would be easy to replace the function pointer part with basic sequential function calls (although modifying library code may be a worse idea).
The only elaborate macros I see are of the style: #define ULOG_INFO(...) ulog_message(ULOG_INFO_LEVEL, __VA_ARGS__), which I believe is reasonably standard. We could also just remove those macros and use calls to ulog_message(...) directly with the log level enum, if we really wanted to avoid macros.
I really like that the ulog_message(log_level, printf-like_format_string) function writes to an intermediate cstring allocated in the data segment statically (instead of allocating on the stack, as we currently generally do for log messages). This increases the simplicity of performing logging, and allows us to remove the bulk of the variable-length arrays (VLAs) in the code currently.
Overall, uLog seems to be quite straight-forward code (not many lines, easy to follow). Logging isn't hard, so I'm glad this library gives a nice foundation without too much complexity.

After reviewing the uLog code, I am in favor of continuing implementation with this library.

Okay, will prepare a PR.
Question about arguments: in littlefs_helper.c, for example:
int8_t LFS_read_file(const char file_name[], uint8_t *read_buffer, uint32_t read_buffer_len)

I'm wondering about the rationale for using [] for the file_name and leaving read_buffer as a pointer, instead of like this:
int8_t LFS_read_file(const char file_name[], uint8_t read_buffer[])

The function could then use  uint32_t read_buffer_len = sizeof(read_buffer);

Thanks for the PR! Taking a look now.
Regarding the question about the array args/sizeof, neither syntax "communicates"/passes the size of the array into the called function. Here's a demo I wrote in an online C compiler to demonstrate: https://onlinegdb.com/VnRut6wmu. You'll see that, when executed, both ways yield sizeof(arg)=8 bytes (suggesting the server is a 64-bit computer).
Interestingly though, sizeof(cstring_arg_with_array_syntax) throws a compiler warning, while sizeof(cstring_arg_with_pointer_syntax) returns the sizeof silently. Using the "array syntax" is a good way to ensure the compiler warns in that case, and is a positive change!
The two options are mostly a matter of style, and are equivalent within the compiler (as far as I know). I generally prefer to use the array-style to communicate that it's an array, unless it's a pointer. No consistency has been enforced, and I frequently forget that personal prefence of mine as I write code, hence the random switching.
I support the change you made in the PR switching to the array-style syntax.

Thanks for the info!


fix: add missing resource to clusterrole.yaml

With kubeletMetrics enabled I get
2024-03-08T11:50:01.933Z        error   kubeletstatsreceiver@v0.95.0/scraper.go:86      call to /pods endpoint failed   {"kind": "receiver", "name": "kubeletstats", "data_type": "metrics", "error": "kubelet request GET https://<IP_ADDRESS>:10250/pods failed - \"403 Forbidden\", response: \"Forbidden (user=system:serviceaccount:opentelemetry-collector:opentelemetry-collector, verb=get, resource=nodes, subresource=proxy)\""}
github.com/open-telemetry/opentelemetry-collector-contrib/receiver/kubeletstatsreceiver.(*kubletScraper).scrape
        github.com/open-telemetry/opentelemetry-collector-contrib/receiver/kubeletstatsreceiver@v0.95.0/scraper.go:86
go.opentelemetry.io/collector/receiver/scraperhelper.ScrapeFunc.Scrape
        go.opentelemetry.io/collector/receiver@v0.95.0/scraperhelper/scraper.go:20
go.opentelemetry.io/collector/receiver/scraperhelper.(*controller).scrapeMetricsAndReport
        go.opentelemetry.io/collector/receiver@v0.95.0/scraperhelper/scrapercontroller.go:197
go.opentelemetry.io/collector/receiver/scraperhelper.(*controller).startScraping.func1
        go.opentelemetry.io/collector/receiver@v0.95.0/scraperhelper/scrapercontroller.go:176

Unless I also add nodes/proxy to the clusterrole

@afreakk Thanks for your contribution. Can you rebase, bump the chart version and run make generate-examples CHARTS=opentelemetry-collector in order to have CI pass?


SKDBGroup API for JS client

And some related fixes/changes.
The new SKDBGroup abstraction should be self-explanatory, but I would appreciate eyes in particular on the fifth commit here -- it's a small change, but that fixes the bug I was chasing for the last week or two.

I'll take a close look at the context usage.

Ok, I took a look at the code and I think I understand what's happening.
write-csv is called from here: https://github.com/SkipLabs/skdb/blob/main/sql/src/Main.sk#L708
We run in a loop. Essentially: grab the context, read all the input, build the rows, and then return a function that is applied under lock that actually updates stuff with the rows we built.
The problem is the 'read all the input'. Once we enter the loop, we have the latest context, and then immediately block waiting on input. Which may arrive any time or never. But we don't update the context once we receive input.
This make sense?
So, I think we need to fix this rather than go with the solution you propose. For a few reasons:

Your solution will grab the latest context on each row check. This might be expensive. Not sure. But it will definitely allow privacy to change mid way through applying a transaction, so we can end up applying a partial transaction.
We hack a fix here, but it's an edge just waiting to trip someone up again.

I think a fix should be fairly straightforward but will probably require not using the looping abstraction runSql. We'd need to buffer a line, then begin the loop which uses this and then consumes the rest of the stream.
Or -- less ideal but should cover things -- we could rename the context passed in to replayDiff to make it clear it's potentially old. Then we could do a privacy check filter pass on all the rows after they've been accumulated but before we buildDiffChain. This would work with the latest context which only needs to be grabbed once.
WDYT? These were just the first couple of ideas that came to mind, open to others.

(I'll look over the rest of this btw, but first concentrated on write-csv.)

WDYT? These were just the first couple of ideas that came to mind, open to others.

Ahh, I see what you mean!  Was wondering what the runtime cost of grabbing the global context would be -- I don't think it's quite as bad as you say here (per-table, not per-row) but I agree on the reasoning that updating the context properly in execWriteCsv is a better solution going forward.

I don't think it's quite as bad as you say here (per-table, not per-row)

parseTableChange is called for every row being updated, one line at a time. Within that we call compute insert which can return multiple rows for the change (but I don't think it ever does?) so there's a loop here too. Between the function name and the loop within, not surprised there's confusion here. :D

Okay, this should be ready for review now.
I played around with a few options and ended up both blocking on the first line before grabbing a context and taking the freshest privacy context possible to check an entire transaction at once.
Just blocking on the first line does help but is insufficient to ensure that you have the latest privacy context.  The withContext in replayDiff does that, and allows to simplify some logic in the diff-parsing state machine there.

(Looking at this today, haven't forgotten.)

Looks great!


not compatible with php 8.0

The latest xampp uses php 8.0
Xerte does not work with php 8.0 yet.

@torinfo I was curious about this so tested a new install with the latest xampp and PHP 8. I haven't tested extensively but in terms of the install routine I first got the following error:
Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in page4.php:28 Stack trace: #0 {main} thrown in page4.php on line 28.
If I comment that out there are 3 more errors re $magic_quotes but the install completes.
Warning: Undefined variable $magic_quotes in I:\xampp\htdocs\xerte39\setup\page4.php on line 106
Warning: Undefined variable $magic_quotes in I:\xampp\htdocs\xerte39\setup\page4.php on line 122
Warning: Undefined variable $magic_quotes in I:\xampp\htdocs\xerte39\setup\page4.php on line 139
I'm able to create end edit Bootstrap and Decision Tree projects but when I create an XOT project the editor window just displays a spinner and doesn't load.
I turned on Xerte debugging but nothing particular useful in the debug.log but I can see errors in the Apache log. So a few questions:
Is PHP 7.4 ok with the latest Xerte code? I've got installs using 7.3 but haven't tried 7.4 yet.
What are the issues with PHP 8?
Are you working through those and do you need any help?
No need to reply we can discuss during the next dev day but as I've just tested thought I would add this here now.

@torinfo I was curious about this so tested a new install with the latest xampp and PHP 8. I haven't tested extensively but in terms of the install routine I first got the following error:
Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc() in page4.php:28 Stack trace: #0 {main} thrown in page4.php on line 28.
If I comment that out there are 3 more errors re $magic_quotes but the install completes.
Warning: Undefined variable $magic_quotes in I:\xampp\htdocs\xerte39\setup\page4.php on line 106
Warning: Undefined variable $magic_quotes in I:\xampp\htdocs\xerte39\setup\page4.php on line 122
Warning: Undefined variable $magic_quotes in I:\xampp\htdocs\xerte39\setup\page4.php on line 139
I'm able to create end edit Bootstrap and Decision Tree projects but when I create an XOT project the editor window just displays a spinner and doesn't load.
I turned on Xerte debugging but nothing particular useful in the debug.log but I can see errors in the Apache log. So a few questions:
Is PHP 7.4 ok with the latest Xerte code? I've got installs using 7.3 but haven't tried 7.4 yet.
What are the issues with PHP 8?
Are you working through those and do you need any help?
No need to reply we can discuss during the next dev day but as I've just tested thought I would add this here now.

@ronm123 Yes 7.4 seems to work fine
And yes you have the same observations as I have. The setup is easy to fix. Have not looked at all yet to the launching of the XOT project editor, but it is probably also easy to fix. I have not looked yet.

@ronm123 Yes 7.4 seems to work fine
And yes you have the same observations as I have. The setup is easy to fix. Have not looked at all yet to the launching of the XOT project editor, but it is probably also easy to fix. I have not looked yet.

@torinfo you may have noticed that after testing this and seeing a clean install again I updated page3.php in setup to change the default pod info for pod 1 and news/other resources pod. Well I tested that with a new install with PHP 8 and noticed that although the workspace showed what I wanted when viewing via management I was getting an error. So I thought perhaps I'd made a syntax error in page3.php. However I tested a clean install using an earlier PHP version and that works fine for both workspace and management. So I checked again with the page3.php that is part of current 3.9 and with PHP 8 I was getting the same error in management:
Fatal error: Uncaught Error: Undefined constant "MANAGEMENT_TUTORIAL_TEXT" in \website_code\php\management\site.php:70 Stack trace: #0 {main} thrown in \website_code\php\management\site.php on line 70
So I'm concluding that the changes I have made and committed are fine and this is just another PHP 8 incompatibility. Again no need to reply just adding details after committing the changes and testing.

@torinfo you may have noticed that after testing this and seeing a clean install again I updated page3.php in setup to change the default pod info for pod 1 and news/other resources pod. Well I tested that with a new install with PHP 8 and noticed that although the workspace showed what I wanted when viewing via management I was getting an error. So I thought perhaps I'd made a syntax error in page3.php. However I tested a clean install using an earlier PHP version and that works fine for both workspace and management. So I checked again with the page3.php that is part of current 3.9 and with PHP 8 I was getting the same error in management:
Fatal error: Uncaught Error: Undefined constant "MANAGEMENT_TUTORIAL_TEXT" in \website_code\php\management\site.php:70 Stack trace: #0 {main} thrown in \website_code\php\management\site.php on line 70
So I'm concluding that the changes I have made and committed are fine and this is just another PHP 8 incompatibility. Again no need to reply just adding details after committing the changes and testing.

This has been fixed (see 5788a93bbe699a8518c278c324bf7bba9c0bc807, 315a74b230dc1c711b8a8a3e90043e30d08c1557 and 07b2830b8149a9e362fc9216856f50f9f6463467)


Simplified module/package structure

When trialling t4c at $work I've had a lot of complaints about the number of different packages and modules that are needed for the core functionality. Here are a few tentative suggestions for reducing barriers to adoption:
modules

combine model into kernel
combine  exporter-common, base and inject into core

packages

move contents of model and inject packages into either the base package or trace and span packages
move contents of kernel package into either the base package or a span package
consider changing the base package from io.janstenpickle.trace4cats to just trace4cats

Any thoughts on this?

@bplommer I'm definitely for this simplification.
We're about to cut a new release soon. Actually I should have done it last week, but still have one PR open. It would be nice to include this change into the new 0.13.0 release.
The only thing that bothers me is how to make the upgrade smooth for the end users. Are you experienced with scalafix so that we could include a fix that can be applied by Scala Steward automagically?

I like the proposal too, with hindsight I went a bit far with the modularisation 😅.
I would like to get thoughts on combining inject and core though. When I first created this project I wanted a separation between the internals (span, completers and exporters) and means of injection. This was so that it could be used with Natchez without having to bring in our inject code and so that the standalone components (agent and collector) would not need to import the inject code either. What is everyone's thoughts here? Maybe keeping inject a separate module, but still making the proposed package changes?

The only thing that bothers me is how to make the upgrade smooth for the end users. Are you experienced with scalafix so that we could include a fix that can be applied by Scala Steward automagically?

I agree with @catostrophe here, I think we'd need to ship some scalafix to apply the package changes, but I don't have any experience using it.
Maybe we should split this into two issues: Module consildation and package naming.

I would like to get thoughts on combining inject and core though. When I first created this project I wanted a separation between the internals (span, completers and exporters) and means of injection. This was so that it could be used with Natchez without having to bring in our inject code and so that the standalone components (agent and collector) would not need to import the inject code either. What is everyone's thoughts here? Maybe keeping inject a separate module, but still making the proposed package changes?

How about chopping up the modules differently - moving the current core into kernel and changing inject to core – that would fit with the pattern of (for example) cats-effect, where kernel has the components typically needed by downstream libraries and core has the components needed for building an app.
Re Natchez - are we talking about incorporating components that use t4c into an app that uses Natchez for end-to-end tracing? Do you have an example of how that works? (I see the trace4cats-natchez module does have a dependency on inject, which I guess is for the more common reverse scenario.)

I agree with @catostrophe here, I think we'd need to ship some scalafix to apply the package changes, but I don't have any experience using it.

I could definitely do that for the packages, though I may not have time for a couple of weeks. It should be possible to do something hacky for the modules, but I’m not sure scala steward can apply scalafixes to build files.

Maybe we should split this into two issues: Module consolidation and package naming.

Sounds good. I made a start with module consolidation (it required creating a new tests module to allow the tests to depend on the test kit) so I’ll open a PR today.

How about chopping up the modules differently - moving the current core into kernel and changing inject to core – that would fit with the pattern of (for example) cats-effect, where kernel has the components typically needed by downstream libraries and core has the components needed for building an app.

This sounds good, I like it! Depending on how we move things around there may also be scope for std library, similar to cats-effect, but happy to stick with kernel and core to start with.

Re Natchez - are we talking about incorporating components that use t4c into an app that uses Natchez for end-to-end tracing? Do you have an example of how that works? (I see the trace4cats-natchez module does have a dependency on inject, which I guess is for the more common reverse scenario.)

The trace4cats-natchez library has a couple of concerns: firstly providing interop between Natchez Trace and t4c Trace, and secondly (to enable this) providing a Natchez Trace implementation using the code in core and kernel, which is just like any of the existing Natchez integrations with Java tracing libraries. This means you could use Natchez in your codebase end-to-end without using t4cinject. Here is the integration code for a Natchez Entrypoint that allows users to work with t4c without using the inject code directly.
The reason inject exists is because it better exposes some of the features in t4c such as lazily evaluated labels, which stops labels from being computed if the span is dropped. When using Natchez they become eagerly evaluated.

but I’m not sure scala steward can apply scalafixes to build files

Ah yes, this could be a problem! Maybe we could still publish certain artifacts with the legacy name where they have been rolled into a library that is below them in the tree and is commonly used by end users (this may just apply to `inject)

I made a start with module consolidation (it required creating a new tests module to allow the tests to depend on the test kit) so I’ll open a PR today.

Amazing, thank you!

Maybe we could still publish certain artifacts with the legacy name where they have been rolled into a library that is below them in the tree and is commonly used by end users (this may just apply to `inject)

That sounds good. We can also leave a trail of deprecated aliases behind.

Hi, sorry for the silence on this - realistically I'm unlikely to move further on this in the next month or two, so you may wish to go ahead with the next release.

No worries @bplommer, we'll proceed with the release as is and target these changes for the next one

@bplommer I'm happy to do some more on this if I get some time in the next few weeks. From what we discussed, I think this was the plan WRT modules:
model, core -> kernel
base, inject, exporter-common ->  (new) core
Let's tackle the package names in a different PR

I think base shouldn't be merged. It's universal and may be used without t4c

Yes, good point. I'll edit the plan above.

I think base shouldn't be merged. It's universal and may be used without t4c

It's basically an optics library and an mtl library tailored for t4c, right? It seems like it should either be split out int general-purpose optics and mtl libraries, or kept as a kind of internal detail of t4c.

It contains only basic lenses needed for t4c. As for mtl part - keeping it as a separate module will prevent us from randomly spoiling it with model leaks.
I don't mind if we move it to a separate lib though.

Maybe now would be a good time to revisit the decision not to include a dependency on tofu-kernel and tofu-optics? We orginially didn't do this because we didn't need all of the functionality from Tofu, but if we're considering a more general purpose repo split out from this one then it's probably worth considering.

Ahh ok, I missed that. I wonder if we should migrate to Tofu once it is compiling against Scala 3? If we decide to do that, it probably means that we should leave base alone.

Maybe the name could be more descriptive though - fp-helpers or something? The current name sounds like it's a foundational part of t4c itself.

Yep, that's a good name. I'd put money on no one depending on it directly at the moment, so safe to rename.

consider changing the base package from io.janstenpickle.trace4cats to just trace4cats
I support this. Maybe we should also consider changing maven org?

Just to be clear, the package renaming should probably happen in a separate PR

@bplommer @catostrophe any thoughts about moving some modules that are currently separate repos back into this one? I thought trace4cats-natchez and trace4cats-http4s might be good candidates. Natchez so that we can maintain compatbility as a first-class consideration and Http4s as it's the most commonly used integration. trace4cats-exporter-http could be a useful one too...

My concern about moving t4c-http4s back in would be supporting different versions. 1.0 won't be out for quite some time but the milestones are beginning to diverge from 0.23 to a degree that people might want to start using it in production soon. How would support for that work in a monorepo?
I think t4c-natchez is a good candidate though.

Could t4c-docs be moved back in?

My concern about moving t4c-http4s back in would be supporting different versions. 1.0 won't be out for quite some time but the milestones are beginning to diverge from 0.23 to a degree that people might want to start using it in production soon. How would support for that work in a monorepo?

Yep good point, it's the same reason we broke out sttp/tapir, let's leave all the http4s bits out

Could t4c-docs be moved back in?

Yep, I think that's a good candidate too

Tracking comment for repo consolidation candidates
trace4cats-natchez
trace4cats-docs

RE some of the module removals, it turns out we can deal with that (to some extent) with ScalaSteward: https://github.com/scala-steward-org/scala-steward/blob/main/docs/artifact-migrations.md. It may result in people ending up with the same artifact imported twice, but I think that's probably OK.

https://github.com/scala-steward-org/scala-steward/blob/main/docs/artifact-migrations.md

Yes, this is a known feature. I would suggest it anyway :)

Tracking comment for repo consolidation candidates:
trace4cats-natchez trace4cats-docs

We have split repos in order to be able to release t4c-natchez when a new version of natchez is out. Back then we though the core repo would be stable and have less releases than integrations.

Could t4c-docs be moved back in?

I don't think so. It has the whole ecosystem as deps.

First of all, which problems are we going to solve by re-assembling repos into one?

The question is, did we go too far separating everything out? If the answer is "no" then I'm happy to leave everything where it is.
I still think Natchez (just to core library) might be a good candidate, just so we can maintain compatability with it. My recent change to Trace would have broken this if I hadn't thought about it ahead of time.

The question is, did we go too far separating everything out? If the answer is "no" then I'm happy to leave everything where it is.
I still think Natchez (just its core library) might be a good candidate, just so we can maintain compatability with it. My recent change to Trace would have broken this if I hadn't thought about it ahead of time.

Any changes in the core may break anything in other repos.
Maybe we should make a pipeline that builds other repos against changes in the core repo?

That's fair. There's two reasons we break out repos that I can think of: 1) we think we may have to support multiple versions of the same dependency. 2) long running integration tests slow down the build/test of this repo.
I'm not sure Natchez fits in either of these reasons, but there is a third softer reason - it's an integration and not an integral part of t4c. If we think that's a good enough reason for keeping it separate then I'm happy to leave it where it is.

Maybe we should make a pipeline that builds other repos against changes in the core repo?

I think that might be good, just as long as it doesn't block the main build as 2) will become a problem again.

This is now released!


@vite-pwa/assets-generator and @vite-pwa/nuxt give error only in production, related to workbox

Hey👋,
for some reason i only get this error in production, seems to be related to the precaching of urls by workbox. I tried many different ways to at least get rid of this error, but nothing. Do you guys have any suggestions? Why is this happening in production and gives no errors in development?
Only by unistalling those dependencies remove the error, but i'm curious of why that happens.
Operating System: Darwin
Node Version: v22.1.0
Nuxt Version: 3.12.2
CLI Version: 3.12.0
Nitro Version: 2.9.7
Package Manager<EMAIL_ADDRESS>Builder: -
User Config: apollo, app, build, css, delayHydration, devtools, experimental, formkit, gtm, i18n, modules, nitro, pwa, runtimeConfig, site, sitemap, sourcemap, ssr, vite
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules: -

Thank You!

you need to prerender / page, workbox requires the html

Hi, i'm not familiar with workbox, and i didn't install it in my project.  Why do i need to prerender the / page? and how do i do that?


[bug][bazel] secure-upload-folder not referenced at main

slsa-framework/slsa-github-generator/.github/actions/secure-upload-folder isn't referenced at main in the internal bazel builder. Is the references check missing this?
https://github.com/slsa-framework/slsa-github-generator/blob/ea62fe80312d00a7185241c8791fa94736be890d/internal/builders/bazel/action.yml#L78

Good catch. This is also true of Java builders, which are not tracked in the reference pre-submits. I'll send a PR


v7 Feedback & Ideas

Hi,
First, I'm trying v7, it's awesome to work with Hooks! Trying it for the first time so my comments might be wrong.
Describe the bug
This are more of an architecture comment than a bug:
If you disable useExpanded hook, the table breaks.
I know in userland you can't disable this hook but the fact that this happens, (edit: actually you can) probably demonstrates wrong app design: I figured out this is happening because you're building initial state within the useExpanded hook (row.cells = ...).
Expected behavior
I think that adding or removing hooks should not break the entire component. Hooks should be encapsulated.
Codesandbox!
https://codesandbox.io/s/nk9rmym6m4
Solution
That initial state logic could be within useTable itself (tested and works fine).
I can provide a PR if needed.

I totally agree. I've done my best so far to make them isolated, but there are still some artifacts like this one you discovered. I'll rework that hook to be more isolated.

Hey,
Sorry to comment here again regarding v7 architecture but I don't know if you guys have an open discussion somewhere about it so I put my thoughts here:
Hook clashes
I think it needs a pattern for hooks clashes: currently the different react-table hooks APIs are mutating the different react-table props to expose the hooks API:
ex:

column.getSortByToggleProps()
column.getGroupByToggleProps()
column.sortedDesc
row.toggleExpanded()
etc.

This approach has different issues:

if you let user add custom hooks, it can quickly lead to clashes between properties name.
if offers poor API discoverability. It gets hard for the user to know what prop is where. You have to read doc etc.

Proposed solution:

prop should be namespaced. A simple solution would be to just use the hook name:
useGroupBy hook -> row|column|header.getGroupByProps()
This way you avoid props clashes.
Also I think everything should be under a get...Props() function instead of directly added to the objects like column.sortedDesc (is there any downside of doing this?).

Let me know if this helps, I would be happy to provide some more contributions if you guys are actually open to discussion!
Thanks!

This is valuable feedback. I'll definitely take it into consideration as I'm flexing the API over the next few weeks.

Some notes while it's on my mind:

I will not be possible to add core hooks to the table system. (They could clearly mutate api.hooks to add their own anyway, but the idea behind the hook system is to have a common layer that multiple hooks can plug into without adding additional API the user has to know about during rendering.
If we're designing a system that will encourage users to request more and more hooks to be added to the core, then we're doing something wrong. Up to this point, I don't think we are, because....
The non-hook, renderer-facing api uses very generic prop getters for different parts of the table which are likely to either not change, or will cover most use-cases.
As for the variables that are directly available on the model (or anything expensively calculated in the table for that matter) like column.sorted or column.sortedDesc are intended. These variables are only computed optimistically and via memoization, so their performance impact is negligible.
The reason for the internal hooks plugin architecture is because data grids actually have 2 main phases of a render:

Setup, change detection, memoization, immutable data transformation, materialization of the final API
Pre-render modifications, inversion of control to the user, pre-rendering logic, anything that requires the final API

More to come.

I will not be possible to add core hooks to the table system. (They could clearly mutate api.hooks to add their own anyway

Why not? For example when I have been experimenting with the v7, I have been adding a useSelectRow hook to add support for select/unselect and batch actions on the table. It's been working just great!
I feel like you miss an opportunity here to provide a "plugin-ready" table where users could add their own feature via hooks.

If we're designing a system that will encourage users to request more and more hooks to be added to the core, then we're doing something wrong. Up to this point, I don't think we are, because....

Yeah that's why a plugin system is great, if a user needs more feature, he can just add it himself without spamming the maintainers.
I think the main issue at the moment with the architecture is that the hooks are mutating the data. I think that hooks should act more like "reducers" (as in Redux reducers for example), take the data as param and return new (mutated) data.
That way you could let the users add hooks without worrying for the table to break.
That's pretty much what the hooks are doing at the moment and I'm not sure why that mutation is necessary.

I think I see what you're referring to now.
The first api is a reducer pattern, which is essentially what produces the final API. It's started in the useTable hook, then reduced through each plugin hook. Each plugin is responsible for returning the newly decorated or changed API as a replacement. Nothing is mutated there.
As all of the hooks are being reduced down to the final API, an internal hooks: {} object is currently used to keep track of functionality that must be deferred and applied later (after the final API has been reduced). Maybe hooks is a bad name internally, since it conflicts with the actual React hooks vocabulary. I'll try and think of a better one. Anyhow, the mutations you're referring to like api.hooks.getTableProps.push(...) could easily be avoided by creating a method like api.addHook('getTableProps', fn). Still, this technically wouldn't protect a user from mutating the hooks list though, since it is a property of the api that is being reduced. Again, we could pull that list out and only pass down the addHook function, but I feel like it's a bit overkill right now.
Under those circumstances, I think you're very correct that in addition to adding more functionality to existing hooks (like adding a prop to a header) you'll also want to be able to add new hooks (and their accompanying methods) to the system like what you mentioned: <input {...row.getSelectInputProps()} />. That way the user would have a new method to call in their markup AND other hooks could extend that api by using api.addHook('getSelectInputProps', fn).
Did I miss anything?

[Feature] Could we have a hook for update entire columns? Right now we are bounded to cells and rows level updates. We want to pivot the table which would make it awesome, is this possible?

[Feature] We can add support for virtualized rendering when used without pagination, this can increase performance of rendering huge tables without pagination.

@Aj1402  RT7 is headless - the developer using the library handles the rendering.  The sample @tannerlinsley provided on codesandbox (https://codesandbox.io/s/m5lxzzpz69) shows how infinite scroll can be implemented by creating a hook. Check src/components/Table.js and look for useInfiniteScroll - as well as just clicking the buttons on the demo. I don't think it is guaranteed, but that hook may be supplied as part of a set of hooks in the production release.

Are there docs in the works for v7? I realize it is still in alpha release but it will help get more usage and feedback. I am trying to bring v7 into my project (for the first time, never used prior versions) and am having to jump into the source to figure out how to use the APIs. For example, I'm trying to fire a callback when filters change and see onFilteredChange referenced in the docs/issues but don't see it in the code base.

Docs are still in the works unfortunately.
Also, the concept for handling changes to state have changed away from what you're used to:
const state = useTableState({ pageCount: 0 });
const [{ sortBy, filters, pageIndex, pageSize }] = state;

useEffect(
  () => {
    // filters changed
  },
  [filters]
);

useTable({
  ...
  state,
  ...
})

Essentially, you hoist the table state out into your own code which allows you to watch it for changes with useEffect probably being the easiest way to do this.

What is the best way to start and play with version 7, I'm looking forward to see all the possibility this rewrite will open and I would like to start testing it and possible contributing to it. I believe the only example out there is the code sanbox linked above, correct? Right now I'm trying to make a table with a nice treeview and I'm wondering if it can be a good feature for v7 and easier to implement instead of hacking something on top of v6 (I tried to use the HoC in v6 but is not doing a great job at the moment)

@dbertella - it will definitely be easier (in some ways) to do a Tree View in V7 but, as with all tree data, it is going to depend on how your tree is organised.  I am still learning V7 myself but hope to add a tree view example.  You would need to write a hook to manage the state (i.e. nodes open/closed etc.) and would possibly also need to implement other hooks to manage what "sorting" or "filtering" means against your tree data.  I recommend having a look at the useExpanded hook as it is currently used to do the pivoting node management.

For others following along here, I have recently been able to get a pure <table>, <tr>, <td> renderer going but there are a few more changes to test and PR to the core before that could be released in a codesandbox.

@gary-menzel thank you for the quick answer! I really want to dig into it now even more, I just find it difficult to figure out how to start. I guess I will start from the sanbox and get a simple version running, it might be nice to have a working example inside the repository perhaps.

That's what I have done. Created a CRA, got the files from the codesanbox, installed the V7 ReactTable and then just poked in.  I have not done much with hooks but the basic concept of them is simple to understand - it is just that the hooks for RT7 do a LOT.  There are also some "bugs" still to iron out.  It should be possible to remove a lot of the hooks and just get a basic table (and it will be) but there are a few dependencies still lurking between the hooks.

@dbertella as far as an example in the repo - I think that will end up staying clean and there will be Wiki entries and codesandbox samples (easier than previously because you can have teams in codesandbox and bind things to github).  I am also in the process of planning a e-book that will (hopefully) cover everything.

Hi,
@gary-menzel
I try to use v7 with server side data and infinite scrolling but it doesn't work even here https://codesandbox.io/s/m5lxzzpz69 :)
// When sorting, filters, pageSize, or pageIndex change, fetch new data
  useEffect(() => {
    fetchData();
  }, [sortBy, filters, pageIndex, pageSize]);

pageIndex never changes

I'm still learning V7 myself and have not yet gotten into how best to approach server-side (or infinite scrolling). @tannerlinsley would probably be the best one to help you out with this (although we are still also deciding what out-of-the-box hooks and renderers will be provided with V7 - maybe we can get something in that just works - or we might rely on some community input once the rest of the API has settled down).

I like the new hooks approach!
I'm curious if useExpanded should be used only for aggregation/pivoting but not expand/collapse of the rows to display details of the row?
btw, it seems that the row expanding is not working in the demo https://codesandbox.io/s/m5lxzzpz69 because  row.toggleExpanded is not defined.

useExpanded is actually extremely lightweight, so it's okay to use it for simple row expansion. Its useGrouping that is responsible for aggregation/pivoting.
Yeah, I need to update the sandbox with what's in master.

@tannerlinsley thank you for your response. Can you please tell me how to use useExpanded for simple row expansion?

Remember, all of this is in alpha and pretty hazy right now, but essentially, using the useExpanded hook will give you various .toggle() methods and expanded state that you can use to control a row's expanded state. You can also read from a row's expanded state through properties on the row model like isExpanded.
That should be adequate for implementing any custom UI for expanded rows you want, inside or outside of your actual table.

@tannerlinsley thank you again. When do you plan to update the npm package and the demo with the latest code?

Thanks very much for a great library. v6 is awesome for what i experimented.
For V7, it uses React Hooks. And i think this is a real deal for a React Datatable!
The real deal is in the simplicity, composability of Hooks, so let's prove it, right ?
Codesandbox is great and helpful, but it's not the best way to prove the change and improvement. Let's prove it in the README. Just give all API usage in a README , nothing more.

@tannerlinsley

using the useExpanded hook will give you various .toggle() methods and expanded state that you can use to control a row's expanded state. You can also read from a row's expanded state through properties on the row model like isExpanded.

As I understand there is no API to manage the rendering of the expanded rows, right? (maybe I can help with it in case you want it to be a part of the library?)
I ended up with something like this:
const MyTable = ({ expandable = false, renderExpandedRow, ...props }) => {
   const instance = useTable(props, ....);
   .....

   const renderRow = (row, index, style = {}) => {
    if (!row) {
      return (
        <Row {...{ style, even: Boolean(index % 2) }}>
          <Cell>Loading more...</Cell>
        </Row>
      );
    }
    prepareRow(row);
    const rowProps = row.getRowProps({ style, even: Boolean(index % 2) });
    const renderedRow = (
      <Row
        {...rowProps}
        expanded={row.isExpanded}
        onClick={() => {
          if (expandable) {
            row.toggleExpanded();
          }
        }}
      >
        {row.cells.map(cell => (
          <Cell {...cell.getCellProps()} className={cell.column.className}>
            {cell.render("Cell")}
          </Cell>
        ))}
      </Row>
    );

    if (row.isExpanded) {
      return (
        <React.Fragment key={rowProps.key}>
          {renderedRow}
          <Row
            {...rowProps}
            className={classNames(rowProps.className, "row--expanded")}
            key={`${rowProps.key}_expanded`}
          >
            {renderExpandedRow(row.original)}
          </Row>
        </React.Fragment>
      );
    }
    return renderedRow;
  };

  return <TableView ... />;
}

So maybe the example isn't very clear on this, but expanded rows are not nested in the model, they are flattened into list of total rows. When you look at each row, you will see row properties that denote the depth of the row, parents, etc. This makes it 10x easier to deal with nested data and not have to write recursive renderers.
React Table strictly does not provide any markup to the user for this reason. What you have here could work great for your specific use case, but might not be what someone else needs. If we were to add it to the API, we would be 10x-ing the API by adding the needed inversion of control points that any given user would need to fully customize it.
Ultimately the v6 API is massive and extremely bloated, and yet it still doesn't support a fully customized rendering option. v7 is half the size and supports an unlimited number of rendering options. This is a perfect example of why headless UI components are so great!

So maybe the example isn't very clear on this, but expanded rows are not nested in the model, they are flattened into list of total rows. When you look at each row, you will see row properties that denote the depth of the row, parents, etc.

I'm not sure but it seems you are talking about aggregation/grouping of the rows. But I'm trying to implement something like in this example https://codesandbox.io/s/github/tannerlinsley/react-table/tree/master/archives/v6-examples/react-table-sub-components.

Most of what I said remains the same. The expanded state that is used for grouping/aggregation can also be used for sub components. It all depends on how you choose to render the expanded state.

@tannerlinsley would you be able to publish the new version with the latest code, please?

My feedback: We've been using v6. I just reviewed the examples of v7 and I have some limited experience with hooks. I think v7 is looking awesome but it is also a huge sea-change from v6. So much so that IMO it should be a new github project not an upgrade from 6 to 7. I am concerned how many users of ReactTable are going to be surprised when they upgrade 6 to 7 on a whim and the API is completely changed. Not 30% changed, but 100%! lol. Could you instead create another github project and then refer ReactTable users to the new project going forward in the README?  Maybe "React-Tabular" or "React-Cell" or "React-xcell" haha.
I think you could then adapt current ReactTable API to use the new v7 project as a dependency and provide the user visuals on top of the hooked ReactTable but would actually have a v6 compatible API. Basically swapping out the old v6 behavior code for the hook code. Existing ReactTable users would experience only a bump in the road going to v7 but would also have a stepping stone to switching to their own visual styles using hooks.  Would this be the best of both worlds?
I have my doubts people on my team are going to understand hooks anytime soon, they can barely wrap their heads around React vDOM :(. It's unfortunate, but it is the truth of most developers and companies that like to hire cheap "talent".
This is food for thought. I really appreciate your work into ReactTable! Both v6 and v7 are awesome!!

@guru-florida that's good feedback. To help with your concern, my plans for v7 are not to only release what you currently see today as the v7 headless core, but also build and release a migration-centric kitchen-sink component along side it. This component's purpose will be to almost replicate the API and experience of the v6 component, but using the new v7 core under the hood. My hope is that this will help people migrate to v7, but easily be able to break out of the "training wheels" component when they are ready.
As for your concern with hooks, I feel obligated to put in my 2 cents: Hooks are React. I wouldn't consider them an addon or alternative syntax. They are core, just like the component API. While this may be painful, it shouldn't be any different than when people were forced to learn the HOC or render-prop patterns, except for they'll be learning core React patterns and utilities that will make their react code safer, faster, easier to write/compose/extract/share, and aligned with the rest of the React ecosystem. I know this can be a hard pill to swallow for companies or larger orgs with many employees, but trust me, your future selves will applaud you for learning and writing new code in React hooks ASAP.
Thanks for your feedback! Keep it coming!

@tannerlinsley Thanks. I wasn't aware of your migration plan and it's essentially the same thing so glad to hear.
I agree 100% with your second paragraph too but it's easier said than done in my case.  I don't have control over who is hired so I have to deal with the hand I've been given. TL;DR version they just aren't that interested in learning it. Old habits. What can ya do right? ....just move on....so in 3 more days I move on to another company. for reals. haha :)
I already use HOC and hooks, etc so I loved the new v7 design immediately and would migrate to it now but no time with me gone in 3 days. I am sure I'll be using it on the next project though.

Feedback: defaultState is not exported. Don't know how to define default state for own plugins.

Have you considered TypeScript?
Having third party type definitions for a very important widget like tables (data grids) can be a bit unnerving.
With official type definitions when user of the react-table updates the library, the user can be somewhat certain the update does not break the behavior since it type checks.

@Ciantic Yes, I have. A few things hold me back on that though:

I simply am not good enough with TS yet to be productive compared to my current status quo.
Using TS would severely limit the amount of people that would be able to contribute to the project, at least until TS gains the majority share of the JS ecosystem.

I have no qualms with moving to TS when the time is right, but in the meantime I will encourage integration tests for stability in its stead.

@AskAlexSharov, would you like to submit a PR to improve those experiences?

@tannerlinsley I am trying to sort desc on first user click. In v7 passing defaultSortDesc=true as a prop to the Table or Column only allows to flip between 'sort desc' and 'sort unset' states, which makes it impossible to sort ascending.
Is this a bug or am I misusing the prop property?

Sounds like a bug.
Tanner Linsley
On May 14, 2019, 6:11 AM -0600, Dmitrii Gaidarji<EMAIL_ADDRESS>wrote:

@tannerlinsley I am trying to sort desc on first user click. In v7 passing defaultSortDesc=true as a prop to the Table or Column only allows to flip between 'sort desc' and 'sort unset' states, which makes it impossible to sort ascending.
Is this a bug or am I misusing the prop property?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@tannerlinsley thanks for the quick response! I've fixed it for myself and shared the code for you #1341 1341

When do you think we will see docs for v7? I'd like to use it but it's a little overwhelming without any help or typescript bindings.

I'm writing the docs right now as I'm upgrading Nozzle from v6 to v7 in our next big release. Once we launch our next version of Nozzle, I'll consider its use-cases complete enough and the API design sufficient to finish the docs. Plan on a month.

@tannerlinsley would you be able to publish the new version with the latest code, please?

Been digging into v7 code for a bit, keen to properly understand how to use the depth/path properties manually to aggregate rows into expandable sections. Would also like to display the parent row when group is collapsed..

@tannerlinsley would you be able to publish the new version with the latest code, please?

Been digging into v7 code for a bit, keen to properly understand how to use the depth/path properties manually to aggregate rows into expandable sections. Would also like to display the parent row when group is collapsed..

@tannerlinsley
First, thanks again!
When copy&pasting table data to another place (word, excel, etc..) it is missing tabulation (table structure).
Will it be possible to add support for it in v7?
Is it even possible technically with css flex?!
Thanks!

@eladbs  The CSS Flex implementation will not work (with any page using it - not just only react-table) as the Office tools are looking for <table>, <td>, etc.  That being said, RT7 allows you to create your own rendering - it's headless, rendering is done by the developer and there will be extra examples along with both the flex/div layout and one using table but anything is possible.
So, if you want people to be able to mark the page and copy into Word/Excel, then you can provide a renderer based on the traditional <table> tags.

@gary-menzel Thanks for your reply!
You mean that I can render each component in the table with the appropriate table/td/tr/etc. to support that capability?
Somehow, I hoped that there will be built in support. I know it's hard or even impossible.

@eladbs Rendering is completely isolated from the table engine itself (which is all based on hooks).
So, while RT7 will have some basic renderers in the box, the developer is ultimately able to decide how to render the table.  RT7 essentially manages the composition of the data so that it fits the desired "shape" (i.e. the columns - and the page of rows).
It's not hard or impossible - it's just not really a design goal of RT7 to be opinionated about how to render tabular data.  The big challenges with previous versions of ReactTable were that everyone wanted different outcomes from the rendering.  So, RT7 provides that.

@gary-menzel Cool. Thanks!
I'll take a look at RT7 and will try to accomplish that.

I'm loving this headless architecture! Just a note, the codesandbox provided in the docs is a little buggy as it's not using the latest release, but I've managed to fix all the issues I was having by switching to the npm package.
Where can I find the latest code for future debugging? I seem to only be able to find alpha 2.

@ryanking1809 there is alpha 6 released on Github.
Would be nice if you could provide that code sandbox link here maybe so other people can use it to debug etc.!

Oh yes it can be found here https://codesandbox.io/embed/react-table-v7-sandbox-cr3eh
Just note the source in the react-table folder table needs to be upgraded for a more accurate reference. Where can I find the latest source in this repo?

Just chiming in to say that I've spent a little while working with the V7 alpha-5, and have really come to appreciate the new approach.  Very well thought out, and so much easier to extend (I wrote a basic useSelection hook to enable row selection) than in V6.  I also love that I have complete control over the presentation.  Thank you, this is fantastic, and to be honest, extremely usable even in its alpha form.

The latest source are on master on this repo yes afaik.

@ggascoigne interesting, I've built my own useSelection as well! I suppose it could be included in the library if already 2 people had to build it themselves.

+1 for for row / cell selection!

There's a bit of a bug when using pagination and grouping. The children of the grouped rows are filtered out due to the page limit. So if you expand the last row all the children will be displayed on the next page. I'm not sure on the best solution, perhaps applying pagination only to top-level rows would work.

@ryanking1809 that's funny but I did a PR to fix exactly this last week. It's actually not a bug but a feature haha.
cc @tannerlinsley
Check my PR for more details https://github.com/tannerlinsley/react-table/pull/1372

@Grsmto I suspect that a standard useSelection might be a good idea.  Since mine lives outside of the library it's a bit tied to its presentation since it injects a checkbox column, but I'd be happy to help work towards a more shareable version.

@ggascoigne ok, mine is only doing pure business logic, no UI. I'll setup a code sandbox and maybe open a PR then.

@Grsmto oh perfect!

Hey guys, really enjoying this hook rewrite. I'm going crazy with writing these plugins given how easy! Why not write a web socket pub / sub as a plugin for each row?????? (JK...jk)
Do you guys have any recommendations as far as the presentation layer? I know there's a clean line of demarcation when the plugin system was written, as to separate business logic from presentation...however there seems to be some crossover in situations that would need to modify both. How are you all recommending handling the cases that can't be separated cleanly?
Are you all making a base component such as in the Examples and passing props that trigger presentation changes that way? Or are you doing presentation changes in the hooks just not for the ones officially accepted under this project?
Also, has anyone tried to mix this up with render prop loaders and gauged performance?
Thanks again for the library, great experience so far and it's still alpha versioning!

As promised for who is interested, you can find my useSelectRow hook and a working example with  CodeSandbox in #1377
@brycejacobs I have been avoiding any presentation things in the hooks. I tried to make it "logic only" or at least versatile so it can work with a large number of UI cases. See the PR I did, that's what I'm using in production on a project and the hook is agnostic of the UI afaik.

As promised for whom is interested, you can find my useSelectRow hook and a working example with CodeSandbox in #1377
@brycejacobs I have been avoiding any presentation things in the hooks. I tried to make it "logic only" or at least versatile so it can work with a large number of UI cases. See the PR I did, that's what I'm using in production on a project and the hook is agnostic of the UI afaik.

I tried it now and,
The shortcoming currently is that the component above component with useTable does not have access to rows, where the selection data is stored.
For example filter and sort info is stored in state and the useTableState can be placed in the component above like in the server example. But useRows is not planned to be put in the component above.

Another thing is the onRowClick (it can also make it's way to this lib)
I pass the click with onRowClick to the component above.
But the click on the checkbox gets registered as well, need to be excluded, this is what I will add to my code now.
            <Row
                onClick={() => onRowClick({ index })}
                {...row.getRowProps({ style, even: index % 2, selected: row.isSelected })}
            >

It's been a while I have been using React Table v6 in my applications. But suddenly today when I visited thinking how can I use React table in right way for functional components, I see this(v7). Looks v7 in great shape. Just wanted to know when can this will done with full release from Alpha? Any ETA of same?

It would love web accessibility to be a first class concern for v7.
Here's some ideas about where to start

Use semantic html elements in the sandbox (currently every element is a div)
Create hooks that implement the ARIA grid role and ARIA treegrid role
Associate the Data Cells with the Appropriate Headers using scope="row" and scope="col" attributes where appropriate

You can read more about table accessibility at:
https://webaim.org/techniques/tables/data
https://www.w3.org/WAI/tutorials/tables/
https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Advanced
This will not just help people who rely on assistive technology to navigate the web, but also it allows power users to navigate tables to their preference. It also looks really good for the library and inspires confidence!

PR’s are always welcomed! ;)
On Jul 11, 2019, 10:06 AM -0600, Tai Klein<EMAIL_ADDRESS>wrote:

It would love web accessibility to be a first class concern for v7.
Here's some ideas about where to start
• Use semantic html elements in the sandbox (currently every element is a div)
• Create hooks that implement the ARIA grid role and ARIA treegrid role
• Associate the Data Cells with the Appropriate Headers using scope="row" and scope="col" attributes where appropriate
You can read more about table accessibility at:
https://webaim.org/techniques/tables/data
https://www.w3.org/WAI/tutorials/tables/
https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Advanced
This will not just help people who rely on assistive technology to navigate the web, but also it allows power users to navigate tables to their preference. It also looks really good for the library and inspires confidence!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

It would be great if onFetchData supported promises. That way we wouldn't need to explicitly handle the loading state and the error state ourselves.

onFetchData is deprecated and also unnecessary in v7. Take a peek at the sandbox for server side data or stay tuned for a more specific example.
On Jul 15, 2019, 6:49 PM -0600, Matt<EMAIL_ADDRESS>wrote:

It would be great if onFetchData supported promises. That way we wouldn't need to explicitly handle the loading state and the error state ourselves.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Any guidelines how to implement server-side + infinite scrolling (sandbox example for this case is not working)? I think any documentation for v7 would be beneficial for the project (more potential contributions). It's hard to grasp lib concepts (how hooks are composed, etc.) only by looking at the code. Any ETA for the initial docs?

I'm writing the documentation right now. It's a big undertaking so be patient. It's gonna be great.
On Jul 17, 2019, 6:21 AM -0600, Aurimas<EMAIL_ADDRESS>wrote:

Any guidelines how to implement server-side + infinite scrolling (sandbox example for this case is not working)? I think any documentation for v7 would be beneficial for the project (more potential contributions). It's hard to grasp lib concepts (how hooks are composed, etc.) only by looking at the code. Any ETA for the initial docs?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Are the HOC's for version 6 compatible with v7? I'd like to make a row selectable with SelectTable

The v6 HOCs are not compatible with this rewrite. V7 is essentially a brand new library with a very different architecture and concept
On Jul 18, 2019, 6:42 AM -0600, Laurie Poulter<EMAIL_ADDRESS>wrote:

Are the HOC's for version 6 compatible with v7? I'd like to make a row selectable with SelectTable
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Is there an easy way to provide a fuzzy-based filter for either all or a pre-defined subset of columns?
the goal is to have a single filter input, where the user can type in his filter string and based on that input only the rows are shown where the filtered string (fuzzy) matches the contents of the pre-defined (or all) rows.
The current way of defining filters on each column and basically combining them with a boolean AND doesn't seem to do the trick - but maybe i'm missing something.

@codepunkt sound like it should be OR not AND

I think the only way to implement this currently is filter data in the parent component before giving it to react-table.

Another option would be to create your own useFilter based upon the one in this repo and implement your own logic.  Then use this new useFilter instead of the one in the main library.

v7 is a great direction! It would be nice if useSortBy exported useMain as I truly only need sorting and little to none of the useTable. Not sure if this could be made more bare bones for sorting and maybe made it's own dedicated library or contributed to react-use.
My use case is in that the hook cares more about how to sort the data and less about Headers and Columns (already handled from the outside).  Thoughts..?

@nmccready That's an interesting idea, however even the main hook in useSortBy itself is still based on the assumption that it's operating within React Table and its API. I think it would be very non-trivial to extract it's usefulness for usage outside of this context.

I think it would be very non-trivial to extract it's usefulness for usage outside of this context.

You're right this is going pretty smoothly. I'll post back when I have a more polished solution.

@tannerlinsley I noticed in the latest releases the src/ is no longer published. This makes it very hard to consume this library in pieces without it. Also in in alpha.7 lib/ files did not match the source files for the ES5 compiled binaries.

In the latest alpha, you'll find I've readded src/**/*.js to the files list. If we end up needing lib/**/*.js files, I can also add those, but as of alpha.15, there shouldn't be any more files from v6 in the npm package.

@tannerlinsley I ported the useSortBy hook here . I'm sure this could be extended / wrapped to fit your needs.
If you want me to PR something back to here I'd be happy to. It is working great thanks!

@tannerlinsley can you please provide working server side example, let's say with pagination when useTableState is used in a parent component? I can't figure out why I get infinite rerendering.. after debugging it seems the cause is table state which I pass to child component responsible for the rendering. Somewhere ref equality is lost. Probably problem with the usage so working example would be a huge help. And thanks for your hard work!

@powah, Sure thing. Serverside examples are in the pipeline. I'm trying to get all of the client side examples and some snapshot tests of them done before moving on to server-side stuff. Hang tight!

This post has been open for a while. What can I do to get V7 released?

You can try the alpha, report missing use cases, write unit tests, or find bugs!
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech<EMAIL_ADDRESS>wrote:

This post has been open for a while. What can I do to get V7 released?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

This post has been open for a while. What can I do to get V7 released?

❯ yarn info react-table
yarn info v1.16.0
{ name: 'react-table',
  description: 'A fast, lightweight, opinionated table and datagrid built on React',
  'dist-tags':
   { latest: '6.10.0',
     next: '7.0.0-alpha.18' },
  versions:
   [ '0.0.5',
     '1.0.0',
     '1.1.0',
     '1.2.0',
....
     '6.10.0': '2019-04-23T23:02:00.560Z',
     '7.0.0-alpha.3': '2019-05-21T20:38:44.827Z',
     '7.0.0-alpha.4': '2019-06-11T17:40:59.369Z',
     '7.0.0-alpha.5': '2019-06-11T17:41:34.599Z',
     '7.0.0-alpha.6': '2019-06-20T21:23:59.551Z',
     '7.0.0-alpha.7': '2019-07-15T17:29:46.048Z',
     '7.0.0-alpha.8': '2019-07-25T19:39:33.379Z',
     '7.0.0-alpha.9': '2019-07-26T16:32:33.216Z',
     '7.0.0-alpha.10': '2019-07-26T16:53:14.524Z',
     '7.0.0-alpha.11': '2019-07-26T17:11:31.925Z',
     '7.0.0-alpha.12': '2019-07-26T17:23:00.224Z',
     '7.0.0-alpha.13': '2019-07-30T16:23:37.539Z',
     '7.0.0-alpha.14': '2019-07-30T17:44:17.674Z',
     '7.0.0-alpha.15': '2019-07-30T20:10:16.559Z',
     '7.0.0-alpha.16': '2019-07-30T23:01:56.484Z',
     '7.0.0-alpha.17': '2019-07-31T18:27:54.731Z',
     '7.0.0-alpha.18': '2019-08-03T20:37:35.260Z' },

Also, if you find that you don't have time to help out on the project, or that you're simply just waiting for the next version to hit, you or the company you work for could always become a patreon supporter of the project. I have tiers from as low as $1 up to $500 / mo. Also to be noted, all patrons on any $100+ /mo plans get their logo in this project's readme with a link to wherever they want. The repo receives about 35k unique visitors every month.

You can try the alpha, report missing use cases, write unit tests, or find bugs!
…
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech @.***>, wrote: This post has been open for a while. What can I do to get V7 released? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Thank you for your responses and thank you for investing time and effort into improving this!
I was looking into the alpha and I like it so far but I'll have to find more time to test it with more complicated use cases.

You can try the alpha, report missing use cases, write unit tests, or find bugs!
…
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech @.***>, wrote: This post has been open for a while. What can I do to get V7 released? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Thank you for your responses and thank you for investing time and effort into improving this!
I was looking into the alpha and I like it so far but I'll have to find more time to test it with more complicated use cases.

My pleasure. Thanks for your support.

You can try the alpha, report missing use cases, write unit tests, or find bugs!
…
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech @.***>, wrote: This post has been open for a while. What can I do to get V7 released? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Have been using  this recently and thanks for all the effort you've put into this. One use case that I think is useful is a control that gives the user the ability to toggle columns off/on. This is especially useful on mobiles and smaller screens. This could be achieved via a plugin hook in the new architecture.
Was wondering if there is already anything in the pipeline like this?

@tilanka The previous version (V6) did have the ability hide/show columns - assuming your column definitions were reactive or in your state management (so any change to the column definitions would cause a refresh). This is no different in V7 (although, hooks likely make the reactivity a little simpler).
Each column has a property on it that allows it to be shown or hidden (show: Boolean | Function).  It is up to the developer to implement the UI for accomplishing changing/setting this (as each use case as to how best to do it needs to fit in with the design of the UI).  react-table V7 is "headless" - meaning it actually doesn't product any markup - that is the developers responsibility.
I have you haven't yet done so, a read of the README on the code page will make this a little clearer as well as having a look at the V7 sandbox code examples.  Although, there is probably no specific example of doing this at present.

Can I use version 7 for production application?
Thank you for this awesome library. I loved the concept you can easily integrate it into any ui library. I am thinking to use this in production application. We have 4 to 5 core pages and each page has data grid. I am thinking to use this to solve all the client requirements. I see v7 is in active development. Is v7 stable?

Can I use version 7 for production application?
Thank you for this awesome library. I loved the concept you can easily integrate it into any ui library. I am thinking to use this in production application. We have 4 to 5 core pages and each page has data grid. I am thinking to use this to solve all the client requirements. I see v7 is in active development. Is v7 stable?

@tannerlinsley I know you must be busy brother but would appreciate a reply. I am in a bit of hurry, my team did not do a good enough job with data tables, and I have to improve them in this sprint.

@nouman91 Works great in production for me just make sure to lock your version as the alpha patch changes can be breaking.

Thank you for your response @jackpope . But I see it is not stable. I used pagination with sorting, it is not working with it. Somehow it gets stuck into infinite render loop. I guess I have to create data table from scratch.

Looks like it's not possible to use useRowSelect together with server side (manual) pagination because data in that case is only the current page and you get same row indexes (paths) for all pages so if you go to the next page - same row indices are incorrectly preselected.

Looks like we need a manual row index override for rows. This way you can provide the true row indices from the server, instead of relying on the manufactured ones. Thoughts? Also, please open a new issue to discuss this.

Closing this issue now, as it's getting pretty long and probably pinging a lot of people. If you have more feedback or questions, please file individual issues for them from here on out.
Thank you everyone!

Is there any link for server side (manual pagination)? I was trying to get data from server, it shows just top 10, not other data's
as server side pagination set for 10row's of data foe each page. Any help on this please
{
"count": 15,
"next": "http://<IP_ADDRESS>:8000/api/v1/applicant/?page=2",
"previous": null,
"results": [
...
...
]
}

Is there any link for server side (manual pagination)? I was trying to get data from server, it shows just top 10, not other data's
as server side pagination set for 10row's of data foe each page. Any help on this please
{
"count": 15,
"next": "http://<IP_ADDRESS>:8000/api/v1/applicant/?page=2",
"previous": null,
"results": [
...
...
]
}


agate: 3.3.3 → 3.3.4

Description of changes
https://github.com/mbrubeck/agate/releases/tag/v3.3.4
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 287066 run on x86_64-linux 1

1 package built:

agate