jarek/6513: spark magic command

cool this works great.  needs the following frontend changes:

move the text boxes to the right so the labels are not truncated.
redo the toggle to show/hide the cluster progress to be more standard at match the rest of the jupyter design.  right now it looks like this:

a jquery accordion titled "Spark Progress" would work.

I don't want to fall into the "that's not how I would have done it" trap, but I'd like to understand the design decision to link Spark into the kernel.  Spark promises binary compatibility for minor versions (unlike Scala), so it should be possible to compile against 2.2.1 and run against 2.3 or later.

Happy to have your input on the right way to do it & am open to changes.
This is definitely a preliminary implementation intended for feedback.
I like the idea of making it totally loadable, will look into it.

On SparkContext vs SparkSession: the Spark docs say that SparkSession (defaulting to spark in the Spark shell) is the preferred entry point in Spark 2.x, and all the examples in the documentation use it.  My preference would be to have the Spark magic default to giving you the same environment that the Spark shell does.
In the above scenario, I'm not sure what the body of a non-empty %%spark cell should return.  A SparkSessionBuilder, I guess.
I am uncertain about multiple sessions in a single kernel.  Is it possible?  Does it have value?  SparkSession.conf allows dynamic reconfiguration of some parameters, and SparkSessionBuilder.getOrCreate says it will reconfigure an existing session if it finds one.

@jaroslawmalekcodete can you please add to this display of spark RDDs (org.apache.spark.rdd.RDD) with the table widget?

can you please add to this display of spark RDDs (org.apache.spark.rdd.RDD) with the table widget?

Some considerations here:

RDDs and Datasets are evaluated lazily, unlike Pandas DataFrames.  Automatically displaying any part of the contents could trigger an undesired expensive computation.
For Datasets, the show() operation computes and prints the first n (20 by default) rows as a plain text table with columns.  A display() operation could do the same thing as a table widget (I've prototyped this).
Dataset show() works because Datasets have an explicit schema with column names.  RDDs don't have an equivalent operation; they would have to display as just strings (e.g., an index column and a value column).

actually put the dataset display on its own PR for this issue: https://github.com/twosigma/beakerx/issues/7040

The cluster progress looks great, thanks!
However there's a problem which is for really quick jobs, it introduces a lot of vertical jumping.
Not sure what the best solutions is but how about this:
the output is first drawn, the Spark Progress is closed.
if the job takes more than 3s then it opens.

I've confirmed that having two sessions in the same kernel does not work.  I suggest removing SparkSessionAlias and just using the session name spark for compatibility with the spark shell.

thanks agreed -- the intention isn't to support more than one, which afaik is not supported by spark at all, but just to allow you to pick the name.  it should be an advanced config that is not normally visible.
we'll get there.


Add support to be loud in other languages

By specifying a language, as a string, to the loud-function, you can be loud in other languages.

I opened a PR on your fork for some suggested improvements.

This is great! Thanks @lekoaf & @colinvh


[BUGFIX] Implement Focus Out Event Handling for Input Controls

This PR adds an onBlur event handler to the input control in Taipy GUI, ensuring that input validation is triggered when the user focuses out of the input field. Fixes #2023 @FabienLelaquais @jrobinAV
Changes:

Added handleBlur function to dispatch the update action when the input field loses focus.
Ensured that all input types (text, number, date) are affected by this change.

Acceptance Criteria:

Input controls should now validate on focus out, equivalent to pressing the Enter key.
All new code is unit tested with a code coverage of at least 90%.

@UTK-a-RSH Thanks for not approving PR :-)

Hi @nagarajpandith, are you still working on this ?
If you are, please, answer the questions
If you are not, please close this PR


fix autoHeight to work correctly when used with centeredSlides param

resolves #3448

Hi! Thanks, but there is much simpler fix i pushed in 6deb1c7db9f845cb9d5c0fcff201d7ff1e030682


Permissions Problems

I've tried making a custom group, which should have worked just fine seeing as how I copied settings from the premade groups. Even when trying to add someones ID and give them InstaSkip it wouldn't work no matter what I tried. Please help because I don't know what I'm doing wrong.

Is it also possible to add a second owner to the bot? I feel like this would be easier than trying to make the IDs work.

Our permissions documentation is here: https://github.com/Just-Some-Bots/MusicBot/wiki/Permissions
To simulate having multiple owners, we suggest adding users to the MusicMaster group.


Afloat and SizeWell Window Plugins Not Working On 10.13

Both Afloat and SizeWell don't work on my config of macOS 10.13 (High Sierra).  I don't know if mySIMBL needs an update to correct this issue or if the plugins themselves need bug fixing.  The versions I am using are mySIMBL 0.5.3 (29), Afloat 2.5.2 and SizeWell 0.8.2. All of these are the latest versions that I found.  As a side note, I am using other mySIMBL plugins that work fine on my machine.

Afloat is working for me on 10.13.2 ?
Not sure about what SizeWell is but I'd guess it's broken and since I don't maintain it I can't help with that one.


Added Logout and Reset Password succesfully

Description of work
Hey @VanshKing30, I have completed integrating authentication functionalities for the users.
Now, our system can successfully execute :

Login for both students and Canteen
Logout for both students and Canteen
Reset the Password for both types of users

Note - I have used cookie parser middleware in the auth middleware for extracting cookies.
Screenshots of work done

Login

See, here you can see the token in response to the login request.
So, this token would be removed as we hit the logout route.

Logout

See, the tokens are successfully removed.

Reset Password

Note - I have only added screenshots of Student section but Canteen portion is also done.
Please, provide if any more changes required!!

Did my PR  successfully merge?


MUIC-502: Remove "print" calls from the Widgets

I'll create a ticket for logging in debug runs
No requirement per se for the engagement existing, but seeing as this is not currently handled and if we wan't to handle it would be very difficult with this approach (probably easier in the poc), I think it makes sense. Of course in ideal world, we'd be able to resume, maybe?

I'll create a ticket for logging in debug runs No requirement per se for the engagement existing, but seeing as this is not currently handled and if we wan't to handle it would be very difficult with this approach (probably easier in the poc), I think it makes sense. Of course in ideal world, we'd be able to resume, maybe?

yep, looks like we could resume the engagement just to call rootCoordinator?.event(.maximized). But we could take a look at this more deeply in the future.

Maybe better to discuss it at refinement session before commiting changes to possibly not introduce new error we would have to deprecate later

@kuldar-daniel  sorry for a long read under this simple PR, but I did some investigation and push one additional commit with swiftgen template that we could apply to this case. Please pull the latest commit and build the project to check the results. Perhaps it will be a better solution than the addition optionality and execution fatalError. Please ping me directly for some additional information/discussion.
Thank you.


Fix coal integration

Fix some coal related issue:

unittest/parallel-geometry.cpp fail because of this issue https://github.com/coal-library/coal/issues/636

Hi ! This project doesn't usually accept pull requests on the main branch.
If this wasn't intentionnal, you can change the base branch of this PR to devel
(No need to close it for that). Best, a bot.


Rather than include the ruby rack application, we should port the web UI to node

There is now a UI for node-resque as an actionhero plugin https://github.com/evantahler/ah-resque-ui


add eVPN support

Hello,has evpn add family been supported by veos? thanks!

Hello, looking for this today. Is this no longer supported?


ubuntu_kafka1_1_fa91fb287f60 exited with code 137

