xAxis Label Overlap

Using v4.7.0:

After upgrading to v5.0.2:

Version
5.0.2
Steps to reproduce

Upgrade to eCharts 5.0.2

Use the following options for xAxis:

options.xAxis.push({
      gridIndex: ndx,
      type: 'time',
      axisLabel: {
            formatter: function (date, index) {
                  return DateTime.dateFormat(new Date(date), true)
            },
            showMaxLabel: false
      },
});

What is expected?
Expect the xAxis intervals to be spread out far enough so that the labels don't overlap.
What is actually happening?
After upgrading to eCharts v5, the labels now overlap. The chart options did not change.

Thanks for your feedback. This is related to #13682 and #14266. It will probably be fixed in v5.1.0 or v5.2.0.

Any news?

Any more news? I have the same problem. I noticed that axis ticks are also irregularly placed which should not happen. I am using version 5.1.2.

@plainheart Thanks a lot. I am anxiously waiting for the new version :). Do you already know when it'll be released?

when will it be fixed ? I'm using the v5.2.2 and it still overlaps

For us it works now with version 5.2.2 - well, sort of. What axis does now is that it simply hides the ones that overlap. It should rearange the layout of the axis instead because the result is not that good as it could be. The axis layout algorithm is in general implemented badly. I know that the problem is that you cannot calculate the tick positions directly because in order to check if two labels overlap, you already need the tick positions. I have implemented such an algorithm long time ago where I roughly estimated the tick positions, checked if texts overlap and if yes, increase the tick offset and continue until I got the correct positions. It usually took only a couple of cycles and produced perfect result.

I had the same issue with 5.2.2. For me it was fixed with setting xAxis.axisLabel.hideOverlap to true.

I had the same issue with 5.2.2 when using label type 'time'. For me it was fixed with setting xAxis.axisLabel.hideOverlap to true.

Tip: if you have axis labels of different lengths (e.g. weekday names), pad the ends with spaces to the same length to get better results.


Shoule we add gradle wrapper in our projetc standalone templates just like liferay workspace ?

moved to https://github.com/gamerson/liferay-blade-cli/issues/4


[18:53:30] [main/INFO] (Minecraft) Completely ignored arguments: [--mimicPlayer, Xyndra]

it worked for a while but now this happened. The mod is still in the "loading ... mods" message but seems to be loaded too slowly

works again now


Address ARC feedback

Address below issues raised during ARC review of RC2 draft. 1) Use "RIMT node" instead of "RIMT device" or "device binding". 2) Use PCIe everywhere.
3) Change Interrupt Wire Number to Interrupt Number 4) Add description about GSI mapping.
5) Just mention 1 as the revision.
6) Add description to ID/Unique ID fields.
7) Describe what is N in ID mapping array.
8) Elaborate ID Mapping and what is source ID.
9) Reword padding field in platform device node.
10) Reworded Name as device object name which is the full path of the device in the namespace.
11) Updated ID field description in platform device node so that it doesn't get confused with the device ID.

Looks good to me. Go ahead.


MultiplayerSynchronizer visibility results in client peer not finding cached object

Tested versions

Reproducible in v4.2.2.stable.official.15073afe3
Reproducible in v4.2.2.rc3.official.16a8334b8
Reproducible in v4.2.2.rc2.official.c61a68614
Reproducible in v4.2.2.rc1.official.c7fb0645a
Not reproducible in v4.2.1.stable.official.b09f793f5

System information
Godot v4.2.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 Ti (NVIDIA; <IP_ADDRESS>76) - Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (8 Threads)
Issue description
I have a multiplayer setup where characters have limited vision using the MultiplayerSynchronizer's visibility settings.
Characters have two MultiplayerSynchronizers:

The main "Sync" MS is for the server to sync character properties to clients
The second "Motion" MS syncs its own properties (target_position) from the client to the server, for movement interpolation

The "NetworkClientScope2D" and "NetworkScopedObject2D" are Area2D nodes that detect when a character is in range and update the "Sync" MP's visibility for the corresponding peer accordingly.
In Godot 4.2.1, this works as expected.
The Host (on the left) always sees the client.
The client (on the right) only sees the host when they're in range:

In Godot 4.2.2, the visibility setting works once. Upon exiting the visibility range, and re-entering the Area2D, the client can no longer receive updates from the "Motion" MS.

Instead, the client will report error messages for each synchronization update:
E 0:00:21:0159   get_cached_object: ID 3 not found in cache of peer 1.
  <C++ Error>    Parameter "oid" is null.
  <C++ Source>   modules/multiplayer/scene_cache_interface.cpp:278 @ get_cached_object()

and, as a result:
E 0:00:21:0167   on_delta_receive: Ignoring delta for non-authority or invalid synchronizer.
  <C++ Error>    Condition "true" is true. Continuing.
  <C++ Source>   modules/multiplayer/scene_replication_interface.cpp:783 @ on_delta_receive()

I believe this may be related to PR 87190 ([MP] Handle cleanup of "scene cache" nodes)
Steps to reproduce
I recommend enabling Visible Collision Shapes from the debug menu

Launch two instances of the MRP.
Start one as host, and have the other join as client (The MRP is set up to host and connect to localhost over WebSocket).
Move the players towards each other (order does not matter) until they're in visibility range.
Note how both characters correctly sync their positions
Move the character apart, so they're no longer in visibility range
Move the characters back together

In Godot 4.2.1, this works fine.
In Godot 4.2.2 (starting with RC1), the host character can no longer synchronize its position to the client. Instead, the client will report get_cached_object errors.

Minimal reproduction project (MRP)
https://github.com/graydoubt/422-mp-regression

Thanks for the detailed report, I think I understand what is going on, I'll try to get a fix out next week.

The same thing happens to me, I'm using 4.2.2.stable.

same error in v4.3 beta2

Thanks for the detailed report, I think I understand what is going on, I'll try to get a fix out next week.

@Faless what do you think about this in relation to the release of 4.3? Do you want to fix this before 4.3 releases or should we wait for 4.3.1?

While unfortunate, as this has been ongoing since 4.2.2, I don't think we should block 4.3 release anymore on this at this point. A fix should still be possible in 4.3.1 (and maybe be cherry-picked to 4.2) just the same, unless Fabio disagrees, of course.

It's unfortunate that this has been delayed as I've just encountered it while using my load function!
Deleting all my player nodes on a load produces this error, may be related? I am not using a multiplayer spawner.
Can I ignore this error for now or will it cause problems?

I also have this error and don't know how to solve it

@agrimminck This should be "fixed" for now by the revert mentioned in https://github.com/godotengine/godot/pull/94984 (and done in https://github.com/godotengine/godot/commit/3504c98c1233bbd2506e89ce46509bc79afaec17). To see the fix, you'd need to use a build that was done after that commit, so you'd either need to wait for the next Release Candidate or build master yourself to see if the fix works for you.

okay, thank you! I will waiy for RC2 then


Convert volumes and surface areas from nanoscale to macroscale

Current status
As of now, the volume and surface area values are given for single molecules or unit cells.
Issue
It is simple but not straightforward to compare data calculated with MoloVol on the nanoscale and values measured on the macroscale.
Proposed change
Add volume and surface area values per gram in the report file.
For this, the molecular weight needs to be known so the element radii file needs to be updated with elements weight.
The radii file should be renamed elements (or elements_properties).
Then the following formulas can be applied:
V [cm^3/g] = V [Å^3] * Navogadro [mol^-1] * 10^-24 [cm^3/Å^3] / M [g/mol]
S [m^2/g] = S [Å^2] * Navogadro [mol^-1] * 10^-20 [m^2/Å^2] / M [g/mol]

Improvement
It could prove useful to get volume and surface area per gram of material, especially to compare to experimental data (e.g. gas sorption for porous solids).

Changes required off the top of my head:

Changing the name of the resource file, will require all explicit references in the code to be changed. This is a good opportunity to centralise access to this file, for instance, by creating a function that returns the correct path. This would have the benefit that if we needed to change the name again for whatever reason, then we would only need to change it once.
Since we're still in pre-release, it's still no issue changing the corresponding command line option for what is currently the radius file ("-fr"). We could change it to something like "-fe"
In the GUI we should change the text box before the element file path to something like "Element data:"

Should this also be an output in the GUI or should this be limited to the result file? I wouldn't want to risk including clutter to the GUI, but if it makes sense, then it should of course be included in the GUI. Maybe there could be a switch to change values back and forth?
I prefer the name "elements.txt".

Should this also be an output in the GUI or should this be limited to the result file?

I don't think this information is required in the GUI which summarizes the main results without further processing. The report file is there to give detailed results.
I'll open a branch for that feature once I find a reliable consistent source for all elements' molar mass.

Alright. Please make sure you use getResourcesDir() in misc.cpp to access the directory in which the elements.txt file is located. It may be good to add another function directly inside misc.cpp that's called something like "getElementFilePath()".
I suggest creating a std::map inside the model class, with which to look up mass using the element symbol as key.


[✨] Let us use your custom hooks, inside the routeLoader$ too

Is your feature request related to a problem?
I want to centralize some code that is used across many routeLoader$ instances. I'm using custom hooks to do that. And inside my custom hook, I'm using your hooks to access URL data (query string in this case).
But I get this error:
Code(20): Calling a 'use*()' method outside 'component$(() => { HERE })' is not allowed. 'use*()' methods provide hooks to the 'component$' state and lifecycle, ie 'use' hooks can only be called synchronously within the 'component$' function or another 'use' method.
For more information see: https://qwik.builder.io/docs/components/tasks/#use-method-rules

The error message is crystal clear. I should use your hooks only inside component$. However, a lot of times we need to centralize code in our many routeLoader$ functions too. I have created an instance for this:
stackblitz
I know that I can access requestEvent from inside the routeLoader$ and pass it to my custom hook. I know that. But that's not clean.
Please let us write this code:
const getData = routeLoader$(() => {
    const data = useCustomHook()
});

const useCustomHook = () => {
    const location = useLocation()
    // rest of the code
}

Describe the solution you'd like
I would like to be able to call your custom hooks inside our custom hooks, and then use our custom hooks inside the routeLoader$ function.
Describe alternatives you've considered
For now, we repeat ourselves. We write this code in every page and in every layout code:
const { url } = useLocation()
const locale = url.searchParams.get('locale')
if (!locale) {
     // loading the default locale from config file in some lines of code
}

Additional context
Please see the example link above and uncomment the getData function in the index.tsx file.

I also need this features. I'm trying to access URL inside my custom hook.

@Nefcanto how did you solve this specific task?

@gioboa, sorry to answer this late. Right now we have to do props drilling. We load some data from the API in routeLoader$, then inside the main component$ we use your custom hooks to get more data, and then we drill those props into our component hierarchy. Yet this is not efficient.

