Root element is not rendering

Hyperscript's root element is not rendering allways. Because snabbdom.js line 184 ... oldCh = oldVnode.children, ch = vnode.children;......
Problem:
 var vnode = h('div#id.two.classes', [
        h('span', 'This is text')
    ]);
    patch(document.getElementById('container'), vnode);

output as

This is text

But may be:

This is text

If I understand this correctly it is the same thing that @raine recently brought up in the Gitter room.
Basically Snabbdom does not apply the information found in the selector for the root vnode. It assumes that that information is already correct. The solution is to make sure that the assumption is correct.

Needs to be documented.

Needs to be documented.

I certainly agree!
Another option is to create a new element based on the root vnode when patch is initially run against a raw element and then replace the raw element with the created root element. I like to have behavior that is intuitive and doesn't surprise people. The only bad thing about doing that is that after patch the DOM element passed to patch would no longer be in the DOM. But if you really need it you could easily dig it out of the vnode returned by patch.

On above example root is meant to "div#id.two.classes" not the "#container" element.  It may be misunderstood.
In the rendering output div#id.two.classes information disappears.
In this case, users can manage itself but normally users waits to:
h('div#myId.myClass', ['This is text']) => This is text but snabbdom only outputs => This is text

On above example root is meant to "div#id.two.classes" not the "#container" element. It may be misunderstood.

I think so. The element passed to patch should be an empty element matching the root vnode. So you should do this:
patch(document.getElementById('id'), vnode);

Is that unclear in the documentation?

https://github.com/paldepind/snabbdom#inline-example seems contrary to this strategy. id = container element is not matching to root vnode (h('div#id.two.classes'....)

I've now done this:

Implemented the behavior described here. This should be more expectable.
Updated the inline example. It was indeed confusing and misleading.
Updated the documentation of patch. This should clarify this as well as the fact that vnode's will have to be reused.

@ismail-codar and @raine, does this solve the issues and is the documentation clear enough now? Please let me know if this is still not adequate.

Quite enough. :+1:

I absolutely disagree with idea that h('div#myId.myClass', ['This is text']) should become
This is text

Things specified in first argument are selector, but I've no complete understanding of such selectors at all because of hierarchical JSX Components idea. Is it possible to create true component wrapper to allow snabbdom to behave like React Components?

@avesus

Things specified in first argument are selector

The first argument to h is not a selector. It's a description of the element including its tag name, its id and it's static classes.

Is it possible to create true component wrapper to allow snabbdom to behave like React Components?

I certainly think it is possible to build such a thing on top of Snabbdom.


fix client package

correct build
correct paths
change name of injection interface to prevent confusion
rm generic get-port export
add createPraxTransport export

some more client package work in another PR but this is enough for the demo

working demo with this client package here https://github.com/turbocrime/nextjs-penumbra-client-example

i'm going to add a changeset patch bump to bech32m to calm down the peer dependency, and then merge this


[BUG] : After page load or reload, a border appears around nav elements upon hovering

Description
If the mouse hovers over the nav elements after the webpage is loaded or reloaded, a white border appears around the hovered element. This behavior stops after one of the nav elements is clicked.

Expected Behavior
A border should only appear on a nav element after it is clicked.

@abinjohn123 This is not happening in my side

@abinjohn123 This is not happening in my side

I'm testing the link attached in the repo
I tried both Chrome(Version 106.0.5249.119 (Official Build) (64-bit)) and Firefox (105.0.3 (64-bit))

@abinjohn123 This is not happening in my side

I'm testing the link attached in the repo I tried both Chrome(Version 106.0.5249.119 (Official Build) (64-bit)) and Firefox (105.0.3 (64-bit))

I am only testing on brave browser, but its working perfectly for me, no problem.

Hi @abinjohn123 yeah you can fix it. @prakhartiwari0 I'm using firefox and this is a bug clearly.

Thank you 👍🏽


MSFT_xAdcsWebEnrollment - Updated to IsSingleInstance model - Fixes #7

This also contains the following changes:
* MSFT_xAdcsWebEnrollment: Created unit tests based on v1.0 Test Template.
                           Update to meet Style Guidelines and ensure consistency.
                           Updated to IsSingleInstance model. **Breaking change**
* MSFT_xAdcsOnlineResponder: Update Unit tests to use v1.0 Test Template.
                             Unit tests can be run without AD CS installed.
                             Update to meet Style Guidelines and ensure consistency.

I updated both MSFT_xAdcsOnlineResponder and MSFT_xAdcsWebEnrollment to match the Style Guidelines as they both had large numbers of violations. I also updated the Tests to match the v1.0 Unit Test templates. The unit tests can now also be run on a Non-Server OS without AD CS installed.
I did not change the MSFT_xAdcsCertificationAuthority resource, but it does still require some work (unit tests, style guidelines violations) to bring it in line. I will work on that at some point, but that will be a separate PR. I may also be able to add Integration tests for these resources as well.
I did not feel comfortable committing the changes to this without resolving the above issues as well.

This change is

Also fixes #16

Reviewed 7 of 7 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

DSCResources/MSFT_xAdcsWebEnrollment/MSFT_xAdcsWebEnrollment.schema.mof, line 1 [r1] (raw file):
Please do not change the module or class version in a resources per the contribution guidelines

