Reinvent4

Not able to run the Reinvent4 tool could you help me to execute it?

Hi,
thank you very much for your interest in REINVENT.
I would need much more information to be able to help.  Have you installed the software?  On what platform?  What does "not able to run" exactly mean e.g. is there an error message, does it start up but fails later, etc.?
Many thanks,
Hannes.

Thank you for the respond,
I did installed the software but don't know how to use it like what command should I execute I changed the config file paths as mentioned and moved it in tests folder, by running "pytest tests" command error is occuring could you provide a tutorial or something that will help me to understand the Reinvent4 better.
Thanks.

Ok, let's take this slowly.
If you install the software as per instructions you should do at some point
conda activate reinvent4
reinvent --help

Does that work and do you get sensible output?  You should get a short description including all the command line options that the tool supports.
You do not have to deal with pytest to run REINVENT or have to copy anything into the test directory. It is for developers, not for end-users.
There is no specific tutorial available at the moment but there are configuration input examples in config/toml with some instructions.

Yes I did created the environment and further steps and got the command line options through help.
Okay so except the pytest how to perform the running modes like sampling, scoring etc using Reinvent4's config files?
Unable to generate the sampling.csv file. Could you provide us the command for that? I did go through the config folder but its bit confusing.

Many thanks, this is useful information.  It would help us to improve the documentation if you could tell us what specifically is confusing to you.
Principally, you have to run the tool from the command line as
reinvent -l sampling.log sampling.toml

If you do not want to write out the log to a file but rather to the screen you leave out the '-l sampling.log' part.   You would copy the configuration file sampling.toml to a directory from where you wish to run your job.  The file is located in config/toml.
Next, you start editing with your preferred editor (ideally one that supports TOML in terms of syntax and highlighting).  There are some details in the various *.md files.  In the TOML file you would need to point the 'model_file' parameter to the right prior.  Those are in the directory you have downloaded from Github.   Depending on the model you may also need a 'smiles_file'.
What prior you choose really depends on what you are trying to achieve and what problems you are trying to solve.   This is of course a much wider question.

Thank you so much for the help I will try the command you gave if any error occurs I will let you know.

In your Conda enviroment can you run the following please
conda list | grep torch

and tell me what your version number of torch is.

torch                     1.12.1+cu113             pypi_0    pypi
torchvision               0.13.1+cu113             pypi_0    pypi

Many thanks.  Would you be able to share your config file with me?

Are you running your job on the CPU?  I see the same error when run on the CPU but not on the GPU.

sampling.zip

Are you running your job on the CPU? I see the same error when run on the CPU but not on the GPU.

No its on GPU

Other running modes like scoring transfer learning, they are giving the output the only error is in the sampling. I even tried with other mode in sampling still the error is similar.

Many thanks for all your help.  We will be working on a fix and will let you know when done,.

Just to be sure, can you provide me with the ouput of your log file (-l), please?

Its running on the CPU I rechecked it.

13:03:34  Started REINVENT 4.0.11 (C) AstraZeneca 2017, 2023 on 2023-11-16
13:03:34  Command line: /home/rinku/miniconda3/envs/reinvent4/bin/reinvent -l sampling.log sampling.toml
13:03:34  User rinku on host admin
13:03:34  Python version 3.10.13
13:03:34  PyTorch version 1.12.1+cu113, git 664058fa83f1d8eede5d66418abff6e20bd76ca8
13:03:34  PyTorch compiled with CUDA version 11.3
13:03:34  RDKit version 2022.09.5
13:03:34  Platform Linux-5.15.0-88-generic-x86_64-with-glibc2.35
13:03:34  Number of PyTorch CUDA devices 0
13:03:34  Using CPU x86_64
13:03:34  Writing JSON config file to /home/rinku/REINVENT4/configs/toml/_sampling.json
13:03:34  Starting Sampling
13:03:34  Using generator Reinvent
13:03:34  Writing sampled SMILES to CSV file sampling.csv
13:03:34  Sampling 157 SMILES from model /home/rinku/REINVENT4/priors/reinvent.prior
13:03:35  Time taken in seconds: 1
Output of log file

"Using CPU x86_64" tells me that you are actually run on CPU.  As you have set use_cuda = true this means that you have a problem with you CUDA setup.  Do you have Nvidia hardward and if so does the tool nvidia-smi work for you.

Ok, I realize that that is what you actually said.  Nevertheless, we will be working on the CPU related bug.

I think we have fixed this.  Please git pull into your repository and let us know how it goes.

Okay thank you so much for your time I will let you know by tomorrow.
On Thu, Nov 16, 2023, 11:11 PM Hannes Loeffler @.***>
wrote:

I think we have fixed this. Please git pull into your repository and let
us know how it goes.
—
Reply to this email directly, view it on GitHub
https://github.com/MolecularAI/REINVENT4/issues/3#issuecomment-1814929822,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BA7XZG2GV7Z2SWCLEP3LH43YEZF5TAVCNFSM6AAAAAA7NSLTXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUHEZDSOBSGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

The sampling is excecuting perfectly also the rest of the modes except the transfer learning.
Earlier the transfer learning mode was running now its showing the below error..
(reinvent4) rinku@admin:~/REINVENT4/configs/toml$ reinvent -l transfer_learning.log transfer_learning.toml
Traceback (most recent call last):
File "/home/rinku/miniconda3/envs/reinvent4/bin/reinvent", line 8, in
sys.exit(main())
File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/reinvent/Reinvent.py", line 284, in main
runner(input_config, actual_device, tb_logdir, responder_config)
File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/reinvent/runmodes/TL/run_transfer_learning.py", line 149, in run_transfer_learning
runner = runner_class(adapter, tb_logdir, mode_config, logger_parameters)
File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/reinvent/runmodes/TL/learning.py", line 136, in init
self.tb_reporter.add_histogram("Tanimoto input SMILES", np.array(sim), 0)
File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/torch/utils/tensorboard/writer.py", line 484, in add_histogram
histogram(tag, values, bins, max_bins=max_bins), global_step, walltime
File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/torch/utils/tensorboard/summary.py", line 352, in histogram
hist = make_histogram(values.astype(float), bins, max_bins)
File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/torch/utils/tensorboard/summary.py", line 380, in make_histogram
cum_counts = np.cumsum(np.greater(counts, 0, dtype=np.int32))
TypeError: No loop matching the specified signature and casting was found for ufunc greater

I believe I have fixed that now too.

Yes its running!!! thank you so much for your help.

In transfer_leraning.toml file what input should I put in validation_compounds.smi file.

This comes down to the basics of machine learning i.e. how to split a dataset into training set, test and/or validation set.
Having said that, you can also just leave it out  The validation set is mostly a help to keep control over overfitting.
In practice, however, the problem is somewhat ill-defined: you want to use TL to make a model produce molecules more like the input set  But what does "more like" mean in practice?  You do not want to be to close to the original model and you do not want the model to reproduce just the molecules from the input data set.

Okay i'll look for it.
Thanks

Would you please open a separate issue for this?  Would you also be able to share TOML config and input SMILES file?

The sampling is excecuting perfectly also the rest of the modes except the transfer learning. Earlier the transfer learning mode was running now its showing the below error..
(reinvent4) rinku@admin:~/REINVENT4/configs/toml$ reinvent -l transfer_learning.log transfer_learning.toml Traceback (most recent call last): File "/home/rinku/miniconda3/envs/reinvent4/bin/reinvent", line 8, in sys.exit(main()) File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/reinvent/Reinvent.py", line 284, in main runner(input_config, actual_device, tb_logdir, responder_config) File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/reinvent/runmodes/TL/run_transfer_learning.py", line 149, in run_transfer_learning runner = runner_class(adapter, tb_logdir, mode_config, logger_parameters) File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/reinvent/runmodes/TL/learning.py", line 136, in init self.tb_reporter.add_histogram("Tanimoto input SMILES", np.array(sim), 0) File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/torch/utils/tensorboard/writer.py", line 484, in add_histogram histogram(tag, values, bins, max_bins=max_bins), global_step, walltime File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/torch/utils/tensorboard/summary.py", line 352, in histogram hist = make_histogram(values.astype(float), bins, max_bins) File "/home/rinku/miniconda3/envs/reinvent4/lib/python3.10/site-packages/torch/utils/tensorboard/summary.py", line 380, in make_histogram cum_counts = np.cumsum(np.greater(counts, 0, dtype=np.int32)) TypeError: No loop matching the specified signature and casting was found for ufunc greater