Actually there's no reason to confine signals to the render tree, but there can be no reactivity between server and client (that requires a communication channel).
Hooks could be made possible inside loaders, but they would not see any context and they would run fresh every time.
So if you want to use a graphql hook inside route loaders, that would technically be possible, but it would be adding some overhead for no reason, and you'd have to put the client provider just before the query.
So it would look weird, and it would be a little inefficient.

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.


Thanks for your help.
Fritz

sorry, there will be another small bug in a next PR (to my defense the specification of std::streambuf is not clear :-/ )

Trust me I know the pain. I appreciate your help.


ITMS-90876: Missing entitlement

Since this app contains an App Clip, the com.apple.developer.associated-appclip-app-identifiers entitlement should be present and include the value of the App Clip's application identifier. Please add this entitlement, then resubmit.

https://stackoverflow.com/questions/67521532/xcode-12-5-missing-entitlement-com-apple-developer-associated-appclip-app-identi

https://developer.apple.com/forums/thread/718317


Not able to make it work

Followed simple steps..

cloned it (tried both truck and v2-release branch)
just ran docker-compose up
also tried local npm hacks.. install, update, --legacy-peer-dep (even npm-check-updates and ncu -u etc). but the project seems to be left behind the numerous dependencies that have moved on since the last update.
On my macbook... here'e the node env.
Atlas2: '2.0.4',
npm: '7.7.4',
node: '15.12.0',
v8: '8.6.395.17-node.27',
uv: '1.41.0',
zlib: '1.2.11',
brotli: '1.0.9',
ares: '1.17.1',
modules: '88',
nghttp2: '1.42.0',
napi: '8',
llhttp: '2.1.3',
openssl: '1.1.1j+quic',
cldr: '38.1',
icu: '68.2',
tz: '2020d',
unicode: '13.0'
has anyone tried this in 2021 and made it work ?

Nope. I do not think anyone tried it.
It has been 2-3 years since I have not been able to maintain the project.

Thanks! Let me take a shot at it locally first.. to be honest the whole npm thing is a depedenecy hell :-) I am also not a node expert, more of a java guy but will give it a shot.. will get back if I am able to solve it and then can contribute back


How to construct the first node in the first Order message when the AGV initially stops on an edge？

Node1 is start_node of Edge1.  Node2 is end_node of Edge2.
I have two ideas.

I can make a virtual node with the current coordinates of the AGV and create an virtual edge that starts from the AGV's current location.
Set a large range to attribute “allowedDeviationXY” of Node1。

The first idea involves lots of complex coding to create virtual element, however, it's friendly for AGV.


API Docs | Typo fix for headerExtractor description in Public API

What does this PR do?
Fixes a typo for the headerExtractor description in:

https://www.elastic.co/guide/en/apm/agent/java/current/public-api.html#api-start-transaction-with-remote-parent-header
https://www.elastic.co/guide/en/apm/agent/java/current/public-api.html#api-start-transaction-with-remote-parent-headers

Checklist

[X] My code follows the style guidelines of this project
[x] I have rebased my changes on top of the latest master branch

[x] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

[ ] I have updated CHANGELOG.asciidoc
[ ] I have updated supported-technologies.asciidoc
[ ] Added an API method or config option? Document in which version this will be introduced
[ ] Added an instrumentation plugin? How did you make sure that old, non-supported versions are not instrumented by accident?

Author's Checklist

Related issues

Closes #1041
Use cases

Screenshots
<!-- _(Optional)_
Add here screenshots about how the project will be changed after the PR is applied. They could be related to web pages, terminal, etc, or any other image you consider important to be shared with the team.

@elasticmachine, run elasticsearch-ci/docs

@bmorelli25 Thanks for the review! Can you help merge this? Or assign it to the appropriate person. Not sure who to assign this.

Yup, I'll let one of the engineers merge this.
@felixbarny or @SylvainJuge What does the failing CI-approved contributor check mean?

@bmorelli25 Thanks. Afaik, I had not signed the contributor agreement before I did the PR. Did it right after. Should be good now. Someone can review that.

thanks!


While creating (dragging) a new edge with SmoothStepPath the arrow points in wrong direction

What platform were you using when you found the bug?

React Flow version: 11.11.1

Live code example
No response
Describe the Bug
When you create (drag) a new custome edge with SmoothStepPath from a source handle to a target handle, the final part of the path always "points to the right" even when snapping to a target handle that has Position.Top
After letting go the mouse button, the edge path correctly switches to pointing down
But I'm requested to also show the dragging path as pointing down when snapped to a Position.top target handle
Steps to reproduce the bug or issue
Create a custom edge with a SmoothStepPath. Then create two nodes where one of the nodes has a handle with Position.Top
Create/Drag a new edge between the two nodes and snap the edge to the target handle (without letting the mouse go). It will point to the right even though the target handle is Position.Top
Only after finishing (letting go the mouse button) the final edge path points down correctly
Expected behavior
After snapping to a target handle with a position other than Position.left the edge path should point in the right direction
Screenshots or Videos

Additional context
No response

This is fixed in React Flow 12.


Validate named imports in JSDoc

Resulting from code like this:
import * as MathUtil from '../math-util.js';
/**
 * @param {MathUtil.Vector3} vector
 * @param {number} timestampS
 */
ComplementaryFilter.prototype.addGyroMeasurement = function(vector, timestampS) {
  this.currentGyroMeasurement.set(vector, timestampS);
  const deltaT = timestampS - this.previousGyroMeasurement.timestampS;
  if (Util.isTimestampDeltaValid(deltaT)) {
    this.run_();
  }
  this.previousGyroMeasurement.copy(this.currentGyroMeasurement);
};

In order to fix this properly, I need to register every possible type of imports.
Then we can also validate types like typeof import('whatever').Whatever... looking forward to implement this :sweat_smile:


Improve performance of user events endpoint

Now with over 40 networks on tlbc the user event endpoint has become too slow.
endpoint: `/users/<user_address>/events
We need to make it faster. The way todo it is to not do separate queries to the database, but to ideally do one or at least fewer requests.

Done in 3638b45fee45485fd25445cdc35e9e594eba5c9d


change filter:-query to filter:-query_string:

following documentation creates this error:
RequestError(400, u'parsing_exception', {u'status': 400, u'error': {u'line': 1, u'root_cause': [{u'reason': u'no [query] registered for [query]', u'type': u'parsing_exception', u'line': 1, u'col': 208}], u'type': u'parsing_exception', u'reason': u'no [query] registered for [query]', u'col': 208}})

What version of elastalert are you using and how are you running it?
This error should have been fixed already.

when rule configured as specified in doc, with extra query keyword:
`
filter:

query:
query_string:
query: "metricset.name: cpu"
then v0.1.8 (latest at time of filing pull request) fails with:  elastalert-test-rule --config config.yaml rules/spike-bad.yaml
Successfully loaded Events_Spike_all-hosts

INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): snpstemp054
WARNING:elasticsearch:GET http://snpstemp054:9200/metricbeat-*/_search?ignore_unavailable=true&size=1 [status:400 request:0.005s]
Error running your filter:
RequestError(400, u'parsing_exception', {u'status': 400, u'error': {u'line': 1, u'root_cause': [{u'reason': u'no [query] registered for [query]', u'type': u'parsing_exception', u'line': 1, u'col': 208}], u'type': u'parsing_exception', u'reason': u'no [query] registered for [query]', u'col': 208}})`
but version v0.1.9 fails with different not related:
`
elastalert-test-rule --config config.yaml rules/spike-bad.yaml
Traceback (most recent call last):
File "/usr/local/bin/elastalert-test-rule", line 11, in
load_entry_point('elastalert==0.1.9', 'console_scripts', 'elastalert-test-rule')()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/init.py", line 560, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/init.py", line 2648, in load_entry_point
return ep.load()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/init.py", line 2302, in load
return self.resolve()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/init.py", line 2308, in resolve
module = import(self.module_name, fromlist=['name'], level=0)
File "/usr/local/lib/python2.7/dist-packages/elastalert-0.1.9-py2.7.egg/elastalert/test_rule.py", line 20, in
import elastalert.config
File "/usr/local/lib/python2.7/dist-packages/elastalert-0.1.9-py2.7.egg/elastalert/config.py", line 8, in
import alerts
File "/usr/local/lib/python2.7/dist-packages/elastalert-0.1.9-py2.7.egg/elastalert/alerts.py", line 26, in
from twilio.base.exceptions import TwilioRestException
ImportError: No module named base.exceptions
`
So, there is no way for me to validate fix.

You can fix that with pip install twilio==6.0.0

Closing this because an extra 'query' should work with all versions of ES, where as this version will break ES < 5.0. If you can recreate that error on the most recent version, please open an issue.

I tried with latest elastalert v0.1.12 and it works fine.
Thank you!


fix: data mapping

Issue
Description
Checklist

Code is easy to understand
No obvious errors or bugs
CI/CD Pipelines did run successfully
Tests were implemented
Documentation was created

Can you, @dominikhorn93, quickly summarise what this fix implies. What needs to be tested and what is the expected behaviour?
Ty!

More or less a Bugfix.
Due to the refactoring of the worker api, we lost the json mapping in c7 workers.


Clean Up Wiki

Change wiki homepage to something more presentable. Right now it's pretty useless. I'm thinking just using the contribution page for home is fine for now.
Cost: A few minutes
Benefit: Cleaner presentation to people interested in the project and/or looking to contribute.

changed homepage to contributions.


Migrate manifests from downstream repo

Closes https://issues.redhat.com/browse/RHOAIENG-3410
Description

Migrate RHOAI manifests from the downstream repo into the manifests folder here. Some items will need to become overlays and also require some additional handling by the installer which will be addressed as we move forward.
Open questions:

How does odh-enabled-applications-config.configmap.yaml get deployed
Do we still use the anaconda validator: https://github.com/zdtsw-forking/rhods-operator/blob/main/config/partners/anaconda/base/anaconda-ce-validator-cron.yaml

How Has This Been Tested?

For ODH

Deploy the base files oc apply -k manifests/base
Deploy the CRDs oc apply -k manifests/crd
Deploy the modelserving resources oc apply -k manifests/modelserving
Deploy the consolelink oc apply -k manifests/consolelink
Deploy the apps oc apply -k manifests/apps

For RHOAI

Deploy the base files oc apply -k manifests/overlays/rhoai
Deploy the CRDs oc apply -k manifests/crd
Deploy the modelserving resources oc apply -k manifest/overlays/modelserving
Deploy the consolelink oc apply -k manifest/overlays/consolelink
Deploy the apps:

For on prem: oc apply -k manifests/overlays/apps/apps-onprem
For on addon: oc apply -k manifests/overlays/apps/apps-addon

Test Impact

Request review criteria:

Self checklist (all need to be checked):

[X] The developer has manually tested the changes and verified that the changes work
[X] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

@zdtsw We've added the consolelink with the icon, the overlay will override everything, so if the operator needs to add a follow up to add the consolelink, feel free to adapt it in a follow up PR

@dgutride @DaoDaoNoCode @andrewballantyne We only need to verify both odh-enabled-applications-config.configmap.yaml and anaconda-ce-validator-cron.yaml. For the first one, I'm not sure how we've been deploying it for upstream, since we have that in an overlay, downstream we had the file, not sure if we were creating it if missing, for the other one, i need more context

@zdtsw We've added the consolelink with the icon, the overlay will override everything, so if the operator needs to add a follow up to add the consolelink, feel free to adapt it in a follow up PR

do you have any jira to track this change for 'consolelink ennoblement in ODH'? i will need a reference for our change

@zdtsw We've added the consolelink with the icon, the overlay will override everything, so if the operator needs to add a follow up to add the consolelink, feel free to adapt it in a follow up PR

do you have any jira to track this change for 'consolelink ennoblement in ODH'? i will need a reference for our change

Nope, we decided to get it inside this same issue, let me create a new one, so we can get a reference for the platform.


Update HowToDebug.rst

We have another pipeline for updating Chinese docs now. Thanks for your contribution.


SignalR 1.0.0-preview2-final server and client mismatch CORS

I know there have been a few issues created in this repo concerning the same problem and I read every one of them but haven't come to a solution, stackoverflow wasn't of any help either so I'm trying here as a final effort until a stable version is released.
I keep running into the CORS issue integrating the example project on https://blogs.msdn.microsoft.com/webdev/2018/02/27/asp-net-core-2-1-0-preview1-getting-started-with-signalr/  in my application.
Versions of all packages used are listed below, I have checked that those are indeed the ones installed.
On my AspNetCore app I have these packages, I have also tried using Microsoft.AspNetCore.App package instead of listing them all out but it gives the same problem.
<PackageReference Include="Microsoft.AspNetCore" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.Facebook" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.Google" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.OAuth" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.HttpsPolicy" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.SignalR" Version="1.0.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.1.0-preview2-final" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.0-preview2-final" />
<PackageReference Include="Sendgrid" Version="9.9.0" />
<PackageReference Include="Swashbuckle.AspNetCore" Version="2.4.0" />

In my angular 5 application in my npm-shrinkwrap I have the following signalR package:
"@aspnet/signalr": {
  "version": "1.0.0-preview2-final",
  "resolved"<EMAIL_ADDRESS>
  "integrity": "xxx"
},

I have double checked my node modules and this is the version that is installed. The code used to create the connection is the one linked above, but I keep getting the following errors thrown into my browser console when starting the connection:
zone.js:2969 OPTIONS https://localhost:44304/api/notification/negotiate 405 ()
dashboard:1 Failed to load https://localhost:44304/api/notification/negotiate: Response to preflight
request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the
requested resource. Origin 'http://localhost:4200' is therefore not allowed access. The response had
HTTP status code 405.
signalr.js:1410 Warning: Error from HTTP request. 0:

Please include as much of the following as you can in your bug report

Versions of Server-Side NuGet Packages: 1.0.0-preview2-final
Versions of Client-Side NuGet/NPM Packages: 1.0.0-preview2-final
Are you using the C# client or the JavaScript client: JavaScript/Typescript
The Server you are using (Kestrel/HttpSysServer/IIS/IIS Express/Azure Web App/etc.): IIS Express
The Operating System on the Server (Windows/Linux/macOS): Windows
The Operating System on the Client (Windows/Linux/macOS): Windows
The Browser on the client, if using the JavaScript client (IE/Chrome/Edge/Firefox/etc.): Chrome
If possible, please collect Network Traces and attach them Network traces
If possible, please collect logs from the client:
If possible, please collect logs from the server:

Any help would be really appreciated

In my Configuration method in startup.cs I have the following lines. The rest of my application hasn't given any CORS issues so far.
// CORS
services.AddCors(options =>
{
   options.AddPolicy("AllowAnyOrigin",
       builder => builder.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader());

   options.AddPolicy("AllowSpecificOrigin",
       builder => builder.WithOrigins("localhost:4200").AllowAnyMethod().AllowAnyHeader());
});
services.Configure<MvcOptions>(options =>
{
    options.Filters.Add(new CorsAuthorizationFilterFactory("AllowAnyOrigin"));
});

In my Configure method I have:
app.UseAuthentication();
app.UseCors();
app.UseHttpsRedirection();
app.UseSignalR(routes =>
{
     routes.MapHub<NotificationHub>("/api/notification");
});
app.UseMvc();

Is there a specific order I have to follow here?

Okay I will close the issue, it seems that configuring MVC with CORS doesn't seem to work here.
When I use
app.UseCors(builder =>
  builder.WithOrigins("http://localhost:4200")
     .AllowAnyHeader().AllowAnyMethod().AllowCredentials()
  );

It's working, thank you for your time.

I think the problem is that you were creating named policies and not referencing them in the CORS middleware. In your most recent example, you are directly applying the policy to the middleware so it works. Though, I'm not an expert on how CORS works so I'd suggest asking on StackOverflow or in aspnet/Cors if you have more questions about CORS specifically


Letter Spacing/ kerning style

It would be awesome if the text had some sort of kerning\ letter spacing style. Letters are currently really close together.

As a workaround, you can use the letter-spacing CSS style by entering Hello, World in the HTML view of the label:


[Feature][Redis Plugin] Follow redirects in case of cluster

Summary
The redis server sometimes redirects to the node in question. The client is expected to connect to the specified node to retry the request.
Motivation
Since cluster nodes are not able to proxy requests, clients may be redirected to other nodes using redirection errors -MOVED and -ASK. The client is in theory free to send requests to all the nodes in the cluster, getting redirected if needed,

The specification for cluster can be found here : https://redis.io/topics/cluster-spec

Is there a way to configure this?

Thank you.
I solved the problem，spring:session:xxx has write into redis cluster. But logout an exception occured. "RedisCommandExecutionException: CROSSSLOT Keys in request don't hash to the same slot"
To fix the problem
Update RedisConfig.java  add redisNamespace = "{spring:session}"
@EnableRedisWebSession(maxInactiveIntervalInSeconds = 2592000, redisNamespace = "{spring:session}")


Added logo

First try drawing a gopher! Think it got good enough to use as a logo until someone draws a better one!
Also added constants for known exchange types.

I'm taking the liberty to merge this since I'm keen to see the new logo and there's no logical changes to the code. Well, except the TLS interface (which isn't really used yet).

I changed my mind. Since I re-wrote so much of the README would be nice if you could read it through. I know that I tend to do a lot of typos and misspells :)

Thanks! Fixed!


Node flags detected: --map

Hi,
after using --map arg, I got warning  Node flags detected: --map. My node version 10.13.0. When I changed arg value from map to maps everything was fine.

Hi!
Get the same warning on the v10.16.3
Please, run sudo npm install gulp-cli -g
Similar issue https://github.com/gulpjs/gulp/issues/1564 with gulp

@mattkrupnik if you have found this problem again, please reopen the issue.


the camera screen is  black

when i  download this library
wehn run  project
and  give permission for camera
the  camera not loaded is  black

Had the same issue.
I forgot the following code line:
await Methods.AskForRequiredPermissionAsync();
after that, the camera worked just fine for me


Add CDN link

I added a jsDelivr CDN link to the readme as it is the same as downloading it but easier and faster.

Thank you!


Reduce dependency on central

Fixes Issue - too many to reference...

If a Java dependency already has analyzed a pom.xml the Central Analyzer will be skipped
The Maven plugin no longer uses the central analyzer

Have test cases been added to cover the new functionality?
existing

Can one of the admins verify this patch?


Duplicate json fields in result

> 64000 Artix route de l'aéroport 64121

Result:

{
  "postcode": "64000",
  "house_number": "artix",
  "road": "route de l'ae ́roport",
  "postcode": "64121"
}

Thanks for reaching out. Duplicate fields actually are allowed in the address parser. The output in the client does looks roughly like JSON. I can change it to an array so it is indeed valid.
Incidentally, what is the correct parse for this address? Does Artix mean the French commune Artix or is it part of the street name? I couldn't find that address in either Google Maps or Nominatim. Is it real?
Note that the parser gets 98.9% accuracy, not 100%, so it may still get some cases wrong. I'm not a native and am always curious to learn more, but from what I understand, the typical way to write a French address would be more like:
> 64000 route de l'aéroport 64121 Artix

Result:

{
  "house_number": "64000",
  "road": "route de l'ae ́roport",
  "postcode": "64121",
  "city": "artix"
}

Which libpostal parses correctly. In that instance, even though 64000 could be a postal code (and is even a valid postal code in France), its position in the address next to a word like "route" helps disambiguate that it is in fact the house number. Whereas when it is seen next to a city name like Artix, it will be more likely to be a postal code.
Libpostal is currently trained on the more standard French address formats. If listing the city before the street name is a (reasonably common), alternative form, we should add that form to the address-formatting repo, which is used by libpostal to generate training addresses from OSM.
Let me know what you think.

Yes sample address is ill, but edge cases are still interesting.
I play a bit with libpostal and works fine with simple well formatted addresses, but fail on complicate cases. I will make other issues about this.

@frodrigo the 1.0 release still gets this parse wrong (I think), but it's closer to correct than the previous version:
> 64000 Artix route de l'aéroport 64121

Result:

{
  "postcode": "64000",
  "city": "artix",
  "road": "route de l'aéroport",
  "postcode": "64121"
}

I added some formatting exceptions to the training data so when libpostal is building its training examples, it can switch certain components at random to create different formats. In the case of France, I allow city to come between house_number and road, but it still has trouble with this parse.
We now import the entire cadastral data set for France and its territories from OpenAddresses, so almost every address in the country is seen by libpostal during training. However, I didn't find any addresses with a 5-digit house number in France. So wanted to ask: are you certain that "64000" is a house number in this case? I suppose maybe if it's a typo or something. In any case, it it is legitimately a house number, we should add more edge case like that one to OSM so libpostal can pick them up for training, and/or I can try adding some random noise to the actual house numbers, for instance appending a digit some random proportion of the time so at least there are some in the training data.
In any case, it's worth giving libpostal 1.0 a try. It works significantly better on a variety of more complicated French addresses. Currently not the "BÂTIMENT F" case, because it's not yet trained on that style and I'm still trying to figure out a method for consistently handling buildings in larger complexes, but it does have several new sub-building components including things like "ap 12", "et. 2", "rez-de-chaussée"/"rdc", "BP 234", etc. There's a config file that details some of the new fields we use to augment OSM in places where it's lacking, and contributions are welcome.

Here, 64000 is the postcode, 64121 dosn't look like a French postcode. There is a very high probabily that a French postcode finish with a 0.
city between house_number and road is completely unnatural for French.
I will give a new try of libpostal with the rejected addresses of my local addok geocoder (https://github.com/addok/addok)

On last version the parsing look as I expected:
> 64000 route de l'aéroport 64121 Artix
{
  "house_number": "64000",
  "road": "route de l'aéroport",
  "postcode": "64121",
  "city": "artix"
}

Nevertheless I encountered duplicate house number field on very well formed French address
> 26 rue verte 06160 juan les pins
{
  "house_number": "26",
  "road": "rue verte",
  "house_number": "06160",
  "road": "juan les pins"
}

Ah ok, so as far as I can tell, both 64121 and 64000 are both valid postal codes, and both are near Artix. So I think in that example there should be two postcodes, it's just ill-formatted. Will revert the change that allows house numbers between cities and roads.
For Juan-les-Pins, I grepped for it in the training data (which are now public, your input is welcome if there are any issues with French addresses), and the only examples I could find were a road in Quebec, Canada. Juan-les-Pins exists in OSM as a suburb, and so does that postcode, but weirdly that point does not match the France country polygon in our polygon index. Points without a country are ignored, so essentially that place name doesn't exist as far as libpostal knows. We build the country polygons with Shapely and no buffering. When moving to unbuffered polygons, I'd spot-checked a bunch of points that were close to borders and it didn't seem to have any problems, but maybe with coastlines it does. Using buffering of about 0.01, the France polygon does contain the point for Juan-les-Pins. So I suppose for reverse-geocoding to country, since that's necessary for addresses to be considered, it might make sense to use a "kitchen sink" approach i.e. do an initial point-in-polygon check on the unbuffered polygons (for accuracy along tight borders) and then a check on the buffered version if there are no exact matches. I will look into this for the next training batch.


Fix #261 by changing 'character rate' to 'dot speed' …

… and selectively enabling/disabling spacing options depending on selected speeds.
This change re-labels "character rate" to "dot speed" as an experiment.
In addition to the purely cosmetic change of label, the code now also check to see if the "code speed" and "dot speed" are the same and disables Farnsworth spacing selections, fixing the value to "NONE".  Conversely, as soon as the two speeds diverge, "NONE" is deselected and "Between characters" and "Between words" become enabled, with whichever one was originally configured selected.
Try this out and let me know what you think of the effect?

This fixes any inconsistencies between selecting spacing and specifying the same or different “dot speed” vs. “code speed”.  There’s one other thing we could do to really make it clear what’s happening: since there’s no way to send with “dot speed” > “code speed”, we COULD make the preferences window automatically bump up “code speed” to keep up with “dot speed” as soon as “dot speed” = “code speed”?  That would have the effect of ensuring code speed is always at least dot speed with dot speed increases ultimately “raising the ceiling” and dragging overall code speed with it.
Thoughts?
73, -Patrick.

On Feb 4, 2021, at 12:11 AM, Patrick Dirks<EMAIL_ADDRESS>wrote:
… and selectively enabling/disabling spacing options depending on selected speeds.
This change re-labels "character rate" to "dot speed" as an experiment.
In addition to the purely cosmetic change of label, the code now also check to see if the "code speed" and "dot speed" are the same and disables Farnsworth spacing selections, fixing the value to "NONE". Conversely, as soon as the two speeds diverge, "NONE" is deselected and "Between characters" and "Between words" become enabled, with whichever one was originally configured selected.
Try this out and let me know what you think of the effect?
You can view, comment on, or merge this pull request online at:
https://github.com/MorseKOB/PyKOB/pull/262 https://github.com/MorseKOB/PyKOB/pull/262
Commit Summary
Fix #261 by changing 'character rate' to 'dot speed' and selectively enabling/disabling spacing options depending on selected speeds
File Changes
M pykob/preferencesWindow.py https://github.com/MorseKOB/PyKOB/pull/262/files#diff-9accc83b9c1afe7f173372ed2481bec180d81f29b0f8de6f489a784c0cdaa49b (50)
Patch Links:
https://github.com/MorseKOB/PyKOB/pull/262.patch https://github.com/MorseKOB/PyKOB/pull/262.patch
https://github.com/MorseKOB/PyKOB/pull/262.diff https://github.com/MorseKOB/PyKOB/pull/262.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/262, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK53U5M3D76GOJLGNMLS5JJDNANCNFSM4XCLJ2JA.

since there’s no way to send with “dot speed” > “code speed”

Why is it not possible to send with 'dot speed' > 'code speed'? That's the normal situation with Farnsworth. For example, you might want to send your text with a code speed of 15 wpm, but have each character sent at dot speed of 18 wpm.

This branch works for me. I might rather have full control and be able to turn off Farnsworth temporarily by selecting 'None' for spacing when 'Code speed' is, say, 15 wpm and 'Dot speed' is 18 wpm, but I can achieve the same result by cranking 'Dot speed' down to 15 and then cranking it back up to 18 (assuming I remember where it used to be). But if there are advantages to disabling 'None' I can definitely live with it.

Sorry - that’s stated exactly backwards.  You can’t select “dot speed” LESS THAN “code speed”.  So as you dial dot speed BELOW code speed, the UI could automatically drag code speed down with you.

On Feb 4, 2021, at 3:46 AM, Les Kerr<EMAIL_ADDRESS>wrote:
since there’s no way to send with “dot speed” > “code speed”
Why is it not possible to send with 'dot speed' > 'code speed'? That's the normal situation with Farnsworth. For example, you might want to send your text with a code speed of 15 wpm, but have each character sent at dot speed of 18 wpm.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-773247889, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK5UKJSZMYU6AKABHHTS5KCJ7ANCNFSM4XCLJ2JA.

When you imagine (temporarily) turning Farnsworth OFF, what do you think you have in mind?  "Let me see what this code speed looks like full-out”?  Or "let me see what that speed when sent without continuous looks like”?  Or “Let me dial back the pauses and see how it goes”?
One might lend itself more naturally to adjusting code speed - the other perhaps to “forcing” code speed to match the selected dot speed.  We could permit both but I wonder if people would be surprised if clicking on the “None” radio button jumped the code speed ahead?  They might even miss the effect, and then be surprised it’s not what they set it to?
73, -Patrick.

On Feb 4, 2021, at 4:01 AM, Les Kerr<EMAIL_ADDRESS>wrote:
This branch works for me. I might rather have full control and be able to turn off Farnsworth temporarily by selecting 'None' for spacing when 'Code speed' is, say, 15 wpm and 'Dot speed' is 18 wpm, but I can achieve the same result by cranking 'Dot speed' down to 15 and then cranking it back up to 18 (assuming I remember where it used to be). But if there are advantages to disabling 'None' I can definitely live with it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-773255935, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK7L63TOHO2RVZJ46ATS5KEBVANCNFSM4XCLJ2JA.

Sorry - that’s stated exactly backwards. You can’t select “dot speed” LESS THAN “code speed”. So as you dial dot speed BELOW code speed, the UI could automatically drag code speed down with you.

But I always set my Farnsworth dot speed less than the code speed. My standard settings are code speed = 24 and (minimum) dot speed = 18. As always, code speed takes precedence and the dots are actually sent at 24 wpm. If I occasionally want to send much slower, at 15 wpm say, then I change my WPM setting on the main KOB window to 15. Farnsworth kicks in and the characters are sent at 18 wpm. When I want to go back to my normal speed, I change the WPM setting to 24. I never touch the Morse Code tab after first setting it up.

When you imagine (temporarily) turning Farnsworth OFF, what do you think you have in mind?

As always, the code speed setting takes precedence. So when I turn Farnsworth off, the dot speed setting is ignored, the code is sent at the specified code speed without any extra space between characters.

… but that results in seemingly impossible settings (code speed = 24/dot speed = 18 or code speed = 15/dot speed=18/Farnsworth=None).  YOU know the code speed settings take precendence but I’m not sure that’s a good UI - the settings don’t show how they’re actually being interpreted.
I’d rather if you set a dot speed greater than the actual code speed, you see there’s some spacing inserted somewhere.  Conversely, when the speeds are the same, you should see that spacing=None.  When you decide you want to send more slowly, I think it’s natural to start dialing down code speed; when it goes below dot speed, you should see spacing come alive and show you where it’s being inserted.
I guess the main oddity is you want to have a Farnsworth speed specified BELOW your code speed, even though that can’t really be done, just to “peg” the dot speed for when you control the code speed?
If we make decreasing dot speed drag down code speed with it, and increasing code speed drag dot speed UP with it to ensure “dot speed” setting is always >= “code speed” setting, I guess you’d end having to dial down both the code speed AND the dot speed some, from both =24 to code speed=15, dot speed=18.
Let me try tying those speeds together to enforce their relative settings and let’s experiment with dialing it around?

On Feb 4, 2021, at 9:55 AM, Les Kerr<EMAIL_ADDRESS>wrote:
When you imagine (temporarily) turning Farnsworth OFF, what do you think you have in mind?
As always, the code speed setting takes precedence. So when I turn Farnsworth off, the dot speed setting is ignored, the code is sent at the specified code speed without any extra space between characters.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-773495016, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK3GOLU2T5X4BCCS6QTS5LNRLANCNFSM4XCLJ2JA.

Hi Les,
Thanks for reviewing the change.  I’d like to see if we can do better… what do you find clumsy?  Not manipulating Farnsworth spacing directly with speed settings possibly inconsistent?    Should we try something different (perhaps as a separate change)?
Did you try the latest commit, BTW, which drags “dot rate” up as code speed goes above “dot speed” and drags code speed down as dot speed is slowed BELOW code speed?
73, -Patrick.

On Feb 4, 2021, at 11:34 AM, Les Kerr<EMAIL_ADDRESS>wrote:
@leskerr approved this pull request.
I've tried it and I can do everything I want to do, even though it's clumsy
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/262#pullrequestreview-583744742, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK6LAJEDICOHQXKMTWLS5LZDJANCNFSM4XCLJ2JA.

Hi Patrick,
Yes, I pulled the latest commit (with the dragging) and tried it. And yes,
my brain has adjusted to it.
There may still be an untidiness. If I change my code speed from 25 to 30
on the main KOB window and then open the Morse Code tab. It shows code
speed 30 and dot speed 25. I thought you were going to have the dot speed
track the code speed when the code speed increases.
~Les
On Thu, Feb 4, 2021 at 11:37 AM Patrick Dirks<EMAIL_ADDRESS>wrote:

Hi Les,
Thanks for reviewing the change. I’d like to see if we can do better… what
do you find clumsy? Not manipulating Farnsworth spacing directly with speed
settings possibly inconsistent?  Should we try something different (perhaps as a separate
change)?
Did you try the latest commit, BTW, which drags “dot rate” up as code
speed goes above “dot speed” and drags code speed down as dot speed is
slowed BELOW code speed?
73, -Patrick.

On Feb 4, 2021, at 11:34 AM, Les Kerr<EMAIL_ADDRESS>wrote:
@leskerr approved this pull request.
I've tried it and I can do everything I want to do, even though it's
clumsy
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <
https://github.com/MorseKOB/PyKOB/pull/262#pullrequestreview-583744742>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/ALTAYK6LAJEDICOHQXKMTWLS5LZDJANCNFSM4XCLJ2JA
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-773555063, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APHISTJ7D2QXANYT2Y5TM6DS5LZOFANCNFSM4XCLJ2JA
.

Hi Les,
The immediate update of the running MKOB settings based on config changes made it being tracked as a separate issue.  Ed has made some progress on that separately - I’m waiting for him to submit that but this change should have no impact on that (except perhaps for variable name changes - I did add an underscore to internal preferences variables but we’ll sort that out in the merge if it’s a factor).
I’ll see if Ed has any comments; otherwise I’ll merge the change sometime tonight or tomorrow.
73, -Patrick.

On Feb 4, 2021, at 11:58 AM, Les Kerr<EMAIL_ADDRESS>wrote:
Hi Patrick,
Yes, I pulled the latest commit (with the dragging) and tried it. And yes,
my brain has adjusted to it.
There may still be an untidiness. If I change my code speed from 25 to 30
on the main KOB window and then open the Morse Code tab. It shows code
speed 30 and dot speed 25. I thought you were going to have the dot speed
track the code speed when the code speed increases.
~Les
On Thu, Feb 4, 2021 at 11:37 AM Patrick Dirks<EMAIL_ADDRESS>wrote:

Hi Les,
Thanks for reviewing the change. I’d like to see if we can do better… what
do you find clumsy? Not manipulating Farnsworth spacing directly with speed
settings possibly inconsistent?  Should we try something different (perhaps as a separate
change)?
Did you try the latest commit, BTW, which drags “dot rate” up as code
speed goes above “dot speed” and drags code speed down as dot speed is
slowed BELOW code speed?
73, -Patrick.

On Feb 4, 2021, at 11:34 AM, Les Kerr<EMAIL_ADDRESS>wrote:
@leskerr approved this pull request.
I've tried it and I can do everything I want to do, even though it's
clumsy
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <
https://github.com/MorseKOB/PyKOB/pull/262#pullrequestreview-583744742>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/ALTAYK6LAJEDICOHQXKMTWLS5LZDJANCNFSM4XCLJ2JA
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-773555063, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APHISTJ7D2QXANYT2Y5TM6DS5LZOFANCNFSM4XCLJ2JA
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-773567553, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK7MVXPTXWIMWM4WH63S5L37NANCNFSM4XCLJ2JA.

I am working on the updates tonight and hope to finish them by EOD tomorrow.
I will say that the method of setting is somewhat backward to what I would do (I would set Text WPM and Spacing, if Spacing is NONE, then Dot speed doesn't matter. Otherwise, set Dot speed), but I'm a novice, so I defer to the more experienced telegraphers in the group. I guess that one wrinkle is that the main UI only has the Text WPM value. So you can adjust it there without being able to make any changes to Spacing or Dot Speed. So what happens as you increase/decrease the Text WPM value without having the ability to change either the Spacing or Dot Speed values from what they had been set to?

Hi Ed,
Actually I was just thinking tonight how there might be an alternative approach as well.
Let’s call the current approach “speed first” - you configure the code speed and the dot speed and the UI makes sure whatever you specify is sensible and physically possible.  Farnsworth spacing is disabled if not applicable; users can opt for “character” or “word” spacing if Farnsworth is needed.
The alternative would be, let’s call it “spacing first” - the Farnsworth spacing options are always available; if set to “None” then the dot speed either follows code speed 1:1 or is disabled altogether (probably more sensible), leaving just the code speed to tweak.  If you select “Character” or “Word spacing” the “dot speed” control comes alive as a separate control (still tied to code speed based on physical limits to make sure "dot speed” >= "code speed” at all times) but all Farnsworth controls are always available.  The UI still ensures only physically realizable settings can be entered.
I think it makes sense at any time to select “Character” or “Word” spacing and enable both controls.  If you have two different speeds up with, say, “Character” spacing selected and you change the Farnsworth spacing to “None”, presumably code speed and dot speed become the same.  Which speed should be used, though?  Should code speed increase to dot speed?  Or dot speed slow down to code speed?
If you permit me to bias the discussion: since the dot speed control is about to be disabled, I’d vote to leave that one unchanged and increase code speed to match dot speed - now that that control is “live” you can change the setting if you don’t like what it “jumped up” to?  I’d think it’d be awkward to have the dot speed suddenly change but then be disabled and you have to think to realize that you can get whatever you were hoping for by tweaking the OTHER speed setting (code speed).
Thoughts?  Want me to whip up an experiment on another branch?
73, -Patrick.

On Feb 4, 2021, at 11:05 PM, Ed Silky<EMAIL_ADDRESS>wrote:
I am working on the updates tonight and hope to finish them by EOD tomorrow.
I will say that the method of setting is somewhat backward to what I would do (I would set Text WPM and Spacing, if Spacing is NONE, then Dot speed doesn't matter. Otherwise, set Dot speed), but I'm a novice, so I defer to the more experienced telegraphers in the group. I guess that one wrinkle is that the main UI only has the Text WPM value. So you can adjust it there without being able to make any changes to Spacing or Dot Speed. So what happens as you increase/decrease the Text WPM value without having the ability to change either the Spacing or Dot Speed values from what they had been set to?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-773839576, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALTAYK6PLMOKTCR7O4CT5NDS5OKDPANCNFSM4XCLJ2JA.

I'm going to step back from this discussion and not try to guess what's best for most users. My comments will be limited to what works for me and what doesn't.
The fact of the matter is, I NEVER use Farnsworth (except for my feeds, which don't use the MKOB client anyway). I want to be able to turn Farnsworth off, and have it stay off no matter what I do with the WPM control on the main KOB window.
For me, the problem with the current branch is if I'm running with WPM at 24 (and spacing 'None') and I lower WPM to 22, 'Dot speed' stays stuck at 24 and spacing becomes 'Between characters'. This is unacceptable.
~Les

@pwdirks you say:

The alternative would be, let’s call it “spacing first” - the Farnsworth spacing options are always available; if set to “None” then the dot speed either follows code speed 1:1 or is disabled altogether (probably more sensible), leaving just the code speed to tweak.  If you select “Character” or “Word spacing” the “dot speed” control comes alive as a separate control (still tied to code speed based on physical limits to make sure "dot speed” >= "code speed” at all times) but all Farnsworth controls are always available.  The UI still ensures only physically realizable settings can be entered.

That is what I intended to suggest in my earlier comment in our email discussion (2/3/2021):

It might be a difference between an experienced telegrapher and a novice - but I think it would be more natural to me to allow specifying the 'Text' WPM and then have a 'Farnsworth' section. The spacing value selection would have a label of 'Farnsworth' with possible values of 'None'/'Between Characters'/'Between Words' (representing SPACING='NONE'/'CHAR'/'WORD'). The 'Dot Speed' selection would be within the Farnsworth section, but would only be enabled if the selected value of 'Farnsworth' isn't 'NONE'. If the 'Dot Speed' selection is enabled the value should initially be populated with the currently configured dot speed if it is greater than the entered text speed or with the entered text speed (not the currently configured text speed). Any dot speed value entered should be checked to validate that the entered value is greater than (or equal to) the entered 'Text Speed' value. Otherwise, that value shouldn't be allowed.

I like that approach because to me it is more intuitive for a new user of the application and I think it will also solve @leskerr 's situation where he sets 'SPACING=NONE' and controls the speed entirely with the 'TEXT WPM' value on the main GUI.
Also, this says it fixes #261, but that is the 'Local sounder' issue. I believe you mean #260.

I don't want to move this discussion to a separate pull request but I've created a separate branch to try the alternative.  Check out branch "pwd-260-preferences-with-new-Farnsworth-model" sometime and let me know how you find that model?
The only thing I had to make a call on was whether to keep dot speed >= code speed by bumping it up as code speed is increased as the previous change did.  I decided against that in favor of a one-time check when Farnsworth spacing is selected: at that point code speed will drop to match dot speed (previous value unchanged) as the separate dot speed control is enabled.
Please let me know what you think!

I changed the subject to refer to the correct issue #260.

The pwd-260-preferences-with-new-Farnsworth-model branch works for me.
~Les
On Sun, Feb 7, 2021 at 9:51 PM Patrick Dirks<EMAIL_ADDRESS>wrote:

I don't want to move this discussion to a separate pull request but I've
created a separate branch to try the alternative. Check out branch
"pwd-260-preferences-with-new-Farnsworth-model" sometime and let me know
how you find that model?
The only thing I had to make a call on was whether to keep dot speed >=
code speed by bumping it up as code speed is increased as the previous
change did. I decided against that in favor of a one-time check when
Farnsworth spacing is selected: at that point code speed will drop to match
dot speed (previous value unchanged) as the separate dot speed control is
enabled.
Please let me know what you think!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MorseKOB/PyKOB/pull/262#issuecomment-774887275, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APHISTIU3MQTOOYB4ZZIW6TS553WHANCNFSM4XCLJ2JA
.

Great!  @leskerr if this version works for you let me go ahead and merge pwd-260-preferences-with-new-Farnsworth-model in instead of this.  I'll should be able to do the merge later this evening.

Fixed by merging "Fix #260 by renaming speed controls and tying availability of separate 'dot speed' to Farnsworth spacing setting" branch instead.


Fatal error - engineio.server  - https://mysite.com is not an accepted origin. after upgrade

Rasa version:
Rasa 1.2.2
Rasa X version (if used & relevant):
Python version:
Python 3.6.8
Operating system (windows, osx, ...):
ubuntu server
Issue:
After run
pip3 install rasa --upgrade
I started to get the message:
engineio.server  - https://mysite.com is not an accepted origin.
Now my webchat is broken and I'm stuck !!!
It seems to be related to cors but I tried the command above and still it didn't work.
rasa run --m models/dialogue --enable-api --debug --endpoints endpoints.yml --credentials credentials.yml --cors '*'
Thanks !
Error (including full traceback):
2019-08-08 06:37:12 DEBUG    pykwalify.compat  - Using yaml library: /usr/local/lib/python3.6/dist-packages/ruamel/yaml/__init__.py
2019-08-08 06:37:19 INFO     engineio.server  - https://myip.com is not an accepted origin.

Command or request that led to error:
        rasa run --m models/dialogue --enable-api --debug --endpoints endpoints.yml --credentials credentials.yml --cors '*'

Content of configuration file (config.yml) (if relevant):

Content of domain file (domain.yml) (if relevant):

Thanks for the issue, @wochinge will get back to you about it soon!
You may find help in the docs and the forum, too 🤗

@EmannuelRoque On which machine is your Rasa server running and on which machine is the socketio input running?

I have the following structure:

webchat (hosted on site)
nginx proxy server (to generate https)
server running core (proxy redirects from internal board)
server running actions (internal card)

The chrome console shows this message:
chatb-ibegi.php?c=1041100906&p=363&t=bBsul:1 Access to XMLHttpRequest at 'https://bot.ctips.biz/ibegi/socket.io/?EIO=3&transport=polling&t=MnnxFS0' from origin 'https://resolveja.com' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'.   It worked fine in windows platform.
My environment is as follows:
Rasa version: Rasa 1.2.1
Rasa X version (if used & relevant):
Python version: Python 3.6.8
Operating system (windows, osx, ...): ubuntu server 18.0.4
Chat: webchat
I started rasa in ubuntu 18.0.4 to get the message:
engineio.server - http://jw.ngrok2.xiaomiqiu..cn is not an accepted origin.(http://jw.ngrok2.xiaomiqiu..cn is my ngrok tunnel for http://localhost:80).

I have solved the issues. Because the version of python-engineio is 3.9.2 in ubuntu, it will work fine after I downgraded python-engineio from 3.9.2 to 3.8.1.

@jwjuven Did you get any insights why python-engineio does not support this?

No Idea why is this happening, but I got the same issue..

Just updated to Rasa 1.2.3 and this started to happen to me too. Downgrading python-engineio to 3.8.1 worked for me.

We will release a new version 1.2.4 which should fix this. Could you please check if that resolves your issue?
The PR for that is https://github.com/RasaHQ/rasa/pulls?q=is%3Apr+is%3Aclosed

We will release a new version 1.2.4 which should fix this. Could you please check if that resolves your issue?
The PR for that is https://github.com/RasaHQ/rasa/pulls?q=is%3Apr+is%3Aclosed

Wonderful news! Any estimation about when this new release is coming out?

Already released https://pypi.org/project/rasa/1.2.4/ 🎉

This is what I got when i installed the latest rasa = 1.2.4 , please help me

@akelad Not entirely sure from the message of you and Tom in the PR, but did we have time to test it with 4.3.1?

Yes I tested it with that and the python-engineio method that’s pinned and it worked fine


The result on ResNet18 is frustrating

Hi Ildoo, thank you for sharing great code.
I tried ResNet18 on ImageNet, but the result is not good. Have you ever experimented on ResNet18, or do you have any suggestions?
Hyperparameters: SGD with linear lr=0.4, batch=1024, weight decay=1e-4, epochs=120.

method
top1

baseline
70.68

fast aa
70.22

The learning curves:

@iamhankai
There is a bug with learning rate scheduler with recent version of pytorch. I fixed it so you can try again.
Also I will look into this problem as soon as I can.
https://github.com/kakaobrain/fast-autoaugment/commit/2424224291616a2158a2265069ee95a78a2d13d9


UpdatePanelAnimationExtender - no animation when update is initiated by a control inside UpdatePanel (ChildrenAsTriggers)

See sample and description in https://github.com/DevExpress/AjaxControlToolkit/issues/162

Technical details:
The _triggerControlsClientID array contains only IDs of controls which are specified in the <Triggers> collection. Possible solution is to analyze whether _activeElement is located inside the UpdatePanel to which UpdatePanelAnimationExtender is attached. However this functionality would be new, and should be controlled by an additional option. I mark this ticket with the "enhancement" label.


L4-7 models

Below are the features added for L4-7 model
-> Added App under config for l4-7 configurations
-> Added TCP and HTTP model on App . The profile can be used in traffic and can be scaled for TCP and HTTP configs
-> Added Traffic in App for L4-7 traffic configurations such as client, server , endpoints and objectives configs
-> it resolves discussed functionality in issue: https://github.com/open-traffic-generator/models/issues/238
View the proposed changes using the redocly API viewer
Sample snippet
def configure_ixload(api):
    conf_obj = api.config()
    port_1 = conf_obj.ports.port(name="p1", location='<IP_ADDRESS>/1/1')[-1]
    port_2 = conf_obj.ports.port(name="p2", location='<IP_ADDRESS>/1/2')[-1]

    #rx and tx varible naming is to differentiate between client and server configs.
    rx_device, tx_device  = conf_obj.devices.device(name="client").device(name="server")

    rx_device.port_name = port_1.name
    tx_device.port_name = port_2.name
    #Client Configuration
    rx_eth = rx_device.ethernet
    rx_eth.name = "rx_eth"
    rx_eth.mac = "00:00:00:00:65:01"
    rx_eth.mtu = 1500

    rx_ipv4 = rx_eth.ipv4
    rx_ipv4.name = "rx_ipv4"
    rx_ipv4.address = "<IP_ADDRESS>"
    rx_ipv4.prefix = "24"
    rx_ipv4.gateway = "<IP_ADDRESS>"

    server_app = conf_obj.apps.app()[-1]
    #TCP config
    rx_tcp = server_app.tcp.tcp()[-1]
    rx_tcp.name = "tcp1"
    rx_tcp.keep_alive_time = 700
    rx_tcp.receive_buffer_size = 4096
    rx_tcp.transmit_buffer_size = 4096
    #HTTP Server config
    http_server = server_app.http_server.server()[-1]
    http_server.transport_name = rx_tcp.name
    http_server.name = "http_server1"
    http_server.http_version = "2.0"
    http_server.http_port = "8080"

    #HTTP client config
    tx_eth = tx_device.ethernet
    tx_eth.name = "tx_eth"
    tx_eth.mac = "00:00:00:00:70:01"
    tx_eth.mtu = 1500

    tx_ipv4 = tx_eth.ipv4
    tx_ipv4.name = "tx_ipv4"
    tx_ipv4.address = "<IP_ADDRESS>"
    tx_ipv4.prefix = "24"
    tx_ipv4.gateway = "<IP_ADDRESS>"

    client_app = conf_obj.apps.app()[-1]
    #TCP config
    tx_tcp = client_app.tcp.tcp()[-1]
    tx_tcp.name = "tcp2"
    tx_tcp.keep_alive_time = 700
    tx_tcp.receive_buffer_size = 4096
    tx_tcp.transmit_buffer_size = 4096

    #HTTP Client config
    http_client  = client_app.http_client.client()[-1]
    http_client.transport_name = tx_tcp.name
    http_client.name = "http_client1"
    http_client.http_version = "2.0"
    #Method.post will configure the post configuration for HTTP POST config.
    post_method = http_client.method.post()
    post_method.url= "http_server1"
    post_method.page = "/a.html"
    #Method.get will configure the post configuration for HTTP POST config.
    get_method = http_client.method.get()
    get_method.server= "http_server1"
    get_method.page = "/a.html"

    #Traffic configs
    traffic = client_app.stateful_flows.stateful_flow()[-1]
    traffic_cl = traffic.client()
    traffic_c_ep = traffic_cl.endpoints.endpoints()[-1]
    traffic_c_ep.ip_interface_name = tx_ipv4.name
    traffic_c_ep.ports.values = [80,81,82,84,85]
    traffic_cl.protocol = http_client.name

    traffic_sl = traffic.server()
    traffic_sl_ep = traffic_sl.endpoints.endpoints()[-1]
    traffic_sl_ep.dest.name = rx_ipv4.name
    traffic_sl_ep.dest.ports.values = [80,81,82,84,85]
    traffic_sl.protocol = http_server.name

    objt= traffic.objective.throughput()
    objt.value = 100
    objt.ramp_up_value = 30
    objt.sustain_value = 120
    objt.ramp_down_value = 30
    api.set_config(conf_obj)

Changes to HTTP (to separate out client and server properties) are still pending.

@ankur-sheth  Have added client and server properties separate.
Below are the snippet

@lemoncrust FYI.

@bortok @Vinod @ankur-sheth
Following are use cases and sample code snippet.

Emulation of HTTP Client and Server, HTTP client and server as endpoints.
Emulation of TCP  and TCP as endpoints.
One arm use case - Emulation of HTTP client with real server, HTTP client and real server as endpoints.

api = snappi.api(location="http://<IP_ADDRESS>:5000", verify=False)

config = api.config()
#use case 1 - Emulation of HTTP client and server
port_1 = config.ports.port(name="p1", location="<IP_ADDRESS>/11/3")[-1]
port_2 = config.ports.port(name="p2", location="<IP_ADDRESS>/11/7")[-1]
(device_3, device_4) = config.devices.device(name="device_3").device(name="device_4")
(eth_3,) = device_3.ethernets.ethernet(name="device_3.eth_3")
eth_3.connection.port_name = "p1"
eth_3.mac = "00:00:01:00:00:01"
(eth_4,) = device_4.ethernets.ethernet(name="device_4.eth_4")
eth_4.connection.port_name = "p2"
eth_4.mac = "00:00:02:00:00:01"
(ipv4_3,) = eth_3.ipv4_addresses.ipv4(name="eth_3.ipv4")
ipv4_3.address = "<IP_ADDRESS>"
ipv4_3.gateway = "<IP_ADDRESS>"
(ipv4_4,) = eth_4.ipv4_addresses.ipv4(name="eth_4.ipv4")
ipv4_4.address = "<IP_ADDRESS>"
ipv4_4.gateway = "<IP_ADDRESS>"

(app_1, app_2) = config.apps.app(name="app_1").app(name="app_2")
(tcp_1,) = app_1.tcp.tcp(name="tcp1")
tcp_1.keep_alive_time = 120
(tcp2,) = app_2.tcp.tcp(name="tcp2")
tcp2.keep_alive_time = 120

(http_client_1,) = app_1.http_client.httpclient()
http_client_1.client.name="HTTP_client1"
http_client_1.client.transport_name = tcp_1.name
http_client_1.client.command_timeout = 60
http_client_1.client.cookie_reject_probability = False
(m1,) = http_client_1.client.methods.get()
m1.server = "Traffic2_HTTPServer1:80"
m1.page = "/64k.html"

(http_client_2,) = app_2.http_server.httpserver()
#http_client_2.server.name="HTTP_server1"
http_client_2.server.name = "HTTP_server1"
http_client_2.server.transport_name = tcp2.name
http_client_2.server.http_port = 80

#Traffic configs

traffic = app_1.stateful_flows.statefulflow()[-1]
traffic.client.protocol = http_client_1.client.name
traffic_c_ep=traffic.client.endpoints.client()[-1]
traffic_c_ep.ip_interface_name = ipv4_3.name

traffic_c_ep.ports.values = [1]

traffic.server.protocol = http_client_2.server.name
traffic_sl_ep = traffic.server.endpoints.server()[-1]
traffic_sl_ep.dest.name = ipv4_4.name
traffic_sl_ep.ports.values = [1]

#Use case 2: Testcase for tcp as endpoints

port_5 = config.ports.port(name="p5", location="<IP_ADDRESS>/11/5")[-1]
port_6 = config.ports.port(name="p6", location="<IP_ADDRESS>/11/6")[-1]
(device_5, device_6) = config.devices.device(name="device_5").device(name="device_6")
(eth_5,) = device_5.ethernets.ethernet(name="device_5.eth_5")
eth_5.connection.port_name = "p5"
eth_5.mac = "00:00:01:00:00:01"
(eth_6,) = device_6.ethernets.ethernet(name="device_6.eth_6")
eth_6.connection.port_name = "p6"
eth_6.mac = "00:00:02:00:00:01"
(ipv4_5,) = eth_5.ipv4_addresses.ipv4(name="eth_5.ipv4")
ipv4_5.address = "<IP_ADDRESS>"
ipv4_5.gateway = "<IP_ADDRESS>"
(ipv4_6,) = eth_6.ipv4_addresses.ipv4(name="eth_6.ipv4")
ipv4_6.address = "<IP_ADDRESS>"
ipv4_6.gateway = "<IP_ADDRESS>"

(app_3, app_4) = config.apps.app(name="app_3").app(name="app_4")
(tcp_3,) = app_3.tcp.tcp(name="tcp_3")
tcp_3.keep_alive_time = 120
(tcp_4,) = app_4.tcp.tcp(name="tcp_4")
tcp_4.keep_alive_time = 120

#stateful_2 configs

stateful_2 = app_3.stateful_flows.statefulflow()[-1]
stateful_2.client.protocol = tcp_3.name
stateful_2_c_ep=stateful_2.client.endpoints.client()[-1]
stateful_2_c_ep.ip_interface_name = ipv4_5.name

stateful_2_c_ep.ports.values = [1]

stateful_2.server.protocol = tcp_4.name
stateful_2_sl_ep = stateful_2.server.endpoints.server()[-1]
stateful_2_sl_ep.dest.name = ipv4_6.name
stateful_2_sl_ep.ports.values = [1]

# Use case 3 - Testcase for One arm test

port_1 = config.ports.port(name="p7", location="<IP_ADDRESS>/11/7")[-1]
(device_7,)= config.devices.device(name="device_7")
(eth_7,) = device_7.ethernets.ethernet(name="device_7.eth_7")
eth_7.connection.port_name = "p7"
eth_7.mac = "00:00:01:00:00:01"
(ipv4_7,) = eth_7.ipv4_addresses.ipv4(name="eth_7.ipv4")
ipv4_7.address = "<IP_ADDRESS>"
ipv4_7.gateway = "<IP_ADDRESS>"

(app_5,)  = config.apps.app(name="app_5")
(tcp_5,) = app_5.tcp.tcp(name="tcp_5")
tcp_5.keep_alive_time = 120

(http_client_1,) = app_5.http_client.httpclient()
http_client_1.client.name="HTTP_client1"
http_client_1.client.transport_name = tcp_5.name
http_client_1.client.command_timeout = 60
http_client_1.client.cookie_reject_probability = False
(m1,) = http_client_1.client.methods.get()
m1.server = "<IP_ADDRESS>"
m1.page = "/64k.html"

#stateful_3 configs
traffic = app_5.stateful_flows.statefulflow()[-1]
traffic.client.protocol = http_client_1.client.name
traffic_c_ep=traffic.client.endpoints.client()[-1]
traffic_c_ep.ip_interface_name = ipv4_7.name
traffic_c_ep.ports.values = [1]

traffic_sl_ep = traffic.server.endpoints.server()[-1]
traffic_sl_ep.dest.ipv4_address = "<IP_ADDRESS>"

response = api.set_config(config)
print(response)

response = api.get_config()
print(response)


fix: Preserve Presentation Format

https://input-output.atlassian.net/browse/ATL-7666

coverage: 48.646% (-0.4%) from 49.009%
when pulling ee22c873f9224d31bbeca803e0dc6444aa56b49f on ATL-7666
into 91cb4e7f4371a651617265279a27fefe9551887c on main.


Concurrent

CSP Multiplatform Patch for Shiny
There are enough changes here to warrant a list

[x] Eliminate event deque
[x] Replace all event sends and recv with channel operations
[x] Expose channels as package scoped global variables
[ ] Witness the apocalypse because channels are exposed across API boundaries
[x] Remove structures responsible for storing a map or slice of multiple windows
[x] Separate mouse event from scroll event
[x] os/darwin: fix dst2src logic
[x] os/linux: fx dst2src logic
[x] os/darwin: remove double buffer from OpenGL
[x] os/windows: remove opengl pieces
[x] arch/amd64: enhance swizzle with avx2
[x] Delete widgets and other interesting things
[x] Simplify the codebase by flattening directories when possible
[ ] Write graphical tests
[x] Enumerate things that can be back-ported to the original shiny implementation in golang repo

Seems that I forgot to add the swizzle on Linux. Will do this next.


DEVX-2067: First draft of validation library for App Builder templates

Description
https://jira.corp.adobe.com/browse/DEVX-2067
https://wiki.corp.adobe.com/display/dxdevx/Validation+checks
NPM CLI tool that runs checks on metadata of NPM packages containing App Builder templates.
tv run-checks <link to NPM package>
tv run-checks https://www.npmjs.com/package/@adobe/generator-app-asset-compute

Motivation and Context
Meant to be integrated in template submission workflow in GitHub Actions for https://github.com/adobe/aio-template-submission
How Has This Been Tested?
Clone the repository locally and cd into folder.
npm init
npm test

Types of changes

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

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Let's add ESLint and some unit tests to cover this functionality. Please add Adobe copyright as well.
It makes sense to sync with @VladimirZaets and see what standard he's using for the API code.

Hi Olena, I've added ESLint and unit tests.

Let's add ESLint and some unit tests to cover this functionality. Please add Adobe copyright as well.
It makes sense to sync with @VladimirZaets and see what standard he's using for the API code.

Hi @lenaorobei , I have added ESLint, unit tests, and Adobe copyright headers.

@VladimirZaets Hi, I submitted a commit that made improvements based on some of your suggestions. I decided to save your other suggestions for a later refactor.


Update Feed Registry Page

Fixes #709 referring to this page: https://docs.chain.link/docs/feed-registry/
Adds TOC and Overview
Adds separate page for functions

Made a few reorganization changes
Rebased to main

Rebased to main and resolved conflicts


SCRD-5901 Add package-lock.json

So that users of both yarn and npm will have the same experience, we should keep the package-lock.json current with the yarn.lock file.

So now we will have two different generated files from two different build tools, both generated from the third file, package.json. This feels like it's going to be problematic to keep all 3 in sync.

This can mostly be done automatically if you are a yarn user, added postinstall script to keep package-lock.json up to date.

I understand the idea here, but I wonder if we're making a bit of a dependency mess to solve a problem we havent run into so far...


Change UI start page

@matthiasr

In lieu of a bigger redesign, can we just merge this for now, after applying this comment: https://github.com/prometheus/prometheus/pull/1039#discussion_r38184595
/graph is definitely a better default than /status.

Done, merging.
I also don't think that our opinion is to skewed here. The initial request came from someone using Prometheus as a non-developer, I see many people using it the same way, including ourselves when doing non-development work.
We can always return to a more status-like default later on.


Next Generation Assistant does not install

Device name: Motorola Moto G Power 2021
Rom name: Bliss 17.0 (Unnoficial)
Android version: 14
Pixelify version: 3.0

Bug Description:
Choosing to install the Next Gen Assistant does not work, no errors are shown.


Update Publish to IIS doc

Addresses https://github.com/aspnet/Docs/issues/1359

[x] Short description of the web.config file but that primarily relies upon a link to ASP.NET Core Module Configuration Reference to explain the details of configuration.
[X] Short description of the publish-iis tool and project.json setup for it.
[X] Brief description of how to use app_offline.htm.
[ ] Remark that Azure Apps have their own doc and link to it early in this doc.
[X] Add IIS options settings and what they do: services.Configure<IISOptions>(options => { ... });
Additional troubleshooting tips at the top of the Common errors section:

[X] Running the app directly to narrow down IIS-module problem versus app problem.

Additional Common errors to test and list along with the rest

[X] dotnet.exe is not on the PATH
[X] Confirm that having %LAUNCHER_PATH%/%LAUNCHER_ARGS% placeholders match the currently listed behaviors for bad processPath/arguments, respectfully.
[X] MIA .NET Framework on the server (Docs/#1354)

[x] Swap image showing how to reach Basic Settings of the AppPool

I skipped "Remark that Azure Apps have their own doc and link to it early in this doc." It's plainly evident that this doc exists in the Publishing and Deployment section, so I don't think it bears mentioning.

@Rick-Anderson Ok, I think we have ourselves a draft here.

Squish commits, @GuardRex :sunglasses:

@PureKrome I wait until after we go through drafts and I get a little squirrel.

Squish commits, @GuardRex :sunglasses:

You probably mean "squash"? :trollface:

:shipit:

@Rick-Anderson I can rebase if you like. No worries either way. :smile:

I used the magic green button with "Squash and merge" that seems to have worked. Thanks for the update.

@Rick-Anderson Oh, ok, cool. I like :sparkles: magical buttons :sparkles:.


Fixes the cache option's maxAge header

Hi there,
The --cache option incorrectly handles the time passed as argument: the send package (called stream in the code) expects the parameter maxAge to be a time in milliseconds whereas serve expects the command line argument in seconds.
In the current version of the module, the conversion from seconds to milliseconds isn't done. This PR simply multiplies the entry value by 1000.
Clément

@clementprdhomme Let's expect the value in milliseconds! I think that would be much more straight-forward. Would be great if you could adjust the usage information!


WIP: use rewriter to modify wrapping

So far this PR should cover all manual edits to the wrapped code in RasterIO.jl, namely:

CPLErr was added manually: solved by wrapping cpl_error.h
Replace ::Cint with ::Integer as in https://github.com/wkearn/RasterIO.jl/commit/7da9573cca21ae33e4a87b1d7305869db9126abe
Let wrap_gdal.jl comment out some lines in common.jl, as in https://github.com/visr/GDAL.jl/commit/ad44facd91c944ed7b7dee8a01f03a5f1d283444

This rewriting functionality is quite powerful, but I am not yet sure of all useful applications or what to do with those. Some ideas:

padfSrcGeoTransform::Ptr{Cdouble}: rewrite to accept Vector{Float64}
pszDstWKT::Ptr{UInt8}: rewrite to accept AbstractString

Another extreme would be to omit types in function signatures altogether, like is done in CUDArt.jl. We could also convert all function names to lowercase for instance. But I'm currently not convinced these last two are good ideas. Any input or other ideas welcome.

Error checking all functions that return a CPLErr is probably also a good idea, this is also used in the wrap_cuda.jl that I linked.

:100:
It'll be good to figure out the appropriate names for the enums too, e.g. https://github.com/visr/GDAL.jl/blob/rewriter/src/clang/common.jl#L227 versus https://github.com/wkearn/RasterIO.jl/blob/master/src/clang/gdal_cdefs.jl#L55

I'm not sure about going all the way in removing all the types from the function signatures, even if it has been unnecessarily restrictive on a number of occasions

A few other things have snuck into this PR, because I need to start testing/using this API to find the parts that need improvement.
For instance, GDALGetMetadata returns a Ptr{Ptr{UInt8}}, though I think this should really just return a Dict, see the code here. Looking at the GDAP API Tutorial under Techniques for Creating Files, it shows the C and C++ examples calling a method CSLFetchBoolean that we haven't wrapped, whereas in the Python example a dict is returned as well.

I'm really happy with the progress you're making here.

A few other things have snuck into this PR, because I need to start testing/using this API to find the parts that need improvement.

I personally prefer to

keep the original GDAL functions generated by Clang too (we should still replace Cint by Integer, etc, but not to the extent of rewriting the pointers into julian objects). I might write a scraper to fetch documentation from the gdal website as docstrings at some point. If it's cluttering the namespace, we can put them all in a submodule. That way we don't need to resort to ccall-ing the original GDAL functions, and can have the API documentation at the REPL.
Provide higher-level julia functions (auto-generated or handwrapped) that take-in and emit julian types (Dict/Vector/UTF8String/etc), that we'll have to write documentation for. We can either do multi-dispatch on the original GDAL names (which might be confusing), or provide our own set of julian function names.

I think it'll be great if we can do the error-checking at the low-level GDAL layer, but it sounds like a tall order for the rewrite phase though. Probably better to do another PR for error-checking.

For instance, GDALGetMetadata returns a Ptr{Ptr{UInt8}}, though I think this should really just return a Dict, see the code here.

Sure. But my preference will be for it to not overwrite the original GDAL function (see above).

Thanks for your comments. It is good to decide where to draw the line between the low-level GDAL interface and the higher-level Julia functions. I'm not trying to take the step from low-level to high-level directly in this PR.
The way I see it, this is all still the low-level GDAL interface. It's good to have the whole thing available for if somebody wants to use a function that is not in the higher-level API. This means it should be directly usable from Julia, without it being too awkward.
At the same time, I agree the higher level API should be written entirely from function calls to the lower level API, no ccalls. Therefore I understand you don't want too much rewriting, but for me it's still not completely clear where you want to draw the line:

keep the original GDAL functions generated by Clang too (we should still replace Cint by Integer, etc, but not to the extent of rewriting the pointers into julian objects)

What I currently have in mind for the low-level API:

Keep all original function names intact
In general, keep the original function signatures intact, except for:

Replacing basic data types: input/output strings, not Ptr{Uint}; loosen Cint to Integer; OrderedDict instead of Ptr{Ptr{UInt8}}

Don't replace main GDAL types, which are typealiased Ptr{Void}.

For the case of GDALGetMetadata returning a Ptr{Ptr{UInt8}}, why would you want to also retain a version returning Ptr{Ptr{UInt8}}? I'm asking since I don't think we want to get three API layers, one low-level without any rewriter, a second 'nice' low-level, autogenerated from the first, and a high-level API. Or is that what you would prefer?
Regarding the low-level error checking, with https://github.com/visr/GDAL.jl/commit/a8c750b4db101550c7266ed0d9dcf4e2fc5b83f3 we are hooked into GDAL's internal error checking. If an error is raised, the type, code and message gets sent to our Julia function to deal with. This should take care of most low-level error handling needs, and we can change the Julia function when we're not happy. On top of that I added the C_NULL return check for selected return types, because some things GDAL doesn't consider an error that we may want to be an error. I could remove this automatic C_NULL check though.

For the case of GDALGetMetadata returning a Ptr{Ptr{UInt8}}, why would you want to also retain a version returning Ptr{Ptr{UInt8}}? I'm asking since I don't think we want to get three API layers, one low-level without any rewriter, a second 'nice' low-level, autogenerated from the first, and a high-level API. Or is that what you would prefer?

I think that's what I was hinting at. I guess I wasn't thinking of having a high-level API in this package. You might be able to convince me otherwise though.
What I have in mind:
module GDAL

    # re-written, i.e. "nice" low-level
    function getasyncstatusbyname(name::String)

    module capi
        # directly from Clang, i.e. low-level
        ...
        function GDALGetAsyncStatusTypeByName(arg1::Ptr{UInt8})
        ...
    end
end

I don't think it's the responsibility of this package to provide a nicer API than that -- that sounds like the job of downstream packages e.g. RasterIO.jl, or OGR.jl or any other package that wants to provide a nice way of working with GDAL.
You might ask -- why have module capi at all? Some reasons off the top of my head:

Sometimes it might be better to just get the pointer output, and pass it on to another GDAL function, without having to load it into a bytestring/array/etc. There might be people who want to bypass that step, and not load objects into julia's ownership (to reduce GC churn), which our "nice" low-level won't allow for.
It allows us to document with docstrings (fetched directly from GDAL's documentation) what users otherwise have to search through gdal's online documentation for (when ccall-ing).

I don't think it's the responsibility of this package to provide a nicer API than that -- that sounds like the job of downstream packages

This package will also need to provide the build scripts, and test that the wrappers are working etc, for (potentially) different GDAL versions in the future. I think that sounds like enough responsibility on it's own, without having to also worry about the friendliness of the package for end-users?

Ok that's clear. I understand the possible benefits of having a capi submodule now. I'll get rid of most of the rewriter stuff, and instead reapply (and intensify) it to generate the GDAL module. Though I don't think I'll have much time available this week.
I also think the true high-level API is better suited for other packages, it was a 'thin' wrapper after all.

Sorry for coming so late into this thread, thanks for starting this. I really like the model proposed by @yeesian. However, can we still keep the error handling as it is right now or do you think this is too high-level?

@meggart thanks for the comments. I addressed them in the last commit. Also stopped the rewriting and put everything in a submodule C. Sorry it's such a mess right now, I will squash later. With the error handling, do you mean the checknull function? Or the error handling? I removed the checknull for now, but we could consider bringing it back.

What's left here to wrap things up? Might I be able to help in any way?

I think it is indeed best to wrap up this PR such that we can think about
the next steps that need to be done. Are you mostly satisfied with what's
in here? If so I can squash and merge tomorrow.
On Fri, 20 Nov 2015 20:04 Yeesian Ng<EMAIL_ADDRESS>wrote:

What's left here to wrap things up? Might I be able to help in any way?
—
Reply to this email directly or view it on GitHub
https://github.com/visr/GDAL.jl/pull/3#issuecomment-158496055.

Yup, I've checked it out, and it works for me. @meggart?

I can test this evening.

Looks good for me, too. Please merge when you are ready

:tada:


Timestamp/Value Storage Used in Bytes

I'm using BoltDB to store timeseries data and found that the data I'm storing takes about 50 Bytes/Record. This is a bit more than I expected - how can I get this down?
From this timeseries DB benchmark it looks like InfluxDb (which I think at one point was running on BoltDB) can get down to 2.2 bytes per point.
Each record is:
(Key)Timestamp : (Value)[]byte("true")
timestamp := uint32(time.Date(2016, 1, 1, 0, 0, 0, 0, time.UTC).Unix())
key := make([]byte,8)
binary.BigEndian.PutUint32(key,timestamp)
after the write...timestamp++
With the above, I write 100,000,000 records in 240 seconds (416,667 recs/sec) and use about 5,000,000,000 bytes
bolt stats gives me:
Aggregate statistics for 1 buckets
Page count statistics
Number of logical branch pages: 14874
Number of physical branch overflow pages: 0
Number of logical leaf pages: 1234567
Number of physical leaf overflow pages: 0
Tree statistics
Number of keys/value pairs: 100000000
Number of levels in B+tree: 5
Page size utilization
Bytes allocated for physical branch pages: 60923904
Bytes actually used for branch data: 30224544 (49%)
Bytes allocated for physical leaf pages:<PHONE_NUMBER>
Bytes actually used for leaf data:<PHONE_NUMBER> (49%)
Bucket statistics
Total number of buckets: 1
Total number on inlined buckets: 0 (0%)
Bytes used for inlined buckets: 0 (0%)

Setting bucket.FillPercent = .95 brought my usage down to 28 bytes per record.
Any way to get this even lower?

@louisto did you manage to find some way to reduce the data or did you end up selecting a different db technology for your time series storage?


Feature Request: Importing data types from sample datasets

Feature idea:
take a sample datasets of JSON and attempt to derive the data types from the observed values across it's numerous records automatically.
Background:
I'm currently struggling with creating data types that match the data I load from the Run...
Rather than records being loaded, I get a number of empty rows that match the row count of the input file.
I don't know what I'm doing wrong, since there's no feedback in the UI or my kie-Sandbox podman container console.
Was thinking this could be much easier if the data types screen could have an "Auto detect data type from sample JSON dataset file", where I could feed it 10 to a 100 JSON records and let an algorithm observe what data types match for the values observed in each field.
I'm sure something like this is much easier said than done, but I think it would make getting started a lot easier.

As a follow-up to the blank rows I observed, I think I now know why I see this:

I created a Data type structure called SimpleTX (id,vendor,amount,description,category_id all of type any), created a DMN Input Data put it's data type properties to SimpleTX
Next I uploaded JSON data, the data matches the structure of SimpleTX, however there's mention of the Input name or data type in json records

[{"id":1,"amount":1485.19,"category_id":2,"vendor":"Skaboo","description":"Compactor"},
{"id":2,"amount":493.37,"category_id":97,"vendor":"Voolith","description":"Backhoe"},
{"id":3,"amount":2855.0,"category_id":80,"vendor":"Gabspot","description":"Scraper"}]

This creates blank rows
When I do a Download inputs my JSON looks like:

[
  {
    "InputData-1": {},
    "id": 1,
    "amount": 1485.19,
    "category_id": 2,
    "vendor": "Skaboo",
    "description": "Compactor"
  },
  {
    "InputData-1": {},
    "id": 2,
    "amount": 493.37,
    "category_id": 97,
    "vendor": "Voolith",
    "description": "Backhoe"
  },
  {
    "InputData-1": {},
    "id": 3,
    "amount": 2855,
    "category_id": 80,
    "vendor": "Gabspot",
    "description": "Scraper"
  }
]

So the data is there, but not in the format DMN was expecting, so this is my bad as a user...

@deftdawg thank you so much for the suggestion. We will triage this and follow up this feature request here: https://issues.redhat.com/browse/KOGITO-7543


Tests and cleanup of bootstrapping

When I started writing the section of the paper on the toy model MISTIS and the bootstrapping, I found that a few details that were a bit confusing. I think this may have led to some confusion in the stuff that Abel was doing. To make sure that the behavior in the code matches what I write in the paper, I’m writing tests for the bootstrapping.
This may also lead to some changes in the behavior of the FullBoostrapping, and possibly in the MISTISNetwork. I think I’ve occasionally seen bad initial conditions in the MISTIS ipynb test, causing annoying failures. I’m hoping that this PR might fix that. At the very least, it will give a nice bump to our test coverage, and ensure that our paper matches our code!

[x] Tests for the first_traj_ensemble
[x] Tests for the sampling ensembles
[x] Change output of FullBootstrap & Bootstrap to file/stream based (so we can write to /dev/null or stdout depending on what we want)
[x] Tests when extra interfaces exist
[x] Tests when forbidden states exist
[x] Tests when bootstrapping fails from too many attempts
[x] Add numpydoc docstrings to FullBootstrapping

Okay, I don't think I'm going to change anything else in this (for this PR). I'll make some minor modifications to the MISTISNetwork in a separate PR.
This is ready for review. There's a little cleanup, but mostly new tests (and a big jump in test coverage!)

Lg;wm