Hello,
I'm trying to use it in a NAT network with Vbox, steps:
docker-compose -f zk-single-kafka-single.yml down
export DOCKER_HOST_IP=<IP_ADDRESS>
rm -rf zk-single-kafka-single
docker-compose -f zk-single-kafka-single.yml up
...
icaStateMachine)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:56,658] INFO [PartitionStateMachine controllerId=1] Initializing partition state (kafka.controller.PartitionStateMachine)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:56,703] INFO [PartitionStateMachine controllerId=1] Triggering online partition state changes (kafka.controller.PartitionStateMachine)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:56,749] INFO [PartitionStateMachine controllerId=1] Started partition state machine with initial state -> Map() (kafka.controller.PartitionStateMachine)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:56,756] INFO [Controller id=1] Ready to serve as the new controller with epoch 1 (kafka.controller.KafkaController)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:56,813] INFO [RequestSendThread controllerId=1] Controller 1 connected to kafka1:19092 (id: 1 rack: null) for sending state change requests (kafka.controller.RequestSendThread)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:56,835] INFO [Controller id=1] Removing partitions Set() from the list of reassigned partitions in zookeeper (kafka.controller.KafkaController)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:56,855] INFO [Controller id=1] No more partitions need to be reassigned. Deleting zk path /admin/reassign_partitions (kafka.controller.KafkaController)
zoo1_1_b1281ae2f3c5 | 2018-12-20 11:42:57,099 [myid:] - INFO  [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@596] - Got user-level KeeperException when processing sessionid:0x167cb6c42c90001 type:multi cxid:0x36 zxid:0x1e txntype:-1 reqpath:n/a aborting remaining multi ops. Error Path:/admin/reassign_partitions Error:KeeperErrorCode = NoNode for /admin/reassign_partitions
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:57,531] INFO [Controller id=1] Partitions undergoing preferred replica election:  (kafka.controller.KafkaController)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:57,762] INFO [Controller id=1] Partitions that completed preferred replica election:  (kafka.controller.KafkaController)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:57,764] INFO [Controller id=1] Skipping preferred replica election for partitions due to topic deletion:  (kafka.controller.KafkaController)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:57,803] INFO [Controller id=1] Resuming preferred replica election for partitions:  (kafka.controller.KafkaController)
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:57,822] INFO [Controller id=1] Starting preferred replica leader election for partitions  (kafka.controller.KafkaController)
zoo1_1_b1281ae2f3c5 | 2018-12-20 11:42:57,956 [myid:] - INFO  [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@596] - Got user-level KeeperException when processing sessionid:0x167cb6c42c90001 type:multi cxid:0x38 zxid:0x1f txntype:-1 reqpath:n/a aborting remaining multi ops. Error Path:/admin/preferred_replica_election Error:KeeperErrorCode = NoNode for /admin/preferred_replica_election
kafka1_1_fa91fb287f60 | [2018-12-20 11:42:58,213] INFO [Controller id=1] Starting the controller scheduler (kafka.controller.KafkaController)
kafka1_1_fa91fb287f60 | [2018-12-20 11:44:14,887] WARN Client session timed out, have not heard from server in 4631ms for sessionid 0x167cb6c42c90001 (org.apache.zookeeper.ClientCnxn)
kafka1_1_fa91fb287f60 | [2018-12-20 11:45:42,158] INFO Client session timed out, have not heard from server in 4631ms for sessionid 0x167cb6c42c90001, closing socket connection and attempting reconnect (org.apache.zookeeper.ClientCnxn)
zoo1_1_b1281ae2f3c5 | 2018-12-20 11:44:51,281 [myid:] - INFO  [SessionTracker:ZooKeeperServer@358] - Expiring session 0x167cb6c42c90001, timeout of 6000ms exceeded
zoo1_1_b1281ae2f3c5 | 2018-12-20 11:46:44,050 [myid:] - INFO  [ProcessThread(sid:0 cport:2181)::PrepRequestProcessor@487] - Processed session termination for sessionid: 0x167cb6c42c90001
zoo1_1_b1281ae2f3c5 | 2018-12-20 11:46:44,075 [myid:] - INFO  [SyncThread:0:NIOServerCnxn@1008] - Closed socket connection for client /<IP_ADDRESS>:48598 which had sessionid 0x167cb6c42c90001
zoo1_1_b1281ae2f3c5 | 2018-12-20 11:46:44,088 [myid:] - WARN  [NIOServerCxn.Factory:<IP_ADDRESS>/<IP_ADDRESS>:2181:NIOServerCnxnFactory@213] - Ignoring unexpected runtime exception
zoo1_1_b1281ae2f3c5 | java.nio.channels.CancelledKeyException
zoo1_1_b1281ae2f3c5 |   at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
zoo1_1_b1281ae2f3c5 |   at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:87)
zoo1_1_b1281ae2f3c5 |   at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:182)
zoo1_1_b1281ae2f3c5 |   at java.lang.Thread.run(Thread.java:745)
ubuntu_kafka1_1_fa91fb287f60 exited with code 137
ifconfig:
br-7904a60fc3b9: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
inet6 fe80::42:c6ff:fea5:a632  prefixlen 64  scopeid 0x20
ether 02:42:c6:a5:a6:32  txqueuelen 0  (Ethernet)
RX packets 1  bytes 28 (28.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 12  bytes 936 (936.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
ether 02:42:77:11:f2:5e  txqueuelen 0  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
inet6 fe80::a00:27ff:fe2e:488c  prefixlen 64  scopeid 0x20
ether 08:00:27:2e:48:8c  txqueuelen 1000  (Ethernet)
RX packets 282686  bytes 388713407 (388.7 MB)
RX errors 1795  dropped 0  overruns 0  frame 0
TX packets 32242  bytes 2453771 (2.4 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 9  base 0xd020
Thank you in advance

I can't reproduce sorry... unsure what's happening?
Try using a previous tag for example https://github.com/simplesteph/kafka-stack-docker-compose/tree/v5.0.0


Home Assistant and MQTT

Hello,
First of all you done a great job with pylips, so thank you very much for your efforts!
Now my situation and problem ....
I own to Philips TVs that supports pylips. With the last firmware it wasn't possibile to change the source "hdmi1" - "hdmi4" with my hormony hub. So I've looked for an other way to chnage the input channel of my tv. I've installed pylips and checked that it works.
So python3 pylips.py --config /root/docker_pylips/settings-GaestezimmerTV.ini --command input_hdmi_1" chnges to hdmi1 without any problem.
So my next step was to run pylips in MQTT-mode. I've an MQTT broker "mosquitto" running on my home sssistant system.
[DEFAULT]
verbose = True
mqtt_listen = True
mqtt_update = True
num_retries = 3
update_interval = 3

[TV]
host = <IP_ADDRESS>
port = 1926
apiv = 6
user = PbNyDWWLxwUzrk7z
pass = 2d9ca40c7d0bd7d2c3dadeef211d2eda2d757a575fkzgb4d7c927ab774620
protocol = https://

[MQTT]
host = hassio
port = 1883
user = <mqtt-broker>
pass = <password>
tls = False
cert_path =
topic_pylips = GaestezimmerTV_Command
topic_status = GaestezimmerTV_Status

On start, I received the following on the topic "GaestezimmerTV_Status":
{
    "powerstate": "On",
    "volume": 0,
    "muted": false,
    "cur_app": {
        "app": "TV",
        "channel": {
            "channel": {
                "ccid": 244,
                "preset": "9",
                "name": "kabel eins"
            },
            "channelList": {
                "id": "allsat",
                "version": "2"
            }
        }
    },
    "ambilight": {
        "styleName": "Lounge light",
        "isExpert": false,
        "menuSetting": "FRESH_NATURE",
        "stringValue": "Fresh Nature"
    },
    "ambihue": "On"
}

Now my problem, If I try to send:
"command":"powerstate"
 "body": "Off"

to the topic "GaestezimmerTV_Command" pylips stops with an error:
python3 pylips.py --config /root/docker_pylips/settings-GaestezimmerTV.ini
Connected to MQTT broker at hassio
Traceback (most recent call last):
  File "pylips.py", line 470, in <module>
    pylips = Pylips(args.config)
  File "pylips.py", line 103, in __init__
    self.start_mqtt_listener()
  File "pylips.py", line 379, in start_mqtt_listener
    self.mqtt.loop_forever()
  File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1779, in loop_forever
    rc = self.loop(timeout, max_packets)
  File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1181, in loop
    rc = self.loop_read(max_packets)
  File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1572, in loop_read
    rc = self._packet_read()
  File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 2310, in _packet_read
    rc = self._packet_handle()
  File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 2936, in _packet_handle
    return self._handle_publish()
  File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 3216, in _handle_publish
    self._handle_on_message(message)
  File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 3444, in _handle_on_message
    self.on_message(self, self._userdata, message)
  File "pylips.py", line 345, in on_message
    message = json.loads(msg.payload.decode('utf-8'))
  File "/usr/lib/python3.7/json/__init__.py", line 348, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.7/json/decoder.py", line 340, in decode
    raise JSONDecodeError("Extra data", s, end)
json.decoder.JSONDecodeError: Extra data: line 1 column 10 (char 9)

Please help!!

Hi,
I thought I've found the problem. The JSON was malformed. The correct data for MQTT is:
{
   "command":"input_hdmi_1"
 }

So my only wish were that it would be geat, if the source would be a little bit more resistant for malformed JSONs.

Hi,
Good point on the malformed JSONs, thanks! I'll fix it in the next release. Also powerstate only returns the current power state, it does not allow changing it. Use {"command": "standby"} instead.


Azure Key Vault Storage Account Keys implementation using ARM template.

Hello,
I am interested to know if there is possibility of key rotation using ARM template, apart from PowerShell or C#, to implement Azure Key Vault Storage Account Keys. I am able to provision both resources and write secrets to keyvault using ARM template(in VSTS), but i want to know if it is possible to implement rotation of keys with same ARM template, which would reduce a post provision step using PowerShell.
Thanks
Chaitanya Alladi.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: cebec73e-e7f4-75c5-2068-ae89f12d8d95
Version Independent ID: e2497a7b-3b5f-554a-1a31-da540740fcc9
Content: Azure Key Vault Storage Account Keys
Content Source: articles/key-vault/key-vault-ovw-storage-keys.md
Service: key-vault
GitHub Login: @lleonard-msft
Microsoft Alias: alleonar

@chaitualladi Thanks for your feedback! We will investigate and update as appropriate.

@MohitGargMSFT the above link is about Storage Service Encryption (SSE), which is not what i'm looking for, but rotation of storage keys using ARM, if possible other than powershell. I do not see any ARM implementation examples for rotation of keys, so i was curious to know if we can or not. If not i can stick to my implementation using powershell though.

@chaitualladi I tired to reach out to some the service team contact. It seems the methods I mentioned in my earlier comment are only available at this time. I will you know in case I get any update information on it. For now you can safely assume that powershell or API is the way to go.

@MohitGargMSFT Thanks Mohit!


can't login with admin

      docker run -p 6443:443 \

       --env PHPLDAPADMIN_LDAP_HOSTS=ldap.example.com \

       osixia/phpldapadmin:latest

Login DN: cn=admin,dc=example,dc=org (cn=admin,dc=ldap,dc=example,dc=org)
password: admin
Response:
Unable to connect to LDAP server ldap.example.com
Error: Can't contact LDAP server (-1) for user
Failed to Authenticate to server
Invalid Username or Password.

@zWingz , wondering how you fix it?
I got the same issue..............
I ran it by:
docker run -p 6443:443 \
       --env PHPLDAPADMIN_LDAP_HOSTS=localhost \
       --detach osixia/phpldapadmin:0.7.1

Appreciate it in advance :)

@keenkit confirm PHPLDAPADMIN_LDAP_HOSTS is right

Thanks @zWingz ..
It works by By running the script:
#!/bin/bash -e
docker run --name ldap-service --hostname ldap-service --detach osixia/openldap:1.2.1
docker run --name phpldapadmin-service --hostname phpldapadmin-service --link ldap-service:ldap-host --env PHPLDAPADMIN_LDAP_HOSTS=ldap-host --detach osixia/phpldapadmin:0.7.1

PHPLDAP_IP=$(docker inspect -f "{{ .NetworkSettings.IPAddress }}" phpldapadmin-service)

echo "Go to: https://$PHPLDAP_IP"
echo "Login DN: cn=admin,dc=example,dc=org"
echo "Password: admin"

I got
Go to: https://<IP_ADDRESS>
Login DN: cn=admin,dc=example,dc=org
Password: admin

which is good!

Not sure how you fixed it?

docker run -p 6443:443 \
       --env PHPLDAPADMIN_LDAP_HOSTS=localhost \
       --detach osixia/phpldapadmin:0.7.1

the script only start the phpAdminServer,
but the ldap server is not running.
you need to start the LDAP SERVER at first
and use PHPLDAPADMIN_LDAP_HOSTS connect to LDAP SERVER

yes.. True, need to start LDAP SERVER first.
Did you start up ldap server simply by:
docker run --name my-openldap-container --detach osixia/openldap:1.2.1

which is indicated in the https://github.com/osixia/docker-openldap#quick-start ?

@keenkit https://github.com/materliu/ldap-docker-compose

I had some problem，but I changed the script that the introduce give . and it works well
#!/bin/bash -e
docker run -p 389:389 -p 636:636 --name ldap-service --hostname ldap-service -v '/Users/su/tmp/openldap/database:/var/lib/ldap' -v '/Users/su/tmp/openldap/config:/etc/ldap/slapd.d'  --detach osixia/openldap:1.2.4
docker run  -p 6443:443 --name phpldapadmin-service --hostname phpldapadmin-service --link ldap-service:ldap-host --env PHPLDAPADMIN_LDAP_HOSTS=ldap-host --detach osixia/phpldapadmin:0.8.0
echo "Go to: https://localhost:6443/"
echo "Login DN: cn=admin,dc=example,dc=org"
echo "Password: admin"

I face the same problem，and I solve it with your solutions. "--link ldap-service:ldap-host and PHPLDAPADMIN_LDAP_HOSTS = ldap-host. If your problem is not caused by firewall or ldap didn't start at first etc. I guess your problem is the same as mine. And by the way I didn't create a new network for this, I use the existing network.


Tabster should include a way to indicate that it was the cause of programmatic focus

When focus has been moved programmatically because of Tabster (say to restore focus to a trigger element after dismissing a popover or dialog), there should be a way to indicate that tabster was the cause of this programmatic focus (maybe through the keyborg event).

@ling1726 I know that you can check if something was programmatically focused or not, but I don't think you can check whether tabster was the cause of the focus moving programmatically or if something else was the cause, can you?

Ah @khmakoto I see what you mean. Can you please describe the scenario where this would be needed?

It's for scenarios like the one in Tooltip here, where we do not want a tooltip to show if things like closing another surface would cause focus to be restored to a trigger button with a Tooltip attached to it. However, there are products that have a mixture of tabster usage + their own custom solutions for certain tab-related scenarios where they sometimes move focus programmatically and would like the Tooltip to show up in those scenarios.

Tabster dispatches tabster:movefocus event every time before it moves focus. See TabsterMoveFocusEventDetail for the event's detail signature (it has next element and related keyboard event, if any). You can also can call preventDefault() and Tabster won't handle it at all (but you will have all the data about what it wanted to focus).

Tabster also adds typings for addEventListener() so that you don't need to import the event signature directly, it will be inferred automatically when you do element.addEventListener('tabster:movefocus', e => ...).


USB-C port cannot be used as host

For some time now I've heard of people who need USB 3 strugging to use the USB-C port, which is the BBAI's only USB 3 port, in host mode (using a charging hub).  Recently I finally got around to digging into it, and my conclusion is:  it cannot work,  at least not if either the BBAI or the hub complies with the USB standard (if both violate USB standard then those violations might perhaps in some cases fortuitously interact to yield a working result, but that's obviously terrible to rely on).
Here's why:
When connecting devices via USB-C, initially one side has to become sourcing host (i.e. host data-role and source power-role) and one side has to become sinking device (i.e. device data-role and sink power-role), or no connection will be established.  Becoming initial-host requires being able to supply VBUS power, hence a VBUS-powered device like the BBAI will always initially negotiate device role on connect.  Even if the BBAI is powered via P9, it lacks the ability the provide VBUS to the USB-C connector, hence it still cannot negotiate initial host role.
After these initial roles are established it is possible for the devices to subsequently swap data role (i.e. which side is host and which side is device) and/or power role (i.e. which side is source (i.e. supplies VBUS power) and which is sink), which is the only way you can become a sinking host or sourcing device.  However, these role swaps can only be done using USB Power Delivery (PD) signalling.  Unfortunately the USB-C controller on the BBAI (TUSB322I) does not support PD signalling, nor does its replacement on rev A2 (HD3SS3220), hence it cannot perform a data role swap.
Since the BBAI can neither be initial-host nor perform a data role swap, there is no way for it to ever have host role on its USB-C port.  Forcing the usb subsystem into host mode via sysfs will merely cause the BBAI to violate the usb specification and may result in a drive conflict.  It does not change the negotiated role, hence it will not result in successful connection (unless the other side also violates the usb specification).
The only real fix is to use a USB-C controller with support for PD communication, specifically data role swap.  (Or, in retrospect, another option would have been to use a dedicated USB3 host (instead of the USB2 host port) and limit the Type-C port to USB2 instead of doing it the other way around, since it seems more likely people would want the beaglebone to be USB3 host than to be USB3 device.)

This make the whole USB-C situation even more ridiculous.  Running the BBAI at full speed requires easily north of 2A at 5V which is fine for a USB-C Powersource (although even most Powerbanks are more likely to suport 9V@2A than 5V@2.5A), but in the likely case of using it as a USB client, even my beefy Thinkpad sometimes fail to deliver. So one might like to use a powered HUB, but that leaves us with a USB 3 Type A Port, as true USB-C are not existant as of now, and USB Type A is rated at a 0.9A, while most hubs will deliver 1.5-2A with a reasonable voltage Ddop, at times (boottime to be precise) the voltage browns out rebooting the BBAI. Learning that it will also not work as a host, which could be done as most USB-C Hubs feature a USB-C power input, makes one really wish to have the good old barrel jack back. To sum it up: To use USB 3 at all it must be powered via P9.
Note that the preinstalled debian comes with an older kernel having a 400Mhz mode available, which uses less power at the cost of beeing unbearably slow.

You just need a splitter cable to provide power externally (or from the other USB port - lots of those online for use with smartphones and power banks) and it works just fine. You might have to wait for the attached device to reconnect if you restart the BBAI since the vbus won't loose power but it usually takes less than 10 seconds.

You just need a splitter cable to provide power externally

I'm assuming you replied purely based on the subject instead of actually reading the post, since this is an awful "solution" for something that is not even the problem under discussion in this thread. I was already assuming the connected device supplies power, typically by using a charging hub/dock, since otherwise the BBAI obviously doesn't have power.  There is no way to make a USB-C "splitter cable" unless either

there's actually a whole bunch of electronics in the "cable"
the cable is a blatant violation of every relevant spec, only works in limited situations with certain devices (rather than consistently and reliably), sabotages the overcurrent protection designed into the usb standard, and probably risks damaging devices.


[Feature] Add a new Rt notebook with MCMC

Bring in this Rt estimate https://github.com/k-sys/covid-19/blob/master/Realtime Rt mcmc.ipynb
Also check https://github.com/rtcovidlive/covid-model/blob/master/rtlive-model.ipynb

@heerden could you assist and just have a 2nd rt file just denoted that it is using MCMC

@vukosim very excited that they released an updated MCMC model. I will review it this weekend but have a few initial questions.
To match the US Covid Tracking Project daily data set to our SA data sets, can you confirm if these fields represent the same meaning?
US positive -> total (covid19za_provincial_cumulative_timeline_confirmed)
US total -> cumulative_tests (covid19za_timeline_testing)
We will then be limited to only country-level Rt results with this multivariable model.

@vukosim The draft is available on my fork
https://github.com/heerden/covid-model/blob/master-za/rtlive-model-za.ipynb. Will format for export and add all the model files to our repo later in the week.
With the new model Rt seems very constant at 1.2 for the last month.

Thanks @heerden
Can you check the current challenge with the automation and also add the mcmc automation. LGTM

@vukosim Sorry, I should have followed up earlier on the last 3 automated action failures, but had another deadline.
Thanks for confirming the MCMC model.
The remote server is extremely finicky with pymc3 in a notebook, thus I will use a pure python script.
Will submit daily manual results for now and commit the automation on the weekend.


feat!: implement ADR-017 subspace grant

Description
Closes: #XXXX
Forwarding #1057
This PR implements ADR-017 subspace grant feature.

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[ ] followed the guidelines for building modules
[ ] included the necessary unit and integration tests
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Note: ExpiringAllowancesQueue requires Cosmos-SDK 0.46.0 backporting. I will open a PR to our cosmos-sdk fork repo.


riff system uninstall should remove Istio by default

Currently to remove Istio you must opt-in during riff system uninstall --istio. This is backwards, riff system uninstall should remove all resources created by riff system install. Istio should be removed by default, the exceptional case is wanting to preserve istio between installs.
I propose we remove the --istio flag. If still have a strong use case for keeping Istio around, we can add a --keep-istio flag for users who want to preserve the Istio install. (The original rational was to make it easier for rapid install/uninstall cycles, but I'd argue we're not actually testing full uninstall/install in that case). Keeping Istio between installs implies that version of Istio is compatible with the new Knative install, which may not be true.
cc @trisberg

The intention was to separate Istio from Knative in terms of installation. We wanted to allow for installing riff on a cluster that already had Istio installed. In that case there is no way of knowing where Istio came from. It seems that the goal for Knative was to be able to use a standard Istio install separate from Knative.
In practice Knative and Istio are still installed together most of the time for riff. I don't see a strong point for changing the flags but don't really mind if we do change it to --keep-istio or something like --knative-only

The riff system commands no longer exist. The cnab bundle is responsible for removing resources it created during uninstall


Training points

Training set point selection method and balancing

see also https://github.com/bcgov/ccissr/issues/4


Multiple Textbox

Hello. I need to create textbox group to take value for each month in a year. I created all textboxes in a loop. However I wonder if there exist more efficient way to do that.
Actually I should edit the CSS. Can I change CSS of a group of textboxes? (I would like to create multiple inputs like the bootstrap example Multiple inputs CSS )

I did it using XElement.


fix: Do not reset RegexLogitsProcessor._fsm_state

Closes #757

Looks good to me, thank you for the fix!


docs: state management part 2

builds on #8547:

focuses on how to prevent shared state on the server rather than saying 'you don't need to worry about this if you build an SPA', because that will unduly encourage people to build SPAs
separate section for stores+context
explanation of component state preservation
mention snapshots
remove form stuff

Yes yes yes! This is the way, with examples of what to do, but more important is what not to do! Thanks!


Race condition?

Thanks for your work on this. It looks very promising.
I'm running -portable on Linux. I've gotten it built and am able to run a command to register and request some certs from the staging service. However, during this run I get the following:
./acme-client -s -vvNnm -C /acme/challenges -c /acme/public -k /acme/private/domain.pem -f /acme/account/account.pem example.com
acme-client: /acme/account/account.pem: generated RSA account key
acme-client: /acme/private/domain.pem: generated RSA domain key
acme-client: https://acme-staging.api.letsencrypt.org/directory: directories
acme-client: acme-staging.api.letsencrypt.org: DNS: <IP_ADDRESS>
acme-client: acme-staging.api.letsencrypt.org: DNS: 2001:418:1416:284::3d5
acme-client: acme-staging.api.letsencrypt.org: DNS: 2001:418:1416:29d::3d5
acme-client: transfer buffer: [{ "key-change": "https://acme-staging.api.letsencrypt.org/acme/key-change", "new-authz": "https://acme-staging.api.letsencrypt.org/acme/new-authz", "new-cert": "https://acme-staging.api.letsencrypt.org/acme/new-cert", "new-reg": "https://acme-staging.api.letsencrypt.org/acme/new-reg", "revoke-cert": "https://acme-staging.api.letsencrypt.org/acme/revoke-cert" }] (372 bytes)
acme-client: https://acme-staging.api.letsencrypt.org/acme/new-authz: req-auth: [mydomain]
acme-client: acme-staging.api.letsencrypt.org: cached
acme-client: acme-staging.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "detail": "No registration exists matching provided key", "status": 403 }] (120 bytes)
acme-client: bad exit: netproc(15477): 1

It appears that the client is trying to authorize to request certificates before it's registered.
I've only begun digging into what's happening, but in the course of diagnosing, I encountered a Heisenbug: some of my debug printfs caused the whole routine to work. Reducing this, if I put a usleep(500) at the top of xrun(), I get a successful run every time.  If I remove the usleep(), it fails every time.  (I am clearing and replacing the whole of /acme with each run.)
This begins to smell of a race condition, so I thought I'd go ahead and report it even though I don't have a solution yet.

Yes, I think you're right.  I'll implement a fix as soon as I can.  (Basically, the key is created and then the process checks if it's there: if it is, the -N or -n flags are ignored.)

That's what it seemed like, but orchestrating a fix among the co-processes is probably better left to you than me. :)  Thanks, much appreciated!

I just merged the above fix (in the main codebase) into the portable one.  It pushes the check into the main process, splicing out the arguments on failure.  Does this fix your issue?

Yes, this is working for me. Thanks for the quick fix!

Still needs work, though, for situations like -nN.

Works now for all possible invocations.  Can you test it again?  If it works fine, close out and it'll be in the next release.


Try extends instead of Super

Hi,
the onFail method in the Try class, I think, should extends the generic exception instead of using super.
In this way it will be possible to have a more generic way to act based on specific exceptions.
Thanks

fixed in v4.0.3

Fixed in v4.0.3 and on Master


scripts: zephyr modules: introducing Zephyr module dependency handling

This commit introduces the possibility of adding dependencies between
Zephyr modules to ensure that a Zephyr module on which other modules
depends is processed first.
This is configured in the zephyr/module.yml file, as example:
build:
  cmake: .
  depends:
    - fatfs

Signed-off-by: Torsten Rasmussen<EMAIL_ADDRESS>

100% on board with the idea, just would like to see more details on the semantics here.

Looks good, but how/where are unmet dependencies handled? I see handling for cyclic dependencies, but no explicit handling/error for unmet dependencies.

An unmet dependency like:
build:
  cmake: .
  depends:
    - invalid_project

will never get removed from dep_modules, and as such show up at the final if dep_modules:.
Will adjust error description.


:book: Add hugo documentation structure to docs

Summary

support for versioned docs
docs are contained in the repo itself
docs are built and deployed to github pages on every commit to main and release
breaking changes to docs structure

Signed-off-by: Avinal Kumar<EMAIL_ADDRESS>

If we merge this, where can I access the docs?

If we merge this, where can I access the docs?

Once published it will be accessible at https://kcp-dev.github.io/kcp . I haven't updated the publishing action yet, working on it #2153

/lgtm
/approve

/lgtm


Added Character perturbations along with a test

@blackrosedragon2  there is an issue with black formatting for the tests
https://pypi.org/project/black/ Run this in the repository root directory
black .

This shall solve all the issues

Thank you @someshsingh22


Development work for Work page

This is a placeholder for the development work that will take place this quarter. Issues will be built out once designs and content are done.

@thekaveman @angela-tran Designs and copy for the Work page are finalized within this Figma file. These are the same designs we reviewed with Segacy on 1/8. Sarah kindly inserted the final copy and cleaned it up for us, along with addressing comments from Machiko. Let us know if you have any questions or need anything else. Thanks! cc @AnthonyRollins

Here's what I'm thinking for breaking up the development work:
This first task is

[ ] Add new /our-work page with empty sections with background colors

All tasks below are blocked until the first task is done. Once unblocked, they can be worked on by anyone in any order. Just make sure to stay in your section.

[ ] Implement top "Our Work" section

should be similar to other pages' top sections

[ ] Implement "What We Do" section

add accordion and the styles for it specified in Figma
add signpost icon

[ ] Implement "What We've Done" section

implement cards

tags on cards
non-image card
image card

card contents are driven by a data file?
"See more projects" button and "See fewer projects" button -> reference team member section from /about for how this is done

[ ] Add testimonial section

should be able to reference testimonial section from /about

[ ] Add "Ready to work together?" section
[ ] Add menu item for /our-work page named "Our Work"

I'll wait for #204 to be merged in before creating the rest of the tasks, so we can test out the workflow. (And so I don't have to manually set the project 😄)


Refactor smoketest script

Perform a bit of smoketest refactoring and fix up a few bugs.

Update alert trigger to use startsAt in order to potentially speed up
delivery of the alerts. Failures in the SNMP_WEBHOOK_STATUS seems to
be primarily to delayed alert notification through
prometheus-snmp-webhook.
Add an alert clean up task as part of the clean up logic at the end.
Update openssl x509 to not use the -in flag which seems unnecessary
and on some systems causes a failure.
Add new SMOKETEST_VERBOSE boolean so local testing can skip massive
amounts of information dumped to stdout.
Remove curl pod using label selector for slightly cleaner output.
Update failure check to combine RET and SNMP_WEBHOOK_STATUS since
testing seems to show changes are slightly more reliable.

Actually I thought both OCP 4.12 and 4.10 failed, but it seems that the OCP 4.10 CI system failed again. I've done local testing and gotten multiple passes to happen, and it looks like OCP 4.12 has also passed. However I see this at the very end:
*** [FAILURE] Smoke test job still not succeeded after 300s

Then I can see in the logs output for the snmp-webhook receiver that it never got an alert:
*** [INFO] Logs from snmp webhook...
DEBUG:prometheus_webhook_snmp.utils:Configuration settings: {"debug": true, "snmp_host": "<IP_ADDRESS>", "snmp_port": 162, "snmp_community": "public", "snmp_retries": 5, "snmp_timeout": 1, "alert_oid_label": "oid", "trap_oid_prefix": "<IP_ADDRESS>.4.1.50495.15", "trap_default_oid": "<IP_ADDRESS>.4.1.504<IP_ADDRESS>.1", "trap_default_severity": "", "host": "<IP_ADDRESS>", "port": 9099, "metrics": false, "cert": "", "key": ""}
INFO:cherrypy.error:[15/Sep/2023:20:55:15] ENGINE Listening for SIGTERM.
INFO:cherrypy.error:[15/Sep/2023:20:55:15] ENGINE Listening for SIGHUP.
INFO:cherrypy.error:[15/Sep/2023:20:55:15] ENGINE Listening for SIGUSR1.
INFO:cherrypy.error:[15/Sep/2023:20:55:15] ENGINE Bus STARTING
INFO:cherrypy.error:[15/Sep/2023:20:55:15] ENGINE Serving on http://<IP_ADDRESS>:9099
INFO:cherrypy.error:[15/Sep/2023:20:55:15] ENGINE Bus STARTED

And I see near the top that the curl pod actually errored out (not sure why...):
*** [INFO] Creating smoketest jobs...
No resources found
job.batch/stf-smoketest-smoke1 created
*** [INFO] Triggering an alertmanager notification...
*** [INFO] Create alert
No resources found
pod/curl created
*** [INFO] Waiting to see SNMP trap message in webhook pod
*** [INFO] Waiting on job/stf-smoketest-smoke1...
job.batch/stf-smoketest-smoke1 condition met
*** [INFO] Checking that the qdr certificate has a long expiry
*** [INFO] Showing oc get all...
NAME                                                            READY   STATUS      RESTARTS   AGE
pod/alertmanager-default-0                                      3/3     Running     0          3m17s
pod/cert-manager-operator-controller-manager-7fccfddcbb-bnrt4   2/2     Running     0          14m
pod/curl                                                        0/1     Error       0          2m31s

Not sure why the smoketest stage actually passed then. Seems like I must have broken something there.

OK I'm merging this down. It's landing in issue/306 so we still have an opportunity to adjust if we want, but I'm looking to get everything merged down. Passes 1 of 2 CI systems, so good enough for merging to not-master :)


Chaining Asynchronous Functions Node.js with mongoskin

I have been reading many posts on how to chain asynchronous functions but I just can't seem to get it right!
As the title indicates. I am trying to chain mongoskin database calls together, so that i can gather all the information in chunks and then finally send the accumulated result in the response.
I have the object user as :
var User = {
       username: 'someusername',
       accounts: [{name: 'account_1'}, {name: 'account_2'} , ...]
   }

For each of the accounts I need to gather data and then send the accumulated data in the response. So i am using the following for loop to iterate over the accounts:
var promise = require('bluebird');
var db = require('mongoskin').db('mongodb://localhost/someDB');

for(var x in user.accounts){
   //Fetch account data
   user.accounts[x].accountData = fetchAccountData(user.accounts[x].name);
}

//Finally send the collected response
response.send(user);

And the function fetchAccountData looks like the following:
function fetchAccountData(screen_id){
   db.collection('master')
     .aggregate([
        {$match: {screen_id: screen_id}}
      ], function(err, res){
           if(err)
              return null;
           else{
              console.log('Done', screen_id);
              return res;
          }
     });
 }

How can i chain this to have the following algorithm:
 start:
      for each account:
           fetchDataForAccount
      Finally:
           Send Response

Please ask support questions on Stack Overflow or IRC as indicated clearly in the README file - see the contributing.md file for what constitutes of a good issue for the bug tracker - this is a link you get before posting an issue.
Happy coding!


Added recursive types

Pull Request Test Coverage Report for Build 69

0 of 28 (0.0%) changed or added relevant lines in 2 files are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.07%) to 1.769%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

