Code listing titles could be styled in HTML output

AsciiDoc allows code listings to have titles (typically file name). However, they look ugly and confusing in YARD documentation. In particular, they are difficult to distinguish from regular paragraphs.
Obviously, using a custom template may help a lot. However, this issue should be addressed in a default template IMO.
I am not sure if this issue belongs to this repository or rather to https://github.com/docmeta/rubydoc.info.
Steps to reproduce
Following AsciiDoc document was used to illustrate the issue:
== In AsciiDoc...

This is a lead paragraph.  Code listing starts right below.

.test.rb
----
two = 1 + 1
eleven = "1" + "1"
raise if Failure.problem
----

This is the second paragraph.  Code listing has just ended.

With default settings, YARD translates it to a following piece of HTML:

In AsciiDoc…

test.rb

two = 1 + 1
eleven = "1" + "1"
raise if Failure.problem

test2.rb

two = 2 + 2
eleven = "2" + "2"
raise if Failure.problem

Actual Output

Expected Output
Something of similar quality like:

I can prepare CSS updates if this is non-controversial.
I have read the Contributing Guide.

@lsegal How about this one? Can I implement such feature, or is it something what doesn't fit to YARD for some reason?

cc @lsegal

@lsegal Two more ideas:

Achieved with a following CSS change (the darker variant is commented out):
/* code block titles (supported in AsciiDoc) */
#filecontents .listingblock .title {
  padding: 9px 14px 9px 14px;
  margin-top: 4px;
  border: 1px solid #e1e1e8;
  background: #efeff1;
  /*background: #e1e1e8;*/
  border-radius: 4px;
  font-size: 1em;
  overflow-x: auto;
  line-height: 1.2em;
  margin-bottom: -9px;
}


fix: typo in Hungarian locale file

Description
In the 'mighty' hungarian language we don't use plurals after numbers. This will fix it on the Categories page.

Type of change

[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 not work as expected)
[ ] Documentation update

How has this been tested

[ ] I have run bash ./tools/deploy.sh --dry-run (at the root of the project) locally and passed
[x] I have tested this feature in the browser

Test Configuration

Browser type & version:
Operating system:
Ruby version:
Bundler version:
Jekyll version:

Checklist

[x] I have performed a self-review of my code
[ ] I have commented on my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

Their plural form is different from singular, but if they appear after a number, they are grammatically correct. Unfortunately, I didn’t check out these two new texts in the categories at first.


Watchify + BRFS

Not ready to merge yet, but wanted to create a place for discussion. This current PR includes the (rebased onto master) brfs branch, in addition to a watchify workflow.
I've changed module.js to avoid explicitly providing Tangram on the window object, favoring using browserify's standalone bundling process which creates a UMD build (which implicitly creates the window object). We can also decide whether we want Tangram set on the worker instances as well.
To be decided on how this should work in tandem with the makefile. As mentioned in an email, I would suggest moving away from the makefile and towards simple npm scripts, so a developer can run
npm run dev // for bundling and watchify
npm run bundle // for bundling, minifying
npm run test // calls your Karma test suite

Currently I've avoided this issue by putting the build in a separate script, build_dev.js

For the worker, it's useful to have the debug items available somewhere, is that still happening but on self now (here)?
I used make originally because it seemed the most "timeless" / agnostic to the rest of the pipeline, but I'm not tied to it if it's hindering the workflow. Running a watchify process from a make command doesn't inherently bother me, but if you think it would be weird to a typical developer (vs. expected by an npm command), moving towards npm scripts is fine with me (and I suppose we are not likely to move away from npm anytime soon).
For the watch process, what is a good way to handle switching branches? I noticed this was an issue when I was testing it out, I frequently switch branches and it seemed to be getting confused. Likewise, I don't recall seeing any error output, the build was silently failing. Those both seem issues that interfere with everyday use, otherwise the experience was much improved.
Small note on tests, I usually use the combination of make karma-start to start the Karma browser, then make run-tests several times (so the browser only needs to be setup once, not each time the tests are run). We can account for this with appropriate parallel npm scripts if we're moving to that.

I'm fine with either a makefile or npm scripts. Having a make command like make bundle-watch or something works. I have a preference for npm scripts as I think it's more friendly to the JS dev community and they don't come with the dependency burden of gulp/grunt. If we decide on npm scripts we can have both those and make commands and gracefully deprecate one if that's a concern.
Do you mean switching git branches? I'm not sure why there would be a problem. Maybe some things aren't npm installed in other branches?
For the build silently failing. It seems to add syntax error support, you need more middleware, go figure. There is a generic syntax-error module https://www.npmjs.com/package/syntax-error, or we can go with a some middleware choices (which may be a good option anyway because it can refresh the browser automatically on bundle creation):

https://www.npmjs.com/package/watchify-server
https://www.npmjs.com/package/watchify-middleware
https://www.npmjs.com/package/errorify

npm scripts is cool.
Middleware to automate reload sounds interesting (I do think syntax error
feedback is needed or you can end up pretty confused as to why it's not
updating). Have you checked out the budo dev server?
Not sure what I was seeing with git branches, I'll try again when the
rest of this is ready.
Did you want to also remove the shaderSources module?
On Tuesday, April 12, 2016, David Valdman<EMAIL_ADDRESS>wrote:

I'm fine with either a makefile or npm scripts. Having a make command like make
bundle-watch or something works. I have a preference for npm scripts as I
think it's more friendly to the JS dev community and they don't come with
the dependency burden of gulp/grunt. If we decide on npm scripts we can
have both those and make commands and gracefully deprecate one if that's a
concern.
Do you mean switching git branches? I'm not sure why there would be a
problem. Maybe some things aren't npm installed in other branches?
For the build silently failing. It seems to add syntax error support, you
need more middleware, go figure. There is a generic syntax-error module
https://www.npmjs.com/package/syntax-error, or we can go with a some
middleware choices (which may be a good option anyway because it can
refresh the browser automatically on bundle creation):

https://www.npmjs.com/package/watchify-server
https://www.npmjs.com/package/watchify-middleware
https://www.npmjs.com/package/errorify

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/tangrams/tangram/pull/291#issuecomment-209128894

Seems budo is a good way to go. The launch script would be:
budo src/module.js:dist/tangram.debug.js --live -- -t [ babelify --optional runtime ] -t brfs -s Tangram

This obviates the need for the node build_dev.js script and can simply be run via command line/npm script. Not getting syntax errors to appear, however..
I believe the shaderSources module is still needed unless we want to remove the brfs approach for glslify. Right?

I think you can get this to work with brfs the same way you would with glslify (both just generate a string), wherever each shader is reference, you would use the brfs call instead of referencing shaderSources, e.g.
In https://github.com/tangrams/tangram/blob/brfs-valdman/src/styles/style_manager.js#L30:
ShaderProgram.addBlock('global', shaderSources['gl/shaders/accessors']);
becomes
ShaderProgram.addBlock('global', fs.readFileSync(__dirname + '/shaders/accessors.glsl', 'utf8'));

Sure that works. I can replace those parts of the codebase.

Oh except here they are referenced dynamically, but that could be refactored so each Style directly referenced its shader string, instead of the name of a value within shaderSources, e.g.:
In https://github.com/tangrams/tangram/blob/ac07620a124c0b15716e2b9cb455dad56d437740/src/styles/polygons/polygons.js#L15:
vertex_shader_key: 'styles/polygons/polygons_vertex'
could become something like:
vertex_shader_base: fs.readFileSync(__dirname + '/shaders/styles/polygons/polygons_vertex.glsl', 'utf8')
(It may have been prematurely abstracted)

Removed the watchify script in favor of an npm script using budo. Now a developer just needs to run (after npm install)
npm run watch

To have a live-reloading browser and incremental building of tangram.debug.js

:raised_hands:

Seems a worker test living on your CI server (/tangram.test-worker.js) is failing

Seems the tests may be failing because the test bundle (make test-ci) isn't being built as a UMD module, and we removed the bit in module.js that set the Tangram symbol globally?

Yeah I think that's what's going on. I wasn't able to test locally, so I pushed up new dist files (was going to force revert after). Then I noticed the makefile was creating a special test distribution. It would be good to sit down and get the local testing up and running.

Spent all day fiddling with karma configs :-( That little green check mark makes it all worth it though. The last commit changes the testing process slightly. Instead of building two bundles, tangram.test.js and tangram.test-worker.js, now there is just one build tangram.test.js (which is a staging test bundle of Tangram) and the individual test files are loaded by the karma configuration file. This eliminates the redundancy and gives an easier path to moving to simpler npm scripts and away from the makefile.

:boom:

What do you think about putting this on a path to merging with master? I'd like to replace the other make commands with npm scripts, and update the brfs calls.

Sounds good! Once that's done I'll give it a whirl to see if I notice anything, otherwise good to go.

Besides the gzip command, which I'd still like to include, this branch is ready for testing to incorporate into master! @bcamper

To summarize the diff:

uses brfs and inline calls to shader source text
more efficient build to karma testing suite by bundling tests into the karma config
uses budo for incremental building and a live reloading browser (npm run watch)
migrates from makefile to npm scripts. Common scripts described below:

	npm run test // lints, builds tangram.test.js, and runs karma (for use on circle CI)
	npm run test-local // lints, builds, tangram.test.js and runs karma locally (single run)
	npm run karma-start // sets up karma
	npm run karma-run // runs tests after setup
	npm run build // bundles tangram.debug.js and minifies to tangram.min.js
	npm run build-debug // bundles tangram.debug.js
	npm run watch // runs budo for incremental building and live reloading

build.js, build_deps.sh, and watch.sh (old watcher) can all be removed now too, right?

Head's up I switched the local port back to 8000, just because it's what we've used historically and is likely to cause the least disruption (we often have branches or local modified copies of demos or Tangram Play that point to local copies of Tangram on 8000, for testing them in tandem).

Alright, pegged the dependencies, reused the same shaders in lines.js from polygons.js and deleted the deprecated build/watch scripts. I also declared the shader sources as const. Are they mutated eventually in the pipeline? If so I can revert this change.

const is only going to ensure that the reference of the property defined as const doesn't change (e.g. shaderSrc_spotLight itself shouldn't be set to a different string at run-time). But once those are copied to a style property like vertex_shader_src, all bets are off. ShaderProgram does the actual shader string construction, and these strings are passed in / copied when that is instantiated anyway, so in summary everything should work (and you'd know right away if it didn't anyway... :)

