fix codecov and widget test screenshot uploads

Description
Fix codecov and widget test screenshot uploads.
While debugging failing pipelines, I noticed some warnings related to codecov and the widget test screenshot:

This PR fixed the cypress warnings by fixing the path to upload and the htmlcov warnings by only uploading when the python tests have been run (in case the widget tests failed the python tests are not run).
Checklist

[ ] I have added screenshots above for all UI changes.
[ ] Documentation was updated if it was needed.
[x] New tests were added or changes were manually verified.

Codecov Report

Merging #1428 (830eec5) into main (bc7a9f9) will decrease coverage by 0.38%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1428      +/-   ##
==========================================
- Coverage   89.34%   88.95%   -0.39%
==========================================
  Files          80       34      -46
  Lines        3556     1521    -2035
==========================================
- Hits         3177     1353    -1824
+ Misses        379      168     -211

Flag
Coverage Δ

unittests
88.95% <ø> (-0.39%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ponsibleai/responsibleai/_tools/shared/__init__.py

...ponsibleai/responsibleai/rai_insights/constants.py

...sibleai/responsibleai/_tools/shared/base_result.py

...nsibleai/responsibleai/_managers/causal_manager.py

...ai/responsibleai/_tools/error_analysis/__init__.py

.../responsibleai/modelanalysis/constants/__init__.py

responsibleai/responsibleai/__init__.py

responsibleai/responsibleai/exceptions.py

...sibleai/responsibleai/rai_insights/rai_insights.py

...bleai/responsibleai/_tools/causal/causal_result.py

... and 36 more

Continue to review full report at Codecov.

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


gh-208: remove legacy random number generation

Gets rid of legacy RandomState and replaced it with the new random number Generator for rng calls.
Fixes: #208

I think it would be good to have the random seed as a test constant or pytest.fixture

Agree, I usually make rng itself the fixture, which can be helpful for testing with a mock RNG.


Custom error page not loading properly

I am running from CLI via ./node_modules/.bin/superstatic ./dist --port 8080 --no-cache
My superstation.json (which is in my root) has:
{
  "errorPage": "./dist/index.html"
}

However, the standard error.html gets displayed on error.

@shamoons try removing the dist from the path. It is relative to your root directory.

My index.html page is in the dist/index.html. So is it relative to where I am running the command from or from where I specify it to serve from?

Relative to the root. So ./dist is the root in your case, so you can drop it from the path to your error page.

@shamoons I'm going to close this as a non-issue. Please let me know if you need any more help.

Where should my superstation.json file be? In my root or in dist?

@shamoons if your configured root directory is ./dist, then place it in root.


Members area: add role descriptions

Add to action buttons lists. "Roles in FreeCEN" or "Who does what".

@PatReynolds to talk with @geoffj-FUG about this.


Pie Charts don't show decimal percentage

Hi
I want to show decimals on my pie charts, and I don't need integer numbers, I tried used the property 'dataLabelFormatCode' but it does not work.
Can help me please?
I would greatly appreciate it, thank you.

Can you post your code and demonstrate the result you're looking for in a PowerPoint screencap?

This is mi file pie.js on this create a pie chart:
`
const PptxGenJS = require('pptxgenjs');
const colors = require('./colors');
const unitLabels = require('./unitLabels');
const pptx = new PptxGenJS();
function addPie(slide, chart, position, size) {
const { x, y } = position;
const { data, unit } = chart;
const { w, h } = size;
const targets = data.map(data => data.name);
let title = ${chart.title} (${targets});
if (unit === 'index') title = ${chart.title} (${targets} indexed against Base Target);
const options = {
x,
y,
w,
h,
chartColors: colors,
showLegend: true,
legendPos: 'r',
showTitle: true,
title,
titleFontSize: 10,
};
slide.addChart(pptx.charts.PIE, data, options);
slide.addText(unitLabels[unit], { x: x + (w - 0.7), y: y + 0.18, w: 0.7, fontSize: 10, bold: true, align: 'right' });
}
module.exports = addPie;
`
Data I send : [ { name: 'All Adults',     targetIndex: 0,     labels:      [ 'None/ Don\'t know/ Refused',        'Sunday Night Football',        'Auto racing' ],     values: [ 50.61, 42.39, 14.29 ] } ]
Exporter:

I need a pie with decimal percentage values don't need proximations, the correct way would be:

None/ Don't know/Refused: 47.2%
Sunday Night Football: 39.5%
Auto racing: 13.3%

Hi @Alexiz-Padilla
What dataLabelFormatCode value are you using?  That should be the key to achieving the formatting you're looking for.

I'm using dataLabelFormatCode: ###.### and dataLabelFormatCode:  000.00
But it does not work.

I found the solution in support.office.com
They say Currency, percentages, and scientific notation: "To display numbers as a percentage of 100 — for example, to display .08 as 8% or 2.8 as 280% — include the percent sign (%) in the number format."
Por lo tanto, la propiedad sería así:
dataLabelFormatCode: '##.##%'


Add Vector of any example

I thought adding at least one example would be nice. So here is my push request 🌝

I commited the requested changes and made a rebase.

@miathedev Thank you again!


Weird behaviour of  tag in Firefox

Hello.
Please look at this jsfiddle.
Press New Modal button, then try to select anything from select input. In Firefox the list with selectable options will appear not right under select input, but far to right side. In Chrome select input works normal.

Hello, thanks for the issue and especially the jsfiddle.
I've checked your example but everything works fine for me on Firefox 55.0.3, I've even added more options to the  in case it was a height related problem, but everything seems ok to me:

Just in case, can you please validate what version of Firefox are you using? Also, here's the same fiddle with three more options added: jsfiddle.

Whoa! I use the same version of Firefox. Your answer forced me to check my jsfiddle in newly created firefox profile... a-a-and it works fine!
Ha-ha, it seems that one of installed extensions breaks down behavior of select tag. Sorry for disturbing you. At first I asked my colleague to check jsfiddle from his computer and he confirmed the "bug". If you don't mind, I will find what extension does this and will add its name in comment later.

ohh great, thank you! and btw sorry! I've just noticed that my screenshot didn't upload, sorry for that :D. I'll close this comment now and wait for your extension feedback.
Thank you!

It turned out that this was Super Drag extension. It was last updated in 2014 and not compatible with new Firefox.


Add flag for ingest range check

What problem does this PR solve?
Issue Number: close https://github.com/pingcap/tiflash/issues/7766
Problem Summary:
What is changed and how it works?
Allow users to disable the range check in order to start TiFlash normally.
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/hold

just trigger /unhold when ready to merge

/merge

/unhold

/run-unit-test


Add setup_engine and is_engine_config

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (46bdc03) 100.00% compared to head (9266d95) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #300   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          316       316
  Lines         9925      9936   +11
  Branches       961       962    +1
=========================================
+ Hits          9925      9936   +11

Impacted Files
Coverage Δ

src/gravitorch/engines/__init__.py
100.00% <100.00%> (ø)

src/gravitorch/engines/base.py
100.00% <100.00%> (ø)

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


tests/posix/common failed on multiple ARM platforms.

Describe the bug
This test tests/posix/common failed on reel_board, frdm_k64f, mimxrt1050_evk and sam_e70_xplained boards.
To Reproduce
Steps to reproduce the behavior:

west build -b reel_board -p auto tests/posix/common/ -DCONFIG_NEWLIB_LIBC=n
west flash
See error

Screenshots or console output
*** Booting Zephyr OS build zephyr-v2.2.0-347-gcd90d49a8627  ***
Running test suite posix_apis
starting test - test_posix_pthread_execution
**Assertion failed at ZEPHYR_BASE/tests/posix/common/src/pthread.c:294: test_posix_pthread_execution: (ret not equal to ESRCH)**

uninitialized getname!
FAIL - test_posix_pthread_execution
starting test - test_posix_pthread_termination
Thread 0 starting with a priority of 4
Cancelling thread 0
Thread 1 starting with a priority of 3
Cancelling thread 1
Thread 1 could not be cancelled
Thread 2 starting with a priority of 2
Cancelling thread 2
Thread 3 starting with a priority of 1
Cancelling thread 3
Thread 3 could not be cancelled
PASS - test_posix_pthread_termination
starting test - test_posix_multiple_threads_single_key
Different threads set different values to same key:
thread 0: set value = 536876524 and retrieved value = 536876524
thread 1: set value = 536876780 and retrieved value = 536876780
PASS - test_posix_multiple_threads_single_key
......
starting test - test_posix_rw_lock
main acquire WR lock and 3 threads acquire RD lock
Thread 2 scheduling policy = 1 & priority 3 started
Not able to get RD lock on trying, try again
Thread 1 scheduling policy = 1 & priority 2 started
Not able to get RD lock on trying, try again
Thread 0 scheduling policy = 1 & priority 1 started
Not able to get RD lock on trying, try again
Parent thread releasing WR lock
Thread 2 got RD lock
Thread 1 got RD lock
Thread 0 got RD lock
Thread 1 releasing RD lock
Thread 1 acquiring WR lock
Thread 0 releasing RD lock
Thread 0 acquiring WR lock
Thread 2 releasing RD lock
Thread 2 acquiring WR lock
Thread 1 acquired WR lock
Parent thread acquiring WR lock again
Thread 1 releasing WR lock
Parent thread acquired WR lock again
Parent thread releasing WR lock again
3 threads acquire WR lock
Main thread acquiring RD lock
Thread 2 acquired WR lock
Thread 2 releasing WR lock
Main thread acquired RD lock
Main thread releasing RD lock
Thread 0 acquired WR lock
Thread 0 releasing WR lock
PASS - test_posix_rw_loc
Test suite posix_apis failed.
PROJECT EXECUTION FAILED
Environment (please complete the following information):

OS: fedora 28
Toolchain: zephyr-sdk-0.11.1
Commit ID: cd90d49a8627

I bisected, tried the test on nrf52840_pca10056, and the offending commit seems to be the following:
https://github.com/zephyrproject-rtos/zephyr/commit/17b19eb810e2429bf91fb231bbeae4a3c82bf0dc
merged in PR #22845 .
The error I see is:
starting test - test_posix_pthread_execution

    Assertion failed at ../src/pthread.c:294: test_posix_pthread_execution: (ret not equal to ESRCH)
uninitialized getname!
FAIL - test_posix_pthread_execution

@chen-png can you confirm my finding?
Copying @nslowell (author of #22845) and reviewers/maintainers/release-team-members: @pfalcon @andrewboie @jhedberg

Would you mind assisting with some debugging?  QEMU didn't show any issues.  Is the memory space of newthread[0] somehow non-zero at the point of failure?

@ioannisg  yes, this issue happened since 17b19eb.

@ioannisg Would you mind assisting with some debugging? QEMU didn't show any issues. Is the memory space of newthread[0] somehow non-zero at the point of failure?

Will take a look and update here.

this test also failed on iotdk board.

Is the memory space of newthread[0] somehow non-zero at the point of failure?

That's exactly what happens here - use of uninitialized value. The matter is aggravated by using confusing variable names in the testcases. I'm about to submit patch.

Fix posted: https://github.com/zephyrproject-rtos/zephyr/pull/23556 . (I would humbly suggest it as an example of a good commit message, which explains the issue, what complicated investigating the issue, and different strategies for addressing both, and why particular solutions were chosen.)


fix: KafkaSpout is blocked in AutoCommitMode

overwrite https://github.com/apache/storm/pull/1863 to merge changes of STORM-2225
see https://issues.apache.org/jira/browse/STORM-2340 for more details

@XuMingmin does this PR make the initial PR obsolete? If so, can you please close that one? If not, I suggest that we have only one PR (compatible with STORM-2225) to address this issue.

closed https://github.com/apache/storm/pull/1863.
https://github.com/apache/storm/pull/1919 is compatible with STORM-2225.

@XuMingmin Could you also include a STORM JIRA number in the description of this JIRA?  That is how Apache is able to tie the pull request to a corresponding JIRA.

@revans2 updated. thanks for the notes!

Good point to document the impact, is preparing an update PR.
According to my understand, there's no replay for AT-MOST-ONCE mode in storm. We use this mode when data missing is not a concern, and want to remove the overhead of tuple tracking.
With auto-commit enabled, the consumer's offset will be periodically committed in the background by Kafka consumer, so no need to track commit offset status with emitted/numUncommittedOffsets manually.

There are two different settings influencing retry behavior here. Auto commit on the spout, and number of ackers configured for Storm (https://storm.apache.org/releases/1.0.0/javadocs/org/apache/storm/Config.html#TOPOLOGY_ACKER_EXECUTORS). You can configure Storm to require tuple acking, while also using auto commit for this spout, in which case the spout will retry tuples that fail, but only on a best-effort basis (i.e. if the spout crashes, tuples will not be replayed). In that case, the spout actually needs to track tuples even though auto commit is on. You can also set acker executors to 0, which will cause Storm to just ack tuples immediately when emitted. In that case it doesn't hurt anything if the spout adds tuples to emitted, because they'll just get removed again when ack() is called.

This is the thing with auto-commit.  auto-commit removes some of the overhead of tracking outstanding messages, but also violates a lot of the guarantees that storm has in place.
To truly get at most once processing you need to commit the message as soon as it is emitted.   Otherwise a crash can still result in messages being replayed.  If you want at least once processing you have to ack the message only after it is fully processed.  Storm makes this work out of the box for most spouts that commit the message when ack is called.
With auto-commit it makes it so we could replay messages even in at most once processing and that we might not replay messages in at least once processing.  It is "I really don't care what messages I see processing".

it makes sense for me to totally rely on kafka autocommit in at-most-once semantic, and leverages manually offset management for at-least-once, not mix the two offset options.

The spout as is doesn't support true at-most-once. When auto commit is on, the consumer periodically commits offsets. When auto commit is off and ackers is 0, the spout periodically commits offsets manually. In either case the spout could crash and replay tuples that were acked but not committed. If you need real at-most-once, the spout needs to commit offsets immediately when acked, and in that case you would also need to disable auto commit.

The situations in my mind:

autocommit=true + ack=0, --> work, at-most-once
autocommit=true + ack>0 --> work, at-most-once ( acker be idle ? )
autocommit=fale + ack=0 --> not work, blocked when numUncommittedOffsets < maxUncommittedOffsets;
autocommit=false + ack>0. --> work, at-least-once

Autocommit=true + ack=0 means the consumer will commit periodically. Tuples cannot fail. Messages may be replayed if the spout crashes (it may not have committed them because it only happens periodically). This is not true at-most-once, since it is only at-most-once if the spout doesn't crash.
Autocommit=true + ack>0. Acked tuples are handled identically to the case above. Failed tuples are replayed, but only if the spout doesn't crash. This configuration could make sense if you just want best-effort replaying, or you're running a topology with other types of spouts as well.
Autocommit=false + ack=0 will cause Storm to ack tuples immediately. The spout will commit them periodically (https://github.com/XuMingmin/storm/blob/717edc8e7ea46ef3392ec1402235a764039070ff/external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/KafkaSpout.java#L241). This is identical behavior to the first case, except the commit handling has moved from the consumer to the spout.
Autocommit=false + ack>0 is at-least-once.

when ack=0, explicit ack()/fail() should not take affects as no AckExecutor is running.
Regarding to spout crash, possiblely some tuples are replayed in a periodically commit manner, unless offset is committed after every emit, that's a trade-off for performance.
Another point, may need to skip messageId in SpoutOutputCollector.emit() when auto-commit, to disable ack permanently:

public List emit(List tuple)  Emits a tuple to the default output stream with a null message id. Storm will not track this message so ack and fail will never be called for this tuple. The emitted values must be immutable.

Please see https://github.com/apache/storm/pull/1919#discussion_r99888764 and https://storm.apache.org/releases/1.0.0/javadocs/org/apache/storm/Config.html#TOPOLOGY_ACKER_EXECUTORS. If ack=0 Storm will call ack immediately on emit.
Yes, some tuples may be replayed if the spout crashes. What I'm saying is you can't currently configure the spout to commit after every ack. So it's not really at-most-once, so we shouldn't call it that. It's confusing.
Emitting with null message id is an option, but then you have to make sure that emitted tuples leave no state behind (i.e. they aren't put in emitted). It also prevents you from getting best-effort replaying unless you explicitly check for ackers in emitIfNotEmitted.

remove at-most-once for better describe the changes;
emit null msgId when AutoCommitMode to disable tuple track in storm;

@srdo  @revans2, any comments ?

LGTM. It doesn't support running with auto commit mode and getting best-effort retry, but I don't know if that's a real use case, so maybe it doesn't matter.

thanks @revans2 , updated doc as advised.
Regarding to anchor, as ack() is called immediately when acker=0, though it's not needed to track.
Originally, this ticket is focused to solve case 1. let's have a separated one to address case 2 and case 3?
1). autocommit=true + ack=0
2). autocommit=true + ack>0 //ack track is running idle, to-be-confirm
3). autocommit=fale + ack=0 //ack immediately, similar as case 1, to-be-confirm
4). autocommit=false + ack>0

Case 3 is normally what we think about non-ack in Storm spout, and it's not same as case 1 since it can guarantee at most once.
So one way to keep our delivery guarantee is forcing autocommit to true (not selectable from user), which I'm not sure we're all satisfied. What do you think?

I would prefer to keep case 1 for at-most-once, when user want to avoid manage the offset additional in KafkaSpout.
IMO, there's no difference for guarantee between case 3 and case 1. It's achieved either committed by KafkaSpout or by KafkaConsumer.  Back to the discussion before, I think case 1 can also guarantee after reading code of KafkaSpout as below:
*it's assumed that KafkaSpout.close() is called in any crash, otherwise no for both  *

close() call shutdown;
when consumerAutoCommitMode=false, commitOffsetsForAckedTuples() is called to commit offset;
then kafkaConsumer.close() in the finally block would commit the latest offset if consumerAutoCommitMode=true, as

KafkaConsuer.close()
 -> ClientUtils.closeQuietly(coordinator, "coordinator", firstException);
   -> ConsumerCoordinator.close()
     -> ConsumerCoordinator.maybeAutoCommitOffsetsSync();
       -> commitOffsetsSync(subscriptions.allConsumed());

@XuMingmin You shouldn't assume that KafkaConsumer.close is called when crashing. If the executor running the spout crashes (or throws an uncaught Exception), close is not called as far as I know. If the spout is reassigned to another worker, Storm will just kill -9 the JVM running the spout. I'm not sure ISpout.close is actually ever called in a non-local cluster. See https://storm.apache.org/releases/0.9.7/javadocs/backtype/storm/spout/ISpout.html#close--
If you need real at-most-once, the spout would probably need to commit offsets after every ack.

@srdo if kafkaConsumer.close() is not guaranteed to call, strictly, there's no at-most-once guarantee for either case 3 or case 1 so far. And case 1 equals case 3 after this PR.

Yes, that's what I mean. It's not really at-most-once. For real at-most-once, the spout should call KafkaConsumer.commitSync when it receives an ack, not periodically (and then you'd need to disable auto-commit).

@srdo agree, that's why I remove the word at-most-once in this conversation to make it clear.
I haven't followed the latest Storm version for some time, I remember no later than 0.9.* people call it at-most-once when acker=0.

@srdo @XuMingmin
If my understanding is right, at-most-once can be guaranteed with this step:

pull the data from datasource
send ack to the datasource
emit the data to the downstreams

Loosening the requirement that there will be no crash between emitting the data and sending ack to the datasource, we can swap 2 and 3, and that's what we're often referring to.
So yes case 3 should explicitly ack to the datasource and data should be emitted only when sending ack succeeds. I'm not familiar with Kafka new API, but if KafkaConsumer.commitSync guarantees ack, we should use this for case 3.
Please correct me if I'm missing here.

@HeartSaVioR That's pretty much my understanding of this as well. I'm not sure what order the ack/emit happens in when ackers=0, but if it's ack followed by emit, then it should be enough to put a KafkaConsumer.commitSync call in KafkaSpout.ack. commitSync guarantees that the committed offset is properly committed when it returns.
I agree that this is how it should work for case 3.

@srdo
I think it's up to the Spout implementation and we don't need to consider ordering if we don't rely on ack() method.
If the spout is aware of the count of ackers (0 or more) and data source provides the way to ack synchronously, nextTuple() method can have two branches (ack vs non-ack) which handle ack/emit accordingly, and ack() method can don't do anything when no acker is activated.

Do we really need a commitSync call for every emit? That would be lots of calls. The consumer reads data in batch.
The pseudo-at-most-once, either case1 or case 3, is good option, as a performance trade-off .

What I'm referring is the blog doc: https://www.confluent.io/blog/tutorial-getting-started-with-the-new-apache-kafka-0.9-consumer-client/
Referring to the doc, "at most once" can be achieved with below code snippet with no autocommit enabled:
try {
  while (running) {
  ConsumerRecords<String, String> records = consumer.poll(1000);

  try {
    consumer.commitSync();
    for (ConsumerRecord<String, String> record : records)
      System.out.println(record.offset() + ": " + record.value());
    } catch (CommitFailedException e) {
      // application specific failure handling
    }
  }
} finally {
  consumer.close();
}

It calls commitSync for every poll, not every emit (println in the code).
Again I'm not familiar with new Kafka API so if we think the above code snippet has some other issues I'm completely OK to not providing strict at-most-once.

@HeartSaVioR  instinctively I think your code can meet at-most-once. Records that are pulled and not yet emitted are discarded if any crash.
Still, I'd want to limit the scope of this task, to close it first to fix case 1, and have a new task(STORM-2357) to figure out what's the proper solution to achieve exactly at-most-once.

@XuMingmin
OK agree that it's beyond the PR's scope. We still need to sort out case 1 to 4, but this PR itself looks great to me.
+1

@HeartSaVioR Right, acking a batch at a time is better.


Fixed tables, added keyboard graphics

Fixed tables from having a width of 75%, resulting in whitespace.
Added :experimental: attribute so keyboard graphics can be used.
Changed all keyboard key short cuts to be keyboard graphics.

Great, thanks a lot, keep them coming. :-)


Filter by layer

Could this be similar to gatherDisplayEntities but returning a Collection instance?
I wonder if the transforms on inserts could be  supplied independent of the entity as to not need cloning.
What do you think about Layers inheriting from Collection?
With the primitives then being stored per layer.
var filteredCollection = collection.filterByLayer(['L0','L1']);

Or some kind of filtering & searching chain-able query functions.
.find(['L0'],'circle').having('r','between', [100, 300])

linq like? http://hugoware.net/Projects/jlinq
Or were you thinking of a white/black filter of layers when initially parsing the DXF?

There will be no filtering during the parsing stage, filtering can be applied to entities afterwards in client code.
This lib will not have linq-like filtering or any other kind of higher-order filtering - that is up to the client to implement


Divide elastic docs into sections

retest this please

retest this please

retest this please

retest this please

0/4 so far on this documentation-only PR. This time:
`* What went wrong:
Could not resolve all dependencies for configuration ':cassandra:compileClasspath'.

Could not download protobuf-java.jar (com.google.protobuf:protobuf-java:2.6.1)
Could not get resource 'https://repo1.maven.org/maven2/com/google/protobuf/protobuf-java/2.6.1/protobuf-java-2.6.1.jar'.
Connection reset
`

@gabrielhartmann What do you say to just merging this?


API Control automated check have failed

Seems like the API Control tests we moved into their own weekly CRON job has had its first fail: https://github.com/algolia/npm-search/actions/runs/6704941688/job/18218376954. This is partly expected, as those tests are flaky.
The action should also have automatically created this issue, but I misconfigured the GITHUB_TOKEN env variable and it didn't.
As for the test itself, we could simply increase the timeout, but I think @Haroenv mentioned also adding a retry mechanism. Any preference? @MartinKolarik have you seen just being slow and waiting long would work, or does it make more sense to retry?

I think just trying the whole test a second time, with a little time between would be ideal in this case

I suggest at least five attempts in total with up to a few minutes between each. The API is occasionally very slow or just straight up failing with 502 errors.


Update iris.go

Replace NoListen (which I will remove right now from Iris too) with ListenVirtual

Coverage remained the same at 97.21% when pulling 993b466b4982f1032d3d9cecc7947e9482611b4a on kataras:master into 35c8994667acb85dad8c454a2d231ebc1b782caf on gavv:master.


Foreground notification for iOS 14

The option Alert was deprecated in exchange of UNNotificationPresentationOptionAlert and UNNotificationPresentationOptionList, this means that iOS 14 or higher will not receive foreground push notifications with current version of this package.
Even calling completionHandler(UNNotificationPresentationOptionBanner); in AppDelegate it doesn't prompt the dialog in foreground.

It seems was a bad setup to the AppDelegate file, it works with the documentation example:
completionHandler(UNNotificationPresentationOptionSound | UNNotificationPresentationOptionAlert | UNNotificationPresentationOptionBadge);

I am still unable to receive notifications in the foreground, and the documentation example I have used is
-(void)userNotificationCenter:(UNUserNotificationCenter *)center willPresentNotification:(UNNotification *)notification withCompletionHandler:(void (^)(UNNotificationPresentationOptions options))completionHandler {   completionHandler(UNNotificationPresentationOptionSound | UNNotificationPresentationOptionAlert | UNNotificationPresentationOptionBadge); }
Could you help me out with this?

This works for me.


IgnoreFieldAttribute should work on properties

When constructing a FormFlow model, the IgnoreField attribute can be placed on both fields and properties, but seems to have no effect on the latter. So either honor the attribute or disable placement on properties and make a new IgnoreProperty attribute for that purpose.

Investigating this. :D

It's probably due to the lack of a Where clase here and here.

It would seem like they were missed at those two places. Contributions are always welcome, and you are welcome to make a pull request and I'll ensure the proper people see it through to approval.

Looking at the code, these are also the same places where the OrderAttribute is supposed to be applied. Meaning that Order also does not work on properties currently. Might as well lump that into the issue.

Closing because I see you made a pull request! 👍


Open Sm3p Project Automatically?

Heya, I have put in code inside of the SearchModule.rb file to auto-create a sm3p file for us when ran. Our users then have to open that file. is there a way I can add in the code to automatically load it in? or if they select Open Project it automatically goes to the directory that the new sm3p file is at?
New Code:
require "java"
java_import javax.swing.JOptionPane
ERROR = JOptionPane::ERROR_MESSAGE
YES_NO = JOptionPane::YES_NO_OPTION
YES = JOptionPane::YES_OPTION

def get_input(message,initialvalue="")
	return JOptionPane.showInputDialog("RITM_SearchName",initialvalue);
end

def show_confirm(message,title="Confirm?")
	return JOptionPane.showConfirmDialog(nil,message,title,YES_NO) == YES
end

ritmSearchName = get_input("input","").to_s

nuix_case = $current_case
case_path = nuix_case.getLocation.getPath.split('\\')
dirPath = "\\\\"+case_path[2]+"\\"+case_path[3]+"\\"+case_path[4]+"\\"+case_path[5]+"\\Case_Management\\EDD\\Scratch\\"+ritmSearchName
sm3pFile = dirPath+"\\"+ritmSearchName+".sm3p"

if !java.io.File.new(dirPath).exists
	java.io.File.new(dirPath).mkdirs
end

show_confirm("Please load in the following s3mp file:\n"+sm3pFile,"PLEASE NOTE")

output = File.open(sm3pFile,"w" )
output << File.read("\\\foo\\bar\\foo\\bar\\foo\\Saved Settings\\ID_Default_SearchModule_InTest.sm3p").gsub("RITM_SearchName",ritmSearchName).gsub("SearchKey",("SearchKey_"+ritmSearchName))
output.close

I can't find the code in SearchModule.rb file that has dialog methods for auto open directories or files

Hello @ccastillo-id the script should be automatically be saving the project settings to 2 files each run:

same directory as script
same directory as report file

see these lines:
https://github.com/Nuix/Search-Module/blob/master/Ruby/SearchModule.nuixscript/SearchModule.rb#L119-L121
To have it automatically load that auto saved project file from the script directory, I would probably modify lines 96-101 of Searchmodule.rb:
while true #Loop until user cancels.  Loop will be show dialog, run, show dialog, run, ...
	file_timestamp = Time.now.strftime("%Y%m%d_%H%M%S")
	default_report_file = "#{$current_case.getLocation.getAbsolutePath}\\Reports\\SearchModule3_#{file_timestamp}.xlsx"

	dialog.setReportFilePath(default_report_file)
	dialog.setVisible(true)

and change that to this:
while true #Loop until user cancels.  Loop will be show dialog, run, show dialog, run, ...
	file_timestamp = Time.now.strftime("%Y%m%d_%H%M%S")
	default_report_file = "#{$current_case.getLocation.getAbsolutePath}\\Reports\\SearchModule3_#{file_timestamp}.xlsx"

	# Load project object from file that is created each run (if it exists)
	# and then load that into the dialog
	project_file = java.io.File.new("#{File.dirname(__FILE__)}\\LastRunProject.sm3p")
	if project_file.exists
		project = com.nuix.searchmodule.SearchModuleProject.loadFromFile(project_file)
		dialog.loadProject(project)
	end

	dialog.setReportFilePath(default_report_file)
	dialog.setVisible(true)

Thanks @JuicyDragon !!


Clarify that ESLint now only recommends a config

Prior to 1.x, ESLint had a default configuration, but it is now only a recommendation.

Thanks!


Missing Footer on Multiple Pages and Responsiveness Improvements

This PR addresses the issue of a missing footer across multiple pages in the application. It adds a consistent footer to all relevant pages and enhances its responsiveness to improve user experience on both desktop and mobile devices.

Closes : #98

Changes Made

Footer Component Added: Integrated the footer component into the following pages:

[List the pages where the footer was added, e.g., Home, About, Contact, etc.]

Responsiveness Improvements:

The footer is now fully responsive, with a layout that adapts to different screen sizes.
The subscribe section has been adjusted to stack vertically on mobile devices while maintaining a side-by-side layout on desktop.
Used Tailwind CSS for styling to ensure a clean and modern look.

Screenshots:

Desktop

Mobile

@4darsh-Dev fixed double footer! you can merge now.

I've checked in codespaces, it was working fine 👍🏻


Installation bug report on Linux Ubuntu

Hi @Sicrve11 , thanks again for your contribution to this great tool! I've been working around installing PROST on my Linux machine but failed on pip install -r requirements.txt following your documents' instruction. Specifically, rpy2 was not able to be built as the error said Failed building wheel for rpy2. Inspired by the solution in here and I can successfully install PROST now. Hope this workaround can help you improve PROST further.

Thanks again for your feedback! rpy2 is indeed a hard package, it's more strict on the environmental requirements. We tested it only using conda under the Centos or the Windows. You have provided another solution, thank you very much!


Contributing from M1

Bug report
Describe the bug
go buffalo's pop CLI doesn't work on M1 stopping contributing from M1 mac's
To Reproduce
Follow Contributing.md install guide
Expected behavior
Able to start contributing.
Screenshots
N/a
System information

OS: [e.g. macOS, Windows] macOS, M1
Browser (if applies) [e.g. chrome, safari] N/a
Version of supabase-js: [e.g. 6.0.2] N/a
Version of Node.js: [e.g. 10.10.0] N/a

Additional context

Contributing.md file

This can be closed, it just requires you to look into work arounds. They can be found on the internet and to my knowledge the contributing document it getting reworked soon too


Change deleteTrigger API.

API change (breaking backward compatibility)

Class/File to be change : ThingIFAPI (ThingIFAPI.java)

Methods changed : public Trigger deleteTrigger(@NonNull String triggerID) throws ThingIFException

Behaviour to change : Make GET request every time before delete

Change overview :

Change methods signature return from Trigger to String

public String deleteTrigger(@NonNull String triggerID) throws ThingIFException

Behaviour change

Remove GET request

Implementations Change

remove un necessary getTrigger call before deletion
update test case.

@satoshikumano please review

LGTM

iOS: KiiPlatform/thing-if-iOSSDK#113


61 add version control

Rules are now versioned when Patched, Published or Deleted
Deleted rules are soft-deleted
A previous version of the rule can be restored

Versioning
Each version of a rule is stored as a separate item in the container.
Versions are maintained using the "created" timestamp property.
Versions are grouped using the "latestId" property, which points to the id of the current version.
If the item is the latest item, it will not have a "latestId" property
If the item has been deleted, the "latestId" property will be empty and if the rule is published, it will be unpublished so that the library/engine do not think the rule exists.
If a published item is patched, the new item will remain published and the previous version will be unpublished.
Testing
The following functionality should be tested:

Getting all rules
Getting a version of a rule
Creating a new rule
Modifying a rule
Restoring a previous version of a rule
Deleting a rule
Publishing a rule

@gerrycampion overall the code looks good. I am a little concerned about saving a copy of the rule in the rules table on each save. I think if enough users save frequently the table could get pretty large and queries could slow down. What do you think about creating a new table: RuleHistory, which would store old versions of the rule? The rule record in the main rules table would have references to the rule history table:
[
{
    "created": timestamp
    "creator": <name>
    "replaced/updated": <timestamp when a new version of the rule became the latest>
    "rule_history_id": "id of the rule version in the rule history table"
}
]

This way we would only query rule history when getting a specific diff, so we could look up by ID when the rule author selects a rule to diff with. It might also be cheaper since we would not be doing as many queries on all rules ever created

@gerrycampion overall the code looks good. I am a little concerned about saving a copy of the rule in the rules table on each save. I think if enough users save frequently the table could get pretty large and queries could slow down. What do you think about creating a new table: RuleHistory, which would store old versions of the rule? The rule record in the main rules table would have references to the rule history table:
[
{
    "created": timestamp
    "creator": <name>
    "replaced/updated": <timestamp when a new version of the rule became the latest>
    "rule_history_id": "id of the rule version in the rule history table"
}
]

This way we would only query rule history when getting a specific diff, so we could look up by ID when the rule author selects a rule to diff with. It might also be cheaper since we would not be doing as many queries on all rules ever created

The Rules table now stores a historical list of { created, creator, id}. The historical rules are stored in a separate container.
I also updated the core id population to avoid reusing core ids for rules that have been deleted.


label attribute for custom values is confusing

It is confusing that we use label in items for setting the selected value.
label is used in most of our elements for a different purpose.
<vaadin-dropdown-menu label="Select a Name">
   <template>
      <vaadin-list-box >
         <vaadin-item label='Manuel'>Manolo</vaadin-item>

I suggest to use value which is used in native select/option tags
<select>
  <option value="volvo">Volvo</option>

Well, I don’t think it’s confusing, as the attribute is placed on the item. It provides the same feature – the visual and audible label for that particular focusable piece of UI.
“Value” sounds more like the underlying data that gets submitted in a form (or used in a data binding), like an id. That would be more confusing IMO.

Sorry, already working on this and sent a fix, before reading this.
If you don't consider this confusing let's go with label, but as I said we should align with the platform as much as possible. Since we are in very early alpha status, changing the API here shouldn't be a big deal

we should align with the platform as much as possible

If you refer to the value attribute for option elements than that is another thing. It does not change the visual label of the item/option, only the value which is used in form submission.
If you mean something else, can you please clarify?

So IMO, please revert back to using label instead.
This does not rule out the possibility of introducing another value property/attribute in addition, which would then match with the vaadin-combo-box API.

Out of curiosity why is in vaadin-radio-button the same thing named value shouldn't we be aligned in the api we offer in all elements?

In vaadin-radio-button, the value property/attribute is also used for form submission, not for the visible/audible label for the control.
For example:
<vaadin-radio-button value="item_1234">Item name (id: 1234)</vaadin-radio-button>

The end user would see ⦿ Item name (id: 1234) and a screen reader would announce something like Item name, id 1234, radio button, checked.


requirements for 2025

Just a brainstorm with @YichenWangs this morning about what we are trying to do:
Need:

2-column and 1-column templates (paper and music respectively)
LaTeX and Word versions (recommend to all to use LaTeX with Overleaf but not ready to get rid of Word)

Would like:

no CCS concepts in any template
no DOI listing in any copyright block or footer (we cannot generate a DOI until after camera ready and production)
neat CC-BY 4.0 License information (the little image is not necessary)
easy access to update the conference "title" in the copyright block.
remove the anonymise package (easier to use the ACM Publication Format anonymisation function)

Fonts:

present ACM templates have different fonts in LaTeX and Word but end up set in Linux Libertine and Linux Biolinum. The word docs use default-ish word choices like Times New Roman and Arial. Probably ok to have this difference and try to cope with it at the camera ready end (e.g., fix fonts on author supplied .docx files) this would allow us to scope out the problem for future years.

Technical Wizardry:
ideally we might adopt the current ACM publication template (acmart.dtx): https://github.com/borisveytsman/acmart

We would fork it, (allowed under LaTeX Project Public License) modify it to NIME-ify it and compile it to provide a common .cls file.

Recent acmart updates are actually pretty useful, e.g., now supports CC licensing out of the box which was a problem for a while.

Hi all,
Yes, great idea, we can therefore modify the .dtx to create a correct NIME cls.
For the paper/music templates, they would then be directly defined here, and simply copied to the nime-template repository ?

I think we can define the paper template file directly in the nimeart repo, you just have to adjust the text in samples.dtx. There's not much to change for papers.
For music/workshops, I think it might be good to provide slightly different text, adjusted afterwards to explain what sections are required.

For the thread, our fork of acmart is https://github.com/nime-conference/nimeart

If we want to get rid of CCS, we might need to remove the corresponding section in the sample.

Other minor changes that would be nice in the new template :

Remove the ACM Rights information section
Remove the CCS section
Add information on anonymization of videos/urls (in addition to the link to the main document)


The note field is omitted when converting BibTeX to Hayagriva

Input t.bib:
@book{test_1,
    note = {This is a test!}
}

Expected output:
test_1:
  type: book
  note: "This is a test!"

Real output:
test_1:
  type: book

I've notices that when converting a BibTeX file into a Hayagriva file, the note field is omitted. (I ran the command hayagriva t.bib using Hayagriva v0.5.3. This bug is also carried into Typst: CSL styles which use the note field cannot use it when the user is working with a BibTeX file directly.)

I believe this has been fixed with #220.


Search: find, replace input boxes miss scrollbar

Testing #64270
When having a tall multi-line input, the search find & replace boxes seem to miss a scrollbar when scrollable.

Bumping this as it's been ignored since 2018.
This also applies to horizontal scrolling.


[release/9.0-rc1] Backport Update template ids, names etc (#6118)

Change shortName to ["foo", "foo-9"]

Rename template nuget package ids
Aspire.ProjectTemplates.9.0.net9 -> Aspire.ProjectTemplates
Aspire.ProjectTemplates.9.0.net8 -> Aspire.ProjectTemplates.net8

Update Name, and description to include the version

Track naming changes in the tests

[tests] Fix detection of template packages

Fix missed description, and name changes

Update templatestrings.en.json as updated by build

Update templatestrings json files

Update templatestrings json files for net8

Add tests for templates with alternate name

Add version to name, and description in files missed

Separate the ttest framework template tests

fix test

(cherry picked from commit 0aace47ca8c220bbaa2143dece2bf942be176cd5)
Microsoft Reviewers: Open in CodeFlow

We are but I have been proactively looking into these directly on GH today and marking as approved

This is approved given it is a new feature in 9.0, and we want people to dogfood this and get feedback on it.
@radical will we need to backport #6167 too?


Hide the Autocomplete Dialog when Field is disabled

Fix #469 A non-editable field should not show autocomplete options
Description
I think it solves the issue because the disabled field is not actually being passed down to the input element.

The height adjustment also helps with the input color (specially on autocomplete) fitting the outer container:

Hello @nextrapi,
Thanks for your contribution. The disabled prop do work for the autocomplete use case. However, disabling a field makes it invisible when navigating with the keyboard (especially with the tab) and the screen reader (unless you scan the text). For each component modification, we have to think about making it readable and usable for everyone. That's why the disabled props is not passed to the components. So, the aria-disabled property allows us to give the information of this state. Concerning auto completion issue, this is a common issue we have here (especially with browser password extensions). I think we can try to set the props autoComplete="off" if the field is disabled.
Don't forget to run the test and regenerate the snapshots 😉
To regenerate the snapshots, you can run yarn test -u in packages/strapi-design-system;
const FieldInput = ({ ..., autoComplete }) => {
    ...;
    <Input
        ...
        autoComplete={disabled ? "off" : autoComplete}
};

FieldInput.defaultProps = {
  autoComplete: undefined,
  ...,
};

FieldInput.propTypes = {
  autoComplete: PropTypes.string,
  ...,
};

The snapshots seems to be broken. Can you check all the tests suites please.
At the root:
Run the test : yarn test
Run the e2e test : yarn test:e2e

I noticed that we had a problem with the test configuration. develop is now up to date, can you update your branch so we can merge it. Sorry for that.


Linux Apps unable to access VNet integration via Networking tab in UI

From these docs, it's not clear that VNet integration is or is not available to web apps that are started using docker-compose. The VNet section in the Networking tab is not available from the app service, and the 'Networking' tab is completely grey'd out on the app service plan page.

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

ID: a7a98803-1438-b1b5-f543-7dd88bc4294e
Version Independent ID: 37ff1d0f-ed8e-5e4d-1f4c-1b9f6cffb938
Content: Integrate apps with Azure Virtual Network - Azure App Service
Content Source: articles/app-service/web-sites-integrate-with-vnet.md
Service: app-service
GitHub Login: @ccompy
Microsoft Alias: ccompy

Hi @cbcoutinho,  hanks for the feedback! We are currently investigating and will update you shortly.

Hey @cbcoutinho, we appreciate your feedback! We have added a note in the doc stating "If the "Networking” blade is disabled (grayed out) in the menu for your Linux apps, it means that feature is currently not available." based on this doc  https://docs.microsoft.com/en-us/archive/blogs/waws/things-you-should-know-web-apps-and-linux
I have submitted a PR to update the doc, the change is merged internally and will go-live in the public docs shortly. We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue. Thanks!


Fixed insane wait times

Closes #37

I'll try it out in a second, I'll first try to get #49 in, to see what's going on.
The reason the CI fails is that it forbids any clippy warnings. Don't worry about the remaining failures, I'll fix them.

Just tested it, it's absolutely amazing! Thanks a lot, @ccgauche.

@DzenanJupic May you merge?

Using both your pull request (https://github.com/Discursif/rustube/commit/6b676ca30a2c9bfe089718b79ec4b51573a669c6) and the "fixed" branch on this repo (https://github.com/DzenanJupic/rustube/commit/f118c6b6a0979f48127490468ca2e0ad874f9065), this minimum example from the readme downloads an empty video file:
#[tokio::main]
async fn main() {
    let url = "https://www.youtube.com/watch?v=Edx9D2yaOGs&ab_channel=CollegeHumor";
    println!("downloaded video to {:?}", rustube::download_best_quality(&url).await.unwrap());
}

Here's how I added the dependency as a sanity check:
[dependencies]
rustube = { git = "https://github.com/DzenanJupic/rustube", branch = "fix-warnings-and-rebase-master" }
tokio = { version = "1.12.0", features = ["rt-multi-thread"] }

I'll check that, thanks for the notice.

I'll check that, thanks for the notice.

I'll also look around possibly tonight but I don't really understand how it works lol 🙃

The fix has been tested on a very very large amount of musics (since it was made for my music app) but wasn't tested at all on videos. Maybe using the old system as a fallback could be a good idea while we find out what causes the issue (probably related to the file size of videos since music is a lot smaller). The pytube fix is a little big longer with more things and checks so maybe they are here to fix this issue. Didn't have the time to test. In my tests on music they changed nothing so I removed them to better fit my use case and reduce the fix size.

I've checked a bit what causes the issue of an empty file being created for the example video. The problem seems to arise from the usage of the Range header in cases where streams have content length populated as zero - which is the case for the highest quality stream of the example video.

@ccgauche
The download speed has increased significantly, but there is a problem that appears, which is that the videos are downloaded without sound.
Also, the speed is not stable, most of the time the download stops suddenly
cargo.toml
rustube = { git = "https://github.com/Discursif/rustube", branch = "master", features = ["callback"]  }
main.rs
stream.download_to_with_callback(file_path, callback)


[EventHubs] Update underlying EP implementation

Use Queue to enqueue callback tasks, and user callback would work in a user thread.

Can one of the admins verify this patch?


Cannot wrap GradientTape.batch_jacobian with tf.function on tf.keras model with LSTM cells

System information

Have I written custom code (as opposed to using a stock
example script provided in TensorFlow):  Yes
OS Platform and Distribution (e.g.,
Linux Ubuntu 16.04):  macOS Mojave
TensorFlow installed from (source or
binary): binary
TensorFlow version (use command below): 2.1.0
Python version: 3.7.4

Describe the current behavior
The @tf.function wrapper is not able to convert LSTM cells correctly for use in the batch_jacobian function (or jacobian, tested both). These functions work correctly without the decorator.
    ValueError: No converter defined for VariableShape
    name: "loop_body/VariableShape_2"
    op: "VariableShape"
    input: "binary_classification_lstm/lstm/while:10"
    attr {
      key: "out_type"
      value {
        type: DT_INT32
      }
    }

Describe the expected behavior
This should run without throwing an error
Standalone code to reproduce the issue
import tensorflow as tf

class BinaryClassificationLSTM(tf.keras.Model):
    def __init__(self, units, name=None):
        super(BinaryClassificationLSTM, self).__init__(name=name)
        self.lstm_layer = tf.keras.layers.LSTM(units, activation='softsign')
        self.dense = tf.keras.layers.Dense(1)
        self.sigmoid = tf.keras.layers.Activation('sigmoid')

    def call(self, x):
        sequence = self.lstm_layer(x)
        logit = self.dense(sequence)
        prob = self.sigmoid(logit)

        return prob

@tf.function
def get_jacobian(model, tensor_in):
    with tf.GradientTape() as tape:
        tape.watch(tensor_in)
        predictions = model(tensor_in)

    return tape.batch_jacobian(predictions, tensor_in)

inp = tf.zeros((1, 10, 5))
lstm = BinaryClassificationLSTM(10)
jacobian = get_jacobian(lstm, inp)

Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.
Traceback (most recent call last):
  File "test.py", line 29, in <module>
    jacobian = get_jacobian(lstm, inp)
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/def_function.py", line 568, in __call__
    result = self._call(*args, **kwds)
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/def_function.py", line 615, in _call
    self._initialize(args, kwds, add_initializers_to=initializers)
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/def_function.py", line 497, in _initialize
    *args, **kwds))
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/function.py", line 2389, in _get_concrete_function_internal_garbage_collected
    graph_function, _, _ = self._maybe_define_function(args, kwargs)
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/function.py", line 2703, in _maybe_define_function
    graph_function = self._create_graph_function(args, kwargs)
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/function.py", line 2593, in _create_graph_function
    capture_by_value=self._capture_by_value),
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/framework/func_graph.py", line 978, in func_graph_from_py_func
    func_outputs = python_func(*func_args, **func_kwargs)
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/def_function.py", line 439, in wrapped_fn
    return weak_wrapped_fn().__wrapped__(*args, **kwds)
  File "/Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/framework/func_graph.py", line 968, in wrapper
    raise e.ag_error_metadata.to_exception(e)