underscore_semant/src/unify.rs
0
9
0.0%

underscore_semant/src/trans.rs
0
19
0.0%

Files with Coverage Reduction
New Missed Lines
%

underscore_semant/src/trans.rs
1
0.0%

tests/underscore_test.rs
1
71.11%

Totals

Change from base Build 67:
-0.07%

Covered Lines:
32

Relevant Lines:
1809

💛  - Coveralls


Build lws against monero <IP_ADDRESS>

Update monero-lws and build against version <IP_ADDRESS> of monero

Should be against 0.18 now.

Closed by #61 and #62


Compiled module's main function misnamed in ipython shell.

When compiling guppy in an ipython shell, instead of the main function being called main, it is called something like <ipython-input-3-3e9b5833de21> in the compiled hugr.
For example:
alec@QuantUK-6R64C14:~/r/guppy-integration$ uv run ipython
Python 3.12.3 (main, Nov  6 2024, 18:32:19) [GCC 13.2.0]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.29.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from guppylang import guppy
   ...: from guppylang.std.builtins import result
   ...: from guppylang.std.quantum import h, measure, qubit

In [2]: @guppy
   ...: def main() -> None:
   ...:     q0 = qubit()
   ...:     h(q0)
   ...:     result("m", measure(q0))
   ...:

