Multiple gettys fighting over tty1/console

Version (k3OS / kernel)
v0.11.0-rc1
Architecture
amd64
Describe the bug
When attempting to log in to the console, username/password input does not appear to be recognized properly. If you hit return repeatedly without entering username or password, the prompt alternates between /dev/ttys1 and /dev/console every time you hit return.
To Reproduce
Install k3os from ISO, wait for host to reboot to login prompt.
Expected behavior
Able to log in to system
Actual behavior
Cannot log in.
Additional context
This worked properly under v0.10.3 so it appears to be a recent issue. If you hit ctrl-alt-f2 and switch to tty2 you can log in fine.

Getting something similar myself.  When booted i get two login prompts one for /dev/console and /dev/tty1 .

When you login accepts username
hit enter gives you password prompt
enter password and hit enter
the password you entered then is printed on screen and you are give a 2nd password prompt
typeing and hitting enter does nothing
after 60 seconds you get a time out and prompt for /dev/console comes back up
a second or two latter you get a 2nd timeout and the /dev/tty1 login shows up

Screenshots:
login screens at boot:

Screen when trying to login:

Going to tty2 (ctrl-alt-f2) allows me to login correctly

If you login to the box with tty2 (ctrl-alt-f2) and as root edit /boot/grub/grub.cfg
change this line:
linux (loop0)/vmlinuz printk.devkmsg=on console=tty1 console=console
to this:
linux (loop0)/vmlinuz printk.devkmsg=on console=tty1
it will stop loading both and only load tty1 allowing you to login as normal
At least this is what worked for me

I think this issue is related to the changes made by https://github.com/rancher/k3os/pull/504


build: Update common-jvm dep for Maven BOMs

This change is

Depends on world-federation-of-advertisers/common-jvm#268


[BUG] Visual Studio Credential looking for tokenprovider.json file at wrong file path

Library name and version
Azure.Identity 1.10.4
Describe the bug
running a dotnet 8 Native AOT application configured to build for docker support on linux x64 systems. When running locally in Windows 11 Visual Studio 2022 an exception is throw by the visual studio authentication provider with the below message:
IO_PathNotFound_Path, /home/app/.IdentityService/AzureServiceAuth/tokenprovider.json

I found this PR: https://github.com/Azure/azure-sdk-for-net/pull/33556/files which seems to address this issue but i'm assuming there is a bug with how RuntimeInformation.IsOSPlatform works with set configurations for Native AOT applications.
Here is my csproj file configuration for native aot:
<Project Sdk="Microsoft.NET.Sdk.Web">

	<PropertyGroup>
		<TargetFramework>net8.0</TargetFramework>
		<Nullable>enable</Nullable>
		<ImplicitUsings>enable</ImplicitUsings>
		<InvariantGlobalization>true</InvariantGlobalization>
		<PublishAot>true</PublishAot>
		<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
		<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
		<OutputType>exe</OutputType>
		<DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
		<EventSourceSupport>false</EventSourceSupport>
		<UseSystemResourceKeys>true</UseSystemResourceKeys>
		<StripSymbols>true</StripSymbols>
		<OptimizationPreference>Speed</OptimizationPreference>
		<Platforms>x64</Platforms>
	</PropertyGroup>

Expected behavior
Expect it to correctly detect that i'm running on a windows system even when the contain is being executing inside of a docker desktop app to find the file it requires.
Actual behavior
It is looking for the token provider on a linux file path and not a windows file path and will never work like this.
Reproduction Steps
create a new Dotnet 8 native aot application building for linux with linux docker support running on docker desktop on a windows 11 machine.
builder.Configuration.AddAzureKeyVault(
    new Uri(settings.AzureKeyVaultUrl),
    new DefaultAzureCredential(
        new DefaultAzureCredentialOptions { TenantId = settings.AzureTenantId, VisualStudioTenantId = settings.AzureTenantId, IsUnsafeSupportLoggingEnabled = true}),
    new KeyVaultSecretReplacer(builder.Configuration));

Environment
dotnet --info
.NET SDK:
Version:           8.0.200
Commit:            438cab6a9d
Workload version:  8.0.200-manifests.e575128c
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.22631
OS Platform: Windows
RID:         win-x64
Base Path:   C:\Program Files\dotnet\sdk\8.0.200\
.NET workloads installed:
[maui-windows]
Installation Source: VS 17.9.34622.214
Manifest Version:    8.0.6/8.0.100
Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maui\8.0.6\WorkloadManifest.json
Install Type:        FileBased
[maccatalyst]
Installation Source: VS 17.9.34622.214
Manifest Version:    17.2.8004/8.0.100
Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maccatalyst\17.2.8004\WorkloadManifest.json
Install Type:        FileBased
[android]
Installation Source: VS 17.9.34622.214
Manifest Version:    34.0.52/8.0.100
Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.android\34.0.52\WorkloadManifest.json
Install Type:        FileBased
[ios]
Installation Source: VS 17.9.34622.214
Manifest Version:    17.2.8004/8.0.100
Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.ios\17.2.8004\WorkloadManifest.json
Install Type:        FileBased
Host:
Version:      8.0.2
Architecture: x64
Commit:       1381d5ebd2
.NET SDKs installed:
8.0.200 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.27 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.27 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:
x86   [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

//cc @NCarlsonMSFT

@funkel1989 If I understand you're repro correctly, you're running an app published using AOT in a linux container through the Visual Studio container tools. Is that correct?
If so, it's an expected shortcoming of the way the token proxying from VS works that it doesn't support containers that don't have the .NET runtime installed (for instance the runtime-deps base image used by an AOT project). I have posted an example with a work-around that swaps out the base image when debugging in VS to add the needed .NET runtime and the GDB debugger: https://github.com/NCarlsonMSFT/VisualStudioCredentialExample/commit/b36d0fe216622dbec3049e3f9da8686759a5c8de. Does that unblock you?

@NCarlsonMSFT I made the changes shown in your commit and didn't seem to get any further in this process. For clarity I'm trying to solve this as another potential solution to handling secrets locally for a team of developers where I've built a secret replacer and they can access an azure keyvault with permissions granted via the account they have used to log into visual studio with.
You are correct that I am running a AOT app published to a Linux container through Video Studio Container Tools. My local workstation running visual studio is a windows 11 machine. When the DefaultCredential attempts to authenticate I get 7 internal exceptions. The third one is always regarding the Visual Studio token provider and always has a message of:
Visual Studio Token provider can't be accessed at /home/app/.IdentityService/AzureServiceAuth/tokenprovider.json

Inner Exception Message: IO_PathNotFound_Path, /home/app/.IdentityService/AzureServiceAuth/tokenprovider.json

Its looking for this file (which does exist on my local machine) in a directory inside of the container in which it is running instead of the host machine. Thinking about this more... this is probably intended and the way I'm attempting to go about this may not be supported now or ever. It doesn't seem like the runtime dep container is missing anything as adding the aotdebug container made no changes in the way it operated.

@funkel1989 looking for the file in the container is the expected behavior, when debugging from Visual Studio it starts a service that generates the config file in the container and orchestrates proxying communication with the launching visual studio for authentication (docs).
Some more clarifying questions:

Are you running your container from VS (F5 or Ctrl+F5) or publishing and then running the image? The token proxy is only inserted when run from VS (17.6+).
Are you running your container in Fast mode or Regular mode? If you haven't set ContainerDevelopmentMode the default is Fast for the Debug Configuration, Regular for all other Configurations.
If you set the environment variable MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED to 1 before launching VS and check the logs in  %tmp%\Microsoft.VisualStudio.Containers.Tools, do you see any errors from the token proxy?
If you docker exec into your container, what is the output from dotnet --info ?


Corrections to Townsend snow model

Private communications with the model's author have turned up some issues with the pvlib implementation. Chief among the issues is  this part of the calculation:
    lower_edge_height_clipped = np.maximum(lower_edge_height, 0.01)
    gamma = (
        slant_height
        * effective_snow_weighted_m
        * cosd(surface_tilt)
        / (lower_edge_height_clipped**2 - effective_snow_weighted_m**2)
        * 2
        * tand(angle_of_repose)
    )

    ground_interference_term = 1 - C2 * np.exp(-gamma)

When lower_edge_height_clipped < effective_snow_weighted_m, gamma < 0 and the ground_interference_term can become negative. In contrast, the author's intent is that C2 < ground_interference_terms < 1. The author recommends clipping the squared difference (lower bound being worked out but will be something like 0.01.).
Other issues appear to arise from the unit conversions. The published model uses inches for distance and snow depth. The pvlib code uses cm for snow depth (convenience for working with external snow data) and m for distances (for consistency with the rest of pvlib). After several steps, including the ground_interference_term calculation, the code converts from cm or m to inches to apply the final formula for loss (since the formula involves some coefficients determined by a regression). It would be easier to trace the pvlib code back to the paper if the internal unit conversions (from cm / m to inches) were done earlier.

Interestingly, clamping the difference of squares at 0.01 was part of the original PR but got lost along the way: https://github.com/pvlib/pvlib-python/pull/1251#discussion_r830258000
It would be great if the communication with the author results in improved tests as well as improved code.

After communications with the author, the pvlib code is missing two items:

a lower bound on lower_edge_height_clipped**2 - effective_snow_weighted_m**2 which the author specifies should be 0.1 in^2.
a factor that multiplies the monthly loss fraction, to represent the potential for a string of modules at the top of the slanted array to generate power while strings at lower positions are still affected by snow.  This factor was brought up in #1625

Neither is documented in the 2011 paper but should be added to 1) prevent unreasonably low loss values (item 1) and to better represent the loss for systems with multiple, horizontally-oriented strings.
Also, the author recommends advising users to enter 1/2 the total module width as the slant_height for single-axis tracked systems, which makes sense to me, as snow could slide off either surface depending on its rotation.

@cwhanse . Thank you. It was very  helpful.


Custom Slot "Rest of the Sentence"