ValueError: in converted code:

    test.py:24 get_jacobian  *
        return tape.batch_jacobian(predictions, tensor_in)
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/backprop.py:1246 batch_jacobian
        sys.exc_info()[2])
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/six.py:702 reraise
        raise value.with_traceback(tb)
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/eager/backprop.py:1238 batch_jacobian
        parallel_iterations=parallel_iterations)
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/ops/parallel_for/control_flow_ops.py:189 pfor
        return f()
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/ops/parallel_for/control_flow_ops.py:183 f
        return _pfor_impl(loop_fn, iters, parallel_iterations=parallel_iterations)
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/ops/parallel_for/control_flow_ops.py:256 _pfor_impl
        outputs.append(converter.convert(loop_fn_output))
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/ops/parallel_for/pfor.py:1280 convert
        output = self._convert_helper(y)
    /Users/henryprior/anaconda3/envs/test/lib/python3.7/site-packages/tensorflow_core/python/ops/parallel_for/pfor.py:1460 _convert_helper
        (y_op.type, y_op, converted_inputs))

    ValueError: No converter defined for VariableShape
    name: "loop_body/VariableShape_2"
    op: "VariableShape"
    input: "binary_classification_lstm/lstm/while:10"
    attr {
      key: "out_type"
      value {
        type: DT_INT32
      }
    }

    inputs: [WrappedTensor(t=<tf.Tensor 'binary_classification_lstm/lstm/while:10' shape=() dtype=resource>, is_stacked=False, is_sparse_stacked=False)].
    Either add a converter or set --op_conversion_fallback_to_while_loop=True, which may run slower
    Encountered an exception while vectorizing the batch_jacobian computation. Vectorization can be disabled by setting experimental_use_pfor to False.

