Raw16 files

Thomas - I have been using your wonderful all sky software for the past year, running with an ASI178MC and RPI-4 here in Central Oregon. I've spread the knowledge to others in my geographic area - in particular to two observatories whose new all sky cameras using your software should come online within a month.
Moving forward, we are interested to measure skyglow and I may make the effort to calibrate my camera to allow estimation of radiance from the Raw16 images. In looking at the RAW16 images captured under Type=2 and PNG Quality=9, it seems that while they are encoded into 16-bit values, that there are only 256 unique 16-bit values in each of the color channels. Using the same camera, images captured via ZWO's ASI Studio software show RAW16 images with a very large number of unique values, not limited to 256 unique values.
My evidence is from looking at the two respective RAW16 images in the Pixinsight software, one image captured by the allsky software and the other by ASI Studio. After importing the two RAW16 images into Pixinsight and pulling apart the CFA pattern via the Pixinsight SplitCFA algorithm (which does not interpolate values of adjacent filter locations), the 64-bit histograms of each RAW16 image have very different character. The RAW16 from allsky has about 256 spikes across the 64-bit range. The RAW16 from ASI Studio has a completely filled-in histogram, indicating many more than 256 values are present in the image.  See the figure below.
Perhaps there are other camera settings to overcome this apparent limitation of the RAW16 images from the allsky software? I look forward to any comments.

You are welcome. Btw, I don't think the image is losing bit depth. Instead there are a limited number, perhaps 256, of 16-bit values being written to the RAW16 image. It's as if there is some look up table in the code that is limiting what is written to the image. Perhaps a table of 256 16-bit values is being applied, instead of the thousands of available 16-bit values.

Oh I see. It's like if it was a 256 indexed color image with 16-bit values used.
I'm thinking it's probably an issue with imagemagick trying to optimize the output. I'll explore what the -type option produces.
https://imagemagick.org/script/command-line-options.php#type

Thomas, were you able to look into this?
wsk412,
have you tried this with ZWO's "demo" program that comes with their SDK and runs on the Pi?
I believe on the Pi, the 16-bit mode is for mono cameras only, and there is no 16-bit mode for color cameras.  The only color mode takes 3 bytes total for R, G, and B.
Eric

Closing - no response from user despite two requests.