Hello,
First of all, congrats for this great NLU engine!
I was wondering if there is a way to configure a custom slot so that it captures everything that is unmatched at the end of a sentence.
Thank you!

Hello @ea167 ,
There is no particular option to do that, but if your intent is structured enough, this should work automatically, provided you have marked the entity as automatically_extensible.
For instance, let's say you want to create a simple Reminder intent with a single action slot that can take any value:
---
type: intent
name: Reminder
utterances:
- Remind me to [action](go to the gym)
- remind me to [action](take an umbrella)
- remind me to [action](walk the dog tonight)
- could you remind me to [action](call my mom)
- please remind me to [action](go to my appointment)

---
type: entity
name: action
automatically_extensible: yes

Because the utterances are well structured around the "remind me to" chunk, the NLU will be able to generalize very well to any value.
This is an extreme case where the pattern of the intent is strong. In general, for a fix dataset size, the more structured the intent is, and the better the parsing accuracy will be. In order to reach good parsing accuracy for intents without a strong structure, you will have to provide more utterances.
I hope this helps.

Thank you very much Adrien @adrienball! I'll try it right now.
Would a configuration with matching_strictness: 0.0
help, or won't it change much?

You don't need to change the default matching_strictness if your entity is configured with automatically_extensible: yes.

Thank you Adrien!
It works pretty well, congrats!
One surprising element in this particular case is the need to provide a value, otherwise we get the exception: snips_nlu.exceptions.DatasetFormatError: At least one entity value must be provided for entity 'AnythingSlot'
The "Reminder" is a great use case, another would be a search (to retrieve an element about XXX, etc.)
An interesting point that I found out during my tests: commands are robust to a lot of variations in English, except the -ing for verbs. When you input "searching..." instead of "search...", the intent is not recognized.
Hope it helps!
Thanks again for this great NLU engine!

Thanks for the feedback :)
Regarding your experience with "-ing" variations not working, it can be addressed by modifying the default configuration used by the NLU engine.
The default configuration used in English can be found here: https://github.com/snipsco/snips-nlu/blob/master/snips_nlu/default_configs/config_en.py
As you can see, it's pretty big and a bit opaque, but there is "use_stemming" field in "tfidf_vectorizer_config" which is set to False:
{
    "unit_name": "featurizer",
    "pvalue_threshold": 0.4,
    "added_cooccurrence_feature_ratio": 0.0,
    "tfidf_vectorizer_config": {
        "unit_name": "tfidf_vectorizer",
        "use_stemming": False,  # Allow to enable or disable stemming for intent classification
        "word_clusters_name": None
    },
    "cooccurrence_vectorizer_config": {
        "unit_name": "cooccurrence_vectorizer",
        "window_size": None,
        "filter_stop_words": True,
        "unknown_words_replacement_string": None,
        "keep_order": True
    }
}

With this configuration, words are not stemmed in the intent classification step. We made this choice for the default config, as English has typically few variations compared to other languages and we found that overall disabling stemming worked better.
If you find that stemming is relevant for your use case, here's a simple way to provide a custom configuration with stemming enabled:
from copy import deepcopy

from snips_nlu import SnipsNLUEngine
from snips_nlu.default_configs.config_en import CONFIG as CONFIG_EN

config_with_stemming = deepcopy(CONFIG_EN)  # Make a deepcopy to avoid changing the default config globally
config_with_stemming["intent_parsers_configs"][1]["intent_classifier_config"][
    "featurizer_config"]["tfidf_vectorizer_config"] = True

nlu_engine = SnipsNLUEngine(config=config_with_stemming)

You can also create your own NLUEngineConfig from scratch by checking the documentation here.
Cheers

Wonderful, thank you Adrien!


PlatformException(500, Attendees cannot be changed., null)

in android simulator app is working fine,
but when i test it in ios simulator without attendees is working fine but when i add  attendees it showen exception,
[599] Device calendar plugin ran into an issue. Platform specific exception [500], with message :Attendees cannot be changed., has been thrown.

Is this with an event that was created through the plugin?
What account type is it (office365, Gmail etc) and what device type (iOS or Android)?

Is this with an event that was created through the plugin? => yes i have used plugin  device_calendar: ^3.1.0
its iphone inbuild calendar. List of calendar screen i selected Calendar named and i have also checked is not read only

i have also try to make demo app from your github example, same issues face in ios device.

i have again try to copy example from https://github.com/builttoroam/device_calendar/tree/develop/example. but face same issues

[599] Device calendar plugin ran into an issue. Platform specific exception [500], with message :Attendees cannot be changed., has been thrown.

@jayeshpansheriya Does everything work fine with 4.x version!?

nop still an opened issue.
I'm facing same error.

I think I saw it too, but since I could add events just fine I didn't think it was important.
Is there any notable problem when handling attendees on iOS? Or is the only issue the warning in console (ie not urgent to fix)?

I think it's because https://developer.apple.com/documentation/eventkit/ekparticipant: EventKit cannot add participants to an event nor change participant information. Use the properties in this class to get information about a participant.

Halo, I'm facing same issue with device_calendar: ^4.2.0, is any update to this issue?

We should have new ways to handle attendants properly now
And the demo has included the new iOS specific popup for attendants

Still facing the same problem. Running on device_calendar 4.2.0.

Dug into this a bit and found a possible workaround here:
https://stackoverflow.com/questions/30627694/modifying-ekparticipants-attendees-in-eventkit-like-sunrise
I'll see what I can do with the information in the link, but since I am but an amateur don't wait for it...

I am facing a similar issue. I'm not updating the attendees. But I am trying to update an event that I have created using the plugin. The functionality works as expected on iOS but returns the following error on Android device. The android device I am using is OnePlus Nord 2.
PlatformException(500, Attempt to invoke virtual method 'int java.lang.Integer.intValue()' on a null object reference, null, null)
Device calendar plugin ran into an issue. Platform specific exception [500], with message :"Attempt to invoke virtual method 'int java.lang.Integer.intValue()' on a null object reference", has been thrown.
Following is my json of event data:
{calendarId: 1, eventId: 833, eventTitle: Appointment, eventDescription: , eventStartDate:<PHONE_NUMBER>000, eventStartTimeZone: Asia/Kolkata, eventEndDate:<PHONE_NUMBER>000, eventEndTimeZone: Asia/Kolkata, eventAllDay: false, eventLocation:  Eiffel Tower, eventURL: null, availability: BUSY, eventStatus: null, reminders: [{minutes: 60}]}

I have the same issue by replacing the code below in CalendarDelegate.kt fixed the problem.
private fun getEventStatus(eventStatus: EventStatus?): Int? = when (eventStatus) {             EventStatus.CONFIRMED -> Events.STATUS_CONFIRMED     EventStatus.TENTATIVE -> Events.STATUS_TENTATIVE     EventStatus.CANCELED -> Events.STATUS_CANCELED     else -> 0 }

Submit a PR and I'll merge it :)

@thomassth  Is this issue has been resolved or not yet? I was trying in the Ios 17 emulator and I faced the same issue.

I also had the same issue. I solved it by adding eventStatus value when updating the event. If eventStatus is something other than these values: EventStatus.CONFIRMED , EventStatus.TENTATIVE ,EventStatus.CANCELED  it is not working because the getEventStatus is not returning value in else as @FelixYew  has mentioned above about replacing it.

The same issue happens to me on Android real device while updating the existing event. Suggested workaround of setting up EventStatus.CONFIRMED works for me.


Is it possible to determine the field that matched a query?

For example, if a search entry has summary and content fields, could is it possible to determine which of the fields matched a given query without searching the individual fields again?

I'd like to know the answer to this too.

Right now, its not possible.
I'm not against adding such a feature, I think currently it is not trivial to add this functionality, also I have a couple of changes I'd like to make to how results are returned/generated by lunr.
I'll definitely keep this feature in mind when re-working the results from a search.

Thanks for the feedback, @olivernn.


Redirect::back() no longer works

Hi! After updating to the latest inertia js. I am having problems with a redirect back. getting 404 error pop up due to XHR of axios. Is anyone experiencing this problem as well?
is Redirect::back() no longer supported? coz looking at the documentation it only state Redirect::route()

Have you setup the new Inertia middleware? See here.

Have you setup the new Inertia middleware? See here.

Finally got it working. Thank you!

Finally got it working. Thank you!