👍  I'll be changing the contributing.md file to reflect the changes. Sorry to not do this with the PR.


Report CompileTime metric in flutter build aot --report-timings.

This is the correct metric to report for compilation time benchmarks rather
than RunTime. Rename the 'gen_snapshot' value to merely 'snapshot' for
backwards compatibility and overall simplicity.
This change simplifies Dart's benchmarking of Flutter by making it easier to
adopt --report-timings (made for Dart to use), which makes the benchmarks
much more robust.
Description
This changes matches what the Dart benchmarking infrastructure needs a little better than the existing behavior. I don't believe anything else is using --report-timings, so this should be fine to slightly change.
Related Issues
The --report-timings flag was introduced in #30032 for use by dart's benchmarking infrastructure.
Tests
I updated the existing test to test the new behavior. I couldn't figure out how to run the test though, cd packages/flutter_tools $ flutter test test/base/build_test.dart failed to me with Failed to load test harness. Are you missing a dependency on flutter_test? and FileSystemException(uri=org-dartlang-untranslatable-uri:package%3Aflutter_test%2Fflutter_test.dart; message=StandardFileSystem only supports file:* and data:* URIs). Let's see if the PR checks work here on github.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[X] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[X] I signed the CLA.
[X] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[X] I updated/added relevant documentation (doc comments with ///).
[X] All existing and new tests are passing.
[X] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[X] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
[X] No, this is not a breaking change.

@mraleph

Merged for @sortie because he does not have repository access (AFAIK).


[AMQ-8397] Add a destination option to sendDuplicateFromStoreToDLQ

Default 'true' to match existing behavior
Added counter to DestinationView

I think this should be set to 'false' as default for 5.17.0.


cythonize py files?

This project looks awesome! And I couldn't find anything like it, thanks!!
i'm trying to cythonize python files and compile them to c (for performance and not open source reasons).
I think that the build.py file is hard coded to look for .c and maybe .pyx files, and doesn't not look for *.py files.
this code, inside a setup.py, has done what I wanted before. but it's in a setup.py and can't use cibuildwheel.
ext_modules=cythonize(
    "<top-level-dir>/**/*.py",
    compiler_directives={'language_level': 3, "linetrace": False},

I tried to figure out what to do for a setuptools Extension to do the same thing and didn't quite get things to work.
Is there already a way to cython the *.py files that I missed? Or what would you recommend?

I'm still learning cython myself, butI think you can just add the path to all the python files you want to cythonize to the list here:
https://github.com/BrianPugh/python-template/blob/9e217e7d27ee91c7da70ef7c55bd2445b47c685e/build.py#L42
You can also do it programmatically, like if all the python files you want are in the directory foo/, you could add *Path("foo").rglob("*.py").

Thanks! I think this worked, and I now see *.c files produced for *.py files. This is what I added:
    c_files = [str(x) for x in Path("librarytemplate/_c_src").rglob("*.c")]     **py_files = [str(x) for x in Path("librarytemplate/").rglob("*.py")]**     extensions = [         Extension(             # Your .pyx file will be available to cpython at this location.             "librarytemplate._c_extension",             [                 # ".c" and ".pyx" source file paths                 "librarytemplate/_c_extension.pyx",                 *c_files,                 *py_files,             ],

Thanks, I'll close this issue


String slice arguments are not parsed corectly

I try to execute the following command
omg-cli photon \
  --dns <IP_ADDRESS>,<IP_ADDRESS>

on the deployed vm I see in /etc/resolv.conf
nameserver <IP_ADDRESS>,<IP_ADDRESS>

Passing coma separated list of values also don't work for '--network-dns-1' flag when deploying cloud-config, though help message says that this parameter expects comma separated list.

Slice flags should be specified by duplicating the flag name.  For example:
--dns <IP_ADDRESS> --dns <IP_ADDRESS>
The exception to this is when the flags are stored in Vault.  In this case, we store a comma separated string in Vault and handle the splitting internally.
You're correct that the help message incorrectly mentions a comma separated list.  We'll fix that.


Does not work with Xamarin Forms 2.5

When creating a ViewRenderer<NullableDatePicker, EditText> in 2.5 the android render constructor needs to be created like:
NullableDatePickerRenderer(Context context): base(context)
This seems to be causing the renderer to crash. I'm new to Xamarin and have tried a few work arounds with no luck. Any help would be appreciated.

Updated the sample to XF 2.5,  let me know if still have any issues.

I've looked at your changes and am still having the same issue. When I debug and set break points it seems to work fine in the NullableDatePicker code. When it comes to the constructor in the renderer it fails. Unfortunately it fails with "No compatible code running" so I don't know what the exact error is but it never gets past the base constructor of the renderer.
I've tried other peoples custom nullable date pickers with renders and they work perfectly fine but they are not as nice of a solution as this nullable picker is if I could get it working.
Other date picker renders inherit from DatePickerRenderer instead of ViewRenderer<NullableDatePicker, EditText>. I suspect passing a context to ViewRenderer is causing some issue.

I resolved the issue. I updated my android sdk's and that seemed to solve the problem. This can be closed.


docs: update manual

Codecov Report

Merging #265 into dev-1.5 will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           dev-1.5     #265      +/-   ##
===========================================
- Coverage     14.2%   14.19%   -0.02%
===========================================
  Files          280      280
  Lines        19179    19179
===========================================
- Hits          2725     2723       -2
- Misses       16454    16456       +2

Impacted Files
Coverage Δ

libdevcore/easylogging++.cpp
39.89% <0%> (-0.16%)
:arrow_down:

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 716838b...be9743b. Read the comment docs.


Check named exports on destructured require

Related: #1145
Adds an option commonjs to named rule, which will check a destructured require statement.
Invalid:
// ./foo.js
export const foo = 'bar';

// ./bar.js
const {baz} = require('./foo');

valid:
// ./bar.js
export const bar = 'foo';
export const foo = 'baz';

// ./baz.js
const {bar} = require('./bar');

// ./foo2.js
const {bar, foo} = require('./bar');

// ./foo3.js
let {bar} = require('./bar'), {foo} = require('./bar');

Coverage decreased (-0.3%) to 96.948% when pulling b776460e27dbe7847b5ef7c8e124384f86515a71 on vikr01:feature/named-require into b4a2f11fcacc6b2f048da4b29cfc896e682f17d1 on benmosher:master.

Coverage decreased (-0.3%) to 96.948% when pulling b776460e27dbe7847b5ef7c8e124384f86515a71 on vikr01:feature/named-require into b4a2f11fcacc6b2f048da4b29cfc896e682f17d1 on benmosher:master.

Coverage decreased (-0.3%) to 96.948% when pulling b776460e27dbe7847b5ef7c8e124384f86515a71 on vikr01:feature/named-require into b4a2f11fcacc6b2f048da4b29cfc896e682f17d1 on benmosher:master.


Branch improve tasklink UI

Codecov Report

Merging #157 (30f39c1) into master (a88bc38) will decrease coverage by 0.12%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #157      +/-   ##
============================================
- Coverage     61.81%   61.68%   -0.13%
  Complexity      521      521
============================================
  Files           103      103
  Lines          1998     2002       +4
  Branches        214      214
============================================
  Hits           1235     1235
- Misses          692      696       +4
  Partials         71       71

Impacted Files
Coverage Δ

src/main/java/seedu/address/ui/TaskCard.java
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


SICHUAN AIRLINES A350-900 (Panda 2）

5.2MB！
I hope there are no errors in its connections.

@kolos26 Hi！I guess you saw this message should be at night, please upload it as soon as possible, by the way check if there is any error in its connection (bottom and body),my fans and i want to play it tomorrow in China,Approximately 8 hours behind where you are. thank you, have a nice time！

Hi,
I'm in GMT+1, so it's afternoon here :) I have added your livery, but github, where the liveries are stored is really slow (at least here) now, so it might take minutes to load. (super annoying), so please note that before getting stroke (like I did yesterday)
Best regards,
Kolos

I'm fixing these too, possibly released this week

Turned out great!

 Turned out great!

I envy you for having HD ：（


Remove redundant code

Some of the code is either dead code, redundant, or always true. Meaning they do not do anything since the cases were already dealt with in earlier parts of the code. It would be best to remove this code.
Note that some of the code removal required a tiny bit of refactoring.

ok to remove as in the ch value check or the entire else if?

OK to remove the ch value check (your change is OK)

Thank you!

Everything fixed!

All issues resolved! @michaelrsweet


Allow overriding database host when using withContainer (Docker-in-Docker)

When using the plugin with a container (jooq.withContainer), it currently doesn't allow overriding the database host used to build the JDBC URL.
Some CI setups utilizing Docker-in-Docker (DinD) require overriding the hostname and use something other than localhost due to the fact that the Docker daemon is running outside of the actual container.
In our specific case, we're using GitLab CI/CD and the CI runners are Docker containers themselves with access to the Docker daemon running on the host machines.
Overriding the database host depending on where the build is running would enable us to use the same build logic (except for the different host name) locally and on the CI runners.

Hey @joschi , when running with container, the plugin uses testcontainers' API to get the hostname of the container to connect to. Testcontainers provide a way to configure host override: https://www.testcontainers.org/features/configuration/#customizing-docker-host-detection
Altho, since testcontainers lib is shadowed by the plugin, I had to adjust the property names to avoid conflicts with a non-shadowed lib (if there is one in the classpath).
So, to sum this up: try to set DEV_MONOSOUL_JOOQ_TESTCONTAINERS_HOST_OVERRIDE env variable in you CI env to the hostname you need. I think that should do the trick for you.
Please, let me know if that works (or if it doesn't).


feature: alias make: commands

This PR introduces new aliases for all of the make:filament-* commands.
The transform from the original is simply removing the make:filament- prefix and using filament:* instead.
In terms of how it works, each command is extended and the signature is overwritten. The $hidden property is set to true as well so that the aliases don't show up in artisan list.
I placed them all in an Aliases namespace so that they're out of the way, but happy to move them out.
The command registration in the service provider is a bit messy. There might be a nicer way of doing it though, so that if an alias exists in the Filament\Commands\Aliases namespace, it's automatically registered. Although this would introduce a small overhead because each alias registration would be an additional Artisan::starting event listeners and therefore another Closure that needs to be invoked.
Let me know what you think!

Hey! Thanks for this. I think that the autodiscovery overhead would be manageable, since commands aren't booted outside of the console anyway. 👍

@danharrin Consider it done!

Awesome, LGTM!


Coordinator device won't connect to new end devices after some time (TZ-329)

I'm using an end device to send a custom String to a coordinator device. Their communication works properly most of the time. Still, I noticed that if I leave only a factory reset coordinator on for around 10 minutes, no new end devices can connect to the Zigbee network, although those that were added before the 10 minutes are still able to rejoin.
I have this simple reconnection logic on my end device that tries to reconnect to a network every 10s:
void* zb_network_check(void* arg)

{
    while(1){
        if(!has_zb_network){
            ESP_LOGE(TAG, "End Device lost connection to Coordinator");
            esp_zb_nvram_erase_at_start(true);
            esp_zb_bdb_start_top_level_commissioning(ESP_ZB_BDB_MODE_NETWORK_STEERING);
        }
        sleep(ZB_NETWORK_RECONECTION_WAIT);
    }

}

This is the log messages I get on my coordinator on the first 10 minutes:
I (385) app_start: Starting scheduler on CPU0
I (389) main_task: Started on CPU0
I (389) main_task: Calling app_main()
I (409) phy: phy_version: 101,0, 76d28a9, Mar 30 2023, 17:12:12
I (419) main_task: Returned from app_main()
I (429) COORDINATOR: ZDO signal: ZDO Config Ready (0x17), status: ESP_FAIL
I (429) COORDINATOR: Zigbee stack initialized
I (429) COORDINATOR: ZDO signal: NWK Permit Join (0x36), status: ESP_OK
I (439) COORDINATOR: Start network formation
I (439) COORDINATOR: Formed network successfully (Extended PAN ID: ff:fe:3d:6f:f7:f9:55:60, PAN ID: 0x742c, Channel:13)
I (909) COORDINATOR: ZDO signal: NWK Permit Join (0x36), status: ESP_OK
I (909) COORDINATOR: Network steering started
I (183389) COORDINATOR: ZDO signal: NWK Permit Join (0x36), status: ESP_OK

This is what it looks like after I try to connect a new end device:
I (909) COORDINATOR: ZDO signal: NWK Permit Join (0x36), status: ESP_OK
I (909) COORDINATOR: Network steering started
I (183389) COORDINATOR: ZDO signal: NWK Permit Join (0x36), status: ESP_OK
I (1011109) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1020959) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1030959) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1040949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1050949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1060949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1070949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1080969) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1090949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1100949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1110949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1120949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (1130949) COORDINATOR: ZDO signal: NLME Status Indication (0x32), status: ESP_OK

These NLME Status Indication messages happen every 10s as my end device keeps trying to reconnect.
This problem lasts even after reset, so the only way I can make the coordinator and end device interaction work again is by erasing flash in both, so they can reconnect with each other

@marcoacolla  After the coordinator forms the network, it is set to open the network by default and allows other devices to join for 180 seconds. So, when you try to join the network after 10 minutes, the coordinator's network is already closed, and you cannot join.
If you want to allow other devices to join the coordinator even after 180 seconds, you can use the following code in the coordinator to reopen the network and permit other devices to join.
 esp_zb_zdo_permit_joining_req_param_t cmd_req;
 cmd_req.dst_nwk_addr = 0x0000;
 cmd_req.permit_duration = 180;
 cmd_req.tc_significance = 1;
 esp_zb_zdo_permit_joining_req(&cmd_req, NULL, NULL);

@marcoacolla ,
Please use the provided code after the network has been formed by the coordinator.

@marcoacolla ,
I believe the following code will be helpful for your question. Please add it to the coordinator device to enable permit_join persistently. Please note that it should be added after the network has been formed.
 esp_zb_zdo_permit_joining_req_param_t cmd_req;
 cmd_req.dst_nwk_addr = 0x0000;
 cmd_req.permit_duration = 0xff;
 cmd_req.tc_significance = 1;
 esp_zb_zdo_permit_joining_req(&cmd_req, NULL, NULL);

Furthermore, if the issue has already been resolved, please consider closing it. Thank you.

Hey, I'm still having this problem I mentioned earlier.

but I keep getting these two warnings whenever I call this method. What does this message mean?
The code works fine, I'm calling it only after the network has been formed as you suggested and now I can connect new devices at any time, but I still can't figure out what this message warns me about. What is this tsn of callback?

Hello @marcoacolla

What is this tsn of callback?

The warnings occur when the ZDO (Zigbee Device Object) command does not receive a response within a specific timeframe. This could be due to a command error or the absence of the destination device.
For instance:
I (46330) ESP_ZIGBEE_API_ZDO: ZDO match descriptor request timeout! NO DEVICE FOUND!
W (46330) ESP_ZIGBEE_API_ZDO: The TSN of the callback is not found.
W (46330) ESP_ZIGBEE_API_ZDO: The TSN of the callback is not found and cannot be removed.

This log indicates a timeout in the match descriptor request. Please check your ZDO commands prefixed with esp-zb-zdo- to ensure their correctness.

This could be due to a command error or the absence of the destination device.

The code works properly, so I assume there is no command error.
My coordinator device doesn't have a specific destination device, and the only esp_zb_zdo_  command I'm using is the esp_zb_zdo_permit_joining_req command, I assume the warnings are related to it.
Here's my coordinator code:
coordinator.txt
So, could you confirm if this behavior is expected in this case, considering the absence of a destination device for the coordinator?

@marcoacolla,
Please refer to coordinator.txt

@marcoacolla ,
If the issue has already been resolved, please consider closing it.


:bug: Fixed surefire integration with jacoco

Description

Readded sureFireArgs for compatibility between jacoco and surefire
Added suppression to IDE to not show as error
added @{argLine} to support custom user arguments handed via command line

Reference
Issues #188

Build is now failing
Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.1.2:test
could not open `{argLine}'

Removed the option due to Problems with some IDEs. Should work now.


Is a Null Header Value a Set header value?

Setting a Header to null

doesn't change its count (stays at zero)
doesn't change the Response output (header is not output)

However it will cause an error if a real value is added after:
app.Run(async (context) =>
{
    var resposne = context.Response;

    // Prints zero
    Console.WriteLine(resposne.Headers["warning"].Count);

    // Does not change response
    resposne.Headers.Add("warning", new StringValues((string)null));

    // Prints zero
    Console.WriteLine(resposne.Headers["warning"].Count);

    // Throws: System.ArgumentException: An item with the same key has already been added.
    resposne.Headers.Add("warning", new StringValues("Hello"));

    await context.Response.WriteAsync("Hello World!");
});

If you can't smell it, see it, taste it, does it exist?
Should it not throw, but set the value? (as no value is set)
From https://github.com/aspnet/KestrelHttpServer/pull/2347 (which was treating it as not set for perf reasons; i.e. don't expend extra cycles tracking nothing for no effect other than to just to throw an error on a second add)
/cc @halter73 @davidfowl

Clearly the correct answer is null value is not set :wink:
As it acts in every measurable way as not set other than throwing exception on a second .Add

Setting to empty string by contrast, will return 1 for count and output a header (with no value); so throwing in that case makes sense.
The only wrinkle/corner case in the logic is
resposne.Headers.Add("warning", new StringValues(new string[3]));

Will return 3 as count and output no headers; but if you do that you are just being very strange.

Added change to remove nulls from arrays to cover the corner case.

/cc @Tratcher

It think we've decided we don't care about the array-of-nulls corner case here.


fixing previous pull request

fixing previous pull request,
sorry

No worries, I still had to try it :)

Whoops, you closed it just before the merge

i noticed something wired with backdrop clicking, sorry again :)

i was missing the pointerEvents="box-none" and modal was using double margin
should be ok now

Did you try it on both iOS and Android?

iOS only, I don't have an android at the moment

Mhhh, the pointerEvents prop might be an issue on Android 🤔

I copied it from your children wrapping View. I don't know if it behaves differently with KeyboardAvoidingView on Android.
the documentation doesn't specify anything.
You can keep this on hold until someone with android can test it


Additional operations not executed when not resized

// First make sure we need to do any work in the first place
if (targetWidth == src.getWidth())
    return src;

Causes src to be returned without executing the additional "ops" if specified.
This behavior does not occur when FIT_EXACT, is specified (since no width/height checking is done there). This means different behaviour (whether or not additional ops are executed or not) changes, when you switch the FIT mode.
I think the additional ops should always be executed.

+1


ESLint lint while typing not working in vue-cli 3.x / VSCode

Version
3.0.0-rc.3
Reproduction link
https://github.com/nickforddesign/vue-cli-3
Steps to reproduce
Set up new project with linting   airbnb or standard config, choose lint on save? Then open project in VSCode and remove semicolons or something that linter will complain about.
What is expected?
Should see the linting errors in editor, and ideally in the browser overlay as with vue-cli 2.x, though that's a separate issue.
What is actually happening?
Only see linting errors and warnings in the Terminal window.

I have eslint for vscode installed. I know it's possible that this is a problem with that plugin and not vue-cli, but I am opening it because it works just fine with 2.x, but not 3.x

@nickforddesign In regards to the part about the linting not showing in VSCode, I needed to add this to my workspace settings and remove all of my VScode linting extensions except for ESLint:
{  "eslint.validate": [     {       "language": "vue",       "autoFix": true     },     {       "language": "html",       "autoFix": true     },     {       "language": "javascript",       "autoFix": true     },    {       "language": "typescript",       "autoFix": true     }   ] }
Drove me mad for awhile trying to figure out how to get the linting errors to show in VSCode.


Email headers with html?

Am I able to set email headers? Trying to make an email template through QC that is sent daily as an update. Unless an html header is set, I can't use tables to display data...
headers = array('Content-Type: text/html; charset=UTF-8')
algorithm.Notify.Email(email, subject, message)

Is the only way to achieve my goal is to use the webhook to send data to my website and then use php to send however I want?

LONGS INFO
Current Longs: ['UNFI', 'TGI', 'RRC', 'SPCE', 'DRNA', 'DRD', 'TNDM', 'AU', 'FLIR', 'PAAS', 'SCWX', 'RGEN', 'GSX', 'RGLD', 'MDB', 'KGC', 'IRWD', 'VLY']
Flattening Longs: ['AU_01180388334', 'KGC_78083601151', 'GSX_78136670705', 'MDB_24207661826', 'UNFI_22211010626']
New Longs: []
SHORTS INFO/
Current Shorts: ['RJF', 'ALXN', 'MIK', 'PE', 'MMSI', 'REFR', 'MUR', 'FELE', 'AEY', 'BZUN']
Flattening Shorts: ['REFR_48552800810', 'MMSI_53702678828', 'ALXN_54405584048', 'REFR_48555264868', 'RJF_28367237766']
New Shorts: []

Related to https://github.com/QuantConnect/Lean/issues/4270


'Report an Issue' not working

Save us time! Click 'Report an Issue' from the Help and Support panel inside of VS Code after you have connected to a system.
I tried this and it flashes "Gathering issue details..." and then nothing.   I'm pretty sure I did this in the last couple of weeks and it opened up Firefox and copied in all the useful info you need into a new issue.  I'm on 1.9.4 running on Windows 10. connected to PUB400.COM.
I've exited VSCode and reconnected and the problem still exists.
Describe the bug
(A clear and concise description of what the bug is. We will not accept your bug and close it if this is not filled out correctly.)
Los problemas en espanol estan bien.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

Extension version [e.g. 0.x.x]
IBM i OS version [e.g. 7.x]

Additional context
Add any other context about the problem here.

Good catch!
Turns out some of the information we get from the system are not accessible to everybody (OS version and TR level).
This PR will fix this: https://github.com/halcyon-tech/vscode-ibmi/pull/1365


To fix the 'repo_states.json' file generating

this commit removes the error of the 'commit_id' field in the exported
'repo_states.json' file

Dima, please review too


Python : Arithmetic Operators

Write your solution to this Python problem of hackerrank:-
Problem link : Arithmetic Operators

@Riddhi9570 Could you please assign me this issue as part of Hacktoberfest 2022

@Riddhi9570 Can you please assign this issue to me with the hacktoberfest tag

@Riddhi9570  I have already done this problem can you please assign this issue to me 🙏with hacktoberfest tag?


Added LISP-RAW special form.

Allows the insertion of raw strings into output javascript expressions. Useful for generating javascript with 3rd party tools, as in this example

This function was present in Parenscript a long time ago and removed, because it is a really bad idea - adding raw output can break the generated code in arbitrary and hard to debug ways. What this functionality is really used for is packaging arbitrary JavaScript code from multiple sources, and is something that is much better handled by build tools. So that is another reason to leave this feature out - Parenscript deliberately tries to be build process agnostic.


ic-navigation-item does not focus slotted content when using .setFocus method

Summary of the bug
ic-navigation-item has a .setFocus() method, used for programatically setting focus to the element inside the shadowDOM by the user. However, this relies on a value called itemEl, which is only set if an element is not slotted into the nav item, such as a React Router NavLink or Gatsby Link.
🪜 How to reproduce

Create a component in a test app that uses an ic-navigation-item.
Slot in a custom link element
Run .setFocus on the nav item
Nothing will be focused

🧐 Expected behaviour
If a slotted element is used, it should focus that when running .setFocus
📝 Acceptance Criteria
Given that a slotted element is used in an ic-navigation-item
When I run .setFocus on the navigation item element
Then the slotted link should be focused

may be able to call focus on the firstElementChild


Extra "lib" folder on npm install

This just started happening on our build server and I was able to reproduce it locally with<EMAIL_ADDRESS>There seems to be an extra "lib" folder in the node_modules folder now, so for example the bin is located at lib/bin/bower instead of bin/bower -- unsure if this is a bug or not, but lib/lib seems odd.

It's on purpose. Is it an issue for you?

This breaks https://github.com/eirslett/frontend-maven-plugin

It was an issue, but I've switched from using hardcoded bin path to using node_module/.bin/bower which fixes the problem for me. Just be aware that changing the bin path is not backwards compatible so it may break things for other people as well.

Also breaks https://www.npmjs.com/package/grunt-bower-install-simple

Yes It break zeppelin as well.
We are using maven frontend plugin and it is expecting bower binary at "node_modules/bin/bower."
Please see this: https://issues.apache.org/jira/browse/ZEPPELIN-634
We have moved to bower:1.7.2 to fix zeppelin issue.

I'll create an alias for binary where it was..

Thanks a lot @sheerun, it would definitely solve our purpose.

Having a deprecation warning in a wrapper file for transition and not changing this in a point release in the future would be appreciated.

how could it be that a bugfix upgrade breaks so much stuff? This could be a hint that we should not use bower anymore...

It's breaking for you because you're using bower binaries directly, instead using npm aliases. If you used binaries from npm bin --global or npm bin the path wouldn't change.
I understand this change affects people using bower this way, so I will create an alias anyway.

@sheerun Yes, but nobody told us or others.
For example the people at Atlassian are using exactly this path as Default on integrating Bower as task into their Bamboo CI. So all Bamboo CI Plans using Bower are failing right now. Further more I'd never have understand what it is supposed to be.
General rule thumb of rule: If you have ever exposed anything in your libraries it will eventually get used and it will eventually be really hard to change.  Careless how it is supposed to be right.
I think the best solution would be:

write a wrapper which spills out 3 annoying warning message that everbody should use the new location
remove that wrapper in the next major release.

@bentolor :+1:

We're really careful to not introduce any backward-incompatibilities and the process is exactly like you describe for features that are documented to be public. For these that aren't, we release patches as soon as possible.
Besides, we can't notify you not use bower binaries directly, because there's no way to detect it.
I've released bower 1.7.6 that should fix your issue.

Thank you @sheerun for the fast fix!

Thanks!

...but still failing, because "bower/lib/renderers/StandardRenderer" is missing.

@derTobsch basically this: https://github.com/bower/bower/issues/2160. It also explains why the lib in the first place..

Great... I can't assume people are not depending on any random file in bower. I'll try to figure out how to preserve all the paths while still embedding node_modules.. @derTobsch What package is failing for you?

@sheerun https://www.npmjs.com/package/grunt-bower-install-simple, this dies depend on "bower/lib/renderers/StandardRenderer" i added a pull request for that module and informed the developers. Let's see what they will do. I forked that package and will use my branch with the fix until they fix it.

@derTobsch I've released bower 1.7.7 with almost all paths back at their places.

@sheerun that fixed our problems. thanks


Collection of enum leads to enum renaming to "Anonymous"

Creating an array (or list, etc) of an enum property on a class model leads to the enum being renamed to "Anonymous."
Additionally, if you have the same enum as an array in other places it creates a new "Anonymous" version of that enum even if the two arrays are in the same class.  The latter is already being addressed in NJsonSchema/NJsonSchema#17.

Can you provide a sample to reproduce this?

public enum SomeEnum { Thing1, Thing2 }

public class SomeClass
{
    public int SomeProperty { get; set; }
    public SomeEnum[] SomeEnums { get; set; }
}

I cannot reproduce the problem with NJsonSchema only: https://github.com/RSuter/NJsonSchema/commit/f5b2c0effe85f77fc65575835d46dbecc8eaa90f
Can you reproduce this with an NJsonSchema unit test?

Unfortunately, I am pressed for time with a difficult work schedule and don't have the time to set up a project for unit testing.  If the unit test that you wrote doesn't fail because it doesn't produce the results I am getting then it must have done something wrong in the way I am generating my client.  I did notice something in the meantime, however.  I am generating a Swagger document as my first step using SwaggerDocument.FromUrlAsync(...) which, when examined for the portion that would contain my enum array, is rendered as "someEnums":{"type":"array","items":{"enum":{"Thing1","Thing2"],"type":"string"}} which explains why is coming up as anonymous enum.

Enums only have a name when they are referenced... I thought you generated the spec with nswag.

Can you provide a sample spec?

I am using NSwag to generate the spec.  The SwaggerDocument object that I am using to generate it is in the NSwag namespace:
var doc = await SwaggerDocument.FromUrlAsync(urlString);

var settings = new SwaggerToCSharpClientGeneratorSettings()
{
	GenerateClientClasses = true,
	GenerateDtoTypes = true,
	ClassName = "ConfigurationClient",
	OperationNameGenerator = new MultipleClientsFromOperationIdOperationNameGenerator()
};

var generator = new SwaggerToCSharpClientGenerator(doc, settings);
var code = generator.GenerateFile();

return code;

I hope this is enough of the spec:
{
   "swagger":"2.0",
   "info":{
	  "version":"v1",
	  "title":"My Something or Other App v1"
   },
   "basePath":"/",
   "paths":{  },
   "definitions":{
	  ...
	  "SomeClass":{
		 "type":"object",
		 "properties":{
			"someEnums":{
			   "type":"array",
			   "items":{
				  "enum":[
					 "Thing1",
					 "Thing2"
				  ],
				  "type":"string"
			   }
			}
		 }
	  },
	  ...
   },
   "securityDefinitions":{}
}

No, you are not generating a swagger spec with NSwag but only loading an existing spec from an URL... this is why the enums are not referenced and thus are named "Anonymous*"...
But you can provide a custom TypeNameGenerator (settings.CSharpGeneratorSettings.TypeNameGenerator) and return a custom class name for the enum schema (just inherit from the default implementation and return a different name for the enum schema).

Ok, I see now.  Sorry for the confusion.  I will try out what you have suggested.  Thank you for your help.


XOR operation of two circles are not correct

The operation XOR between to circles does not give the correct result:
from compmec.shape import Primitive

circle_left = Primitive.circle(radius = 50, center = (-15, 0))
circle_right = Primitive.circle(radius = 50, center = (15, 0))
circle_xor = circle_left ^ circle_right

Although using this operation we get the correct shape
circle_or = circle_left | circle_right
circle_and = circle_left & circle_right
circle_xor = circle_or - circle_and

The current implementation of __xor__ is theorically correct:
def __xor__(self, other):
    return (self - other) | (other - self)

Using regular_polygon gives the correct result:
from compmec.shape import Primitive

circle_left = Primitive.regular_polygon(35, radius = 50, center = (-15, 0))
circle_right = Primitive.regular_polygon(35, radius = 50, center = (15, 0))
circle_xor = circle_left ^ circle_right

Probably it's a problem from the intersection between two bezier curves of degree 2.


SVGs Not Showing On Snapshots

Our SVGs are located in the assets directory.
The SVGs load correctly when serving in all environments including the test environment.
Apparently the SVGs have never loaded in Percy snapshots.
We use ember exam and testem to run the tests.

What I've tried so far:

I've tried upping to the latest version of @percy/ember.
I've tried renaming the svg file name to check is it was a caching problem.
I've tried using the ember test helper waitFor.

Please let me know what else I should try or if you need anymore information.

Hey @beanshearer thanks for the issue! Would you be able to link to a build where this is happening? I'd like to download a snapshot to take a look (and figure out if it's an SDK issue or something larger)
You could also send the link to<EMAIL_ADDRESS>if you won't want to link it publicly 👍

Thanks for the quick response. I'll send a link to<EMAIL_ADDRESS>now.

Any updates on this we have the same issue?

This is usually SDK setup / support kind of issue -- you can either reach out to support @ percy.io or open a Q&A discussion with verbose logs/as many details as you can provide to help us debug.
If it turns out to be an SDK bug we'll deff create an issue from it and get a fix working ASAP 😃


markdown-it-for-inline throws cannot read property 'referenes' of undefined on malformed link.

Here is an example:
var iterator = require('markdown-it-for-inline');
md.use(iterator, 'test', 'link_open', function(tokens, idx) {
    console.log(tokens[idx]);
});

md.parse(markdown_text);

Tried to parse this:
**Hello** This is a test!

[alink]http://example.com)

Notice the link is missing a beginning (.
This results in:
TypeError: Cannot read property 'references' of undefined

md.parse(src, env) is an internal method, which requires you to supply an environment as a second argument. That is a bit different from a md.render() function.
So please use md.parse(markdown_text, {}) instead if you want to get a token list.


GEP-2627 DNS Policy

/kind gep
What this PR does / why we need it:
Adds a draft GEP outlining more on the what and why for supporting DNS configuration as part of Gateway API
Fixes #2627

This needs a very serious security review. As a DNS admin - either public or private - I expect very strict controls on who can create DNS entries affecting the entire domain or VPC.  It is certainly not something to enable in all clusters or namespaces - or trust that users have the security expertise to use this safely.
I think external-dns (alpha) CRD is the right approach for users who want to use KRM to manage DNS - the other options allowing random namespace owners to create arbitrary DNS (A and TXT) entries are a huge security risk.
I would be very strongly against this feature - DNS management is a very different thing from Gateway management, the user controlling DNS decides if a specific name (including ability to get ACME certs, etc) can be delegated to a particular Gateway in a particular cluster or not - which in turn allows specific routes (like .well-known/ for getting certs) to be sent to specific namespaces.
The argument that 'user just want an easy way to shoot themselves in  the foot and break their own security - because they know what they're doing' is not valid for this particular case, since the implications are far broader than a single cluster.

I should mention Istio - and any mesh based on interception, or L4-based security mechanisms - is completely dependent on DNS security - both the DNS resolver ( bob.com resolving to evil.com IP ) but also control over creation of entries in private or public DNS.
At the very least this option should  not be allowed if any GAMMA implementation is used in the same VPC ( not only cluster).

@costinm Thanks for your response.
This needs a very serious security review. As a DNS admin - either public or private - I expect very strict controls on who can create DNS entries affecting the entire domain or VPC. It is certainly not something to enable in all clusters or namespaces - or trust that users have the security expertise to use this safely.

I think external-dns (alpha) CRD is the right approach for users who want to use KRM to manage DNS - the other options allowing random namespace owners to create arbitrary DNS (A and TXT) entries are a huge security risk.

Not sure if it is clear, but the proposal and discussion was focused around a new API  and as such would be controlled by regular RBAC controls just as creating a Gateway would be or creating an external dns resource would be. So there should be no issue controlling who is allowed to create such an object and in turn control the DNS for a given Gateway's listeners.

Btw - the CRD defined by external-dns project seems like a good start and has support for most DNS servers. Any reason users can't just use that ?

@costinm, this is an initial GEP that lays down the scope and terms to start the discussion of if, and if so, how, we can represent that Gateways should have external DNS configured in a standard, portable way. I agree that there are significant security considerations, and that those security considerations should be included in the GEP.
If you have specific feedback about extra use cases or other concerns that you would like addressed, the correct way to indicate them is via comments on the file, rather than broad generalizations discouraging further work on this.
Once this PR merges and we have a basis for discussion, I'd love for you to shepherd some more changes to it to ensure that your concerns are captured.

Also not aware that discussion can happen only after this PR merge - do you
have a doc listing those rules and processes ?
On Thu, May 23, 2024, 11:14 Costin Manolache @.***> wrote:

Nick - I don't have additional use cases, my comments are related to the
scope of this WG ( DNS overlaps with core K8S) - I don't want to discourage
work, quite the opposite - just to make sure it's in the right place.
Gateways obviously need DNS config and integration with DNS - just like
many other things like LB Services.
I was not aware comments on the file are the only supported form of
feedback, will do that in the future.
On Wed, May 22, 2024, 19:48 Nick Young @.***> wrote:

@costinm https://github.com/costinm, this is an initial GEP that
lays down the scope and terms to start the discussion of if, and if
so, how, we can represent that Gateways should have external DNS configured
in a standard, portable way. I agree that there are significant security
considerations, and that those security considerations should be included
in the GEP.
If you have specific feedback about extra use cases or other concerns
that you would like addressed, the correct way to indicate them is via
comments on the file, rather than broad generalizations discouraging
further work on this.
Once this PR merges and we have a basis for discussion, I'd love for you
to shepherd some more changes to it to ensure that your concerns are
captured.
—
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/gateway-api/pull/2712#issuecomment-2126090023,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2SRZCH6RWEX7NRPXALZDVKHFAVCNFSM6AAAAABBW3CZYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGA4TAMBSGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

This work is to provide a standardized way to request DNS records are created for Gateway instances - as you said earlier, basically the same as what external-dns does today. The idea is to see if we can find some common ground and provide a relatively standardized way to communicate this config, that can cover common use cases across multiple providers or implementations.
Some implementations (external-dns for one) are already looking at the Gateway object to provision DNS config, the intent here is to ensure that relevant information has a structured, extensible, portable format that it can be stored in.
The process for GEPs is documented at https://gateway-api.sigs.k8s.io/geps/overview/, and as this is the first stage (moving from discussion into Provisional), the bar is intended to be pretty low. It's intended that we use this chance to agree:

that the problem is one we should consider
what terms we will use to describe the problem
what use cases we are considering

There can be multiple PRs while a GEP is in Provisional, but the intent is to provide a place that is more durable than Github comments to raise concerns, answer questions, and so on.
The best type of feedback here is feedback on the specific file, yes, but I think that questions about if the problem is in scope for Gateway API should be addressed here, so that we can all be on the same page.
I believe the problem of ensuring that there is a reliable way for Gateway owners to request provisioning of DNS records to cover access to the "outside" of the Gateway is in scope for Gateway API. If we agree on that, then the discussion becomes about:

what config is needed for the given use cases
where that config should live

It could be that minimal extra configuration is needed, but from the fact that external-dns and other projects already have Policy objects to cover this, it seems likely that we will need additional structured configuration of some kind. Additionally, if there are at least three implementations of the same feature, then that is the level at which we will consider doing something not provider-specific, to leave room for other implementations to do the same task in a compatible, portable way.

As I mentioned in my previous comment - I believe this is out of scope for
the Gateway WG - and
perfectly in scope for the 'external DNS WG' - which is focused on
representing multiple
K8S resources in DNS - as well as the 'Core API WG', which define the core
DNS.
It looks like the 'external DNS' WG also believes (implicitly) it is in
their scope - given that they
already implemented support for representing gateway resources among many
others.
The Gateway WG does have a larger security problem around ownership for
hostnames -
it does solve some of the 'confused deputy' issues and has some basic
delegation/grant model,
however the 'persona' who owns the DNS zone and domain ( and indirectly all
associated security - ability
to get certs for subdomains, etc) is different from the persona configuring
a Gateway in a namespace.
DNS may span multiple clusters and non-k8s environments - and operates on a
top-down
model, and needs a consistent security and delegation model across all
record types and uses.
How to configure DNS (securely) is clearly a very important problem - but
best handled in a WG focused
on DNS, not in 'leaf' APIs that interact with a single record and small
subset - and without a
security/IAM model matching DNS needs.
The proposal doesn't mention any 'prior art' or existing LB implementation
that programs DNS -
Istio does handle DNS interception but only for egress use cases. The
permissions needed for
an in-cluster load balancer to program a customer DNS zone - and the
complexity on integrating
with the many DNS APIs ( see the list of plugins in external DNS and ACME
programs ) makes it
unlikely that even 2-3 gateway implementations will be able to do that -
while external-dns has
a working implementation that can be used with any gateway ( and vendors
can provide
specialized ones as well - most of the code is related to the 100 DNS APIs).
In general: any GEP that is not based on existing art and features that a
significant number
of gateways supports ( I would go for 'majority'...) will lead to
fragmentation and user pain with
the proliferation of optional features - as well as poor APIs that are not
based on well established
and broadly implemented designs (and I would say in Istio we have a bit of
experience with that...)
On Thu, May 23, 2024 at 10:57 PM Nick Young @.***>
wrote:

This work is to provide a standardized way to request DNS records are
created for Gateway instances - as you said earlier, basically the same as
what external-dns does today. The idea is to see if we can find some common
ground and provide a relatively standardized way to communicate this
config, that can cover common use cases across multiple providers or
implementations.
Some implementations (external-dns for one) are already looking at the
Gateway object to provision DNS config, the intent here is to ensure that
relevant information has a structured, extensible, portable format that it
can be stored in.
The process for GEPs is documented at
https://gateway-api.sigs.k8s.io/geps/overview/, and as this is the first
stage (moving from discussion into Provisional), the bar is intended to be
pretty low. It's intended that we use this chance to agree:

that the problem is one we should consider
what terms we will use to describe the problem
what use cases we are considering

There can be multiple PRs while a GEP is in Provisional, but the intent is
to provide a place that is more durable than Github comments to raise
concerns, answer questions, and so on.
The best type of feedback here is feedback on the specific file, yes, but
I think that questions about if the problem is in scope for Gateway API
should be addressed here, so that we can all be on the same page.
I believe the problem of ensuring that there is a reliable way for Gateway
owners to request provisioning of DNS records to cover access to the
"outside" of the Gateway is in scope for Gateway API. If we agree on that,
then the discussion becomes about:

what config is needed for the given use cases
where that config should live

It could be that minimal extra configuration is needed, but from the fact
that external-dns and other projects already have Policy objects to cover
this, it seems likely that we will need additional structured configuration
of some kind. Additionally, if there are at least three implementations of
the same feature, then that is the level at which we will consider doing
something not provider-specific, to leave room for other implementations to
do the same task in a compatible, portable way.
—
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/gateway-api/pull/2712#issuecomment-2128598774,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2UDTY36ST345EUCNX3ZD3JC3AVCNFSM6AAAAABBW3CZYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRYGU4TQNZXGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@costinm, my responses below.

As I mentioned in my previous comment - I believe this is out of scope for the Gateway WG - and perfectly in scope for the 'external DNS WG' - which is focused on representing multiple K8S resources in DNS - as well as the 'Core API WG', which define the core DNS. It looks like the 'external DNS' WG also believes (implicitly) it is in their scope - given that they already implemented support for representing gateway resources among many others.

I disagree. People using this API need to have an answer for how they ask some DNS management system to consider their Gateway in scope for management. Right now, in external-dns, the support only looks at Route resources, which misses the whole model we have for having hostnames match between Gateway and Route. I can see you logged kubernetes-sigs/external-dns#4402 to request adding support for Gateways to the API, which I agree should definitely be supported.
The reason here is that we (Gateway API) have not documented anywhere how consumers of the DNS information already present in the API should use that information. We don't have anything that says "Implementations wanting to do automatic configuration must consider both Gateway and Routes in generating information". It's implied by the spec (since you can't get an address without looking at the Gateway), but we haven't actually said that anywhere.
@maleck13 and the other folks who are working on Kuadrant have also already built a solution for managing the same config, in a different way to the external-dns team. So, some discussion here is required, even if the outcome is that we end up picking one of those implementations as the canonical one. (I think that's unlikely.)
Nobody is suggesting that Gateway API own end-to-end DNS provisioning here. But, as a traffic routing specification, we interact with DNS, and unless we define how that happens, and explicitly rule things out of scope, then we will end up owning it by default. I don't want that, and it seems that you don't either. But that requries us defining what is in scope.

The Gateway WG does have a larger security problem around ownership for hostnames - it does solve some of the 'confused deputy' issues and has some basic delegation/grant model, however the 'persona' who owns the DNS zone and domain ( and indirectly all associated security - ability to get certs for subdomains, etc) is different from the persona configuring a Gateway in a namespace.

Yes, and this is one of the many reasons why we haven't addressed this at all up until now.
Again, this provisional GEP is not suggesting that we solve this problem. In fact, I believe that this should be the responsibility of the implementation that is actuating the creation of DNS records. If a Gateway is created somewhere, and that person shouldn't be creating hostnames there, that's up to the thing that handles DNS creation, not the Gateway API implementation.
Again, this GEP is about defining how other controllers that maybe don't implement routing configuration can manage DNS config sourced from Gateway API resources. Doing this does not mean that north-south Gateway implementations need to support it. Sure, they can if they want to, but the idea here is to ensure that everyone doing it (which, again, multiple implementations already are) does it in the same way.

DNS may span multiple clusters and non-k8s environments - and operates on a top-down model, and needs a consistent security and delegation model across all record types and uses. How to configure DNS (securely) is clearly a very important problem - but best handled in a WG focused on DNS, not in 'leaf' APIs that interact with a single record and small subset - and without a security/IAM model matching DNS needs.

This is not yet a proposal, to be clear. It's an attempt to start talking about what a proposal will involve. The fact that certain questions have been asked and others haven't is exactly what this process is supposed to achieve.
Also, part of the job of a Gateway is to map addresses to routing config. Part of the routing config is the hostname, so it's reasonable natural to assume that people may want to mark hostnames on a Gateway as "please configure these automatically".
I agree that it shouldn't be the job of Gateway API to decide how the requests to map an address to a hostname should be actuated. But it's entirely within our scope to define something that says "use these mappings and not these ones." You're asking us to boil the ocean of solving all DNS management problems, of course that's out of scope. But marking particular mappings is well inside the scope of Gateway API.

The proposal doesn't mention any 'prior art' or existing LB implementation that programs DNS - Istio does handle DNS interception but only for egress use cases. The permissions needed for an in-cluster load balancer to program a customer DNS zone - and the complexity on integrating with the many DNS APIs ( see the list of plugins in external DNS and ACME programs ) makes it unlikely that even 2-3 gateway implementations will be able to do that - while external-dns has a working implementation that can be used with any gateway ( and vendors can provide specialized ones as well - most of the code is related to the 100 DNS APIs).

Yes, because it is at the stage of gathering questions, not proposing solutions.

In general: any GEP that is not based on existing art and features that a significant number of gateways supports ( I would go for 'majority'...) will lead to fragmentation and user pain with the proliferation of optional features - as well as poor APIs that are not based on well established and broadly implemented designs (and I would say in Istio we have a bit of experience with that...)

I don't understand what saying this is intended to achieve. Yes, the point of the GEP process is to ensure that the features we include can be well supported by multiple implementations. Specifications that we define don't have to be implemented by every implementation, and I think External DNS is a great example of functionality that will probably be mostly implemented by a different set of controllers than the ones that provide core routing functions.
These functions may be optional in the spec, but if we don't define them, each implementation will define their own, probably using annotations, and we will be back where we were with Ingress all over again.
I'm about to go and add some suggested changes to capture some of what we've been discussing here. If you wish to discuss this further, I think that we should move it to the community meeting or a separate dedicated meeting to get some higher-bandwidth communication.

Right now, in external-dns, the support only looks at Route resources, which misses the whole model we have for having hostnames match between Gateway and Route. I can see you logged kubernetes-sigs/external-dns#4402 to request adding support for Gateways to the API, which I agree should definitely be supported.

Hey... I'm just now seeing this issue/PR for the first time.
I implemented Gateway API support in external-dns and this claim isn't true. It has always respected Listener AllowedRoutes and Hostnames. I'd be happy to hear about and fix any cases where this isn't working properly.

To better support DNS use cases, I'd be happy to see a change in Gateway API to allow hostnames in Routes and Listeners that don't need hostnames (i.e. move Hostnames to CommonRouteSpec). It would be mostly backwards compatible because the empty hostname matches everything. The only wrinkle is that the Hostname field in the Listener is documented as "ignored for protocols that don't require hostname based matching." It wouldn't be backwards compatible from a Go package API standpoint, but I don't think that's been a problem before :)
HTTPRoutes, TLSRoutes, and GRPCRoutes and their associated Gateway Listeners can mutually specify hostnames which lets Cluster Operators and Application Developers collaborate to control which hostnames are used. I understand that hostnames would be unavailable in the actual routing path for TCPRoutes and UDPRoutes. However, it could be used in Listener attachment and/or DNS management (the part I care about).
External-DNS does all the things you would hope it would do to determine the correct hostnames for HTTP, TLS, and GRPC Routes. For TCP and UDP Routes it reuses the existing external-dns.alpha.kubernetes.io/hostname annotation on the Routes without any control or validation from the Gateway. The caveat that makes this somewhat more tenable is that external-dns provides a lot of ways to filter (e.g. explicit lists or regular expressions) which domains are allowed and/or blocked.
As far as which WG owns or has claimed this as in their scope... I'm not on any WGs. I'm just some guy who wanted DNS automation for Gateway API to exist, so I implemented it in external-dns three years ago, and I've tried to keep it up to date since then. There was an issue to add support for it, which I think was created by a member of GWAPI. I wrote the code then presented my design with a detailed doc at a GWAPI meeting, which went very smoothly.  For my efforts I've mostly just gotten complaints from strangers on the internet who think external-dns is messed up, when really their GWs and Routes are misconfigured because they don't understand GWAPI concepts like the security model and cross-namespace route binding.

To better support DNS use cases, I'd be happy to see a change in Gateway API to allow hostnames in Routes and Listeners that don't need hostnames (i.e. move Hostnames to CommonRouteSpec)

@abursavich Listener Hostname is already optional:
https://github.com/kubernetes-sigs/gateway-api/blob/4cd0ab41932e776a77b1b40decae1a07998c2620/apis/v1/gateway_types.go#L270-L271
We do have a requirement that the combination of hostname, protocol, and port is unique among Listeners, is that what you'd like to remove?

We do have a requirement that the combination of hostname, protocol, and port is unique among Listeners, is that what you'd like to remove?

@robscott,  my suggestion is to add hostnames to Routes that don't directly use them: TCPRoute and UDPRoute. I can understand why you might not want to do that. It can't be enforced in the data path and would probably confuse some people, but it would be helpful for DNS.

One thing that we probably should make more clear is that, for TCPRoute and UDPRoute, you can't have more than one of the type attached to any specific Listener. So adding a hostname to the Routes probably wouldn't do much - for both of those Kinds you need to look at the Listener hostname anyway.

/remove-lifecycle rotten


Added typescript definitions

Typescript definitions for those wanting to use the Typescript with react native

@Jpoliachik No probs man! I'll send a PR soon for flow typings

@Jpoliachik Just reminding you to push version to npm. New install from npm doesn't include types

@iRoachie thanks for the reminder, just published 0.0.7 to npm


inclusive language: deprecate "slaves" from the API

Bond.SLAVES is now deprecated by Bond.PORT

OVSBridge.Port.LinkAggregation.SLAVES_SUBTREE is now deprecated by
OVSBridge.Port.LinkAggregation.PORT_SUBTREE

OVSBridge.Port.LinkAggregation.Slave.NAME is now deprecated by
OVSBridge.Port.LinkAggregation.Port.NAME

Team.PORT_SUBTREE is now "port" instead of "ports"

Signed-off-by: Fernando Fernandez Mancera<EMAIL_ADDRESS>

Only did partial reviews. Have to manually test whether old API still works.

Only did partial reviews. Have to manually test whether old API still works.

Will test it manually too. I think it should work as the deprecation test is passing.

I've tested this manually, here is the output:
Python 3.6.8 (default, Apr 16 2020, 01:36:27)
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from libnmstate.schema import Bond
>>> from libnmstate.schema import OVSBridge
>>> Bond.SLAVES
sys:1: FutureWarning: Using 'Bond.SLAVES' is deprecated, use 'Bond.PORT' instead.
'port'
>>> OVSBridge.Port.LinkAggregation.SLAVES_SUBTREE
sys:1: FutureWarning: Using 'LinkAggregation.SLAVES_SUBTREE' is deprecated, use 'OVSBridge.Port.LinkAggregation.PORT_SUBTREE' instead.
'port'
>>> OVSBridge.Port.LinkAggregation.Slave.NAME
sys:1: FutureWarning: Using 'LinkAggregation.Slave' is deprecated, use 'OVSBridge.Port.LinkAggregation.Port' instead.
'name'

When yml file still using old slave term, the apply will fail, this is not acceptable.
We should still support old term of slave regardless user use it as constant or hard-coded string.

I've fixed this. Thanks!

The schemas/operational-state.yaml is not updated.
And it should allows both old and new terms.

Done, thank you!


Is there a way to use searchAfter keyword?

I don't mind write some customized code. Please point out a way to use searchAfter keyword.
It is extremely usefully when walking through lots of data.
Or, I can work on this feature with your help.
ES Doc: https://www.elastic.co/guide/en/elasticsearch/reference/5.5/search-request-search-after.html
GET twitter/tweet/_search
{
    "size": 10,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "search_after": [1463538857, "tweet#654323"],
    "sort": [
        {"date": "asc"},
        {"_uid": "desc"}
    ]
}

NVM. I figured it out.
queryBuilder.searchAfter([123, "456"]);


Added =>Maths_And_Stats => Calculus => Riemann_Sum => C#

Assigned Issue Number ?
#392
Language Opted ?
C#
Number of files added or updated ?
1
Name of these files ?
Added =>Maths_And_Stats => Calculus => Riemann_Sum => Riemann_Sum.cs
Checklist

[x] I've read the contribution guidelines.
[x] I've referred the correct issue number.
[x] I've fill up this entire template correctly.

Here is a screenshot of the code working. It can be verified by taking the definite integral of y=x^2 from 3 to 6. The program will give values closer and closer to 63, as the resolution gets higher and higher. I also wanted to add that this program was super fun to make. Implementing some of my favourite math fundamentals in code is something I'd like to explore more. Thanks!


Add a Select component for URL submission egress

Related to: https://github.com/CybercentreCanada/assemblyline/issues/58

This PR was not merged into DEV and should be tested there before making it ready.


Allow users to edit nicknames

Users should be able to set their own usernames.

An input field next to or under the current username display.
A button to submit. (button and field should disappear on click, but users should still be able to change again).
Change nickname, send new nickname to host.

A message could be sent that would update all new user's of the nickname, but I don't think that's necessary, since the change will then be visible on all future messages.

Completed


Create action translator for Textfile builder to ninja

The Textfile builder could have an automatic translator to prevent needing to callback to scons, similar to the MkDir or Copy Builder: https://github.com/SCons/scons/blob/f70935229414532f55ee172148ded902ec25e558/SCons/Tool/ninja/Rules.py#L37-L52
This was requested by a user in the scon's user mailing list thread: https://pairlist4.pair.net/pipermail/scons-users/2022-May/008985.html

@dmoody256 Are there any plans to change this issue in the near future?


Make the repo py27 and py3 compatible

Summary of Changes
Include a summary of changes then remove this line
Tests
What tests did you add or modify and why? If no tests were added or modified, explain why. Remove this line
Documentation
What documentation did you add or modify and why? Add any relevant links then remove this line
CheckList
Make sure you have checked all steps below to ensure a timely review.

[ ] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[ ] PR includes a summary of changes.
[ ] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

[ ] PR passes make test

@jinhyukchang , the repo has python3 / python2 unit test enable (https://github.com/lyft/amundsendatabuilder/blob/master/Makefile#L19) .
And I think it just allows python runtime to be either in python27 or python36 or above.


Adds CupertinoTheme

Fixes #18037

Add CupertinoTheme using InheritedModel
Remove material from cupertino gallery demos and use cupertino scaffolds
Collect fonts and styles from various Cupertino widgets to the theme
Refer to the them from various Cupertino widgets
Move CupertinoThemeData to a model where derivation of dependent properties are done at read time rather than construction time
Let the CupertinoThemeData's copyWith etc allow unspecified downstream properties be re-derived when upstream overrides change
Add a new constructor to CupertinoButton to use the color of the theme instead of any particular color or null which means no color
Add a dark mode to most Cupertino widgets
Let Cupertino widgets demos in the gallery also respect the top level Material dark mode toggle
There are no AnimatedCupertinoTheme or lerping because iOS is very non-visual-mutating-animation styled
Create a MaterialBasedCupertinoThemeData that derives upwards from Material ThemeData rather than iOS defaults when upstream is unspecified
MaterialBasedCupertinoThemeData is also based on InheritedModels where dependency is only created on individual properties read
Material Theme also creates a CupertinoTheme and all Cupertino widgets only have dependencies on CupertinoTheme
MaterialBasedCupertinoThemeData can also be copiedWith (and reused in a CupertinoTheme) and only specified properties rather than Material or iOS based derivations
Let InheritedModel.inheritFrom not crash when no InheritedModels exist in the ancestry tree
There's a single input API (CupertinoThemeData constructor) and a single output API regardless of if it's constructed and read right away (in which case no dependencies get created) or read via inheritance from CupertinoTheme or Material Theme. This is probably the most debatable point.

cc @HansMuller this is what I have in mind so far. The InheritedModel stuff and the deferring to Material Theme parts still need work.

@HansMuller sorry, this thing is a bit long but it's ready for a look. Should be based on the same ideas as your PR.
I think we're going to want something different than the _CupertinoThemeInheritedData thing but the rest should be mostly unaffected.

  I can probably do a better review on something of this size if you can help guide me through what you did and what you were thinking.

Sure, if you're in tomorrow, let's walk through it together.


Modify Banner to have English and Spanish links

Tasks

look into modify the Banner component
understand how to switch
integrate fully flushed out es.json
is there such a thing as snapshot testing in Spanish?
investigate ordinal value translation into Spanish
mobile view has to move Eng and Spanish links to menu button

Would it be possible for us to create an updated placeholder es.json with a complete set of fields (albeit without fully translated text, until we get translations from DoS?

Task update:

[x] get language selection links to work
[x] re-style header to match mock
[ ] componentize gov header
[ ] add world icon
[ ] refactor styles to USWDS tokens
[ ] test gov banner expand on desktop / mobile
[ ] ensure language links display and work correctly on mobile
[ ] align vertically to Site logo
[ ] re-align beta banner to Site logo
[ ] add unit tests


Fix health delay bar

Problem
When we recover health and immediately get damage delay bar not recover with health bar.
Solution
Set delay bar scale to health bar scale when we recover health.

@Sod3n Hello! Thanks for contributing to the project with the bug fixes and some new features :D
Do you have discord? Mine is @snaiel. I'd love to chat about the project with you.


docs(tooltip): Improve docs for Tooltip component page

Rephrase sentences and change structure for several blocks.

Codecov Report

Merging #225 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #225   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          20     20
  Lines         379    379
=====================================
  Hits          379    379

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 21df19a...33944b3. Read the comment docs.


scroll-margin-top not working

Description
I can’t get scroll-margin-top to work as expected. It’s working fine on any other site but fails on any gridsome page.
Is there any magic happening on anchor clicks in gridsome?
Steps to reproduce
add CSS:
*[id] {
    scroll-margin-top: 100px;
}

click on any link with anchor.
Expected result
element should be 100px below top after scrolling.
Actual result
element is 0px below top after scrolling.
Environment
  System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
  Binaries:
    Node: 14.4.0 - ~/.nvm/versions/node/v14.4.0/bin/node
    Yarn: 1.21.1 - ~/.yarn/bin/yarn
    npm: 6.14.5 - ~/.nvm/versions/node/v14.4.0/bin/npm
  Browsers:
    Chrome: 86.0.4240.75
    Firefox: 81.0.1
    Safari: 14.0

I had to change the router scroll behavior to get it to work:
// Overwrite the router options.
  router.options.scrollBehavior = async (to, from, savedPosition) => {
      const elem = document.querySelector(to.hash)
      // vue-router does not incorporate scroll-margin-top on its own.
      if (elem) {
        const offset = parseFloat(getComputedStyle(elem).scrollMarginTop)
        return {
          selector: to.hash,
          offset: { y: offset }
        }
      }
    }
    if (savedPosition) return savedPosition
    return { x: 0, y: 0 }
  }

I actually have a lot of other things in here to get scrollBehavior to do what I want, but this should get you started.

@cco3 Thanks. that works great!

This is some pretty strange default behaviour. Any way we can get this merged in somehow?

I think it might be an issue for vue-router rather than gridsome.

// Overwrite the router options.
router.options.scrollBehavior = async (to, from, savedPosition) => {
const elem = document.querySelector(to.hash)
// vue-router does not incorporate scroll-margin-top on its own.
if (elem) {
const offset = parseFloat(getComputedStyle(elem).scrollMarginTop)
return {
selector: to.hash,
offset: { y: offset }
}
}
}
if (savedPosition) return savedPosition
return { x: 0, y: 0 }
}

router.options is private. How does this work?


multiple output

Hey! thanks a lot for this cool dash-uploader. I tried to integrate it with my dash app. It works perfectly well with a single output. Unfortunately, when it comes to multiple output (e.g. multiple children for different pages), it didn't work.
Any comments?!
Look forward to your reply. :-)

Hi! Nice to hear you are liking it! Could you tell what is the dash-uploader version you are using, and provide a minimum code example on how the problem can be reproduced?

Sure!
`
def get_upload_component(id):
return du.Upload(
id=id,
max_file_size=1800,  # 1800 Mb
filetypes=['pk'],
upload_id=uuid.uuid1(),  # Unique session id
)
html.Div(
[
get_upload_component(id='dash-uploader'),
],
style={  # wrapper div style
'textAlign': 'center',
'width': '200px',
'padding': '10px',
'margin-left': '1rem',
'display': 'inline-block',
'color': 'white'
})
@app.callback([Output('page_1-1', 'children'),
Output('page_2-2', 'children'),
Output('page_3-3', 'children')],
[Input('dash-uploader', 'isCompleted'),
Input('dash-uploader', 'fileNames'),
Input('dash-uploader', 'upload_id')])
def get_a_list(is_completed, filenames, upload_id):
if is_completed and filenames is not None:
global object
object = pp.load_Gnetdata_object(UPLOAD_FOLDER_ROOT + '/' + str(upload_id) + '/' + filenames[0])
    new_page_1 = create_page_1()
    new_page_2 = create_page_2()
    new_page_3 = create_page_3()

    return [new_page_1, new_page_2, new_page_3]

`
So it works with individual pages for a single output.. but not with multiple pages.. :(

Thank you @MingBit . How are page_1-1 and create_page_1() defined? Could you paste or upload full minimal example with code that I could run as such? It would be easier to spot what is wrong if I could just run your script.

yesss.. sure! :-)
So I have a sidebar as a menu and page_1 is the one of the sub-pages. And page_1 will be updated based on the global object (upload by user).
1) Default page_1
page_1 = html.Div(id='page_1-1', children=html.H4('please upload object!', style={'color': 'white'}))
2) Create new page_1 once global object uploaded

def create_page_1():
    page_1 = html.Div([
        dbc.Row([
            dbc.Col([
                html.H4('Cell distribution'),
                html.Br(),
                dcc.Graph(id='cell_distribution'),
                dbc.Row([
                    dbc.Col([
                        html.P('color encoded by:', style={'color': 'white'}),
                        dcc.Dropdown(options=get_cellinfo_column(), id='color_code', value='Condition')
                    ]),
                    dbc.Col([
                        html.P('shape encoded by:', style={'color': 'white'}),
                        dcc.Dropdown(options=get_cellinfo_column(), id='shape_code')
                    ])
                ])
            ]),
            dbc.Col([
                html.H4('Cell percentage'),
                html.Br(),
                dcc.Graph(id='cell_percentage')
            ])
        ]),
        html.Br(),
        html.H4("Cell annotation table"),
        html.Hr(),
        dash_table.DataTable(id='table',
                             columns=[{'name': i, 'id': i} for i in object.CellAttrs['CellInfo'].columns],
                             data=object.CellAttrs['CellInfo'].to_dict('records'),
                             fixed_rows={'headers': True},
                             style_table={'overflowX': 'scroll',
                                          'overflowY': 'scroll',
                                          'width': '100%',
                                          'height': '50%',
                                          'minWidth': '100%',
                                          'maxHeight': '50ex'},
                             style_cell={'overflow': 'hidden',
                                         'maxWidth': 2,
                                         'textOverflow': 'ellipsis',
                                         'backgroundColor': '#457b9d',
                                         'color': 'white',
                                         'textAlign': 'center'},
                             style_header={'fontWeight': 'bold',
                                           'color': 'black',
                                           'backgroundColor': 'rgb(230,230,230)'},
                             sort_action='native', sort_mode='multi', filter_action='native')
    ])
    return page_1

3) update call back

@app.callback([Output('page_1-1', 'children'),
               Output('page_2-2', 'children'),
               Output('page_3-3', 'children')],
              [Input('dash-uploader', 'isCompleted'),
               Input('dash-uploader', 'fileNames'),
               Input('dash-uploader', 'upload_id')])
def get_a_list(is_completed, filenames, upload_id):
    if is_completed and filenames is not None:
        global object
        object = pp.load_Gnetdata_object(UPLOAD_FOLDER_ROOT + '/' + str(upload_id) + '/' + filenames[0])

        new_page_1 = create_page_1()
        new_page_2 = create_page_2()
        new_page_3 = create_page_3()

        return [new_page_1, new_page_2, new_page_3]

The full code can be found at my github

Thank you for the code. I tried it but did not encounter any problems, probably because I do not have the data your app wants to use (.pk file) - I just get "Invalid file type" message. Could you describe more what do you mean by "it didn't work."?

Sorry to make this so complicated! The pickle file was successfully uploaded but the code inside didn't run, meaning the page_1, page_2 and page_3 don't update and  still show the default message 'please upload object' after data uploaded.
it runs perfectly with
@app.callback(Output('page_1-1', 'children'),
               # Output('page_2-2', 'children'),
               # Output('page_3-3', 'children'),
              [Input('dash-uploader', 'isCompleted'),
               Input('dash-uploader', 'fileNames'),
               Input('dash-uploader', 'upload_id')])
def get_a_list(is_completed, filenames, upload_id):
    if is_completed and filenames is not None:
        global object
        object = pp.load_Gnetdata_object(UPLOAD_FOLDER_ROOT + '/' + str(upload_id) + '/' + filenames[0])

        new_page_1 = create_page_1()
        new_page_2 = create_page_2()
        new_page_3 = create_page_3()

        return [new_page_3]

Hey! I just test again and it works with two outputs. One is page_1 and the other one is html object from your example.
So I guess there must be some issues with subpage functions.  Uploader is cool! Thank you very much! :+1:
@app.callback([Output('page_1-1', 'children'),
               # Output('page_2-2', 'children'),
               Output('page_3-3', 'children'),
              **Output('callback-output', 'children')],**
              [Input('dash-uploader', 'isCompleted'),
               Input('dash-uploader', 'fileNames'),
               Input('dash-uploader', 'upload_id')])

I'm happy you figured it out! Is it ok to close this issue?

Yeah! Sure! :-)


When all tests pass, users should be advanced to subsequent challenge

Ethan has argued that this may not be necessary for our MVP and we may just rely on users manually marking challenges complete after tests pass.

Lets call this the 'Auto-Advance' feature. Unnecessary for MVP. Will be added in the future.


[7.0] Moved value field in spec from ObjectMember to ObjectProperty as ObjectMethod's don't have it

Q
A

Bug fix?
no

Breaking change?
no

New feature?
no

Deprecations?
no

Spec compliancy?
no

Tests added/pass?
N/A

Fixed tickets
comma-separated list of tickets fixed by the PR, if any

License
MIT

ObjectMember was defined as having a value field but actually only ObjectProperty has this field but ObjectMethod extends ObjectMember so it shouldn't have it there, so I removed it off ObjectMember and put it on ObjectProperty instead.

Nice catch!
Kind of thinking we should just link to ESTree again and then add the nodes we have that are different (Babel 6 nodes)


API for zero copy IO

it should be possible to initialize interpreter with user defined u8-array-slice being used as environment memory by interpreter. This would enable parity-wasm to perform zero-copy IO in context of sockets.
API should provide helper functions to derive correct indices of elements being stored in the memory-chunk, such as length values, buffer-start/end, etc

I totally agree that interpreter should be able to execute code in the context of borrowed (mutably) memory, it is something we are thinking about at the moment.
Could you provide more details about

derive correct  indices of elements [...]

?
How can interpreter reason about those indices/length-es/buffers, etc. ?

as for "derive correct indices of elements":
The assumption is that the parity-wasm interpreter can deal with single contiguous memory-chunk as env-memory. In this case its API should provide an abstract view onto this memory-chunk, exposing interfaces for partitioning and interpretation as primitive or length encoded array of variable length. As for the latter, length and capacity as structured prelude to the array-body.
parity-wasm should  provide a abstraction as simple memory manager in context of the contiguous memory-chunk, to deal with the corresponding allocation/partitioning and representation/marshalling of structured data. The abstract interface shall provide a native view as Rust-types (eg Rust array slices), but also exposing the index-positions of certain structured data instances encoded within the memory-chunk (prelude+body of array).
In case the interpreter would be able to deal with multiple memory-chunks (multiple array-slices) forming a virtual contiguous memory, the abstract interface should provide the logic to 'concat' these elements as linked list, and creating  a virtual index space. The abstract interface would create the corresponding indices for wasm-function invocation, and interpreter would need to map the index and offsets onto effective memory-chunks within the linked list.
I dont know which way parity-wasm intends to follow.

I am still thinking about the scope of this, and weather the scope is inside this library also.
Can you imagine example (code) of how it will be used?

this is related to #96, the corresponding env-memory API.
Assuming we deal with a single linear memory chunk. The chunk  can be resizable, which means we are not allowed to deal with raw-references into that chunk, but just with indeces, that are transformed to rust-refs if required.
// => linear memory is created
// memory  may grow automatically
let env_memory = env_instance.memory(ItemIndex::Internal(0)).unwrap();
// append/alloc  memory for primitive
let  idx : PrimIdx = env_memory.prim_alloc(); // index probably alligned to sizeof(i32)
let ar_idx : SeqIdx<&mut [u8]> = env_memory.seq_alloc(octet_size);  // no alignmend
// no more allocation must occure from now on, to prevent memory-chunk is resized and position of the
// memory is changing
idx.set(42); // demonstrating setting of primitive
let io_buffer : mut &[u8] = ar_idx.get();
let (nread, fromaddr) = socket.recv(io_buffer, octet_size);
...
The wasm functions would  be invoked with two parameters,  index of buffer and its octet-length.
it would be possible to place the complex structure of vec in the env-memory as well, but it would be necessary to standardize the memory layout, a canonical form between  Rusts Vec<>, Javascript-Arrays and C++ std::vector<>, etc.

Interpreter moved to wasmi crate