DSCResources/MSFT_xAdcsWebEnrollment/MSFT_xAdcsWebEnrollment.schema.mof, line 6 [r1] (raw file):
Should we consider leaving name in as a `Write' property for better compatibility?

Examples/Config-SetupActiveDirectory.ps1, line 253 [r1] (raw file):
consider updating to the cmdlet ( you could file an issue)  set-wsmanquickconfig -force
Example usage

Comments from Reviewable

Review status: 4 of 7 files reviewed at latest revision, 3 unresolved discussions.

DSCResources/MSFT_xAdcsWebEnrollment/MSFT_xAdcsWebEnrollment.schema.mof, line 1 [r1] (raw file):
Sorry about that. For some reason I thought we had discussed updating the class version - but I think it was for a different resource change. Reverted.

DSCResources/MSFT_xAdcsWebEnrollment/MSFT_xAdcsWebEnrollment.schema.mof, line 6 [r1] (raw file):
I was thinking all configurations using this resource will have to be updated anyway to add the IsSingleInstance so removing the name wouldn't be an issue.  My sense of neatness would say to leave it out - but I'll completely go with what you think is best on this.

Examples/Config-SetupActiveDirectory.ps1, line 253 [r1] (raw file):
Good catch!
Fixes #16

Comments from Reviewable

Reviewed 3 of 3 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

DSCResources/MSFT_xAdcsWebEnrollment/MSFT_xAdcsWebEnrollment.schema.mof, line 6 [r1] (raw file):
I don't think I have a strong opinion either way.  I was wanted to make sure it was discussed.

Comments from Reviewable


[Azure_IoT_Central_ESP32] Failed decoding SAS key

Describe the bug
"Failed decoding SAS key" occurs when trying individual enrollments of SAS with sample code Azure_IoT_Central_ESP32.
To Reproduce

Generate SAS Key with openssl rand -base64 64 command.
Set SAS Key to IOT_CONFIG_DEVICE_KEY

Expected behavior
The SAS Key generation command openssl rand -base64 64 uses what is written in the Azure IoT Central document.
I am generating a 64 byte key, but it seems that Azure_IoT_Central_ESP32 only supports up to 32 bytes.
I think you should increase ECODED_SAS_KEY_BUFFER_SIZE in the sample code to 64 or change the Azure IoT Central documentation.
Screenshots
Generate SAS key:
$ openssl rand -base64 64
JX5MSR2bjrEpY3siZjcMxaTDcZ//7OPjdmER024lETmj8mZVXHVMvHE/9ELwqomI
tb3TRkmTzdbHbe1ASsR6Lg==

Log:
1970/1/1 00:00:00 [INFO] Connecting to WIFI wifi_ssid seeed2g
..
1970/1/1 00:00:01 [INFO] WiFi connected, IP address: <IP_ADDRESS>
1970/1/1 00:00:01 [INFO] Setting time using SNTP
......
2022/9/28 11:48:07 [INFO] Time initialized!
2022/9/28 11:48:07 [INFO] Azure IoT client initialized (state=2)
2022/9/28 11:48:07 [ERROR] Failed decoding SAS key.
2022/9/28 11:48:07 [ERROR] Failed creating mqtt password for DPS connection.
2022/9/28 11:48:07 [ERROR] Failed initializing MQTT client.
2022/9/28 11:48:07 [ERROR] Azure IoT client is in error state.

Yes, the default autogenerated keysize in IoT Central is 32 bytes, but also supports (and DPS) 64 byte device keys. Will update the sample with longer 64 byte key.

https://github.com/Azure/azure-sdk-for-c-arduino/pull/30

Issue resolved with https://github.com/Azure/azure-sdk-for-c-arduino/pull/30


forever+pool test

currently failing
Closes https://github.com/request/request/issues/1511

Thanks for submitting this test @devTristan I'll merge it once the new release of forever-agent get published :+1:

Thanks for all of your help @simov :)

Now passing.


Add Databricks UC Volume Object Store

What does this PR do?

Add support for Databricks Unity Catalog Volumes to upload and download data to UC

What issue(s) does this change relate to?
N/A
Before submitting

[x] Have you read the contributor guidelines?
[ ] Is this change a documentation change or typo fix? If so, skip the rest of this checklist.
[x] Was this change discussed/approved in a GitHub issue first? It is much more likely to be merged if so.
[ ] Did you update any related docs and document your change?
[x] Did you update any related tests and add any new tests related to your change? (see testing)
[x] Did you run the tests locally to make sure they pass?
[x] Did you run pre-commit on your change? (see the pre-commit section of prerequisites)

Testing

Added unit tests

 python -m pytest tests/utils/object_store/test_uc_object_store.py

Manually tested this with a sample script as below:

import composer.utils.file_helpers as fh
import tempfile
import os

def main():
    print('Testing object_store_test')
    uri = 'uc://Volumes/ml/automl/test-volume/'
    object_name = 'composer-file.txt'

    localfile1 = os.path.join(tempfile.gettempdir(), 'file1.txt')
    localfile2 = os.path.join(tempfile.gettempdir(), 'file2.txt')

    # cleanup
    if os.path.exists(localfile1):
        os.remove(localfile1)
    if os.path.exists(localfile2):
        os.remove(localfile2)

    # write something to file1
    with open(localfile1, 'w') as f:
        f.writelines('This is a sample composer file\n')

    object_store = fh.maybe_create_object_store_from_uri(uri=uri)

    # upload
    object_store.upload_object(object_name, localfile1)

    # download
    object_store.download_object(object_name, localfile2)

    # get size
    print(f'object_size={object_store.get_object_size(object_name)}')

    # validate that the contents of file1 and file2 are the same
    with open(localfile1, 'rb') as f:
        filecontent1 = f.readlines()
    with open(localfile2, 'rb') as f:
        filecontent2 = f.readlines()
    assert filecontent1 == filecontent2

if __name__ == '__main__':
    main()

Call the above script as below:
source venv/bin/activate; DATABRICKS_HOST=<host> DATABRICKS_TOKEN=<token> python manual-test.py

File is seen in UC Volume:

Verified contents of the file:

Integration testing
DATABRICKS_HOST=<host> DATABRICKS_TOKEN=<host> python -m pytest -v -m remote --log-cli-level 10 tests/utils/object_store/test_uc_object_store.py::test_uc_object_store_integration

@dakinggg @karan6181 I addressed your comments. This is ready for another pass. The existing sdk does not have support for listing files. I am waiting to hear back from the deco team that owns the SDK to see if there is an easy workaround to address this. I will follow up on this once I hear back. The rest of the code should be ready for another pass. Thanks!

This looks good to me! Can you please create a jira for adding log_model support? You can put it in the genai runtime project and the mosaic finetuning private preview epic.
and @eracah can you please do a pass and approve?

Thank you @dakinggg I added jira tickets for:

log_model support: https://databricks.atlassian.net/browse/MCLOUD-3130
list_objects support: https://databricks.atlassian.net/browse/MCLOUD-3130

Looks pretty good. Can you add a small e2e test, where you actually train for a few batches and save to UC then load from it. It can be a manual test. Here's an example

Thank you @eracah I updated the PR with the e2e test and also fixed some bugs that I found on the way. UC Volume treats the first 4 directories of the path as the bucket root so we have to handle cases where object_name is passed relative to bucket root eg: .credentials_validated_successfully as well as cases where the full path like Volumes/ml/mosaicml/test-volume/checkpoints/1695720685-tourmaline-wolf/test-model.pt is passed. I added tests and comments to document this behavior. PTAL. cc: @dakinggg  too

This PR is adding really slow tests to CPU.   I was downloading a 1Gb file in my tests 🤦🏾♂ which is why this was slow. Fixing it now. Thank you!


inject windowAppBar into Workspace

Codecov Report

Merging #21 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #21      +/-   ##
==========================================
+ Coverage    78.1%   78.15%   +0.04%
==========================================
  Files          30       30
  Lines         475      476       +1
  Branches       38       38
==========================================
+ Hits          371      372       +1
  Misses         89       89
  Partials       15       15

Impacted Files
Coverage Δ

...ery-elasticsearch-app/src/components/Workspace.tsx
80% <100%> (+5%)
:arrow_up:

Continue to review full report at Codecov.

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


Rich presence API?

Will the new rich presence API be available here?
https://discordapp.com/rich-presence
https://discordapp.com/developers/docs/rich-presence/how-to
Best regards

Rich Presence being added to Discord.Net.Rpc would be nice. Without it, the Rpc lib will be incomplete, and not to mention the official RPC SDK wraps an unmanaged library. I personally feel it would be easier for .NET/Unity game developers (like me) to integrate Rich Presence into their game, and I might consider opening a PR regarding this.
Dylan P
HOO @ Ultz


ARROW-8927: [C++] Support dictionary memo in CUDA IPC ReadRecordBatch functions

Adds support for dictionary memo in ReadRecordBatch for CUDA IPC, passing the memo directly to the ipc::ReadRecordBatch function. This allows one to handle record batches with dictionaries, though it might be worth adding some tests around using SerializeSchema as well, so we can have the complete CPU + GPU IPC path in place -- let me know and I'd be happy to do so.

I think this is ready for a first look. The python side could probably some tests. I'm also interested in adding some functions which would pack both the schema, memo, and CUDA handle in IPC messages, similar to ipc::RecordBatchStreamReader, but that could probably be a separate PR.
I also didn't attempt backwards compatibility here. Let me know if that's desirable in these endpoints. It probably wouldn't be too hard to do, though the error you get if you don't have a dictionary memo is a little vague.

@alexbaden Are you willing to update this? Otherwise I may take a look.

I'd be interested in trying to add it into the record batch stream reader -- the idea being you could send both CPU data and GPU data pointers in a single serialized object with a single call. We could then replace this code https://github.com/omnisci/pymapd/blob/91520f021b2a92cc2a6affeb0e5084641e0637d7/pymapd/_parsers.py#L200 with roughly a single call. I'm more comfortable in C++  so I might try it there, first (replacing this code: https://github.com/omnisci/omniscidb/blob/a84b42d324af2f4406abaaf83c465ce11c6039ab/Tests/ArrowIpcIntegrationTest.cpp#L378)

@alexbaden I'm not sure I understand what you have in mind. Could you elaborate?

I'd like to have an object similar to RecordBatchStreamReader that could read the schema, IPC handles, and dictionary memo from a single buffer, and a corresponding writer of course.

Well, can't you just use BufferReader and BufferOutputStream? Am I missing something?

Maybe with this PR that is possible, I'll have to explore a bit once this is merged. The concern is more around getting the order of the dictionary, etc right in the message stream so that when you go to unpack everything you don't end up with dangling dictionary references to old memory locations, which is what I had to work around with the previous API.

Ok, I'm gonna merge this then. Thank you!


par: improve logger

Resolve #4336

Creating different debugMessage groups for different functionalities of the TritonPart frame work. These groups are based on the flow described in the paper & the way the functionalities are actually implemented (the groups are briefly described in the new docs file).

Converting a lot of reports, infos and warns to debugMessages.

MPL2 will inform the user that PAR is being called. I chose to add this info, because I thought it would be odd to just pop a PAR message in the middle of macro placement flow.

Please address the test failures

@maliberty The failure in regression tests was due to some messages that needed suppression. As this messages were related to files' names, I refactored the several name file printing that was going on in the top level TritonPart framework functions.


[ISSUE] Unable to update user store name using a PUT request to the user store endpoint

Describe the issue:
Trying to update the name of a user store using the /userstores/{userstore-domain-id} endpoint results in the following error.

However, I am able to successfully update the user store description using the same endpoint.

@Kanapriya
As per the source code of userstore REST API, there is a comment that userstore domain name is not allowed to be updated from UI. https://github.com/wso2/identity-api-server/blob/master/components/org.wso2.carbon.identity.api.server.userstore/org.wso2.carbon.identity.api.server.userstore.v1/src/main/java/org/wso2/carbon/identity/api/server/userstore/v1/core/ServerUserStoreService.java#L130
did we come to a conclusion during the design review to not to allow users to update userstore domain name from REST API?

Yes, we decided not to update the user store type and user store domain name in the design review at that time as we need to regenerate the type and domain id. But we can revisit and add this capability.

@thivi @thanujalk
do we have a blocking requirement to update userstore domain name? Can't we delete the userstore and add again with the required new domain name as a work-around?

The userstore domain name can be made read-only on the frontend if that's the case. Since the carbon console allows it, I thought the same thing should be possible through the dev portal as well.

The userstore name was made readonly in the edit view.
https://github.com/wso2/identity-apps/pull/682


(FACT-1459) Specify config file on command line

This commit contains all the necessary changes to the Travis and Appveyor scripts to build cpp-hocon as part of Facter, so it will have to be merged before the actual settings logic.

CLA signed by all contributors.

Closing in favor of https://github.com/puppetlabs/facter/pull/1383.


unresolved dependency on 'debug_tools'

I'm trying to get this to work as I was interested in the semantic line breaking, but there seems to be a missing dependency on a package called debug_tools that is not resolved:
File "/Users/leon/Library/Application Support/Sublime Text 3/Packages/WrapPlus/wrap_plus.py", line 14, in <module>
    from debug_tools import getLogger
ImportError: No module named 'debug_tools'

(tried both via a git clone in the Packages directory and by adding the repo URL to Package Control)

I was able to install your fork as well by changing the dependencies. Pardon my ignorance, but why don't you simply change this in your version?

Because the name DebugTools mix up with my other packages which are also named PascalCase.
The "conversion" would be dependencies as lower_case and packages as CamelCase.
As well I could easily keep the name DebugTools, but they could also easily accept the name change.


502 on Register page

Steps to reproduce:

go to dev.volontulo.pl
click on "Załóż konto"
fill the form & submit

Not occuring anymore.


Tuesday 24-10-2023  roll call

Roll Call!
Leave a comment with these two things:

A summary of your study using only emojis
Something you'd like to share, anything goes! (within respect)

emoji cheat sheet

Good morning 🌞

hi

GOOD MORNING

Good morning

Good morning!

Good morning everyone 🌹

Present

Good morning

😀

present


Smooth zoom to point

Implements a smooth version of the zoom to point feature.

How this PR works:
The previous zoom to point implementation was very jumpy:

 Example

This PR aims to fix that issue. The reason for the issues in the previous implementation, was due to fact that it only ever dealt with full, whole, grid cells. This meant that as you zoomed and a new grid cell was needed or not needed, it must appear or disappear in its entirety, which was the cause of the "jump".
In order to solve that problem, we can instead deal with fractional grid coordinates, e.g (2.5, 1.3), rather than (2, 1). Lets say the difference in grid cells after zooming has changed by (2.5, 1.333). This means we need to shift all placed objects by 2 full grid cells + half a grid cell in the x direction, and 1 grid cell + 1/3 of a grid cell in the y direction. Additionally, we also need to offset the grid by the fractional part of the change (50% of a grid cell in the x direction, 33% of a grid cell in y direction in the example above).
Current tasks:

[ ] Move code that offsets LayoutObject.Position outside of OnMouseWheel and into RenderObjects (the fractional part of the offset should be the same for both the Position of an object and the Grid). Completing this should simplify the resolution of many of the other issues.
[ ] Tidy up code
[ ] New placements do not align to the grid
[ ] Test toggling the zoom feature on/off (can be properly tested once new placements are aligned).
[ ] Test saving/loading - file sizes could explode as we are saving fractional rather than whole numbers for the position property. Could be solved by resetting to the nearest grid cell, and might be solved automatically when fixing the previous issue.
[ ] Write tests for CoordinateHelper.ScreenToFractionalGrid

Closing this PR for now as I think a different approach is required.


Linux image for Python3 not running on GitLab CI Runner

Enviroment
GitLab CI Runner in Docker mode with bash shell and current cdrx/pyinstaller-linux:python3 image.
Problem description:
Some CI servers like the current GitLab CI Runners will execute scripts in docker containers in a non-interactive way. In this mode the .bashrc will not get executed which is discussed in detail in this StackExchange thread. Therefore the changes added to the .bashrc in the current Dockerfile for the linux python3 image are ignored. This results in errors like: "pip command not found", because obviously the changes to $PATH are ignored...
Problem delimitation:
I did not explicitly check how other CI solutions currently behave regarding interactive/non-interactive shell code execution.

I wanted to share my workaround for this issue (I haven't run this in GitLab CI but I belive the issues are similar).
docker run -v "$(pwd):/src/" -v pyenv:/root/.pyenv -ti --rm --entrypoint /bin/bash cdrx/pyinstaller-linux -c '\
  export PS1="$$" && \
  source ~/.bashrc && \
  PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install -s 3.6.7 && \
  pyenv rehash && \
  pyenv shell 3.6.7 && \
  python --version && \
  pip install --upgrade pip && \
  pip install -r requirements.txt && \
  pyinstaller --clean -y --dist ./dist/linux --workpath /tmp package.spec'

Some notable things are happening:

-v pyenv:/root/.pyenv creates a docker volume to store the pyenv environment so Python does not have to be installed every time the container runs. You may want to change the volume name (pyenv before the :) to the actual name of your project (eg. -v foobar-pyenv:/root/.pyenv).

export PS1="$$" basically gives us a shell prompt which will then allow source ~/.bashrc to run properly. The first line of .bashrc checks that $PS1 is non-empty.


[🐞] pnpm qwik add added wrong shell scripts in  README.md

Which component is affected?
Qwik Runtime
Describe the bug
I have created my README.md and using pnpm in my README but once i have added any new adapter i.e netlify it will add p before my all scripts now the problem is suppose i have a command pnpm run dev it becomes ppnpm run dev.
Reproduction
https://github.com/harshmangalam/qwik-x
Steps to reproduce

Add any new adapter
Verify the README file

System Info
System:
    OS: macOS 13.3.1
    CPU: (8) arm64 Apple M1
    Memory: 121.77 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.16.0 - ~/.nvm/versions/node/v18.16.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.16.0/bin/yarn
    npm: 9.5.1 - ~/.nvm/versions/node/v18.16.0/bin/npm
    pnpm: 8.6.12 - ~/Library/pnpm/pnpm
  Browsers:
    Chrome: 117.0.5938.132
    Safari: 16.4

Additional Information
No response

Closed by #5275


Fixed some bugs in the new AF_PACKET implementation

I found some bugs in the AF_PACKET code that I introduced yesterday. I have
fixed and tested these fixes.
Signed-off-by: Levi Gross<EMAIL_ADDRESS>

This is a follow up from https://github.com/google/gopacket/pull/295. I have fixed the issues with this update. I am really sorry for the PR headache

No worries, happens to the best of us :)
If you have the inclination, we should probably set up an integration test for afpacket, something like https://github.com/google/stenographer/blob/master/integration_test/test.sh


License for the code

Hi,
Under which license, are you distributing this code ? I am interesting to reuse few of your classes.
Thanks

Hey, Good to know that you like to reuse few things. I added Apache License for the project. Feel free to use them (some points to be aware of that this project is an year old and done real quick)

Thanks Sirdhar.  I only use few classes related to protostuff.
On Friday, January 30, 2015, Sridhar Gnanasekaran<EMAIL_ADDRESS>wrote:

Hey, Good to know that you like to reuse few things. I added Apache
License http://www.apache.org/licenses/LICENSE-2.0 for the project.
Feel free to use them (some points to be aware of that this project is an
year old and done real quick)
—
Reply to this email directly or view it on GitHub
https://github.com/srid99/protostuff-example/issues/1#issuecomment-72127965
.

No problem. Have fun!


Method IProblem.getModel() is missing

I understand that the class Model is in choco-solver, but it is an issue.
One could define a generic IProblem interface.
Beside, the indentation is weird in the github viewer.

Anyone can define it own implementation of such a method but since pf4cs should not depend on a specific solver, there is no good reason to create it.
We could use generics, but I'm not enclin to that.

see #2


vue create can only create two files named Readme.md and package.json

Version
4.4.6
Reproduction link
https://github.com/vuejs/vue-cli
Environment info
(node:20512) UnhandledPromiseRejectionWarning: Error: Command failed: wmic os get Caption

Steps to reproduce
the foler strcture is error, there are only two files and miss the script
What is expected?
I expecte to create a vue project
What is actually happening?
When I input 'vue create xxx', the info show that I create a project succesfully, but the foler only has two files and miss the structure. I cannot open the serve

What is your full Environment info?

What's the content of package.json?
Could you run echo $NODE_ENV (or echo %NODE_ENV% if you are using cmd) to see if it's incorrectly set to production?

Closing due to inactivity.


Allow tokens to be used for login

This adds a new method Client.loginWithToken which logs the bot in using just a token. See #159

Do you need me to test?

I've tested it a little already but more testing can't hurt.


Dateformat not working for french Pascalcase months

Hi,
I'm unable to parse a string containing pascal case french month.
So I've implemented a little unit test to explain that better:
test("Testing date format", (){
    final locale = 'fr_FR';
    initializeDateFormatting(locale).then((_){
      String pattern = "MMMM yyyy EEEE dd";
      String data = "Novembre 2018 Dimanche 25";
      Intl.withLocale(locale, (){
        DateTime datetime = DateFormat(pattern).parse(data);
        expect(datetime, isNotNull);
        expect(datetime.month, equals(11));
        expect(datetime.year, equals(2018));
        expect(datetime.day, equals(25));
        expect(datetime.weekday, equals(7));
      });
    });
});

This tests will fail with this message:
FormatException: Trying to read MMMM from Novembre 2018 Dimanche 25 at position 0
The error occurs at line:
DateTime datetime = DateFormat(pattern).parse(data);
After investigating the Intl code, it seems that only lowercased months are available for french.
In my point of view, parsing "Novembre 2018", "NOVEMBRE 2018" and "novembre 2018" shall be parsed successfully and shall lead to the same result.

The case don't work for English too. It seems like the parsing logic is case sensitive. This works:
import 'package:intl/intl.dart';

void main() {
  String dateStr = '11/Jul/21'; // <------- note the case of the month
  print(new DateFormat("dd/MMM/yy").parse(dateStr)); //<------- Works!
}

But this doesn't work:
import 'package:intl/intl.dart';

void main() {
  String dateStr = '11/JUL/21'; // <------- My month name is completely uppercase
  print(new DateFormat("dd/MMM/yy").parse(dateStr)); // <------- Fails
}

Coming from Python, it was not a problem there. IMHO, this parsing logic needs upgrade.

The problem lies here, I think:
https://github.com/dart-lang/i18n/blob/main/pkgs/intl/lib/src/intl/date_format_field.dart#L475
  int parseEnumeratedString(StringStack input, List<String> possibilities) {
    var results = [
      for (var i = 0; i < possibilities.length; i++)
        if (input.peek(possibilities[i].length) == possibilities[i]) i // <-- Exact match only
    ];
  //....

If there was an option of string comparer to be passed as argument, then it could work.
E.g.
import 'package:intl/intl.dart';

void main() {
  final compareIgnoringCase = (String a, String b) => a.toUpperCase() == b.toUpperCase();
  String dateStr = '11/JUL/21';
  print(new DateFormat("dd/MMM/yy").parse(dateStr, compareIgnoringCase));
}

Or, the code gets improved by comparing text ignoring the case implicitly, i.e.:
if (input.peek(possibilities[i].length).toUpperCase()( == possibilities[i].toUpperCase()


No response due to jupyter_core>=5.7.0

When running lc_wrapper with jupyter_core>=5.7.0, it seems to stay in Connecting and not proceed.

With version 5.6.1 it looks like it would work.


Fixes #575: Some example quick-starts should get packaged into the patch...

....

Can one of the admins verify this patch?

Again, prod repositories are already defined here. You can verify the correct download like this
> git fetch fuse wildfly-camel-2.2.0.redhat-620036
> git checkout FETCH_HEAD
>  rm -rf ~/.m2/repository/org/wildfly/camel/
>  mvn clean install -pl itests/distro
>  mvn clean install -f examples -Dts.all

Building the distro in step four should not be necessary, which #594 is about.

Camel examples should be put in the already existing ${eap.home}/docs/examples directory.

This is still waiting to have two items fixed mentioned in the comments

remove repository defs
move to docs/examples

rejected


AG Grid Table View and Share Feature Integration

AG Grid integrated into Project
FE Component for User's Articles Table View created
Component Integrated with Share WF

@elenakot Document looks good. It will likely have merge conflicts as we work up the pull request queue. We can review it tomorrow morning.


Only apply imagePullPolicy to plugins if instructed

Adds a new option which allows the user to specify whether or
not to apply the imagePullPolicy to all plugins and override
their stated values.
This is important since even the default value was overwriting
explicit values in the plugins leading to confusing behavior.
Techinically a breaking change for someone who was running
sonobuoy CLI with the --image-pull-policy flag to overwrite explicit
values. They will now need to add the --force-image-pull-policy flag
to obtain the same behavior. This makes all modifications to plugins
explicit via some option rather than this one being implicit.
Fixes #1652
Signed-off-by: John Schnake<EMAIL_ADDRESS>Release note:
Users will now need to add the --force-image-pull-policy flag if they want the plugins to use the same imagePullPolicy as the Sonobuoy aggregator/worker containers.  Sonobuoy will respect the imagePullPolicy stated in the plugin definitions otherwise.

Not a big change but just lots of golden files being tweaked.
Added a field to the config object and plumbed it through to a flag. Gated logic on that value.


Exposing file control operations

We have a use case where it would be useful to be able to run file control operations (i.e. sqlite3_file_control()).  Our primary use will actually be to set PERSIST_WAL, also mentioned by another user in #1029.  More specifically, we're looking manage the database in such a way that it is safe to use with litestream, which as discussed in https://github.com/benbjohnson/litestream/issues/510 relies on the wal being persisted.
We understand that we could achieve this with a custom build, but this can also be set at runtime using sqlite3_file_control(), which of course would be a more convenient alternative.  There's some prior art to setting file control operations at runtime, such as the sqlite3 CLI's .filectrl command and the go driver's SetFileControlInt().
Would the project be open to a contribution that exposes this interface through a method on Database?

better-sqlite3 is designed to be immune to segfaults and undefined behavior, regardless of what the user does, but [erhaps this could be enabled for unsafe mode.


Implement QuickLinks component

PR for Task #9 to replace PR #28

Merging. Final fixes to be done later on.


How to make a patch for Nintendo Switch? nifm patch is good

@lsp199308 If and when I get time, and when I'll bother to do the guide(s), It'll be in the repository on how to.

@lsp199308 I have published a basic guide detailing the process to create nifm patches, although very delayed.


RC Test: Circuit Construction Kit: DC & Virtual Lab 1.0.0-rc.1

In https://github.com/phetsims/QA/issues/51#issuecomment-337291139 @phet-steele indicated we are ready for CCK RC.  In https://github.com/phetsims/circuit-construction-kit-dc/issues/166 @mattpen and I published the following links:
https://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc/1.0.0-rc.1/circuit-construction-kit-dc_en.html
https://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc-virtual-lab/1.0.0-rc.1/circuit-construction-kit-dc-virtual-lab_en.html
Here are the iframe links:
https://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc-virtual-lab/1.0.0-rc.1/circuit-construction-kit-dc-virtual-lab_en-iframe.html
https://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc/1.0.0-rc.1/circuit-construction-kit-dc_en-iframe.html
Test Matrix
DC and DC Virtual Lab use the same SHAs so if maintenance needs to be performed, it can be performed on both.
Please also verify

[x] stringTest=double (all strings doubled)
[x] stringTest=long (exceptionally long strings)
[x] stringTest=X (short strings)
[x] stringTest=rtl (right-to-left)
[x] stringTest=xss (test passes if sim does not redirect, OK if sim crashes or fails to fully start)
[x] showPointerAreas (touchArea=red, mouseArea=blue)
[x] Full screen test
[x] Screenshot test
[x] iframe test

If any new issues are found, please note them in https://github.com/phetsims/circuit-construction-kit-common/issues and reference this issue.
This is the first RC test for Circuit Construction Kit: DC or Virtual Lab, so I presume it will need "the works", please add checkboxes for additional tests as necessary.
Also assigning @ariel-phet for prioritization and scheduling and to see if there is anything else to add to this issue.

@samreid are we planning to send this sim to LoL? If so, I'll need to prepare descriptions and icons.

It is a question for @kathy-phet.

@samreid are we planning to send this sim to LoL?

Too late! We already tested on LoL. 😄
@samreid this RC is done, ready for the next.

Yes, this will go to lol.
Sent from my iPhone
On Oct 17, 2017, at 12:46 PM, Sam Reid <notifications<EMAIL_ADDRESS>wrote:
Assigned #55https://github.com/phetsims/QA/issues/55 to @kathy-phethttps://github.com/kathy-phet.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/phetsims/QA/issues/55#event-1297540896, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AE3FZO5ip7vFD3cvDIBlN5EDi_VVYMgEks5stPX1gaJpZM4P8oe2.

Thanks, we'll continue in https://github.com/phetsims/circuit-construction-kit-dc/issues/169


Option to use Fetch Time as Pubdate

Hi found this project due to Miniflux, great work.
There are several feeds I subscribe to which post new articles with past pubdates. The problem with that is that they get lot in my feedreader because I focus on articles which are only added on the top. Is there an option or which lines in your code would I need to change to replace the "updated" field not with the parsed pubdate of the feeds but with the time it was fetched?
Thank you in advance
Andy

Sorry, I discovered that this is much more an individual matter than a particular thing which should be pursued in the development of this project.


Snap based install of .NET can lead to segmentation faults.

Source: https://github.com/dotnet/runtime/issues/51322#issuecomment-890306629 and https://github.com/dotnet/runtime/issues/3775#issuecomment-534263315 and https://github.com/dotnet/runtime/issues/3464
Also, according to this comment Snap issues have been closed "to reflect current priorities."
Shouldn't this be reflected in the documentation? Why do the docs provide instructions on installation via snap when it isn't a "current priority" and it doesn't work?

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

ID: a40005eb-f935-d50d-10ce-c1e0a47ea70e
Version Independent ID: 91f4a9b7-09d0-f18e-af4a-c0af28a8948f
Content: Install .NET on Linux with Snap - .NET
Content Source: docs/core/install/linux-snap.md
Product: dotnet
Technology: dotnet-install
GitHub Login: @adegeo
Microsoft Alias: adegeo

Associated WorkItem - 45520

Thank you for letting me know. I'll prioritize getting a note added to the article.

Note: Opened an internal discussion on this.

At this point we're still waiting. I'm going to close this for now and when new info about snap becomes available, I'll reopen this.


clair: 4.0.0 -> 4.0.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/quay/clair/releases.
meta.description for clair is: "Vulnerability Static Analysis for Containers"
meta.homepage for clair is: "https://github.com/quay/clair"
meta.changelog for clair is: "https://github.com/quay/clair/blob/v4.0.1/CHANGELOG.md"
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 4.0.1 with grep in /nix/store/vqhj0wa0p4x6is6125q11fi7wi3f1lxl-clair-4.0.1

directory tree listing: https://gist.github.com/b8084f333830a44bc43cdad39c41c072

du listing: https://gist.github.com/c7ac04e86550832bfc98ac2a0b0ef9b0

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
clair

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vqhj0wa0p4x6is6125q11fi7wi3f1lxl-clair-4.0.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A clair https://github.com/r-ryantm/nixpkgs/archive/d3309d84e0a25cf955c175f028931e6c6ac063f1.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vqhj0wa0p4x6is6125q11fi7wi3f1lxl-clair-4.0.1
ls -la /nix/store/vqhj0wa0p4x6is6125q11fi7wi3f1lxl-clair-4.0.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

clair

Maintainer pings
cc @marsam @kalbasit for testing.

Result of nixpkgs-review pr 113256 run on x86_64-linux 1

1 package built:

clair


Find Connected components in an undirected graph

Description
Description
We can find connected components ina undirected graph using both bfs and dfs , in this I am using dfs. By applying dfs to all the unvisited vertex.
Domain
CPP
Type of Contribution
Addition
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

/assign


WFNEWS-1158

@ssylver93 Changes look OK. Were you able to test this in Docker or locally to ensure we're not seeing any problems with interrupts when the connection closes?


🌐 CORS Problem: Cross-Origin Resource Sharing

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
You encountered a CORS issue while making a web request from your application.
Description: 🔄
CORS (Cross-Origin Resource Sharing) is a security mechanism that restricts web resources (e.g., APIs) from being accessed by web pages originating from different domains. It prevents potential security risks by enforcing the same-origin policy.
However, if your application tries to make a request to a different domain, the browser enforces CORS and blocks the response from the server. This restriction is in place to protect users' data and prevent unauthorized access.
Expected Behavior
Solution: ✅
To resolve the CORS problem, you can take one of the following actions:
1⃣ Server-Side Solution: Implement CORS headers on the server-side to allow cross-origin requests. Configure the server to include the appropriate Access-Control-Allow-Origin header in the response, specifying the allowed origins.
2⃣ Proxy Server: Set up a proxy server to bypass CORS restrictions. The proxy server acts as an intermediary between your application and the remote server, making the request on your behalf. This way, the same-origin policy is not violated.
3⃣ JSONP: If the remote server supports JSONP (JSON with Padding), you can use it as an alternative to bypass CORS. JSONP is a technique that allows cross-domain requests by dynamically adding a

The problem was solved by configuring the Firebase service.


gyves, disinterment (logical-conflict)

This pull request was generated by the 'mq' tool

/trunk merge


Doesn't honor search-invisible

The desired behaviour is when search-invisible is set to nil, don't search inside the invisible area.
There are cases that the user don't want to search in the hidden area. One example is dired-mode with git-annex font lock enabled, file symlinks targets are hidden sha256 strings, it makes no sease to search those hidden symlinks. Another use case is org mode with partly folded headings.

Thanks for pointing out this problem. I don't have time right now to implement a solution, but I would be able to review and merge a pull request adding logic to handle the case. It should be rather similar to https://github.com/raxod502/ctrlf/issues/23, porting logic over from Isearch for compatibility.


[feature] Add clipping plane support in Volume Rendering

Hi, @NicolasRannou . I want to clip the model by a plane. I found that the material of volume is 'MeshStandardMaterial' in your demo #2 which clip brain. Using 'MeshStandardMaterial' on volume can be success to clip the model in my demo.
However, the material of volume in demo #6 is 'ShaderMaterial'. I add the attribute of clippingPlanes on the material is invaild. I guess some errors occur on the 'ShaderMaterial'.
I want to know how to clip the volume in demo #6. Looking forward to your reply.

Related to #218


⚠ Bofrost.at has degraded performance

In 21ccc17, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1892 ms

Resolved: Bofrost.at performance has improved in 3f4e74d.


Implement an information schema table to inspect flow node's internal state.

What problem does the new feature solve?
Provide an information schema table like cluster_info to inspect flow node's internal state. Things like assigned tasks, handled rows etc can be reported in this way.
What does the feature do?

[ ] Implement a system table for flow node

Implementation challenges
No response

This reminds me that the allocation (task to flownode) info is also requested in meet-up

yes, we also need to track lifecycle and status of tasks.

Can I work on it?

Sorry for the delay...
FlownodeManager should contain the info we need. The requested system table needs to read that info from FlownodeManager and then construct a temporary table from those data like other tables in information_schema.
Are you still interested in this task?

Yes, let me take it.


Dashboard variables

Add support for dashboard variables. Depends on #42
For example here,
df = px.DataFrame(table='http_events', start_time=__time_from)
df['cluster'] = '$clusters'

The $clusters will get replaced with the dashboard variable value.

Is there a reason we use a different syntax here ($ vs __ prefix) than the time/interval special variables? I would recommend using the same approach for both

Also, looks like the commit history might be including some other stuff

Is there a reason we use a different syntax here ($ vs __ prefix) than the time/interval special variables? I would recommend using the same approach for both

This is actually replacing the variables directly in Grafana UI. Previously we handled the __time and other variables ad hoc, but grafana can do it natively from the UI. The benefit of doing that is that you can use any dashboard variable in your scripts, even user defined variables. So we can handle the common case like __start_time, __end_time, but also any other variable such as cluster or pod in the future.
The Grafana UI actually just replaces the $ variables before sending to backend, so we can remove that logic there completely.

Also, looks like the commit history might be including some other stuff

I will rebase on main in a moment.

So you're saying that the $ replacement is done by Grafana, not manual logic on our side.
In that case, we might want to support $start_time, $interval, and $end_time in addition to __start_time, __interval, and __end_time, so that we can move toward a consistent experience with $ only.  I think that would be better than the user having to know both ways, going forward, but we can still support the old way for backwards compatibility
We can therefore update our Grafana plugin to support both and update our example scripts to use $

So you're saying that the $ replacement is done by Grafana, not manual logic on our side.
In that case, we might want to support $start_time, $interval, and $end_time in addition to __start_time, __interval, and __end_time, so that we can move toward a consistent experience with $ only. I think that would be better than the user having to know both ways, going forward, but we can still support the old way for backwards compatibility
We can therefore update our Grafana plugin to support both and update our example scripts to use $

The equivalent with Grafana global variables are $__interval, $__from and $__to. I think these should be familiar to users because Grafana mentions these variables directly in their documentation.


Missing orentation

The horizontal orientation is missing. please add this. Thank you.

Landscape mode is supported by default. A horizontal preview will be added in readme.


chore: Improve ObjectHashAggregate fallback error message

Which issue does this PR close?

Closes https://github.com/apache/datafusion-comet/issues/845
Rationale for this change

Before this PR, we see errors such as:
ObjectHashAggregate [COMET: ObjectHashAggregate is not supported]

With this PR, we see information about which aggregate expression is not supported:
ObjectHashAggregate [COMET: unsupported Spark aggregate function: bloom_filter_agg]

What changes are included in this PR?

How are these changes tested?

@parthchandra fyi, another small improvement in reporting unsupported expressions


Feature request: Support to throw an RequestException

First of all, thank you for this amazing package!
Love the additional assertions you can do on top of the guzzle handler stack!
With the current Guzzle handler you're allowed to set a RequestException in the handler stack
Would be nice to have some functionality to support this in the current package.
See original Guzzle docs and look for  https://docs.guzzlephp.org/en/stable/testing.html

It's already possible.
If you don't "care" much about the assertion, you just want to throw an exception on a specific request, you use something like this
      (new GuzzleMockResponse('random-path'))
                    ->withBody(['status' => 'running'])
                    ->withStatus(SymfonyResponse::HTTP_OK)
                    ->withAssertion(function() {
                        throw new ConnectException('Empty server reply', new Request('GET', '/random-path'));
                    })
                    ->once(),


Undefined method method_name in rubocop 0.59.2

Rubocop Performance does not work with latest rubocop 0.59.2
undefined method `method_name' for s(:lvar, :evaluator):RuboCop::AST::Node
Did you mean?  method
/Users/fritz/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/rubocop-performance-0.0.0/lib/rubocop/cop/performance/size.rb:60:in `array?'
/Users/fritz/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/rubocop-performance-0.0.0/lib/rubocop/cop/performance/size.rb:50:in `eligible_receiver?'
/Users/fritz/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/rubocop-performance-0.0.0/lib/rubocop/cop/performance/size.rb:44:in `eligible_node?'
/Users/fritz/.asdf/installs/ruby/2.5.1/lib/ruby/gems/2.5.0/gems/rubocop-performance-0.0.0/lib/rubocop/cop/performance/size.rb:30:in `on_send'