[KYUUBI #6101] Bump Jackson from 2.15.0 to 2.15.4

:mag: Description
Issue References 🔗

This pull request fixes https://github.com/apache/kyuubi/issues/6101
Describe Your Solution 🔧
This updates the jackson version from 2.15.0 to 2.15.4
Types of changes :bookmark:

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Behavior Without This Pull Request :coffin:
Behavior With This Pull Request :tada:
Related Unit Tests

Checklist 📝

[X] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

seems there are issues on shading with multi-version artifact, need more investigation

@pan3793 All tests have passed now.

[Hive Test (8, -Dhive.archive.mirror=https://archive.apache.org/dist/hive/hive-2.3.9 -Dhive.archiv...](https://github.com/apache/kyuubi/actions/runs/8083005789/job/22085080370?pr=6110#logs)
This check has failed after running for 6 hrs, could be intermittent.
Do you have option to restart this particular check?

The test failure is irrelevant, thanks, merged to master.

@Deepali1211 you may want to link your email<EMAIL_ADDRESS>to your GitHub account, otherwise your contribution won't be counted by GitHub.

@pan3793 Thank you for the suggestion. I have linked my personal email Id. Do you mean it has to be org email if they want to count my contributions.

@Deepali1211 there are no restrictions, the email address is extracted from your git commit.

Yes, understood the point. Thank you so much!


Review Request for ARGOS data property definitions BCO

Please review and post comments here on GITHUB for ARGOS data property definitions BCO
Use the BCO Review documentation and Best Practices  as a guide.

@HadleyKing where is the BCO? The BCO link you have above is an empty page https://biocomputeobject.org/builder/https/biocomputeobject.org/BCO_DRAFT_4e9cb351aa774f798073d15781304a88

@HadleyKing can you please email me the BCO name and BCO usability domain?

Reviewed using https://www.jsonschemavalidator.net/
(Suggest addressing these comments from the bottom up to keep line numbers from changing!)

Consider "scientists" or "curators" or "project members" or something like this instead of "team members" in line 54
Consider breaking line 55 up into multiple list items for readability
Suggest adding keywords "definitions" and/or "ontology" or "controlled vocabulary" at line 60
Suggest changing step numbers to 1 and 2 instead of 0 and 0 on lines 64 and 120
Remove whitespace line 68 (validation)
Remove whitespace line 124 (validation)
Since driver definition is "Indication of the kind of executable that can be launched in order to perform a sequence of commands described in the script," should we link this to Google Docs for example (line 149)? Or Excel executable?
Change input URI line 172 to http://data.argosdb.org/ln2downloads/argosdb_qc/02_15_2022/property_definition.tsv (or appropriate filename) (sanity check)
Add filename line 174 with matching filename (sanity check)
Change mediatype to text/tsv line 179
Change output URI line 181 to https://data.argosdb.org/ln2data/argosdb_qc/02_15_2022/property_definition.tsv (sanity check)
Remove whitespace line 189 (validation)

@kee007ney

Reviewed using https://www.jsonschemavalidator.net/ (Suggest addressing these comments from the bottom up to keep line numbers from changing!)

Consider "scientists" or "curators" or "project members" or something like this instead of "team members" in line 54

Done

Consider breaking line 55 up into multiple list items for readability

I was trying to use the format from the BCO Review documentation and Best Practices to format the usability domain. I don't really see a good breakpoint in that text as it describes the column headers..

Suggest adding keywords "definitions" and/or "ontology" or "controlled vocabulary" at line 60

Done

Suggest changing step numbers to 1 and 2 instead of 0 and 0 on lines 64 and 120

Done

Remove whitespace line 68 (validation)) RE: description_domain/pipeline_steps[0]/prerequisite

Whitespace is an issue with format conversion. the minimized version published on biocomputeobject.org will not have that. But I removed the blank prerequisite.

Remove whitespace line 124 (validation) RE: description_domain/pipeline_steps[1]/prerequisite

Whitespace is an issue with format conversion. the minimized version published on biocomputeobject.org will not have that. But I removed the blank prerequisite.

Since driver definition is "Indication of the kind of executable that can be launched in order to perform a sequence of commands described in the script," should we link this to Google Docs for example (line 149)? Or Excel executable?

Good Question! I was wondering the same thing.... Since you suggested it I will list Google doc. But doesn't that mean we should do the same for the input_subdomain? See comment below about line 181

Change input URI line 172 to http://data.argosdb.org/ln2downloads/argosdb_qc/02_15_2022/property_definition.tsv (or appropriate filename) (sanity check)
Add filename line 174 with matching filename (sanity check)

I did not think sanity check was run on input files. But ok. -> Correction. See note above about driver

Change mediatype to text/tsv line 179. RE: output_subdomain[0]/mediatype

Done!

Change output URI line 181 to https://data.argosdb.org/ln2data/argosdb_qc/02_15_2022/property_definition.tsv (sanity check). RE: output_subdomain[0]/uri/uri

Thanks for catching that one!

Remove whitespace line 189 (validation). RE: parametric_domain

Whitespace is an issue with format conversion. The minimized version published on biocomputeobject.org will not have that. Thanks!
Also: Based on @rajamazumder's review I have updated the BCO to include all three of the property files:

core_property_list.tsv
property_definition.tsv
annotation_property_list.tsv


Cosmos Spark connector: Ingestion scenario best practices

Description
This PR contains a draft for the "Ingestion" best practices when using the Cosmos Spark connector. I will fill the gaps for "Query", "Throughput control" and "Changefeed processing" subsequently in separate PRs.
** the easiest way to review the MD file is by using this link https://github.com/FabianMeiswinkel/azure-sdk-for-java/blob/users/fabianm%2FCosmosSprakDocumentation/sdk/cosmos/azure-cosmos-spark_3-1_2-12/docs/scenarios/Ingestion.md **

keep it open please

Keep this alive please


Added the validator github link

The link was added to the error message below the link to Neurostars.
Addition to resolve https://github.com/INCF/bids-validator/issues/493

@franklin-feingold Thanks!


Discussion: React-Redux and React async rendering

I'll open this up as a general forum for discussing anything related to how React-Redux is going to interact with React's new "Suspense" async rendering capability and time-slicing behavior.
At the moment, we don't really have a good idea of what that means for React-Redux.  We're going to need a better understanding of how React's async rendering behavior works, how this suggested "caching" concept fits into things, and what the final React APIs are going to look like.

The general React API will change for suspense, but the main concept I believe is that this.deferSetState({ foo: 'bar' }) will try to render as much as the tree as possible, but only flush the actual changes when all the thrown promises in the tree have completed (movieFetcher.read() throws a promise). The actual update could occur after several seconds if the promises are HTTP requests.
If you call deferSetState again the old tree is discarded to avoid race-conditions.
There are other bells and whistles, like Placeholder and Loading which allow to have finer-grained access to this process, but this is the overall idea I believe.
In the demo the fetchers seem to use a cache. Throwing an HTTP promise in the render is akin to "start this HTTP operation and re-render me when there's a response", so the cache seems to exist for the render to understand when the response arrived.
It's unclear how this can be used with Redux, and we should probably keep an eye on this PR https://github.com/reactjs/react-redux/pull/856
From a high-level, the cache that render's use to understand whether they need to start an async operation could very well be a redux store.
I imagine redux should be notified about when such async operations occur:
function MovieDetailPage({ movieId }) {
  const movie = movieDetailFetcher.read(movieId) // throws a promise
  ...

Instead, the connect HOC could pass to the component the actual fetcher so it knows about the promise:
function MovieDetailPage({ movieId, movieDetailFetcher }) {
  const movie = movieDetailFetcher(movieId) // throws a promise, and let's redux know about it
  ...

Just my two cents.

You can throw a Promise both from render and from getDerivedStateFromProps. The latter looks like it would be a good way to handle things. But it would require us handling side effects explicitly. That's normally done in the middleware, so it's just a matter of this library providing its own "middleware" of sorts and expecting a particular return from middleware (this would be new).
We would wrap the store.dispatch in a function that checks for a promise return. If it gets one, we store it, fire a setState to trigger an update, and during the render we would throw that promise to React. When it resolves, we would get a re-render from React and should pass through with the resolved state.
The fun part is the specific timing of things with the React render cycle and the store subscription cycle. I think we just need to try it and see what happens.
It would also require middleware spit out that Promise, so we'd need ecosystem coordination. But I think that's do-able and we can provide some helpers for the common cases (wrap function returns from thunks, some sort of saga coordinator, etc).

One potential issue there is that I know a lot of people are depending on being able to do this.props.someThunkReturningAPromise().then( () => {} ) inside a connected component.
Another big aspect that's not clear yet is this whole "cache" thing.  How are components expecting to access a cache?  What does the caching API look like?  How could this potentially map to data in a Redux store?

There's a bunch of relevant WIP info from Brian Vaughn about async rendering and subscriptions:

React docs PR #596: An update on async rendering

Blog post preview
Gist: Advanced example for eagerly prefetching data in a component
Gist : Example for loading new external data in response to updated props
Gist: Advanced example for manually updating subscriptions in response to props changes in an async-safe way

React PR #12325: WIP create-component-with-subscriptions

Gist: create-subscriber-component proof of concept

Also relevant:

React PR #12279: WIP - Suspense

react-reconciler/tests/ReactSuspense-test.js

That would pass through the dispatch wrapper. And in async mode, they'll be able to throw that promise too:
render() {
  if (!this.props.users) {
    throw this.props.loadUsers().then(this.handleLoadedUsers)
  }

  return this.renderUsers(this.props.users)
}

Of course, what are you seeing people do within that .then? If it's a loading state, that's handled entirely different by Suspense. So, there's some refactoring needed on the user side too.

Don't have specific examples to point to atm, but it's usually triggering more fetches, dispatching actions, or setting component state.

You can throw a Promise both from render and from getDerivedStateFromProps

You can also throw a Promise inside state updater functions!

You can also throw a Promise inside state updater functions!

Oh, that's a good one too!

I want to warn against coming up with something complicated. Our goal is to make React Redux work roughly the way it was conceived three years ago. Not put another super complicated system like we have now on top.

My tentative understanding is we want to move state handling in React and use setState updater form + context for it. Some follow up questions that I don’t know answers to:
Who Owns the State?
If React owns the state (which is what we need for time slicing and suspense) then createStore doesn’t make sense. Which might be fine. I imagine top-level Provider could give you an imperative store-like object with a compatible API (just like a ref).
For example, instead of this:
let store = createStore(reducer);
ReactDOM.render(<Provider store={store}><App /></Provider>, node);

you might have:

Dan, I know that's what you and Andrew have said you want.  I'm not sure that's what Tim, Jim, and I want.  We don't yet have a full enough understanding of the situation to say that's the right approach.
One point of concern: React-Redux is currently usable with React alternatives like preact-compat and inferno-compat.  What happens if we rewrite all of React-Redux's internals in terms of React 16.x-only behavior?

My tentative understanding is we want to move state handling in React and use setState updater form + context for it. Some follow up questions that I don’t know answers to:
Who Owns the State?
If React owns the state (which is what we need for time slicing and suspense) then createStore doesn’t make sense. Which might be fine. I imagine top-level Provider could give you an imperative store-like object with a compatible API (just like a ref).
For example, instead of this:
let store = createStore(reducer);
ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  node
);

store.dispatch(stuff());

you might have:
let storeRef = React.createRef();
ReactDOM.render(
  <Provider storeRef={storeRef}>
    <App />
  </Provider>,
  node,
  () => {
    let store = storeRef.value;
    store.dispatch(stuff());
  }
);

From user’s point of view it doesn’t matter where store is coming from since it has the same API.
How Are Priorities Handled?
Redux store has getState() (and middleware calls it). It’s not clear to me how this should work with deferred updates that haven’t finished yet. I haven’t really thought about this yet.

One point of concern: React-Redux is currently usable with React alternatives like preact-compat and inferno-compat. What happens if we rewrite all of React-Redux's internals in terms of React 16.x-only behavior?

I understand if that’s important to you, but supporting this was never the goal of these bindings when we were creating them. I don’t think it makes a lot of sense to support the common denominator forever because:

These packages have already chosen to fork the ecosystem (inferno, preact)
This doesn’t let React move forward.

One problem with "the store lives purely inside of a <Provider>" is that people are doing lots of stuff with the store outside of the React component tree.  Store setup, passing the store to persistence utilities, running tests, etc.

This doesn’t let React move forward.

Yes, but as maintainers of a package that is used by more than just React users, we've got to take the ecosystem as a whole into consideration.
It may be that the final approach is to maintain 5.x as the designated "backwards compatible" line, and 6.x onwards is the "React future-only" line.  That's something we can discuss.  But, my goal would be to find a way to minimize total API churn and compatibility issues for all of our users, even if that means that we have to do some complex bookkeeping internal to the library.

One problem with "the store lives purely inside of a " is that people are doing lots of stuff with the store outside of the React component tree. Store setup, passing the store to persistence utilities, running tests, etc.

I agree, and we need to find a solution for these use cases. I’m sure one exists. For cases where you only need the store after rendering, my ref API above should work just fine. For other cases, we can come up with something similar.
I think the mistake here would be to spend a lot of energy on not addressing this, and instead jumping to our regular “let’s completely work around React” way of thinking.

My concern is also: can we get the same predictability with suspense? Will dispatching N actions always bring you to the same state?

React updater functions are deterministic, yes.

I wouldn't phrase it as "let's work around React".  Right now, I want to understand exactly what the constraints are that we need to properly work with React, so that we can figure out the possible solutions based on those constraints.

The main constraint, as I understand it, is that React should own applying the state updates. Which is, luckily, very easily fits with the reducer paradigm. The main issue here is that createStore doesn’t quite work this way. So that’s what I think we should be looking at (instead of intercepting Promises, rethrowing them, etc).

I like the storeRef idea, for apps that use both React and some non-React Redux consumer.
To expand a bit on Dan's "lowest common denominator" metaphor, the point here is that in the current  architecture, Redux is in charge of scheduling:
store change event -> React render cycle

That means that React's scheduling can only ever be as sophisticated as the store. Which is: not sophisticated at all. Redux stores are dumb, synchronous event emitters. They do a bit batching for nested dispatches, but that's it. Effectively, this means all rendering that occurs as a result of a redux dispatch must be synchronous to avoid inconsistencies.
That worked fine in a pre-async world, but if we limit ourselves to only having scheduling as smart as what an event emitter can do, we're missing out on all of the amazing stuff Dan showed off in his demos.
By letting React control the scheduling, we get prioritization, rebasing, and suspense for free.

They do a bit batching for nested dispatches, but that's it.

Note that even today (in sync world) they're already very inefficient for network requests. Because if you have many setStates as a result of network response, Redux store won't batch React rendering. Unless you use an explicit enhancer that is aware of unstable_batchedUpdates.

I like the storeRef idea, for apps that use both React and some non-React Redux consumer.

One interesting question that comes out of this: what if you have multiple React roots that currently use the same store? How would that work?

Yes, I get the desired advantages of that approach.  What I don't feel I have yet is a full list (or even a partial list) of the constraints and use cases that we need to actually solve in order to properly work with React.
I know the React team has spent a ton of time focusing on the React side of things, and you're naturally focused on doing everything "the React way".  I'm trying to figure out all the other Redux-side use cases that would potentially conflict with that.

One interesting question that comes out of this: what if you have multiple React roots that currently use the same store? How would that work?

Yeah.  For example, right now I've got an app that's 85% Backbone and 15% React, and we're progressively rewriting / adding new features with React.  We've got many small ReactDOM.render() component trees spread throughout the UI, and they're currently sharing the same Redux store instance.

I don't see how that storeRef can work. How does one apply middleware or store enhancers?

what if you have multiple React roots that currently use the same store? How would that work?

Not sure. The most straightforward way to do this is that a dispatch calls setState on every root. Each React root has their own scheduling (they are committed separately), so in the current model, tearing is inevitable. But I think that's inherent to having multiple roots. If you want coordinated scheduling, you should use portals instead.

How does one apply middleware or store enhancers?

Props to Provider. Again, not saying it’s the final API I propose, just want to get something started. :-)

Can we put together a small example that illustrates the problem with code? All this theory talk without a practical example has me almost completely lost.

That's why I published those canaries :D Try building Dan's movie demo using Redux and you'll see the problem immediately.

My gut still says that some kind of a React-Redux-specific store enhancer would be a potential approach here.  Override dispatch() and subscribe(), and have that hook into React's state management and lifecycles somehow.  (Maybe some kind of private/internal API function that Provider could pass as the setState() completion callback, and until that's executed, the store still returns the "old" state.)

Is Dan's demo published somewhere? More than happy to take the lead on that. For once, I want to build a broken application 😄

So here's the next specific concern I have:
Dispatching an action is intended to be 100% synchronous unless altered by a middleware, and calling store.getState() immediately after dispatching returns the updated state.  This pattern is frequently used to do additional logic with the updated state, such as:
// An example of checking state after a dispatch
function checkStateAfterDispatch() {
    return (dispatch, getState) => {
        const firstState = getState();
        dispatch({type : "FIRST_ACTION"});

        const secondState = getState();

        if(secondState.someField != firstState.someField) {
            dispatch({type : "SECOND_ACTION"});
        }
    }
}

How does multiple-dispatching tie into React's reconciliation process?
If React were to "own the state", how would the thunk logic access the updated state synchronously right after dispatching the second action?

@markerikson I would be perfectly happy with a newer react that depended on promises:
// An example of checking state after a dispatch
function checkStateAfterDispatch() {
    return async (dispatch, getState) => {
        const firstState = getState();
        await dispatch({type : "FIRST_ACTION"});

        const secondState = getState();

        if(secondState.someField != firstState.someField) {
            dispatch({type : "SECOND_ACTION"});
        }
    }
}

@ericanderson : but there's tens of thousands of projects out there that may rely on the existing behavior.  And, thunks are at the core Redux level, not the React-Redux level (so far).

I think this project will suffer stagnation if the concern is preact or existing behavior. Thats what major version numbers are for. If this project is more interested in supporting alternative JSX impls, or legacy, I will personally be happy to fork it (or ideally someone else does so and I use their fork).
One of my major projects uses thunks, but this is not react-redux-thunk nor preact-redux. Supporting thunks going forward is a nice goal but if thunks don't fit into the new world, I'll take the performance improvements to react over thunks.

Repeating my comment from earlier:

It may be that the final approach is to maintain 5.x as the designated "backwards compatible" line, and 6.x onwards is the "React future-only" line. That's something we can discuss. But, my goal would be to find a way to minimize total API churn and compatibility issues for all of our users, even if that means that we have to do some complex bookkeeping internal to the library.

I know the React team would like to have the ecosystem sufficiently prepared so that when an async-rendering-capable React release does come out, the rest of the ecosystem is ready to work with it right away.  But, this is still very early discussion.  Async rendering won't be out for a while.  The React APIs aren't final.  Nothing is set in stone.  We're just trying to figure out what the problem space looks like.  We've got time to figure out what we're going to do.

I think an important question to answer... What should happen when an action is dispatched from a component displaying stale state?

Legit question: how does this valueChangedCallback-type stuff meaningfully differ from, specifically, a Redux store subscription callback? How is this async-friendly-er?

I am not familiar with the implementation of react-redux (or most other similar libs).

And, given that a Redux store can already be treated as an observable, what's the feasibility or relevance of using the proposed "component with subscriptions" with the current Redux store behavior?

To be clear, my proposal for create-component-with-subscriptions is not targeting libraries like react-redux. I thought the PR opening made this clear but perhaps it didn't. The main purpose of this helper library would be to simplify async-compatible application code.
Libraries like this one might decide that it's easier/better/faster/whatever to support async internally, using similar patterns as create-component-with-subscriptions uses (or as shown in this gist).

@bvaughn : sorry if I misread things.  I've only skimmed through your PR and gists, and it looked sorta-relevant.
On that note: I was discussing this topic in Reactiflux last night, and have a couple additional thoughts.
Right now, every connected component is a separate subscriber to the Redux store.  That's part of why we have to enforce the top-down subscription behavior, so that if the data that a connected list item wants goes away, its connected parent list re-renders first and unmounts that list item before the list item tries to read a non-existent piece of data.
This is also relevant to the "tearing" issue, where ComponentA tries to re-render initially and gets state 1, and ComponentB tries to re-render at a slightly later point in time and gets state 2 instead, because they're both calling store.getState() internally, and the store state may have changed in between.
Sooo... completely brainstorming atm, but what if there's a middle ground here?  What if we still keep the current "app state source of truth" in the Redux store as it is right now, but rather than having every connected component subscribe to the store, we copy the current store state into the <Provider> and have the connected components subscribe to that instead?
Now, I know that React has different behavior when setState() is triggered from within a React event handler vs a callstack that starts outside of React code.  Maybe there's some kind of better integration we can do there to allow batching if multiple actions are dispatched close together.
On a similar note: one of the literal Redux FAQs is why we don't include actions/state as arguments to subscriber callbacks, and the answer is:

Subscribers are intended to respond to the state value itself, not the action. Updates to the state processed synchronously, but notifications to subscribers can be batched or debounced, meaning that subscribers are not always notified with every action. This is a common performance optimization to avoid repeated re-rendering.

So, given that the UI isn't guaranteed to see every action anyway, it seems like we can exploit that somehow.
Loosely put, it seems like what we need is a better sync-Redux-to-async-React adapter.
(These thoughts may or may not be entirely coherent - the coffee hasn't fully taken effect yet.)

Repeated disclaimer: I haven't used Redux in a long time, and I am not familiar with react-redux internals.
No worries. It is definitely relevant 😁 I just don't know if it's appropriate for react-redux to use, or if you would be better off following the patterns I've shown there and here within this library instead.
Sounds like you have an interesting idea with the Provider thing. May be worth trying out?

@bvaughn : for point of reference, here's a gist Dan wrote a long time back illustrating the basic conceptual implementation of connect.  It completely hand-waves where it gets the store from, and doesn't include any of the performance optimization aspects, but it shows the basic data flow.
The real react-redux v5 implementation differs in some big ways:

The top-most connected component will end up subscribing directly to the store, but nested connected components actually subscribe to their nearest connected ancestor instead (to enforce the top-down behavior)
In v4 and earlier, connect did the bulk of the work inside of render(), after calling this.setState({storeState}).  In v5, we use a bunch of memoized selectors in the subscription callback, and basically do a dummy setState() call to trigger a re-render once we know that something has actually changed for this component.

More random brainstorming:
Perhaps we can leverage the new context API as part of this in some way?  Aspects like passing down the current store state to subscribers, the potential bitmasking optimization, etc.
Also, I saw an interesting-looking state memoization lib the other day that uses Proxies.  Possibly relevant here.
So yeah, I think my first suggestion for us would be to try a revamp of connect() that just does this.setState({storeState : store.getState()}) inside of <Provider>, and the nested connected components access that updated state via the new context API.

Thats an interesting concept @markerikson. The context API is interesting because the HOC goes away and just becomes a fiber I write myself.
<Redux.Consumer>{
  (state) => (
    <Foo thingy={getThingy(state)}>
      { getStuff(state).map((stuff) => (<Stuff key={stuff.id} other={stuff.other}/>)) }
    </Foo>
  )
}</Redux.Consumer>

On the one hand this is really nice. I don't have to connect both Stuff and Foo. For other things I dont want my consumers to have to think about the store. The pattern feels good though.

@ericanderson : for now I'm not picturing dropping connect() - I'd just like to reimplement its internals.
That said, we've certainly gotten plenty of requests for a render-props version of React-Redux.  I'd be okay with potentially adding that in v6.

Yeah, i would want to keep connect for certain cases but providing the above could be nice. It could work with multiple stores too.
function createReduxContext(store) {
  const { Provider, Consumer } = Redux.createContext(store.getState());

  const ReduxProvider = class ReduxProvider extends React.Component {
    render: () => (
      <Provider value={this.state.storeState}>
        {this.props.children}
      </Provider>
    )
    componentWillMount: () => store.subscribe(() => this.setState({storeState: store.getState()}));
  }

  return { Provider: ReduxProvider, Consumer };
}

Its lightweight and cheap but enables new patterns and you can still provide connect() which is nice for legacy code.

Does moving the store subscription up to the top level and relying on context as essentially a subscription net us any benefits? And more importantly, can we maintain the top-down behavior we have today?
BTW, I'm still waiting on an async demo I can implement in redux... 😉

Suspense literally waits before applying your state changes. This means that store.dispatch(foo()) might update your store before your UI, making them out-of-sync.
Isn't this the main issue or am I missing other problems?

Suspense lets you "suspend" during render, hence the name. It's not that it's waiting to apply your changes, it already has, but to the next instance of state. And it has a means of merging interim states when that suspension resumes.
However, that doesn't really apply here, as the state should already be updated by the store when it goes to ship it to React. I.e., the "next state" is already the "current state" at that point. There's no going back!

However, that doesn't really apply here, as the state should already be updated by the store when it goes to ship it to React. I.e., the "next state" is already the "current state" at that point. There's no going back!

Right but how will Redux's know about when it's done applying the changes?

I think I'm not concerned with the "Suspense" aspect yet.  The immediate goal would be to solve the tearing aspect.  If all of the connected components are grabbing the "current Redux state" from <Provider> instead of store.getState(), then React is handling making sure that all components are re-rendering with the same state tree instead of divergent states read at differing times.

@gaearon , @acdlite , @bvaughn : per Tim's question:  what is the update sequencing of the new context API?  Is it literally based on the component tree itself?  If I have a context provider in <Parent>, and both <Child> and <Grandchild> consume it, will <Child> always update before <Grandchild>?
My instinct (and hope) is that the answer is "yes", which would potentially handle the top-down subscription aspect.

Relevant discussion https://twitter.com/aweary/status/970523274189840384

One thing I want to clarify: both with suspense and with time slicing, there’s no one “current state”. There is an update queue, and we “merge” it one way when we want to handle a high priority interaction, but then “merge” it another way when we continue rendering low priority (or suspended) tree. At least that’s my mental model. These two states can interleave (we render the low pri version, then interrupt to render a new hi pri update, the continue rendering the lo pri update). Does this make sense?

So the problem we want to address is: to really benefit from async features we want it to be possible to interrupt a low-priority dispatch (caused by eg a network response) with a high-priority dispatch (caused by an interaction). Just like we can do with setState. This is why we what to use setState + context since then all of this “just works”.
Maybe it makes sense to just implement it this way first and play with it. Then see how existing middleware and enhancers can fit into this.

@gaearon Can you share your movie demo, or some other simple async example? I'd like to implement it in redux as a practical demo of the problem.

@timdorr I found this https://codesandbox.io/s/5zk7x551vk from @acdlite

@timdorr here's one implementation:
https://benoitzugmeyer.github.io/react-suspense-demo/
https://github.com/BenoitZugmeyer/react-suspense-demo/

Also see A Walkthrough of "That" React Suspense Demo.

Thanks all!

Off topic, but any implementation to @gaearon 's time slicing demo?

We'll share it when it's ready. There are still bugs and performance issues we need to fix before it's generally usable.

@ericanderson wouldn't that require the Context.Consumer to be aware of specific Context.Provider though, making them tightly coupled? I think the connect() approach should still be the default one, as asingle store is used un majority of cases, with the added possibility of creating custom Provider+Consumer pairs.

So the utility I wrote above is something I would ship in react-redux as another pattern.

Don't want to sidetrack the discussion, but with your utility it would either:

have to  live in react-redux completly, so that I can

import { Consumer } from "react-redux";

or have to live in user-land

import { Consumer } from "/store/createStore.js";

of which only the first one keeps the "light" coupling we have with connect right now.

I think you’re missing a fundamental aspect of the new context api. React redux would only expose the utility. It’s on me the end user to call createReduxContext and to use the result.

It’s on me the end user to call createReduxContext and to use the result.

Yes, that's the part that would work differently than it does currently. The consumer would end up having to import some userland code to get the proper context pair, rather than importing provider-agnostic connect like it does now. Just wanted to bring that part into attention.

Is the intention to have better typing support?

Yeah, that's actually an interesting point, and something I was just starting to realize earlier this evening.
I know that new context isn't even out yet, but there's a polyfill and people have been playing with it.  Do we have any examples or suggested approaches for actually getting the Consumer into the right spots as needed?  I know there's been several context-based mini-state-management libs people have thrown together in the last few weeks.  Could someone do me a favor and maybe pull together a summary of how they deal with context consumers, and specially how they might handle having multiple context instance pairs?
For example, looking specifically at the implementation of unstated, it appears to create a singleton context pair and reuse that.
We could certainly do the same in React-Redux, especially since you're supposed to only have one store and stick Provider at the top of the tree, but I've definitely seen cases where people put multiple Providers in different parts of the tree.  Or, going further, libraries that extend / override React-Redux's behavior by defining:
    childContextTypes = {store}
    contextTypes : {store}

    getChildContext() {
        const realStore= this.context.store;
        return {store : ...realStore, getState : this.specialGetState}
    }

Or something similar to that.
Obviously that's not an intended part of the public API, but with new context being these specific paired instances, that sort of thing wouldn't work any more.
Back to my question: I can imagine we could create a default ReactReduxContext pair inside the lib.  But, what happens if someone wants to have another <Provider> with another store somewhere in the tree?  The second <Provider> might be subscribed to the second store, but it would be using the same ReactReduxContext.Provider instance.  We could offer up a createReactReduxContext() API, or even just tell them "call createContext yourself and do <Provider store={store} contextProvider={myContext.Provider}>, but then how do they get their own myContext.Consumer into all of the nested components?
I'm so confused now :(

@nickmccurdy: honestly, typing is low on my priority list atm, both because I'm more concerned with actually figuring out plain implementation details, and also because none of us Redux maintainers use typings ourselves.  See my comment over in #799 .

I should have some free time tomorrow.  I really should be trying to do workshop prep, but I think I'm going to spend the day playing around with a proof-of-concept spike for connect.
@gaearon , @acdlite , @bvaughn : what's the latest and bleeding-edge-est React copy that I can play around with?  Clone the main repo, merge in Andrew's branch, and build that?  Or is there a good alpha floating around I can grab?  I guess I don't care about the Suspense stuff atm, I just want new context + any async / time-slicing flags I can turn on.

$ npm info react | grep 16.4
     canary: '16.4.0-alpha.0911da3' },
     '16.4.0-alpha.3174632',
     '16.4.0-alpha.7926752',
     '16.4.0-alpha.0911da3' ],
     '15.3.0-rc.3': '2016-07-21T22:59:16.416Z',
     '16.4.0-alpha.7926752': '2018-02-13T00:52:25.835Z',
     '16.4.0-alpha.3174632': '2018-02-24T05:07:52.478Z',
     '16.4.0-alpha.0911da3': '2018-02-27T02:14:07.333Z' },