how can you fix this error? I came into the same error.
many thanks


table component ui improvement

Removed Hover effect on Table Header and changed the bg
Added only borderBottom
Updated hover and active colors for Tr
Added pointer cursor type for row elements
Added docs for Table component

@meenakshi-ss  we don't have a documentation on Table Component. It would be nice to release that also. @akzhysparrow   please coordinate on what all has to be documented

@justin-ss There is a an issue with table in docusaurus, the default styling for tables in docusaurus is interfering with the styles that we are applying and the output is incorrect. We will either have to force reset all the styles for docs alone or we will have to embed it in an iframe.
I tried using shadow DOM but in that case stitches styles were also not getting applied.

@justin-ss There is a an issue with table in docusaurus, the default styling for tables in docusaurus is interfering with the styles that we are applying and the output is incorrect. We will either have to force reset all the styles for docs alone or we will have to embed it in an iframe. I tried using shadow DOM but in that case stitches styles were also not getting applied.

Is this a problem in Live Editor also?

@justin-ss There is a an issue with table in docusaurus, the default styling for tables in docusaurus is interfering with the styles that we are applying and the output is incorrect. We will either have to force reset all the styles for docs alone or we will have to embed it in an iframe. I tried using shadow DOM but in that case stitches styles were also not getting applied.

Is this a problem in Live Editor also?

@justin-ss , the issue is happening in live editor and its preview only, and in storybook it is working fine.

We could make a sandbox and link it there instead of live preview until the playground can support custom examples @justin-ss

@all-contributors please add @meenakshi-ss for code, bug


Abolish the unique attribute "RecordDefinitionAttribute" and replace it with a generic one

candidate
System.ComponentModel.DataAnnotations.Schema.TableAttribute

I considered it, but "System.ComponentModel.DataAnnotations.Schema.TableAttribute" requires a Name, and the usability is quite different, so there is no advantage to integrating it.
We will not integrate attribute classes.
However, I don't think the current class name "RecordDefinitionAttribute" is common, so I will change it to "TableDefinitionAttribute".


Sharp crashes silently

What is the output of running npx envinfo --binaries --languages --system --utilities?
  System:
    OS: Windows 7
    CPU: (8) x64 AMD FX(tm)-8320 Eight-Core Processor
    Memory: 6.66 GB / 11.97 GB
  Binaries:
    Node: 8.9.1 - C:\Program Files\nodejs\node.EXE
    npm: 5.5.1 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.15 - C:\Users\Halil\.windows-build-tools\python27\python.EXE

What are the steps to reproduce?
sharp version: 0.23.0
Run simple code with any PNG, like the one below (getting the metadata).
What is the expected behaviour?
BEFORE + AFTER, but only BEFORE happens (example below).
Are you able to provide a standalone code sample, without other dependencies, that demonstrates this problem?
const sharp = require("sharp");

console.log("BEFORE");
sharp("intros.png").metadata()
    .then(() => {
        console.log("AFTER");
    });

Are you able to provide a sample image that helps explain the problem?