Thanks for trying the edge code. rubocop-performance 0.0.1 has been released.
RuboCop Performance is still work in progress, but please let me know if you noticed anything :-)


Flash Controller: Excess data being erased

The auto-generated code from OpenTitan includes this:
// Number of bytes per page
#define FLASH_CTRL_PARAM_BYTES_PER_PAGE 2048

Indicating that there are 2048 bytes in each page.
If FLASH_CTRL.MP_BANK_CFG ERASE_EN_0 and ERASE_EN_1 aren't enabled we should be able to erase a page at a time. So we should be able to erase only 2048 bytes in an operation.
What I'm seeing when running on the Nexys Video FPGA is that the page erase operation at address 0x200c0000 is instead erasing from 0x20040000 upwards. This seems to be wrong. Even if I was erasing an entire bank (0x80000 bytes) this is still erasing the previous bank as well.
I don't see anything in flash_ctrl_test to ensure that other data isn't erased and due to https://github.com/lowRISC/opentitan/issues/7728 I am unable to test this in flash_ctrl_test. It does look like too much data is being erased on a flash operation though.

do you see similar behavior when running verilator? it wouldn't be super surprising if there is a bug here, the flash controller logic is not super well verified yet.
one thing i should point out first though (and maybe this is related to the fpga problem you're observing), due to the nexysvideo fpga not being big enough, we actually need to run some scripts first to reduce the flash size.   Please see here.
So when you build locally, you'll also have to make sure to run that script first before doing anything. This is all related to issu #7707, please feel free to have a look.
What might be happening is that because the flash is shrunk, when you erase 0x200c0000, it actually thinks its 0x2004000.
However, the fact the flash controller does not error seems to be a bug itself.  I can help take a look at this.

I haven't checked on Verilator.
Thanks for pointing that out. Is it worth swapping over to the ChipWhisperer CW310 then to fit more of the design?
Do you know what the flash size is reduced to?
I'm not building the bistream locally (just using one from the CI).
If the flash is smaller then I'm expecting that might be the issue.

yeah i think it is the issue.
the flash is reduced by half.
So instead of one bank at 0x2000_0000 and one at 0x2008_0000, it is now
0x2000_0000 and 0x2004_0000.
So when you erased 0x200c_0000, due to the flash not checking the address
is completely out of bounds, it actually wraps to 0x2004_0000, and likely
erased the incorrect data (i think).
Yes switching to CW310 will give you the "most" complete system. I haven't
looked into exactly how cw310 isw built, but it is meant to be the FPGA
that can hold the entire design.
On Thu, Aug 12, 2021 at 10:40 PM Alistair Francis @.***>
wrote:

I haven't checked on Verilator.
Thanks for pointing that out. Is it worth swapping over to the
ChipWhisperer CW310 then to fit more of the design?
Do you know what the flash size is reduced to?
I'm not building the bistream locally (just using one from the CI).
If the flash is smaller then I'm expecting that might be the issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/issues/7730#issuecomment-898204634,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSUI6N7Z3DU37BR43YTT4SV3RANCNFSM5CC2ML6A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

Argh! That is exactly the issue!
I tried changing the addresses, but they were always above 0x2008_0000. It didn't even occur to me it would wrap around.
Thanks for figuring that out so quickly. I have been pulling my hair out trying to figure out what is going on.
I'll close this as you have opened https://github.com/lowRISC/opentitan/issues/7731
Thanks again for the help!

Unfortunately flash_ctrl IP is not verified, so bugs in the design are expected. Apologies for the inconvenience.


Add GitHub Actions

Remove Travis and add GitHub Actions for testing.

@ldko @somexpert This is ready for review.


module PolymorphicEmbed.HTML.Component is not loaded and could not be found

I can't find a way to use the Component or Form modules, it seems to not be compiled. I tried importing the module as the doc says, even in  lib/shop_web/components/core_components.ex, but raises the message below:
error: module PolymorphicEmbed.HTML.Component is not loaded and could not be found. This may be happening because the m
odule you are trying to load directly or indirectly depends on the current module

PolymorphicEmbed.HTML.Helpers seems to be compiled:
iex(1)> Code.ensure_loaded? PolymorphicEmbed.HTML.Form
false
iex(2)> Code.ensure_loaded? PolymorphicEmbed.HTML.Component
false
iex(3)> Code.ensure_loaded? PolymorphicEmbed.HTML.Helpers
true

Elixir version: 1.16.1 (compiled with Erlang/OTP 26)
Phoenix version: 1.7.12
Polymorphic Embed version: 4.0.0

@SteffenDE could you have a quick look at this? 🙏🏻

@mathieuprog You didn’t make a new release since https://github.com/mathieuprog/polymorphic_embed/pull/97, right? So my quick guess is that it’s this.

Actually I did. @rubynho you're not on the latest version.

Great, that works. Thanks! The version spec in the documentation could be "~> 4.0" to allow minor version updates.

Okay done: https://github.com/mathieuprog/polymorphic_embed/tree/master?tab=readme-ov-file#installation
👍

Hello, I'm still getting this error even I'm on v.5.0.0 same using the git branch directly
 {:polymorphic_embed, "~> 5.0"}

 {:polymorphic_embed,
       git: "https://github.com/mathieuprog/polymorphic_embed.git", tag: "v5.0.0"}

iex(2)> Code.ensure_loaded? PolymorphicEmbed.HTML.Form
false

@xantrac it is only available if this check succeeds at compile time:
if Code.ensure_loaded?(Phoenix.HTML) && Code.ensure_loaded?(Phoenix.HTML.Form) && Code.ensure_loaded?(PhoenixHTMLHelpers.Form) do

Do you have :phoenix_html (>= 4.0) and :phoenix_html_helpers in your dependencies?

I was looking at that right now,
I don't have PhoenixHTMLHelpers.Form since it was deprecates in favor of Phoenix.Component https://hexdocs.pm/phoenix_html_helpers/PhoenixHTMLHelpers.html

I don't know how I couldn't see it. Thank you. FWIW https://hexdocs.pm/phoenix_html/3.2.0/Phoenix.HTML.Form.html#hidden_inputs_for/1 is available in PHoenix.HTML as well. Not sure if you would compatibility issues with older phoenix versions.


refactor variable logic out of debugging manager

-move interfaces to types.ts
-move functions to helper.ts
-move variable view logic to debuggerVariables and variable view
-only call scopes and variables for the first stack and scope
For #7365

[ ] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[ ] Title summarizes what is changing.
[ ] Has a news entry file (remember to thank yourself!).
[ ] Appropriate comments and documentation strings in the code.
[ ] Has sufficient logging.
[ ] Has telemetry for enhancements.
[ ] Unit tests & system/integration tests are added/updated.
[ ] Test plan is updated as appropriate.
[ ] package-lock.json has been regenerated by running npm install (if dependencies have changed).

Codecov Report

Merging #7502 (afddddf) into main (ba3e176) will decrease coverage by 0%.
The diff coverage is 14%.

:exclamation: Current head afddddf differs from pull request most recent head 279dc78. Consider uploading reports for the commit 279dc78 to get more accurate results

@@          Coverage Diff          @@
##            main   #7502   +/-   ##
=====================================
- Coverage     64%     64%   -1%
=====================================
  Files        363     364    +1
  Lines      22598   22617   +19
  Branches    3436    3445    +9
=====================================
- Hits       14655   14653    -2
- Misses      6721    6741   +20
- Partials    1222    1223    +1

Impacted Files
Coverage Δ

...c/client/datascience/variablesView/variableView.ts
17% <0%> (+<1%)
:arrow_up:

src/client/debugger/jupyter/debugControllers.ts
10% <0%> (-1%)
:arrow_down:

...rc/client/datascience/jupyter/debuggerVariables.ts
15% <4%> (-2%)
:arrow_down:

src/client/debugger/jupyter/helper.ts
6% <6%> (ø)

src/client/debugger/jupyter/debuggingManager.ts
21% <21%> (-1%)
:arrow_down:

src/client/debugger/jupyter/kernelDebugAdapter.ts
5% <33%> (+<1%)
:arrow_up:

...lient/datascience/variablesView/notebookWatcher.ts
68% <100%> (-2%)
:arrow_down:

.../datascience/variablesView/variableViewProvider.ts
65% <100%> (-2%)
:arrow_down:

src/client/debugger/types.ts
100% <100%> (ø)

src/client/datascience/dataScienceSurveyBanner.ts
54% <0%> (-9%)
:arrow_down:

... and 5 more


Joshua-262: Slf4j - Log4j bridge

Migrated from java.util.logging to slf4j with log4j bridge.

@KellenSunderland Thanks for the review and feedback. I fixed them.
However, we are left with 200+ System.out.print and 200+ System.err.print more calls.
I will need another iteration to resolve them.

#17 has been created to make the merging job easy by targeting to JOSHUA-252.
So closing this PR.


Smart Contract and Front end values don't match?

Hi Steven,
I hope you are all OK with this pandemic situation.
I have a  confusing issue to understand and sorry to ask many questions, but there's no better person to ask than the coder himself.
Here's the issue:
The active Smart Contract  SiteCapital (TTXotPkx5YypmMjgzvGb9496XmrCxbNNaZ) values:
11.dias
Call
root:"165"
14.porcent
Call
root:"125"

The main deposit code lines (126-134) at:
https://github.com/stevenstc/SMART-SITE-CAPITAL/blob/main/src/components/CrowdFunding/index.js
var dias = 185;//await Utils.contract.tiempo().call();
//var velocidad = await Utils.contract.velocidad().call();

//dias = (parseInt(dias)/86400)*velocidad;

var porcentaje = 155;//await Utils.contract.porcent().call();

On the website (https://smartsitecapital.ml) these are the published values:
TASA E.A 108.51%
RETORNO TOTAL 155%
RECOMPENSA 55%
Tiempo en días 185
I thought the  Smart Contract (TTXotPkx5YypmMjgzvGb9496XmrCxbNNaZ) can not be altered and is responsible to execute its own values.
So if I want to use the same logic and pass my own values from the Deposit form on the website,
what values can I use to achieve a simple deposit:
365 days deposit
!23% Per Year
I understand the 'RETORNO TOTAL 155%' but don't understand the workings of:
TASA E.A 108.51%
RECOMPENSA 55%
Is this like a compounding interest percentage calculation?
Can you please describe why there are different percentages like
TASA E.A 108.51%
RETORNO TOTAL 155%
RECOMPENSA 55%
Many thanks for all your contribution and guidance on Tron development and congratulations on your Super Representative achievement :)
Best regards,

That is correct since it was requested by the company that paid for the development, there is no problem since this was intentional


Unreviewed commit on master!

Unreviewed commit(s) COMPARE was merged to master by jiezhang.
Comment with appropriate number of :+1: to approve.

Reviewed requirements satisfied? No
Ancestors reviewed? Yes

Minimum Reviews
0/1

More info

👍

Review Error for chaoyandy @ 2022-11-23 00:15:32 UTC
User must have write permissions to review

👍

Review Error for chaoyandy @ 2022-11-23 00:37:57 UTC
User must have write permissions to review

👍

Review Error for chaoyandy @ 2022-11-23 00:59:24 UTC
User must have write permissions to review

👍

Review Error for wangwzhou @ 2022-11-23 01:28:56 UTC
User must have write permissions to review

👍

Review Error for chaoyandy @ 2022-11-23 02:01:59 UTC
User must have write permissions to review

Review Error for wangwzhou @ 2022-11-23 02:07:59 UTC
User must have write permissions to review

👍

Minimum Reviews
1/1

chaoyandy
1

Pull request is reviewed and can be merged to master!
More info

👍

Review Error for wangwzhou @ 2022-11-23 17:25:28 UTC
User must have write permissions to review

👍

Review Error for wangwzhou @ 2022-12-06 00:35:52 UTC
User must have write permissions to review

👍


Update references to fishtown in README

Description & motivation
Fishtown is dead, long live Labs

Thanks for updating this, Joel! I'm closing this PR because it appears to have been fixed in another PR!


During the daxter chase, hide jak and make it look like only dax is on jetboard

can hide jak (target) with:
(logior! (-> *target* draw status) (draw-control-status no-draw-bounds2))
but jetboard visibility is tied to jak's visibility here:
https://github.com/OpenGOAL-Mods/OG-Mod-Base/blob/09fc7b4ea52e03e7a811fe6db0614cf8fba785dd/goal_src/jak2/engine/target/board/board-util.gc#L52
(maybe just get rid of the entire condition for this mod? you pretty much always want jetboard visible)


some questions

Hi there,
When I am using the gr-droneid branch with a mavic air 2, gnuradio console displays offsets/phase angle etc. and i see some extracted constellation results in the QT constellation diagram which I assume corresponds to gnuradio extractor/demodulator blocks working properly. But when I check the /tmp/bursts folder I only see a zc and channel file.
I have watched the DragonOS youtube videos and in those videos it seems that thee bursts are getting recorded as well (file_1, file_2, etc.). As I mentioned I only got files named zc and channel getting created in the folder. Does this mean something is not working correctly, or is this normal behavior?
My other question is regarding computation time for the process_file.m script. I have a fairly decent machine (16 cores, 16GB RAM) and running the octave script on 2GB of fc32 recording takes a very long time. Is this normal, or have I configured something incorrectly?
Thanks for all your work, very interesting repo!

thanks for the clarification. Are we supposed to feed the shorter burst recordings (the ones that have been disabled) directly to the .m file or should I just stick with the full IQ recording?

I think the bursts, but in my case none of my bursts ran individual or smashed together produce a result (at least for me) with the octave script. If instead I run the full IQ file that produced the bursts through octave, I hit jackpot. Be great to hear if you get results with just the bursts from your IQ file.

I guess you are cemaxucuter, right? I watched your youtube vids, and in that you directly used the ~2GB IQ recording, so that was part of my confusion. Maybe @proto17 can clarify this specific issue further.

I am not 100% sure why the processing_file.m script doesn't work with the extracted bursts from GNU Radio.  Might have to do with not having enough padding on either end of the file.  There is logic in the ZC sequence finder [1] that will abort if there aren't enough samples around the burst.  It's definitely something that should work, so I'll take a look this week.
[1] https://github.com/proto17/dji_droneid/blob/main/matlab/updated_scripts/find_zc_indices_by_file.m#L159

I guess you are cemaxucuter, right? I watched your youtube vids, and in that you directly used the ~2GB IQ recording, so that was part of my confusion. Maybe @proto17 can clarify this specific issue further.

That’s me :). I had a 8GB file at first.. that took a long while, so bursts would be great.