Looks like 16.4.0-alpha.0911da3 was the latest release, for Dan's demo. I don't know if there are caveats or gotchas.
If you want to build the latest from master:
git clone git@github.com:facebook/react.git
cd react
yarn install

Maybe toggle some feature flags
yarn build

I've just created a PR with a seemingly-working first cut at a rewrite of React-Redux v5 to use the new React.createContext() API.  Please see #898 for details.

The problem of obtaining data asynchronously for the initialization of the store is probably one of the most unpleasant. I try to solve it by transferring an asynchronous request to Link, making it asynchronous.  https://github.com/apapacy/realworld-react-universal-hot/blob/master/src/react/asyncLink.js

@markerikson regarding the multiple stores + multiple contexts issue, I see 3 options:

provide your own Context to <Provider /> and all your calls to connect:

const context = React.createContext(null)
<Provider context={context} store={store} />
connect(mapState, etc, { context })

not ideal

offload all the context providing/consumption work to us and allow users to provide a map of stores to our <Provider /> component, and we'll use a single Context.Provider to broadcast to all connected Consumers. Here's the usage:

<Provider stores={{ store1, store2 }}>
      <App />
</Provider>

And here's a quick implementation:
const Context = React.createContext(null)

export default class ReactReduxProvider extends Component {
  constructor(props) {
    super(props)

    let { stores, store } = props

    if (Array.isArray(props.stores)) {
      this.storeNames = Object.keys(stores)
    }
    else {
      this.storeNames = ['main']
      stores = { main: store }
    }

    this.state = this.storeNames.reduce((initialState, name) => {
      const { dispatch, subscribe, getState } = stores[name]
      initialState[name] = { dispatch, subscribe, getState, state: getState() }
      return initialState
    }, {})
  }