A bit longer explanation:
I do the devops in my company. I use sharp in the last pre-release step, to optimize the images on the site. It works on all linux machines (2), all mac machines (1), and 3 windows machines out of 6 (it works on 3 win10 machines, doesn't work on 2 win10 and 1 win8). It just crashes, breaking the program without any output... Can you figure out why it is happening and how to mitigate the issue for these machines?
PS. The issue happens with 0.23.0 version. With 0.22.1 everything works, so we have reverted to that one for now (so we're not blocked by the issue).

Hi, are you able to use WinDbg or similar to get a backtrace of the crash?

I am able, but you have to guide me through the steps. I tried installing windbg and setting it as postmortem debugger as described here, but windbg does not get auto-started after the crash and I don't know how to get the crash report....

https://github.com/lovell/sharp/issues/1708#issuecomment-510459336 provides an example of using procdump that should help.

Ok, sorry for the wait, so I started the code above with sharp 0.23.0 and procdump:
Output:
BEFORE
[13:26:22] Exception: C06D007F
[13:26:22] Unhandled: C06D007F
[13:26:22] Dump 1 initiated: c:/repro\node.exe_190821_132622.dmp
[13:26:23] Dump 1 complete: 4 MB written in 0.5 seconds
Exception code=0xc0000005 flags=0x0 at 0x0000000000000000. Access violation - attempting to execute data at address 0x0000000000000000
[13:26:23] Dump count reached.

Dump attached.
node.exe_190821_132622.zip
Hope this helps!

Thanks, I'll try to find a Windows machine to inspect this file on. Does this problem occur only with PNG input images?

It does happen on jpg as well

I tried analysing the dump file using WinDbg and, with a bit of web searching, my best guess would be that this exception relates to delayed loading of DLLs . A good next step might be to try running http://www.dependencywalker.com/ on the sharp.node file on one of the machines that fails and comparing the result of running it on a machine that works.
Perhaps overzealous anti-virus software on the failing machines is somehow intercepting/breaking DLL calls?

@bjg2 Were you able to make any progress with this?

Closing due to inactivity but please feel free to reopen with more details if further help is required.


Add HTTP query caching

Allow to annotate the GraphQL schema with caching hints and add middleware that dynamically computes the cache expiration time on a per query basis. In this first iteration these cache hints are used to set the HTTP Cache-Control header, but I've also did some preparation work for custom user-space cache implementation for example using Redis. However there were some open questions around short-circuiting and cache key computation that were stalling the original PR, so I decided to leave them out.
Closes #2089
Examples
The examples below only show how to apply the @cacheControl directive on object type fields, but the directive can also be applied on object types, interfaces and union types. If a field returns a type that specifies a @cacheControl directive, the field will use the cache information from the type, unless the field itself specifies a @cacheControl directive.
Annotation-based
services.AddGraphQLServer()
    .AddHttpQueryCache()
    .UseQueryCachePipeline()
    .ModifyCacheControlOptions(options =>
    {
        options.Enable = true;
        options.ApplyDefaults = true;
        options.DefaultMaxAge = 0;
    })
    .AddQueryType<Query>();

public class Query
{
    [CacheControl(100, Scope = CacheControlScope.Private)]
    public string Foo() => "Bar";
}

Code-first
services.AddGraphQLServer()
    .AddHttpQueryCache()
    .UseQueryCachePipeline()
    .ModifyCacheControlOptions(options =>
    {
        options.Enable = true;
        options.ApplyDefaults = true;
        options.DefaultMaxAge = 0;
    })
    .AddQueryType<QueryType>();

public class QueryType : ObjectType
{
    protected override void Configure(IObjectTypeDescriptor descriptor)
    {
        descriptor.Field("foo")
            .Resolve("bar")
            .CacheControl(100, scope: CacheControlScope.Private);
    }
}

Schema-first
services.AddGraphQLServer()
    .AddHttpQueryCache()
    .UseQueryCachePipeline()
    .ModifyCacheControlOptions(options =>
    {
        options.Enable = true;
        options.ApplyDefaults = true;
        options.DefaultMaxAge = 0;
    })
    .AddDocumentFromString(@"
        type Query {
            foo: String @cacheControl(maxAge: 100 scope: PRIVATE)
        }
    ");

@michaelstaib @PascalSenn I have laid out the basic user-facing API of this feature, so we have a discussion basis. You can see some usage examples here: https://github.com/ChilliCream/hotchocolate/blob/bc441e9f5dda779cd9639d4c29f3d5e2f903fc34/src/HotChocolate/Caching/test/Caching.Tests/Examples.cs
Essentially this would allow users to specify generic cache hints in their schema, regardless of the approach chosen and even dynamically within resolvers.
Then they could implement an IQueryCache that specifies how a query is cached and how it's loaded. The QueryCacheMiddleware takes care of computing the scope and maxAge of a query based on these cache hints and passes the result to the IQueryCache which can then decide what to do with this information.
In the future we could also ship caching implementations for Redis, etc. as we did for other features. At the moment I have only implemented HTTP caching, which essentially just sets the Cache-Control header.
There are some things I'm still not sure how to actually implement, but I first wanted to discuss the API with you guys. I have closely modeled it after the Apollo approach: https://www.apollographql.com/docs/apollo-server/performance/caching
One thing that would affect the user facing API is, what would actually end up in the Cache? I think it only makes sense to store the raw JSON response that would be returned from the GraphQL server. From what I've seen, materializing the query result inside the pipeline shouldn't be a problem, but I'm not sure how feasible it is to short-circuit the pipeline and return just the raw JSON data, once it has been loaded from the cache.
Let me know what you think of the API and the above "problem". Once we agree on the API, we should probably do a call on how I can implement this. I would've implemented it like the OperationComplexityAnalyzer, but I'm for example not sure how I would handle the dynamic cache hints set by a resolver, etc.

Awesome Tobias, will gobthrough it tonight

@tobias-tengler Thanks. with this branch, can we try cacheControl directive. It would be great, if any usage snippets added here.
Also is this targeted with v13, kindly confirm. thanks.

@tobias-tengler @michaelstaib Thank you. It would be great if this can be targeted to v13

@zf-jsk You can try out the HTTP query cache by registering it like this:
services.AddGraphQLServer()
    .AddHttpQueryCache()
    .UseQueryCachePipeline()
    // optional:
    .ModifyCacheControlOptions(options => { })

You can then use the CacheControl() method in Code-first, the [CacheControl] attribute in Annotation-based or the @cacheControl directive in Schema-first to specify rules.
I haven't worked on this in a while, so I'm no longer sure what the current limitations are, but if I remember correctly it should cover basic use cases.
If custom caches are not part of the first iteration then I think this could go into v13. I'll try to spend some time on it to get it usable with HTTP Cache-Control. :)

@tobias-tengler thank you, lets try using it and update here. Awaiting for this feature out. :)

Give me a ping if you need help @tobias-tengler

@michaelstaib Could you check and see if this implementation is alright? If so, please let me know then I can add XML summaries and documentation.
This version includes only the HTTP query cache, I've cut out the implementation for reading cached queries from a user-defined storage such as Redis. I think we should wait whether there is interested in having any other caches besides the HTTP cache, before starting to implement the reading portion.

Federated cache directives is a big win. Looking forward to the outcome of this.

 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.

No clue why it's throwing the The FrameworkReference 'Microsoft.AspNetCore.App' was not recognized for the Caching.Http project. The csproj looks the same as the AspNetCore project, so I'm not sure where it's coming from. Maybe a .NET 7 thing, but I haven't found anything around it. Maybe one of you knows what's going on here :)

OK ... will have a look at this

The title of the PR, "Add HTTP query caching" is somewhat misleading.  I thought that it was implementing actual response caching.  But it does not appear to do that, but instead provides a way to dynamically set the cache-control header.
I find the topic of output caching, with automatic cache invalidation based on mutations, very interesting.  However, it appears, we are not quite there yet.

The issue name is more correct


Tnet not present in pointnet implementation

First, thanx for the codes.
In the pointnet implementation your implementation seems to not contain tnet ( orthogonal transformation )
May I ask why ?
thanx

I didn't use the pointnet implementation. You can ignore it.


[WIP] Enable to stop one or more labs

Make
labctl playground stop playID

to accept a list of playground IDs. Pretty much make it work like docker stop
docker stop cont1 cont2 cont3

so it looks like
labctl playground stop playID1 playID2 playID3

@iximiuz The code does what I expect it to do (it iterates over the list of passed in playground IDs to stop command), however the spinner somewhat stands on my way now and I can't get my head around how it works. It will just process the first playground ID and "eat" all other playgrounds so they won't get stopped. Can you take a look at it? 👁

Or it may as well be related to GET'ing the playground ID which checks the status before it continues processing. I noticed that GET'ing a list of playgrounds is somewhat "laggy". What I mean by that it that when I refresh the dashboard page I see the playgrounds are gone however when I GET the list of playgrounds it still shows some active playgrounds. Not sure which is the source of truth here :)


dyld: Symbol not found: with update from 0.100 to 0.103.2

Goals
Update RealmSwift with CocaoPods from version 0.100 to 0.103.2
Expected Results
On a clean simulator I expect my App to run normally as with version 0.100.
Actual Results
crash on startup
dyld: Symbol not found: _TFC10RealmSwift6Object14linkingObjectsuRxS0_rfTMx11forPropertySS_GSax
Steps to Reproduce

Update to version 0.103.2 with "pod update"
Xcode menu Product / Clean
Product / Run

Code Sample
Crashes at startup before any of my code runs.
Version of Realm and Tooling
Realm version: 0.103.2
Xcode version: 7.3.1 Build version 7D1014
OSX version: OS X 10.11.5 15F34
iOS version: Version 9.3 SimulatorApp-645.9
Dependency manager + version: CocaoPods 1.0.0

Could you please try deleting derived data and cleaning the build folder in Xcode? You're likely getting this error because Xcode thinks its build cache is valid when in fact it isn't.
To clean the build folder, hold down the ‘Option’ key while opening the ‘Product’ menu, then choose ‘Clean Build Folder…’. You can also type “Clean” into the Xcode help search menu and select the ‘Clean Build Folder…’ menu item when it shows up in the search results.

I deleted the DerivedData directory and cleaned the build folder but it didn't help.
Also I tried to remove the RealSwift dependency from my podfile, did "pod update". Then added RealmSwift back in and did "pod install". The problem remains.
Do you have any other suggestion?

Try this:
pod cache clean Realm
pod cache clean RealmSwift
pod deintegrate
rm -rf Pods
pod install --verbose

I found the problem. I still had an old FRAMEWORK_SEARCH_PATHS in Build Settings which pointed to an old Realm version before I switched to CocaoPods. After I deleted this setting I still had to delete the DerivedData directory and clean the build folder before it worked.
Thanks for your help.

Glad to hear you resolved this!


Add Casambi light_turn_on service

Adds support for the light_turn_on service in the casambi platform. This service allows to control brightness and distribution provided by aiocasambi.

Shouldn't custom_components/services.yaml be located in custom_components/casambi/ e.g. in the casamb domain?

Yep you are right. Thanks for reviewing. That was a wrong copy&paste when I transferred the changes from my devcontainer. Just added a second commit to move the file.

Thanks for the PR!


self and root links should always be absolute URLs

This change had unanimous agreement. This would allow all other relative links to be clearly resolved. While it may make moving catalogs slightly more involved, we feel it is a reasonable burden that results in a more easily navigable catalog.

We should probably clarify what a 'root' link means in STAC API, and what it should point at.

So this is all up to date for self links. I think still need to double check for root, but I think I'm just going to change this issue to self only, and then we need to do a bit more work in general on defining how root works, especially in context of stac api stuff.


add misses to cache to avoid pegging schema registry

Codecov Report

Merging #363 into master will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #363      +/-   ##
==========================================
- Coverage   89.94%   89.93%   -0.02%
==========================================
  Files         139      139
  Lines        2954     2950       -4
  Branches      138      130       -8
==========================================
- Hits         2657     2653       -4
  Misses        297      297

Impacted Files
Coverage Δ

...ala/hydra/avro/resource/SchemaResourceLoader.scala
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


sdk: add dsl.OneOf docs

/hold
Do not merge until after https://github.com/kubeflow/pipelines/pull/10067 is released

/remove-approve

/assign @chensun

/unhold


Document how to detect out-of-memory crash

this is follow up on go/notes-user-profile-for-devtools-memory-uxr
It should be documented how to determine if application crashed because of memory issues.

Hi @polina-c where should this be documented, do you think?

The same place as specified here: https://github.com/dart-lang/sdk/issues/50605#issuecomment-1339825865

https://github.com/dart-lang/site-www/issues/4419


task name length issue in tree view

It seems that the space allocated for the task name is not sufficient for long task names.

Fixed.


Wrong color parsing

This lib would be very useful.
However when testing with #ffffff and #000000 swatches, the white colour is incorrectly parsed as #0000ff = blue

Good catch! This is just a quick PoC but that scenario should be inside the test cases :)
PR's welcomed 😄

Just did a quick test case for that and seems like it's working fine. Can you please provide a test .aco file for that scenario? :)

Yes, I have a swatch exported from Photoshop with white and black colors only.
Output is #0000ff for the white swatch. Here's the aco file and my basic script:
https://github.com/czebe/swatch-names

Taking a look into it now. I'll let you know :D