In [3]: out = guppy.compile_module()

In [4]: "main" in str(out)
Out[4]: False

The <ipython-input-3-3e9b5833de21> is actually the name of the module. The main function isn't even being compiled...

The <ipython-input-3-3e9b5833de21> is actually the name of the module. The main function isn't even being compiled...

Ah yes you're right.


Preferences doesn't open

From<EMAIL_ADDRESS>on 2012-03-30T06:28:33Z
Spyder Version:  2.1.8
Python Version:  2.7.2
Qt Version:      4.7.4, PySide 1.1.0 on Windows
What steps will reproduce the problem?

Click the Tools menu header and then click the Preferences menu item What is the expected output? What do you see instead? The preferences window should display.  Instead, errors show up in the internal console.

Please provide any additional information below
. Internal console output:
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\spyderlib\spyder.py", line 1632, in edit_preferences
widget = plugin.create_configwidget(dlg)
File "C:\Python27\lib\site-packages\spyderlib\plugins_init_.py", line 159, in create_configwidget
configwidget.initialize()
File "C:\Python27\lib\site-packages\spyderlib\plugins\configdialog.py", line 46, in initialize
self.load_from_conf()
File "C:\Python27\lib\site-packages\spyderlib\plugins\configdialog.py", line 241, in load_from_conf
checkbox.setChecked(self.get_option(option, default))
RuntimeError: Internal C++ object (PySide.QtGui.QCheckBox) already deleted.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=980