I have done some extra experimentation with gr-droneid branch and have some additional questions.
I have uncommented Line 85 in time_sync_impl.cc as per @proto17's recommendation. Now burst files end up in /tmp/bursts as expected. When feeding the bursts to process_file.m however I get the following warning messages:
warning: Skipping burst at offset 6288 as the beginning of the burst has been clipped
warning: called from
    extract_bursts_from_file at line 62 column 13
    process_file at line 47 column 8

warning: Skipping burst at offset 8562 as the beginning of the burst has been clipped
warning: called from
    extract_bursts_from_file at line 62 column 13
    process_file at line 47 column 8

warning: Skipping burst at offset 9093 as the ending of the burst will be clipped
warning: called from
    extract_bursts_from_file at line 67 column 13
    process_file at line 47 column 8

error: Did not find any bursts
error: called from
    assert at line 109 column 11
    process_file at line 50 column 1

Is this normal expected behavior?
Another thing I notice is that when running gr-droneid branch .grc file, sometimes the flowgraph crashes/stops working immediately after catching the first burst. And sometimes it just stops working after a while (not more than few minutes). Is this something the droneid module decides itself or can it be due to something I have done (I am running gnuradio/fosphor/uhd/droneid within a docker container). When it stops, I get the following: >>> Done (return code -11)
I also tried running the IQ recording through the octave file. (I recorded a Mavic Air 2 with B210 @ 2.4295GHz with gain set to 0.8) remove_turbo binary just outputs: [ERROR] CRC did not zero out.  Got a5a072 after calculation. Does this mean that I failed in capturing the DroneID packets? (QT constellation diagram shows results similar to @alphafox02's youtube videos)
Another thing I noticed is that droneid constellation detects some bursts even when there is no drone within the vicinity of the SDR. Is droneid somehow capturing WiFi/802.11 packets? Should I try to record outdoors far from other 2.4GHz sources?

@alphafox02 yeah I have experienced the same, high gain is probably the common denominator in the "crashes" though I don't why. I will check the closed ticket you mentioned.
One other problem I have is calling remove_turbo from octave. For some reason when calling remove_turbo from octave I get an error saying libturbofec is not found. However, I can directly use remove_turbo from the command line myself. ldd remove_turbo also shows /usr/local/lib/ for libturbofec.so , therefore I assume it is properly linked. I don't know whether calling binaries from octave using system somehow misses the linked libraries.

The WiFi detection is quite interesting.  I am not in a very WiFi heavy area, so maybe I never encountered that issue just due to not having a lot of activity there.  I can say that high gain will cause crashes in the gr-droneid branch.  I made some changes in gr-droneid-update to help prevent crashes due to high gain.  I think the issue ended up being that the correlation scores went through the roof when the gain was jacked up too high.  Not totally sure if I fixed it, but I made it a little less of a problem in my tests.
The original crashing bug was due to walking off the edge of an array.  Make sure that you have the most up to date gr-droneid as it has the fix for that problem.  If you're still experiencing then I'll do what I can to recreate the bug under GDB.
I suspect that the PATH variable in Octave doesn't know about /usr/local/lib.  Try running getenv('LD_LIBRARY_PATH') in Octave and see if it matches echo $LD_LIBRARY_PATH in the Linux terminal.  If they don't match then that's likely the problem.  You might be able to get around the issue by preloading the library when you run Octave:
LD_PRELOAD=/usr/local/lib/libturbofec.so octave

And to fix an issue with the LD_LIBRARY_PATH variable:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib octave

@proto17 , yeah looks like octave's LD_LIBRARY_PATH was different since I installed it with snap. Thanks for the pointer!
In terms of high gain; gr-droneid-update branch is way more resilient than gr-droneid branch to high gain. New branch hasn't crashed on me yet! What I have noticed is though; gr-droneid branch after gain 0.8 starts somehow capturing the WiFi and usually crashes as gain goes above 0.9. With gr-droneid-update I need to push gain all the way up to 1.0 for the "WiFi" captures but haven't seen any crashes.
I have another question regarding the update branch: I get stuff getting printed on the GR console as the flowgraph is running and when bursts are captured they are recorded in tmp/droneid_debug folder. Most of the time what is printed is like
Max: 13047 offset: 6736 - 6311
short: 144 long: 160 fft: 2048
((start_idx . 6311))
Found burst @<PHONE_NUMBER> /<PHONE_NUMBER>
Sending message with 23856 elements (23856) starting at<PHONE_NUMBER>
Found burst @<PHONE_NUMBER> /<PHONE_NUMBER>
Sending message with 23856 elements (23856) starting at<PHONE_NUMBER>
Found burst @<PHONE_NUMBER> /<PHONE_NUMBER>
Sending message with 23856 elements (23856) starting at<PHONE_NUMBER>
ZC start index: 13047, est start index: 6311
Max: 14913 offset: 6736 - 8177
short: 144 long: 160 fft: 2048
((start_idx . 8177))

but I don't get any hex frames dumped. When I get the hex frames they are always CRC Check Failed! . What does this mean? Did I somehow fail in capturing DroneID frames? Or are the frames written to console only if they fail?
Also this is a trivial suggestion; but for ease of installation you might want to include CRC.h in the relevant include folder (unless there is a license conflict) and probably cmake can look for libturbofec.so to catch any issues before make.

Right now the frequency offset and equalization in GNU Radio isn't working well.  In fact the equalization is turned off as it causes more problems than it solves.  This means that the constellations are almost certainly going to be rotated too much for demodulation to work properly.  I have improvements pending in MATLAB that once tested there will be moved over the the GNU Radio module.  The GNU Radio module was not actually meant to do full demod.  The original purpose was to just extract bursts so that I didn't have to make a multi-gigabyte recording that takes ages to process.  But, that plan has shifted a bit to trying to make the GNU Radio code as robust as the MATLAB.  All of that to say that the CRC failure you're seeing is because the frame CRC-24 failed [1].  You definitely should see some hex, so I'm not quite sure what's going on there [2].  So long as there isn't an error in the Turbo decoder/rate matcher you should get some bytes printed to the terminal.
I didn't include CRC.h because I wasn't sure about just taking that person's code.  I felt it more responsible to the author to force the end user to go get it from it's actual home.  I'm fairly new to open source and didn't want to seem rude to those that work so hard to make our lives easier for free :)  As an alternative I might just make it a submodule which will maintain that link to the original author.
As for the CMake, I do have libturbofec as a dependency to gr-droneid [3].  Are you saying I should do something in addition?  I'm not a wizzard when it comes to modern CMake, so there's definitely a chance that I missed something.
Now that I think about it, I might be able to instruct CMake to clone the repo containing CRC.h instead of requiring the user to install it.
[1] https://github.com/proto17/dji_droneid/blob/gr-droneid-update/gnuradio/gr-droneid/lib/demodulation_impl.cc#L461
[2] https://github.com/proto17/dji_droneid/blob/gr-droneid-update/gnuradio/gr-droneid/lib/demodulation_impl.cc#L455
[3] https://github.com/proto17/dji_droneid/blob/gr-droneid-update/gnuradio/gr-droneid/lib/CMakeLists.txt#L44