@henry-prior, I tried replicating the reported issue but getting different error, can help us to reproduce the issue. Please find the gist here. Thanks!

@gadagashwini I got the same error when running the code in a notebook, but when I ran it as a .py script (using a fresh venv) I got the error I posted in the issue. From briefly checking the tf code I believe the error in the gist is caused by the underlying problem from the error in the script. Let me know if you're able to reproduce this.

I could replicate the issue on local system as a .py  with Tf 2.1. Thanks!

Addin Rohan from core team. I think it might be an issue for tape. get_jacobian()
ValueError: No converter defined for VariableShape

Unassign myself since I don't think this is a LSTM issue. Feel free to assign back if you feel there is anything need to be fixed on RNN side. Thanks.

Support for VariableShape was added some time back. Can you check if this is still broken, and if so, does it give a different error.
Please test it against the nightly version, not 2.1.

I tested in nightly and got the following (different) error message:
NotImplementedError: Vectorization tried to stack variant tensor
Tensor("gradient_tape/binary_classification_lstm/lstm/while/gradients/grad_ys_3/pfor/Identity:0", shape=(), dtype=variant).
This is likely because vectorization of that variant is not fully supported yet

Should be fixed now (fix in https://github.com/tensorflow/tensorflow/commit/a20b5857915cd573f595942eab6a928ae3837639 integration test in https://github.com/tensorflow/tensorflow/commit/d5b5e1148ab3ef1817fadb864694ec3139746400), thank you for the report.


Can auto fillup method parameters?

if I write a method like setItemClick, can butterknife auto fillup the necessary parameters? I don't expect to remember all those parameters.
I know I can use int position as the parameter, but what if there are two int parameters.

It matches left to right. So if there are two int params you'll match the first two corresponding int parameters of the backing listener method, assuming there are at least two. To my knowledge there aren't any occurrences of this. The closest is the int and long parameters of a list click which correspond to the position and ID, respectively.

@JakeWharton thx for the explanation.
another question is whether butterknife can automatically fillup the parameters of the method? for example, i typed: @OnItemClick void onI, can it auto shows completion like onItemClick(), and auto fillup the 4 parameters of method?

No. It can't do that. That would require an IDE plugin which I'm not going
to develop, but someone is free to do so as a third-party extension.
On Sat, Mar 18, 2017 at 11:20 PM macarthor<EMAIL_ADDRESS>wrote:

@JakeWharton https://github.com/JakeWharton thx for the explanation.
another question is whether butterknife can automatically fillup the
parameters of the method? for example, i typed: @OnItemClick void onI,
can it auto shows completion like onItemClick(), and auto fillup the 4
parameters of method?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JakeWharton/butterknife/issues/905#issuecomment-287591364,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEQ6NOf-Hehs7SLgebD_8OoSKSvLTks5rnJ8JgaJpZM4MhVQB
.

@JakeWharton got it. many thx.


Disable ratchet by argument

For example, by default jest-ratchet would ratchet results, but if I were to run jest --disable-ratchet it wouldn't ratchet the results and the results would remain the same.

Option added in #25.  Closing.


Sample App may fail good_order behave test

Under some circumstances, creation of the nw sample fails to customize the data model for cascade delete.  This will lead to a failure in the behave test.
Until fixed, use ApiLogicServer create --project_name= --db_url=nw+ instead of the recommended defaulted db_url.
Under investigation.

Fixed in 10.03.06

Released in 10.03.06


Fails to build on some non-x86 platforms

Needs this upstream patch in order to build on at least powerpc: https://github.com/bitcoin/bitcoin/pull/12998

Is there something I can do about it? This is blocking me from contributing to rust-lightning because this doesn't build on my computer.

It was included in 0.16.1, so bumping the subtree should fix the issue.


As a backend developer I want to listen to customer feedback ( other Team which tests our system ) in order to address problems of the customer directly such that the customer is convinced of the product.

Improvements included alot of front end changes

Better buttons
Slimmed down layout
Removal of non-functional items
Backend
Added online player count etc


Git repository header fields should be aligned

See dashed blue line in second image:

It should be better now.

@girba Using GT version DEV v0.8.2504 released 2023-02-10T11:16:43 it looks like this UI could still use some alignment love:

It would also be really nice to have consistent vertical space between the fields. I’ve drawn the height of the first field’s baseline to the next field’s capline to highlight this:

Here’s a reference guide to caplines and baselines in case that’s helpful:


Fix flashy toolbar in 2661

This try to fix the problems in #2661 with the flashy toolbar if the user is not logged in, which where a little bit deeper than I expected, and no, we cannot live with the flash of the toolbar in a live site.

So, once I've delved into the real problem, tried to adjust Volto to it...
Cypress now is clunky and flaky because having to make the types endpoint depend on the actions response (we need to know in advance if we are really authenticated from the backend, before we can issue the @types call or not). A bunch of components that relied on the token to be present (which was immediate), now have to rely the backend response for it as well. All these provokes timing issues in Cypress (could be addressed probably, but hard). Also, relying on the backend call to know if we are really logged in, entails other problems, like, you don't have the username upfront, nor token, which should also be taken care.
These are my 5c: the changes this PR # 26621 introduces are far too substantial in how Volto behaves. Don't know if we (and the projects we have to maintain) are ready for it now, or if we could address it differently.
BTW, help is needed to fix Cypress (and probably other problems could all the changes provoke)...
@plone/volto-team Thoughts?

@sneridagh I agree that the risk is too high ATM. We would need a company that uses Volto extensively on a daily basis to step up and test this for a while in prod and is willing to fix all the issues that come up before we can consider trying to merge this again.

Cypress now is clunky and flaky because having to make the types endpoint depend on the actions response

I'm guessing this means that the integration tests that run using Cypress are now having issues related to my changes?  Can you elaborate?  Are there specific failures?  Errors?  Intermittent behavior?

you don't have the username upfront

Yeah, my plan for that when I was last working on this was to add a new API endpoint to return the user data that isn't included from the actions.  I know I wrote that up before but I can't find it quickly ATM, so please forgive the omission.  I'll try to remember to link back here when I do find it.

@rpatterson answering to all here.
I had to refresh myself on the issue, and the problem, sorry for not getting to you earlier.
First of all, I recreated the PR (from the reverted PR) in
https://github.com/plone/volto/pull/2661
and this PR is trying to solve the problems in there, so you can continue from here or there, whatever you want.
Core problem
First, let's define the core problem here in a TL;DR fashion: Volto relies in something "tangible" as is the JWT token. As tangible I mean that can be checked immediately, and lives in the user browser. Changing to anything async backend-based will be hard and difficult. Since now the JWT token it's the cornerstone where all the architecture relies on. So shouldn't be taken lightly and should be a thoughtful decision, as should be the implementation.
As you can see, I tried hard to succeed and spent already quite some time in this PR (given my experience in Volto) and I miserably failed. My take: as it is now, it can't be done in the way we would like to. Sorry for being that hard on this, but if someone else is able to get it done right given the current Volto needs and specifications, please show us.
So, I think as main outcome, that the whole architecture of the solution should be rethought. After you take an initial look at the depth of the problem and how we desire to fix it, we can have a meeting with the Volto Team and discuss about it all.
Also, since Eau de Web is pushing for it, I would like someone from the EdW Volto Team to help you during all the implementation and act as a liaison to the Volto Team.
Requirements

The toolbar should be permission aware, and dependant on it
Some other components are permission aware too, so it should be taken into account too
The @types endpoint should only be hit if we have to (egg. permissions to add)
The username (which we get now from the JWT token) should be known
The JWT token should be issued and put in place, if there's none and we are authenticated by other means
The "unified login" should be implemented as opt-in, if possible
We should test it thoroughly, both in Cypress and in real projects before merging

My personal take on this
To be honest, right now, I don't see this feature worth the effort nor the hassle. Also we are moving to a recommended way of deploying Plone 6 in a way that classic is completely hidden (using the new JSON-only traversal). So I don't see it as a priority right now. Also, I think that if really needed, a more lightweight solution could be more suitable/sustainable (like, eg. unifying cookies? we did that in the past, and although one could argue that it's not elegant, it's effective and works. We are anyways issuing them in the backend).
Also, we have now in our plate challenges far more interesting and valuable to solve than this one. For me the wins if this succeeds are very scarce, and poorly valuable comparing to other features. /cc @alecghica
Permissions handling in Volto
I would like to shed some history on this one too. So this has been a recurrent item in the Volto's to-do list. Effectively we don't have a way to know specific permissions of a user in an specific context. We always relied in inner implementation details for endpoints (and that worked so far). However, we can't do a thing that Plone does all the time when showing/hiding features in UI (or access to those features): checking for specific user permissions. Also another more trivial things (eg. show the registration link or not) that is registry setting powered.
In the future, we would like to get an unified way of doing this. I do not know if it's via the @actions endpoint or not. But we will need a way to handle these more effectively and performant way.
One of the reasons that we still haven't managed to handle it yet, is that we still do not know what's the silver bullet for this.
Questions

Can you elaborate on why this should be a thunk?

If everything relies on the response from the backend to the @actions endpoint, then some actions should fire (or not) after knowing if we are or not logged in, right? Then, this is used later in the Toolbar component, one as a result of the other. So it needed to be a thunk. I might not be aware of the latest Redux best practices, but how you make one action dependent on another? This is the way we did always.

Can you elaborate more on this than "fix @types missing"?

Same as above...

Can you elaborate on why you switched from !...login to !!...logout?

I do not remember now, but I had a problem of "nullish" value handling here (eg. null !== false), and of naming as far as I remember. I wrote the tests for getting it right. If I'm not mistaken it revolved around the fact that I don't want to know if I'm logged in, but I want I really want to know is if I'm logged out.

I'm guessing this means that the integration tests that run using Cypress are now having issues related to my changes?  Can you elaborate? Are there specific failures? Errors? Intermittent behavior?

You can see for yourself, and run cypress locally if you want (see the setup in the package.json scripts), take a look at the PR checks:
https://github.com/plone/volto/runs/3673409172?check_suite_focus=true
https://github.com/plone/volto/runs/3673416890?check_suite_focus=true

Yeah, my plan for that when I was last working on this was to add a new API endpoint to return the user data that isn't included from the actions. I know I wrote that up before but I can't find it quickly ATM, so please forgive the omission. I'll try to remember to link back here when I do find it.

We need all the things in "Requirements" as a whole, and working successfully in the resultant PR.

First, let's define the core problem here in a TL;DR fashion: Volto relies in something "tangible" as is the JWT token. As tangible I mean that can be checked immediately, and lives in the user browser. Changing to anything async backend-based will be hard and difficult. Since now the JWT token it's the cornerstone where all the architecture relies on. So shouldn't be taken lightly and should be a thoughtful decision, as should be the implementation.

Ah, this is very clearly stated and an important requirement to have well defined.  I'm not necessarily convinced by the rationalizations but I'll take this as direction. Thanks!

if someone else is able to get it done right given the current Volto needs and specifications, please show us.

I the requirement is that the Volto Redux UI state be based on, and only on, the JWT token, then to my mind that re-frames the core issue here to be one that all the involved PAS authentication plugins be kept in sync.  I don't have any reason to think that isn't achievable on the API/back-end side.  On the Volto Redux side the only additional handling required would be to recognize a JWT cookie when the authenticated session was initiated outside of the Volto login component.  This doesn't seem too invasive or hard to maintain given the benefit of being able to be agnostic as to how authentication was established.  This probably also removes the need for a new user data API endpoint, at lease not for this.

Also, since Eau de Web is pushing for it, I would like someone from the EdW Volto Team to help you during all the implementation and act as a liaison to the Volto Team.

I'm certainly happy to talk/pair/work with anyone.  If you're feeling that I'm directing too many of my questions or too much of my discussion at you, then please feel free to consider comments in PRs from me as directed at no one in particular and I'll refrain from @'ing you.  ;-)

Requirements

The toolbar should be permission aware, and dependant on it
Some other components are permission aware too, so it should be taken into account too
The @types endpoint should only be hit if we have to (egg. permissions to add)

IMO, these 3 requirements are outside of the scope of this specific concern, namely unifying authentication across the 3 existing ways of authenticating to Plone/Zope. Agreed?
BTW, this permissions stuff a problem I'd love to be a part of solving!  Zope's ACL/permissions system is one of the things I most love from Zope and tackling the ways it meshes and clashes with modern web UI seems like it would be a fun challenge.

Can you elaborate on why this should be a thunk?

If everything relies on the response from the backend to the @actions endpoint, then some actions should fire (or not) after knowing if we are or not logged in, right? Then, this is used later in the Toolbar component, one as a result of the other. So it needed to be a thunk. I might not be aware of the latest Redux best practices, but how you make one action dependent on another? This is the way we did always.

Ah, gotcha, so thunks are for "chaining"" actions.  If anyone cares to elaborate on why a different thing is needed for this in Redux and how thunks are the right thing, I feel like understanding that would make me a better Redux developer.

I'm guessing this means that the integration tests that run using Cypress are now having issues related to my changes?  Can you elaborate? Are there specific failures? Errors? Intermittent behavior?
You can see for yourself, and run cypress locally if you want (see the setup in the package.json scripts), take a look at the PR checks:
https://github.com/plone/volto/runs/3673409172?check_suite_focus=true
https://github.com/plone/volto/runs/3673416890?check_suite_focus=true

Thanks!  I haven't decided, given how the requirements are changing, if that will be next, but I'll dig into those failures at some point.

We need all the things in "Requirements" as a whole, and working successfully in the resultant PR.

Well, I think doing all this in one PR stacks a whole lot on top of it and makes for a large, hard to review PR.  I'm not convinced there aren't ways we could do this in smaller chunks.  And I'm saying that as someone who's PRs are way too often too large for the teams I'm working on.  ;-) That said, I'll take that as direction and make it work as one PR.
Thanks much for your time!

I the requirement is that the Volto Redux UI state be based on, and only on, the JWT token, then to my mind that re-frames the core issue here to be one that all the involved PAS authentication plugins be kept in sync. I don't have any reason to think that isn't achievable on the API/back-end side. On the Volto Redux side the only additional handling required would be to recognize a JWT cookie when the authenticated session was initiated outside of the Volto login component. This doesn't seem too invasive or hard to maintain given the benefit of being able to be agnostic as to how authentication was established. This probably also removes the need for a new user data API endpoint, at lease not for this.

Unfortunately, Plone 6 UI is more than a simple client-side Redux application. It does have its own requirements as a whole.

I'm certainly happy to talk/pair/work with anyone. If you're feeling that I'm directing too many of my questions or too much of my discussion at you, then please feel free to consider comments in PRs from me as directed at no one in particular and I'll refrain from @'ing you. ;-)

I'm more than happy to help on this one, but my time is limited too, and since this is effort sponsored by a Volto company, I think it's better that someone from the company that are part of the Volto Team this pairs with you and answers your questions about the app architecture and behaviour. I am open to meet and have a discussion on how we could design the solution in a way that is workable.

Requirements

The toolbar should be permission aware, and dependant on it
Some other components are permission aware too, so it should be taken into account too
The @types endpoint should only be hit if we have to (egg. permissions to add)

IMO, these 3 requirements are outside of the scope of this specific concern, namely unifying authentication across the 3 existing ways of authenticating to Plone/Zope. Agreed?

To be honest I can't see now if these requirements are not met, we could merge the feature... If you break the Toolbar behaviour, but your feature works well, how could we merge it? Plone 6 is bigger than a single feature. We can't release a product whose quality is below the previous release, right? This feature moves the corner stone of Plone 6 UI. If after you move it, you don't left things in the same place, then better not move it.

BTW, this permissions stuff a problem I'd love to be a part of solving! Zope's ACL/permissions system is one of the things I most love from Zope and tackling the ways it meshes and clashes with modern web UI seems like it would be a fun challenge.

That would be great!

Oops, I didn't notice ths PR was against my previous/old branch which I just deleted.  I thought it was obseleted by this branch.  At any rate, I think these changes should be reviewed against master anyways.  I don't see a way to edit what branch a PR is against, so I'll open a new PR.


Fix searchbox

I found a updated npm package called omega-react-js-search this has the bug fixes for the caseInsensitive prop please everyone do an npm i again after you do a pull. thanks


[pytorch] Fixes #1437, check empty IValue[]

Change-Id: If6bebfef02efb1d42b65b1dd58b591df8274ff24
Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report

Merging #1440 (26b6094) into master (bb5073f) will decrease coverage by 1.41%.
The diff coverage is 47.84%.

@@             Coverage Diff              @@
##             master    #1440      +/-   ##
============================================
- Coverage     72.08%   70.67%   -1.42%
- Complexity     5126     5299     +173
============================================
  Files           473      493      +20
  Lines         21970    23217    +1247
  Branches       2351     2532     +181
============================================
+ Hits          15838    16409     +571
- Misses         4925     5534     +609
- Partials       1207     1274      +67

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <ø> (-5.24%)
:arrow_down:

...odality/cv/translator/BigGANTranslatorFactory.java
33.33% <0.00%> (+8.33%)
:arrow_up:

...nslator/InstanceSegmentationTranslatorFactory.java
14.28% <0.00%> (-3.90%)
:arrow_down:

.../modality/cv/translator/YoloTranslatorFactory.java
8.33% <0.00%> (-1.67%)
:arrow_down:

...i/djl/modality/cv/translator/YoloV5Translator.java
5.69% <0.00%> (ø)

...odality/cv/translator/YoloV5TranslatorFactory.java
8.33% <0.00%> (-1.67%)
:arrow_down:

...modality/nlp/embedding/TrainableWordEmbedding.java
45.00% <0.00%> (-3.34%)
:arrow_down:

...pi/src/main/java/ai/djl/ndarray/BytesSupplier.java
54.54% <0.00%> (-12.13%)
:arrow_down:

...i/src/main/java/ai/djl/ndarray/NDArrayAdapter.java
15.23% <0.00%> (-0.83%)
:arrow_down:

... and 158 more

Continue to review full report at Codecov.

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


Fix: QuillToolbarToggleStyleButton Switching failure

Description
Fix: QuillToolbarToggleStyleButton Switching failure for block attributes
Related Issues

Fix #2216

Type of Change

[ ] ✨ New feature: Adds new functionality without breaking existing features.
[ X ] 🛠 Bug fix: Resolves an issue without altering current behavior.
[ ] 🧹 Code refactor: Code restructuring that does not affect behavior.
[ ] ❌ Breaking change: Alters existing functionality and requires updates.
[ ] 🧪 Tests: Adds new tests or modifies existing tests.
[ ] 📝 Documentation: Updates or additions to documentation.
[ ] 🗑 Chore: Routine tasks, or maintenance.
[ ] ✅ Build configuration change: Changes to build or deploy processes.

Thank you for addressing the pasteUsingPlainOrDelta() issue.
As a side note, we should avoid exposing new APIs to the public, when a new property or function is introduced, it should be experimental for a while before promoting to stable when something is deprecated it's probably better to create extension on the class and move the deprecated members there instead of having them in the main file, we usually want to make more members private unless there is a reason to not, or moving them into a separate file without exporting the internal file.
Also using @visibleForTesting is useful. It can be considered as a breaking change if that API commonly used.


x/pkgsite: link to standard library from homepage

What did you do?
Go to https://pkg.go.dev/
What did you expect to see?
A link to https://pkg.go.dev/std
What did you see instead?
Just examples of search terms.
If you already know the name of packages in the standard library, it's not a big deal to search for them, but if you want to explore the standard library, you need to find https://pkg.go.dev/std somehow, and the homepage gives no indication of how to get there.

Technically you can click on "Docs", which leads to golang.org/doc, and then on "Packages", which leads to pkg.go.dev/std
But yes, at the latest when all content from golang.org is moved to go.dev the link needs to find a new home.

This is already tracked in #40785, closing here in favour of the older thread.


New Images Don't Save Without Interaction

If you take a new picture within the library and tap "Next" until the library processes are done, the photo is not saved to the phone. The only way to get it to save is to tap a filter which includes "Normal" after which it will save. If the photo is newly taken, it should save regardless of whether a filter is selected.

Below is my quick hack update to this in YPImagePicker. Now if a picture is newly taken in the library and no changes are made to it, it will still save as long as the shouldSave boolean is true.
 case .photo(let photo):
                let completion = { (photo: YPMediaPhoto) in
                    let mediaItem = YPMediaItem.photo(p: photo)
                    // Save new image to the photo album
                    if YPConfig.shouldSaveNewPicturesToAlbum
                    {
                        var modifiedImage = photo.modifiedImage
                        if photo.fromCamera && modifiedImage == nil {
                            modifiedImage = photo.originalImage
                        }
                        if modifiedImage != nil {
                            YPPhotoSaver.trySaveImage(modifiedImage!, inAlbumNamed: YPConfig.albumName)
                        }
                    }
                    self.didSelect(items: [mediaItem])
                }


Automated cherry pick of #4829: fix: 公有云日志权限列表

Cherry pick of #4829 on release/2.13.
#4829: fix: 公有云日志权限列表

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.13@f3c16ac). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release/2.13   #4832   +/-   ##
==============================================
  Coverage                ?   6.85%