From pierre.raybaut on 2012-03-30T09:46:51Z
This is already fixed in the development version (I'll have check the revision number before closing this issue).
So this is fixed in forthcoming v2.1.9.

From pierre.raybaut on 2012-03-30T13:53:29Z
Status: Duplicate
Mergedinto: 897


Small tweaks to nomad job, primarily

One important question -- you have source = "{{ .GitRepoURL }}" in the artifact clause.  I wasn't able to get that to work.  I had to use source = "git::{{ .GitRepoURL }}".  I also needed to populate GitRepoName with e.Repo.GetName() and not e.Repo.GetFullName(), which caused issues for me.

This PR is replaced by #15


nixos/zfs-replication: expected "âlz4câ" command missing

Describe the bug
I'm testing services.zfs.autoReplication out with the following configuration:
services.zfs.autoReplication = {
  enable = true;
  username = "root";
  host = "tmplt.dev";
  identityFilePath = /root/.ssh/id_backup;
  localFilesystem = "rpool/media/music";
  remoteFilesystem = "rpool/test_backup_music";
  followDelete = false;
};

Which yields the following:
# systemctl start zfs-replication
# systemctl status zfs-replication
● zfs-replication.service - ZFS Snapshot Replication
   Loaded: loaded (/nix/store/9vbrvymsbwg9590h05jq0jfdpi4x98gs-unit-zfs-replication.service/zfs-replication.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2020-06-19 21:30:55 CEST; 6min ago
     Docs: https://github.com/alunduil/zfs-replicate
  Process: 31171 ExecStart=/nix/store/amjy2bz5y33xjkyv0p4bhd201pffxwqh-zfs-replicate-1.1.14/bin/zfs-replicate --recursive -l root -i /root/.ssh/id_backup tmplt.dev rpool/test_backup_music rpool/media/music (code=exited, status=1/FAILURE)
 Main PID: 31171 (code=exited, status=1/FAILURE)
       IP: 18.9K in, 197.3K out
      CPU: 286ms

Jun 19 21:30:53 dulcia systemd[1]: Started ZFS Snapshot Replication.
Jun 19 21:30:55 dulcia zfs-replicate[31171]: Error: failed to create snapshot: 'rpool/media/music@initial': b'/usr/bin/env: \xe2\x80\x98lz4c\xe2\x80\x99: No such file or
directory\ncannot receive: failed to read from stream\n'
Jun 19 21:30:55 dulcia systemd[1]: zfs-replication.service: Main process exited, code=exited, status=1/FAILURE
Jun 19 21:30:55 dulcia systemd[1]: zfs-replication.service: Failed with result 'exit-code'.
Jun 19 21:30:55 dulcia systemd[1]: zfs-replication.service: Consumed 286ms CPU time, received 16.6K IP traffic, sent 61.3K IP traffic.

The error message, decoded, says:
$ python
>>> print('/usr/bin/env: \xe2\x80\x98lz4c\xe2\x80\x99: No such file or directory\ncannot receive: failed to read from stream\n')
/usr/bin/env: âlz4câ: No such file or directory
cannot receive: failed to read from stream

To Reproduce
Steps to reproduce the behavior:

Subscribe to nixos-20.03-small
Configure expected zfs datasets, create snapshot, generate keys, etc...
Deploy client host with the above configuration.
systemctl start zfs-replication

Expected behavior
A transmission of a snapshot from the client to tmplt.dev
Notify maintainers
@alunduil
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.36, NixOS, 20.03.2265.199de046888 (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.6`
 - channels(tmplt): `"nixos-20.09pre221814.10100a97c89"`
 - channels(root): `"nixos-20.03.2260.7bb2e7e0f69"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

At first glance this looks like the remote host doesn't have lz4 in its path when root logs in.  Can you confirm this by starting an SSH session to that host as root and doing a whereis lz4?

That was it: installing lz4 fixed it; a snaphot is currently being transmitted. A note about lz4 being expected should probably be added to the documentation of zfs.autoReplication.host.


Method comments are switched

In file index.d.ts the method comments for onHover and onClick are switched.

Good catch!
It should be fixed in the new v2.0.5 release.


.html endpoints

I don't think we're planning on implementing this any time soon.  If we aren't we should take it out of the docs.

Restarting development, so unfortunately this is obsolete.


GraphQL client

Facebook's GraphQL appears to me a natural choice of backend protocol for new React projects vs. REST. Within the React ecosystem, it moreover goes nicely with Facebook's Relay, Meteor's Apollo or other client libraries to provide modern UX and DX.
Although it is of course possible to just let the developer call their GraphQL API within a Redux saga, it seems natural to replace Redux with Relay/Apollo/other (also in order to use all current and upcoming features such as caching, optimistic updates, realtime/subscriptions, etc). Apollo actually uses Redux under the hood and documents how to interoperate with an existing Redux store. It means an opinionated restriction of the backend protocol to GraphQL, but that appears in line with the doc: "start your app with our community's current ideas on what represents optimal developer experience, best practice, most efficient tooling and cleanest project structure."
Conveniently, GitHub just released a GraphQL API, so the example could be updated with it.
Is the choice of redux(-saga) set in stone? If not, what do others think of replacing it with Relay/Apollo/other?

I'm hearing more about relay, it's popped up a few times for me recently.  is really a replacement for redux? does that mean the whole app structure would change (e.g no more actions/reducers etc)?

@peter-mouland it appears so, the data stays together with the view. No more (implicit data dependencies) across components (but under the hood is one central graph cache).

Conveniently, GitHub just released a GraphQL API, so the example could be updated with it.

Correction, that API isn't public yet, requires agreement to pre-release program then using auth token.

Also, Relay offline support is not prime-time yet, but announced in blog and roadmap. If that's a hard requirement, this could be closed for now. Personally I intend to try it as I can live without offline in my prototype.

I love GraphQL and Relay, I absolutely agree that they highly likely are the future of APIs.
The issue I have is that it would make react-boilerplate only feasible for projects that don't have an existing API and/or are willing to make the jump to GraphQL.
I'm willing to bet that that's a pretty small percentage of them, and right now, I'd much rather focus on getting the frontend part 100% right for APIs of any kind and not be tied to any specific backend system.
That being said, I'll happily discuss more about this! Convince me, why should react-boilerplate switch to a GraphQL/Relay setup by default?

I guess I could flip around the argument of jumping to GraphQL: why would new projects, even those already having a REST API, invest in learning and maintaining Redux, Redux-saga, etc, instead of GraphQL, which seems a more powerful and promising technology?
If we agree GraphQL is the future, shouldn't this boilerplate help kick off projects which will be part of this future for months and years to come?
How about providing a minimal GraphQL backend within this boilerplate? Backend devs would have the flexibility to add their own code to plug into existing REST APIs or to start anew, while frontend devs would have direct access to state of the art DX/UX.
FYI, react starter kit (>10k stars) demoes a GraphQL backend.

Besides the "REST vs. GraphQL" discussion, remember that the choice of GraphQL primarily benefits front-end devs! It enables them to query the data in exactly the way they want it presented, right beside their views, together with static type checking and linting, plus all of the existing and upcoming optimizations.

I'll have to think about this, it's an interesting direction.
Not convinced this is something we want to do just yet, but I'm now pretty sure it'll happen eventually…

Yes I get you. If you have further thoughts/insights about this or some experiment to share, I'd love to hear back! Also at least when Relay 2 comes out, we should reconsider.

Please correct me if I am wrong, but doesn't GraphQL require the app to have some form of NodeJS web server, removing the ability to have the app hosted entirely as static web apps? The ability to just deploy to a CDN (or non-NodeJS server) is one of the reasons that initially brought me to this project.
However, I feel this issue can be mitigated with a proper CLI for RBP that allows one to choose features, i.e. static, SSR/GraphQL, etc.
@mxstbr what's the Issue/Feature # for the CLI work? :-)

I'm not sure this is going to happen in the way you're imagining – I don't really want to maintain multiple codebases at the same time, that's a big pain. (we've been doing that for generator-keystone and it's the worst)

Completely agree-I'd prefer not to maintain separate codebases. I was just trying to think of a way to offer GraphQL and Relay/Apollo in lieu of not wanting to lose the static deployment aspect of RBP. Again, if I'm wrong in the assumption-which was the case last year-that GraphQL requires Node to run, please let me know.

One potentially really cool thing, would be the ability to hot-reload the frontend code upon backend schema changes. It's technically feasible with babel-plugin-react-relay, but a graphql bug prevents from having it working (npm prune and npm dedupe didn't help). Thanks @schickling for troubleshooting!
So right now I first make things work by building the schema manually (by manual call to introspectionQuery) and passing it to babel-relay-plugin. Could explore the cool HMR stuff separately.

@jwinn forgot to answer: of course with GraphQL like any other backend, nothing prevents you from querying a remote endpdoint and ensuring this repo only provides the frontend. I'm curious though, how does this get deployed to a CDN (which I'm not familiar with) as it does have Node.js code (the express server)? And can you give an example of such a CDN/non-NodeJS server?
So the same way it's (from what you say) already possible to ignore the backend within this repo and query something else instead, it should be possible to do the same with GraphQL.

I'm really looking forward to where this goes 😊

BTW managed to use babel-plugin-react-relay as documented here: https://github.com/graphcool/babel-plugin-react-relay/pull/11
This opens the possibility of HMRing the frontend upon backend schema changes and having on-the-fly type checking. (NB: don't know what Apollo is capable of to compare.)

@jwinn forgot to answer: of course with GraphQL like any other backend, nothing prevents the frontend from querying another endpdoint than an endpoint provided within this repo, and hence ensuring this repo only provides the frontend. I'm curious though, how does this get deployed to a CDN (which I'm not familiar with) as it does have Node.js code (the express server)? And can you give an example of such a CDN/non-NodeJS server?

RBP does have a NodeJS server (Express) but it's not required. Just npm run build and copy/deploy the contents of the build folder over to a CDN, (shared) hosting provider, Apache server, application server, etc. As it's just static content (HTML, JS, CSS, etc.), there is no Node environment required--outside the build process--any web container will do. React, redux(-saga), react-router, etc. do not require a Node backend, so this affords flexibility in how the project is used and deployed.
Correct me if I am wrong (as I haven't checked in over a year), but GraphQL must be run in a Node environment. Under this assumption, switching to GraphQL and Relay/Apollo, in lieu of redux-saga (and reselect), would remove the static deployment--via npm run build and deploy--ability of the boilerplate. Sure, where static deployment is needed, GraphQL could be removed, but then what would one add for managing the API (e.g. GitHub) interaction and side effects, redux-saga or some other flux-(like) implementation?
Again, I am not inherently opposed to switching. I just want to make sure this concern/consideration is taken into account when determining to overhaul an, arguably, important piece of the boilerplate. :-)

@jwinn as mentioned, the GraphQL client code can access a public API outside of this repo, just like right now it accesses the GitHub public REST API. No intrinsic need for Node.

@sedubois That was the key crux of the assumption. If GraphQL can run entirely client-side, then static deployment is a non-issue. Like I said, the last time I checked (over a year ago) GraphQL required a node environment to work effectively.

@jwinn I think there's a confusion between client and server here. Of course GraphQL clients don't need Node, or they wouldn't be clients.

@sedubois To alleviate any perceived client/server confusion, in this discussion, for all intents and purposes, Relay/Apollo are GraphQL clients, correct?
TL;DR

Is there any value in switching out redux-saga(/reselect) for Relay/Apollo?
If so, what is the value and does the value still exist if GraphQL is not utilized on the backend?
Can all of this be deployed to a non-NodeJS web environment (e.g. Apache, IIS, Application Server, CDN, etc.)?

My concern is related to baking the GraphQL server into the boilerplate. Currently, in the boilerplate, API implementation is left to the developer leveraging the boilerplate. If a GraphQL-based solution can be run (deployed) entirely without NodeJS (outside of the build process), then the concern is no longer valid.
@mxstbr If, from RBP's perspective, the ability to provide deployment of an app into a non-NodeJS web environment, is not required, please let me know.
I am not arguing neither for nor against GraphQL, as I think GraphQL can have huge upsides. Also, I feel GraphQL and Relay/Apollo are being conflated here. Neither necessarily, requires the other. Substituting redux-saga(/reselect) for Relay/Apollo should be its own conversation. With another conversation discussing whether a GraphQL server should be a reference implementation on the backend. If there is no intrinsic value of switching to Relay/Apollo, without using a GraphQL server, then, I think, this is where the confusion, if any, in the conversation, is stemming from.
Also, a PR would be appreciated to show how Relay/Apollo (and GraphQL if required) would work in the boilerplate. :-D

If so, what is the value and does the value still exist if GraphQL is not utilized on the backend?

This is a good question, I'd like to know that too.

Can all of this be deployed to a non-NodeJS web environment (e.g. Apache, IIS, Application Server, CDN, etc.)?

As far as I know, there are GraphQL implementations in other languages, but depending on the above answer there might not be a static build anymore like right now.

If, from RBP's perspective, the ability to provide deployment of an app into a non-NodeJS web environment, is not required, please let me know.

I'm not sure. Currently, this is possible because we were always focussed on the frontend side of things. I don't know yet if I want to change that, to be completely honest.

Also, a PR would be appreciated to show how Relay/Apollo (and GraphQL if required) would work in the boilerplate. :-D

I agree, but obviously I don't want anybody to do any "useless" work. (though I would hardly call maintaining a fork of this boilerplate that has Relay/GraphQL baked in useless 😉)

Yes yes, gimme a sec to lear this stuff ;)
GitHub API currently down so can't check right now, but it should look something like this: https://github.com/mxstbr/react-boilerplate/pull/1065