my bad, I didn't see libturbofec in cmake. Instead of just cloning the repo, I thought it might be more straightforward to just include the CRC.h file in your repo itself but I also see your point. licensing is difficult :)
As I mentioned, terminal usually prints: Found burst @<PHONE_NUMBER> /<PHONE_NUMBER> Sending message with 23856 elements (23856) starting at<PHONE_NUMBER> but no hex most often the time. But when it prints a hex it is CRC Check Failed! .  I will be looking for further changes in the gr-droneid-update branch.
Btw, have you tried running your extracted bursts through octave/matlab? When I do that I can't get any hex dumps. I either get:
error: Did not find any bursts
error: called from
    assert at line 109 column 11
    process_file at line 50 column 1

or
warning: Skipping burst at offset 9093 as the ending of the burst will be clipped
warning: called from
    extract_bursts_from_file at line 67 column 13
    process_file at line 47 column 8

error: Did not find any bursts
error: called from
    assert at line 109 column 11
    process_file at line 50 column 1

thanks for the answer! another thing I noticed is the flowgraph in gr-droneid uses a default delay of 5416 whereas the one in gr-droneid-update is set to 8783, is this somehow significant or just random?

Hmm, that's not ideal.  I don't recall if there was a reason for this 😳

explanation for discrepancy:
gr-droneid:
samp_rate = 15.36e6*2
decimation = 2
fft_size = samp_rate / decimation / 15e3 = 1024
long_cp_len = round(0.0000052 * samp_rate / decimation) = 80
short_cp_len = round(0.00000469 * samp_rate / decimation) = 72