❯ xxd fixtures/swatches.aco
00000000: 0001 0002 0001 0000 0000 ffff 0000 0000  ................
00000010: 0000 0000 0000 0000 0002 0002 0001 0000  ................
00000020: 0000 ffff 0000 0000 0006 0057 0068 0069  ...........W.h.i
00000030: 0074 0065 0000 0000 0000 0000 0000 0000  .t.e............
00000040: 0000 0006 0042 006c 0061 0063 006b 0000  .....B.l.a.c.k..

Taking a quick look to your swatches.aco, seems like it's actually blue 😅 even if the name of the color is White as you can see in bytes 20..30. In the first line you can see the 00000000: 0001 0002 0001 0000 0000 ffff 0000 0000. If I use a third party tool I also get a blue "white" hehehe. Is photoshop actually showing a white white?

The swatch I've created for testing looks like this, please note that is inverted Black and then White.
❯ xxd fixtures/test-black-and-white.aco
00000000: 0001 0002 0000 0000 0000 0000 0000 0000  ................
00000010: ffff ffff ffff 0000 0002 0002 0000 0000  ................
00000020: 0000 0000 0000 0000 0006 0042 006c 0061  ...........B.l.a
00000030: 0063 006b 0000 0000 ffff ffff ffff 0000  .c.k............
00000040: 0000 0006 0077 0068 0069 0074 0065 0000  .....w.h.i.t.e..

here is the correct ff's -> 00000030: 0063 006b 0000 0000 ffff ffff ffff 0000  .c.k............
Could you please create a new swatch?

Hmmm, seems like it could be the colour space as your's is 0001 (HSB) and mines it's 0000 (RGB). This is something that needs to be addressed in #1 as for now it's only working with RGB. A PR would be welcomed! :D

Ahhha!! I didn't notice that. Loading the swatch in Photoshop shows the correct black/white colors.

Ok, I figured out how to change the color space for swatches in Photoshop. HSB swatches are exported by default. You need to click the RGB color mode on the color picker before creating the swatch. Exporting after this, works just as expected. This is somewhat counterintuitive, as designers would never switch to this mode in the color picker:

Hi, I'm beginning to get my head around the ACO file format. One thing that I don't get yet, maybe you can help:
On line #44:
const getHex = (color) => color.slice(0, 2)
What's the rest of the color definition mean?
Eg. #010000 is represented by bytes: 0102 0000 0000.


fix(android): Removed read and write media permissions to allow to use Android photo picker #866

Platforms affected

Android

Motivation and Context
Google recommends using the Android photo picker in apps where it's not frequent to access these files instead of the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions.
This should fix #866
Description
Removed the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions and WRITE_EXTERNAL_STORAGE storage permission maxSdkVersion is set to 30.
Testing
Tested these changes on Android 10,11,12,13 and 14 devices.
Checklist

[ ] I've run the tests to see all new and existing tests pass
[ ] I added automated test coverage as appropriate for this change
[x] Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
[x] If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
[ ] I've updated the documentation if necessary

As it stands, this PR will break picking content from the gallery.
The PR simply removes the READ_MEDIA_* permissions and reduces the WRITE_EXTERNAL_STORAGE permission to max 30.
I understand that the photo picker requires API 30, so starting with API 30 the photo picker could be implemented and API 29 and lower can do what the plugin currently does. Is the intent to have another PR implement the photo picker to cover the gallery use case?

Also https://github.com/apache/cordova-plugin-camera/pull/890 is merged so if you rebase, it will get the new CI config for the android tests.