==============================================
  Files                   ?     523
  Lines                   ?   89199
  Branches                ?       0
==============================================
  Hits                    ?    6117
  Misses                  ?   82573
  Partials                ?     509

Flag
Coverage Δ

#aFlag
6.85% <ø> (?)

Impacted Files
Coverage Δ

pkg/cloudcommon/policy/resources.go
0% <ø> (ø)

Continue to review full report at Codecov.

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

/lgtm

/approve


Expose stack outputs to Action

Hi there, not so much an issue as a feature request or question.
I am experimenting with using Actions + CDK to deploy a Lambda function with API Gateway, and as you probably know, on success the URL of the API is output as a "stack output" by CDK.
Is it currently possible, or could you consider making it possible, to somehow capture such stack outputs for re-use in the Action, perhaps as an environment variable?
Example use case: I deploy my api with gitops and would like to receive a Slack post (sent by the action) which includes the API url from the stack output later in the workflow on a successful deployment.

This can be done with outputs, although it might be tricky to capture the API URL from the CDK output.

cdk seems to output the line Outputs: followed by key-value pairs in the format key = value. Perhaps they could be mapped up to Action outputs generally, just passing through the CDK outputs as Action outputs (with a prefix?), and leaving the job of understanding them to the downstream jobs.
E.g.:
Outputs:
test001.Endpoint*** = https://***.execute-api.ap-southeast-2.amazonaws.com/prod/