  componentDidMount() {
    this.storeNames.forEach(name => {
      const store = this.state[name]

      store.subscribe(() => {
        const state = store.getState()

        if (state !== store.state) {
          this.setState({ [name]: { ...store, state } })
        }
      })
    })
  }

  render() {
    return (
      <Context.Provider value={this.state}>
        {Children.only(this.props.children)}
      </Context.Provider>
    )
  }
}

connect(mapState, { store: 'store1' })
connect(mapState, { store: 'store2' })
connect(mapState) // useses 'main' store from `props.store`

function connect(mapState, etc, options = { store: 'main' }) {...}

This has a performance problem though. All the connected hocs will try to update when any of the store update. Each of their shouldComponentUpdate methods could return false in this case, but it still doesn't feel good enough.

The most performant option (least amount of components updating): we could have 2 types of context providers:

1 that provides a map of all available contexts, and it's "statically" available for connect HoCs to access. It's where they will dynamically learn of all available stores/contexts.
And then the context providers that actually provide the state for a given store.

The connect api would be the same as in #2, and an implementation would look something like this:
export const ReactReduxRegistryContext = React.createContext(null) // statically imported by `connect.js`

export default class ReactReduxProvider extends Component {
  constructor(props) {
    super(props)
    this.state = {}

    this.storeNames = Object.keys(props.stores)

    this.state.stores = this.storeNames.reduce((stores, name) => {
      const { dispatch, subscribe, getState } = stores[name]
      stores[name] = { dispatch, subscribe, getState, state: getState() }
      return stores
    }, {})

    this.state.contextRegistry = this.storeNames.reduce((registry, name) => {
      registry[name] = React.createContext(null)
      return registry
    }, {})
  }