As per information present in the below page (shared  in #866 by Fantikor),
https://medium.com/androiddevelopers/permissionless-is-the-future-of-storage-on-android-3fbceeb3d70a

This plugin is using ACTION_GET_CONTENT intent, so this new photo picker is actually used under the hood. So I modified this plugin and removed the code that requests permissions (for READ_MEDIA_IMAGES and READ_MEDIA_VIDEO) as they were previously only required for Android API levels 33 and above and for the versions 29 and below the plugin would retain the same behavior as before.  If I am not wrong the gallery use case is also working as expected and no other changes are required as Android photo picker is used under the hood.
Let me know if you see something is missing or If I misunderstood it.

This plugin is using ACTION_GET_CONTENT intent, so this new photo picker is actually used under the hood. So I modified this plugin

Ok this is good... I thought we were using some other intent and didn't actually realise ACTION_GET_CONTENT will actually use the photo picker. Android docs doesn't explicitly state this but if we restrict the media type (which in most cases we do) then android will choose the best picker/application for the requested type of content.
The bad news is, simply using the picker and removing the permissions isn't the complete solution. Bear with me this will be quite a lengthy post... but this will explain the situation.
To be clear, this is not the fault of this PR or anything, just things that Cordova has done in the past because it seemed like a good idea at the time and never has updated or introduced the breaking changes required to move to newer concepts and now Cordova is getting a bite of those consequences.
First, I've done all my testing using the FILE_URI mode, and only using images. I'm assuming videos has identical behaviour.
Cordova takes primarily two different paths when using the camera API:

Sourcing new content from the camera hardware
Sourcing existing content from the gallery

Sourcing new content from the camera does work, regardless of permissions or API level. This works because the native receives a content:// uses the content resolver and reads the content and writes it to an app-specific cache directory and then returns the app-specific internal file:// path, which is usable by the filesystem APIs. While this works... it is kinda problematic for a reason I'll get into later.
Sourcing existing content from the gallery however doesn't do file copy. It instead simply resolves the content:// to the external file system path and returns that. Both READ_EXTERNAL_STORAGE and READ_MEDIA_* permission requirements comes from the fact that the API shares these external URIs. They are required if you use the Filesystem APIs instead of the MediaStore APIs. In API 30, Android has a concept of FUSE filesystem that maps external FS kernel calls to the media store to enforce access but this does not grant the application temporary access that the content:// urls does when using the media store. Scope storage exists in API 29 which also lacks this FUSE filesystem so I believe this is currently completely broken on API 29 devices.
Solution 1

While this works... it is kinda problematic for a reason I'll get into later.

So the quick solution which will fix API 29, and should also allow us to eliminate the storage permissions is to do what we do when sourcing content from the camera. Use the content resolver to obtain the content and write it to app-specific cache and return those uris instead of external paths. This isn't a breaking change, we aren't changing the public API. But the reason why this approach is problematic is, copying large files obviously will take time. So picking videos will likely not give a good user experience, depending on the size of the video. Image content is usually manageable in terms of file size.
Here are some code references:

https://github.com/apache/cordova-plugin-camera/blob/master/src/android/CameraLauncher.java#L576 (if you follow the method calls, it will eventually return a temporary file location to write to)
https://github.com/apache/cordova-plugin-camera/blob/master/src/android/CameraLauncher.java#L583 (here, if you follow into the method,  we use the content resolver to get the content output stream) and copy via a 4096 byte buffer to the temporary cache location
https://github.com/apache/cordova-plugin-camera/blob/master/src/android/CameraLauncher.java#L586 (here, we return the tempoary file location uri back to the webview)

The problematic returns are likely:

https://github.com/apache/cordova-plugin-camera/blob/master/src/android/CameraLauncher.java#L574 (which I think returns the uri from gallery if it already exists in the gallery, probably yielding an external or content URI)
https://github.com/apache/cordova-plugin-camera/blob/master/src/android/CameraLauncher.java#L733 (which is the main handler method for processing the result from gallery)

Other Thoughts
I've also explored passing content:// uris directly to the webview, which poses several issues:

The webview will not accept content:// uris (despite even using setAllowContent(true) on the webview settings). Android docs doesn't state anything on why this might be the case but blocking content uris might be intentional based since Android KitKat on https://issuetracker.google.com/issues/36985138 (aka when Android moves to a chromium based webview).
Apache Cordova doesn't have a media store interface, so the user can't programmatically interact with the content
content:// uris give temporary access to the app, which makes the uris not persistent. Once the app activity closes, access to the content:// content is expired. So if the user wants to persistently access that resource, they must be able to programmatically interact/copy the data making issue 2 a big deal.

cordova-android platform could solve the first issue by mapping a path inside the WebViewAssetLoader that can resolve to the content:// uri and make use of the content resolver and return that content. But the other 2 issues will be prevalent without a media store API. There are third-party plugins available for a media store API but I don't think Apache Cordova should build the core plugins to rely on third-party plugins.
Being able to use content:// uris (even indirectly) is probably much better, but will require a lot of other moving parts to occur first. Additionally, requiring the use of a media store plugin for android also isn't ideal when iOS will need to continue to use the file plugin APIs. Cordova code is meant to be shared across platform, so we can't have a plugin API that requires using the result in two different ways depending on the platform. Therefore Cordova ideally needs to figure out how it can incorporate content:// uris in the file plugin APIs so that usage can be consistent cross platform.
Final Thoughts
Due to time constraints, I don't think the content:// solution is viable, so I think we are stuck with the first Solution. I know this is a lot, I'm not sure if this is still something you are willing to work on. If not, then that's okay too, we can probably still make use of what you've done in this PR and implement the rest in another PR.

I've done a bit more testing using content urls and wanted to follow up with some more details.
Using content urls directly simply doesn't work and I still don't know why.
Using resolveLocalFileSystemURL on a content url does work and you can then use toURL() on the entry object to obtain an asset loader will yield a "valid" https url. This however still doesn't work and is likely a bug inside cordova-android core platform.
Filesystem does have some support for using file APIs against content urls, though permissions may limit the actions you can take on content uri sources, but I've tested the following:

Using the FileReader to obtain a data uri and/or blob will allow you to use the asset in the DOM.
You can also use copyTo (with a caveat) to copy the content from the content filesystem into the local app-data for more persistent access.

First caveat is content urls have a filename that contains a : character which apache file apis deems illegal, so a new file name must explicitly be supplied when using copyTo.
The second caveat is content urls give temporary access. The url cannot be saved to be used later. Once the app exits, the read grants provided to the app is expired, and attempting to read it again will result in a security exception.
But this might actually make the content path usage viable, especially if we can fix the asset loader in cordova-android.

Thank you for the clear explanation, didn't reliaze that the selecting photos from Gallery is broken for API levels 29 and below. I was under the assumption that functionality should still work on devices with 29 and below as READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions were previously only added from 33 and above. Probably then this is an existing issue in the plugin that selecting the files from the external system didn't work. I, myself didn't check this behavior, will check once.
Will wait on #629 to be merged then

Will wait on #629 to be merged then

I don't get the reference to that PR. How is #629 related to fixing the permissions problem?

Will wait on #629 to be merged then

I don't get the reference to that PR. How is #629 related to fixing the permissions problem?

The actual link is https://github.com/apache/cordova-plugin-file/pull/629 (it's a different repo)
And the reason that relates is because this PR will cause content:// urls to be returned instead of file:// urls which Cordova had support for, but it was something infrequently used and it hasn't actually worked properly in quite some time.
https://github.com/apache/cordova-plugin-file/pull/629 makes the content uris consumable by the file plugin allowing you to use toURL() to get a DOM-usable url or any other file APIs to read and/or copy the file content.
We are going to have to add some documentation I think, there are significant differences and applications will have to adapt their usage. For example access to the content:// is temporary and will expire once the app's activity has been closed. Therefore those urls cannot be saved. If you need permanent access then a copy will need to be made. A hypothetical scenario would be letting the user choose a profile pic, you'll want to be able to access that content again in the future, so the image should be copied to the app's internal data storage.

Thanks for the info @breautek. Yeah, I was tricked by the wrong auto-link.
As long as the final URIs work from the WebView (like cdvfile) it totally makes sense to me. I eas already treating the URIs to picked images as "ephemeral" and copying the bytes somewhere else, usually sending to a REST API or storing in a local database.

The deadline set by Google for this change is Oct 31. Is there anything missing for this PR to be merged?

Does this need to be a major version bump for the plugin, since it changes the returned file paths?

It will be included in a 8.0 major release.

Does that change affect older versions of Android as well? (I'm a bit unclear since we're actually lowering the version checks in the code rather than raising them)

The READ_MEDIA_* permissions were API 33+ permissions which I think is the key point.
But tbh I think this is something I want to re-test. Causing looking back now it does seem weird.

Just to get a cordova-wide view of this issue, plugin-file has already merged Content FS support, plugin-media-capture has an open issue with a PR removing the permissions and plugin-camera is here doing the same, right?

plugin-media-capture has an open issue with a PR removing the permissions and plugin-camera is here doing the same, right?

I haven't really kept a close eye on media-capture plugin so I don't know if it's "in-sync" with what the camera plugin is doing. I know there was previous proposals to make the media-capture plugin copy the assets from the content:// store to the app's internal temp directory to avoid permission problems or requiring the READ_MEDIA_* permissions but I think that fell through. This isn't so much a problem for images, but for videos copying the files can be an expensive and lengthy process too.
With the Content FS changes in file plugin (which is currently in the release process and I'm hoping to make a release this week if I can get enough binding votes) it will give the app developers a choice of immediate playback directly from content:// or if they need more persistent access they can choose to copy themselves, depending on the application use cases & needs. I'm not sure if the media-capture plugin has any PR that just simply exposes the content:// path, but that is likely where we want to go for it.

@ravi-yk I think I'm going to fork your PR to extend what you've done even further. This way you're contributions are still credited in the form of a commit.
The reason is I think we can go much further, I've been re-testing things and I think with some more changes we can completely remove all permissions, including the READ/WRITE external storage permission. It would simplify and cleanup a lot of the codebase. I have a working PoC testing API 24 atm.
Is this OK?


Fixed up grammar and syntax in the examples

I just fixed up some of the grammar and syntax in your example questions.

thanks!


Upgrading The Package

Any thoughts of upgrading react-fonticonpicker to the latest-n-greatest of React and all this NPM's dependencies?

Hi,
I planned to rewrite the whole thing. I may have a week free in coming future and will see if I can do a full rewrite.


Changing the shopifyConfig from the menu does not update webhook data

Current behavior

If we have selected shopifyConfig as A and then change the shopify config to B then the webhooks section does not update
Expected behavior

Webhooks data should be updated on changing shopifyConfig
Steps to reproduce the issue

Go to order page
See the status for webhooks
Change the shopify config and see that the webhooks data is not updated

Can you handle fixing this bug by yourself?

[x] YES
[ ] NO

Environment details

Browser:
OS:
Code Version:

Additional information

Verified and working fine in release 2.23.2. Hence, closing it.


Registering PingDevs Educational Center

Registering PingDevs Educational Center

@karadzinov I am sorry, I have to close the request without merging, because this organization is a training center, not a college, nor a university. Please ensure that you are familiar with this repository rules located at the bottom of this page.
Please apply for an appropriate licensing option (which may also be free) at https://www.jetbrains.com/community/education/#courses
Thank you for your understanding!


[core] Method decompilation fails if catch and finally block is empty

Hi,
I did some tests with jadx and try-catch-statements and I found this one:
Method can't be decompiled if catch and finally block is empty.
  public void catchAndFinallyEmpty(final FileInputStream f1) {
    try {
      f1.close();
    } catch (final IOException e) {
    } finally {
    }
  }

Tested with v1.1.0-b1181-cc29da8e and openjdk8
This seems to be a special case, so I think a unit test for this would help.
Thank you!

fixed in latest git version


No longer works on Windows due to wrong directory separator char being used in getNodeModulesPath

Describe the bug
The CLI fails since version 3.0.0 on Windows due to the wrong directory separator char being used in the new getNodeModulesPath function.
To Reproduce
Just execute on Windows.
Expected behavior
Works as before version 3.0.0 on Windows, too.
Screenshots
Error: Failed to invoke license-compliance: 'node_modules' could not be found up the directory tree
Please complete the following information):

OS: Windows 10
Version 3.0.0
Node: any

Additional context
#223 fixes the issue

#223 got merged


Ghost tiles that cannot be moved and disappear on reload

Before:

After:

Not sure if it is a graphic glitch or game state inconsistentcy, because the affected tile disappears if I switch the app e.g. to the browser and back, like happened before I took the 2nd screenshot.
Game export:
2024-07-14-12-36_10068.game2048.json

Hello @gatopeich
Thank you for the report. Yes, I also saw such lost tiles sometimes. These are glitches of the game engine that I use, and I couldn't eliminate them so far.
I hope that some upcoming update of the KorGE (game engine) will resolve the problem magically :-)


Fix antrea-agent crashing with proxyAll enabled in networkPolicyOnly mode

In networkPolicyOnly mode and proxyAll is enabled, the ifindex of antrea-gw0 in nodeConfig
is uninitialized, resulting in the failure to install the ip neighbor to antrea-gw0 due to
the fact that the ifindex of antrea-gw0 is wrong. Additionally, the ipsets storing the pairs
of Node IP and NodePort are not initialized and periodically synced. Consequently, this results
in the failure to sync the iptables rules that referring to the ipsets.