TBH I'll probably be doing this sort of thing with custom domain names most of the time anyway so I wouldn't consider this urgent, but it would be nice to have. Getting the stack outputs accessible might be pretty useful generally though,


Unable to run the application in Azure Cloud Shell

Hi,
I'm doing th 'Use shared access signatures to delegate access to Azure Storage' exercise and found that the sample application does not run:
azureuser@Azure:~/sas$ dotnet run
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
  * You intended to execute a .NET program:
      The application 'run' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible installed .NET SDK for global.json version [3.1.401] from [/home/azureuser/sas/global.json] was not found.
      Install the [3.1.401] .NET SDK or update [/home/azureuser/sas/global.json] with an installed .NET SDK:
        6.0.300 [/usr/share/dotnet/sdk]

I'm not a .NET developer and don't know if below findings and solution are valid, but I found that in Azure Cloud Shell a newer version of .NET is available:
azureuser@Azure:~$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.300
 Commit:    8473146e7d

I adjusted the version in global.json:
azureuser@Azure:~/sas$ cat global.json
{
  "sdk": {
    "version": "6.0.300",
    "rollForward": "latestMinor"
  }
}

And in patient-records.csproj:
azureuser@Azure:~/sas$ cat patient-records.csproj
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp6.0</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <RootNamespace>patientrecords</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Azure.Identity" Version="1.4.1" />
    <PackageReference Include="Azure.Storage.Blobs" Version="12.9.1" />
  <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="6.0.5" />
  </ItemGroup>