delay = int(fft_size * 5) + long_cp_len + (short_cp_len * 3) = 5416

gr-droneid-update:
decimation = 1
samp_rate = 15.36e6*2
long_cp_len  = round(0.0000052 * samp_rate / decimation) = 160
short_cp_len = round(0.00000469 * samp_rate / decimation) = 144
fft_size = samp_rate / decimation / 15e3 = 2048

delay = int(fft_size * 4) + long_cp_len + (short_cp_len * 3) - 1 = 8783

So the older code gave more padding than the newer one.  The newer graph doesn't add any real padding from the start of the burst which will likely make MATLAB angry.  The symbol being used for correlation is the 4th symbol, so I think that the newer graph doesn't provide any additional padding at the start.  I'd have to look at the plots to know for sure.
As some background, the delay is all about stalling the complex samples long enough that by the time the correlation filter sees the spike, the delayed samples are some amount before the start of the burst.  If the second OFDM symbol is the one that we are interested in, then without the delay the first sample we would see when the correlation spike is found would be the first (or last depending on the correlation) sample of the second OFDM symbol, losing the first symbol entirely.

Any intuition/ideas regarding this observation?
  It's unlikely that anything other than the ZC sequence is generating a correlation score that high.  Considering that the spike looks very much like the higher scores, it might be a bug in my code.  I'd be curious if you drop the correlation score threshold [2] and then look at the burst(s) in question to see if they look correct.  Maybe they have a much lower amplitude?  It's also possible that you're getting an intermittent interferer that's messing up the correlation score.  Perhaps WiFi?