Will add the commit message later.

@tnqn Could you have another look at this PR? Thanks!

@tnqn Could you help have another look at this?

/test-all


[🐛] Sessions are not isolated

Disclaimer
I have not been able to figure out if this is a configuration issue with https://juice-shop.herokuapp.com/ only. If it applies to all Juice Shops, or only the ones deployed to Heroku.
:bug: Bug report
Steps to reproduce

Open incognito mode and go to: https://juice-shop.herokuapp.com/#/score-board

Notice that there are lots of solved challenges

Open https://juice-shop.herokuapp.com/#/score-board on a different PC, mobile, etc, that is not connected to you other account

Notice that the same challenges have been solved here as well

If you leave the page open for a while, you will get fireworks and congratulations. I presume because someone else solved a challenge.
Is this a regression?
The herokuapp has been like this for a while now. (A few months at least.) But it was not like this when I first tried https://juice-shop.herokuapp.com.
My apologies if this is the wrong issue tracker. I could not find out who was responsible for the https://juice-shop.herokuapp.com

JuiceShop is a single user application. Challenge progress is always shared with anyone who has access to the instance.
So this is by design 😊
We have the MultiJuicer project to host isolated JuiceShop instances for multi user settings. https://github.com/juice-shop/multi-juicer

Ah. I thought the official heroku app had made juice shop multiuserfriendly. Since it is public.
Sorry to raise the false alarm


Check accessibility of previews with axe-core npm package.

Description
Use axe-core from npm in Cuprite System tests. I also made sure to update to<EMAIL_ADDRESS>Integration

Does this change require any updates to code in production?

No
Merge checklist

[x] Added/updated tests
[ ] ~Added/updated documentation~
[x] Added/updated previews

Related, https://github.com/primer/view_components/pull/1589
If we switch to playwright, then the https://www.npmjs.com/package/@axe-core/playwright axe-core playwright package might be easier to use?

If we switch to playwright, then the https://www.npmjs.com/package/@axe-core/playwright axe-core playwright package might be easier to use?

Yeah! I'm sure @axe-core/playwright would be pretty much plug and play into a JS playwright setup. This PR plugs better into our existing test infrastructure. I think using playwright directly instead of Capybara is the way to go eventually but I'd prefer to have it implemented in ruby with the existing tests.


Jetson NX SD Card Creation

I feel like I'm probably missing a step somewhere but am unable to boot using the tegra-demo-distro or a custom image built off of meta-tegra.  I am not using mender in either build.  I am building the SD card based on instructions here (https://github.com/OE4T/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit) with the short version of extract tegraflash and use dosdcard.sh.  I'm new to the nvidia stuff but have done some work with oe before, can share additional info on the build if helpful.
The jetson powers on and starts the boot process but logs the following output and drops to limited shell:
Mounting /dev/mmcblk0p1
EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (mmcblk0p1): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs error (device mmcblk0p1): ext4_iget:4591: inode #8 comm mount: checksum invalid
EXT4-fs (mmcblk0p1): no journal found
mount: mounting /dev/mmcblk0p1 on /mnt failed: Invalid argument

So the filesystem for the rootfs is corrupted. After you run dosdcard.sh, I'd suggest running e2fsck -f /dev/sda1 (or whatever the right device name is for partition 1 on the SDcard) to verify it before you eject it from the the writer on your development host.
If it verifies OK on the host, but the kernel on the NX still can't read it, then maybe there's some kind of compatibility issue with the SDcard and the controller on the NX.  What kind of card is it?  You might try swapping in a different one.

It looks like the fs is corrupted when validating on the development/flash host.  I am using a SanDisk Extreme 64GB card but using the stock 16GB layout for now.  I wanted to get to a bootable image before I made too many changes.  Not sure if I have any other types of cards available to test with.
$ sudo e2fsck -f /dev/sdb1
e2fsck 1.44.1 (24-Mar-2018)
Superblock has an invalid journal (inode 8).
Clear<y>? no
e2fsck: The journal superblock is corrupt while checking journal for /dev/sdb1
e2fsck: Cannot proceed with file system check

/dev/sdb1: ********** WARNING: Filesystem still has errors **********

Based on that checked the core-image-sato-dev.ext4  contained in the tegraflash.tar.gz and that looks clean.
$ e2fsck core-image-sato-dev.ext4
e2fsck 1.44.1 (24-Mar-2018)
core-image-sato-dev.ext4: clean, 49581/3670016 files, 1352959/3670016 blocks

The below are config and layer info (can provide commit hashes but should be close to current dunfell head).  For meta-tegra it is dunfell-l4t-r32.4.3.
Layer Info:
layer                 path                                      priority
==========================================================================
meta                  /home/user1/jetson/poky/meta           5
meta-poky             /home/user1/jetson/poky/meta-poky      5
meta-oe               /home/user1/jetson/poky/../meta-openembedded/meta-oe  6
meta-python           /home/user1/jetson/poky/../meta-openembedded/meta-python  7
meta-filesystems      /home/user1/jetson/poky/../meta-openembedded/meta-filesystems  6
meta-networking       /home/user1/jetson/poky/../meta-openembedded/meta-networking  5
meta-virtualization   /home/user1/jetson/poky/../meta-virtualization  8
meta-tegra            /home/user1/jetson/poky/../meta-tegra  5
contrib               /home/user1/jetson/poky/../meta-tegra/contrib  4

local.conf, in general this should be at defaults and overrides added at the end of the file.  the wks file was from the ridgerun wiki and is not being used but hasn't been pulled out yet.
IMAGE_CLASSES += "image_types_tegra"
WKS_FILE="jetson-sdcard.wks"
IMAGE_FSTYPES = "tegraflash tar.gz wic.gz wic.bmap"
TEGRA_ROOTFS_AND_KERNEL_ON_SDCARD = "1"
ROOTFSPART_SIZE = "15032385536"

PREFERRED_VERSION_python3 = "3.8%"
PREFERRED_VERSION_python3-native = "3.8%"

# older version of gcc for cuda
GCCVERSION = "8.%"

require conf/include/gstreamer-1.14.conf

MACHINE = "jetson-xavier-nx-devkit"
DISTRO_FEATURES_append = " x11 opengl ldconfig virtualization"
EXTRA_IMAGE_FEATURES += " tools-sdk"
IMAGE_INSTALL_append = " cuda-samples cudnn tensorrt gstreamer1.0-plugins-nvvideo4linux2 deepstream-5.0"
IMAGE_INSTALL_append = " nvidia-docker nvidia-container-runtime cudnn-container-csv tensorrt-container-csv libvisionworks-container-csv"


[Table] Refactor and extra features

Feature
As part of the Mailbox Rewrite, we take a look at our current Table component and bring some features to make it usable as a suitable ConvoList.
Changes
Refactor
While adding the select row feature, performance issues became a problem and for this reason I refactored the table to use Hooks, specifically wanting to use memoization and useReducer.
Access to nested data in columns
While inspecting the data in the current list, I noticed that some of it was nested, ie:
customer: {
	name: 'Ringo',
	email<EMAIL_ADDRESS>}

We can now access this data by providing columnKey a dot notation string, for example:
const columns = [
	{
    	title: 'Customer',
    	columnKey: ['customer.name', 'customer.email'],
	}
]

If using a customized cell rendering, you get access to this data by replacing the dot . with an underscore _:
renderCell: ({ customer_name, customer_email, row }) => ( // replace . with _

          {customer_name}

          {customer_email}

      ),

renderCell now also gives you access to the row data in case you need it.

Selecting rows
We add the ability to select rows, with the following props:

withSelectableRows: Enable the feature
selectKey: A unique key from your data to identify selection, defaults to id
onSelectRow: Callback that gives you an array of selected items (by the key provided in selectKey which by default is id)

This feature includes select / unselect all items from the checkbox in the table header row.
🎥 https://c.hlp.sc/L1uBqEGl
Focusable Rows
We add the prop withFocusableRows, which simply adds a tabindex = 0 to each row so you use can tab to navigate them, and if onRowClick is provided, execute the action on enter
Conditional class names for Rows
If you need to add a class name to a row based on a condition, you can do it with rowClassName:
rowClassName={row => {
	return {
  	[CONVO_STATUS_CLASSNAMES[row.status]]: true,
  	replying: row.id === 281796231,
  	viewing: row.id === 281796229,
	}
}}