</Project>

With these changes in place application started successfully:
azureuser@Azure:~/sas$ dotnet run
info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[62]
      User profile is available. Using '/home/azureuser/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
info: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to https://localhost:8001 on the IPv6 loopback interface: 'Cannot assign requested address'.
info: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to http://localhost:8000 on the IPv6 loopback interface: 'Cannot assign requested address'.
Hosting environment: Development
Content root path: /home/azureuser/sas
Now listening on: https://localhost:8001
Now listening on: http://localhost:8000
Application started. Press Ctrl+C to shut down.

As stated before, I'm no .NET expert and don't know if above is a valid solution or just a hack, but it would be great if someone with more expertience could fix the sample app to make the learning experience a bit better.
Thanks!
Pawel

Hi Pawel,
I just experienced the same issue as you. I am not a .NET expert neither but your fix made it work for me.
Thanks!
JC

Hi Pawel,
Your solution worked for me as well!
Thanks

This just happened to me and required me to update global.json with these contents:
{
  "sdk": {
    "version": "7.0.302",
    "rollForward": "latestMinor"
  }
}

and patient-records.csproj with these contents:
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp7.0</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <RootNamespace>patientrecords</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Azure.Identity" Version="1.4.1" />
    <PackageReference Include="Azure.Storage.Blobs" Version="12.9.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="6.0.5" />
  </ItemGroup>