Eric,
Thanks for this. I have not tried that ZWO program on the Pi.
I sent an email to ZWO just now, which I expect will confirm your note below about this bit-depth limitation on the Pi. I’ll let you know what I hear back from ZWO.
Sorry about the non-reply earlier and I understand that this topic is otherwise closed.
Cheers,
Bill
From: EricClaeys @.>
Sent: Friday, October 15, 2021 10:31 PM
To: thomasjacquin/allsky @.>
Cc: wsk412 @.>; Mention @.>
Subject: Re: [thomasjacquin/allsky] Raw16 files (#342)
@wsk412 https://github.com/wsk412  have you tried this with ZWO's "demo" program that comes with their SDK and runs on the Pi?
I believe on the Pi, the 16-bit mode is for mono cameras only, and there is no 16-bit mode for color cameras. The only color mode takes 3 bytes total for R, G, and B.
Eric
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/thomasjacquin/allsky/issues/342#issuecomment-944860320 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AN5RK6RB2DY76X4IM6CXHVLUHEEYHANCNFSM4Z5JH6NQ .
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&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

Reopening. Let's see what ZWO says, and whether or not it works on ZWO's Linux program.

@wsk412   Did you ever hear back from ZWO?

Eric,
Thanks for following up. No, I never heard back from ZWO.
For what it’s worth, I found that the AllSkEye https://allskeye.com/  software does successfully create 16-bit FITS files from my ASI178MC camera.
Bill
From: EricClaeys @.>
Sent: Monday, May 30, 2022 9:02 PM
To: thomasjacquin/allsky @.>
Cc: wsk412 @.>; Mention @.>
Subject: Re: [thomasjacquin/allsky] Raw16 files (#342)
@wsk412 https://github.com/wsk412  Did you ever hear back from ZWO?
—
Reply to this email directly, view it on GitHub https://github.com/thomasjacquin/allsky/issues/342#issuecomment-1141643441 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AN5RK6TTCILCJRCYXC6C6DDVMWFK3ANCNFSM4Z5JH6NQ .
You are receiving this because you were mentioned.Message ID: @.***>

@thomasjacquin   Thomas, on March 31, 2021 you said:

Oh I see. It's like if it was a 256 indexed color image with 16-bit values used.
I'm thinking it's probably an issue with imagemagick trying to optimize the output. I'll explore what the -type option produces.
imagemagick options

Were you ever able to look into this?
Eric

I think with asi178mc (mc as multicolor), we'd need raw48 format for 16 bits of info in every channel. Allsky documentation states that raw16 is only for monochrome cameras.

@grue74   The ZWO library for Linux only supports the following modes:
ASI_IMG_RAW8 // Each pixel is an 8 bit (1 byte) gray level
ASI_IMG_RGB24 // Each pixel consists of RGB, 3 bytes totally (color cameras only)
ASI_IMG_RAW16 // 2 bytes for every pixel with 65536 gray levels
ASI_IMG_Y8 // mono chrome mode 1 byte every pixel (color cameras only)

The RAW16 produces mono images only and RGB24 is 8 bits per Red, Green, and Blue.
Everything in ZWO's documentation says RAW16 images sizes are width * height * 2 and RGB24 is width * height * 3.
It's possible the Windows drivers support 16-bit per channel color images.


Heroku Guide docs

Addition of Heroku Guide docs and images.

Thanks for this!
 You can use a tool like http://optimizilla.com/

Done and done.
Thanks for the suggestion about the optimizilla. Very cool and useful.

Looks great!
We're separating the docs into their own repo. I'm going to close this pull request, but could you re-open it against https://github.com/begriffs/postgrest-docs ?


Upgrade deprecated linters

Lint execution is producing these warnings:
  level=warning msg="[runner] The linter 'interfacer' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner. "
  level=warning msg="[runner] The linter 'golint' is deprecated (since v1.41.0) due to: The repository of the linter has been archived by the owner.  Replaced by revive."
  level=warning msg="[runner] The linter 'scopelint' is deprecated (since v1.39.0) due to: The repository of the linter has been deprecated by the owner.  Replaced by exportloopref."

We should fix them.

Hello, how do I reproduce these warnings and could this be assigned to me.

You can run make lint to test locally.

close


Is x.filing_parties truly meant to be per-document?

@BryceStevenWilley
And if so, is it required for each document, or just the lead document?

explain_user_paying comes up in a weird place right now (from an earlier change I made). Just wondering how best to relocate it

Yeah, it's per document.

OK, I'm a bit confused about how this impacts fee calculations, but maybe it doesn't impact that at all.


When features are embedded in a page and then unpublished, the page where they are embedded should load without the embedded content

Currently, if a page is created with an embedded poll and then published, but then the poll is later unpublished, the page where the poll is embedded will not load (front end users receive an error syntax page). Ideally, in this scenario, the page will still load, but without the unpublished poll and the CMS editor will not be able to republish or resave the page without deleting the poll widget component from page content.

Applies also to embedded polls that are deleted.
Does this happen with Page Buttons as well? Any other new content block elements?

Prioritizing this as it affects the homepage, eg if you delete a Page which is promoted on the homepage then the homepage breaks.
This is very different behavior to V1 where you can delete content and it disappears from the homepage without issue.

We should handle this gracefully both when pages are deleted and unpublished. I assume in that case the respective element should simply not be rendered for now. We can make a separate issue about warnings to display on the CMS side.
Can we a compile a complete list of instances?

questionnaires in articles
featured content in homepage
featured content in section
recommended content in articles
page buttons?
...

Organized slightly differently
Content blocks used in all Page types

Page button
Embedded survey/poll/quiz
Article (in Homepage)
Image
Media

Paragraph Content Block functions

Media
Link (link text seems dependent on the linked asset)
Document
Image

Article Page

Recommended content

Homepage Page

Banners

Page Link Page

Destination Page

Section Page

Featured content

All Page Types

Icon

I think this is all the locations where a Page relies on assets outside the Page. These are not necessarily all causing the problem.
Do you need us to manually confirm which of these currently cause problems, or will you build a solution that addresses all?


Allow text wrapping in string table cell

via @mtanco
@lo5 The only thing I am wondering about is where should we put the switch within API. Directly on TableColumn as wrap? This would however apply to text types only. Another option would be to wrap by default and swap it with current elipsis.

related: via @goldentom42
We could also allow tooltips on hover instead of wrapping.
Proposal: provide an overflow prop with 3 possible values:

ellipsis - default, the three dots
wrap - wrap the text in the column
tooltip - show tooltip with full value

Another possible solution is to always show tooltips by default for every cell and go with the proposal above ^^

@mturci has there been any progress on this one ? thx.

Not yet, but we can prioritize if needed.

@mturoci This would be quite handy for our app, as we have some larger tables with certain column width restrictions and it would be nice to hover over a cell, and be able to read the whole content.

@mturci if you can prioritize that would be awesome ! thank you.

cc @lo5 for API review
Related: #1096


fix the broken link

Thanks for the PR.
@evilnick can you confirm the cni-kube-ovn page is the one we want to link to from here? I originally had this link to charm-kube-ovn to mirror what the Calico charm's README links to, but I guess we don't have a charm-kube-ovn page.

@cynerva - yes, that looks good to me. We removed all the 'charm' docs in favour of charmhub docs, so there are no 'cahrm-' pages any more

Got it. Thanks folks.


Adding Support for KW protocol

KW protocol implementaiton thanks to Corentin Lutgen (I have not tested it)
single byte readingings thanks to LHARD

KW protocol not tested by myself


Untitled Notebooks are opening existing saved untitled files

Create new untitled notebook (Notebook-0)
Type in some content in that Notebook
Open another tab (can be anything - SQL query or whatever) and click on it
Close ADS
Re-open ADS
Run "New Notebook" action

The "Notebook-0" notebook is opened with the previously typed content instead of a new Notebook
I believe the problem here is that the logic we're using (https://github.com/microsoft/azuredatastudio/blob/main/extensions/notebook/src/common/utils.ts#L189)  looks at all opened documents to see what names are available - but a document isn't actually opened until it's clicked on for the first time and so if you start ADS then all the "saved" untitled notebook editors don't actually load their documents until you click on them so this logic thinks they're available - but then when we open the editor with that URI it loads the previously saved Notebook instead of the new one.

I can repro this.


feat(psp22): testnet drink test feature gating

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (chungquantin/feat-psp22_example@dd4ce50). Learn more about missing BASE report.

@@                        Coverage Diff                         @@
##             chungquantin/feat-psp22_example     #377   +/-   ##
==================================================================
  Coverage                                   ?   51.60%
==================================================================
  Files                                      ?       48
  Lines                                      ?     4910
  Branches                                   ?     4910
==================================================================
  Hits                                       ?     2534
  Misses                                     ?     2327
  Partials                                   ?       49


chore: build and push docker image to ghcr.io

What this PR does / why we need it?
This PR added the build_image_ghcr workflow.
The images stored in ghcr.io are supposed to be used for testing.
Tags or branches following the rules[ 'main', 'docker', 'dev' ] will trigger this workflow.
When Axon has a new release tag, build_image.yml will also push the corresponding image to Docker Hub.
What is the impact of this PR?

No Breaking Change
Acceptance and DevOps team can pick a docker image from ghcr.io more quickly without long time building.

Special notes for your reviewer
Suggestions are welcome.
PR relation:

replace/close https://github.com/axonweb3/axon/pull/1347

CI Settings

CI Usage
Tip: Check the CI you want to run below, and then comment /run-ci.
CI Switch

[ ] Coverage Test
[ ] E2E Tests
[ ] Code Format
[ ] Web3 Compatible Tests
[ ] OCT 1-5 And 12-15
[ ] OCT 6-10
[ ] OCT 11
[ ] OCT 16-19
[ ] v3 Core Tests

CI Description

CI Name
Description

Chaos CI
Test the liveness and robustness of Axon under terrible network condition

Cargo Clippy
Run cargo clippy --all --all-targets --all-features

Coverage Test
Get the unit test coverage report

E2E Test
Run end-to-end test to check interfaces

Code Format
Run cargo +nightly fmt --all -- --check and cargo sort -gwc

Web3 Compatible Test
Test the Web3 compatibility of Axon

v3 Core Test
Run the compatibility tests provided by Uniswap V3

OCT 1-5 | 6-10 | 11 | 12-15 | 16-19
Run the compatibility tests provided by OpenZeppelin

[ ] ERROR: failed to push ghcr.io/axonweb3/axon:sha-b0e65b8: unexpected status from HEAD request to https://ghcr.io/v2/axonweb3/axon/manifests/sha-b0e65b8: 403 Forbidden


handlers not called after focus switch..

Hi!
I have nested a hotkey element and an input element within another hotkey element:
import React from 'react';
import {HotKeys} from 'react-hotkeys';

const Neat = React.createClass({
  onKeyDown (event) {
  },

  render () {
    var handlers = {
      'up': function(event) {
        console.log('up');
      },
      'down': function(event) {
        console.log('down');
      }
    };

    var inputHandlers = {
      'up': function(event) {
        console.log('inputHandler up');
      },
      'down': function(event) {
        console.log('inputHandler down');
      }
    };

    return (<div>
            <HotKeys handlers={inputHandlers}>
            <HotKeys handlers={handlers}>
            <div> hello </div>
            </HotKeys>
            <input ref='input' onKeyDown={this.onKeyDown}>
            </input>
            </HotKeys>
            </div>);
  }
});

module.exports = Neat;

Here's how I reproduced the issue:

click to focus on 'hello' div
use up and down key to trigger the handlers of the nested hotkey wrapper
click and focus on the input
now press up or down key, you'll find that one of the handlers of the outer layer is not called (and which one depends on the order of keys pressed in step 2..)

This is the minimal example to reproduce the problem I had.
The behavior depends on the order of keys pressed and whether you focus on a certain element. (stateful!) I wonder if it's something with mousetrap or the way we use it..

It seems to be something with lastChildSequence, I'm not sure if I understand the check here: https://github.com/Chrisui/react-hotkeys/blob/master/lib/HotKeys.js#L110
So it's checking to see if current sequence is already handled by child, if child has processed the sequence, lastChildSequence should already have been set to the sequence, thus parent should not process it.
But consider this case:

child process sequence (e.g. 'a')
lastChildSequence of parent is set to 'a'
child loses focus, but focus is still within parent element
sequence 'a' is fired again

this is the case where child has not processed the sequence, while parent falsely believes it has. So it explains why the previous example did not work?
A fix would be to just reset lastChildSequence of parent when a hotkey loses focus..
But I'm not sure if this will break other behaviors.

Thank you for the time taken to debug and solve this! I have merged your PR as you're totally correct that this state should've been cleaned up on blur.
I'm going to do a quick test and then I'll publish a release to npm.
Thanks again! :)

Great! Thanks!

Hey Chris,
Could you let me know when you do an update to npm. We'd rather pull it from npm than use our own copy of react-hotkeys.
Thank you!

Just published v0.7.1 with the fix for this.
CC @fantasticsid @pashasadri
Cheers!

Awesome! Thanks Chris!


Add vSphere driver

This issue is tracking the addition of the vSphere driver.

@cduchesne Does this need to stick around? Is this on the roadmap? I'm inclined to close.

Issue moved to codedellemc/rexray #947 via ZenHub


[5.1] Search for SwiftShims in SDK (#23287)

…but only if the compiler resource directory doesn’t have them. These will move to the SDK soon.
Resolves rdar://problem/48865477.

@swift-ci please test


feat(datasource/graphene)

continued from https://github.com/google/neuroglancer/pull/317
refactored to use SegmentationGraphSource. still very much in progress

I have some questions for how I should proceed.
First to summarize what I did and open to feedback. I added a createRenderLayer method to the graph connection interface. SegmentationUserLayer calls it and adds a layer if one exists. Maybe it should be an array to be flexible. I added the ability to override select if there is a graph and it implements a select operation.
Many of our operations need to be able to change the VisibleSegmentState. Do you suggest we use the connections set pattern that you used in local? I started to do that but I wasn't sure the case where we would have more than one graph connection. This is also related to the next question.
The select method is currently it is on the graphConnection but I think it should be moved it to graph because it shouldn't be different from merge and split. Though I'm also a little split because this is called from the SegmentationUserLayer which has a single graphConnection associated with it. Regardless of using the connections set, it still relies on accessing our renderLayer. I haven't implemented the functionality in this seunglab PR https://github.com/seung-lab/neuroglancer/commit/5045538e84b2388c2c06078fc3467d2fd4a7167a#
But basically we want to prevent the select operation if the user is zoomed out too far because it would put too much stress on the browser and our graph backend. It checks the zoom by comparing the sliceview pixel size with the layer voxel size. I'm still trying to understand this code, I think it should be possible to simplify it and I was hoping we could do this calculation inside of our select method in our graph implementation. I was struggling to figure out how to access the current pixel size given a SegmentationUserLayer. Maybe you have a better idea on how to deal with this issue.
We have custom UI for graphene and I'm not sure how to integrate custom configurable UI limited to the Graphene source. For example, we have a simple date picker in our graph tab that allows us to view the graph as it was at a previous point in time (we also disable editing if that is set). We probably want to add a tab for all of our graphene specific UI. Is this already possible in neuroglancer? I haven't spent much time in this area.

filterVisibleSources to limit zoom out looks like a good solution, thanks, and I think I understand the graph source vs graph connection now.
I'm working on the segment query.
What was your idea behind watchSegment, I'm wondering if that could be useful for graphene.

trackSegment is actually currently unused, so you can ignore that.
I think I originally added it for use by the split and merge tools to keep track of the root id corresponding to the selected seed points (which might change as other splits/merges are performed), but then found it was not necessary.
In the nggraph prototype all segment ids added to the visibleSegments set are tracked and updated as splits and merges are performed on the graph, including by other users.  There is a websocket connection to the server specifically for this purpose.
I would suppose graphene could support that as well, possibly with additional server-side support, but my understanding is that goes against the current model used in the seung-lab neuroglancer, where after selecting a segment, it is pinned to the version at the time it is selected (until a split/merge action is performed), and Sven indicated that this pinning behavior was considered desirable by users.

Hi Jeremy,
Ran into an issue with implementing multicut using the temporary sets. This is an image of our multicut tool in action. As soon as I add a split point, the segment that contains the supervoxel becomes our focus segment. The supervoxel layer darkens everything outside of that focus segment. I have one supervoxel in the red set, one in the blue set. I am planning to use the stated colors to handle that coloring.
I tried to implement the "focus" feature in a similar way to our previous branch, using an additional hash table. The issue I run into seems to be that in order to filter by the focus segment, it needs to look up the non-temporary equivalence. I can set useTemporaryVisibleSegments to true and keep useTemporarySegmentEquivalences false. I can make something similar to valueForColor so it knows when to use value and base value for our scenario. The problem is this is starting to feel too specific to the situation for multicut. I was hoping everything I added would fairly generic.

Basically I have a situation where I want to display some temporary and some non temporary.

Are you planning to still have a separate RenderLayer for the supervoxels?  I added the temporary segments options in order to avoid having to do that.  To be honest I don't remember exactly why I didn't want to use a separate RenderLayer for the temporary stuff shown during split/merge operations, but I recall that I initially attempted to go that route with nggraph but ran into some problems.
Do I understand correctly that the objective here is that once you start a multicut operation:

Every segment except the focus segment should be hidden
The focus segment should be shown in white
The seed supervoxels should be shown in red and blue.

I think you could potentially accomplish this by:

adding a temporary segment stated colors map, that works similarly to the existing temporary segments and temporary equivalences
create a temporary equivalence map that links everything in the focus segment to its root id, except that it excludes the seed supervoxel ids
add the root id and the seed supervoxel ids, to the temporary visible segments set
add the root id and the seed supervoxel ids to the temporary segment color map

I removed the separate render layer.
What you said is correct although it is more about darkening everything but the focus segment but perhaps that can be achieved with a combination of darken everything and brighten the focus segment.
I'll try out your suggestion, thanks!

That seems like it will work well, I do think I need to add a render setting to darken all non-"visible segments".
I have another question for multicut. In the picture I posted earlier, you can also see a red annotation. We keep track of the position of the mouse clicks as I mentioned that we also do with the merge. For this tool we render them as an annotation layer. We did this previously by creating our own SliceViewAnnotationLayer and PerspectiveViewAnnotationLayer on the segmentation_user_layer for each the red and blue sets which means we don't display them as their own user layer. We display our own list of them separate in our graph tab separate from the layer annotations list.
I tried to see if I could do this with the addAnnotationLayerState or addLocalAnnotations on the SegmentationUserLayer which didn't exist when it was implemented in the seung lab branch.
,

Yes, I think some refactoring of addLocalAnnotations/addAnnotationLayerState may be needed in order to allow these split/merge points to be shown as a separate annotation list.
As far as the units being wrong, moueState.position is always in the global coordinate space, but you should store these annotations in the coordinate space of the segmentation data source.  You can look at the getMousePositionInAnnotationCoordinates function defined in ui/annotations.ts.

Does this seem like a reasonable way to create an AnnotationLayerState outside of activateDataSubsources?
My first solution was to add an optional method on graphConnection inside activateDataSubsources. It seemed messy but perhaps I could write a generic function to just allow graph connections to do whatever they need, passing the loadedSubsource and the layer.
Instead I decided to try a more brute force approach which I prefer because it allows me keep it from polluting segmentation_user_layer.
function getGraphLoadedSubsource(layer: SegmentationUserLayer) {
  for (const dataSource of layer.dataSources) {
    const {loadState} = dataSource;
    if (loadState === undefined || loadState.error !== undefined) continue;
    for (const subsource of loadState.subsources) {
      if (subsource.enabled) {
        if (subsource.subsourceEntry.id === 'graph') {
          return subsource;
        }
      }
    }
  }
  return undefined;
}

function createAnnotationState(layer: SegmentationUserLayer) {
  const loadedSubsource = getGraphLoadedSubsource(layer)!;
  const source = new LocalAnnotationSource(loadedSubsource.loadedDataSource.transform, [], []);
  const displayState = new AnnotationDisplayState();
  const state = new AnnotationLayerState({
      localPosition: layer.localPosition,
      transform: loadedSubsource.getRenderLayerTransform(),
      source,
      displayState,
      dataSource: loadedSubsource.loadedDataSource.layerDataSource,
      subsourceIndex: loadedSubsource.subsourceIndex,
      subsourceId: loadedSubsource.subsourceEntry.id,
      role: RenderLayerRole.ANNOTATION,
    });
  layer.addAnnotationLayerState(state, loadedSubsource);
  return state;
}

Inside my MulticutSegmentsTool constructor, I have
    let initialized = false;
    this.layer.readyStateChanged.add(() => {
      if (!this.layer.isReady || initialized) return;
      initialized = true;
      createAnnotationState(this.layer);
      ...

I think your basic approach of adding the annotations is reasonable, given that they are really owned by the multicut tool, rather than by the datasource.
It would be good, though, to ensure they are only shown when the multicut tool is active, and are destroyed when the multicut tool is destroyed or the graph source is removed/deactivated.
Additionally, I think we don't want the points showing up in the normal annotation tab --- I suppose they should be shown in a separate list?
That would require modifying addAnnotationLayerState, so that they are somehow added to a different collection of annotation states, or something like that.  Maybe that can be deferred for now, though.

@googlebot I consent

@googlebot I consent.

hey @jbms been a while since the last update and I've accumulated some more questions about design decisions. We've been making good progress though I still need to address many of your previous points.

First, one that I ran into a while ago and it looks like I never brought it up, is forEachVisibleSegment. We have meshes per root id, so with no changes, it ends up making a request for each equivalence and it slows down mesh loading. We just need it to run callback on each rootObjectId callback(rootObjectId, rootObjectId).
We don't set the high bit for our root ids, but if we did, the check for isHighBitSegment is doing the opposite of what we need for graphene. I'm not sure if it would make sense/possible to use the high bit for graphene. We have a graphene version of isBaseSegmentId and we could define a isRepresentitiveId though we rely on data from our MultiscaleVolumeInfo to calculate base/root segments, so it would need to be a property/method on GraphSource.

I've implemented most of the Multicut functionality though I had to make some decisions I'm unsure about.
The multicut state is stored in two AnnotationLayerStates/sources. I have a class that makes it more convenient to interact with them called MulticutState. Am I right that neuroglancer only saves annotations attached to annotation user layers? Not when I add them to the segmentaton user layer.
Also, I attached this state to the SegmentationGraphSourceConnection so that it can be shared among several buttons attached to my GrapheneTab as well as the AnnotationLayerView on the GrapheneTab. The other buttons can possibly be removed, as I also added them to the makeToolActivationStatusMessageWithHeader but I still have the AnnotationLayerView. I see you added anchorSegment to SegmentationUserLayerDisplayState so maybe having the state attached to Tool isn't the right decision but I do feel like I just threw it on SegmentationGraphSourceConnection because I could.

Few smaller things I wanted to mention. I extended AnnotationLayerView and overrode get annotationStates to control what states to display in our additional multicut annotation list. Feels a bit hacky but I only had to make the smallest change in AnnotationLayerView to support it.
What is the reasoning behind this line? I wasn't sure about cases where the segmentationGroupState would change.

// Ensure we use the same segmentationGroupState while activated.
const segmentationGroupState = this.layer.displayState.segmentationGroupState.value;

I added the graphene tab using
if (segmentationGraph.tab) {
  const graphTab = segmentationGraph.tab;
  this.tabs.add(
    'graph', {label: 'Graph', order: -25, getter: () => {
      return graphTab(this);
    }});
  this.panels.updateTabs();
}

I think I should remove it in refCounted.registerDisposer though it looks like I would need to make some modifications to support removing tabs. Also, the tab adding is a bit crude so could use some input.

Hi Chris, thanks for your continued work on this!
Regarding forEachVisibleSegment: looks like maybe highBitRepresentative as a boolean value should be replaced by an enum that indicates one of several possible ways of iterating over the visible segments, e.g. SIMPLE_EQUIVALENCES, HIGH_BIT_REPRESENTATIVE_EXCLUDED, HIGH_BIT_REPRESENTATIVE_ONLY.

As far as storing the multicut seed points, you do need to explicitly store them somewhere in the json state if they are to be stored.  For annotation layers they are stored as an annotations property of the layer, but I think for this purpose it would make sense to store them within the json state of the multicut tool itself, since they are specific to that tool as far as I understand.  I made anchorSegment a property of the layer rather than the tool because it is used by both the split and merge tools, and it is convenient for them to share the same anchor rather than use separate ones.

Your tiny modification to AnnotationLayerView seems fine.
The segmentationGroupState is controlled by the "Linked segmentation" option on the "Rendering" tab.  That allows multiple segmentation layers to share the same set of selected segments and equivalences.  The goal there is to make sure we don't get into an inconsistent state if for some reason the user has changed it while the tool is activated.
As far as adding the additional Graph tab --- it is true that the current tab handling is not really designed for adding and removing tabs after the layer is initialized, and that will have to be fixed somehow.  A particular issue is what happens if the user has either selected the Graph tab, or dragged it out into a separate side panel.  In that case the tab won't initially exist when the layer is first created, because it is only added once the graphene data source is loaded.

Thinking a bit more about how to store the multicut points in the JSON state --- probably they should indeed be a property of the layer, storing it in the tool's own json state wouldn't work that well since that is associated with a specific key binding as well.

Would it be possible to make graph connection trackable? Another idea I have is to make annotations on UserLayerWithAnnotationsMixin trackable, maybe an option when adding via addAnnotationLayerState. Though I would need to be able to identify the annotation and reconnect it with the tool. I think I would need to identify it. It probably wouldn't make sense for any of the annotations that are added from datasources.
Also, I forgot to mention my changes to segmentation_renderlayer so I could replicate what we did in the seung lab branch.
The following features only affect the 2d rendering.

Added baseSegmentHighlighting (with UI) similar to baseSegmentColoring though it deals with the effect when hovering over a segment.

Added focusSegments and showFocusSegments (no UI) so you can set them and toggle them. When a segment is focused, it has transparent color and non focus segments are colored black with 50%. I want segment stated colors to override the transparency of the focus segment because I then use segmentStatedColors to color supervoxels within the focus segment.
A few things that would be clean up the code is a temporarySegmentStatedColors and adding transparency to segmentStated colors.

Added highlightColor (with UI). Colors the current being hovered over rather than the brighten effect.  Unfortunately there is no way to clear it through the UI. Value of undefined disables this feature. It would also be nice if this supported transparency. Looks like it will take a while before input="color" supports that. The default opacity on works fine for our use. It may make sense to remove the UI, I could also make a color + checkbox widget to be able to toggle it.

If it would help, I could break these segmentation_renderlayer changes into a separate PR.

Change the graphConnection member of SegmentationUserLayer to be a WatchableValue<SegmentationGraphSourceConnection|undefined> seems reasonable.
Can you explain a bit more what you have in mind as far as making annotations trackable?
Also, perhaps you can give a high-level overview of how segments are displayed in both the 2d and 3d view when using the multicut tool?
As far as focusSegments --- if I understand correctly, in the seung-lab branch when you begin a multicut operation, the single agglomerated segment you are splitting is a "focus segment" and everything else is shown darker?  Is that the only purpose of the "focusSegments" functionality?  With the current local equivalences support, instead, everything but the single segment being split is hidden when the split tool is activated.
In general the tools should only manipulate "temporary" display properties, not the display properties that are persisted in the JSON state, as otherwise the JSON state can become corrupted if you copy it while using a tool, etc.   That was the reason for introducing the temporary properties.  If necessary, additional temporary display properties can be added.
As far as baseSegmentHighlighting --- I think it would be ideal if we can avoid having this exposed in the UI in addition to baseSegmentColoring unless it is really necessary.  It looks like this is enabled automatically by the multicut tool; that would be better handled by a "temporary" display property.
In general one of the goals of Neuroglancer is to try to have the 2-d and 3-d views correspond as much as possible.  It seems that the correspondence is lost as far as the colors and highlighting during graphene multicut operatiions; however, to support that would require encoding the base supervoxel ids in the meshes served by graphene so I can see why it is currently not done.

When you add the first split point in multicut, the root segment is becomes the focus segment. (I made focus segment a set so it was more flexible but we also ever have one at a time). Removes all color, everything besides for the neuron is dark so the users know what they are splitting. Because we remove color, this frees us to color supervoxels red or blue if they are part of the sinks or sources.
We also use the highlight color so users know which group red/blue is currently active. We have an action to swap between the two groups and an action to add a point to the active group.
Here is an image of the multicut state in 2d, The clear sections show which root segment is in focus. I have 2 segments in the the sink/red group and 1 segment in the source/blue group.

It seems like maybe there isn't a need for a separate set of focusSegments, and instead there could just be a temporary notSelectedColor option of some sort?

Also, it is true that at the moment it is kind of annoying to add additional temporary display options due to the large number of levels of watchable that they need to be threaded through.  Unfortunately I don't have a good solution for that at the moment.  Longer term I'm planning to see about replacing the watchable/signal mechanism in Neuroglancer with something based on MobX, which I think would significantly simplify the code and reduce the chance of forgetting to install appropriate signal callbacks, and hopefully not at any performance cost.  However, that would be an enormous refactor and not likely to happen soon.

notSelectedColor for everything outside the focus segment? I first tried making the focus segment white though it definitely is harder to see the image data, which I think is one of the reasons we set the alpha to 0. I also think some people wouldn't enjoy the 3d being a white neuron but I can ask about that.
As far as saving the multicut state, I was thinking graphConnection implement TrackableValue, not just watchable. Have segmentation_user_layer call this.graphConnection.toJSON and restoreState.
I don't know if I have anything insightful as far as how to save annotations. I just know the annotations added to segmentation_user_layer aren't saved on reload though annotations added via annotation_user_layer are saved. Maybe multicut could create annotation_user_layers. I'm not sure how multicut would reconnect with annotations on load.

Anything saved in the Neuroglancer state needs a specific location/path in the JSON representation.
For "local://annotations" annotation layers, there is an extra "annotations" property that encodes the annotations.
What do you have in mind as far as the graph connection state --- perhaps something like?
"graphConnection": {
  "multicut": {
    "include": [
      {"position": [1, 2, 3], "segment": "123"}
    ],
    "exclude": [
      {"position": [4,5, 6], "segment": "456"}
    ]
  }
}

Alternatively "multicut" could just be a property of the layer itself.  Is there additional state you need to save in the graph connection?

You have a good point that white is not a good color choice for the cross-section view, and I guess maybe not ideal for the 3d view either.
An alternative would be to use a different color, like "green".
In general I am just keen to keep the correspondence between the 2d and 3d views as much as possible.

something like that for the multicut state would work. We would also need to store the root id as well.
"graphConnection": {
  "multicut": {
    "focusSegment": "789",
    "include": [
      {"position": [1, 2, 3], "segment": "123"}
    ],
    "exclude": [
      {"position": [4,5, 6], "segment": "456"}
    ]
  }
}

Besides multicut, we also want to store the time (if they are viewing a historical segmentation). Two points for our find path tool that I haven't added to this PR yet. Possibly the anchor segment for our merge and split, or we could add coordinates to go along with the existing anchorSegment property.

Sven said that you had an idea on where we could store the multicut state. I believe he said something about the datasource metadata. If that's correct, how would that be done?
It was also mentioned a while aback about a way we could set default key bindings (and alter it so that shift wasn't necessary for some tool binds) with our build config. Is that functionality that we need to add or is it existing?

For the multicut state, I recommend storing it within the datasource, i.e.:
{"layers": [
  {"name": "segmentation",
   "source": {
      "url": "graphene://...",
      "state": {"multicut": ...},
    },
  },
]
}

That will require changes to layer_data_source.ts to parse the state (e.g. layerDataSourceSpecificationFromJson) and probably various other places to pass the state around and handle the toJSON path as well.
Adding default key bindings in build config is functionality you will need to add.

I'm back to focusing on this PR, I know we all want to wrap it up soon.
Does this look like the way you would implement states in datasources?
https://github.com/google/neuroglancer/pull/340/commits/93fb56b37bb2d0a39c0eb3237fb8b4bdd4a7592f
Also as far as default key bindings.
By default we could have it so that default key bindings get bound as long as a tool does not already have a key bound to it nor is the key bound to anything else.
In addition, we could have an option so that certain keybinds can consider the active layer, in which case they can be bound to multiple tools at the same time. We would bind those keys to all of the related tools as long as they don't have a key around bound to it. This feature seems like it would be more difficult to implement and you said it is a behavior you are trying to move away from.
I think for now we should focus on just the single tool binds. Our users are used to the selected layer affecting the keybinds though we aren't considering it critical.
You said "default key binding should occur when the layer is created". You said it would be tricky. Would it mean we have a path where a key can trigger a tool with no corresponding button (since it may not be created yet)?

If you just add some additional global "split" / "merge" key bindings (not using shift+letter) as an additional build-time option, to match the current behavior of the seung lab branch, then there should be no conflict.  I think that is the simplest approach since it involves the fewest changes.
The buttons themselves are just part of the UI panel, and are only created when the panel itself is displayed, so binding of keys should not be triggered by that.
The issue I was referring to with regard to layer creation is that when the layer is first created, the data sources have not yet been loaded.  Only once the data sources are loaded do we know whether there is a graphene source (at least under the current design, particularly since you can have a redirection so it can't be determined from the data source URL alone).  However, having key bindings change non-deterministically as data sources are loaded also seems unfortunate.

I removed the graphene specific code from the core mesh classes. I added getFragmentKey to the MeshSource interface though we need it to return a fragment key and a fragment id. I'm not sure what to name it, I could split it into two separate functons getFragmentKey and getFragmentId. Graphene doesn't use the original fragment key because we want to re-use meshes even if the root id changes.
I also cleaned up the graph tab code though it still feels crudely implemented.
I also wanted to bring up my last iteration of saving the multicut state https://github.com/google/neuroglancer/pull/340/commits/03f9da11e4b8a7810169d19db03b99d548e5405c

After talking to Sven, we decided to try to make. this PR more manageable, I'm going to break out the proofreading code to a separate PR.

closing, is being split up into multiple PRs


How to add configuration key

Hello,
I am using one variable (setPoint), I want to give access to CMS users to change that setPoint variable. Need to make the setPoint variable as the configuration key.
Can you please tell me how to make the setPoint variable as the configurationKey?
My expectation is, the CMS user should be able to change that configurationKey (setPoint).
Is it possible?

Hi @demirschmid61,
Yes, it is possible. You can declare custom configs which the library will handle like any other configuration then. Here is the how-to: https://github.com/matth-x/MicroOcpp/issues/248#issuecomment-1883585103

@matth-x ,
Thank you very much, I'll just implement it in the same way.


Create login and signup views

Header nav should display login or logout depending on current session status

pushed to develop


Compile error: Attempted import error: 'registerPlugin' is not exported from '@capacitor/core'.

Describe the bug
Attempting to build Ionic React app after importing this plugin.
Failed to compile.
<EMAIL_ADDRESS>Attempted import error: 'registerPlugin' is not exported from '@capacitor/core'.
@capacitor/core 2.4.0
@Ionic/core 5.5.4
@ionic/react 5.5.4
@capacitor-community/keep-awake 2.2.0
To Reproduce
Steps to reproduce the behavior:

import { KeepAwake } from '@capacitor-community/keep-awake'
add    const keepAwake = async () => { await KeepAwake.keepAwake()}
attempt to build

Desktop (please complete the following information):

OS: macOS big sur
Version 11.1

Additional context
Add any other context about the problem here.

@msacchetti make sure you're using version 1 of the plugin with @capacitor/core 2.4.0 since version 2 supports Capacitor 3. Also see the changelog


Stimulus: Panel and Block should accept data attributes

Is your proposal related to a problem?
It is hard to implement general reusable Stimulus controllers without having the ability to easily pass data attributes into various FieldPanels and Blocks.
Describe the solution you'd like
Ability to pass attributes in the constructor as static values or callable.

Closing as duplicate of https://github.com/wagtail/wagtail/issues/10133
@pySilver feel free to add comments to that issue - I think it covers things.
There is also a WIP PR up https://github.com/wagtail/wagtail/pull/10323


Task list 1

[ ] Turn on GitHub Pages
[ ] Outline my portfolio
[ ] Introduce myself to the world

[ ] Turn on GitHub Pages
[ ] Outline my portfolio
[ ] Introduce myself to the world

[x] Additional markup is supported, including @mentions, #references, links, emphasis, and HTML tags.
[x] List syntax is required.

You can nest lists below, too!

[x] This item is completed.
[ ] This item is not complete.


Reduce logo size

On Edge at 100% on a 1024 x 768 screen, top bar gets cut off.  Need to make the logo sizes smaller.

Fixed.


feat: data replication

Can this be closed now that #224 is merged or is there another task missing?

It can be closed for now.


Amount won/lost

Show how much every player won/lost during the hand.

I would really appreciate this feature! :)


Heavens-Above Timezone support broken...?

Timezone support appears to be broken in current version as the timezone isn’t passed to Heavens-Above. See...
https://github.com/stleary/stars-at-night/blob/750a4de1aabc0cb6a5bceb30ca362ad93169adc4/src/class-planet-passes.php#L66
https://github.com/stleary/stars-at-night/blob/750a4de1aabc0cb6a5bceb30ca362ad93169adc4/src/class-satellite-passes.php#L67
https://github.com/stleary/stars-at-night/blob/750a4de1aabc0cb6a5bceb30ca362ad93169adc4/src/class-satellite-passes.php#L153
That said, Heavens-above isn’t recognising BST as a valid timezone when passed in the URL anyways, so when manually uncommenting those lines for UK users at present date/time, Heavens-above throws an error. When configuring locally on Heavens-Above, GMT produces correct times, so something’s squiffy in their API relating to appropriate use of GMT / BST.
eg:

https://www.heavens-above.com/main.aspx?lat=53.6833&lng=-1.5059&loc=Wakefield&alt=0&tz=BST produces application error.

https://www.heavens-above.com/main.aspx?lat=53.6833&lng=-1.5059&loc=Wakefield&alt=0&tz=GMT produces correct date/time info, even tho the timezone is actually incorrect.

Have fixed this locally in my copy by uncommenting line at the above locations, and replacing...
https://github.com/stleary/stars-at-night/blob/750a4de1aabc0cb6a5bceb30ca362ad93169adc4/src/class-planet-passes.php#L60
https://github.com/stleary/stars-at-night/blob/750a4de1aabc0cb6a5bceb30ca362ad93169adc4/src/class-satellite-passes.php#L61
https://github.com/stleary/stars-at-night/blob/750a4de1aabc0cb6a5bceb30ca362ad93169adc4/src/class-satellite-passes.php#L147
...with:
$heavensAboveTZ = $dateTime->format ( 'T' ) == 'BST' ? 'GMT' : $dateTime->format ( 'T' );
...as otherwise everything was showing up for me with times an hour earlier than they should’ve been.

Investigating...

Hi @PatchworkBoy, thanks for bringing up this issue. I think in this case, it is working as designed. My recollection is that heavens-above does not use timezone in the UI when selecting locations, so I decided not to use it in the REST API either. It seems to be working correctly. In the shortcode, instead of timezone code 'BST', try using the PHP-supported string, 'Europe/London'. After all, we don't want to make users change their shortcode parameters twice a year. I will take an action item to clarify the documentation regarding how to specify timezones, and look into an enhancement request to allow the use of timezone abbeviations like BST.

“...as otherwise everything was showing up for me with times an hour earlier than they should’ve been.”
The above was the case with unaltered code and time zone set to “Europe/London” as per standard configuration instructions for the plugin. It coming back with nonBST times set that way was what caused me to look at the code to start with.

@PatchworkBoy Sorry, missed this comment until just now, will investigate. Suspect there may be a  problem with how the PHP lib processes the Europe/London timezone

@PatchworkBoy I checked against Europe/London time and the values seem to be correct.
Some background:
This is a WordPress plugin that is implemented in PHP. The WordPress shortcode passes in required parameters including local latitude, longitude, timezone, and number of days to display. It only supports PHP-based timezone names. The algorithms are believed to work correctly even for timezones that are 30 or 45 minutes offset from UTC, and when the number of days spans a time change (e.g. transition from standard time to daylight savings time). Here is how it works:
Sunrise/sunset
The latitude, longitude and timezone offset in hours is passed to the PHP functions, date_sunrise() and date_sunset(). These functions are called repeatedly for as many days ahead have been specified in the shortcode.
Moonrise/moonset
The latitude, longitude, timezone offset in minutes, and the original timezone value is passed to code ported from this project: https://dxprog.com/entry/calculate-moon-rise-and-set-in-php where the moon times are calculated and returned. This function is called repeatedly for as many days ahead have been specified in the shortcode.
Planets, ISS, and Iridium flares
The latitude and longitude are passed via the REST API to the http://www.heavens-above.com webserver. Timestamps are returned in UTC. This value is then rendered in the specified timezone. This function is called repeatedly for as many days ahead have been specified in the shortcode.
Request for more information
Since there are 3 different mechanisms for calculating local time, it is unlikely that all of them will be wrong at the same time, unless there is a problem in the php timezone library.  If you have noticed that any times are off by more than 2 minutes or so, please include the following information:

Date when the error was noticed
Shortcode parameter values
Screenshot or list of the actual incorrect values

I will keep this issue open for a few months in case any problems are discovered.


.NET 2.1 End-Of-Life

.NET Core 2.1 will reach End of Support on August 21, 2021
https://devblogs.microsoft.com/dotnet/net-core-2-1-will-reach-end-of-support-on-august-21-2021/
We use 2.1 in the following areas:

Running tests unit/live/perf/stress.
Cross-compiling packges to target 2.1.
Referencing BCL packages that might be part of 2.1 release https://github.com/Azure/azure-sdk-for-net/blob/main/eng/Packages.Data.props#L62-L75

For each of these, we need to make a decision and possibly move to 3.1 (Current LTS)

cc @weshaggard


Rename PyBouncerInfo field

This change is

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (bd986b3) 71.36% compared to head (8b99c2e) 71.55%.

Files
Patch %
Lines

...ates/native_blockifier/src/transaction_executor.rs
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1301      +/-   ##
==========================================
+ Coverage   71.36%   71.55%   +0.19%
==========================================
  Files          59       59
  Lines        7225     7298      +73
  Branches     7225     7298      +73
==========================================
+ Hits         5156     5222      +66
- Misses       1657     1664       +7
  Partials      412      412

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[Fix] Backfill's date-picker date value mismatch

Description

The problem existed due to the use of .toISOSString() when formatting the selected date, which will add time zone offset. Fixed using (the already exists) moment.
How Has This Been Tested?

Before

After

Checklist

[x] The PR is tagged with proper labels (bug, enhancement, feature, documentation)
[x] I have performed a self-review of my own code
[ ] I have added unit tests that prove my fix is effective or that my feature works
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation

[ ] If new documentation has been added, relative paths have been added to the appropriate section of docs/mint.json

cc: @johnson-mage

@edmondwinston After saving a backfill date and then going back to edit it, does the start/end date go back 1 day for you? For example, please see the gif below. I would expect the date to stay the same upon clicking Edit, making no changes, and then saving again, but if I click Edit, make no changes, and then save, the start/end date goes back 1 day.

@johnson-mage
I figure the problem is that we store datetime in UTC, and then when displaying we're parsing them to UTC again. Tested the latest code with different time zones, but please also try it yourself.
Also, I'm having the idea of making another PR removing the convertToUtc option, since we would never be converting if we always store them in UTC from the first place. shouldDisplayLocalTimezone() doesn't have to be call at every components here and there anymore - they could be called when parsing. What do you think?

I figure the problem is that we store datetime in UTC, and then when displaying we're parsing them to UTC again. Tested the latest code with different time zones, but please also try it yourself.

Cool, I'll test it out.

Also, I'm having the idea of making another PR removing the convertToUtc and localTimezone option, since we would never be converting if we always store them in UTC from the first place. shouldDisplayLocalTimezone() doesn't have to be call at every components here and there anymore - they could be called when parsing. What do you think?

This would require a lot of testing, since there's a lot of different areas in the app that display times and could be hard to catch everything. I think there are just a bunch of different scenarios where the datetimes are not always a consistent format, which is why you have several different methods for parsing the dates. It could definitely use some cleanup, but doesn't seem high-priority if the times are being displayed correctly already. The issue you ran into with selecting the date from the datepicker definitely needs to be fixed, though it seems to be an edge case that doesn't happen for most users.


[Artworks] Crash while paging

https://rink.hockeyapp.net/manage/apps/37020/app_versions/225/crash_reasons/122479397
RCTFatalException: Unhandled JS Exception: this.props.artworksQuery is not a function. (In 'this.props.artworksQuery(this.props.relay.route.params.artistID,t)', 'this.props.artworksQuery' is undefined)', reason: 'Unhandled JS Exception: this.props.artworksQuery is not a function. (In 'th..., stack:
value@625:943
value@625:2897
scrollResponderHandleScroll@362:1586
handleScroll@360:2499
a@258:71
o@256:391
a@256:582
f@254:159
g@254:262
i@260:102
processEventQueue@254:1382
s@304:92
handleTopLevel@304:181
_receiveRootNodeIDEvent@303:613
receiveEvent@303:714
value@196:3100
<unknown>@196:1319
k@196:413
value@196:1291

Closing in favour of #100.


Add AMP (Accelerated Mobile Pages) output

Google has started to support AMP.
So It would be better if I can make AMP pages with hugo.
Thanks
AMPProject

🖖
Agree

:+1:

OK, I read about and it looks interesting. It got some pretty powerful companies behind it, so I guess it's gonna stay.
If I understand this correctly

From Hugo's point of view, this is another output representation, lets name it amp
amp and others can have their own templates (they normally would, so:

if index-amp.html exists, that template will be used for the amp output.

The alternative output will be placed in a subfolder of the main representation, so "/my-post/index.html" and "/my-post/amp/index.html"
Alternative outputs should be a list in site config (["amp", "???"] and adding one will double the page output (including paginator pages)
We might have to think about URL refs
The user is responsible for adding link rel="amphtml" and the other way around in the templates

Does the above make sense?
/cc @spf13

Hi,
We need it! It seems there's already something for jekyll https://github.com/juusaw/amp-jekyll as well as for wordpress https://wordpress.org/plugins/amp/
BR

@bep @spf13
hugo should really support AMP asap.
@bep
Your list make sense. But please consider that you need to add also a canonical tag with the html version of the page, and from the html version a rel=amphtml link to the amp versions URL.
So maybe we need the variables like URL.HTMLVERSION and URL.AMPVERSION?

hugo should really support AMP asap.

This is open source. ASAP is as soon as you want.

that you need to add also a canonical tag with the html version of the page, and from the html version a rel=amphtml link to the amp versions URL.

This is in my list as a "end user responsibility" (simply add it in the templates)

Is there a need for this, rather than just applying AMP on the site in general? This way, hugo doesn't have to know about AMP. An argument for this could be the ability to have AMP content and AMP-violating content simultanously, but I suspect that one in this case should consider just abiding by AMP.
The ability to render all content in multiple layout sounds like a bit of an overhead, but doable. The solution should definitely not know what AMP is, and any AMP-ness should be completely user-defined. (AMP is not a magic bullet, and slows down some sites considerably - I also do not approve of the supertracking features it was designed to have).
@bep: index-{name}.html would not work with non-ugly-urls. What about rendering the entire thing to a subfolder, /{name}, with pages the normal places, /{name}/posts/wee? This would mean that you could nit have a section with the same name as an additional layout, but might be a bit cleaner, and would make linking more logical. This could also be used to have things like /beta/ for a new layout.

My take on this is that there's a lot of unknowns around AMP and what the best way to implement it is which makes sense since it's so new. For example, the wordpress plugin mentioned appends /amp/ to the end of urls (and doesn't support all pages yet), where the Jekyll one does something entirely different.
I believe that ideally Hugo would support AMP in an integrated way and have support for it integrated into the theme system. Ideally a user would be able to have their content, download a AMPable theme and it would just work. The user wouldn't need to know anything about AMP.
There are a few dependencies to adding full AMP support including adding image processing to satisfy the "amp-img components, like all externally fetched AMP resources, must be given an explicit size (as in width / height) in advance, so that the aspect ratio can be known without fetching the image." requirement.
Really what needs to happen is for someone to take the initiative and come up with a proposal for how to add AMP support into Hugo.

I thought a bit about getting the appropriate width/height on images, and thought of 3 possible solutions that made sense:

Having this be a post-process step on the HTML output. Possible, but really ugly.
Mangle markdown processors to have runtime-replaceable export mechanisms that default to their current state. A bit intrusive in other projects, but not too bad. This would allow hugo to look up the image dimensions if necessary, and for hugo to change a tag if a layout asks for it.
A new command for inserting an image that allowed manual input of the dimensions, or automatic fetching if hugo felt like it. This could be done without messing around with the markdown processors.

I think 2 is the neatest, with 3 being the quickest.
I really hope that we could reach AMP compatibility without amp-awareness in hugo. Dimensions on image tags are helpful to all layouts, not just mobile or AMP, as it avoids jumpy content and wasted clock-cycles on recalculated styles.
I vote for a mechanism where a layout can be a "group" of layouts that should all be run for all content, with each sub-layout having some local settings for the export (dimensions on images, what tag to use, ...) and their own destination sub-folder. That would allow for themes to both have normal and AMP in one package, while being more generic, and allowing some of the features to be applied to normal themes (dimensions on images). It would allow us to be more flexible in case of changes to the AMP spec as hugo doesn't care, and would also allow someone to make a Facebook Instant Articles variant of their layout, or whatever other custom layout they'd want to make.

This theme is for Jekyll that support AMP. It is very popular. Their approach is:

Google AMP has it's own set of special html tags for including content. You should use these instead of normal Markdown or HTML tags.

I don't think this is a good approach.
Solution 2 that proposed from @joushou is a good solution and makes changing between themes easy. It does not required you to change the contents to change themes.

In addition, markdown processor need to be update to allow :
Inline-style:

Reference-style:

To be transform in
We need image size detection.
And CSS inlining.
BR

I do not believe CSS inlining is in any way a required feature. That's just a matter of inlining the stylesheet for an AMP-specific layout.
The ability to output amp tags, as well as detecting image sizes (which I would like to be separate, so that regular sites can benefit from properly sized img tags as well), has already been mentioned. There are 3 different approaches to the implementation in my previous comment.

Did anyone started to work on this topic ?

This issue has been automatically marked as stale because it has not been commented on for at least four months.
The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still valuable, please open a proposal at https://discuss.gohugo.io/.
This issue will automatically be closed in four months if no further activity occurs. Thank you for all your contributions.

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.
If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

This will be covered by Hugo 0.20 + https://github.com/spf13/hugo/issues/3220


Added semantic-release-monorepo

:tada: This PR is included in version 1.0.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Replicate only give me error 500

Hi,
Im trying make a simple call for "meta-llama-3.1-405b-instruct" but it always return erro 500:
DEBUG 2024-10-23 05:49:13,367 _trace receive_response_headers.complete return_value=(b'HTTP/1.1', 500, b'Internal Server Error', [(b'Date', b'Wed, 23 Oct 2024 05:49:13 GMT'), (b'Content-Type', b'application/json; charset=UTF-8'), (b'Content-Length', b'41'), (b'Connection', b'keep-alive'), (b'Preference-Applied', b'wait'), (b'Report-To', b'{"endpoints":[{"url":"https:\\/\\/a.nel.cloudflare.com\\/report\\/v4?s=26t4irv%2Bd915fWOFYROvw%2BhoJFgA5aEquIeLbjWo0ZetlQOZ5bwRGa8wxmM53behG7hVKjDiP6NTGAD38EgI%2B7jip3KD%2FWamYc0Hj9th%2BeBi%2BCxWZaoYwQJ2HkveKno9YF6W"}],"group":"cf-nel","max_age":604800}'), (b'NEL', b'{"success_fraction":0,"report_to":"cf-nel","max_age":604800}'), (b'Vary', b'Accept-Encoding'), (b'Strict-Transport-Security', b'max-age=15552000'), (b'Server', b'cloudflare'), (b'CF-RAY', b'8d6f71069b60e12d-GIG'), (b'alt-svc', b'h3=":443"; ma=86400')])
INFO 2024-10-23 05:49:13,372 _client HTTP Request: POST https://api.replicate.com/v1/predictions "HTTP/1.1 500 Internal Server Error"
DEBUG 2024-10-23 05:49:13,373 _trace receive_response_body.started request=<Request [b'POST']>
DEBUG 2024-10-23 05:49:13,374 _trace receive_response_body.complete
DEBUG 2024-10-23 05:49:13,374 _trace response_closed.started
DEBUG 2024-10-23 05:49:13,374 _trace response_closed.complete
ERROR 2024-10-23 05:49:13,374 flux Replicate error: ReplicateError Details:
status: 500
detail: An unexpected error occurred

My code:
model = replicate.models.get("meta", "meta-llama-3.1-405b-instruct")

prompt_input = "say hello in python"

result = replicate.run(
    model.latest_version,
    input={
        "top_k": 50,
        "top_p": 0.9,
        "prompt": prompt_input,
        "max_tokens": 1024,
        "min_tokens": 0,
        "temperature": 0.6,
        "presence_penalty": 0,
        "frequency_penalty": 0,
    },
)

When i see in Replicate dashboard the request/response is there and the data is generated. But it is not returned when call the API returning error 500.
Im using lib replicate==1.0.2.
What is wrong?
Thanks.

Thank you for the report! The 500 error is a problem on our side which we'll work on fixing separately, but the good news for you is that you don't need to use model.latest_version on this model to get the latest version. You can run:
prompt_input = "say hello in python"

result = replicate.run(
    "meta/meta-llama-3.1-405b-instruct",
    input={
        "top_k": 50,
        "top_p": 0.9,
        "prompt": prompt_input,
        "max_tokens": 1024,
        "min_tokens": 0,
        "temperature": 0.6,
        "presence_penalty": 0,
        "frequency_penalty": 0,
    },
)

You can find other examples of how to call this model from Python on our website.


Creating pull request for 10.21105.joss.02013

If this looks good then :shipit:

@whedon accept deposit=true


XD-3519: Rabbit Taps GH-193

Resolves #193

instead of publishing to the default exchange, producers now publish to a topic exchange, to which the main queue is bound
taps on a stream simply bind a queue to the same exchange with a name including the group for the tapping stream and a
routing key pattern #
this means that multiple instances of the same tap stream will compete but multiple tap streams will get a copy
for partitioned data, a single topic exchange is used, which each partition queue bound with its name as the routing key
this means taps on partitioned data see the consolidated messages

Add group to ChannelBindingServiceProperties

What would be the impact if we replace rather than deprecate the existing bindPubSubConsumer(..) method?

For some reason, I thought the Binder API was being used directly in s-c-df so I was trying to avoid issues there; but now I see it's not so I agree, it can be removed.

Rebased; pushed.

Pushed

squashed and merged as https://github.com/spring-cloud/spring-cloud-stream/commit/a375e6126009b111a3992ae47489b5630f4e3942

@garyrussell @markfisher does this get automatically pushed to snapshots?

Yes, but only if the build passes :frowning:
https://build.spring.io/chain/result/viewChainResult.action?planKey=SCS-SMJLE&buildNumber=212

@garyrussell thanks, I went to see if it fixed my issue and it didn't, so that is why :-)

@mbogoevici any ideas...
java.lang.RuntimeException: org.springframework.beans.factory.BeanInitializationException: Property 'cleanup.policy' must be set to 'compact' on offset topic
	at org.springframework.integration.kafka.listener.KafkaTopicOffsetManager.validateOffsetTopic(KafkaTopicOffsetManager.java:306)

Yeah,
Not sure how the test environment got broken like this. Need to check the PR.

OK, this is fixed now in master. The artifacts have bee successfully deployed as per https://build.spring.io/browse/SCS-SMJLE-214/


Feedback from CaptainMinnette#8435

From CaptainMinnette :
Very minor note, but one of the bullet points in the Windows info is a dash instead of a bullet.

From Faith | Am Girl! :
It's intentional, it relates to the previous point, although the lack of whitespace can make it confusing at times.


Incompatibility with BouncyCastle 1.5x?

We've had some issues using passkit4j with the newest BouncyCastle library. The exception and stacktrace are pretty perplexing as well!
Core exception:
2016-06-14 20:49:02,479 ERROR (web.errors.GrailsExceptionResolver) VerifyError occurred when processing request: [GET] /our/mobile/app/endpoint/
Bad type on operand stack
Exception Details:
  Location:
    org/bouncycastle/cms/CMSSignedDataGenerator.generate(Ljava/lang/String;Lorg/bouncycastle/cms/CMSProcessable;ZLjava/security/Provider;Z)Lorg/bouncycastle/cms/CMSSignedData; @301: invokevirtual
  Reason:
    Type 'org/bouncycastle/asn1/ASN1ObjectIdentifier' (current frame, stack[2]) is not assignable to 'org/bouncycastle/asn1/DERObjectIdentifier'
  Current Frame:
    bci: @301
    flags: { }
    locals: { 'org/bouncycastle/cms/CMSSignedDataGenerator', 'java/lang/String', 'org/bouncycastle/cms/CMSProcessable', integer, 'java/security/Provider', integer, 'org/bouncycastle/asn1/ASN1EncodableVector', 'org/bouncycastle/asn1/ASN1EncodableVector', integer, 'org/bouncycastle/asn1/ASN1ObjectIdentifier', 'java/util/Iterator', 'org/bouncycastle/cms/CMSSignedDataGenerator$SignerInf' }
    stack: { 'org/bouncycastle/asn1/ASN1EncodableVector', 'org/bouncycastle/cms/CMSSignedDataGenerator$SignerInf', 'org/bouncycastle/asn1/ASN1ObjectIdentifier', 'org/bouncycastle/cms/CMSProcessable', 'java/security/SecureRandom', 'java/security/Provider', integer }
  Bytecode:

  ... <lots of hexdump> ...

Additional stack trace:
...
	at com.ryantenney.passkit4j.sign.PassSignerImpl.createGenerator(PassSignerImpl.java:136)
	at com.ryantenney.passkit4j.sign.PassSignerImpl.<init>(PassSignerImpl.java:128)
	at com.ryantenney.passkit4j.sign.PassSignerImpl$Builder.build(PassSignerImpl.java:122)
	at com.todaytix.cms.PassbookService.createPassForTransaction(PassbookService.groovy:115)
...

The core issue seems to be a change made for BouncyCastle 1.47, wherein DERObjectIdentifier was renamed to ASN1ObjectIdentifier.
@jessestuart has been troubleshooting a bit here at @TodayTix.

Thanks for the heads up. I guess it would make sense to upgrade the library to use the latest BC and this fix this issue. I'll take a look at it a little later and see if the upgrade goes smoothly.

Hi,
The problem is when you have two distinct dependency of bouncycastle.
For example: bcprov-jdk16 (v1.46) and bcprov-jdk15on (v1.54).
I had this two dependencies ones and I deleted the first one.
I could to make a pass with bcprov-jdk15on (v1.54).

@ryantenney,
@Waxampu is absolutely right; this is yet another Grails dependency nightmare.
I have also verified that passkit4j does build and pass tests with bouncy castle 1.54, FYI.

Seems this is all fine and dandy!


Log in to IATI Connect (in order to include community posts in the feed)

Fixed in 39a1c15aa1afc83a6f78ebf9de691eb7f55ec052.


Proof of concept: Metal writer

Current coverage is 99.41% (diff: 70.00%)

Merging #129 into master will decrease coverage by 0.58%

@@           master       #129   diff @@
========================================
  Files          80         81     +1
  Lines        1012       1032    +20
  Methods         0          0
  Messages        0          0
  Branches      171        178     +7
========================================
+ Hits         1012       1026    +14
- Misses          0          2     +2
- Partials        0          4     +4

Powered by Codecov. Last update e232a03...1c51757

Thanks for the PoC! We will probably add something like this at some point. I'm closing this PR for now to clean up the PR view.


pod with VF doesn't get NODE GUID

What happened?
After create pod use this repo demo, I can see the VF use ibstat or ibdev2netdev. But I find VF‘s NODE GUID is 0000:0000:0000:0000. And when I do ib_write_bw test. It shows
Couldn't allocate MR
failed to create mr
Failed to create MR
 Couldn't create IB resources

What did you expect to happen?
What are the minimal steps needed to reproduce the bug?
Anything else we need to know?
Component Versions
Please fill in the below table with the version numbers of components used.

Component
Version

SR-IOV Network Device Plugin

SR-IOV CNI Plugin

Multus

Kubernetes

OS

Config Files
Config file locations may be config dependent.
Device pool config file location (Try '/etc/pcidp/config.json')
Multus config (Try '/etc/cni/multus/net.d')
CNI config (Try '/etc/cni/net.d/')
Kubernetes deployment type ( Bare Metal, Kubeadm etc.)
Kubeconfig file
SR-IOV Network Custom Resource Definition
Logs
SR-IOV Network Device Plugin Logs (use kubectl logs $PODNAME)
Multus logs (If enabled. Try '/var/log/multus.log' )
Kubelet logs (journalctl -u kubelet)

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

Hi @jeffreyyjp,
please take a look on the sriov-network-operator it should help you configure the IB https://github.com/k8snetworkplumbingwg/sriov-network-operator/blob/master/doc/ib-vf-guid-static-configuration.md

@SchSeba Got it. Thank you.


Broken link - Build a pipeline

Hello everyone, in the following page the link for ContainerOp (broken link) is outdated. I think it should point to this link. If my guess is correct, I can open a small PR for it, thanks :)

looks like this issue is fixed

the ContainerOp link on https://www.kubeflow.org/docs/components/pipelines/v1/sdk-v2/build-pipeline/#understanding-pipelines seems to be working


Fix Card and update packages

Please follow commit message guidelines as documented in ViBE - Getting Started.

Make sure commits are signed. Instructions are here


AP-4826: Add LAA reference link question

What
AP-4826
Add ‘What is the LAA reference of the application you want to link to?’ question. Users will see this question if they have selected yes to either family or legal linking.
For MVP, they will be restricted to only searching by LAA reference, with an exact match of ref number required.
A message is displayed if:

no case is found
a case is found, but it has not yet been submitted - this will provide a link to the application that needs to be submitted via the search

Checklist
Before you ask people to review this PR:

Tests and rubocop should be passing: bundle exec rake
Github should not be reporting conflicts; you should have recently run git rebase main.
The standards in the Git Workflow document on Confluence should be followed
There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
The PR description should say what you changed and why, with a link to the JIRA story.
You should have looked at the diff against main and ensured that nothing unexpected is included in your changes.
You should have checked that the commit messages say why the change was made.

looks good , I have added some suggestions for some possible additional tests


Improve definition file caching

Why
Currently, architecture icon and definition file caching is based on a hash of static values such as file names, and hash values do not change permanently, so changes to architecture icons and definition files are not reflected.
File caching is implemented as internal/cache.
What

Use HTTP Etag caching for instant updates and reduce unnecessary data transfers.

Confirmed that the cache is automatically replaced by updating the definition file and use cache after it
$ ./awsdac examples/vpc-natgw.yaml -v
INFO[0000] input file: examples/vpc-natgw.yaml
INFO[0000] Load DefinitionFiles section
INFO[0000] Fetch definition file from URL: https://raw.githubusercontent.com/awslabs/diagram-as-code/main/definitions/definition-for-aws-icons-light.yaml
INFO[0000] [internal/cache/cache.go] FetchFile https://raw.githubusercontent.com/awslabs/diagram-as-code/main/definitions/definition-for-aws-icons-light.yaml
INFO[0000] [internal/cache/cache.go] Found previous Etag cache. Use HTTP Etag value "d4dce883bb896a1a248e8886f8e485fc949977307e3b238601a0c90147c81fd1"
INFO[0000] [internal/cache/cache.go] Server respond with HTTP 200
INFO[0000] [internal/cache/cache.go] Server respond with Etag. Save Etag value "52aa0a4e488e0af8a02de5e92a4875d602ab77c1e18c80c7d10a4864a6e316ed"
INFO[0000] Read definition file from cache file: /Users/kitayu/.cache/awsdac/850960c5c172c277f880286d0349c39c-definition-for-aws-icons-light.yaml
...
$ ./awsdac examples/vpc-natgw.yaml -v
INFO[0000] input file: examples/vpc-natgw.yaml
INFO[0000] Load DefinitionFiles section
INFO[0000] Fetch definition file from URL: https://raw.githubusercontent.com/awslabs/diagram-as-code/main/definitions/definition-for-aws-icons-light.yaml
INFO[0000] [internal/cache/cache.go] FetchFile https://raw.githubusercontent.com/awslabs/diagram-as-code/main/definitions/definition-for-aws-icons-light.yaml
INFO[0000] [internal/cache/cache.go] Found previous Etag cache. Use HTTP Etag value "52aa0a4e488e0af8a02de5e92a4875d602ab77c1e18c80c7d10a4864a6e316ed"
INFO[0000] [internal/cache/cache.go] Server respond with HTTP 304
INFO[0000] [internal/cache/cache.go] Use cache based on matched HTTP Etag
INFO[0000] Read definition file from cache file: /Users/kitayu/.cache/awsdac/850960c5c172c277f880286d0349c39c-definition-for-aws-icons-light.yaml


/etc/systemd/system/service.d/lxc.conf generates a lot of logs "Unknown key name 'ProtectProc' in section 'Service', ignoring."

Required information

Distribution: ubuntu
Distribution version: 20.04
The output of "lxc info" or if that fails: (I don't think the full lxc info is necessary here)

Kernel version: 5.4.0-72-generic
LXC version: from snap : 4.0.5
LXD version: lxd from snap version 4.0.5
Storage backend in use: ZFS

Issue description
A new file is now added at this location {{/etc/systemd/system/service.d/lxc.conf}}. This file contains the following lines:
[Service]
ProtectProc=default
ProtectControlGroups=no
ProtectKernelTunables=no

This make other services log this:
Apr 30 20:25:19 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:19 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:20 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:20 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:20 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:20 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:20 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:20 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:25:20 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:26:11 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:26:11 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:26:12 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:26:12 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:26:12 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:26:12 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.
Apr 30 20:26:12 example-20 systemd[1]: /etc/systemd/system/service.d/lxc.conf:2: Unknown key name 'ProtectProc' in section 'Service', ignoring.

I would like to avoid to manage this file to remove this line, since for some service, this generate a lot of useless noise.
The container is running ubuntu 20.04, this is recent since other containers I created last week don't have this file.
Steps to reproduce

lxc init with ubuntu 20.04
run a systemd service

Ok thanks, does the settings in this file make sense even with security.nesting set to true?
Currently the file content is:
[Service]
ProtectProc=default
ProtectControlGroups=no
ProtectKernelTunables=no

From https://www.freedesktop.org/software/systemd/man/systemd.exec.html , it looks like since ProtectSystem is available with security.nesting and it implies ProtectControlGroups and ProtectKernelTunables, this file should be removed from any container that is started with security.nesting.
Can you confirm?

security.nesting for unprivileged containers let's you get around most of those but it can vary a bit based on the host distro/kernel and guest.

As we're working to move to a systemd generator, we may eventually be able to attempt using some of those features and relax the override where needed, though initially the focus will be to avoid using unsupported systemd features.

OK, I see that this dependent on the systemd version but if I understand correctly, for an unprivileged Ubuntu 20.04 container with security.nesting, I'm better of removing this file, right?

Yep, it's safe to remove in your case.

Thanks for the confirmation.


Fix bug #847, guard against submitting incorrect test cloud requests …

…causing task to be stuck in loop

Looks good to me.


Remove onClick border

Hello hello. This might be a dumb question but when I clicked into a Geography (in all of the examples from the documentation), a rectangle with a blue-white border containing the clicked Geography appears. How do I prevent that from being visible? :)

If you want to remove that you can just set outline to none for the geography via the custom style prop.
<Geography
  style={{
    default: { outline: "none" },
    hover: { outline: "none" },
    pressed: { outline: "none" },
  }}
/>

Hope this helps
Cheers

Ahhh got it! Cheers mate! :)

Style component. You also need the setting for focus out too.
`import { Geography } from 'react-simple-maps';
import styled from 'styled-components';
const StyledGeography = styled(Geography)`
&:active {
outline: none;
}
&:focus,
&:focus-visible {
outline: none;
}
`;
export default StyledGeography;
`


PL/SQL Format document adds spaces to brackets, not valid

When I use this extension to format a block of PL/SQL code it always adds spaces behind opening curly brackets and before closing brackets.
{entityid} becomes { entityid }
https://d.pr/v/DXaZHm
The code is used in NetSuite custom search formulas, and the added spaces are invalid and have to be removed. How can I adjust the settings to stop this from happening?
(PS. I'm not a developer)

Hi, this issue is fixed in my fork here:
https://github.com/inferrinizzard/prettier-sql
https://www.npmjs.com/package/prettier-sql

This doesn't look like valid PL/SQL code to me. PL/SQL uses double-quotes to escape column names, not braces.
I think there's some other templating language in work in here that uses this { ... } syntax, so this is really out of scope for sql-formatter.


Notebook with PathCORE analysis workflow example

This notebook addresses issue #4:

[x] It updates the README of the jupyter-notebooks directory with some description of the file.
[x] It updates the requirements.txt file with a new dependency specific to the imports made in this directory (and not the parent one, e.g. scikit-learn is used in the parent directory so we don't need to import it in this one)
[x] It provides a notebook that runs through the PathCORE analysis workflow with a FastICA model of the PAO1 gene compendium. We do this to address a reviewer's suggestion that we apply PathCORE to an ICA model. The notebook format allows a user to read through each step and examine the results from a complete PathCORE analysis.

Something that may be updated in the notebook after a bug is fixed in the PathCORE repository:

I'd like the last line of the notebook to also be a dataframe. The dataframe would only contain edges considered significant after the permutation test. Because I want to first address this issue I created in the PathCORE repo (basically I'm not getting enough information from the return value of a method to do so), I may create a follow-up issue to issue #4 to improve the clarity in this notebook at a later time, or add it to this existing pull request.

Thank you for the suggestions @gwaygenomics! I've added more comments to the notebook and included %%time in the ICA model construction, enrichment analysis, and permutation test steps. Let me know if it looks ok or if there are further improvements I can make. :)

Looks great @kathyxchen - two additional comments:

Some of the lines seem to run long in cells 12 and 14 - you should look at the jupyter rendering on github to make sure the lines do not automatically wrap
The cells after cell 17 need to be run - make sure you save the notebook before you commit! ;)

@gwaygenomics good catch. x.x always double check that it saved before you (meaning, me) commit... have updated the file with those changes!


@rescript/core does not support ESM.

When I compile rescript into JavaScript and have Node.js run it, I found that the @rescript/corewas not set as a esmodule. When I manually changed the package.json in the core to type: module, everything worked properly.
(node:46659) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/Users/projects/rescript-message/node_modules/.pnpm/@rescript+core@1.3.0_rescript@11.1.0/node_modules/@rescript/core/src/Core__List.res.js:3
import * as Belt_Array from "rescript/lib/es6/belt_Array.js";

You need to set the file extension to .mjs or .res.mjs to opt into ESM for dependent packages. If we were to set "type": "module" in the package.json for Core it would mean ESM would be the default and for CJS support you would need to set the file extension to .cjs. Opting into ESM is probably the best path now, but the docs could probably be clearer around this. Soon this library will be part of the compiler, so it will be easier to keep everything aligned with ESM/CJS.

@jderochervlk  Thank you. You've saved me time.


Always use a 64K receive buffer in the UDP listener

What does this PR do?
Always use a 64K buffer when receiving UDP.
Motivation
datadog-go (and other statsd clients) allow to send much bigger UDP packets than the current default (8KB), and there is really no reason to conflate the size of the receive buffer with that of the buffers in the internal queue.
Increasing the size of the receive buffer to the maximum allowed UDP size will remove a footgun and simplifies configuration, as now the buffer size controls a single thing (the size of buffers in the queue), not two. Because there is a single receive buffer, memory increase is very limited (+56KB).
This change is discussed in https://github.com/DataDog/datadog-go/issues/168, that provides additional context why allowing bigger UDP packets by default makes sense.
Additional Notes
Reading https://github.com/DataDog/datadog-go/issues/168 will help.
Describe your test plan
The only meaningful test would be sending, to an agent with the default configuration, a statsd UDP packet of size >> 8192 bytes. If it works, all is good.
If this PR is accepted, at least in principle, I plan to add some unit tests covering this.

Hey @CAFxX,
Thanks for the very interesting point-of-view and detailed issue. I will give a look into it and we also have benchmarks / scenarios here I'm interested to run this against.
You've addressed it but I'll carefully validate that it won't just trade RAM usage against throughput, which is something which is an issue in a lot of real-world scenarios. (but you've mentioned in the datadog-go issue and you're right that tweaking the dogstatsd_queue_size could do the job).
In all honesty, maybe not in detail this week but I'll look into this soon, it's very interesting.

Hi @CAFxX thank you for your patience. We hadn't forgotten about this PR, but other work around the dogstatsd server processing pipeline derailed us a little bit. While I definitely agree that the UDP socket receive buffer and the internal buffers are different, disjoint elements, the internal representation of the messages is somewhat coupled; let me explain.
It's definitely true that the maximum size for UDP datagrams is 64kB, and that currently requires setting dogstatsd_buffer_size to said value, otherwise we just can't carry the dogstatsd payload through the processing pipeline. You mention the size of the socket receive buffer and these internal buffers should not be conflated; however it doesn't make much sense to read more than we can store in these buffers from the socket. Consider the following:

We read 64kB from the socket (but say our internal buffers can only hold 8kB dogstatsd_buffer_size).
We pass the receive buffer from (1) to the packet assembler, but it will only be able to copy 8kB because it's the most the internal buffers hold, so that message will likely be dropped while parsed. Or worse, it could potentially correctly parse a truncated message. Probably the safe thing to do here is just drop the message in the packet assembler in this event, something we're not currently doing.

Increasing the size of internal buffers to 64kB would certainly have an impact in memory usage (8-fold increase for the shared packet pool by default), all while remembering we use that shared packet pool also for unix domain sockets. We'd probably not want to do this by default to avoid using too much memory with the shared packet pool, this is why it's configurable.
So while you're absolutely correct about the receive buffer being it's own beast, it doesn't buy us much to always set it to 64kB because we can't internally carry a message larger than dogstatsd_buffer_size through the pipeline. One could argue that the current design is reasonable, as having the socket receive buffer match the internal buffer size allows us to weed out large messages that we'd be unable to process immediately.
I hope this makes sense.

Hi @CAFxX thank you for your patience. We hadn't forgotten about this PR, but other work around the dogstatsd server processing pipeline derailed us a little bit. While I definitely agree that the UDP socket receive buffer and the internal buffers are different, disjoint elements, the internal representation of the messages is somewhat coupled; let me explain.
It's definitely true that the maximum size for UDP datagrams is 64kB, and that currently requires setting dogstatsd_buffer_size to said value, otherwise we just can't carry the dogstatsd payload through the processing pipeline. You mention the size of the socket receive buffer and these internal buffers should not be conflated; however it doesn't make much sense to read more than we can store in these buffers from the socket. Consider the following:

We read 64kB from the socket (but say our internal buffers can only hold 8kB dogstatsd_buffer_size).
We pass the receive buffer from (1) to the packet assembler, but it will only be able to copy 8kB because it's the most the internal buffers hold, so that message will likely be dropped while parsed. Or worse, it could potentially correctly parse a truncated message. Probably the safe thing to do here is just drop the message in the packet assembler in this event, something we're not currently doing.

Increasing the size of internal buffers to 64kB would certainly have an impact in memory usage (8-fold increase for the shared packet pool by default), all while remembering we use that shared packet pool also for unix domain sockets. We'd probably not want to do this by default to avoid using too much memory with the shared packet pool, this is why it's configurable.
So while you're absolutely correct about the receive buffer being it's own beast, it doesn't buy us much to always set it to 64kB because we can't internally carry a message larger than dogstatsd_buffer_size through the pipeline. One could argue that the current design is reasonable, as having the socket receive buffer match the internal buffer size allows us to weed out large messages that we'd be unable to process immediately.
I hope this makes sense.

Closing this PR for the time being. Please see the comment above for more details on the reasoning. Regardless, thank you very much for your help and contribution (and a very valid point!) @CAFxX. We'll keep this in mind for further dogstatsd development.


fix for ERROR alert state generation in doc-level monitors

Signed-off-by: Subhobrata Dey<EMAIL_ADDRESS>Issue #, if available:
Description of changes:
fix for ERROR alert state generation in doc-level monitors
CheckList:
[X] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #768 (2ecde35) into main (780744f) will increase coverage by 0.06%.
The diff coverage is 83.33%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##               main     #768      +/-   ##
============================================
+ Coverage     75.43%   75.50%   +0.06%
  Complexity      116      116
============================================
  Files           125      125
  Lines          6828     6835       +7
  Branches       1024     1026       +2
============================================
+ Hits           5151     5161      +10
- Misses         1143     1147       +4
+ Partials        534      527       -7

Impacted Files
Coverage Δ

.../opensearch/alerting/DocumentLevelMonitorRunner.kt
79.51% <82.35%> (+1.93%)
:arrow_up:

...rch/alerting/transport/TransportGetAlertsAction.kt
75.51% <100.00%> (ø)

.../alerting/transport/TransportIndexMonitorAction.kt
54.93% <0.00%> (-2.97%)
:arrow_down:

.../kotlin/org/opensearch/alerting/util/IndexUtils.kt
70.83% <0.00%> (-2.09%)
:arrow_down:

...destinationmigration/DestinationConversionUtils.kt
70.00% <0.00%> (-1.12%)
:arrow_down:

...ain/kotlin/org/opensearch/alerting/AlertService.kt
80.00% <0.00%> (+0.93%)
:arrow_up:

.../org/opensearch/alerting/model/MonitorRunResult.kt
87.12% <0.00%> (+2.97%)
:arrow_up:

...tlin/org/opensearch/alerting/util/AlertingUtils.kt
68.75% <0.00%> (+15.62%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.