Can lower correlation bursts still be leveraged?
Yes, you can lower the correlation threshold using [1] for MATLAB and [2] for GNU Radio (this value needs to be exposed by the OOT module in GNU Radio Companion).  Since the correlation is normalized you should be able to bring that value pretty low and still not have false positives.  That's assuming that you're RX gain isn't jacked to the moon such that you're clipping on at the front end.
The extractor module does indeed use an FFT filter to do the correlation to search for the ZC sequence.  For reasons I do not understand the output of the FFT filter correlation is magically normalized.  The MATLAB filter function wasn't always working that way, so there's a special normalized correlation function in there (this is one of the places where MATLAB and GNU Radio differ in implementation).  It might be that the GNU Radio FFT filter has the same issue that the MATLAB filter function does, but I haven't had anyone run into it yet.  The issue being the output of the filter function in MATLAB not necessarily coming out normalized.  This might be related to the SDR used, but I'm not sure.  Anywho, the MATLAB correlates through all of the samples in the file and stores off the normalized correlation scores.  Then it looks through those scores for values that meet the specified threshold [1] and calls those "bursts" and extracts out samples before and after to be processed later.  In GNU Radio I don't have access to all of the samples at once, so the FFT filter output is sent to the extractor along with a delayed copy of the samples.  Once the FFT filter output reaches the threshold [2] it calls that a burst, and begins counting samples until it has received X [3] number of samples.  Those samples are then packaged up and sent to the next block.
I have not really put much effort into detections at a longer range.  The original intent for the GNU Radio code was to extract bursts without having to record literal minutes of IQ at 30.72 MSPS to then have to run through MATLAB for several more minutes.  The real limiting factor for the GNU Radio code is that there's no equalizer.  The code is there [4] but when I try to use it things go all screwy.  I stopped working on it because it became apparent that integer frequency offset was going to hose everything, so I focused more on trying to solve that problem.  After several days of trying things I thought I had something that worked down to just a few dB SNR, but once I tried it on real data everything fell apart :frowning_face: So, to just get something that people could use for more instant gratification than MATLAB/Octave I smashed the descrambler, Turbo decoder, and rate matching code into the GNU Radio module and called it a day.
[1] https://github.com/proto17/dji_droneid/blob/main/matlab/updated_scripts/process_file.m#L37
[2] https://github.com/proto17/dji_droneid/blob/gr-droneid-update/gnuradio/gr-droneid/lib/extractor_impl.cc#L73
[3] https://github.com/proto17/dji_droneid/blob/gr-droneid-update/gnuradio/gr-droneid/lib/extractor_impl.cc#L47
[4] https://github.com/proto17/dji_droneid/blob/gr-droneid-update/gnuradio/gr-droneid/lib/demodulation_impl.cc#L196

Thanks for the detailed answer @proto17.
I have changed the OOT module and made correlation threshold a parameter that can be controlled from GRC.   Once the ZC correlation exceeds the threshold; the bursts are registered properly as you described. However, I did not notice much of an improvement just by dropping the correlation threshold, maybe qualitatively more bursts were getting detected but I am not exactly sure about that. I have tried with a correlation threshold of 0.1 and 0.01 and they both seemed to work fine.
Can lower correlation bursts still be leveraged?
Regarding this question, I guess I did not really convey what I was meaning. With gnuradio extracted bursts, I basically see three max. correlation levels in matlab/octave: ~0.7, ~0.26, and ~0.02. When the octave computed correlation is around 0.7; remove_turbo works properly and I can get a hex frame that can be decoded in DroneID values. When octave-computed correlation is around 0.02 the correlation plot is basically jitter and there is no notable peak. However; when octave-computed max correlation is ~0.26, there is a very obvious peak and the shape of the overall correlation plot (plot(abs_scores)) is pretty much identical to the 0.7 case. The problem is that remove_turbo gives CRC did not zero out error in the case of 0.26 correlation. As you mentioned such dominant peak in the correlation should indicate a DroneID burst but I can't seem to get any frames in that case. Any ideas here? Could it be due to frequency offset?
Another thing I noticed is about frequency offset calculation. I tried pushing the index discovered by find_zc_indices_by_file here to right and left. Adding up to +75 to the index, and frames can still get interpreted properly by the descramble and turbo remover. Hovewer, moving the index by -1 to left immediately leads to CRC errors. I believe this is somehow due to the frequency offset calculation channel_phase_adj = (channel1_phase - channel2_phase) / 2;. I was wondering whether this is expected behavior. Also given this observation do you think it is a good idea to use a guard interval and use something like index+10 instead of index to make sure CRC always zeroes out?

Apologies for the delay!
I suspect that my assumption that the FFT filter in GNU Radio would just magically provide normalized output was false.  This would explain why you have to drop the correlation score randomly, and why MATLAB and GNU Radio do not agree.  I started work on a normalized cross correlator for GNU Radio, but it's crazy slow.  On the order of ~ 2 MSPS max throughput with a filter size of 1024 samples which is the best case for the GNU Radio graph.  It will take a while to figure out how to get the throughput up, and to test that everything is working properly.
There are a few possible alternatives to the normalized cross correlation:

Don't normalize and instead look for a sudden rise in correlation scores (this will likely sacrifice low SNR performance and be more susceptible to false triggering)
Use an auto correlator instead of a cross correlator.  This would work because the ZC sequence is symmetric in the time and frequency domains.  And it would be less expensive than the cross correlation when not normalized since I only need to compute the dot product of 1/2 of an OFDM symbol.  It would probably be just as expensive in the normalized case due to needing to convert both vectors to zero mean, and get the variance of both vectors for every single shift of the correlator.  This might also have some complexity around the fact that the second half of the sequence needs to be reversed each time before computing the dot product.
Only cross correlate for part of the ZC sequence.  Perhaps just looking at the first half of the sequence is enough.  That's at least 512 * N samples (where N is the oversampling ratio) which is better than 1024 * N

