store configuration in consul  problem on v12.0.0

Expected Behavior / New Feature
hi
When the configuration is stored in consul, restarting the application causes local ocelot. json information to be synchronized to consul, resulting in loss of consul configuration data;
I find that every restart application is executed.
if(AdministrationApiInUse(adminPath))
{
   var fileConfigSetter = builder.ApplicationServices.GetService<IFileConfigurationSetter>();
   await SetFileConfig(fileConfigSetter, fileConfig);
}
Actual Behavior / Motivation for New Feature
Steps to Reproduce the Problem

Specifications

Version:v12.0.0
Platform:
Subsystem:

@q315523275 mmmmm I will check this out ASAP, I thought I fixed this already.

@q315523275 Ive had a chance to look at this issue, it looks like expected behaviour. If you are using the administration API when Ocelot starts up it writes to ocelot.json and ocelot.{env}.json because users expect both of these configs to be in sync.
If you are using consul instead of using DiskFileConfigurationRepository to do the save it uses the Consul version and hence it saves to your consul instance.
The fix for this is say if using consul to store ocelot configuration don't save the config when starting Ocelot. This would mean exposing some kind of delegate from Ocelot.Provider.Consul package.
For now I would suggest dont use the administration api when using Consul. You shouldnt need both.

@TomPallister Thank you very much for your reply. I will use API management in another way.


Grid not rendering - Cannot read property 'headerCssClassName' of null

Griddle version
"griddle-react": "^1.3.1",
Expected Behavior
Should render proper table
Actual Behavior
Not rendering table, getting error

Steps to reproduce
Follow this documentation  - http://griddlegriddle.github.io/Griddle/docs/
Install griddle
npm install --save griddle-react
Here is my code
import React from 'react';
import Griddle, { plugins }  from 'griddle-react';

export class DashboardPage extends React.Component { // eslint-disable-line react/prefer-stateless-function
  constructor(props) {
    super(props);

    // ignore these lines
    const fromDate = new Date();
    const toDate = new Date();
    fromDate.setDate(fromDate.getDate() - 30);
    toDate.setHours(23, 59, 59, 0);
    fromDate.setHours(0, 0, 0, 0);
    this.state = {
      fromDate: fromDate,
      toDate: toDate,
    };
  }
  componentDidMount() {
    this.props.getCompanies(this.state.fromDate, this.state.toDate,this.refs.DashboardToastr);
  }

  onFilter = (e) => {
    const toastr = this.refs.DashboardToastr;
    this.props.getCompanies(this.state.fromDate, this.state.toDate, toastr);//Sending toastr parameter to access them in Sagas.
  }
  render() {
    const { loading, error, companies } = this.props;
    return (
           <Griddle
              data={ companies ? companies : [{}]}
              plugins={[plugins.LocalPlugin]}
            />
    );
  }
}
DashboardPage.propTypes = {
  loading: React.PropTypes.bool,
  error: React.PropTypes.oneOfType([
    React.PropTypes.object,
    React.PropTypes.bool,
  ]),
  companies: React.PropTypes.oneOfType([
    React.PropTypes.array,
    React.PropTypes.bool,
    React.PropTypes.object
  ]),
  getCompanies: React.PropTypes.func,
};
export function mapDispatchToProps(dispatch) {
  return {

    getCompanies: (fromDateObj, toDateObj, toastr) => {
      let fromDate = moment(fromDateObj).format(DATE_FORMAT);
      let toDate = moment(toDateObj).format(DATE_FORMAT);
      dispatch(loadCompanies({ fromDate, toDate, toastr }))
    },
  };
}
const mapStateToProps = createStructuredSelector({
  companies: makeSelectCompanies(),
  loading: makeSelectLoading(),
  error: makeSelectError(),
});
// Wrap the component to inject dispatch and state into it
export default connect(mapStateToProps, mapDispatchToProps)(DashboardPage);

Pull request with failing test or storybook story with issue
While this step is not necessary, a failing test(s) and/or a storybook story will help us resolve the issue much more easily. Please see the README for more information.

@ryanlanciaux
Could you please help on this issue, am I doing something wrong here?
I've followed the documents - http://griddlegriddle.github.io/Griddle/docs/ but no use.
Note : Its working fine in - "griddle-react": "^0.8.1".

Try installing the latest version? I'm not able to reproduce this, and I can't see how cellProperties on the failing line could be null given its implementation.

@dahlbyk
Thanks for the reply will try to install the latest version as you suggested.
Right now I'm using - "griddle-react": "^1.3.1", is not the latest?

Right now I'm using - "griddle-react": "^1.3.1", is not the latest?

"griddle-react": "^1.5.0" is available, but not marked @latest yet.