Ha...thanks for this. After some research I've decided to scrap a bunch of work and start again with Apollo. It seems like it should be pretty straightforward drop the Sagas and add in Apollo.
My only concern now is SSR, is it at all feasible with this boilerplate?

@scf4 I think isomorphic-relay provides that. I'm not very familiar with SSR in general, and I was also wondering, how is SSR provided when deploying on a CDN?

You would host all your assets on a CDN, but render the initial HTML on the same server as your API (rather than serving empty HTML on the CDN and waiting to load data from the API server).
I don't know whether Apollo or Relay would be best for React Boilerplate in the future, but since adding Apollo to a project seems trivial (and they're essentially feature-equivelant) it seems to make the most sense for me. It uses Redux under the hood (and can connect to your store) unlike Relay which seems to require a lot of fundamental changes to your stack.

In this PR I added Relay: https://github.com/mxstbr/react-boilerplate/pull/1065 and so far it works...
About CDN, the "problem" is that you don't necessarily need an API server at all. For example right now I experiment with Graph.cool which serves as my only backend. I added a feature request there, maybe it helps.

Apollo seems the better choice in relation to Redux concerns and features. Why would we want to use Relay instead of Apollo?

@alisalaah so far I went with Relay basically for the reasons outlined in the conclusion of this article, but I haven't properly evaluated Apollo myself. That might change when trying to integrate some GraphQL CMS backend such as Relax which is nearing beta. That one provides its own GraphQL client, Relate.
I think the main point right now is to bring attention to GraphQL APIs in general. The choice of GraphQL client in particular to choose on the front-end, or which data/content GraphQL server to have on the back-end, doesn't need to be set in stone. These things would be decoupled.