The frequency offset estimation code might not be perfect.  I have an adjustment to it in my local repo that uses all of the cyclic prefixes to compute a (hopefully) better coarse estimate.
Moving the starting index to the left (in time) causes the starting index of each OFDM symbol to end up in the cyclic prefix.  Starting inside the cyclic prefix is fine as it just causes a cyclic shift in the frequency domain.  This is actually something that I have done in the past when I wasn't sure about the true starting sample index.  When in doubt, move the starting sample into the cyclic prefix.  Now, what's surprising here is that you say you added to the start index which would push the first sample into the data samples.  This would cause the 1024 samples that go to the FFT to include cyclic prefix samples of the next OFDM symbol.  That's bad and will break things.  That's a bit confusing to me.
The channel estimation logic is definitely load bearing code.  The line you reference for channel_phase_adj is an attempt to deal with residual time offset.  Without using that line you will end up with a constellation that is rotating OFDM symbol to OFDM symbol.  It's not usually bad enough to be an issue, but it looks nasty, so I wrote that logic to lock the constellations.  I haven't yet run across a situation where that code causes issues, but you can remove it if you would like to try.  It's used here [1].  You can just comment that line out.  You won't always see the constellation rotating without that line, but it will be more likely.
The biggest issue with starting sample estimation right now is that if you have a frequency offset then the starting offset of the ZC sequence will be wrong.  It's some strange feature of the ZC sequence that the cross or auto correlation of the sequence in the presence of a frequency offset will correlate well, but the peak of the correlation will be before or after the actual starting index of the sequence.  Since I use the peak to determine the starting index, a large enough frequency offset will break everything.  This frequency offset comes from a combination of the transmitter and receiver clock inaccuracies.  So even if you have a GPS disciplined oscillator on your SDR, the drone might have a worst case offset and throw everything off.  Ultimately I think you're right, that the only real option is to back the starting index off into the cyclic prefix.  I've tried that in the past and had issues, but it could have just been that I was doing it wrong =\
[1] https://github.com/proto17/dji_droneid/blob/main/matlab/updated_scripts/process_file.m#L166

@proto17 , hi there! I just revisited this repo and had a thought. In the grc file, you feed the pseudo-correlation to the extractor block via filtering the input with the zc sequence (droneid.misc_utils.conj(droneid.misc_utils.create_zc_sequence(samp_rate/decimation,600))).
Though for it to be a (pseudo)correlation should not the zc sequence be reversed? For instance, check gnuradio's correlation implementation here.

You're absolutely right about needing to reverse the filter taps!  It just so happens that the ZC sequence is mirrored about the center in time and frequency :)

Thanks for the detailed answer @proto17.
I have changed the OOT module and made correlation threshold a parameter that can be controlled from GRC. Once the ZC correlation exceeds the threshold; the bursts are registered properly as you described. However, I did not notice much of an improvement just by dropping the correlation threshold, maybe qualitatively more bursts were getting detected but I am not exactly sure about that. I have tried with a correlation threshold of 0.1 and 0.01 and they both seemed to work fine.
Can lower correlation bursts still be leveraged? Regarding this question, I guess I did not really convey what I was meaning. With gnuradio extracted bursts, I basically see three max. correlation levels in matlab/octave: ~0.7, ~0.26, and ~0.02. When the octave computed correlation is around 0.7; remove_turbo works properly and I can get a hex frame that can be decoded in DroneID values. When octave-computed correlation is around 0.02 the correlation plot is basically jitter and there is no notable peak. However; when octave-computed max correlation is ~0.26, there is a very obvious peak and the shape of the overall correlation plot (plot(abs_scores)) is pretty much identical to the 0.7 case. The problem is that remove_turbo gives CRC did not zero out error in the case of 0.26 correlation. As you mentioned such dominant peak in the correlation should indicate a DroneID burst but I can't seem to get any frames in that case. Any ideas here? Could it be due to frequency offset?
Another thing I noticed is about frequency offset calculation. I tried pushing the index discovered by find_zc_indices_by_file here to right and left. Adding up to +75 to the index, and frames can still get interpreted properly by the descramble and turbo remover. Hovewer, moving the index by -1 to left immediately leads to CRC errors. I believe this is somehow due to the frequency offset calculation channel_phase_adj = (channel1_phase - channel2_phase) / 2;. I was wondering whether this is expected behavior. Also given this observation do you think it is a good idea to use a guard interval and use something like index+10 instead of index to make sure CRC always zeroes out?

Would it be safe to assume that a correlation threshold of 0.1 and 0.01 will be good to enter by default into the gr-drone_update flow graph? I wanted to put a default setting in there to ensure the flow graph runs by default.

The GNU Radio update branch (gr-droneid-update) might not have the latest and greatest MATLAB.  I worked on the GNU Radio branch totally separate from the MATLAB code.  So that's something I need to look at.  For now, assume that main contains the most up to date MATLAB, and gr-droneid-update contains the latest GNU Radio code.
I would worry that as you lower the correlation threshold, the chance of having a timing offset increases.  This shouldn't be an issue for the MATLAB/Octave code, but might for the GNU Radio.  I don't think the GNU Radio logic makes a second, more targeted pass at the ZC sequence start index.  If it doesn't, then a very low threshold would cause the GNU Radio logic to see the start time offset (STO) as being several samples early, which would break demod later on.  The other issue with a low threshold is false triggering which will both consume loads of CPU, and cause missed DroneID bursts since the software is busy consuming samples for a phantom burst.
It's also worth noting that a large frequency offset will cause you to get low correlation scores.  I don't have access to the flow graph right now, but I seem to recall that I do have a low pass filter in the graph so that you can only see ~ 10 MHz in the center of your baseband.  If you have a DroneID burst that only partially comes into your passband, then you might get a tiny correlation spike and think that something was wrong.  I recommend looking at the figure; plot(10 * log10(abs(burst_samples).^2)) (log power in the time domain) view of the samples in the burst that you think you missed.  You should see an obvious and clean signal present.  You can also check the frequency domain to be sure that the signal wasn't clipped by the low pass filter figure; plot(10 * log10(abs(fftshift(fft(burst_samples))).^2);
In the end, lowering the threshold has the most effect on CPU.  The lower you make it, the more false positives, and the more time your CPU spends chugging on samples.  Because of this, you should be on the lookout for Os in the terminal (assuming you're using an Ettus radio) signifying that your CPU wasn't keeping up.  You can also open up top, press H and look for processes that are using 100% of a core.  If you see that, and the name matches up to a block in the graph, then you are going to get bad correlations because samples are randomly getting dropped.
Hope that helps!

Think I'm on the right track then, plan was to update the gnuradio with the gnuradio update branch, but then switch back to main after it's installed so that the matlab code was newer. That way if someone wanted to save off the IQ file/bursts they could then use matlab/octave scripts? But.. if they wanted to try and get decoding running in the bottom left window of gnuradio - that ability would also be there if they open the new flowgraph.
I just wasn't completely sure what to stick as a default value in the correlation setting in the flow graph. I need to grab another drone and try this out again. I have the b205 and for a sort period, the x310.


Error when running sync on Windows

I am running git-town installed manually in a directory on %PATH% on Windows 7.
When I first ran git-town sync I got the following error on the Stash Pop step after pulling changes down.
CONFLICT (content): Merge conflict in src/test.js 2017/05/22 11:29:28 open /tmp/sync_C:_Projects_myProject: The system cannot find the path specified.
I can resolve the conflict manually - but I'm guessing something when wrong there.
If I've omitted/forgotten any important information let me know so I can update the issue.
A

git-town saves some state in temporary files if there are conflicts or if the command is undoable. Is /tmp/sync_C:_Projects_myProject a valid path on a windows machine?

It shouldn't be a valid path on Windows - AFAIK Windows does not allow for ":" in folder names.

Okay. Currently the temp file includes the full path to the repository with the "/" converted to "_". We can add a conversion to remove the ":".

While we are at it, let's convert all non-alphanum characters to underscores to solve this once and for all, for all platforms.

4.1.0 released with a fix


Issue token to allow shifting JupyterHub API calls to frontend

Proposed change
Idea discussed with @yuvipanda. The gist is to move JupyterHub API calls to the frontend, so that a client library can control building and launching.
Right now, the sequence is:

binderhub builds image
binderhub creates jupyterhub user via API
binderhub 'issues' token (generates random string)
binderhub sends API request to hub to launch jupyter-server with the token

Proposed sequence changes at step 3 to use the JupyterHub API to issue a real short-lived token that can be used to launch the server.
For example:
# POST /api/users/:name/tokens
{
  "expires_in": 900, # 15 minutes - whatever spawn timeout should be
  "scopes": [
    "servers!server=username/", # start/stop the server
    "access:servers!server=username/", # access the server (not really used unless jupyterhub-singleuser is launched)
  ],

The build event stream would then end with this token, and the client library would take over, making the API requests to launch and await the server instead of BinderHub.
Issues to consider:

limiting what image(s) can be spawned with the token
enforcing quotas when BinderHub doesn't decide when to launch
how does this interact with authenticated BinderHub?

Alternative options
Run the anonymous user-creating service somewhere else, so that launch is fully decoupled from BinderHub (or still inside BinderHub, but decoupled from build). This requires more thought, since there are major security implications, but ultimately BinderHub already is this - you can create any number of anonymous JupyterHub users by requesting builds. But BinderHub quotas apply limits, which may become tricky to enforce.
Who would use this feature?
binderhub-client javascript library could control building and spawning.

yesssss i like this.

Currently, it looks like if authentication is enabled, we simply skip the 'create user' step. We can continue to do that here, right?

In general moving binderhub's scope to be narrower will be a useful direction to take in the long / medium run. This allows it to get out of the business of 'launching jupyterhub user servers'. That can be a client responsibility. And we can do this without changing the experience on mybinder.org easily.
me likey the scopey. Thanks, @minrk

Currently, it looks like if authentication is enabled, we simply skip the 'create user' step. We can continue to do that here, right?

I think so. And indeed, we could use the OAuth token issued to binderhub during oauth as the token (make sure the launch permissions are in oauth_client_allowed_scopes). In the auth case, I think this would remove any need for BinderHub to make API requests to the Hub aside from the standard oauth requests. That means the BinderHub service would need no permissions at all.
I think enforcing quotas and limiting images are going to be the tricky parts, since BinderHub is no longer involved in that step, and JupyterHub doesn't have that understanding. That logic would need to move to the BinderHubSpawner, I guess.