(I'm 99% certain what you're seeing will have been fixed by https://github.com/GriddleGriddle/Griddle/commit/dbcff1d2b0fb80ffa3db02523f08a29bb69b2a8c.)

@dahlbyk
This issue has been fixed in the latest version - "griddle-react": "^1.5.0".
Thanks @dahlbyk.
But styles are not rendering - found the reason here - https://github.com/GriddleGriddle/Griddle/issues/661#issuecomment-299944751


CIF-937 Clean up Venia leftover components from CIF Core Components

Description
Clean up Venia leftover components from CIF Core Components project - move hero image to sample project
Related Issue
CIF-937
Motivation and Context
Clean up Venia leftover components from CIF Core Components project
Types of changes

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

Checklist:

[x] I have signed the Adobe Open Source CLA.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes and the overall coverage did not decrease.
[x] All unit tests pass on CircleCi.
[x] I ran all tests locally and they pass.

Review together with https://github.com/adobe/aem-cif-project-archetype/pull/37

Review together with https://github.com/adobe/aem-core-cif-components/pull/107


Add subrc before the value

Seems the PR doesn't contain any changes (Files changed = 0)?

Hmm?
f0db6449e7f1ecd23b3642d1b605f9469779fa80 was already merged into master with 24486c7d56eba954d6eb76a664fdab955b18755f  in #2477

Looks like a display issue check https://github.com/larshp/abapGit/pull/2646/commits/f0db6449e7f1ecd23b3642d1b605f9469779fa80

f0db644 was already merged into master with 24486c7 in #2477


count(table.*) not parsing

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

SELECT COUNT(myTable.*) FROM myTable
Parsing this SQL using JSqlParser with this statements
Exception
org.junit.ComparisonFailure: Expected query to parse but it failed to parse (error: Encountered unexpected token: "(" "("

Expected behavior
query to parse
System

postgres
15
4.1

Confirmed, I will have to fix that.


single file AREPO snapshots (in series)

from scida import load

ds = load("/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/")
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[4], line 1
----> 1 ds = load("/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/")

File /vera/u/dnelson/code.py/scida/src/scida/convenience.py:270, in load(path, units, unitfile, overwrite, force_class, **kwargs)
    268 if issubclass(cls, DatasetSeries):
    269     classtype = "series"
--> 270 cls_simconf = _determine_type_from_simconfig(path, classtype=classtype, reg=reg)
    272 if cls_simconf and not issubclass(cls, cls_simconf):
    273     oldcls = cls

File /vera/u/dnelson/code.py/scida/src/scida/discovertypes.py:85, in _determine_type_from_simconfig(path, classtype, reg)
     83 metadata_raw = dict()
     84 if classtype == "dataset":
---> 85     metadata_raw = load_metadata(path, fileprefix=None)
     86 candidates = check_config_for_dataset(metadata_raw, path=path)
     87 assert len(candidates) <= 1

File /vera/u/dnelson/code.py/scida/src/scida/io/_base.py:787, in load_metadata(path, **kwargs)
    772 """
    773 Take a quick glance at the metadata.
    774 Parameters
   (...)
    784     Dictionary of attributes.
    785 """
    786 loader = determine_loader(path, **kwargs)
--> 787 metadata = loader.load_metadata(**kwargs)
    788 return metadata

File /vera/u/dnelson/code.py/scida/src/scida/io/_base.py:389, in ChunkedHDF5Loader.load_metadata(self, fileprefix, use_cachefile, **kwargs)
    385     paths = self.get_chunkedfiles(
    386         fileprefix, choose_prefix=kwargs.get("choose_prefix", False)
    387     )
    388     if len(paths) == 0:
--> 389         raise ValueError("No files for prefix '%s' found." % fileprefix)
    390     path = paths[0]
    391 tree = {}

ValueError: No files for prefix 'None' found.
> /vera/u/dnelson/code.py/scida/src/scida/io/_base.py(389)load_metadata()
    387             )
    388             if len(paths) == 0:
--> 389                 raise ValueError("No files for prefix '%s' found." % fileprefix)
    390             path = paths[0]
    391         tree = {}

where we have a run that saves only one file per snap, and this changes the snapshot file naming structure to (no sub-directories):
[dnelson@vera02 ~]$ ls /vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap*
/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_000.hdf5
/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_001.hdf5
/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_002.hdf5
/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_003.hdf5
/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_004.hdf5
/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_005.hdf5
...

Any suggestion how to differentiate an output folder for a series with single (non-subdir) hdf5 files versus a single multi-file snapshot subdir? I would not want to rely on the "output" subfolder name, and potentially also not on the exact numbering pattern (*.X.hdf5 for snap; *_X.hdf5 for series).

I don't see a perfect way. I agree not to rely on any part of the path.
Do you currently use/rely on the NumFilesPerSnapshot header attribute in any way? If so, this gives one answer.
Otherwise, a series for us is (for now) always a time series, right? If you find a Header/Time or Header/Redshift and these are not the same across files, it is a series and not a chunkset.
The load() could also accept an optional e.g. series=True to hint, although I don't like this.
Being very general, since the prefix of snapshot files is arbitrary (specified in the parameter file for Arepo runs even), and a folder could easily have multiple sets of HDF5 files, e.g. some output option could also produce other diagnostic files for each snapshot, perhaps load() could also accept a file prefix and wildcard, e.g. /path/to/folder/snap*.hdf5.

Could you please test
sim = load("/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/")
and its functionality after checking out branch fix187 @dnelson86 ? Thanks!

Looks good, detects series with 513 snapshots. (You should have permission to the path, can also check it).
But, each dataset is ArepoSnapshotWithCosmologyMixinWithUnitMixin, is this an issue, or just a bad name? (Since these are not cosmological).
In [3]: sim.info()
class: ArepoSimulation
source(id=0): /vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_000.hdf5
Ndatasets: 513
=== metadata ===
redshift: 0.0
z: 0.0
boxsize: 1.0
time: 0.0 -- 25.6
t: 0.0 -- 25.6
============

probably it would be better not to have redshift and z, or else to write explicitly for them NaN or 'missing'?
Then in addition, for units:
In [8]: sim.datasets[0]
Out[8]: INFO:scida.interfaces.mixins.units.missing_units:Unit mismatch for '/PartType0/Density': '1.0 code_mass / code_length ** 3' (unit file) vs. 1.0 gram / centimeter ** 3 (metadata) [cgs-factors 3.31637e-22 (unitfile) != 1.00000e+00 (metadata)]
INFO:scida.interfaces.mixins.units.missing_units:Unit mismatch for '/PartType0/InternalEnergy': '1.0 kilometer ** 2 / second ** 2' (unit file) vs. 1.0 centimeter ** 2 / second ** 2 (metadata) [cgs-factors 1.00000e+10 (unitfile) != 1.00000e+00 (metadata)]
INFO:scida.interfaces.mixins.units.missing_units:Unit mismatch for '/PartType0/Masses': '1 code_mass' (unit file) vs. 1.0 gram (metadata) [cgs-factors 2.84067e+43 (unitfile) != 1.00000e+00 (metadata)]
INFO:scida.interfaces.mixins.units.missing_units:Unit mismatch for '/PartType0/Velocities': '1.0 a ** 0.5 * kilometer / second' (unit file) vs. 1.0 centimeter / second (metadata) [cgs-factors 1.00000e+05 (unitfile) != 1.00000e+00 (metadata)]
INFO:scida.interfaces.mixins.units.missing_units:Cannot determine units from neither unit file nor metadata for '/PartType0/VelocityCurl'.
INFO:scida.interfaces.mixins.units.missing_units:Cannot determine units from neither unit file nor metadata for '/PartType0/VelocityDivergence'.
INFO:scida.interfaces.mixins.units.missing_units:Unit mismatch for '/PartType0/Coordinates': '1 code_length' (unit file) vs. 1.0 centimeter (metadata) [cgs-factors 4.40811e+21 (unitfile) != 1.00000e+00 (metadata)]
Missing units for 7 fields.
Fields with missing units:
  - /PartType0/Density (mismatch)
  - /PartType0/InternalEnergy (mismatch)
  - /PartType0/Masses (mismatch)
  - /PartType0/Velocities (mismatch)
  - /PartType0/VelocityCurl (missing)
  - /PartType0/VelocityDivergence (missing)
  - /PartType0/Coordinates (mismatch)

what does "unit file" refer to?
The metadata of these snapshots seems ok (for such an idealized setup):
In [1]: f = h5py.File('/vera/ptmp/gc/dnelson/sims.idealized/sims.turbbox/gamma53_64/output/snap_000.hdf5','r')
In [4]: f['PartType0']['Density'].attrs['a_scaling']
Out[4]: np.float64(0.0)

In [5]: f['PartType0']['Density'].attrs['h_scaling']
Out[5]: np.float64(0.0)

In [6]: f['PartType0']['Density'].attrs['length_scaling']
Out[6]: np.float64(-3.0)

In [7]: f['PartType0']['Density'].attrs['mass_scaling']
Out[7]: np.float64(1.0)

In [8]: f['PartType0']['Density'].attrs['velocity_scaling']
Out[8]: np.float64(0.0)

In [9]: f['PartType0']['Density'].attrs['to_cgs']
Out[9]: np.float64(1.0)


WIP switch from quinine to yahp

Closes #130 . Our friends at Mosaic have created a nice little config library called yahp. It's not perfect, but it's like 90% of what I'd want. All the config is in dataclasses now, and the yaml barely had to change.
As a bonus I made it so that we can handle just about every argument from TrainingArguments in HF and it's auto-synced with updates to hugging face.
I still need to:

[ ] merge a PR into yahp to support lists of lists
[ ] fix docs for the small changes to configs
[ ] run more tests
[ ] maybe some more cleanup?!?

Fixes Issues
#130
Unit test coverage
Are there unit tests in place to make sure your code is functioning correctly?
^^ situation is no worse, and we have some semblance of static type checking sometimes
Known breaking changes/behaviors
Configs need to change a bit, but mostly just removing "nulls" that should just be unspecified rather than null, imho.

Oh man we'll have to change the graphic on the front page ...

Any particular reason you favor yahp over quinine ? I guess overall yahp has a team maintaining/developing it and we probably have some degree of freedom to directly alter it if we have great ideas ... quinine just has one person and we probably have more freedom to alter it but still at the discretion of Karan ... so I don't really care either way

In addition to the points you mention, I like types and dataclasses that my IDE will recognize. I ran into a limitation in quinine/cerberus a while back (though I've forgotten by now exactly what it was. it had to do with lists)
Both Cerberus and Quinine also seems somewhat abandoned? If it were just quinine, I'd just take it over if need be, but with cerberus also being abandoned that seemed not good.


[beacon api] check if we need to fix anything in our definitions

https://github.com/ethereum/beacon-APIs/pull/444
I haven't read this closely, but if someone can take a look... its probably worth testing the query parameter.

Just double checking before executing on something that we don't want.
The PR mentioned above changes the type of the field skip_randao_verification.
In Teku we only have skip_randao_verification in the BlockV3. My understanding is that the type change is all we want to do in Teku.
We don't want to add this field to blinded_block, correct?
Same applies for BlockV2  which seems to be deprecated.


[RFC] Refactor LocalTestCluster into LocalTestClusterOpenSearch and LocalTestClusterOpenSearchDashboards.

Description
Refactor LocalTestCluster into LocalTestClusterOpenSearch and LocalTestClusterOpenSearchDashboards.
To minimize the impact of this change, I still keep LocalTestCluster as it is which will be later replaced by LocalTestClusterOpenSearch. Thus there is no impact to the existing logic since the related change has not yet been used.
I also notice that the S3 path to build/bundle has been changed. However to keep the scope of this PR small, I will use the existing path for now.
Test
The current 1.2.0 OpenSearch artifact has the issue master_not_discovered_exception. Thus my test strategy is to monitor whether the code execution can reach the health ping. I have been testing the LocalTestCluster class to use inside integ test suite to see the output. Below is the output snippet when trying to use ServiceOpenSearchDashboards and also comment out the logic to start OpenSearch inside it.
2021-10-31 23:50:21 INFO     Unpacking
2021-10-31 23:50:23 INFO     Unpacked
/tmp/tmp_oisyjff/local-test-cluster
opensearch-dashboards-1.2.0-linux-x64  opensearch-dashboards-1.2.0-linux-x64.tar.gz
2021-10-31 23:50:23 INFO     Started OpenSearch with parent PID 1238080
2021-10-31 23:50:23 INFO     Waiting for Dashboards service to become available
2021-10-31 23:50:23 INFO     Pinging http://localhost:5601/api/status attempt 0
2021-10-31 23:50:23 INFO     Service not available yet
2021-10-31 23:50:33 INFO     Pinging http://localhost:5601/api/status attempt 1
2021-10-31 23:50:33 INFO     Service not available yet
2021-10-31 23:50:43 INFO     Pinging http://localhost:5601/api/status attempt 2

Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/837
Check List

[x ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #845 (6db81f5) into main (726a16e) will decrease coverage by 9.40%.
The diff coverage is 1.16%.

@@            Coverage Diff             @@
##             main     #845      +/-   ##
==========================================
- Coverage   91.48%   82.08%   -9.41%
==========================================
  Files          80       86       +6
  Lines        2231     2506     +275
==========================================
+ Hits         2041     2057      +16
- Misses        190      449     +259

Impacted Files
Coverage Δ

src/test_workflow/integ_test/local_test_cluster.py
80.83% <ø> (ø)

...rkflow/integ_test/local_test_cluster_opensearch.py
0.00% <0.00%> (ø)

...g_test/local_test_cluster_opensearch_dashboards.py
0.00% <0.00%> (ø)

src/test_workflow/integ_test/process_utils.py
0.00% <0.00%> (ø)

src/test_workflow/integ_test/service_opensearch.py
0.00% <0.00%> (ø)

...rkflow/integ_test/service_opensearch_dashboards.py
0.00% <0.00%> (ø)

src/manifests/bundle_manifest.py
94.23% <50.00%> (-5.77%)
:arrow_down:

src/system/temporary_directory.py
82.75% <0.00%> (-13.80%)
:arrow_down:

src/system/os.py
92.30% <0.00%> (-7.70%)
:arrow_down:

src/system/zip_file.py
100.00% <0.00%> (ø)

... and 2 more

Continue to review full report at Codecov.

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

Good start, still needs a bit of work to get to a mergeable state. I think you should extract Process code out of this into a separate PR first, with tests, and we can get that merged - it will reduce the size of this change by a bit.

Sure. Created https://github.com/opensearch-project/opensearch-build/pull/853/files

Related PR https://github.com/opensearch-project/opensearch-build/pull/853 has been merged. Thus I will resume working on this PR. Next steps:

rebase latest change

address PR comments

add more tests

Just performed rebase and quick clean up of the old ProcessUtils class (now replaced by Process class). PR is not ready for official review yet.

Added more subtasks for this issue to have incremental progress. See the main issue for details https://github.com/opensearch-project/opensearch-build/issues/604

This PR has been created for a while (17 days ago). Due to its size, we are breaking it down and working on small pieces in parallel to have incremental progress. Thus this PR will be open and serve as a reference purpose.
Ultimately it may be changed to only handle the last small piece or just been discarded.

Issue has been resolved through incremental work https://github.com/opensearch-project/opensearch-build/issues/837
Close this RFC PR


dracut: udevadm settle after writing the disk GUID

To prevent disk-manipulating services ordered against disk-uuid.service
from racing with udev manipulating the associated device symlinks, settle
immediately after we write the GUID.

LGTM

Seems reasonable.


studio: send images.

Closes #520.

Holding on to merge this until the front-end support is done so it can be tested fully end-to-end

@daavoo
Quick Update: I have merged the PR: https://github.com/iterative/studio/pull/5886 related to frontend support for the image on the studio side.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.02 :tada:

Comparison is base (d1864da) 95.97% compared to head (9d32293) 96.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #525      +/-   ##
==========================================
+ Coverage   95.97%   96.00%   +0.02%
==========================================
  Files          43       43
  Lines        2810     2828      +18
  Branches      240      241       +1
==========================================
+ Hits         2697     2715      +18
  Misses         66       66
  Partials       47       47

Impacted Files
Coverage Δ

src/dvclive/studio.py
92.30% <100.00%> (+1.19%)
:arrow_up:

tests/test_studio.py
100.00% <100.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


DF Module Name: Summarize issue...

Module
DF Chat Enhance 3.5.1 (under Foundry version 9)
Describe the issue
Can't send messages using chat box when pressing the enter key.
Produces the following stack trace:
libWrapper-wrapper.js:664 Uncaught TypeError: game.keyboard.getKey is not a function
[Detected 3 packages: df-chat-enhance, lib-wrapper, _chatcommands]
at ChatLog.🎁ChatLog.prototype._onChatKeyDown#df-chat-enhance (modules/df-chat-enhance/src/main.js:1)
at Z.🎁call_wrapper [as call_wrapper] (modules/lib-wrapper/lib-wrapper.js:1)
at ChatLog.🎁ChatLog.prototype._onChatKeyDown#0 (modules/lib-wrapper/lib-wrapper.js:1)
at HTMLTextAreaElement.jumpToMenuHandler (modules/_chatcommands/scripts/Autocomplete.mjs:219)
at HTMLTextAreaElement.dispatch (jquery.min.js:2)
at HTMLTextAreaElement.v.handle (jquery.min.js:2)
NOTE: This error gets thrown when any key is pressed in the chat box.
To Reproduce
Steps to reproduce the behavior:

Update Foundry to version 9.
Activate DF Chat Enhance using Google Chrome.
Click on chat box at bottom right corner.
type some message and press enter.
Instead of sending the message to chat (as normal), a newline is produced in the chat box.

Expected behavior
Enter key should send the message to the message log (and to other players).

Getting this as well. Have to play without the package :sob:

Yeah, none of the DF modules have been updated for V9 yet: https://discord.com/channels/170995199584108546/513918036919713802/923950716375146506


[seo-check]: Exclude email links from trailing slash rule

Should email links be excluded from the trailing slash check?
 'Internal links should include a trailing slash: [support<EMAIL_ADDRESS>does not.'

This one is an error as well right?
'Internal links should include a trailing slash: [\n    Start your wellness journey](/price-and-plans/?ref=home) does not.'


liquibase can't bootstrap a blank database

Liquibase fails to bootstrap a blank database on postgres 15, seemingly due to identity column changes that postgres made since 10.

The actual underlying issue is a change in the prior baseline is processed. Previously, <column autoIncrement="true" name="id" type="BIGSERIAL"> meant exactly what you'd expect, but it started meaning "use an IDENTITY column" at some point, so the implicit sequence-based default could not longer be replaced with a custom default.


Fix has_access() to pass on unrecognized kwargs like 'user'

This PR fixes has_access to pass on keyword arguments to super().has_access(), since the user keyword argument was added to Airflow's vendored/customized FAB security manager.

Tested on platform, looks good.


Amazing Bug With Forge 2304

hello. installed ONLY this mod, and setting the max-frame-rate option to unlimited, then press ESC to see the menu gui, aand minimize the minecraft window; minecraft ram usage increases regular forever.
normally, it uses 1600 MB in task manager, but when do that i told, it increases per second 1800..2000...2220...2540...(MB)
please help it :(
and it fixes when i set the max frame rate to the 60.

and i can record a video if you want. only Blur mod is installed on clean install of Vanilla (no resource pack, etc)

Sorry, in the video it's only vanilla? How did you come to the conclusion that this is caused by my mod?

because it happens only your mod is installed.

I do not do anything in this mod that would cause such memory issues, to my knowledge.
I'm going to need more evidence than a video from 3 months ago showing a vaguely similar issues. Please compare memory usage with and without the mod, in a way that can easily be reproduced.


THRIFT-5265 add the zlib transport to c_glib

[x] Did you create an Apache Jira ticket?  (not required for trivial changes)
[x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
[x] Did you squash your changes to a single commit?  (not required, but preferred)
[ ] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?
[ ] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

Hi,
(1) whats the status of this?
(2) who could be possibly revieweing this? Its not really a smal change ...
(3) crosstested against some other impl, like c++?

@Jens-G I will add crosstested against other impl soon.

Great!

Ping

@zeshuai007 merge?


[GLib] Add support for MatchSubstringOptions

Describe the enhancement requested
Target option
MatchSubstringOptions
Proposed feature
Add support for MatchSubstringOptions.
Impact of this request
It will be used in these functions:

count_substring()
count_substring_regex()
ends_with()
find_substring()
find_substring_regex()
match_like()
match_substring()
match_substring_regex()
starts_with()

Reference of this request
https://arrow.apache.org/docs/cpp/compute.html#containment-tests
Component(s)
GLib, Ruby

@heronshoes Do you want to implement this? Or can I implement this?

@kou Sorry I have no skill other than Ruby...

OK. I'll do it.

Thanks!


fixed inline xml extraction; added inline xml checksum validation

JIRA Ticket: https://jira.lyrasis.org/browse/FCREPO-3604 & https://jira.lyrasis.org/browse/FCREPO-3145
What does this Pull Request do?

Fixes the extraction of inline XML so that it is identical to what's in the FOXML
Validates that recorded inline XML digests match the transformed version of the XML

How should this be tested?
Run the migrator on an F3 dataset and compare the migrated inline xml to what's in the FOXML.
Interested parties
@fcrepo/committers

@pwinckles :  I'm testing this on the uwmadison dataset.  It appears to work, but interestingly there are some entries in foxml that have empty MD5 values for example:
in ./objects/dlmap/9/bb/cf/info%3Afedora%2F1711.dl%3AFolkFigures:39:
37 <foxml:datastream ID="RELS-EXT" STATE="A" CONTROL_GROUP="X" VERSIONABLE="true">
38 <foxml:datastreamVersion ID="RELS-EXT.0" LABEL="RDF Statements about this object" CREATED="2019-07-0    1T17:11:23.931Z" MIMETYPE="application/rdf+xml" FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt-    1.0" SIZE="1034">
39 <foxml:contentDigest TYPE="MD5" DIGEST=""/>
Just calling this out in case we want to the ability to skip this validation in the validation.

@pwinckles :  I'm testing this on the uwmadison dataset.  It appears to work, but interestingly there are some entries in foxml that have empty MD5 values for example:
in ./objects/dlmap/9/bb/cf/info%3Afedora%2F1711.dl%3AFolkFigures:39:
37 <foxml:datastream ID="RELS-EXT" STATE="A" CONTROL_GROUP="X" VERSIONABLE="true">
38 <foxml:datastreamVersion ID="RELS-EXT.0" LABEL="RDF Statements about this object" CREATED="2019-07-0    1T17:11:23.931Z" MIMETYPE="application/rdf+xml" FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt-    1.0" SIZE="1034">
39 <foxml:contentDigest TYPE="MD5" DIGEST=""/>
Just calling this out in case we want to the ability to skip this validation in the validation.

@pwinckles : I'm testing this on the uwmadison dataset. It appears to work, but interestingly there are some entries in foxml that have empty MD5 values for example:
in ./objects/dlmap/9/bb/cf/info%3Afedora%2F1711.dl%3AFolkFigures:39:
37 <foxml:datastream ID="RELS-EXT" STATE="A" CONTROL_GROUP="X" VERSIONABLE="true">
38 <foxml:datastreamVersion ID="RELS-EXT.0" LABEL="RDF Statements about this object" CREATED="2019-07-0 1T17:11:23.931Z" MIMETYPE="application/rdf+xml" FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt- 1.0" SIZE="1034">
39 <foxml:contentDigest TYPE="MD5" DIGEST=""/>
Just calling this out in case we want to the ability to skip this validation in the validation.

I'll update the code to skip those. I had assumed that the content digest wasn't being created for data like that.

@pwinckles : I'm testing this on the uwmadison dataset. It appears to work, but interestingly there are some entries in foxml that have empty MD5 values for example:
in ./objects/dlmap/9/bb/cf/info%3Afedora%2F1711.dl%3AFolkFigures:39:
37 <foxml:datastream ID="RELS-EXT" STATE="A" CONTROL_GROUP="X" VERSIONABLE="true">
38 <foxml:datastreamVersion ID="RELS-EXT.0" LABEL="RDF Statements about this object" CREATED="2019-07-0 1T17:11:23.931Z" MIMETYPE="application/rdf+xml" FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt- 1.0" SIZE="1034">
39 <foxml:contentDigest TYPE="MD5" DIGEST=""/>
Just calling this out in case we want to the ability to skip this validation in the validation.

I'll update the code to skip those. I had assumed that the content digest wasn't being created for data like that.

rebased to pull in github actions

Windows is refusing to read the xml as utf-8 encoded...

Rebased again to cleanup the windows mess. Finally got it working. Windows requires a declaration or else it will refuse to use the correct encoding no matter how many times you ask.


Allow 'bool' configuration type

Fixes #298

Does this work with convert and validate in type checking?

@AaronFriel Yup convert works and properly recognizes it as a bool

The failing lint tests seem to be an anomaly, ran gofmt and no issues


Update gradle dependency configs with new taxonomy. #482

Note that it is based on #472  currently.

Rebased on master.


DeviceLanguage  SaveInUserDefaults Swift 3

Hi, when I switch to a different language, the app switches to that language and the language is saved for the next time. If I switch back to the DeviceLanguage the app switches to the Device Language on the fly. But after restarting the app, the app is translated into the language translated which I selected before switching back to the DeviceLanguage.
This is in my viewDidLoad:
Localisator.sharedInstance.saveInUserDefaults = true
And this I what I call in the didSelectRowAt function
if indexPath.section == 0 {             if SetLanguage(arrayLanguages[0]) {                 print("Set Device Language")             }         } else {              if SetLanguage(arrayLanguages[indexPath.row + 1]) {                 print("Set User wanted language")             }         }
Nothing more
Cheers

Ok I added the following on your setLanguage
`fileprivate func setLanguage(_ newLanguage:String) -> Bool {
    if (newLanguage == currentLanguage) || !availableLanguagesArray.contains(newLanguage) {
        return false
    }

    if newLanguage == "DeviceLanguage" {
        currentLanguage = newLanguage
        dicoLocalisation = nil
        **userDefaults.removeObject(forKey: kSaveLanguageDefaultKey)**
        NotificationCenter.default.post(name: kNotificationLanguageChanged, object: nil)
        return true
    } else if loadDictionaryForLanguage(newLanguage) {
        NotificationCenter.default.post(name: kNotificationLanguageChanged, object: nil)
        if saveInUserDefaults {
            userDefaults.set(currentLanguage, forKey: kSaveLanguageDefaultKey)
            userDefaults.synchronize()
        }
        return true
    }
    return false
}`

Nice catch, thanks for submitting the workaround :)


Add postgres_replication.key_format, unique constraint on name

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#7  👈
#6
#5
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @acco and the rest of your teammates on  Graphite


Unexpected Crash

Unexpected crash! Please log a bug with the commandline you specified.
when running the command:
dts-gen -m @google-cloud/compute

See #138 for solution


sendOnClose function broken -- logs dropped when users navigate away from page

Navigating from a page to another should trigger "sendOnClose" which flushes the log queue when a page is closed.
user report that at transmittalInterval >50ms and logcountthreshold=1, the last log (e.g., 'click') isn't being transmitted.

Replicated bug: last click on page before redirect (linked button element) is not flushed out of queue to logging endpoint.
desired behavior is that any dump of page triggers a flush of the log queue to the server.
Built example mock at ./example/index.html on https://github.com/apache/incubator-flagon-useralejs/tree/flagon-userale-50
Confirmed with both example server and running single node ELK stack as logging backend.
NOTE: I'm seeing this issue for default params in .options. Desired behavior should be the same for default or modified--dump of page should trigger sendOnClose function.

document.addEventListener('visibilitychange', function () {
if (document.visibilityState === 'hidden' && logs.length > 0) {
navigator.sendBeacon(config.url, JSON.stringify(logs));
}
});
this code does work to the desired behavior.

document.addEventListener('visibilitychange', function () {
if (document.visibilityState === 'hidden' && logs.length > 0) {
sendLogs(logs, config, 1);
}
});
This code does not work. sendLogs doesn't seem to work when the page is in this state.

I have pushed the code that does work (commenting out the original code). However, it creates 2 other issues (at least):
-breaks submit events. Submit events trigger a refresh. We use sendLogs (sendOnRefresh) to push those logs immediately when the event is detected. However, during the refresh cycle, the page enters into a hidden state. Result is we sometimes get duplicate logs (we're firing the logs off x2), but easy fix (remove sendOnRefresh) and keep testing.
-breaks our logging server whenever page refreshes or navigate away or close--eg anytime sendOnClose would ship. Can see logs in ELK. Don't know why this happens.
TypeError: req.body.forEach is not a function
at /Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/example/server.js:77:12
at Layer.handle [as handle_request] (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/layer.js:95:5)
at next (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/layer.js:95:5)
at /Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/index.js:281:22
at Function.process_params (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/index.js:335:12)
at next (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/index.js:275:10)
at jsonParser (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/body-parser/lib/types/json.js:119:7)
at Layer.handle [as handle_request] (/Users/jpoore/Documents/Apache_Flagon/test/incubator-flagon-useralejs/node_modules/express/lib/router/layer.js:95:5)
Also, breaks 2 unit tests (expected -- will eventually need be fixed):   sendLogs
✓ sends logs on an interval
✓ does not send logs if the config is off
1) sends logs on page exit with navigator
2) sends logs on page exit without navigator
✓ does not send logs on page exit if config is off

NOTE: do extra testing on Browser Plugin. Could be non issue, could be big issue.

@UncleGedd This issues is a veritable existence proof for Journey Testing... Unit tests were deceptive given methods they used for mocking DOM. Resulted in lost data.

Updated sendOnClose to flush logs queue:
export function sendOnClose(logs, config) {
  document.addEventListener('visibilitychange', function () {
    if (document.visibilityState === 'hidden' && logs.length > 0) {
      navigator.sendBeacon(config.url, JSON.stringify(logs));
      logs.splice(0); // Clear array reference (no reassignment)
  }
});

resolves issue that any visibility change to 'hidden' state will send duplicate logs (e.g., switching tabs). This is desired behavior/intent for this function.

Removed sendOnRefresh from Submit event handling:
  Object.keys(refreshEvents).forEach(function(ev) {
    document.addEventListener(ev, function(e) {
      packageLog(e, events[ev]);
    }, true);
  });

sendOnRefresh was triggering duplicate events. Given that Submit events trigger a refresh which switches the page into a 'hidden' visibility state, sendOnClose now correctly pushes submit chain of events (change, click, submit, load).

might be some interesting literature:
https://volument.com/blog/sendbeacon-is-broken
they are aiming for a slightly different goal, but the data is useful. they also include what is presumably a solution to #65 with their Blob usage.

another good one:
https://calendar.perfplanet.com/2020/beaconing-in-practice/

That's great literature, @confusingstraw. Thanks! I'll checkout firing on pageHide and test against page refresh and navigation, closure. Looks like support for visibility change isn't great on safari. And, no I didn't test on safari, yet. Moz and Chrome are performing reliably though.
I will note that for the life me, I just can't get sendLogs to work with any event in the page close lifecycle--visibilitychange, unload, beforeUnload. .sendBeacon is the only thing I can get to ship packages when the page closes. The only way we were getting submit events (submits trigger a page reload), was to execute sendLogs directly from the submit event (refreshEvents) handler in ./src/attachHandlers.
Anyway, I'll do so further testing on pageHide and safari before I do a PR to test--I'll want some further review before we merge to test (especially since this breaks unit tests and may be undetectable my JSDOM methods--tests were passing before).

@UncleGedd are you open to helping me test this out a bit? I'm digging into this one tomorrow night, but if you're into it, I would love some more testing on this solution or any thoughts you have on an alternative.
hacky fix is running here: https://github.com/apache/incubator-flagon-useralejs/tree/flagon-userale-50. Code link to the patch: https://github.com/apache/incubator-flagon-useralejs/blob/0ec3645b828ff1429ec70beba8165102180d443b/src/sendLogs.js#L63-L66

Sure! I'll take a look today

Ok, I've got one of the tests working:
    it('sends logs on page exit with navigator', () => {
        const html = `<html><head></head><body></body></html>`;
        new JSDOM(html)
        const originalNavigator = global.navigator;
        let called = false;
        global.navigator = {
            sendBeacon: () => {
                called = true;
            },
        };

        sendOnClose([{foo: 'bar'}], {on: true, url: 'test'});
        Object.defineProperty(global.document, 'visibilityState', {
            get: () => 'hidden'
        })
        global.document.dispatchEvent(new Event('visibilitychange'))

        global.navigator = originalNavigator
        expect(called).to.equal(true);
    });

Basically I'm just faking the visibilitychange event and manually setting the visibilityState to "hidden" so the sendBeacon function will fire.
Regarding the other failing test:
it('sends logs on page exit without navigator', () => {
  // ...
}

In what case would we not have the navigator? Do we want to move away from using navigator.sendBeacon as the link Rob posted is suggesting?

@UncleGedd for future reference, i'd recommend checking out using these:
https://sinonjs.org/releases/v10.0.0/stubs/
https://sinonjs.org/releases/v10.0.0/spies/
when dealing with faking functionality, rather than setting up your own stuff like called = true. you can use these helpers to do some interesting stuff.

@confusingstraw, good call. That homemade spy has been there since before my time but I'll see if I can refactor it using sinon. (I think there's a few of these homemade spies floating around)

if that is the case then it is probably my fault. undo my madness.

I’d like to explore that RE alternatives to navigator.sendbeacon. Unfortunately, I can’t get sendLogs working against page unload event handlers (or visibility change events). The only thing that (I’ve tried) that works for this is sending data via navigator.sendbeacon triggered off of a visibility change event. So the ask wasn’t necessarily just to build unit or journey test, but really help shake this solution (integration test).
The problems with this solutionare:

navigator.sendbeacon isn’t as reliable as docs suggest (see Robs links in ticket)

That method is difficult to programmatically test (unit and journey)

Safari doesn’t support visibility change events as uniformly as Moz and Chrome.

Need some more hands on testing before we commit to the current course of action.
Joshua Poore

On Mar 24, 2021, at 12:56 PM, UncleGedd @.***> wrote:

Ok, I've got one of the tests working:
it('sends logs on page exit with navigator', () => {
    const html = `<html><head></head><body></body></html>`;
    new JSDOM(html)
    const originalNavigator = global.navigator;
    let called = false;
    global.navigator = {
        sendBeacon: () => {
            called = true;
        },
    };

    sendOnClose([{foo: 'bar'}], {on: true, url: 'test'});
    Object.defineProperty(global.document, 'visibilityState', {
        get: () => 'hidden'
    })
    global.document.dispatchEvent(new Event('visibilitychange'))

    global.navigator = originalNavigator
    expect(called).to.equal(true);
});

Basically I'm just faking the visibilitychange event and manually setting the visibilityState to "hidden" so the sendBeacon function will fire.
Regarding the other failing test:
it('sends logs on page exit without navigator', () => {
// ...
}
In what case would we not have the navigator? Do we want to move away from using navigator.sendBeacon as the link Rob posted is suggesting?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I don't think we are going to be able to send an HTTP request in those page unload event handlers, see this SO thread. I know the answerer mentions the unload and beforeunload events, but I'm sure the same reasoning applies to visibilitychange
It is indeed hard to ignore the stats from Rob's link regarding sendBeacon. Regardless, I don't think there is a way to get around using the visibilitychange event, and there are solutions to achieve a similar effect in Safari (search for "safari" in that link). Other ideas I'd like to test/mull over:

Web Workers: basic idea is to spawn a web worker whenever userale starts and do a postMessage on the visibilitychange (or any other) event, no more sendBeacon. (There may also be a larger conversation around using web workers in Userale as opposed to sending HTTP requests in the main browser thread, but I'm pretty inexperienced with this sort of thing, maybe @confusingstraw knows more about this)

Websockets: establish a websocket connection and send messages on the appropriate event, requires an elasticsearch plugin

Both of these solutions are more complicated than just using sendBeacon though. Regarding @poorejc's comment above:

navigator.sendBeacon may not be as reliable as expected, but it's simple to use
I think any solution will be difficult to test, although sendBeacon wasn't so bad to unit test, I'll write a journey test around it today
Agreed, but there may be a workaround as described in the link above

Ok, so I've tried writing a cypress/journey test for sendBeacon and it's pretty flaky. It does work in the browser (Chrome) consistently though

Fwiw, I've seen the exact same thing. Frustrating!
On Thu, Mar 25, 2021, 8:41 AM UncleGedd @.***> wrote:

Ok, so I've tried writing a cypress/journey test for sendBeacon and it's
pretty flaky. It does work in the browser (Chrome) consistently though
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-flagon-useralejs/issues/50#issuecomment-806668259,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOZLZ5KHRD77UBI3NNU4S3TFMVPRANCNFSM4Y2SOMLA
.

@UncleGedd you've confirmed some of my suspicions that the HTTP request isn't going to work triggered against events at the tale end of the page lifecycle.
Regarding your thoughts:

Sounds like an interesting idea. Will wait for more thoughts from @confusingstraw

We actually did have some user interest in a Websocket option for sendLogs. It's not a bad option for sendLogs, but I don't think it should be the 'only' option, which is what we're saying if we tie it to expected behavior for sendOnClose. The thing I don't like about that idea for canonical use is that it ties the library too closely to a specific backend. Our loose integration with back-end datastores was a design choice. I know some of our users are now using UserALE with different back-ends (not ELK).

Ok, so I've tried writing a cypress/journey test for sendBeacon and it's pretty flaky, but manual testing works in the browser (Chrome) consistently though

+1. Same here.

RE 3. Safari doesn’t support visibility change events as uniformly as Moz and Chrome.

I think after some more testing, we might end up settling on a conditional that sniffs for visibilitychange events and/or whatever most reliable equivalent is for Safari.

Ok, so I've tried writing a cypress/journey test for sendBeacon and it's pretty flaky, but manual testing works in the browser (Chrome) consistently though

I'll also add that I'd rather a flaky unit/journey test than actual flaky behavior in prod, or in integration tests. I don't want to make the limitations of the test harness make us choose something less reliable in production.
We should include a fix for this (even if not 100% reliable) in next release. I'll keep digging on my end for examples for how to test against sendBeacon. It's been around a while and pretty widely used, so there has to be some fix/hack that someone has done for unit/journey tests.
Thanks again @UncleGedd for fresh eyes on this.

No problem! Also, welcome @kevbrowndev!
Regarding the other failing unit test:
it('sends logs on page exit without navigator', () => {
  // ...
}

Is this unit test necessary? When will we ever not have the navigator?

No problem! Also, welcome @kevbrowndev!
Regarding the other failing unit test:
it('sends logs on page exit without navigator', () => {
  // ...
}

Is this unit test necessary? When will we ever not have the navigator?

That's obsolete given that the HTTP option is flat broken. That will be removed/refactored once we find a Journey test that works for sendBeacon (if)

Gotcha. I was able to get this journey test passing consistently, we can also add a "retry" option to cypress where it'll attempt the test a couple times if it fails.
    it('sends a log whenever a page is navigated away from', () => {
        cy.visit('http://localhost:8000')
        const spies = {beaconWasCalled: false};
        cy.window().then(win => {
            cy.stub(win.navigator, "sendBeacon", () => spies.beaconWasCalled = true);
            cy.contains('Link to Flagon Page').click()
        });
        cy.wrap(spies).its("beaconWasCalled").should("eq", true);
    });

Gotcha. I was able to get this journey test passing consistently, we can also add a "retry" option to cypress where it'll attempt the test a couple times if it fails.
    it('sends a log whenever a page is navigated away from', () => {
        cy.visit('http://localhost:8000')
        const spies = {beaconWasCalled: false};
        cy.window().then(win => {
            cy.stub(win.navigator, "sendBeacon", () => spies.beaconWasCalled = true);
            cy.contains('Link to Flagon Page').click()
        });
        cy.wrap(spies).its("beaconWasCalled").should("eq", true);
    });

Pardon the homemade spy, I got the code from here, and it's the only thing I could get working consistently

Welcome to Open Source, @UncleGedd--everything is "homemade" by a coalition of the willing :)

@poorejc @UncleGedd
I will try to keep this sane.

I don't think Web Workers help us very much, as the spec says that their behavior after their associated documents have gone away is implementation defined. Moreover, they are not allowed to respond to any additional events, so I don't believe they'd actually be able to observe the fact the page had closed. I could be wrong on the second point. Overall, there may be something there, but I am not confident that is the case.
Service Workers might be an effective alternative, as they let us run code regardless of whether the page is open (and regardless of whether there is an internet connection). The (large) downside is that it requires user-approval to install such a worker.
Websockets are great, the main drawback there is that we need to keep one open. This is maybe not so bad, but we also need to make sure it stays connected during periods of poor connectivity. We'd actually still run into the same issue we have now, though, since we'd still need to send a message when the page closes. I do not see any great resources describing how well that works. We could, however, potentially sidestep that requirement altogether by instead letting the server decide when the page was closed. By observing the client disconnecting from the server (and potentially not reconnecting for some time), we can assume they closed the page. This, however, introduces false positives if the client simply lost connection for a long period of time. Maybe not a bad thing, since we could replace "closed the page" with "disconnected".
Another option would be keeping long-polling request or similar mechanic alive, and having the server assume that when it disconnects that the client has left the page. This has a similar drawback as the above.
Lastly, I believe one of the articles I linked mentioned using Image objects as a form of data exfiltration. This could (maybe) be more reliable, but it would require the server to accept data in a different format (since it would arrive as part of the src URL).

Hopefully this was all coherent. I think Websockets are maybe the best, but I am not confident they actually completely solve the problem.

@confusingstraw you've always been someone I consider imminently sane.
Sounds like the right way to go is [3] Websockets @confusingstraw makes a compelling case.

it solves the connectivity and event handling problems
it's something that's pretty ubiquitous
it aligns with previous user interest
the consequences of the "false positive" is that everything in the log queue is sent to back-end and queue is flushed. That results in neither duplicate logs or dropped logs. Seems like a low severity risk
the big drawback is that we have to manage/maintain supporting plugins for ELK and probably provide some other examples for plugins to a few other datastores (e.g., postgress). That's not too crazy.

[1,2,4,5] seem like reaches and [5] seems like it would introduce other headaches.
If nothing else heard (feel free to add opinion here @kevbrowndev, @UncleGedd), I can put together some new tickets to cover this. Could use some help on this one.
Other thing would like opinions on:
To do this right, we should also make sure to mod and test our ELK stack and run full end-to-end integration tests. That could take a little longer. Is it worth doing a little more testing on this branch as is, pushing into next minor release (2.2.0) as a 'hot-fix', then doing the refactoring on sendLogs to websockets as the following release (2.3.0). Would be nice to make sure than NPM users have something incrementally better than current sendOnClose behavior (which doesn't behave at all?) Opinions?

Regarding the Websockets option, does this mean we would need to maintain the logs queue server-side as well? That way, whenever the connection is lost/interrupted, the server has a way of knowing what logs to flush?
I'd like to spike on the web worker/service worker option a bit (will work on it tomorrow). The goal wouldn't be for the web worker to listen to additional events, but rather use the visibilitychange  event in the main browser thread to perform a postMessage and have the worker perform the HTTP request. My assumption is that the worker will be able to perform the request in a more reliable way than sendBeacon

like i said, not entirely sure, but the spec does say that, once the document is closed, workers shouldn't be able to respond to any more events of any kind (no network updates, no new messages, zilch). if the postMessage occurs before the document goes away, then sure, that may work. always worth a shot.

I spiked on the web worker option today and had good results. I listened for the visibilitychange event to fire postMessage, and the web worker was able to consistently perform the HTTP requests before the document fully closed. Understood that this may not work on all browsers and will require more testing. However, I think this is a clean approach that doesn't require anything extra on the backend (and optimizes a bit on the client side).
Regarding websockets, I'm not sure where we would write the websocket server. It looks like the ELK stack only has support for clients

hey, if it works, it works. i don't think there is a need for websockets if the webworker fix seems to do the trick. they'd be a nice addition, but no need to pile on work that doesn't actually bring a lot to the table. i'd imagine we want to move all of the queuing/sendLog work into the worker.

@confusingstraw regarding service workers as an alternative in the comment above. Could you explain a bit more about how they require user-approval to install?

i might just be crazy. i could've sworn they required some form of user interaction to enable. in either case, though, it is possible to disable them entirely (as i have done so in my version of firefox). you can see the option at about:config under dom.serviceWorkers.enabled. you can see any installed works (if enabled) at about:serviceworkers. this means we'd need some kind of fallback for it.
i guess the same argument is also true of webworkers, as some extensions (like uMatrix) allow users to disable web workers entirely.

@UncleGedd thanks again! I'll take a look at this branch tomorrow, test like hell. Also, I'll try out some of the other events Rob discovered aside from visibilitychange and see if I get more reliable performance across browsers.

I finished up the spike and put it in a branch here. I was able to get a decent unit test in, but not a journey test. Currently, cypress does not support intercepting requests from workers. This solution works well in Chrome but not in Safari due to the lack of visibilitychange event support, and I haven't tested in Edge or IE. If you all like this solution, I'll continue the spike and start testing for other browsers.

I cloned your branch @UncleGedd. Doing some testing I'm getting really inconsistent behavior. Rebuilding everything, I'm not seeing that our filters are getting applied, or that custom logs are being generated. That's wonky, so I want to test again tomorrow. Not sure why that's happening, but it could be my env and I want to start clean tomorrow and test methodically with fresh clones and clear cache. I'll also pull your branch into useralejs repo (new branch).
I noticed that your branch doesn't remove sendOnRefresh from sendlogs (or refresh events in /src/attachHandlers). That would send submit logs when the page was refreshed without using sendOnClose...
Also, the new JSDOM test is failing for me. I get this error:

sendLogs
flushes the log queue on visibility change:
TypeError: Failed to execute 'dispatchEvent' on 'EventTarget': parameter 1 is not of type 'Event'.
at Object.exports.convert (node_modules/jsdom/lib/jsdom/living/generated/Event.js:22:9)
at Document.dispatchEvent (node_modules/jsdom/lib/jsdom/living/generated/EventTarget.js:228:24)
at Context. (test/sendLogs_spec.js:132:25)
at processImmediate (node:internal/timers:463:21)

Can't find much wrong with your constructor, and didnt find much out digging through related issues on SO.
Anyway, if you have the time and you want to test more: check to see that your not getting mouseovers on our example page (means filters aren't applying well). We should see custom decorated logs coming through clicking the first button. Also, removing sendOnRefresh from attachHandlers and sendLogs, if you see Submit events with webworkers, that makes me confident that they are working.

@UncleGedd, @confusingstraw I beat up the webworkers pretty good in Chrome and Safari.
BLUF: The web-worker solution does appear to work, but there's still some work to do. Solution seems to be working in the client, but they are very unreliable in successfully posting to the back end (ELK and example server). Details follow:

I did see 'submit' events (after removing sendOnRefresh from refresh events in ./src/attachHandlers), and I did see a 'click' event on a button linked to a web link (e.g., navigate away from page).
Its behavior is terribly unreliable. I only observed the above events x2 in about 25-50 sessions on the example page in Chrome and Safari. That being said, I did reliably see expected script behavior and network events in devtools. No error messages or info messages. But generally, no logs coming through to ELK or our example server (tried both)
I'm NO expert in webworkers. I suspect that the they may be behaving as expected in the client, but some feature of web workers are causing them to fail in posting data correctly to our backends. Seems like the backend is accepting one message sent by the webworkers, but no more. Unclear to me the conditions under which it accepts a message from a webworker. Tried restarting backends, but doesn't seem to reliably work.

Other things:

I played around with a few different configs in @UncleGedd's sendOnClose function. I tried eliminating the condition on configs turning off. This worked in my navigator.sendBeacon event. See: https://github.com/apache/incubator-flagon-useralejs/blob/0ec3645b828ff1429ec70beba8165102180d443b/src/sendLogs.js#L60-L66
I did see about the same behavior in chrome and safari with pagehide instead of visibilitychange. pagehide isn't as good as visibilitychange, but behavior is more consistent across browsers it seems. Something to ponder later, once we figure out how to reliably post logs. see below:

export function sendOnClose(logs, config) {
  if (!config.on) {
    return;
  }
  const worker = createWorker(workerSendLog)
  window.addEventListener('pagehide', function() {
      worker.postMessage({url: config.url, logs});
      logs.splice(0, logs.length)
  });
}

-visibilitychange triggerend sendOnClose unit test is still failing for me.
Lots more testing to do on web workers. I'm going to do some testing with navigator.sendBeacon and pagehide in Safari tonight. At the moment, that is our most reliable solution. I'd like to see if there are any JSDOM examples of mocks for navigator.sendBeacon. @UncleGedd if you have any thoughts or want to do deeper testing with webworkers, feel free. Don't want to discourage you on this--they seem to be producing the right behavior in the client, but they're currently failing integration testing.
FYSA: I merged test branch commits into UncleGedd's branch, took out sendOnRefresh (which was doing the work pushing 'submit' events, not sendOnClose), and pushed to a new branch here: https://github.com/apache/incubator-flagon-useralejs/blob/UncleGedd-sendOnClose/src/sendLogs.js. I also added a navigation button to the example page to test for submit events and page navigation behavior both.

Did some quick testing on https://github.com/apache/incubator-flagon-useralejs/tree/flagon-userale-50
BLUF: flipped out visibilitychange for pagehide listener. Seeing both 'submit' and end of lifecyce events (click before page navigation) events as expected everytime. Did about 2 sessions on Chrome and Safari each. Confirm visibilitychange handler will not work in safari.
Looking at @UncleGedd's unit test for https://github.com/apache/incubator-flagon-useralejs/tree/flagon-userale-50, its a test to see if the log queue is flushed when a given event fires. If I can get the test to work on pagehide, we might have a working unit test, skirting the difficulty to mock navigation.sendBeacon.

Thanks for the thorough testing! When I pushed up the branch all tests were passing so it may have been some inconsistency in our environments that was causing failing tests on your end. It is certainly strange that the web worker's network request appears in the dev tools but not in ELK. I'm able to consistently get the expected logs sent to the example app, but I haven't tried with a local ELK.
Nevertheless, I'm certainly not married to the web worker solution, sounds like it's pretty brittle. I may try another spike using service workers. Like Rob said above, they are supposed to exist regardless of what page is open.
Let me know if I can be of any assistance on the sendBeacon solution. That sounds like the best way forward.

Web-workers seem like a viable approach on its face. if @confusingstraw sees that it’s working, maybe it has legs—testing is a consensus game. One thing that might be affecting things is if you have npm modules installed globally that aren’t getting integrated locally. Usually, package-lock solves that, but sometimes not (my experience). I did test a direct pull of your branch a few nights ago and saw the same issues with unit test I reported out in the merged version.
Could be global/local module conflicts with some of the new packages in jsdom. I build exclusively from package files and don’t maintain any global modules. Also, what version of node.js are you using? I might be a minor version or two behind ‘latest', but I am running 15.x in testing (though didn’t see any LIFECYCLE error codes). Regardless, I’ll update to latest npm and test again. Also, happy to test again on whatever version you are.
When you run tests in the merged branch UncleGedd-sendOnClose, are you seeing test failures?
In observing logs, which kinds of events were you seeing in your testing that gave you confidence in your solution? Maybe I wasn’t clear in my previous comments, but i noticed that .src/attachHandlers code for refresh events still includes a sendOnRefresh function I hacked together: https://github.com/UncleGedd/incubator-flagon-useralejs/blob/f508dd95b69d129f68350e3f818ba3f28ad3fe0c/src/attachHandlers.js#L149-L154 https://github.com/UncleGedd/incubator-flagon-useralejs/blob/f508dd95b69d129f68350e3f818ba3f28ad3fe0c/src/attachHandlers.js#L149-L154 If you were relying on ’submit’ events as proof of life for web-worker sendOnClose behavior, sendOnRefresh might have been doing the work you thought sendOnClose was. You’ll notice I took out that function in the original flagon-userale-50 branch and in the new branch I pushed with your commits (UncleGedd-sendOnClose).
Overall, my proposal is this: let’s keep testing web-workers until we have consensus in testing (tests (unit/integration). If that doesn’t work we can explore web-sockets. However, right now navigator.sendBeacon is reliably passing integration tests. If we can mock a working unit test for that, we can release that as a patch in the next version (2.2.0). It is a less-than-ideal method. However, it’s working now (issues are theoretical and not yet observable). Point is: what we have now in 2.1.1 doesn’t work at all. navigator.sendBeacon will be more reliable than that. So keep testing web-workers, polish and push navigator.sendBeacon so we can close the open bug now, push navigator.sendBeacon in next release (unless breakthrough in web-worker/web-socket). Then, roll in a more elegant solution (web-worker/web-socket) in future release (2.2.1/2.3.0). Thoughts on this fake-it-till-you-make it solution?

On Apr 3, 2021, at 8:48 AM, UncleGedd @.***> wrote:
Thanks for the thorough testing! When I pushed up the branch all tests were passing so it may have been some inconsistency in our environments that was causing failing tests on your end. It is certainly strange that the web worker's network request appears in the dev tools but not in ELK. I'm able to consistently get the expected logs sent to the example app, but I haven't tried with a local ELK.
Nevertheless, I'm certainly not married to the web worker solution, sounds like it's pretty brittle. I may try another spike using service workers. Like Rob said above, they are supposed to exist regardless of what page is open.
Let me know if I can be of any assistance on the sendBeacon solution. That sounds like the best way forward.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/apache/incubator-flagon-useralejs/issues/50#issuecomment-812860922, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC474BTTCMEOAJKPG67XE7TTG4FAHANCNFSM4Y2SOMLA.

All of the tests in the merged branch are passing on my end, using Node version v14.8.0 and I don't have any global packages.
When I was testing the viability of web workers I was swapping between tabs and closing the tab that the example page was open in. Both of those actions resulted in a seeing a custom web worker log in the terminal where the example server was running. I'm confident that the log was coming from the web worker itself, not sendOnRefresh .  I was doing something like this in worker.js:
export function workerSendLog(e) {
    const {url, logs} = e.data
    fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify([{webworker: 'from web worker'}]) // custom web worker log
    })
}

One thing to make sure of is to set the data-interval to some value >1 in example/index.html and ensure that there are logs in the queue before closing the page (ie. click a couple of times and then close the tab to ensure there are logs to be flushed by the web worker).
I saw when running the example app that index.js was not being loaded, looks like this was due to Express not using the base directory to serve files from? I pushed a small change to the example app in that merged branch.
Check out this video I made showing the behavior I'm seeing: https://youtu.be/ri0AHBMai20

Also, you mentioned a sendNavigator unit test, will this suffice?
    it('sends logs on page exit with navigator', () => {
        const html = `<html><head></head><body></body></html>`;
        new JSDOM(html)
        const originalNavigator = global.navigator;
        let called = false;
        global.navigator = {
            sendBeacon: () => {
                called = true;
            },
        };

        sendOnClose([{foo: 'bar'}], {on: true, url: 'test'});
        Object.defineProperty(global.document, 'visibilityState', {
            get: () => 'hidden'
        })
        global.document.dispatchEvent(new Event('visibilitychange'))

        global.navigator = originalNavigator
        expect(called).to.equal(true);
    });

Great info, @UncleGedd. I’ll try testing it again with your parameters ASAP. Thanks again!

On Apr 6, 2021, at 4:45 PM, UncleGedd @.***> wrote:
Also, you mentioned a sendNavigator unit test, will this suffice?
it('sends logs on page exit with navigator', () => {
    const html = `<html><head></head><body></body></html>`;
    new JSDOM(html)
    const originalNavigator = global.navigator;
    let called = false;
    global.navigator = {
        sendBeacon: () => {
            called = true;
        },
    };

    sendOnClose([{foo: 'bar'}], {on: true, url: 'test'});
    Object.defineProperty(global.document, 'visibilityState', {
        get: () => 'hidden'
    })
    global.document.dispatchEvent(new Event('visibilitychange'))

    global.navigator = originalNavigator
    expect(called).to.equal(true);
});

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/apache/incubator-flagon-useralejs/issues/50#issuecomment-814427806, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC474BSXS6OT4IWCHOHBMDDTHNXFZANCNFSM4Y2SOMLA.

All of the tests in the merged branch are passing on my end, using Node version v14.8.0 and I don't have any global packages.
When I was testing the viability of web workers I was swapping between tabs and closing the tab that the example page was open in. Both of those actions resulted in a seeing a custom web worker log in the terminal where the example server was running. I'm confident that the log was coming from the web worker itself, not sendOnRefresh . I was doing something like this in worker.js:
export function workerSendLog(e) {
    const {url, logs} = e.data
    fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify([{webworker: 'from web worker'}]) // custom web worker log
    })
}

One thing to make sure of is to set the data-interval to some value >1 in example/index.html and ensure that there are logs in the queue before closing the page (ie. click a couple of times and then close the tab to ensure there are logs to be flushed by the web worker).
I saw when running the example app that index.js was not being loaded, looks like this was due to Express not using the base directory to serve files from? I pushed a small change to the example app in that original branch.
Check out this video I made showing the behavior I'm seeing: https://youtu.be/ri0AHBMai20

A few findings:

Unit and Journey tests are now passing for me on this branch. May have had some collision when I last tested, also looks like node-fetch was missing from package, which broke jsdom-worker. Adding in that and tests are passing.

Webworkers do appear to send logs during tab changes. I was able to replicate your test with the web-worker. I consistently saw custom messages from the web worker flipping between tabs (jacked log interval to 5 from 1). They are reliably shipping data to the right URL and they are reliably firing off of the visibility change event.

Webworkers aren't working reliably for end of page life cycle visibility events. In that same test [2], web workers fired reliably for tabbing back and forth. However, they did not work for submit and navigation events. Similar to my earlier testing (reported above), I do see submit and click events for linked buttons sporadically--they are very rare and unpredictable. I tested under a wide range of constraints and I don't see a pattern. The common theme is that webworkers don't seem to work reliably (or at all) when the page is unloading. I confirmed this in devtools looking at xml request traffic.

webworkers don't seem to work with pagehide events. I'll test this some more, but I didn't see any behavior (e.g., [2]) using pagehide events. If true, that limits webworkers' utility in Safari.

I'll do a little more testing soon, but I'm leaning toward fixing this issue with navigator.sendBeacon in the next release. Call it a hotfix. We can keep testing webworkers or move to websockets for more elegant solutions. I'll work with and look into your unit test for navigator.sendBeacon @UncleGedd that's very helpful, thanks!

Good to know and thanks again for the thorough testing. Agreed that navigator.sendBeacon is the way forward for now.


Feature Request: Duplicate existing Task

I would like to have an option for copying an existing task.

Maybe we can use a share Intent for this. Sharing a task with OpenTasks could open the editor with a copy of the task data.


Wiki Review

I'm opening this as an issue to track the task, since the Wiki isn't done via pull requests.
It'd be really helpful to get a few other hands to try out especially the installation tutorial on the Wiki.
@seankrag @crvogt this might be a good starting point when you are ready to jump on the boat.
Main page
https://github.com/osrf/vorc/wiki
It's a bit bare, I don't know if we want to move the tutorials to the main page. I was thinking leaving space for documents and other things, but now it seems those will go on the website instead. Then maybe this page looks better with the tutorials directly listed here. Feedback welcome.
Tutorials
https://github.com/osrf/vorc/wiki/tutorials
I've tested the installation tutorial in a barebone nvidia/opengl:1.0-glvnd-devel-ubuntu18.04 Docker image. All the steps up to and excluding the GUI also worked in a more barebone ubuntu:bionic Docker image (which doesn't have graphics).
So the installation should work if you run them on any Ubuntu 18.04 host machine.
Let me know if things don't work for you.
(We are assuming and only providing instructions for installing on host, as opposed to building and releasing a Docker image, due to time constraints.)

Thanks, Mabel.
My main laptop is PopOS on Ubuntu 20.04 but I have another laptop running
standard Ubuntu 18.04. I'll give these install tutorials a try...
Sean
On Wed, Oct 7, 2020 at 2:23 PM Mabel Zhang<EMAIL_ADDRESS>wrote:

I'm opening this as an issue to track the task, since the Wiki isn't done
via pull requests.
It'd be really helpful to get a few other hands to try out especially the
installation tutorial on the Wiki.
@seankrag https://github.com/seankrag @crvogt
https://github.com/crvogt this might be a good starting point when you
are ready to jump on the boat.
Main page
https://github.com/osrf/vorc/wiki
It's a bit bare, I don't know if we want to move the tutorials to the main
page. I was thinking leaving sections for documents and other things but
now it seems maybe we'll be putting those things on the website instead.
Feedback welcome.
Tutorials
https://github.com/osrf/vorc/wiki/tutorials
I've tested the installation tutorial
https://github.com/osrf/vorc/wiki/Installation-on-Host in a barebone
nvidia/opengl:1.0-glvnd-devel-ubuntu18.04 Docker image. All the steps up
to and excluding the GUI also worked in a more barebone ubuntu:bionic
Docker image.
So the installation should work if you run them on any Ubuntu 18.04 host
machine.
Let me know if things don't work for you.
(We are only providing the instructions for installing on host, as opposed
to building and releasing a Docker image, due to time constraints.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/osrf/vorc/issues/3, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARJIVT7KOLYPZA2MWWIZWNTSJTL6TANCNFSM4SH5RCSQ
.

Thanks for trying it out! Do you remember if you ran sudo apt full-upgrade in the very beginning, and this still happens?

I didn't skip any parts, so I'm *sure I ran that as well. Though it seems like gazebo would have been upgrade with that command, so it's making me doubt myself.

Thanks! I will leave the instructions as is for now, and if anyone else complains, I'll add a troubleshoot section.

Hi Mabel,
Sorry this is tardy, but I was finally able to get everything installed and
running on my Ubuntu 18.04 host. Instructions should work fine for a clean
18.04 setup. I encountered a few problems, but these were due to a previous
installation and some environment variables in my laptop's ~/.bahsrc file.
Best,
Sean
P.S. Documenting my issues below for posterity....

installed prerequisites fine, but saw apt messages saying my gazebo was
upgradable
colcon build threw an error while compiling wave_gazebo_plugins:
fatal error: sdf/sdf.hh: No such file or directory
tried another full-upgrade (because of #1 above): colcon build still had
fatal error
uninstalled gazebo9; reinstalled gazebo9; repeated all VORC setup
instructions: colcon build still failed
deleted build, install, and log directories
tried rebuilding with catkin_make instead: this worked!
sourced devel/setup.bash (catkin_make created devel instead of install)
roslaunch vorc_gazebo marina.launch: crashed due to prior robot's ROS_IP
address hard coded in my ~/.bashrc file
fixed ROS environment and roslaunch vorc_gazebo marina.launch works!
removed build, devel directories
tried building again with colcon build: now everything builds
successfully
sourced install/setup.bash
roslaunch vorc_gazebo marina.launch works!

Note: I began this process on my primary laptop, which runs Pop!_OS on
Ubuntu 20.04
This was a non-starter because dfault ros for 20.04 is ros-noetic; I
couldn't easily install ros-melodic, and hector_gazebo_plugins package
requires ros-melodic
On Mon, Oct 19, 2020 at 10:43 AM Mabel Zhang<EMAIL_ADDRESS>wrote:

Thanks! I will leave the instructions as is for now, and if anyone else
complains, I'll add a troubleshoot section.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/osrf/vorc/issues/3#issuecomment-712328132, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ARJIVT35E2B3IV4O3SUB7Y3SLR3ERANCNFSM4SH5RCSQ
.

Thank you Sean for trying it out and the notes!
That is good to know - I did not know hector_gazebo_plugins requires Melodic.
I wonder if colcon would have also worked in step 5, after you cleaned the directories. It is good to see that colcon worked in step 10.
VRX was built with catkin and I changed to colcon for VORC because colcon is more modern. I hope they behave the same.
My takeaway from both of your trials is that we should set up a Dockerfile soon... ha, so that people have clean environments. Looks like pre-existing Gazebo versions can really make people's life frustrating. Cc @caguero
I added a line near the top of the page so that people are warned.
Otherwise I think this issue can be closed.


Fix real equality comparison error

Changed the real equality comparison to an abs comparison. This allows to be compiled without an error as reported in this issue

This looks good, thanks @krvajalmiguelangel. However, can you please remove the binary file .gitignore.swp from the commit?


bug: forgot password

Description
forgot password does not ask for email before showing the sent OTP option
Screenshot

Please assign this issue to me under gssoc. @i-am-SnehaChauhan @MonalikaPatnaik

Good bug..
start working on this you are assigned!


Document which platforms turicreate is able to support GPU acceleration.

It's helpful that turicreate communicates at runtime that "Using GPUs is currently not supported on Mac". However, runtime feedback can be a little late in a setup process (e.g. after working through how to install MXNet from source with CUDA support on a Mac).
Could this limitation be mentioned in the GPU documentation? It may help some Mac enthusiasts with NVIDIA cards find this out early and avoid going down the road of trying to setup GPU support for  turicreate on their Mac.

@otto-schnurr since MXNet 1.0 works fine with NVIDIA eGPU on Mac if you build from source... won't Turi Create 4.1 work with this?

@helloniklas Yeah, I don't know the backstory behind the toolkit error. In case it involves something more than just MXNet capability, I haven't tried to venture past it.
But yes, even with a CUDA-enabled MXNet, I seem to eventually run into this toolkit error when I try to set_num_gpus() to 1 on my Mac.


Viewer updateSize

I have a scenario where I create when the element width is 1920 ,but display is none. I found the result of 'viewer.viewport. getContainerSize' is {x:1,y:1}, when I was to make the display element for block, I try to use the viewer. ForceResize to update, it won't work,But I observed the result of 'viewer.viewport. getContainerSize' is {x:1920,y:1080},Why doesn't he work? Maybe I want a similar one viewer.navigator.updateSize.I found it to have the effect I wanted

You need to give the viewer a defined height too via css.


iq_utils.h

Where is this file? Searched all your repositories, nothing was found

Sorry for the late reply.  Thought I had notifications set for this repo.  Here's the file location:
https://github.com/davemers0160/Common/blob/master/include/iq_utils.h


Adding release notes about the lack of Delivery CLI in 0.14 Windows packages

\cc @btm @mwrock @PrajaktaPurohit @randomcamel

👍

:+1:


Revert "Bump codecov/codecov-action from 3.1.5 to 4.0.1"

Reverts y-iihoshi/ThScoreFileConverter#438 because codecov-action@v4 causes the following error:

Error: Codecov token not found. Please provide Codecov token with -t flag.

even if my CI action passes the token as follows (unchanged since v3.1.5):
    - name: Upload coverage to Codecov
      uses<EMAIL_ADDRESS>      with:
        token: ${{ secrets.CODECOV_TOKEN }}
        file: CoverageResults/coverage.${{ inputs.dotnet-target-framework }}.opencover.xml
      if: inputs.dotnet-configuration == 'Debug'

It was my fault... Resolved by 2ac25f080bce3e28260f761be6768dc245be98ff in #465.