</Project>

This solution really worked for me. Thanks and Cheers!

Same issue happened again. Project uses 7 but cloud has .NET 8 installed. Opened a pull request to update to .NET 8
Note, I'm not a .NET dev, but I tested the change and seems to work fine.
https://github.com/MicrosoftDocs/mslearn-control-access-to-azure-storage-with-sas/pull/19


redux/tests

In this PR tests for Reducers and Actions added.

@ishpaul777  please remove changes to package-lock.json and remove the changes to kratos.yml


Nominatim Geocoding gets errors when running the function

Hello,
I use Excel 2019 Professionnal 64 bits, when i try to use Nominatim functions : nominatimgeocode and NominatimReverseGeocode , the returned result is an error message : " Echec  du téléchargement de la ressource spécifiée"
Would you please tell me how to fix that issue ?
Thanks,

This looks like an Excel reference library version issue. Let me see if I can spot where this happens...

Hello,
I use Excel 2019 Professionnal 64 bits, when i try to use Nominatim functions : nominatimgeocode and NominatimReverseGeocode , the returned result is an error message : " Echec du téléchargement de la ressource spécifiée"
Would you please tell me how to fix that issue ?
Thanks,

@lcoulon I had the same issue on an Excel with european regional parameters, i.e. that uses a comma as decimal separator, which is not compatible with the API format (latitudes and longitudes should be with a point as decimal symbol)
I solved the issue by replacing
xDoc.Load ("https://nominatim.openstreetmap.org/reverse?lat=" + CStr(lat) + "&lon=" + CStr(lng))
by
xDoc.Load ("https://nominatim.openstreetmap.org/reverse?lat=" + Replace(CStr(lat), ",", ".") + "&lon=" + Replace(CStr(lng), ",", "."))