From the function you can return anything classnames accepts, like a string or an object.
Wrapping rows
Sometimes you might need to wrap a row or add attributes to it based on certain conditions, for this we have added the prop rowWrapper. Works like this:

// children: the "row" react component (Table.Row)
// The data for this particular row
rowWrapper={(children, row) => {
  if (row.id === 281796231) {
	// Wrap with a `Popover`
    return (
      <Popover
        triggerOn="mouseenter"
        appendTo={() => document.body}
        withTriggerWrapper={false}
        placement="left"
        renderContent={() => (
          <Avatar
            size="xs"
            name={AvatarSpec.generate().name}
            image={AvatarSpec.generate().image}
          />
        )}
      >
        {
			// Add a `title` attribute on the row
			React.cloneElement(children, {
	          title: 'Someone is replying',
    	    })
		}
      </Popover>
    )
  }
  return children
}}

Note that while you can technically wrap the Row with any element, you are dealing with a
 and generally they don't like to be inside other stuff (like a span for example)
ConvoList story
We include a new story, which is basically a reproduction of the ConvoList, ideally we can use this as a pretty complete base to use in HS App's Mailbox Rewrite.
Visit: https://deploy-preview-958--hsds-react.netlify.app/?path=/story/components-structural-table--selecting-rows

Doesn't include sorting at the moment

Other
Checkbox
Just noticed that class names passed to it weren't being applied. Fixed.
Design
Design is not 100% there yet as I focused on features and I think design decisions for the ConvoList might not be finalized yet.
Tests
Updates and adds a bunch of tests
Next
Most likely there will be more features or tweaks to be done to Table but the aim of this PR is to enable the usage of it asap and we can iterate as needed, so to merge this PR we don't need this to be "complete".

@digitaldesigner Would you mind taking a look please?

Looking great. Couple additional things to consider here:

Entire rows should be clickable (i.e. to get to the conversation) in addition to being selectable
Row hover/tab-focus state (soft gray?)
Consider how the customer name will overflow when it is a super long email address
Thread count
The ability to cap the conversation preview to just one line of text and overflow with a soft shadow (as we do in the main convo list today)
Ability to replace the select box with an icon, so that we could use this component in the Customer / Profile / Conversations table

@digitaldesigner Thanks! I made several updates, getting there I think, the one I don't understand is the last one, can I see an example?

@tinkertrain I think Buzz is referring to how we can show an icon next to the conversation here:

@cen10 @buzz Ah, that is already possible as you can add columns as you see fit and render whatever you want in them

@plbabin Nice pattern, I've refactored the reducer into something very similar to that. Thanks!

@cen10 I've updated the "ConvoList" code to make it easier to follow what is going on, let me know if you have any suggestions or questions on anything you find in there, my hope is eventually we can take that almost as is and bring it in and just tweak as needed.

Ah PL has a GREAT point about QAing the customer list page.

Please stop mentioning me in this issue. Thank you very much


component api: authentication types

Currently it's only possible to configure authentication for cryptosign and wampcra methods using the component API; the others should be added as well.

This API is actually perfect for a project I'm on now.  I'm using TOTP and TOKEN based authentication methods currently.

subseded/fixed in https://github.com/crossbario/autobahn-python/issues/964


Build error "error: linking with cc failed: exit code: 1"

My system:
$ rustup show

1.27.1-x86_64-apple-darwin (default)
rustc 1.27.1 (5f2b325f6 2018-07-07)

Cargo.toml:
[dependencies]
slotmap = "*"

main.rs:
extern crate slotmap;
use slotmap::SlotMap;

fn main() {
    let mut sm = SlotMap::new();
    let foo = sm.insert("foo");  // Key generated on insert.
    let bar = sm.insert("bar");
    assert_eq!(sm[foo], "foo");
    assert_eq!(sm[bar], "bar");
}