  componentDidMount() {
    this.storeNames.forEach(name => {
      const store = this.state.stores[name]

      store.subscribe(() => {
        const state = store.getState()

        if (state !== store.state) {
          this.setState({
            stores: {
              ...this.state.stores,
              [name]: { ...store, state }
            }
          })
        }
      })
    })
  }

  render() {
    const contexts = this.storeNames.map(name => ({
      Context: this.state.contextRegistry[name].,
      store: this.state.stores[name]
    }))

    const PropsChildren = React.createFactory(() => props.children)

    return (
      <ReactReduxRegistryContext.Provider value={this.state.contextRegistry}>
        {contexts.reduceRight((Child, { Context, store }) => {
          const ChildWrapped = () => (
            <Context.Provider value={store}>
              <Child />
            </Context.Provider>
          )

          return i === 0 ? <ChildWrapped /> : ChildWrapped
        }, PropsChildren)}
        </ReactReduxRegistryContext.Provider>
    )
  }
}

The long and short of it is we create this:
<ReactReduxRegistryContext.Provider value={this.state.contextRegistry}>
   <Context.Provider value={store1}>
              <Context.Provider value={store2}>
                  <Context.Provider value={store3}>
                      {React.Children.only(this.props.children)}
                  </Context.Provider>
              </Context.Provider>
    </Context.Provider>
</ReactReduxRegistryContext.Provider>

And then ultimately, connect looks something like this:
function connect(mapState, actions, { name = 'main' }) {
  return function wrapWithConnect(WrappedComponent) {
    class Inner extends Component {
      constructor(props) {
        super(props)
        this.actions = actions && bindActionCreators(actions, props.dispatch) // just basic binding for now
        this.state = { selector: memoize(mapState) }
      }

      static getDerivedStateFromProps(nextProps, prevState) {
        const { storeState, props } = nextProps
        const result = prevState.selector(storeState, props)
        return result === prevState.result ? null : { result } // `null` indicates no state changes occurred; also previously before I got the usage of `memoize-state` correct, I had an additional `shallowEqual` check here--so we get that for free from that library
      }

      shouldComponentUpdate(nextProps, nextState) {
        const resultEqual = nextState.result === this.state.result
        return !resultEqual || !shallowEqual(nextProps.props, this.props.props) // of course updates could be triggered not just from store state changes, but also from regular props, and for this POC we assume a pure component
      }

      render() {
        const { props, dispatch } = this.props
        const { result } = this.state
        const mergedProps = { ...props, ...result, ...this.actions, dispatch }
        return createElement(WrappedComponent, mergedProps)
      }
    }

    function Connect(props) {
      return (
        <ReactReduxRegistryContext.Consumer> // statically accessible consumer
          {(registry) => (
            do {
              const Context = registry[name]

              ;(
                <Context.Consumer> // dynamically discovered consumers
                  {({ dispatch, state }) => (
                    <Inner dispatch={dispatch} storeState={state} props={props} />
                  )}
                </Context.Consumer>
              )
            }
          )}
        </ReactReduxRegistryContext.Consumer>
      )
    }

    Connect.WrappedComponent = WrappedComponent
    return hoistStatics(Connect, WrappedComponent)
  }
}

@faceyspacey : appreciate the effort you went to there, but I think it's all a moot point :)  I saw some comments indicating that if you nest instances of a Context.Provider, the closest one "wins".  So, this should be legal:
<Provider store={store1}>
    <MainApp>
        <Provider store={store2}>
            <NestedApp />
        </Provider>
    </MainApp>
</Provider>

Unless they don’t necessarily want to match the closest parent provider.
That said, if what u just described works, I agree it’s probably best to forget about it. And if people have some complex multi store need, they should just supply the context to both the provider and connect as per #1 above. It’s not that big of a deal, and can be abstracted in userland by wrapping connect in a function that does it for you. Likely context props will become a thing with the new API.

I'm not really into the internals of react-redux and react suspense, but is it possible to put the fetcher/cache into the redux store?
const getData = () => createCache(loadDataAsync);
const reducer = (state = { data: getData() }, action) => {
  switch(action.type) {
    case: 'INVALIDATE': return { ...state, data: getData() };
  }
  return state;
};

The fetcher/cache should be "immutable", i.e. if we want to invalidate the cache, we have to create a new one.

@Lenne231 : "possible"?  Sure, on the grounds that you can put literally anything into a Redux store. However, we discourage putting anything that's not plain serializable data into the store.
The whole "caching" aspect of using React Suspense isn't entirely clear yet.  I know the React team has put out a small reference caching lib, and I know that the general idea is that it's something that should likely be passed down via context and should throw a promise if it is queried and doesn't have the data you want already available.  I'm not yet sure on how that concept would relate to a Redux store.

@gaearon would it be safe to say that React state is consistent in setState callbacks and post-render life cycles?
So would it work to modify react-redux so that dispatch flow is more like:
dispatch(action)
-> get reducer value
calls -> setState(reducer value)
callback/post-render -> update redux state
-> continue synchronously a la old way
In other words, we would delay the synchronous part of the redux so that redux outside of react becomes a subscriber to the state rather than a provider of state that can also push state updates back into react? Do we risk 2-way subscription race condition issues with this idea?
This won't solve the problem of store enhancers, but with enough warning, those (rather limited) examples should have time to update to a new API.

@cellog : that sounds a lot like the "reimplement Redux on top of React" approach that Dan and Andrew have suggested.  Problem is, there's tons of code out there that expects the store to have been synchronously updated as soon as dispatch() returns.  Here's a basic example of a thunk that relies on that behavior:
function checkStateAfterDispatch() {
    return (dispatch, getState) => {
        const firstState = getState();
        dispatch({type : "FIRST_ACTION"});

        const secondState = getState();

        if(secondState.someField != firstState.someField) {
            dispatch({type : "SECOND_ACTION"});
        }
    }
}