@alisalaah I tried to integrate Apollo, but encountered issues like this and this. Contrary to what the docs led to believe, I have the feeling Apollo is not so mature and found it easier to integrate Relay (see https://github.com/mxstbr/react-boilerplate/pull/1065) and I even have time travel etc working as before. Just didn't try sagas (don't want to use them), but I guess should still work as well.

Things I like to happen with RBP

Client-side by default and then have a simple SSR option or branch I could merge. It didn't have to be the best implementation of SSR but one that doesn't lose any benefits of client-side version (there are problems with CSS, assets and routings. And yes I love styled-components).

It would be awesome to finally migrate to GraphQL no matter client or SSR. There's no doubt about benefits of GraphQL over REST and I think this boilerplate needs to show the best practices. All API  Backend frameworks are supporting it out of the box and I guess it's time to seize the moment.

The choice between Redux(with graphql) and Relay(which I don't have any experience with) pops up a question for me: There's more than just data flow to a client app; state management. Using Relay how can I deal with complex UI interactions or forms(redux-form is an awesome redux equivalent)?

Remember the opinions comes from a person who just learned GraphQL and haven't had an actual experience with it and just knows the benefits.

It seems like Relay 2 may be exactly what we need. I just have no idea when it will be released.

https://github.com/facebook/relay/issues/1369

@sourcesoft @scf4 I am indeed curious to get my hands on Relay 2.
Meanwhile (and maybe/probably later too), redux-saga probably remains the way to manage state (as in this example visible here that @mxstbr mentioned to me) and IMHO GraphQL clients could already take care of data fetching, if we demonstrate it mixes well with redux-saga.

I'm becoming more convinced we should integrate GraphQL and Relay, but still keep Redux and redux-saga for state management and long running transactions. What do you think about that?

Yes sounds good @mxstbr, just need to build a compelling example... Maybe guys you can give feedback on https://github.com/mxstbr/react-boilerplate/pull/1065. Also I experimented with Apollo on top of that: https://github.com/sedubois/belong/compare/gql...apollo but encountered https://github.com/apollostack/react-apollo/issues/267 (also noticed the limitations https://github.com/apollostack/react-apollo/issues/262 and https://github.com/apollostack/react-apollo/issues/268 vs Relay).

What are the reasons to keep redux-saga if Relay handles data fetching?

What are the reasons to keep redux-saga if Relay handles data fetching?

I don't use redux-saga for data fetching reasons. I use it for any sort of asynchronous thing that happens in my application. (which does include data fetching, but with Relay just wouldn't include data fetching anymore)
I believe this is one of the best examples of redux-saga. There is no data fetching whatsoever happening, it's just an onboarding flow – but it's beautiful to read while your main application stays clean. (imagine all of that being done in the main app somewhere, ugh)
In my mind, sagas are like a separate "thread" of your application. (not a literal thread, just a mental model) You have your main application, and you have another thread for async stuff. (whatever that may be) Those two "threads" only ever communicate via redux actions.
Thanks to react, our main app thread doesn't have to care about anything. It just fires a redux action to say "Hey, something happened" – and then the saga thread may do something with that, or it might not. In any case, sometime later, something happens on the saga thread, so it fires off a redux action to tell the main app thread to do something. (e.g. render something new)
That, for me, is the beauty of sagas, and why I haven't yet switched to GraphQL/Relay – they just can't do that, while data fetching with them is by far the better way than AJAX/REST. So let's combine them!

I believe this is one of the best examples of redux-saga. There is no data fetching whatsoever happening, it's just an onboarding flow – but it's beautiful to read while your main application stays clean. (imagine all of that being done in the main app somewhere, ugh)

I believe I can have the same clean syntax using async/await on top of defining custom Promises. But the fact that sagas have take, fork, cancel,... and can build a mindset of dealing with them as a separated thread in a single place makes it unique. IMHO as long as we have Redux, sagas makes life easier.
I think boilerplates like react-starter-kit are using redux and GraphQL without any Relay or Apolo. It's better to implement GraphQL first and don't ditch Redux yet.

That, for me, is the beauty of sagas, and why I haven't yet switched to GraphQL/Relay – they just can't do that, while data fetching with them is arguably far the better way than AJAX/REST. So let's combine them!

I agree, these (GraphQL and redux-sagas) can co-exist nicely and serve specific roles in an application. For the boilerplate, removing/augmenting the GH REST call with GraphQL (and Relay) would be great to have. Also, GraphQL isn't an "improved" REST, nor is it a ubiquitous replacement. Both have applicable scenarios the other cannot provide. More importantly, the two are not mutually exclusive. Note, I am talking about formal REST, not what some call REST as noted in the FB GraphQL post:

We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.

Sorry for off-topic but I couldn't find any contact details for yours @jwinn. Could you send me a quick email elaborating a bit more about the use cases where you see REST to be superior to GraphQL?

I've integrated Apollo into this repository, to be more precise, a modification of it—without Immutable.js. Everything is in this commit: https://github.com/Dattaya/react-boilerplate-object/commit/47ea450f5744e6cf1f5a88c0d3b03fcc8f4b235e
This is what has been done:

Added a separate apollo server, the reason is that frontend hot reloading does not work very well with backend hot reloading. According the the authors, apollo-server is compatible with other GrapthQL client libraries. This server fetches data from Github REST API in resolvers.
Added Webstorm support in graphql.config.json, maybe other IDE's support it.
Graphiql can be accessed at this url: localhost:3000/graphql/ide
Created a new script that generates schema.json from schema.js—npm run update-schema

Let me know if you want to port some parts of it back into this repo. I would love to get some feedback because I'm also new to GraphQL.

implement GraphQL first and don't ditch Redux yet

Apollo relies on Redux. That doesn't mean that I promote Apollo though, I'm just experimenting with different GraphQL clients. BTW, in addition to Relay, Apollo, Relate and Lokka, there is also Cashay—https://github.com/mattkrick/cashay

@Dattaya looks great! It's nice to see a working RBP + Apollo demo compatible with all the rest. I added some comments on your code, only to be taken into account if you were to submit a PR of course. General message: let's minimize the impact (to ease review and limit risk; things could be removed/added separately as needed):

don't add a GraphQL backend, use an existing one such as GitHub's
don't add stuff needed only for IDE support
don't do unrelated things like improving checkmark messages
don't remove saga machinery, it's still needed

NB: a proper saga example should come (maybe e.g with a login flow), so IMHO it's OK to remove this GitHub data fetching saga example. Just make sure to keep saga machinery!
NB2: probably we'll learn more about the future of GraphQL clients next week after the GraphQL Summit...
@mxstbr what do you think?

Thanks for your thoughts and mentioning Graphcool, @sedubois!

most importantly, graph.cool is not yet in general availability

It will be soon! Additionally, we'll soon roll out support for schema files which allows you to setup a GraphQL backend based on a IDL file like the following (reduced Instagram example):
type Post {
  description: String!
  imageUrl: String!
  comments: [Comment!]!
}

type Comment {
  text: String!
}

@sedubois, thank you for your feedback and your comments. @mxstbr wanted to go with Relay and so do I, because it has more contributors and Facebook has more talented developers and resources; it's just Relay 1 is too heavy, 114068 bytes gzipped (React included) and probably too complicated for simple and some medium complexity projects. I hope Relay 2 is better in this regard.

don't remove saga machinery

redux-saga is there, just didn't want to leave an empty file. As you said, something else should be added to showcase it.

@Dattaya agreed. About sagas I misread the code (e.g when seeing this deleted).
We could either go with Apollo and migrate to Relay 2 when appropriate, or wait for Relay 2. But why wait if Apollo already works well enough? (just thinking out loud here)

+1 for Relay. Reindex too

Since mentioning Graphcool and Reindex I thought I'd chime in with
Scaphold.io which has the best free tier and a good API.
On Thu, Oct 20, 2016 at 1:48 AM, Matt<EMAIL_ADDRESS>wrote:

+1 for Relay. Reindex too
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mxstbr/react-boilerplate/issues/1041#issuecomment-254905736,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQ9ltissWItUWACIgNRtAg6bagYSkLJks5q1mYOgaJpZM4KGqWr
.

We could either go with Apollo and migrate to Relay 2 when appropriate, or wait for Relay 2. But why wait if Apollo already works well enough? (just thinking out loud here). I also tend to prefer Relay.

I'll wait for @mxstbr decision before sending a new pull request. This is how a request to GitHub GraphQL API would probably look like:
query {
  repositoryOwner(login: "mxstbr") {
    repositories(first: 30) { # Github limits the max value of loaded entries at once to 30
      edges {
        node {
          path
          url
          issues {
            totalCount
          }
          isFork
          parent {
            path
            url
          }
        }
      }
    }
  }
}

It gives the following result:
{
  "data": {
    "repositoryOwner": {
      "repositories": {
        "edges": [
          {
            "node": {
              "path": "/mxstbr/old-blog",
              "url": "https://github.com/mxstbr/old-blog",
              "issues": {
                "totalCount": 0
              },
              "isFork": true,
              "parent": {
                "path": "/poole/lanyon",
                "url": "https://github.com/poole/lanyon"
              }
            }
          },
...

Since at least for now you don't want a GraphQL server, it's going to be really easy to migrate to Apollo (I think same true for Relay)—add apollo client and this query, remove data loading with sagas, adjust tests and that's it. Later we can add "load more" button or load more data as the user scrolls.

Apollo is better than current Relay and definitely beats using Redux/sagas imo.

@alisalaah could you share a complete example of Apollo code doing both data-fetching and async state management (e.g an onboarding or login flow)?

Their example app does data fetching and async management at:
https://github.com/apollostack/GitHunt-API
https://github.com/apollostack/GitHunt-React
On Fri, Oct 21, 2016 at 3:06 PM, Sébastien Dubois<EMAIL_ADDRESS>wrote:

@alisalaah https://github.com/alisalaah could you share a complete
example of Apollo code doing both data-fetching and async state management
(e.g an onboarding or login flow)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mxstbr/react-boilerplate/issues/1041#issuecomment-255319955,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQ9lvB6HGFqukf8PiC-gmWh_u2E9bgtks5q2HJugaJpZM4KGqWr
.

Hey, I'm the lead on the Apollo team. I think there are some compelling reasons to go with Apollo, especially in a project boilerplate. And when Relay 2 comes out eventually, if it's a better choice, then it would be great to switch to that, as it wouldn't be a huge change.

Apollo directly integrates with a variety of tools people might want to use, including Redux. It lets you structure your app the way you like to, and doesn't take over the architecture. It also doesn't require any schema information or custom build tools.
Apollo better embodies what are quickly becoming best practices for GraphQL - for an example, check out our blog post about static queries (one of the main reasons for the Relay 2 re-architecture). at the recent GraphQL summit, Joe Savona, one of the authors of Relay, was also talking about how static queries are a better approach, and it's where Relay 2 is going as well.
In regards to contributors and velocity, the contributor numbers are in the same order of magnitude, especially when you consider that Apollo is decoupled into 5+ repositories. We're excited to work with new contributors as well, to make a flexible client everyone can work on together.
In terms of features, Apollo is on par with what has been announced for Relay 2, with the ability to use fragments for colocation, do persisted queries, etc.

I'd love to have a conversation about this. I think React applications get a lot of benefit out of using GraphQL, and we built Apollo to be a straightforward and powerful way to use that.

@stubailo
Great points, what I think makes the big difference is

Apollo directly integrates with a variety of tools people might want to use, including Redux. It lets you structure your app the way you like to, and doesn't take over the architecture.

as I expressed in https://github.com/mxstbr/react-boilerplate/pull/1065#issuecomment-255808734 for someone comming from what is considered a normal react setup - using redux, react-router etc - Apollo is so friction-less to integrate.

We're experimenting with Apollo + Redux + Sagas. Sagas are still very helpful when doing asynchronous tasks that don't involve our GraphQL API (like calling another API, or dealing with asynchronous IO, for example).  Basically, doesn't seem like an either/or to me - apollo + sagas cover all of our async needs very nicely - highlight recommended :).

FYI GraphQL summit talks are available: http://graphqlsummit.com/#talks-graphql

BTW if there are any improvements we can make to Apollo to make this simpler, happy to consider that!

I just started working on a new app with RBP/Apollo today. Does anyone have an integration example? I followed the Apollo docs but I'm missing something with the way the store is setup:
/**
 * Creates the main reducer with the asynchronously loaded ones
 */
export default function createReducer(asyncReducers) {
  return combineReducers({
    apollo: client.reducer(),
    route: routeReducer,
    language: languageProviderReducer,
    ...asyncReducers,
  });
}

@scf4 perhaps open a separate issue on apollo-client?

@scf4 I have a fully worked app with Apollo, during the day, I will send instructions.

@scf4 @sedubois diff with a fresh RBP https://github.com/DenisNeustroev/react-boilerplate/commit/05f2d920f50a2d4d3226ba7783c264ab769145f3
Also can clone https://github.com/DenisNeustroev/react-boilerplate & install and start & open localhost:3000/apollo and see result

Hmm I think my issue was missing the client in this line in app.js:
const store = configureStore(initialState, apolloClient, browserHistory);
Besides that little hiccup it was incredibly simple to drop Apollo into RBP! cc @mxstbr !!!

@DenisNeustroev Thanks for your sharing, that save my time. Have you tried 'npm run build' ? It failed by
18 11 2016 15:21:52.294:INFO [Chrome 54.0.2840 (Mac OS X 10.12.1)]: Connected on socket /#eDIIkBRV-zNwSmNhAAAA with id 68080617
  selectLocationState
    ✔ should select the route as a plain JS object
  configureStore
    ✖ "before all" hook
  asyncInjectors
    getAsyncInjectors
      ✖ "before all" hook
    helpers
      ✖ "before all" hook

=============================== Coverage summary ===============================
Statements   : 42.7% ( 38/89 )
Branches     : 6.25% ( 2/32 )
Functions    : 21.43% ( 6/28 )
Lines        : 43.37% ( 36/83 )
================================================================================

Finished in 0.047 secs / 0.004 secs

SUMMARY:
✔ 1 test completed
✖ 3 tests failed

FAILED TESTS:
  configureStore
    ✖ "before all" hook
      Chrome 54.0.2840 (Mac OS X 10.12.1)
    TypeError: apolloClient.middleware is not a function
        at configureStore (webpack:///app/store.js:19:17 <- test-bundler.js:22689:75)
        at Context.<anonymous> (webpack:///app/tests/store.test.js:13:27 <- test-bundler.js:92590:83)

  asyncInjectors
    getAsyncInjectors
      ✖ "before all" hook
        Chrome 54.0.2840 (Mac OS X 10.12.1)
      TypeError: Cannot read property 'middleware' of undefined
          at configureStore (webpack:///app/store.js:19:17 <- test-bundler.js:22689:74)
          at Context.<anonymous> (webpack:///app/utils/tests/asyncInjectors.test.js:43:29 <- test-bundler.js:92674:84)

    helpers
      ✖ "before all" hook
        Chrome 54.0.2840 (Mac OS X 10.12.1)
      TypeError: Cannot read property 'middleware' of undefined
          at configureStore (webpack:///app/store.js:19:17 <- test-bundler.js:22689:74)
          at Context.<anonymous> (webpack:///app/utils/tests/asyncInjectors.test.js:75:29 <- test-bundler.js:92708:84)

Any ideas ?

@DenisNeustroev Thanks for sharing, save my time 👍

@stubailo Hi, I'm a Chinese Front-End developer. I wrote an article yesterday to promote the React stack including "React + Redux/Flux + (GraphQL + Relay)/Apollo + Flow + Jest" in large SPA development.  The creator of Vue.js commented that since Apollo is still not in 1.0, I can't consider Apollo as a stable solution. I think Apollo is production ready, so what's your opinion about this stability concern? Thanks.

@ithinco neither GraphQL nor Relay are at 1.0 either. Not that that's an excuse for us, though. We have a few things we'd like to iron out before dropping that number on it. Specifically, here's a list: https://github.com/apollostack/apollo-client/blob/master/ROADMAP.md
We don't expect the developer experience to change significantly, or to remove any features. We're using Apollo in all of our production apps right now very heavily, so we're going to feel the cost if we make any big changes! The last significant change, 0.5, ended up being quite easy to migrate to even though there were lots of differences internally.

@ithinco I don't think this is related to this thread though, so if you have further questions it's probably best to open a new issue somewhere else.

Any update on Apollo-client integration?
This is something that makes a lot of sense to integrate. React-starter-kit integrated graphql as well.

^^^ same as this guy - is there any built in integration OR examples of how to properly integrate the Apollo client into RBP?

It isn't really worth it IMO. Just use create-react-app or another boilerplate. Add redux yourself later if you need it.

@claym - I just chose ARc as my boilerplate.
You can see the Apollo integration here:
https://github.com/diegohaz/arc/issues/106

@advance512 oh, great. Would love to see that get built into ARc's universal-redux branch.

There's also the universal Next.js which, like create-react-app, isn't a boilerplate but an NPM dependency -- and it has a with-Apollo example.
https://github.com/zeit/next.js/tree/master/examples/with-apollo

@sedubois recently I discover your repo relate
seems like it's uses graphql + next etc..
how stable it is ?

@Necmttn it's in development (e.g auth needs to be reworked, some issue with intl, etc). But also some pièces got stable enough (e.g Apollo SSR). Need to add testing etc. But if you have specific questions, comments etc, please continue over there with issues or in Slack.

Any suggestions for similar boilerplates using Relay then? With the same quality and DX for a progressive web app?
Or would you advise me to integrate it with react-boilerplates? I don't want the backend dependencies of react-starter-kit, planning to use the go server implementation.

@patrick-samy  I would suggest you go with Apollo instead of Relay.  Apollo got much more interactive community these days.

Makes sense, what do you guys think about this one: https://github.com/kriasoft/react-static-boilerplate ?

@patrick-samy I'm giving a go to the Gatsby static site generator which uses React+GraphQL. For dynamic SSR apps, I'd try Next.js. Very much depends on the type of data you are dealing with. And for the backend: Graphcool.

@Necmttn Apollo seems to require more work than Relay Modern to keep the local state consistent.
@sedubois Thanks, I want to keep the client static and implement CQRS with microservices in Go on GCP. Not convinced about the flexibility of Graphcool, although it seems like a perfect short term solution.

Thanks for the shout out @sedubois!
Regarding your point @patrick-samy, we're about to announce some really exciting changes to Graphcool, as we're turning it into a GraphQL backend development framework to better address flexibility and vendor lock-in concerns. Stay tuned for some updates!

@patrick-samy

Apollo seems to require more work than Relay Modern to keep the local state consistent.

How so?

@scf4 with relay you don't have to specify how to update the local store when a server sends a response, or do you?

@sedubois have you ever tried react-static-boilerplate?

regarding gatsby.js @sedubois , it's uses for graphql for building the static pages ones you build it's doesn'tt have a module for grab content from graphql.  as I understand Patrick wants to do that in the client side, in that case, i would suggest next.js as well. which has  example with apollo

Thanks - I'm going to stick with react-boilerplate and implement Relay Modern (or maybe Apollo, haven't decided) instead of Redux.
If anyone has already started working on this, let me know :)

You can integrate GraphQL into Gatsby also for dynamic content with SSR, see this article by @lawjolla:
<EMAIL_ADDRESS>Gatsby is evolving quickly so keep an eye on announcements by @kyleamatthews. Looking forward to simple integration with Graphcool or other GraphQL plugin.
Once I get the static part right, then I will experiment with dynamic parts where needed, loading them client side or integrating Next.js.
I just want to give a good try to the JAMstack which should make things much more simple and maintainable.

Thanks @sedubois !
To update, I have a PR into Gatsby that will be merged sometime soon to allow client data fetching at compile time.
https://github.com/gatsbyjs/gatsby/pull/2423

@schickling I might actually start off with Graphcool.
Would you recommend react-boilerplate for an offline-first web app? Or something that already supports Relay Modern such as react-static-boilerplate?

@scf4 Have you by any chance done the same setup to include Apollo Provider/Client into React-Boilerplate, but rather than using the client from Apollo, used the client from AWS AppSync? I'm trying to implement this, to entirely do away with a long complex convoluted Redux/State/Store/API etc... when I can just drop in single components that load their data when logged in without any cross components and such... so easy if I could get it to work... :(
When I add an ApolloClient to my reducer, it responds with appsyncClient.reducer is not a function. I've created the ApolloClient in reducers.js used it there in createReducer, apollo: client.reducer(), imported the client in App.js and used it in const store = configureStore(initialState, client, history); ... added an , between Provider and Language... can't get it to go though.
I agree with half the people here, and also the other half. Apollo is great, but it should only manage it's own state. There are tonnes of other use cases where you have to manage other state aside the redux state.
@marbemac I agree, you can't just use Apollo and do away with Sagas. Both do their own thing, and do it well.

@nikitong I'm trying activly, but integrating Apollo 2 with react-boilerplate it migh not be viable options right now, Apollo people decide to ditch redux and use apollo-link-state to local state management .
There are some hacky ways to use them hand to hand like here but I don't like he idea of using two different stores with two different paradigms.
What I decided is to try to use apollo 1.0 instead similar to what @DenisNeustroev did.

I have been following this discussion for a while now, and I'm wondering if anyone had any ideas about switching the entire project to relay? If they haven't... I'm busy until the weekend... then I'm going to give it a go.
@antondc Yes, it was o.k. worked and all, but wasn't useful in my project. I may give it another go for my next project which will require a lot more changing data and less wide functionality.

Any updates here? I would like to see how the boilerplate file structure changes with Apollo, since we use that instead of Redux.

Any updated?

Sorry but I don't think this is happening. Imposing a switch to GraphQL to all users of the boilerplate doesn't make sense IMO. If anyone wants to maintain an Apollo-based fork of the repo, I'd be happy to link it from the relevant section in the docs.

^ agreed

Closing for lack of activity + no further action here.


refactor assembly areas

centralize and simplify feature integrations

prepare-api-configurator
prepare-api-shape
assemble-models
get-component
database

come up with some more strategies to cleanup assembly

okay, did a big refactor, much cleaner now
now, new features need to be integrated in these places
backend

assimilate-database.ts (consequently database.ts)
assimilate-api.ts

frontend

get-component
prepare-api-shape

still a lot of out-of-feature-directory integrations are needed.. but now they are organized to make much more sense..
not sure if there's a more concise way to integrate features than these four spots


Radar point clustering and lead vehicle detection

Any filtering / detection of objects happens here. Should include a kalman filter to reduce noise and output a lead car with long. distance and speed.

LEad vehicle deteciton works quite well specially if radar is calibrated properly


This does not work with ui-router

I have tried to implement it in my multi view app that uses ui-router. I have put it in a nested ui-view:

No error and no tree view. I am using Angular 1.4.7

Here is a plunkr: http://plnkr.co/edit/IWZXG8
It has nested ui-router views. The tree view is in the /#/tabs/firstTab/insideTab1-substate1


BUGFIX: Age not calculating when updating DOB in Enrollment

Description
Jira Ticket: NONE
Age was not automatically calculating in enrollment after updating DOB.
How to Replicate

Go to enroll a new monitoree.
Change DOB.
Notice age does not calculate even when there's a valid DOB.

Solution
The code to automatically update the age was in the handleChange() method and not the new handleDateChange() method. Just needed to move it over.
Important Changes
app/javascript/components/enrollment/steps/Identification.js

Updated handleDateChange() to update age data upon valid date. Moved this logic from handleChange()

Testing
This fix was tested on the following browsers (submitter must check all those that apply):

[x] Chrome
[ ] Firefox
[ ] Safari
[ ] IE11

To test, please replicate the above steps to try and replicate the bug and confirm it no longer happens.
Submitter Checklist*

[x] I have tested all of my changes locally.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation (if any).
[x] My changes generate no new warnings/errors.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] New and existing unit tests pass locally with my changes.

Reviewer Checklist*
Reviewer 1
Reviewer: @timwongj
Checklist:

[ ] I have carried out all tests described in the PR and verified functionality.
[ ] I have reviewed every file in the diff to verify that changes are reasonable, and that any updated/added code is maintainable and reusable and follows good practices.

Reviewer 2
Reviewer: @holmesie
Checklist:

[ ] I have carried out all tests described in the PR and verified functionality.
[ ] I have reviewed every file in the diff to verify that changes are reasonable, and that any updated/added code is maintainable and reusable and follows good practices.

Couple of notes:

age does not seem to be calculated when age is supposed to be 0 (not sure how many 0 year olds will be enrolled but worth fixing)
age seems to be capped at 120 while date of birth is not limited to older than a date within the past 120 years (probably not a big deal though)

Couple of notes:

age does not seem to be calculated when age is supposed to be 0 (not sure how many 0 year olds will be enrolled but worth fixing)
age seems to be capped at 120 while date of birth is not limited to older than a date within the past 120 years (probably not a big deal though)

For posterity - the existing functionality was to not allow 0, but we can update if we feel that's worth doing. Age is capped at 199 here.