The error:
$ cargo build
   Compiling slotmapthing v0.1.0 (file:///Users/peter/dev/rust/learning/slotmapthing)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-m64" "-L" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.16u6js6g0l3k1ic6.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.181cuta0v63atwcm.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.1im38lueib99jsk0.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.1jnlhyxj59jycbjv.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.1q8ffos2d96smbjs.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.1y16o1qfye96o7m0.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.1zeawhkbeobww1zn.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.23tqyymcb18u96mb.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.2jqywn86b2gsqohu.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.2lyh15q6cjwzy18c.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.3171x0bwu82dptu7.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.3ayaeypdcro9d6yk.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.3ooa3xxhuf308lo4.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.3oqznv5oym7l3m4e.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.3rngp6bm2u2q5z0y.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.3wta9ctgdrpkmlpr.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.3y74nu12zm0rsdqe.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.436dotimmrgzkwfa.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.49a7n47po4ttqjl7.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.4oc10dk278mpk1vy.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.4xq48u46a1pwiqn7.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.4yh8x2b62dcih00t.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.4ypvbwho0bu5tnww.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.8xzrsc1ux72v29j.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.98g0d9x8aw3akpe.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.9elsx31vb4it187.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.oa3rad818d8sgn4.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.y08g5q2x813c4wx.rcgu.o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.z9ox7biyn1otfln.rcgu.o" "-o" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/slotmapthing-141b01f9927061d7.crate.allocator.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps" "-L" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/peter/dev/rust/learning/slotmapthing/target/debug/deps/libslotmap-ae91ece515cc63bc.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-5a05d0933700ddb1.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libunwind-64fd20ce4af6fbad.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_system-2c5b1969da7ded68.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-c80953af6722fea1.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-2ed0d380199e717d.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-8c87fbf7e0bce62b.rlib" "/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-9b97130153f6d410.rlib" "-l" "System" "-l" "resolv" "-l" "pthread" "-l" "c" "-l" "m"
  = note: ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(jemalloc.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(jemalloc.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(state.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(state.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(fileline.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(fileline.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(arena.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(arena.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(base.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(base.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(chunk.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(chunk.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(chunk_dss.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(chunk_dss.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(ctl.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(ctl.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(huge.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(huge.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(mutex.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(mutex.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(util.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(util.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(tsd.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(tsd.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(tcache.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(tcache.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(stats.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(stats.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(pages.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(pages.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(prof.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(prof.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(quarantine.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(quarantine.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(witness.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(witness.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(alloc.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(alloc.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(macho.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(macho.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(posix.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(posix.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(bitmap.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(bitmap.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(chunk_mmap.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(chunk_mmap.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(ckh.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(ckh.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(extent.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(extent.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(nstime.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(nstime.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(rtree.pic.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-3913d194bc6184af.rlib(rtree.pic.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(dwarf.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(dwarf.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(read.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(read.o)) was built for newer OSX version (10.7) than being linked (8.0)
          ld: warning: URGENT: building for iOS simulator, but linking in object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(sort.o)) built for OSX. Note: This will be an error in the future.
          ld: warning: object file (/Users/peter/.rustup/toolchains/1.27.1-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-73671a9242f94467.rlib(sort.o)) was built for newer OSX version (10.7) than being linked (8.0)
          Undefined symbols for architecture x86_64:
            "_opendir$INODE64", referenced from:
                _macho_try_dsym in libstd-73671a9242f94467.rlib(macho.o)
                _macho_add in libstd-73671a9242f94467.rlib(macho.o)
            "_readdir$INODE64", referenced from:
                _macho_try_dsym in libstd-73671a9242f94467.rlib(macho.o)
                _macho_add in libstd-73671a9242f94467.rlib(macho.o)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

error: Could not compile `slotmapthing`.

I don't use C/C++ but it seems that XCode has changed the global configuration of my gcc because I recently compiled an iphone project.
$ gcc --version
Configured with:
    --prefix=/Applications/Xcode.app/Contents/Developer/usr
    --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.4.sdk/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-9<IP_ADDRESS>)
Target: x86_64-apple-darwin17.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Never mind. This just happened to be the first project I created since working with iOS in XCode. XCode has broken all Rust projects.


Feature/126 accordion table sort and group no value fields

Types of Changes
Prerequisites
Please make sure you can check the following two boxes:

[x] I have read the CONTRIBUTING document
[x] My code follows the code style of this project

Contribution Type
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
[x] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
[x] Breaking change (fix or feature that would cause existing functionality to change)
[x] My change requires a change to the documentation
[x] I have updated the documentation accordingly
[x] I have added tests to cover my changes
[x] All new and existing tests passed

Description
See #126.

fix sorting of items that don't have a value for the sortBy/groupBy column
change order of items so that items without a value are moved to the end of the list
AccordionTable:

add a separate pseudo-group for items that don't have a value for the groupBy column
add an optional prop to define the label for this new pseudo-group

change sorting for values of type number so that 0 isn't handled as falsy anymore but instead is sorted and grouped like other numbers

Breaking changes: At the moment the handling of Tables with items that don't have a value defined for the sortBy/groupBy column isn't working correctly so I assume that most people don't have not-defined values in their data. However, as this PR changes the way not-defined values are handled in theory it could change the behaviour of existing apps that depend on the (wrong) sorting and grouping of not-complete items.

Hi @lestard, thanks for this PR. There are a few issues with it though:

You should use a long dash (—) instead of a short dash (-) on case of an empty group without a name. (In the code, they all look the same, but render differently in the browser).
Elements with value "0" should not be included in the empty group because this may cause undesired behaviour.
IMO, I believe empty arrays should also be included in the empty group and, as of now, they are being included to their own not name group.
The groups also show as the first on the table when there is an empty array in the list.

Thank you :)
Hoping to see the fixes soon,
Sorry for the late review.
Gui.


Unable to add account via 'Accounts' after reinstall

Version: 1.36.1 (user setup)
Commit: e56e1d931bbb110fe8f24751423c4e184bb8f22d
Date: 2022-04-21T21:25:10.399Z
VS Code: 1.59.0
Electron: 13.6.6
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19044

When trying to add an Microsoft account, the application gets stuck in the 'loading accounts'. I am still able to close this accounts window.
Steps to Reproduce:

Reinstall Azure Data Studio
Click on 'Accounts' in left corner

Does this issue occur when all extensions are disabled?: Yes

Closing as sufficient logs have not been provided. @Thijs9955 please feel free to re-open this if you are able to attach some more logs.

Unfortunately I cannot do that anymore. To fix the issue I reinstalled windows and Azure Data Studio. This fixed the issue.
Van: github-actions[bot] @.>
Verzonden: vrijdag 6 mei 2022 22:18
Aan: microsoft/azuredatastudio @.>
CC: Thijs van Berkel @.>; Author @.>
Onderwerp: Re: [microsoft/azuredatastudio] Unable to add account via 'Accounts' after reinstall (Issue #19213)
We need more info to debug your Azure Active Directory issue. If you could attach your logs to the issue (ensure no private data is in them), it would help us fix the issue much faster.

In the settings menu, find the setting titled Azure: Logging Level and select the Verbose option
Run the process that produces your error
Open command palette (Click View -> Command Palette)
Run the command: Developer: Open Logs Folder
Follow this path to find the Azure Accounts log file: [default log folder]/exthost1/output_logging_[earliest timestamp]/#-Azure Acounts.log
Please attach the Azure-Accounts.log file to the issue.

—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/azuredatastudio/issues/19213#issuecomment-1119979398, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AY4VNGUDCVKXEAIY7VHFKKTVIV46TANCNFSM5ULBOEFA.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>


Greeks

Sorry, I don't think this is an issue, but I was wondering/looking for Greeks?
The classes look nice (especially nice to see someone include lattice pricing), but is there any Greek functions (like get.delta)?
Thank you,
-Richard

Sorry, I am not currently working on this project.
Still, it's super welcomed if you would like to send a pull request.
Good Luck!

Yang Yuhao
-----原始邮件-----
发件人:foobash @.>
发送时间:2021-03-23 01:42:00 (星期二)
收件人: QSCTech-Sange/option-price @.>
抄送: Subscribed @.***>
主题: [QSCTech-Sange/option-price] Greeks (#3)
Sorry, I don't think this is an issue, but I was wondering/looking for Greeks?
The classes look nice (especially nice to see someone include lattice pricing), but is there any Greek functions (like get.delta)?
Thank you,
-Richard
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Register store consumers outside of useEffect

Store consumers render function must be registered synchronously outside of react useEffects

Done.


Show Synapses and All Synapses is indeterminate when creating new network.

Describe the bug
When a new network is created the All Synapses checkbox remains as it is, but the network is drawn in an indeterminate state where show synapses is concerned.
Application: Brain Simulator
Module/Network: new network
To Reproduce
Steps to reproduce the behavior:

Open any network.
Check the All Synapses checkbox.
Select New Network.
Check random synapses and click OK.
Notice All Synapses checkbox active, and notice the pattern.
Uncheck the All Synapses checkbox and notice pattern does not change (some neurons show synapses).
Check the All Synapses checkbox and notice pattern becomes more crowded (now all synapses show).
Select the entire field, and edit show synapses in the Neuron popup menu (maybe twice, to uncheck it).
Now field is clear, and this should be a valid start state.

Expected behavior
I would expect to get a new network, with random synapses and "Show Synapses" for all neurons set to false, and the shown state according to "All Synapses" (On or off I don't care, as long as it is consistent).
Screenshots
If applicable, add screenshots to help explain your problem.
Immediately after new, when "All Synapses" was set:

After "All Synapses Cleared", some neurons still show synapses:

After "All Synapses" set again, pattern definitely changed, more busy:

Desktop (please complete the following information):

OS: Windows 10 Pro  20H2
Version 2021-04-14 master

Add any other context about the problem here.

Works fine in the 2021-04-15 #2 master


Why is codegen for /ef/publish in tests using a nested container?

Figure out why the codegen for that route is using a nested container and try to stop that

Nevermind. Verified as fixed. Not sure what was happening before.


python: skip redaction in column lineage facet

Problem
Fields in ColumnLineageDatasetFacetFieldsAdditionalInputFields are redacted.
Solution
Add  fields to be skipped.
Checklist

[x] You've signed-off your work
[x] Your pull request title follows our guidelines
[ ] Your changes are accompanied by tests (if relevant)
[x] Your change contains a small diff and is self-contained
[ ] You've updated any relevant documentation (if relevant)
[ ] Your comment includes a one-liner for the changelog about the specific purpose of the change (if necessary)
[ ] You've versioned the core OpenLineage model or facets according to SchemaVer (if relevant)
[ ] You've added a header to source files (if relevant)

SPDX-License-Identifier: Apache-2.0
Copyright 2018-2023 contributors to the OpenLineage project

Codecov Report

Merging #2177 (4fbda26) into main (0702a9c) will increase coverage by 2.12%.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@             Coverage Diff              @@
##               main    #2177      +/-   ##
============================================
+ Coverage     80.98%   83.10%   +2.12%
============================================
  Files            90       41      -49
  Lines          3792     2078    -1714
  Branches         33        0      -33
============================================
- Hits           3071     1727    -1344
+ Misses          682      351     -331
+ Partials         39        0      -39

see 49 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Multi-type viewholder in concrete position support

I’m searching library for multi type viewholder adapter and I found your library. It looks promising so I have question if it is possible to do with your library.
Now I have adapter with a lot of different view types.
For example: A, B, C views, but those views should be in concrete different position in list.
For example:
A - in header (position 0),
B -  in he middle  and in the end of list (in 15 position if list size > 30 and  always in the end)
and C - in the other position of the list.
Now the logic is complex and I want simplify this part. I searched for some examples of your library but I didn't completely understand if it is possible.
So if it is possible to do with you library if I need to create different “ItemAdapter” for each views? But how I could specify concrete item position for each “item adapter” ?
Thanks for any help!

@AllanWang Thanks for answer. The views are different so I think the best option would be to use different adapters.

@ebabenskas theoretically you can also have a generic adapter which will just handle all items type of IItem you simply have to cast then in the listeners for example


readme updates to basic and car auction

 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.


When will go-sdk release actor example?

In what area(s)?
/area test-and-release
Ask your question here
When will go-sdk release actor example?
I already study dotnet-sdk and java-sdk,But I still don't know what to write actor in go-sdk?

@leenux Currently dapr team is focusing on creating actor framework for dotnet, java. Python is in the works. We will do go actors in future but no firm ETA at the moment. We would be happy tow ork with you if you want to contribute and create a go sdk for actors.
cc @msfussell

Thank you @amanbha


Grammar needs to support 'async'/'await' keywords

Ported from https://github.com/Microsoft/TypeScript-Sublime-Plugin/issues/374

Closed by #20 thanks to @ejsmith.