My vague train of thought, looking forwards, is that we might have to come up with something akin to Git branching and rebasing with dispatched actions (which is the same metaphor the React team has been using for async rendering).  Since we've never guaranteed that the UI layer sees every action (especially for scenarios such as batched / debounced subscriber notifications), we might be able to have the Redux store itself update synchronously, but then have React-Redux do some fancy footwork and actually present a separate "current state" where actions get applied as React does updates.  Or something like that.  It's still just a vague set of ideas in my head.  (I suspect that Brian's interaction tracking API proposal would be relevant here.)

I've been following this discussion as well as playing with React Suspense through the custom build in the React repository. I've also run into the fact that I was unsure on how to use redux with React Suspense because in my previous React apps I stored all data in the Redux store. However, I just had the following realisation.
Is it truly needed to modify Redux for usage with React Suspense? What if we separate state from data? This would allow us to continue doing state management with Redux but move the ownership of data to a simple-cache-provider and simply read data from our data cache on an as-needed basis (either loading it or not).
I would imagine that the state in the Redux store would be something like "Viewing list of blogposts in category Javascript on page 3" (i.e. { view: 'posts', category: 'javascript', page: 2 }. The data would then be the actual posts themselves.
The Posts component would then simply call posts.read({ category: 'javascript', offset: 2 * itemsPerPage } and would use React to either show a fallback or immediately show the data if it was previously cached.
This would still allow the user to change what they're doing by clicking a different button which would update the Redux state and re-render (and possibly load) the new state with different data.
The data could then either be stored in React's simple-cache-provider or a custom cache implementation. When using SSR then this data cache could be serialized and shipped across the wire in a similar fashion to how this currently happens for the redux store.
I'm not sure if this solves all the problems/use cases at the moment but I think it comes a long way there, I'd be interested to hear what you think.
I think if you'd be looking for a dividing line then you'd say that state is defined as anything that is owned by the local application (e.g. the view filter parameters) and data would be (read-only?) data that's owned by a remote source.

@Kingdutch : a few thoughts.
First, I'm less concerned about the "caching" aspects of Suspense for now, and much more concerned about React's abilities to pause and resume applying updates based on priorities (which conflicts with Redux's assumption that the state is always updated immediately).
Second, while it's entirely up to an app developer what data is in their Redux store, the Flux architecture has always been intended to be useful for developers who want to cache data they've fetched from a server.  It's true that there's plenty of other options for handling data fetching and caching, such as Apollo and such, but I certainly wouldn't want to blanket declare that people shouldn't cache data in Redux when there's many Redux users doing that right now.
Third, I really don't see us making changes to the Redux core library itself as part of this.  The main conceptual ideas atm seem to be either some kind of store enhancer that better integrates async React behavior + a standard Redux store, or a "reimplementation" of a Redux store that uses React component state as its back end.
Really, at this point we're in something of a holding pattern waiting for the React team to release some demos and further guidance around how to properly write apps and work with Suspense and time slicing, so that we can see exactly what issues that leads to with Redux usage and have something concrete to work on.

@Kingdutch thanks for your ideas. Actually, redux functions as a cache, on a global basis, and so creating a version of something that checks to see if redux has loaded state, and throws a promise to load it (or, to be even fancier, throws a promise that dispatches an async action, and listens to the store for the "loaded" action and then resolves the promise) is a feasible option under suspense.
However, as Mark said, the bigger issue is how React will handle state updates under time slicing. There are 2 issues. The first is that rendering can be suspended and restarted, and so any dispatching that occurs in render, or in anything prior to componentDidMount or componentDidUpdate runs the risk of tearing, where redux state is based on outdated information.  Thus, react-redux 5.x, which relies upon componentWillReceiveProps is intrinsically not safe for suspense.
The second issue is a bit more interesting, and has to do with how React will prioritize both rendering and local state updates. There are a couple of strange new functions in React, unstable_deferredUpdates and unstable_interactiveUpdates which are designed for time slicing in async mode.  Deferred updates are less critical state changes, and interactive are unimportant state changes. React handles this by assigning each fiber a timeout value. It processes fibers in the order of shorter timeouts first, then longer. If higher priority fibers finish first, then the lower priority ones get handled. unstable_deferredUpdates sets the timeout to 100ms, and unstable_interactiveUpdates sets it to something like 800ms (I forget the exact number). So anything executed inside unstable_deferredUpdates or unstable_interactiveUpdates will modify the fibers created in order to change the timeouts. Thus, if you dispatch a setState and a redux dispatch in the same place, the redux dispatch will execute synchronously, and the setState will not.
As for how this will affect redux, honestly, I don't think it does, EXCEPT for when we handle async. So, if a user dispatches a load action and a select action at the same time as the load, there is a chance (with suspense) that the user would select something else and dispatch a different load/select action. If the code is designed so that the select happens after the load is concluded, this will select the option the user requested first, which would be incorrect. So the key will be to dispatch actions at the correct time to update redux state. However, redux apps that are not designed for suspense and use thunks, sagas, or epics for async will need to be redesigned to take advantage of suspense. There will be no drop-in for these situations. Suspense essentially replaces async middleware.
The short version: it's complex, but redux is probably async-ready, it's the async middleware that will be an issue, as it won't play nice with suspense. Also, because redux doesn't have batching built-in, it may be less performant under suspense without modifications to streamline it, although I suspect this won't be an issue ultimately, because React context (new one) batches updates to the state.

@Kingdutch : that actually kind of nails the situation as I understand it.
With the Redux core, calling dispatch() guarantees that the state has been updated and subscribers have been notified by the time the call returns.  This means that a thunk can dispatch an action and immediately call getState() to retrieve the updated state afterwards.
Now, middleware and store enhancers do change that equation.  Any middleware can intercept, pause, delay, stop, modify, or replace any dispatched action.  Similarly, a store enhancer can override dispatch, getState, and subscribe, and provide its own implementation, such as debouncing the actual notification of subscribers.
So, it's not out of the question that we could have some kind of magic "React-Redux synchronizing store enhancer" that somehow interfaces between React and async React-Redux, but if so it will be very tricky.

Here's the thing. A redux app that does not make any changes to use suspense or prioritization of setState will continue to work exactly as designed. The only situation where we could get into issues is if someone tries to mix and match suspense and async middleware.
This situation is most easily solved with a 2-pronged approach:

document a recommended approach to using redux with the new async and time slicing features
warn people not to shoot themselves in the foot by blending middleware and suspense
make sure we have react-redux 6 released, which will avoid componentWillReceiveProps, because react-redux 5 will blow up in some circumstances with suspense even without async middleware in the mix.

The first thing can also include an implementation of simple-cache-provider that uses redux as the cache. Problem solved.
Frankly, I think it's best to point out that older async solutions will work, but you don't get any of the benefits of taking advantage of React's scheduler. It's not like redux will suddenly explode in React 17.
However, I am playing around with a redux-like thing based on using setState, and if it bears fruit will certainly report what I learn.

We should be in a good spot for this with #1000 now on master and later on with #1063.

@timdorr, is there any guidance or wisdom to actually use Suspense with React Redux? #1000 is great but doesn't answer the question to this thread. #1063 will also be amazing but I'm still unsure how hooks would specifically address suspense and asynchronous rendering.

@vincentjames501: no, we really haven't investigated the Suspense side.    See the React team's roadmap here: https://reactjs.org/blog/2018/11/27/react-16-roadmap.html .


fix(bch-js): Updating to 5.3.1

:tada: This PR is included in version 2.4.3 :tada:
Your semantic-release bot :package::rocket:


juxt function

var juxt = R.curry(function(fns, thing){
  return R.map(function(fn){
    return fn(thing);
  },fns);
});

I seem to need this function a lot (very useful for comparing different queries over the same data).
does ramda have room for this? (very similar to R.ap, but more general, and none of the funny business of R.ap where it does some nested mapping).

This seems to me to be exactly ap:
R.ap(fns, [thing])

i don't believe so.
ap looks something like
var ap = R.curry(function(fns, things){
  return R.compose(
    R.unnest,
    R.map(function(fn){
      return R.map(fn, things);
    }))
  (fns);
});

output http://ramdajs.com/docs/#ap
[ 2, 4, 6, 4, 5, 6 ]

juxt on the other hand.
R.map(juxt([R.multiply(2), R.add(3)]), [1,2,3]);

output
[ [ 2, 4 ], [ 4, 5 ], [ 6, 6 ] ]

i see. this is breadth first. i stand corrected.

Although this looks like a very good idea, I think we might want to work through a more substantial implementation that allows the functions to be of higher arity.  Think:
juxt([R.add, R.subtract, R.multiply, R.divide], 12,, 4); //=> [16, 8, 48, 3]

But this would be much more complicated to curry correctly.  As far as I can see, we'd have to do some sort of manual currying, which is made much harder by having to deal with R.__ in all cases manually.  Nonetheless, it seems the right thing to do.  Alternately, we might do this:
juxt([R.add, R.subtract, R.multiply, R.divide], [12,, 4]); //=> [16, 8, 48, 3]

which would be easier to implement, but would complicate the API for the simplest, and presumably most common case of juxt(fns, val).

R.map(juxt([R.multiply(2), R.add(3)]), [1,2,3]) <=>  R.map(R.pipe(R.of, R.ap([R.multiply(2), R.add(3)])), [1, 2, 3])

a little more cruft, but not much more

Because of the comment from @buzzdecafe, I'd like to see a good argument for including the functions, which might be seen almost as syntactic sugar on ap.  I think the example above with map is a bit misleading.  The appropriate parallel is:
juxt([R.multiply(2), R.add(3)]), 1); //=> [2, 4]
ap([R.multiply(2), R.add(3)]), [1]); //=> [2, 4]

My earlier comment is also probably off.  I think if we're going to do this in a manner to support multiple arguments, we'll probably have to do the fixed-arity, juxt([fn..], [arg..]), version.  Although there is a good argument to be made for the variadic version once the list of functions has been curried in, it really makes no sense before then.  And of course, in this version, ap already handles it.

I think it may be valuable to not accept an array for the last argument, and let the user decide if they want to map or not.
if the user uses map(juxt) they can name it.
if you guys like the auto-mapping, that's ok, but the lower level/simpler option should be done first, and build the more complicated stuff using it.
juxt is in clojure, underscore-contrib, and probably in other languages/libs, lets not change it for ramda.

My version with an array would not be for mapping but so that you could use it with functions that aren't unary:
juxt ([R.add, R.multiply], [2, 5]); //=> [7, 10]

Although we could do this -- with some difficulty, I imagine -- with individual arguments, we've been moving towards a goal of having no variadic functions at all in Ramda.
But the points-free version of juxt @buzzdecafe suggests above has the same API as your original function.

sorry, i misunderstood what you guys were talking about.
i think that if you want to have functions of multi-arrity, then this would be a bit complicated.
in my experience, i have never needed juxt to act like this.
juxt is supposed to work with map, so adding this requirenment will break it.

The Clojure docs for its version of juxt mentions that "the returned fn takes a variable number of args" and gives this example:
;; sort list of maps by multiple values
(sort-by (juxt :a :b) [{:a 1 :b 3} {:a 1 :b 2} {:a 2 :b 1}]
;;=> [{:a 1 :b 2} {:a 1 :b 3} {:a 2 :b 1}]

That makes sense to me.  If we wanted to map single-arity functions, it would look a little more complicated:
map(juxt(multiply(2), add(3)), [[1], [2], [3]]); //=> [[2, 4], [4, 5], [6, 6]]

It's slightly more complex syntactically than mapping over [1, 2, 3], but not badly so.
Note that we're discussing a similar issue in #989.

wow, i didn't actually know clojure juxt was like that.
anyway, clojure code maps pretty nicely to ramda.
the rest of clojure's library follows this convention (with map, filter, other fns).
ramda doesn't really follow this convention, so i think that the juxt i presented works nicely with the rest of ramda.
it may be nice to have both.

closing without prejudice, reopen if you want to pursue. as noted above, this function is easily enough produced by composition var juxt = R.useWith(R.ap, R.identity, R.of)

Do I understand this correctly in that the difference between using juxt and ap is that ap requires the functions to be single-arity?

ap is about compatibility with the FantasyLand specification.  Any similarity with juxt is just a helpful coincidence.

What an odd name for an algebraic JavaScript specification :). The reason I asked is that juxt is very useful at least in contrived exercises. Like getting the range of a set of inputs juxt(min, max) (not the most efficient way, but useful). juxt also lends itself well to pointfree function composition in many scenarios.
We teach kids as young as 8 years old JavaScript in a functional style (we later teach them Clojure as well). For our exercises and purposes, the functionality of juxt is used often. So I'd like to put a vote in to adding juxt to the Ramda library.

We teach kids as young as 8 years old JavaScript in a functional style (we later teach them Clojure as well).

@samueller that's fantastic -- and you are using ramda to do this? IMO that is the best possible use of the library, which itself started as a research project.

incidentally, the PF version above doesn't work anymore because of API change to useWith. This is how it would be written today:
var juxt = R.useWith(R.ap, [R.identity, R.of]);

We teach kids as young as 8 years old JavaScript in a functional style (we later teach them Clojure as well).

:fireworks: :balloon: :cake: :star: :sparkling_heart: :sparkles:

@buzzdecafe yes we are working Ramda into our curriculum. We investigated all the other algebraic/functional JavaScript libraries and found Ramda most appealing. By far.
For supporting variadic functions, this should work:
var juxt = R.useWith(R.ap, [R.map(R.apply), R.of])

You would call it like this:
juxt([R.add, R.multiply], [3, 4]) //=> [7, 12]


bug: ion-tab angular-translate

Type: bug
Platform: mobile browser
I use angular-translate the below way; but does not seem to work on ion-tabs
<ion-tab title="{{ 'coffee_title_label' | translate }}">

But when it is
<ion-tab translate="coffee_title_label" title="{{ 'coffee_title_label' | translate }}">

I referred the below codepen example
http://codepen.io/andrewmcgivery/pen/tqymb
Can you let me know, what am doing wrong here !

Greetings @psgganesh!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!

I think ion tabs have some issues with two-way data bind, I tried to use it with ng-repeat and it not worked properly, when I did a little search for bugs with it, I can easy find a bug with tabs and it cannot be solved  by ionic team right now.

Hello (: are you still experiencing this issue?

Since it has been a little while since there was any activity on this issue i will be closing it, but feel free to respond back if your still having the issue! Thanks again

Hi,
Sorry for my down time, yep I still getting the issue, I solved it by adding a css class, but we need to check why this 'hide' class are added to the nav bar.
Thanks

Hi,
is there any known solution to this?
I'm still experiencing it...
THANKS!

Hi @nirarazi,
I created this workaround as a directive:
PS: the pg-title-handler attribute at ion-nav-bar is important and it will not work if you miss that parameter in your view.
Controller
 $scope.$broadcast('$pgSetTitle.done', ['talhaoSafrasTitle', $stateParams.title]);

Directive
(function () {
    angular.module('prograo.core').directive('pgSetTitle', pgSetTitle);

    function pgSetTitle () {
        return {
            restrict: 'A',
            link : function(scope, element, attrs) {
                var NAV_BAR_SELECTORS = {
                    active: '.nav-bar-block[nav-bar="active"]',
                    cached: '.nav-bar-block[nav-bar="cached"]',
                    title: '.title'
                };

                scope.$on('$pgSetTitle.done', function (pgSetTitle, args) {
                    if (args && args.length === 2) {
                        var handler = document.querySelector('[pg-title-handler="' + args[0] +'"]');

                        if (handler) {
                            var activeNavBar = handler.querySelector(NAV_BAR_SELECTORS.active),
                                cachedNavBar = handler.querySelector(NAV_BAR_SELECTORS.cached);

                            if (activeNavBar) {
                                var title = activeNavBar.querySelector(NAV_BAR_SELECTORS.title);

                                if (title) {
                                    if (title.innerHTML && cachedNavBar) {
                                        title = cachedNavBar.querySelector(NAV_BAR_SELECTORS.title);
                                    }

                                    title.innerHTML = args[1];
                                }
                            }
                        }
                    }
                });
            }
        };
    }
})();

View
<ion-view pg-set-title="true">
    <ion-nav-bar align-title="center" class="bar-prograo bar-positive" pg-title-handler="talhaoSafrasTitle">

              <ion-nav-back-button>
              </ion-nav-back-button>

    </ion-nav-bar>

    <ion-content class="safras padding">
    	<ion-list>

    	       <show-activity activity="activity" remove-activity="vm.removeActivity" index="$index"></show-activity>

		</ion-list>

{{'activities.noActivity' | translate}}

{{'activities.goBackRegister' | translate}}

    </ion-content>
</ion-view>

@leonardosalles I will try that, THANKS!


Suggestions for the tests

Same game as last time. I'll make some comments and ping you when the PR's ready for review.
It's not as clean as I was hoping. Further PR's will be better. But have a look, check if there's some ideas you like. Don't pass the comments into the code.

:+1:  I really like your ideas. From my side, we can merge it


added workflow as per issue #7

Fixes #7
@sethshivam11 please review and merge this PR.
Also, please add labels and assign this PR to me.
Thank you!

@Asymtode712 We were told not to accept any PRs from you.

@sethshivam11 Ohh no problem


Fix typo and delete unnecessary spaces

typo: Github -> GitHub
delete unnecessary spaces: As Markdown syntax, there was a large amount of half-width spaces that did not affect the display, so I deleted it

@changeworld : Thanks for your contribution! The author, @anirudhcavale, has been notified to review your proposed change.

Merging typo fix


Installation Issues

Hi Ruizhong,
I am encountering persistent installation issues with several packages and am reaching out for assistance. I have attempted various combinations of versions for pytorch, scatter, sparse, cluster, and geometric, but keep running into errors.
The errors vary: sometimes I encounter an issue with LIB_PATH = os.getenv('LD_LIBRARY_PATH').split(':')[-1], other times I face the error torch_sparse/_convert_cuda.so: undefined symbol: _ZNSt15__exception_ptr13exception_ptr9_M_addrefEv, and at times I run into a segmentation fault as follows:

./tsp500_test_G.sh: line 24: 3291898 Segmentation fault (core dumped) python3 ./test_AS_G.py --seed 123456789 --device cuda:0 --n_nodes 500 --knn_k 50 --outer_opt AdamW --outer_opt_lr 0.001 --outer_opt_wd 1e-5 --inner_opt AdamW --inner_opt_lr 0.01 --inner_opt_wd 0.0001 --net_units 32 --net_act silu --emb_agg mean --emb_depth 12 --par_depth 3 --te_net 120 --te_range_l 0 --te_range_r 128 --te_batch_size 10 --te_tune_steps 0 --te_tune_sample_size 500 --te_sample_size 500 --save_name $1.

I am unclear about the root cause of these issues. It could be due to my NVIDIA CUDA version (12.1), my GCC version (11.4), or my operating system (Ubuntu 22.04.2 LTS).
I am unable to install libraries like scatter. I am wondering if these libraries are particularly sensitive to hardware configurations? Do you have any suggestions for resolving these issues or any alternative approaches that I might consider?
Thank you for your time and assistance.
Best regards,
Yifan

The segmentation fault is due to the failed installation of our TSP sampling library. As far as I am aware of, there are two possible causes of your installation issue:

Our TSP sampling library depends on a .so file in the torch_scatter library. You will have to properly install torch_scatter before installing our TSP sampling library.
The installer torch_sampling/setup.py might fail to find the path of that .so file. If so, please search for the file manually and add its path to torch_sampling/setup.py. Note that there can be two similar .so files, one for CPU and the other for GPU. Please use the GPU version.

If you have any questions, please feel free to let me know.


updated latest vendored version of openshift-ansible to 3.5.22

This is vendored, will fail bot tests

LGTM +1


Test on Travis CI with Firefox

This adds a travis-ci config with:

robotframework
robotframework-seleniumlibrary
geckodriver
firefox (latest)

TODO

[x] travis config
[x] Initial test of whether the kernels exist
[ ] upload someplace when done

Ok, so we're (hopefully) set up to deploy the:

demo (index.html, redirects to lab/index.html)
test reports (log.html, report.html)
the screen shots (*.png)
when this merges.

Also added some branch/tag whitelisting so we don't get double builds.

Cool:

https://deathbeds.github.io/jyve/log.html
https://deathbeds.github.io/jyve/report.html
https://deathbeds.github.io/jyve/00_kyrnels.png
https://deathbeds.github.io/jyve/01_kyrnels_offline.png


Bk/auto scroll drag gesture

Details
This adds auto-scroll functionality to the multi-day-selection drag gesture. If a user starts a drag gesture, then drags close to the edge of the scrollable content, the calendar will auto-scroll forward or backward in time so that they can reach dates outside of the original viewport.
Related Issue
N/A
Motivation and Context
Airbnb app need
How Has This Been Tested
Tested in simulator and on real iPhone, vertical and horizontal layout.
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.

Pushed some updates based on review feedback @brynbodayle