@Walfou -- thanks for this. The issue completely stumped me. I believe replacing CStr with Str will suffice, since Str() uses English conventions, while CStr() is locale aware. I'll put in a fix.


Documentation link broken in the About section

Hey @krishdevdb 👋🏽 This docs link is broken in the about section of this repository, please do fix it.
Also, I was looking at this project and you all have maintained it well. Pretty good!! Keep it up folks 🔥

I can work on this issue. What should be the correct link?
https://github.com/resetercss/reseter.css?

Hey @deepmalamittal 👋🏽 Thanks for showing interest 🔥
@krishdevdb Can you look into this issue and assign it to @deepmalamittal if possible?

Here is the pull request for the same: https://github.com/resetercss/reseter.css/pull/84

Is this issue fixed? If not then I would like to work on this

can i help some??

Can you assign this issue to me, I would Like to help. Thanks

Please provide the correct link to the documentation.

The correct link is https://resetercss.github.io/reseter.css/ I believe. I think the owner of the repo has to update it though?

Is this issue still good to work on? As someone stated above, the link seems good, the owner has to add it, however.

Is this project being worked on by anyone? Please let me know if there are any issues that I can work on.

@krishdevdb Is this issue still open? If it is can you assign it to me, I would like to work on it.

@krishdevdb If this issue is still unsolved, I would like to contribute. Please assign me to it. Thank You.

@krishdevdb I would like to solve this issue give it to me

Thanks for the involvement, everyone, but I don't know how, y'all except Yash, tagged my previous account, which led to me not getting the notification. The link in the sidebar can only be updated by staff 👍 I am doing it now


fixed url and add telemetry

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

Closing this due to lack of activity, please create a new PR if needed


[RfR] Move profile image to links

Purpose
https://openscience.atlassian.net/browse/OSF-4535
Changes

move /data/attributes/profile_image_url to /data/links/profile_image
add helper for adding dict items based on DEV_ONLY mode

Side effects,
None

CR1 complete. This works, and no changes requested.
That said: it's worth noting that NodeContributorsSerializer will also need to be updated to stay consistent. I assume this is planned in a separate ticket (?), but am mentioning it just in case.


Empty lines should not get line numbers in PDF

For this, the complete parsing of lists has to be rewritten.
Recreate with a list and insert two linebreaks with shift+enter. The empty line gets a line number. This shifts all line numbers in the list.

Line numbers now reflect the web-view


Basic one-sided formula support

quick examples:
devtools::load_all("~/Documents/Projects/plot2")
#> ℹ Loading plot2

par(pch = 16)

plot2(~ Temp, airquality)

plot2(~ Temp | Month, airquality, type = "b", par_restore = TRUE)

plot2(~ Temp | Day * Month, airquality, legend = FALSE)

Created on 2023-08-15 with reprex v2.0.2

@zeileis do you mind taking a look at this? Note that this PR just provides basic one-side formula support and doesn't yet address #61. (I have some ready to roll on top of this PR that does address #61, but it starts to get a little more complicated, so I want to hold back on it until we're happy with the basic scaffolding.)

Nice! The only problem I saw was that the bylab title is wrong in the case where the are multiply by variables. In your example you had to switch off the legend because it got too long. A more manageable example could be:
airq <- transform(airquality, Temp = factor(Temp > 85, levels = c(FALSE, TRUE), labels = c("low", "high")))
plot2(~ Ozone | Temp + Month, data = airq, col = rep(palette.colors(5, "Tableau"), each = 2), pch = rep(c(1, 19), 5))

The fix would have just been to replace -(1L:2L) with -yxloc when putting together the bylab. However, when I went through the code I thought that I would add some more comments, add an explicit logical variable no_y, simplify the error message, and a couple of other small changes. They don't change the behavior of the code but I think it is a bit more readable now. Should I push this to the branch so that you can have a look? Or should I just make the minimal change?

OK, I have pushed all my changes (including the cosmetic ones) now, I hope that's alright. Otherwise feel free to revert.

Excellent, thanks!
Btw, on the subject of legends that are too long, I have some ideas for continuous variable legends with interpolated (gradient) palette. I’ll create an issue and tag you when I get a sec to write up my thoughts.

This would probably mean that we shouldn't just coerce all by variables to factors. The continuous gradient you mention could then be used for numeric by variables. However, the same idea/trick could not be used for other properties (pch or lty) that are necessarily discrete. Additionally/alternatively, one could be smarter in coercing numeric by variables to factors. Rather than just always using all unique variables via factor() one could cut() the variable at some quantiles - similar to what lattice does. My feeling was that this could easily get confusing, though, hence I did not try to do anything like that in the formula method.


Github.io site is wrong

Should be blueskyproject.io, not blueskyproject.github.io

E.g. https://github.com/bluesky/python3-pip-skeleton/blame/main/docs/developer/how-to/update-tools.rst#L16

Will also change in the skeleton adoption branch and squash

No need to squash, put on a branch in this skeleton, do a PR, this will do a rebase onto main, then do a git pull python3-pip-skeleton from event model and it should all work

Ah I already squashed, never mind though, will still be able to git pull fine.


Add OMOP dataset + workflow

test result of the BPDanek/PyHealth/master
https://github.com/BPDanek/PyHealth/actions/runs/4259851645


Add support for C++

I tested this extension as it looked quite neat, but unfortunately after installing and while trying it out, I got the message that C++ was not supported.  It would be nice if it was.

Hi @BartVandewoestyne,
thanks for the feedback. I currently don't have the capacity to implement such a feature (especially since I am not a C++ developer and can't really test this feature by myself).
But feel free (or anyone else) to contribute via Pull Request!


Skin changer crashing game everything else working fine.