Feature/reduce level

Closes #169

Codecov Report

Merging #259 (6fc3855) into main (ea29479) will increase coverage by 0.007%.
The diff coverage is 98.058%.

@@              Coverage Diff              @@
##              main      #259       +/-   ##
=============================================
+ Coverage   96.946%   96.953%   +0.007%
=============================================
  Files           55        55
  Lines         2685      2724       +39
=============================================
+ Hits          2603      2641       +38
- Misses          82        83        +1

Impacted Files
Coverage Δ

src/adiar/internal/reduce.h
98.400% <97.619%> (-0.723%)
:arrow_down:

src/adiar/internal/levelized_priority_queue.h
100.000% <100.000%> (ø)

src/adiar/internal/sorter.h
100.000% <100.000%> (ø)

src/adiar/internal/util.h
100.000% <0.000%> (ø)

src/adiar/bdd/bdd.cpp
83.607% <0.000%> (+0.556%)
:arrow_up:

src/adiar/zdd/zdd.cpp
64.706% <0.000%> (+1.070%)
:arrow_up:

Continue to review full report at Codecov.

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

Two primary things to note from the coverage report:

We don't seem to have a unit test for 2+ red1_mappings
As expected: only the internal memory variant is run.

The 14-Queens results look quite disheartening. How can an external memory merge sort be faster than quick sort on a purely internal memory vector?

The 3.15 s for 9-Queens is because somehow the counting time got lost.

For the 9-Queens we spend ~11s on the final bdd_satcount. That is the above is in he Apply-Reduce tandem only

Minimum running time (s) for 9-Queens:

origin/main
origin/feature/reduce_level

4.27
3.46

Which is a 19% performance increase!

I wrote an email to the people at SCALGO, and they suggest to use tpie::parallel_sort. My initial experiments in #98 were not promising with this, but that might have been because it was an -O2 and Debug build. @AnnaBlume99 , what happens if we change the std::sort to a tpie::parallel_sort in a new commit?
I also have a hunch, that our algorithms create semi-sorted input which may mess with the QuickSort algorithm.

Mathias Rav also just chimed in on email, highlighting that the tpie::merge_sorter already tries to handle small instances. That is, we might not gain much when the number of elements to sort exceed the phase 1 memory of the sorter.
So, we might want to lift the external_sorter phase memory computations to be static functions such that they can be obtained from the outside. Presumably, our idea is only better when the tpie::internal_vector::memory_usage(level_width) is going to be smaller than the external_sorter.phase_1_memory(memory_bytes, level_width)

Hmm, that's now three times we have the last line of the console log missing and hence the timing being off by a major margin. For 9-Queens we only see

Minimum running time (s) for 9-Queens:

origin/main
origin/feature/reduce_level

15.89
15.22

Which is only a 4.2% performance increase.

Impressive! There potentially is a slowdown for very small instances by switching to tpie::parallel_sort, but it stays competitive for very large instances. We might get back to whether to use std::sort another day.
Again, subtracting the time for the bdd_satcount (resp. ~11s, ~18s, ~28s), we get:

N
origin/main
origin/feature/reduce_level
Improvement

9
4.89
4.22
13.7%

12
25.48
23.39
8.20%

14
692.42
682.16
1.48%

Which again, if doubled gives us (roughly) the performance increase of the Reduce algorithm.


application does not start trying to access the printers

Here is the generated output:
$ alm
DASHBOARD: http://localhost:4444
Globbing error: { [Error: EPERM: operation not permitted, scandir 'C:\Users\ccron\Ambiente de Impressão']
errno: -4048,
code: 'EPERM',
syscall: 'scandir',
path: 'C:\Users\ccron\Ambiente de Impressão' }
C:\Users\ccron\AppData\Roaming\npm\node_modules\alm\src\server\workers\fileListing\fileListingWorker.js:106
var list = newList.map(function (nl) {
^
TypeError: Cannot read property 'map' of undefined
at Glob. (C:\Users\ccron\AppData\Roaming\npm\node_modules\alm\src\server\workers\fileListing\fileListingWorker.js:106:35)
at Glob.f (C:\Users\ccron\AppData\Roaming\npm\node_modules\alm\node_modules\once\once.js:17:25)
at emitOne (events.js:77:13)
at Glob.emit (events.js:169:7)
at Glob._readdirError (C:\Users\ccron\AppData\Roaming\npm\node_modules\alm\node_modules\glob\glob.js:574:14)
at C:\Users\ccron\AppData\Roaming\npm\node_modules\alm\node_modules\glob\glob.js:525:12
at FSReqWrap.oncomplete (fs.js:82:15)
fileListingWorker worker restarting. Don't know why it stopped with code: 1

Here is the generated output:

you probably started it some root level (e.g. c:\). We glob the whole folder to provide a faster search for file experience. Please start at a project level folder.
Leaving it open as we should provide a better error experience here :rose:

That is true, I was trying to run it in my home directory. Running it in a project directory it works.

We now report this as an error :rose: 0.3.2


Consider dropping client request body support for GET and HEAD

For GET
  A payload within a GET request message has no defined semantics;
   sending a payload body on a GET request might cause some existing
   implementations to reject the request.

for HEAD
 A payload within a HEAD request message has no defined semantics;
   sending a payload body on a HEAD request might cause some existing
   implementations to reject the request.

For the client?  With the goal of sending neither Content-Length nor Content-Transfer-Encoding headers?  I assume this is inspired by #3027?

for the client yes. the server can do what it wants. Since the spec also discourages use of bodies on GET and HEAD, i think we should follow that even if its not a MUST or SHOULD

We've run into a few people using terrible APIs that require it.  I think we should grudgingly allow it, but not send Content-Length or Transfer-Encoding headers that imply a body unless there is one, which we've been tightening up. #4509 should lock that down further.


Class for last active mark

Describe the feature
Hi, currently there is a class on all active mark.
Which prevent us from highlighting  the current value.
Here is what our design team came up with.

Describe the solution you'd like
Would it be possible to add a class on the last active mark or the nearest to the value ?
Something like vue-slider-mark-current that would only apply to one mark instead of all the mark with value lower than the current value.

Try using the slot:
    <vue-slider v-model="value">
      <template v-slot:label="{ lvalue: labelValue }">
        <div :class="['vue-slider-mark-label', { active: labelValue === value }]">{{ label }}</div>
      </template>
    </vue-slider>

There is no lvalue or labelValue on the scoped-slot unless I'm misunderstanding

I made it work with the @change event, but I feel like this should be a core functionality as it's a pretty common pattern to hightlight only the current value and not all the active value. This would only require a new props and maybe adding the class by default as it wouldn't require every use to create a v-slot:label everytime

Ok, thanks I got it.
Much clearer after a short break.
I was able to make it work.
Was a bit more complicated because I wrap vue-slider into a component so I have 2 value, one from the scoped-slot and one from my v-model.
But I still think this should probably be built-it in a future version.
<template>
    <vue-slider ref="slider" v-bind="$attrs" :height="6" tooltip="none" adsorb v-on="$listeners" @change="onChange">
        <template #label="slot">
            <div :class="['vue-slider-mark-label', { 'vue-slider-mark-label-current': slot.value === value }]">
                {{ slot.label }}
            </div>
        </template>
    </vue-slider>
</template>

<script>
export default {
    model: {
        prop: 'value',
        event: 'change',
    },
    props: {
        value: {
            type: String,
            default: '',
        },
    },
};
</script>

Should I keep this open as a feature request or close since there is a workaround ?

You can keep this issue, but it should not be realized in a short time. 😿

@mrleblanc101 Bonjour, rien à voir, mais comment implémentes-tu le slider avec cet aspect "<>" ?
J'aimerai bien avoir une telle apparence sur mon slider ;)

@piolet CSS


[asmgen] generate code for stack argument access differently

To save excess arguments on the stack, previously we would

store the argument using SW with an immediate offset basing from locals-base register. This limits the offset to 12 bits.
Store the offset to the first excess argument to the last ARG register so that callee can access these.

This PR reverses the order. It stores the offset to the last ARG register first. Then the store of argument to the stack slot can be made without requiring large immediate offsets, basing just on the last ARG register.
Fixes #6646

Should we add the test program from the original issue to our test suite?

Done.


Feat: Added ApiException implementation

Added an ApiException where so you can throw a new ApiException that returns an ErrorCode and ErrorMessage

@nickonos To what issue does this correlate?
At the moment there is an open issue #40 what looks like the changes you made.


New Sample: Realistic Lighting and Shadows

Hello,
I was able to take the existing Realistic Lighting and Shadows Java sample and separate the view and the controller. Since it's my first sample I'm sure there is a lot I can improve.
Some areas I would like some feedback are:

the Portland buildings scene layer and camera, based on Hudson's Android sample
changeTimeOfDay() to handle the changing slider value, inspired by the existing setSliderLabels()
setTimeLabel(), inspired by setSliderLabels()
in main.fxml, I want to make sure I replicated the padding and margins with FXML
using SimpleDateFormat to set the time zones and tidy up the time label
the button event handlers inside initialize() - should these be in a separate method?

Thanks

Hi @sclaridge , just to get back to the specific points you asked about, and I didn't manage to address within the code:

the Portland buildings scene layer and camera, based on Hudson's Android sample

This is just fine. We generally keep the data and viewpoints consistent between all the SDKs so it's nice and neat

the button event handlers inside initialize() - should these be in a separate method?

These are good where they are, but once we move to using RadioButtons, it may be possible to trigger a method using a reference in the FXML definition of each RadioButton, e.g.
<RadioButton onAction="#changeLightingMode"/>

Also, I think this sample would look great in the SampleViewer if we recorded a gif!
I use 'snagit' (which should be available in your SoftwareCenter) to record gifs. It's quite intuitive, but let me know if you get stuck. The dimensions for the gif should be the same as the screenshot, 800x400 px


Double firing of AJAX

When submitting a license request the is returned the first time multiple requests could happen.
This also could happen if you click the install button then exit the thickbox modal and click install on a separate download. Thinking an AJAX modal is needed or generated inline of each download.

What if we did something like this:
// set our transient name here
$transient_name = 'my_updater_running_tasks';
// Get any current tasks.
// returns false if none are set.
$current_tasks = get_transient( $transient_name );
$current_tasks = ( false === $current_tasks ) ? array() : $current_tasks;
// This is the task we want to add.
// $id is the product-if for example
// $args are whatever we need.
$new_task = array(
    $id => $args,
);
// merge the arrays
$tasks = wp_parse_args( $new_task, $current_tasks );
// update transient if needed
if ( $current_tasks != $tasks ) {
	set_transient( $transient_name, $tasks, 600 );
}

Then we can check the value of the transient and no duplicate tasks will be contained there... no matter what users do

So basically, create a queue of requests in a transient and process them using that as reference.
It doesn't have to be a transient... we can use options too, as long as we delete it when the process is done to avoid filling up the wp_options table with trash

Interesting idea. I'll play around with this the next few days while I am at Pressnomics.

Archiving this repository and moving things to new repos (links in the readme file) so I'll go ahead and close this one.
The new versions will be completely rebuilt from scratch so any and all issues that existed will be resolved when I'm finished with them.


Optimize TrieLookupTable

@mattklein123 put some work, many years ago, into optimizing HeaderMapImpl for header lookups that are constant-time in terms of the total number of headers. More recently, @ramaraochavali extracted the Trie code into common for use in Redis.
I was poking around a bit, looking at some performance data from our Envoy deployments at Google, and found that we spend about 1-2% of our CPU time on the worker threads in Envoy::TrieLookupTable::find, called from Envoy::Http::HeaderMapImpl::StaticLookupTable::lookup. If we can squeeze a bit more performance out of this, it's worthwhile for us, and I think I may have found a way to do so.
The current TrieLookupTable implementation is sparse and uncompressed: each TrieEntry contains an array with 256 entries, keyed by a single character. We can think of find() as being worst-case O(n) in terms of the number of characters in the string_view key: we traverse entries until we either know the trie doesn't contain our key, or we've found it. Of course, any lookup implementation will have O(n) worst case time complexity in the length of the key (for example, if we just used a hash map, we have to look at all the characters to compute a hash), but the repeated pointer traversal may add a significant constant factor. Pointer traversal is more expensive than accessing sequential bytes in CPU cache.
So I did a bit of digging in the literature and found a couple data structures for this purpose that are more cache-friendly:

Cache-conscious string hash tables: a fast, unordered hash optimized for strings.
HAT-Trie: an ordered prefix trie that is compressed to achieve similar lookup performance to the cache-conscious hash table, with lower memory consumption.

There are some promising benchmarking results in these papers, but I haven't yet done any benchmarking in the context of Envoy yet, to compare the current implementation against them (or, for that matter, against absl::flat_hash_map). Matt previously pointed out that we probably need to flesh out our existing benchmarks more. I know @adisuissa has done some work in this area before as well, so we'll chat and figure out the right thing to do.

Also consider perfect hash-tables for a set of keys known at compile-time: https://www.gnu.org/software/gperf/manual/gperf.html

FWIW sample gperf usage in a C++ system built with bazel:

https://github.com/apache/incubator-pagespeed-mod/blob/41aa63a027ed428b86ecaf2a1eaf3fda28d821b8/net/instaweb/rewriter/BUILD#L162
https://github.com/apache/incubator-pagespeed-mod/blob/master/net/instaweb/rewriter/rewrite_filter_names.gperf

It'd be worth just doing the easiest thing first though and try using absl::flat_hash_map.

It'd be worth just doing the easiest thing first though and try using absl::flat_hash_map.

Agree this is worth trying. This trie code originates from 5+ years ago, well before we were using abseil, and in response to some silly horse race benchmarks with nginx. There are likely better ways of doing it than this simple trie.

+1 on first trying to use absl::flat_hash_map which I think is a very simple change to make it happen.
As for the kind of benchmarks, IIUC most of the header names have the same prefix, so we should aim for tests that capture this scenario. Not sure if there's a known distribution of the header name length, but I guess we should test various lengths between 4 to 128.

RE "same prefix": can you give examples?
I was thinking of very common things like "Date", "Cache-Control", "Content-Type", "Cookie".
There's also the common case where a bunch of custom headers are in use and they all fail the builtin-header lookup. Failing that lookup should be fast too.

I meant the ones that use this prefix. I guess that some of the other (e.g., those that start with "content-" or "grpc-" can also be considered using the same prefix).

That dynamic-ish prefix makes it less elegant to use something like gperf, but my suspicion is that with absl::flat_hash_map we could get some benefit without having to think too much about a hierarchical prefix lookup first. It'd be best to get some benchmarks.

Alright, I did some basic benchmarking of a few different implementations, including the "HAT-Trie" I linked above. I will try to present the benchmark code and the results in some reasonable format here tomorrow, but for now I'll summarize: absl::flat_hash_map seems like a good choice. Probably somewhere between 10-100x faster than the current implementation in my environment, depending on the number of entries and the length of the keys.


Tests are disable and failing in master

when your github action runs:
https://github.com/spotify/backstage/runs/552952974?check_suite_focus=true
The tests don't run in master because you have --since origin/master
Run yarn test
yarn run v1.22.1
$ cross-env CI=true lerna run test --since origin/master -- --coverage
lerna notice cli v3.20.2
lerna info ci enabled
lerna notice filter changed since "origin/master"
lerna info Looking for changed packages since origin/master
lerna success run No packages found with the lifecycle script 'test'
Done in 0.58s.

If I remove --since origin/master to run all tests,  the tests are failing with:
lerna ERR! yarn run test --coverage stderr:
 FAIL  src/components/WelcomePage/ToggleFeatureFlagButton.test.tsx
  ● Test suite failed to run

    TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
    src/components/WelcomePage/ToggleFeatureFlagButton.test.tsx:25:8 - error TS2307: Cannot find module '@backstage/core'.

    25 } from '@backstage/core';
              ~~~~~~~~~~~~~~~~~

 FAIL  src/plugin.test.ts
  ● Test suite failed to run

    TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
    src/plugin.ts:17:30 - error TS2307: Cannot find module '@backstage/core'.

    17 import { createPlugin } from '@backstage/core';
                                    ~~~~~~~~~~~~~~~~~
    src/plugin.ts:22:14 - error TS7031: Binding element 'router' implicitly has an 'any' type.

    22   register({ router, featureFlags }) {
                    ~~~~~~
    src/plugin.ts:22:22 - error TS7031: Binding element 'featureFlags' implicitly has an 'any' type.

    22   register({ router, featureFlags }) {
                            ~~~~~~~~~~~~

 FAIL  src/components/WelcomePage/WelcomePage.test.tsx
  ● Test suite failed to run

    TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
    src/components/WelcomePage/WelcomePage.test.tsx:26:8 - error TS2307: Cannot find module '@backstage/core'.

    26 } from '@backstage/core';
              ~~~~~~~~~~~~~~~~~

 FAIL  src/components/WelcomePage/ErrorButton.test.tsx
  ● Test suite failed to run

    TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
    src/components/WelcomePage/ErrorButton.test.tsx:20:55 - error TS2307: Cannot find module '@backstage/core'.

    20 import { ApiRegistry, errorApiRef, ApiProvider } from '@backstage/core';
                                                             ~~~~~~~~~~~~~~~~~

Failed to collect coverage from /Users/557659/backstage/plugins/welcome/src/plugin.ts
ERROR: TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
src/plugin.ts:17:30 - error TS2307: Cannot find module '@backstage/core'.

17 import { createPlugin } from '@backstage/core';
                                ~~~~~~~~~~~~~~~~~
src/plugin.ts:22:14 - error TS7031: Binding element 'router' implicitly has an 'any' type.

22   register({ router, featureFlags }) {
                ~~~~~~
src/plugin.ts:22:22 - error TS7031: Binding element 'featureFlags' implicitly has an 'any' type.

22   register({ router, featureFlags }) {
                        ~~~~~~~~~~~~
STACK:
Failed to collect coverage from /Users/557659/backstage/plugins/welcome/src/components/Timer/Timer.tsx
ERROR: TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
src/components/Timer/Timer.tsx:18:29 - error TS2307: Cannot find module '@backstage/core'.

18 import { HeaderLabel } from '@backstage/core';
                               ~~~~~~~~~~~~~~~~~
STACK:
Failed to collect coverage from /Users/557659/backstage/plugins/welcome/src/components/WelcomePage/ToggleFeatureFlagButton.tsx
ERROR: TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
src/components/WelcomePage/ToggleFeatureFlagButton.tsx:19:62 - error TS2307: Cannot find module '@backstage/core'.

19 import { FeatureFlagState, featureFlagsApiRef, useApi } from '@backstage/core';
                                                                ~~~~~~~~~~~~~~~~~
STACK:
Failed to collect coverage from /Users/557659/backstage/plugins/welcome/src/components/WelcomePage/ErrorButton.tsx
ERROR: TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
src/components/WelcomePage/ErrorButton.tsx:19:37 - error TS2307: Cannot find module '@backstage/core'.

19 import { errorApiRef, useApi } from '@backstage/core';
                                       ~~~~~~~~~~~~~~~~~
STACK:
Failed to collect coverage from /Users/557659/backstage/plugins/welcome/src/components/WelcomePage/WelcomePage.tsx
ERROR: TypeScript diagnostics (customize using `[jest-config].globals.ts-jest.diagnostics` option):
src/components/WelcomePage/WelcomePage.tsx:36:8 - error TS2307: Cannot find module '@backstage/core'.

36 } from '@backstage/core';
          ~~~~~~~~~~~~~~~~~
STACK:
Test Suites: 4 failed, 4 total
Tests:       0 total
Snapshots:   0 total
Time:        39.516s
Ran all test suites.
Command 'web-scripts' exited with code 1
error Command failed with exit code 1.

lerna ERR! yarn run test --coverage exited 1 in '@backstage/plugin-welcome'
lerna WARN complete Waiting for 1 child process to exit. CTRL-C to exit immediately.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

#445 should fix the master build not running tests and lint properly.
The tests are actually fine though, but you need to build first. Made that part of the root test script in the PR as well, but would like to merge that into tests or remove the need.


support -a reader as --additionals kamidana.additionals.reader

this is not good?
if creating toplevel module foo, and this is additional modules for kamidana, then running kamidana with kamidana -a foo, but this is treated as 'kamidana.additionals.foo' ?


Remove DTGP method reference

DTGP method is not needed. e.g. on SSDT-PLUG had DTGP method but no improvement had been discovered.
This PR removes DTGP method from SSDT-RX580

How do you know that? Just because it isn't needed for one device doesn't mean it is irrelevant for another one.
No merge until further proof.

It's actually a dead code. https://github.com/acidanthera/OpenCorePkg/commit/521196baabd991a4f6b337a1c2f70c26ca252f32

Well, it was removed SBUS-MCHC Table because the method wasn't used in this table. But Local0 is used in SSDT-Rx580.

Well, on SSDT-PLUG DTGP method was used but then removed: https://github.com/acidanthera/OpenCorePkg/blob/f6b4ac59be255a5592ce0aad6e849a1e5b6a7ccb/Docs/AcpiSamples/SSDT-PLUG.dsl

But the method was not just removed, the whole table was re-written in this case. @Baio1977 Can you have a look at the SSDT-RX580 table and check if it's okay, to simple delete the DTGP method fand references from it? Thanks.

https://github.com/5T33Z0/OC-Little-Translated/pull/53/commits/e36bc2ac3c72a64e2b296b40ed2ba0e4ee06e8d7


fix ordering of consumer/publisher delivery tags

This fixes a tricky bug which can occur especially if there are two
open channels on the same connection, though it might be possible to
reproduce even on a single channel (needs a simpler test if we can
figure out how).
The main issue is that the delivery tags used for publisher confirmation
and delivery confirmation are not the same, and should use different
sequences.
For example when a client publishes a message with delivery confirmation
expected, it waits for a (n)ack with the matching delivery tag.  That
means the mock server needs to send a (n)ack with the correct delivery
tag.
However, if the client is acting as a consumer, and server is expecting
delivery confirmation, then the server must exect a (n)ack from the
client with a matching delivery_tag.
In other words, the server needs to keep track of two separate
sequences of delivery tags: one where the server is acting as a
publisher, and one where it's handling a consumer.  The delivery tags
are also channel-specific, so this adds keying by channel for the
delivery tags.
(NOTE: I wrote this fix many months ago but never wrote up a proper
description of it until now, so I'm not 100% sure my description of the
problem is accurate.)
Depends on https://github.com/nikitanovosibirsk/amqp-mock/pull/8 and https://github.com/nikitanovosibirsk/amqp-mock/pull/9

Rebased (still includes #9)

I'm not sure how AMQP protocol defines this, but what is the reason to count publisher confirms? As I see things, counting should happen only on the sending side, eg.:

Broker counts messages sent to consumers (and consumers just respond with the delivery_id that they receive in the delivery headers)
Clients count messages sent to broker (and broker just returns confirmations based on what theu receive in the publish headers.


fix: add /help to block paths

TBD if hardcoding is the best solution.
Test URLs:

Before: https://main--macquarie-help-centre--hlxsites.hlx.page/help/personal
After: https://move-to-help--macquarie-help-centre--hlxsites.hlx.page/help/personal

I will be handling this in separate PR

this is done


Update Dummy Content of "Why SILK"

Update the dummy content of the "Why SILK" section displayed in the picture. Ensure that the content follows the specified character counts and aligns with the values and objectives of SILK Corp.

WHO WE ARE
OUR VIEW OF THE WORLD
We are a team that focuses on ensuring smooth operations and management while upholding the standards in the health and wellness industry. We are committed to advocating for comprehensive well-being practices that encompass mental, physical, and emotional health.
NOTE: Take an idea from the upper paragraph and convert this into an beautiful powerful line's telling your readers about your strong points.
If you are a new contributor study the link before starting to work on it:
https://github.com/NoteHive/Silk-Corp-Guide#readme
To contribute to the GitHub repository, please follow the steps below:

Fork the repository
Go to the gh-pages branch
Look for an index.html file
Find the area where the content needs to update by pressing ctrl+F
Go to the exact highlighted issue and make sure you don't change any list accidentally.
Do not change any code, just work inside glyphs
FOR EXAMPLE: OUT OF BOUND>  YOU WORK HERE  <OUT OF BOUND
Update the content and commit changes

You can also visit SILK Corp's website and franchise guide for more information.

Website: https://silkcorp.org/
Franchise Guide: https://guide.silkcorp.org/

@NF11234, updated please review it.


pre-commit: PR119131

Link: https://github.com/llvm/llvm-project/pull/119131
Requested by: @nikic

/add-label reviewed
/close


[Bug]: Profil and Contact backup

Describe the bug
On 3 testers: 2 worked (Iphone/GrapheneOS), 1 didn't (Android)
Can I wipe the wallet and restore to retrieve my contacts?
I Cannot see picture and name on home screen, even after restarting; clicking on profile, I go through the setup, but no previous profile exists; no contacts either
You can find the seed on the Bitkit testing framework
Reproduce

Reset wallet
Restart the application
Backup wallet
See error

Screenshots / Recording
No response
Operating system
Android
Bitkit version
v39
Log output
No response

Fiex

It worked for two testers but there were bugs with Jan's phone. Can you check with his seed what the problem is? At first he downloaded a old v32 version, maybe that's where the issue came from.

Hi @Nuhvi, some update.
Describe the bug
Can I wipe the wallet and restore to retrieve my contacts? yes
Is the data updated for your contacts: Yes excepted the profil name. Picture profil, bio and links changed
Operating system
Android
Bitkit version
v44
What i see

What my contact see

Not a bug, a feature


Standard library headers not found by bindgen when cross-compiling for Windows

Checklist

[X] I've looked through the issues and pull requests for similar reports

Describe your issue
When cross-compiling for Windows, bindgen fails to find standard C++ library headers.
What target(s) are you cross-compiling for?
x86_64-pc-windows-gnu
Which operating system is the host (e.g computer cross is on) running?

[ ] macOS
[ ] Windows
[X] Linux / BSD
[ ] other OS (specify in description)

What architecture is the host?

[X] x86_64 / AMD64
[ ] arm32
[ ] arm64 (including Mac M1)

What container engine is cross using?

[X] docker
[ ] podman
[ ] other container engine (specify in description)

cross version
cross 0.2.4, on cargo 1.67.0-nightly (a3dfea71c 2022-11-11)
Example
git clone --recursive https://github.com/Penple/msdf-rs
cd msdf-rs

cat << EOF > Dockerfile
FROM ghcr.io/cross-rs/x86_64-pc-windows-gnu:main
RUN apt-get update && apt-get install --assume-yes --no-install-recommends libclang-dev clang
EOF
docker build -t test .

cat << EOF > Cross.toml
[target.x86_64-pc-windows-gnu]
image = "test"
EOF

cross build --target x86_64-pc-windows-gnu

This produces the following error:
error: failed to run custom build command for `msdf-sys v0.1.0 (/project/msdf-sys)`

Caused by:
  process didn't exit successfully: `/target/debug/build/msdf-sys-223228ec41ec6e67/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=wrapper.h
  cargo:rustc-link-lib=static=msdfgen-core
  CMAKE_TOOLCHAIN_FILE_x86_64-pc-windows-gnu = None
  CMAKE_TOOLCHAIN_FILE_x86_64_pc_windows_gnu = None
  TARGET_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_x86_64-pc-windows-gnu = None
  CMAKE_GENERATOR_x86_64_pc_windows_gnu = None
  TARGET_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_x86_64-pc-windows-gnu = None
  CMAKE_PREFIX_PATH_x86_64_pc_windows_gnu = None
  TARGET_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_x86_64-pc-windows-gnu = None
  CMAKE_x86_64_pc_windows_gnu = None
  TARGET_CMAKE = None
  CMAKE = None
  running: "cmake" "/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e7a130b7a8548441/out/msdfgen" "-DCMAKE_SYSTEM_NAME=Windows" "-DMSDFGEN_BUILD_STANDALONE=OFF" "-DMSDFGEN_CORE_ONLY=ON" "-DCMAKE_INSTALL_PREFIX=/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e7a130b7a8548441/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKE_C_COMPILER=/usr/bin/x86_64-w64-mingw32-gcc-posix" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/x86_64-w64-mingw32-g++-posix" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/x86_64-w64-mingw32-gcc-posix" "-DCMAKE_BUILD_TYPE=Release"
  -- The CXX compiler identification is GNU 9.3.0
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++-posix - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Could NOT find Freetype (missing: FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS)
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e7a130b7a8548441/out/build
  running: "cmake" "--build" "." "--target" "msdfgen-core" "--config" "Release" "--parallel" "16"
  [ 13%] Building CXX object CMakeFiles/msdfgen-core.dir/core/MSDFErrorCorrection.cpp.obj
  [ 13%] Building CXX object CMakeFiles/msdfgen-core.dir/core/EdgeHolder.cpp.obj
  [ 18%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Contour.cpp.obj
  [ 18%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Projection.cpp.obj
  [ 27%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Scanline.cpp.obj
  [ 27%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Shape.cpp.obj
  [ 31%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Vector2.cpp.obj
  [ 40%] Building CXX object CMakeFiles/msdfgen-core.dir/core/edge-coloring.cpp.obj
  [ 40%] Building CXX object CMakeFiles/msdfgen-core.dir/core/SignedDistance.cpp.obj
  [ 50%] Building CXX object CMakeFiles/msdfgen-core.dir/core/contour-combiners.cpp.obj
  [ 50%] Building CXX object CMakeFiles/msdfgen-core.dir/core/edge-segments.cpp.obj
  [ 54%] Building CXX object CMakeFiles/msdfgen-core.dir/core/edge-selectors.cpp.obj
  [ 59%] Building CXX object CMakeFiles/msdfgen-core.dir/core/equation-solver.cpp.obj
  [ 68%] Building CXX object CMakeFiles/msdfgen-core.dir/core/msdf-error-correction.cpp.obj
  [ 68%] Building CXX object CMakeFiles/msdfgen-core.dir/core/msdfgen.cpp.obj
  [ 72%] Building CXX object CMakeFiles/msdfgen-core.dir/core/rasterization.cpp.obj
  [ 77%] Building CXX object CMakeFiles/msdfgen-core.dir/core/render-sdf.cpp.obj
  [ 81%] Building CXX object CMakeFiles/msdfgen-core.dir/core/save-bmp.cpp.obj
  [ 86%] Building CXX object CMakeFiles/msdfgen-core.dir/core/save-tiff.cpp.obj
  [ 90%] Building CXX object CMakeFiles/msdfgen-core.dir/core/sdf-error-estimation.cpp.obj
  [ 95%] Building CXX object CMakeFiles/msdfgen-core.dir/core/shape-description.cpp.obj
  [100%] Linking CXX static library libmsdfgen-core.a
  [100%] Built target msdfgen-core
  cargo:root=/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e7a130b7a8548441/out
  cargo:rustc-link-search=native=/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e7a130b7a8548441/out/build
  cargo:rustc-link-lib=dylib=stdc++

  --- stderr
  CMake Warning:
    Manually-specified variables were not used by the project:

      CMAKE_ASM_COMPILER
      CMAKE_ASM_FLAGS
      CMAKE_C_COMPILER
      CMAKE_C_FLAGS

  make: warning: -j16 forced in submake: resetting jobserver mode.
  msdfgen/core/arithmetics.hpp:4:10: fatal error: 'cstdlib' file not found
  thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("msdfgen/core/arithmetics.hpp:4:10: fatal error: 'cstdlib' file not found\n")', msdf-sys/build.rs:67:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Additional information / notes
A workaround is to pass -I/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/c++ -I/usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/x86_64-w64-mingw32 as arguments to the underlying Clang process:
diff --git a/caxton-impl/msdf-rs/msdf-sys/build.rs b/caxton-impl/msdf-rs/msdf-sys/build.rs
index 0fb7624..0b88fa0 100644
--- a/msdf-sys/build.rs
+++ b/msdf-sys/build.rs
@@ -56,6 +56,8 @@ fn main() {

     let bindings = bindgen::Builder::default()
         .clang_arg("-Imsdfgen")
+        .clang_arg("-I/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/c++")
+        .clang_arg("-I/usr/lib/gcc/x86_64-w64-mingw32/9.3-posix/include/c++/x86_64-w64-mingw32")
         .clang_arg("-x")
         .clang_arg("c++")
         .opaque_type("std::.*")

Building this crate for x86_64-unknown-linux-gnu succeeds.

just a tip for you.
[target.x86_64-pc-windows-gnu]
dockerfile = "Dockerfile"

would automatically build the dockerfile for you. But also it could be replaced with
[target.x86_64-pc-windows-gnu]
image = "ghcr.io/cross-rs/x86_64-pc-windows-gnu:main"
pre-build = ["apt-get update && apt-get install --assume-yes --no-install-recommends libclang-dev clang"]

This is partially a duplicate of #1112, and also linked to #1110. However, there's still issues afterwards. The relevant part of the log is below, and as we can see, the toolchain and CMake configuration is done, however, the build script is now unable to find cstdlib, which suggests the include directory path for C++ is off.
error: failed to run custom build command for `msdf-sys v0.1.0 (/home/ahuszagh/git/msdf-rs/msdf-sys)`

Caused by:
  process didn't exit successfully: `/target/debug/build/msdf-sys-813f8f5b6bc6e1e5/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=wrapper.h
  cargo:rustc-link-lib=static=msdfgen-core
  CMAKE_TOOLCHAIN_FILE_x86_64-pc-windows-gnu = None
  CMAKE_TOOLCHAIN_FILE_x86_64_pc_windows_gnu = Some("/opt/toolchain.cmake")
  CMAKE_GENERATOR_x86_64-pc-windows-gnu = None
  CMAKE_GENERATOR_x86_64_pc_windows_gnu = None
  TARGET_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_x86_64-pc-windows-gnu = None
  CMAKE_PREFIX_PATH_x86_64_pc_windows_gnu = None
  TARGET_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_x86_64-pc-windows-gnu = None
  CMAKE_x86_64_pc_windows_gnu = None
  TARGET_CMAKE = None
  CMAKE = None
  running: "cmake" "/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e08a5d644d75ca9a/out/msdfgen" "-DCMAKE_SYSTEM_NAME=Windows" "-DMSDFGEN_BUILD_STANDALONE=OFF" "-DMSDFGEN_CORE_ONLY=ON" "-DCMAK
E_TOOLCHAIN_FILE=/opt/toolchain.cmake" "-DCMAKE_INSTALL_PREFIX=/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e08a5d644d75ca9a/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -m64"
"-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -m64" "-DCMAKE_BUILD_TYPE=Release"
  -- Could NOT find Freetype (missing: FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS)
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e08a5d644d75ca9a/out/build
  running: "cmake" "--build" "." "--target" "msdfgen-core" "--config" "Release" "--parallel" "4"
  Consolidate compiler generated dependencies of target msdfgen-core
  [  4%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Contour.cpp.obj
  [  9%] Building CXX object CMakeFiles/msdfgen-core.dir/core/MSDFErrorCorrection.cpp.obj
  [ 13%] Building CXX object CMakeFiles/msdfgen-core.dir/core/EdgeHolder.cpp.obj
  [ 18%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Projection.cpp.obj
  [ 22%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Scanline.cpp.obj
  [ 27%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Shape.cpp.obj
  [ 31%] Building CXX object CMakeFiles/msdfgen-core.dir/core/SignedDistance.cpp.obj
  [ 36%] Building CXX object CMakeFiles/msdfgen-core.dir/core/Vector2.cpp.obj
  [ 40%] Building CXX object CMakeFiles/msdfgen-core.dir/core/contour-combiners.cpp.obj
  [ 45%] Building CXX object CMakeFiles/msdfgen-core.dir/core/edge-coloring.cpp.obj
  [ 50%] Building CXX object CMakeFiles/msdfgen-core.dir/core/edge-segments.cpp.obj
  [ 54%] Building CXX object CMakeFiles/msdfgen-core.dir/core/edge-selectors.cpp.obj
  [ 59%] Building CXX object CMakeFiles/msdfgen-core.dir/core/equation-solver.cpp.obj
  [ 63%] Building CXX object CMakeFiles/msdfgen-core.dir/core/msdf-error-correction.cpp.obj
  [ 68%] Building CXX object CMakeFiles/msdfgen-core.dir/core/msdfgen.cpp.obj
  [ 72%] Building CXX object CMakeFiles/msdfgen-core.dir/core/rasterization.cpp.obj
  [ 77%] Building CXX object CMakeFiles/msdfgen-core.dir/core/save-bmp.cpp.obj
  [ 81%] Building CXX object CMakeFiles/msdfgen-core.dir/core/render-sdf.cpp.obj
  [ 86%] Building CXX object CMakeFiles/msdfgen-core.dir/core/save-tiff.cpp.obj
  [ 90%] Building CXX object CMakeFiles/msdfgen-core.dir/core/sdf-error-estimation.cpp.obj
  [ 95%] Building CXX object CMakeFiles/msdfgen-core.dir/core/shape-description.cpp.obj
  [100%] Linking CXX static library libmsdfgen-core.a
  [100%] Built target msdfgen-core
  cargo:root=/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e08a5d644d75ca9a/out
  cargo:rustc-link-search=native=/target/x86_64-pc-windows-gnu/debug/build/msdf-sys-e08a5d644d75ca9a/out/build
  cargo:rustc-link-lib=dylib=stdc++

  --- stderr
  CMake Warning:
    Manually-specified variables were not used by the project:

      CMAKE_TOOLCHAIN_FILE

  make: warning: -j4 forced in submake: resetting jobserver mode.
  msdfgen/core/arithmetics.hpp:4:10: fatal error: 'cstdlib' file not found
  thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("msdfgen/core/arithmetics.hpp:4:10: fatal error: 'cstdlib' file not found\n")', msdf-sys/build.rs:67:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
+ rustup component list --toolchain stable-x86_64-unknown-linux-gnu

Ok I've reproduced this to be an issue with any library using C++ dependencies. Here's a minimal example, which has the same code, one using C++ headers, one without. I'll see if I can fix the bindgen search path for this.
$ cross build --target aarch64-unknown-linux-gnu
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
$ cross build --target aarch64-unknown-linux-gnu --features=cpp
error: failed to run custom build command for `issue_1147 v0.1.0 (/home/ahuszagh/git/issue_1147)`

Caused by:
  process didn't exit successfully: `/target/debug/build/issue_1147-28ef13adf2821889/build-script-build` (exit status: 101)
  --- stderr
  /usr/bin/../lib/gcc-cross/aarch64-linux-gnu/9/../../../../include/c++/9/cstdlib:41:10: fatal error: 'bits/c++config.h' file not found
  thread 'main' panicked at 'Unable to generate bindings: ClangDiagnostic("/usr/bin/../lib/gcc-cross/aarch64-linux-gnu/9/../../../../include/c++/9/cstdlib:41:10: fatal error: 'bits/c++config.h' file not found\n")', build.rs:13:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I was looking at possible solutions and it seems this is the actual solution: manually add the search path to the bindgen args.
https://github.com/rust-lang/rust-bindgen/issues/1229#issuecomment-378494555

Success
It works with the following Dockerfile:
FROM ghcr.io/cross-rs/aarch64-unknown-linux-gnu:main

RUN apt-get update && \
    apt-get install --assume-yes --no-install-recommends \
    libclang-dev \
    clang
ENV BINDGEN_EXTRA_CLANG_ARGS_aarch64_unknown_linux_gnu="$BINDGEN_EXTRA_CLANG_ARGS_aarch64_unknown_linux_gnu -I/usr/aarch64-linux-gnu/include/c++/9/"

Fail Testing
After having tested with fail inclusion for assert.h, I can see that it correctly uses the C headers for aarch64, but does not for C++.


Anonymous user pages

They used to exist, and now they don't, or at least the links are gone. reported by @NWPlayer123 and I've seen others request this back as well

people seem to have thinked so...but maybe not?

AFAIK there's no API for accessing the scratches or profiles of anonymous users, so gonna tag this with backend too.
On another note I'm personally not in favour of this feature, surely if someone wants to have their scratches listed they would log in? What are the use-cases of this?

To find scratches if you haven't logged in, the convo we had was that someone had worked on a bunch of Animal Crossing functions while not logged in and it was annoying to track down, would've been much easier if anonymous user pages worked
and yeah, it would be nice if everyone logged in but it logs me out constantly, and some people don't want to go through the hassle of checking if they're logged in every time

the fact that we get logged out often is something we should fix too. I've noticed that but unfortunately don't know how to consistently reproduce it or anything

Do we still need this functionality, or is it enough to track down scratches based on the preset / platform pages?

yeah, we probably don't need this given what you said. if no one squeaks up, I'll close it soon

Agree, it’s somewhat against the point of anons to have pages that link their scratches together


SST deploy: no need for create-sst@rc anymore

What kind of changes does this PR include?

Minor content fixes (broken links, typos, etc.)
New or updated content

Description
<EMAIL_ADDRESS>and<EMAIL_ADDRESS>were released last week, so there's no need to use create-sst@rc anymore.

Nice catch @brettneese, thanks!


Issues linking origin as a WD.

Building a document as a working draft gives the following error when resolving origin:

LINK ERROR: Multiple possible 'dfn' refs for 'origin'.
Arbitrarily chose the one in css-cascade-3.
If this is wrong, insert one of the following lines into a
 block:
spec:html; type:dfn; text:origin
spec:css-cascade-3; type:dfn; text:origin
origin
✔  Successfully generated, with 1 linking errors

I basically never want css-cascade. :) Adding spec:html; type:dfn; text:origin is a problem, as origin also is used in a number of other places as a property (request/origin, from Fetch for instance). Adding spec:html; type:dfn; text:origin; for: / doesn't seem to solve that, as it changes the link for request/origin from Fetch to HTML.
This is arguably HTML's fault, as it redefines the term, but since it's not marked as exported, that usually isn't a problem. The combination of redefinition and link defaults, however, seems to break things. :(
Halp?
/cc @tabatkins @annevk

Use origin.

@annevk: I do. However, for="/" is ambigious because CSS Cascade 3 defines https://www.w3.org/TR/css-cascade-3/#origin.

Oh, I have not gotten conflicts with that thus far. Seems that use of origin should use for="style rule" maybe.

Oh, I have not gotten conflicts with that thus far.

You'll only see the error if you build in "working draft" mode as part of a W3C WG. I think you're unlikely to be inconvenienced. ;)

Seems that use of origin should use for="style rule" maybe.

Indeed. It's been renamed in the latest editor's draft to "cascade origin" (https://drafts.csswg.org/css-cascade/#origin), which seems fine. Ideally, @tabatkins and @fantasai would backport that change to the candidate recommendation at https://www.w3.org/TR/css-cascade-3/. :)
However we resolve this specific instance, however, the general behavior here seems strange. Adding a link default for for=/ should not change the resolving behavior of for=request.

Ideally, @tabatkins and @fantasai would backport that change to the candidate recommendation

Will do next time we pub.  I've got reminders set up to pub everything every 6 months at minimum, so it should get triggered soon.

Adding a link default for for=/ should not change the resolving behavior of for=request.

You're right, that's a bug. One that's been here for quite a while, it seems! Fixed now.
You can now use spec:html; type:dfn; text:origin; for: / to get what you want.


Multiple powermeters support

Apart from root consumption power meter (PM#0, ROOT), I run a second PM to explicitly measure heat pump consumption (PM#1, ADDITIONAL_CONSUMPTION).
Topic "pm" reports full PM#0 values, but PM#1 values are not exposed. Changing RscpMqttMain.cpp from
protocol.appendValue(&PMContainer, TAG_PM_INDEX, (uint8_t)0); to
protocol.appendValue(&PMContainer, TAG_PM_INDEX, (uint8_t)1);
shows PM#1 in pm/* topics.
Maybe a list of indexes in config file would allow cycling through all available powermeters, or those that are wanted to be queried?
Assuming pm_0 and pm_1 relate to the  two powermeters in my system, "pm_0/energy" and "pm_1/energy" topics are available, but no more. Both those energy values are 0.00 at all times.

Hello cwhine,
yes, good idea. I will implement this in the next release.
Best regards
Thomas

Fixed by release v3.14.
Please add the following lines to your .config file:
PM_INDEX=0
PM_INDEX=1
rs2cpmqtt will created topics like:
e3dc/pm/1/* for power meter 0
e3dc/pm/2/* for power meter 1
But maybe no changes regarding  "pm_0/energy" and "pm_1/energy" topics... I have no influence on that...
Best regards
Thomas

The applied extension works well with powermeters #0 and #1, and surely for more in the case of need. Thank you very much.


NextJs SSR Amplify, cold start takes up to 7 seconds

Before opening, please confirm:

[X] I have searched for duplicate or closed issues and discussions.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework
Next.js
Amplify APIs
Authentication, GraphQL API, Storage
Amplify Categories
auth, storage, function, api, hosting
Environment information

# Put output below this line

System:
    OS: macOS 11.5.1
    CPU: (8) arm64 Apple M1
    Memory: 128.09 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.8.0 - /opt/homebrew/bin/node
    Yarn: 1.22.17 - /opt/homebrew/bin/yarn
    npm: 7.21.0 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 109.0.5414.119
    Safari: 14.1.2
  npmPackages:
    @ampproject/toolbox-optimizer:  undefined ()
    @aws-amplify/ui-react: ^4.3.2 => 4.3.2
    @aws-amplify/ui-react-internal:  undefined ()
    @aws-sdk/client-s3: ^3.224.0 => 3.226.0 (3.6.1)
    @babel/core:  undefined ()
    @babel/runtime:  7.15.4
    @edge-runtime/primitives:  2.0.0
    @hapi/accept:  undefined ()
    @napi-rs/triples:  undefined ()
    @next/react-dev-overlay:  undefined ()
    @react-icons/all-files: ^4.1.0 => 4.1.0
    @segment/ajv-human-errors:  undefined ()
    @vercel/nft:  undefined ()
    acorn:  undefined ()
    amphtml-validator:  undefined ()
    anser:  undefined ()
    arg:  undefined ()
    assert:  undefined ()
    async-retry:  undefined ()
    async-sema:  undefined ()
    autoprefixer: ^10.4.13 => 10.4.13
    aws-amplify: ^5.0.8 => 5.0.8
    babel-packages:  undefined ()
    blueimp-load-image: ^5.16.0 => 5.16.0
    browserify-zlib:  undefined ()
    browserslist:  undefined ()
    buffer:  undefined ()
    bytes:  undefined ()
    chalk:  undefined ()
    ci-info:  undefined ()
    cli-select:  undefined ()
    comment-json:  undefined ()
    compress.js: ^1.2.2 => 1.2.2
    compression:  undefined ()
    conf:  undefined ()
    constants-browserify:  undefined ()
    content-disposition:  undefined ()
    content-type:  undefined ()
    cookie:  undefined ()
    cross-spawn:  undefined ()
    crypto-browserify:  undefined ()
    css.escape:  undefined ()
    cssnano-simple:  undefined ()
    data-uri-to-buffer:  undefined ()
    debug:  undefined ()
    devalue:  undefined ()
    domain-browser:  undefined ()
    edge-runtime:  undefined ()
    events:  undefined ()
    find-cache-dir:  undefined ()
    find-up:  undefined ()
    fresh:  undefined ()
    get-orientation:  undefined ()
    glob:  undefined ()
    gzip-size:  undefined ()
    http-proxy:  undefined ()
    https-browserify:  undefined ()
    icss-utils:  undefined ()
    ignore-loader:  undefined ()
    image-size:  undefined ()
    is-animated:  undefined ()
    is-docker:  undefined ()
    is-wsl:  undefined ()
    jest-worker:  undefined ()
    json5:  undefined ()
    jsonwebtoken:  undefined ()
    leaflet: ^1.9.3 => 1.9.3
    leaflet-defaulticon-compatibility: ^0.1.1 => 0.1.1
    loader-utils:  undefined ()
    lodash.curry:  undefined ()
    lru-cache:  undefined ()
    micromatch:  undefined ()
    mini-css-extract-plugin:  undefined ()
    nanoid:  undefined ()
    native-url:  undefined ()
    neo-async:  undefined ()
    next: 13.0.4 => 13.0.4
    node-fetch:  undefined ()
    node-html-parser:  undefined ()
    ora:  undefined ()
    os-browserify:  undefined ()
    p-limit:  undefined ()
    path-browserify:  undefined ()
    piexifjs: ^1.0.6 => 1.0.6
    platform:  undefined ()
    postcss: ^8.4.19 => 8.4.19 (8.4.14)
    postcss-flexbugs-fixes:  undefined ()
    postcss-modules-extract-imports:  undefined ()
    postcss-modules-local-by-default:  undefined ()
    postcss-modules-scope:  undefined ()
    postcss-modules-values:  undefined ()
    postcss-preset-env:  undefined ()
    postcss-safe-parser:  undefined ()
    postcss-scss:  undefined ()
    postcss-value-parser:  undefined ()
    process:  undefined ()
    punycode:  undefined ()
    querystring-es3:  undefined ()
    raw-body:  undefined ()
    react: 18.2.0 => 18.2.0 (18.3.0-next-4bd245e9e-20221104)
    react-beautiful-dnd: ^13.1.1 => 13.1.1
    react-dom: 18.2.0 => 18.2.0 (18.3.0-next-4bd245e9e-20221104)
    react-icons: ^4.7.1 => 4.7.1
    react-is:  18.2.0
    react-leaflet: ^4.2.0 => 4.2.0
    react-refresh:  0.12.0
    react-server-dom-webpack:  undefined ()
    react-slideshow-image: ^4.1.0 => 4.1.1
    react-tooltip: ^4.5.1 => 4.5.1
    regenerator-runtime:  0.13.4
    sass-loader:  undefined ()
    scheduler:  undefined ()
    schema-utils:  undefined ()
    semver:  undefined ()
    send:  undefined ()
    setimmediate:  undefined ()
    shell-quote:  undefined ()
    source-map:  undefined ()
    stacktrace-parser:  undefined ()
    stream-browserify:  undefined ()
    stream-http:  undefined ()
    string-hash:  undefined ()
    string_decoder:  undefined ()
    strip-ansi:  undefined ()
    tailwind-merge: ^1.8.0 => 1.8.0
    tailwindcss: ^3.2.4 => 3.2.4
    tar:  undefined ()
    terser:  undefined ()
    text-table:  undefined ()
    timers-browserify:  undefined ()
    tty-browserify:  undefined ()
    ua-parser-js:  undefined ()
    undici:  undefined ()
    unistore:  undefined ()
    util:  undefined ()
    vm-browserify:  undefined ()
    watchpack:  undefined ()
    web-vitals:  undefined ()
    webpack:  undefined ()
    webpack-sources:  undefined ()
    ws:  undefined ()
  npmGlobalPackages:
    @aws-amplify/cli: 10.5.2
    @ionic/cli: 6.17.1
    npm: 7.21.0
    prebuild-install: 7.1.1
    yarn: 1.22.17

Describe the bug
Hi,
I have created an AWS Amplify Web app with NextJs SSR.
Everything works fine except one huge issue : cold start takes up to 7 seconds to have server response.
I realized that if I remove all my amplify backend, the cold start drops down to less than a second. So I guess the problem comes from the AWS Amplify libraries.
I deployed a version of my website that doesn't call any getServerSideProps, but the latency stays around 7 seconds.

This is my amplify backend configuration :
{
  "auth": {
    "userPoolGroups": {
      "service": "Cognito-UserPool-Groups",
      "providerPlugin": "awscloudformation",
      "dependsOn": [
        {
          "category": "auth",
          "resourceName": "ressourceNamef1xxxxxxxxx",
          "attributes": [
            "UserPoolId",
            "AppClientIDWeb",
            "AppClientID",
            "IdentityPoolId"
          ]
        }
      ]
    },
    "ressourceNamef1xxxxxxxxx": {
      "service": "Cognito",
      "providerPlugin": "awscloudformation",
      "dependsOn": [],
      "customAuth": false,
      "frontendAuthConfig": {
        "socialProviders": [],
        "usernameAttributes": [
          "EMAIL"
        ],
        "signupAttributes": [
          "EMAIL"
        ],
        "passwordProtectionSettings": {
          "passwordPolicyMinLength": 8,
          "passwordPolicyCharacters": []
        },
        "mfaConfiguration": "OFF",
        "mfaTypes": [
          "SMS"
        ],
        "verificationMechanisms": [
          "EMAIL"
        ]
      }
    }
  },
  "api": {
    "ressourceName": {
      "service": "AppSync",
      "providerPlugin": "awscloudformation",
      "dependsOn": [
        {
          "category": "auth",
          "resourceName": "ressourceNamef1xxxxxxxxx",
          "attributes": [
            "UserPoolId"
          ]
        }
      ],
      "output": {
        "authConfig": {
          "defaultAuthentication": {
            "authenticationType": "AMAZON_COGNITO_USER_POOLS",
            "userPoolConfig": {
              "userPoolId": "authressourceNamef1xxxxxxxxx"
            }
          },
          "additionalAuthenticationProviders": [
            {
              "authenticationType": "API_KEY",
              "apiKeyConfig": {
                "apiKeyExpirationDays": 365,
                "apiKeyExpirationDate": "2023-12-10T15:07:46.361Z",
                "description": ""
              }
            },
            {
              "authenticationType": "AWS_IAM"
            }
          ]
        }
      }
    }
  },
  "storage": {
    "s338e9026f": {
      "service": "S3",
      "providerPlugin": "awscloudformation",
      "dependsOn": [
        {
          "category": "auth",
          "resourceName": "ressourceNamef1xxxxxxxxx",
          "attributes": [
            "UserPoolId"
          ]
        },
        {
          "category": "auth",
          "resourceName": "userPoolGroups",
          "attributes": [
            "adminGroupRole"
          ]
        },
        {
          "category": "auth",
          "resourceName": "userPoolGroups",
          "attributes": [
            "superAdminGroupRole"
          ]
        }
      ]
    }
  },
  "function": {
    "ressourceNameSendEmails": {
      "build": true,
      "providerPlugin": "awscloudformation",
      "service": "Lambda",
      "dependsOn": [
        {
          "category": "api",
          "resourceName": "ressourceName",
          "attributes": [
            "GraphQLAPIIdOutput",
            "GraphQLAPIEndpointOutput",
            "GraphQLAPIKeyOutput"
          ]
        }
      ]
    },
    "getgooglereviews": {
      "build": true,
      "providerPlugin": "awscloudformation",
      "service": "Lambda",
      "dependsOn": [
        {
          "category": "auth",
          "resourceName": "ressourceNamef1xxxxxxxxx",
          "attributes": [
            "UserPoolId"
          ]
        },
        {
          "category": "api",
          "resourceName": "ressourceName",
          "attributes": [
            "GraphQLAPIIdOutput",
            "GraphQLAPIEndpointOutput",
            "GraphQLAPIKeyOutput"
          ]
        }
      ]
    }
  }
}

Here is the way my NexJs App is initialized with amplify :
import '../styles/globals.css'
import { ContextProvider } from '../src/components/context/Context';
import Layout from '../src/components/Layout';
import<EMAIL_ADDRESS>import { Amplify } from 'aws-amplify';
import awsExports from '../src/aws-exports';

function MyApp({ Component, pageProps }) {
  Amplify.configure(awsExports);
//Amplify.configure({ ...awsExports, ssr: true }); //==> This doesn't change latency. issue
  return (
    <ContextProvider>
      <Layout>
        <Component {...pageProps} />
      </Layout>
    </ContextProvider>
  )
}

export default MyApp

I read on several forums that Amplify is not able to provide law latency cold start, so I better move to Vercel or Netlify (which I tried and works super well) for example.
Can you please confirm the opposite?
Sources :
https://www.reddit.com/r/nextjs/comments/uamqbl/beware_of_nextjs_on_aws_amplify/
I also found some other solutions like keeping the lambda warm with a cron job. Is that a good idea?
https://www.reddit.com/r/nextjs/comments/ml4i2t/ssr_pages_cold_start_improve_performance/
Thank you.
Expected behavior
I would like to have cold start no longer than 1 second, as it is on most of other cloud providers.
Reproduction steps
amplify init
amplify add auth
amplify add api
amplify add storage
amplify add function
amplify add hosting
amplify push
Code Snippet
// Put your code below this line.

Log output

// Put your logs below this line

aws-exports.js
/* eslint-disable */
// WARNING: DO NOT EDIT. This file is automatically generated by AWS Amplify. It will be overwritten.
const awsmobile = {
"aws_project_region": "eu-west-2",
"aws_cognito_identity_pool_id": "eu-west-2:xxxxxxxxxxxxxxx",
"aws_cognito_region": "eu-west-2",
"aws_user_pools_id": "eu-west-2_xxxxxxxxxxxxxxx",
"aws_user_pools_web_client_id": "xxxxxxxxxxxxxxx",
"oauth": {},
"aws_cognito_username_attributes": [
"EMAIL"
],
"aws_cognito_social_providers": [],
"aws_cognito_signup_attributes": [
"EMAIL"
],
"aws_cognito_mfa_configuration": "OFF",
"aws_cognito_mfa_types": [
"SMS"
],
"aws_cognito_password_protection_settings": {
"passwordPolicyMinLength": 8,
"passwordPolicyCharacters": []
},
"aws_cognito_verification_mechanisms": [
"EMAIL"
],
"aws_appsync_graphqlEndpoint": "https://xxxxxxxxxxxxxxx.amazonaws.com/graphql",
"aws_appsync_region": "eu-west-2",
"aws_appsync_authenticationType": "AMAZON_COGNITO_USER_POOLS",
"aws_appsync_apiKey": "xxxxxxxxxxxxxxx",
"aws_user_files_s3_bucket": "xxxxxxxxxxxxxxx",
"aws_user_files_s3_bucket_region": "eu-west-2"
};
export default awsmobile;
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response

Hey folks - Matt from the Amplify Hosting team. I see the comments that this issue has reappeared for some of you. Going to investigate with the team.

Hey everyone -- we've examined app performance across the board and don't see holistic issues that would contribute to slow starts/time to first byte. There are many factors at play and it is more effective to examine each app on a case by case basis to identify potential issues. If you are still experiencing this issue, please open a AWS Support case or ask in our Community Discord server


Ref: Re-enable checking broken links in sponsors section

Fixes #2362
- Earlier the test was on FossasiaSummit2017 in which one sponsor link was broken so the test failed
- Now we are checking for MozillaAllHands2017 so the test is moved after eventPage visits the MozillaAllHands2017 site

@iamareebjamal can you please review?


azure-quantum authentication get_token failed messages

When authenticating with azure-quantum and using the default DefaultAzureCredential, it will try several authentication mechanisms as described here.
Even if one of the authentication methods happen to succeed, you will see the messages for the authentication methods that didn't succeed before the final (successful) authentication method was attempted.
So you may see a message like this, even if the authentication succeeded.
EnvironmentCredential.get_token failed: EnvironmentCredential authentication unavailable. Environment variables are not fully configured.
ManagedIdentityCredential.get_token failed: ManagedIdentityCredential authentication unavailable, no managed identity endpoint found.
SharedTokenCacheCredential.get_token failed: SharedTokenCacheCredential authentication unavailable. No accounts were found in the cache.
VisualStudioCodeCredential.get_token failed: Failed to get Azure user details from Visual Studio Code.
AzureCliCredential.get_token failed: Please run 'az login' to set up an account

This is the current behavior of the Azure.Identity.DefaultAzureCredential and a corresponding issue was filled to the Azure SDK team.
Meanwhile, please ignore the get_token failed messages if the authentication succeeded (i.e. you were able to submit jobs to Azure Quantum, etc.).
If all authentication methods have failed, then you may pay close attention to all attempts that have failed and see what was missing to the method that you were interested in.

Fixed by #69


Improperly sinking a barrier

Originally from https://github.com/KhronosGroup/SPIRV-Cross/issues/1511.
#define THREADS 256
#define THREADS_HALF (THREADS/2)

__kernel void main_kernel(__global float* data, __global float* output, int count)
{
	__local float list[THREADS];

	const int point1Index = get_global_id(1);
	const int index = get_local_id(0);

	list[index] = data[index];

	for (int halfSize = THREADS_HALF; halfSize > 0; halfSize >>= 1)
	{
		if (index < halfSize)
		{
			const float value1 = list[index];
			const float value2 = list[index + halfSize];
			if (value2 < value1) list[index] = value2;
		}
		barrier(CLK_LOCAL_MEM_FENCE);
	}

	if (!index)
	{
		output[point1Index] = list[0];
	}
}

LLVM loop optimizations transform the loop iteration and sink the barrier into the continue target of the loop. The loop's branch condition ends up based on the local thread id so the workgroup is diverged without a merge instruction.

It is worth noting that if the barrier is moved before the if statement, clspv ends up with the barrier in the loop header.


How to get the enhanced image

The dataroot_gt and dataroot_lq paths in the configuration file are high-quality and low-quality pictures respectively. By enhancing the images in the dataroot_lq folder, we can compare them with the images in the dataroot_gt folder. Through test_from_dataset.py, we can get data such as psnr, and in the result, we can get the different images of the contrast image, but what I want to ask is how can I get the enhanced image. It is an image compared with the dataroot_gt folder. Where is it kept?
Thank you for your answer!

Hi, thanks for your interest,
The enhanced results are saved at
https://github.com/caiyuanhao1998/Retinexformer/blob/master/Enhancement/test_from_dataset.py#L199
in the folder ./results/. Please check that.
If you find our repo useful, please help us star it, thank you :)


added SQLITE_ENABLE_DBSTAT_VTAB compilation flag

Hey, I was just looking to use dbstat with Better Sqlite3. I think this PR never made it and should be resurrected.

Is this something either of you, @JoshuaWise or @mceachen, are willing to consider? Thanks!


Cannot find module './withLastLocation'

Following error occurs after updating to the current 2.0.0 version. Project uses the current create-react-app package:
node_modules/react-router-last-location/dist/index.d.ts:1:57 - error TS2307: Cannot find module './withLastLocation'.

1 import withLastLocation, { WithLastLocationProps } from './withLastLocation';

Hey @valentinpalkovic ,
Could you create an example repository?
I cannot reproduce it using the newest CRA and 2.0.0.

@hinok same problem
yarn run v1.16.0
$ tsc
node_modules/react-router-last-location/dist/index.d.ts:1:57 - error TS2307: Cannot find module './withLastLocation'.

1 import withLastLocation, { WithLastLocationProps } from './withLastLocation';
                                                          ~~~~~~~~~~~~~~~~~~~~

node_modules/react-router-last-location/dist/LastLocationProvider.d.ts:10:15 - error TS7005: Variable '_default' implicitly has an 'any' type.

10 declare const _default;

Could it be because of react-router >= 5 ?

"react-router": "^5.0.1",
"react-router-dom": "^5.0.1",
"react-router-last-location": "^2.0.0",

@valentinpalkovic @olso
I published 2.0.1, the problem should be solved.

#worksformenow

Glad to hear that, have a great end of the weekend!


GUI should indicate which EEPROM values are overridden by .INI

We had a case where a user was confused by the fact that the excitation wavelength stored in the EEPROM was not being used in ENLIGHTEN; it turned out they had a hard-coded value in their .INI file.  ENLIGHTEN should indicate (colorize, etc) settings which are being overridden.  I think that could mostly be done on the EEPROM Editor, with a few exceptions.  (Excitation is also displayed on the LaserControlWidget for instance.)

Note that this would probably need to be persisted in SpectrometerApplicationState, so the EEPROMEditor will correctly update when switching between selected spectrometers.


Custom install fonts and other files

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use case
Is it possible to do a local installation of all external files that are downloaded from the server, to your server, or directly to the asset?
This is necessary for two cases:

If you need to install the site (web version) on a secure network without access to the external Internet
Long time downloading a file from the server. If you put the file on the local network, the download will probably happen faster.

Example file
Here you can see that this file takes quite a long time to download, which leads to a long loading time for the site.

Proposal
Local install fonts

Deduplicating with https://github.com/flutter/flutter/issues/132689


How to have DomainPools reuse existing strands when possible and generate new ones if not.

Hello,
I am making some DNA brick structures. Each brick has 4 domains of 13nts (52nts total for a brick)
We have various 52nt strands which we have used for other designs sitting in our fridge.
I have created a nuad.constraints.Design for my intended structure.
I would like to know if there is a way to give a list of the 52nt sequences we already have and specify that these should be preferentially chosen as the strand sequences is the  nuad.constraints.Design  but that new sequences/strands should also be generated if no strand in our existing library fits the design.
I had a look at setting possible_sequences of nuad.constraints.Domain but as far as I am understanding that doesn't work since we have strands that have 4 domains as well as the fact that the strands in the fridge might not be sufficient to realize the design and may require some additional strands.

There's no "preferential" option. You can call the method Domain.set_fixed_sequence to say that a Domain should have a fixed sequence you give it, which will not be changed by the search. For example you if you have a single-stranded tile such as
        a             b
+=============-=============]
|
+=============-=============>
        c             d

where domains a and b need to have some sequence for whatever reason, you can set their sequences to be fixed, but still let the search look for good sequences for c and d, e.g., finding choices that minimize secondary structure of the whole strand (to whatever extent possible given the fact that a and b can't be changed).
But to encode that you "prefer" a certain sequence probably requires doing something like creating a new constraint that penalizes other sequences (but allows them).

Thanks,
I have used set_fixed_sequence to constrain some of my domains (for adding poly T's outer domains of the whole structure).
Unfortunately that  approach will not work for reusing the existing strands in our fridge. I'll have a look into writing a new constraint.


Penalise single-character non-alphanumeric atoms

I'd rather seen an unchanged variable to an unchanged ,. This is visible here on line 16 of the RHS here:

Discarding 'unchanged' punctuation surrounded by novel items is probably worthwhile too. See the example in https://twitter.com/funcshawnal/status/1567540165010411521

Lodash commit pictured is https://github.com/lodash/lodash/commit/b506174410fa943c053eb5bdae3099df371fdb79


⚠ Bofrost.de has degraded performance

In 7599705, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1860 ms

Resolved: Bofrost.de performance has improved in 2f2e63f after 13 minutes.


Cluster stuck in "provisioning" state when after all hosts get to "active" state.

**Rancher versions: Latest build from msater
Steps to Reproduce:
Create a custom cluster with following node configuration:
2 control 3 worker 3 etcd
Cluster stuck in "provisioning" state when after all hosts get to "active" state.

Attempting to remove this cluster results in cluster stuck in "Removing" state forever.

Tested with latest build from  master.
Created a custom cluster with following node configuration:
2 control 3 worker 3 etcd
When provisioning is in progress, I saw the same error reported for cluster . But it eventually recovered from this state and cluster gets to "active" state.


LSP, websocket and Content-Length

I've implemented a very simple LSP extension for my custom language and I need it to be able to talk to my LSP server (written using LSP4J). The issue I ran into is that the VSCode LSP client sends binary frames whereas the LSP server expects text frames.
I'm wondering if there's any way to instruct the client to send data in TEXT rather than BINARY.
Here's the relevant portion of my code:
function connectToServer(host: string, port: string, path: string): Duplex {
    const ws = new WebSocket(`ws://${host}:${port}/${path}`);
    return WebSocket.createWebSocketStream(ws);
}

function startClient(context: ExtensionContext) {
	console.log('Starting Test LSP Client...');

	const clientOptions: LanguageClientOptions = {
		documentSelector: [{ scheme: 'file', language: 'test' }],
	};

	connection = connectToServer("<IP_ADDRESS>", "3000", "test-language-server");

	client = new LanguageClient(
		"TestLSP",
		"Test Language Server",
		() => Promise.resolve<StreamInfo>({
			reader: connection,
			writer: connection,
		}),
		clientOptions);

	client.start();
	context.subscriptions.push(client);

	console.log('Test LSP Client started!');
}

Many thanks!
E.

Actually I realized my problem is elsewhere - looks like VSCode sends Content-Length header and that messes up my LSP4J server implementation. So is there any way to suppress that?


Move WFS typedefs to typedefs.js

A further step in cleaning up typedefs. As these are marked 'api', I've added a note to the release notes. If people agree with the principle of renaming these things so their names no longer include sub-namespaces, I'll change the others. For the new names, I've followed the principle of leaving the sub-namespace in the name where there's ambiguity, for example, ol.xml.Parser becomes ol.XmlParser not ol.Parser, but removing it where there is no ambiguity, as with these two WFS names where there's no need to preserve 'format'.

If these typedefs make sense in the context of a format, I would keep format in the name. I think it is not related to ambiguity.

I like the names in this pull request. It's consistent with what we do with names in externs/olx.js.

In the case of ol.WFSFeatureCollectionMetadata and ol.WFSTransactionResponse I think there are good arguments to do the proposed change: the typedefs could be reused outside of the formaters. I don't know if it is a good systematic change though, hence my remark.
That being said, if it tastes better this way, the change is fine with me.

it's what I did for the WKT and KML changes. ISTM it's obvious that they're to do with formats. Also layer.LayerState - do you really gain anything by making that LayerLayerState? OTOH creating ol.Parser doesn't tell you much - what Parser? So ol.XmlParser seems better in this case.

Can't recall if I left this comment elsewhere, but I think we should have a dedicated annotation for documenting symbols instead of overloading the @api annotation.  The @api annotation should only be used for things that are exportable - and this defines our API.  In my opinion, we should not expand the concept of the API to include annotations specific to the Closure Compiler.  Instead, the API is JavaScript only.

@tschaub yeah, that was my suggestion in https://github.com/openlayers/ol3/pull/5353#issue-154974267


Add a community guidelines readme

Hi.
I want to contribute to this awesome project by creating a readme file that states community guidelines to enlighten people on how to behave while working on the project.
It's an important thing to have when working with a lot of people.
Shall I get started 🙂

Solved #119


#region do not work for *.vue in typescript

I want to use region&endregion, but not work for *.vue ( in typescript script ).
My code:

Please file this against the vetur extension


Return error for zero run tests

As discussed in https://github.com/cpputest/cpputest/pull/1254 before, if there are no tests run, cpputest returns 0.
It seems that a lot of persons agree that "0 run" is usually not an expected result.
However, I can come up with situations when CI scripts run a pack of test binaries with some default filters and it is OK if some binary has no tests to run. Example out of my mind: we package all UTs to single executable and then run the executable on many test systems that may or may not have some library or some hardware instruction or co-processor (e.g. AVXnnn algorithm testing and we want to verify the algorithm, but skip in on non-enabled systems in a reliable way). Maybe not the best example, but I hope the point is clear.
We can also have a debate if 0 tests passed out of 0 run is 100% passed or 0% passed. :-)
As I've already faced few times the issue that CI is "green", but runs nothing due to bug in build scripts, I think, this should be addressed.
My proposal is to choose one of these options (I can implement it, but would like to know what to implement):

just assume that zero test run is an issue and return error, let caller fix itself to expect that (seems to be the most likely to cause issues);
add new parameter, return failure if zero tests run and the parameter is not provided (may need fixing callers during cpputest update);
add new parameter, return failure if zero tests run and the parameter is provided (whoever wants the feature has to enable it in the caller);
add build configuration flag to choose 2 or 3;
add build configuration flag to choose 1 or current behavior.

If I would have to decide, I'd choose 3 or 4 (possibly 3 for simplicity). It seems to be aligned to valgrind's --error-exitcode=n (do we want the code to be configurable?).
Could maintainers please give some guidance?

I'm leaning towards 1 as it is the simplest.
Not just return an error but also report an error message probably.

Working on it, but takes time as a lot of code assumes "no failed tests = OK"; have to think about each occurrence
Could you please assign to me to avoid duplicate work?

@basvodde : seems the #1 does not work even with cpputest's own CMake tests (seen in https://github.com/cpputest/cpputest/pull/1268, Travis CI link):
68: Test command: /home/travis/build/cpputest/cpputest/cpputest_build/tests/CppUTestExt/CppUTestExtTests "-sg" "IEEE754ExceptionsPlugin2"
68: Test timeout computed to be: 1500
68: !
68: Errors (ran nothing, 510 tests, 0 ran, 0 checks, 1 ignored, 509 filtered out, 0 ms)
68:
68/70 Test #68: CppUTestExtTests.IEEE754ExceptionsPlugin2 ....................................................***Failed    0.00 sec

As you can see, it automatically splits test groups to tests in CTest and some groups have zero tests to run (all ignored). As a result, my change fails the test (quite reasonably).
So, the point is that it seems that restrictions to always treat empty test run (i.e. no tests executed) as failure may be too strict. Probably options 2 or 3 are better (need to decide default to fail or to not fail)

@basvodde : can we get back to this please?
I need guidance how to handle this as option #1 did not work easily (it seems likely to be breaking change for many users)

I thought it over some more and still think option #1 is the correct one. What do we need to do to fix our own build?

The issue comes from this test group (tests/CppUTestExt/IEEE754PluginTest.cpp), I believe:
static IEEE754ExceptionsPlugin ip;

TEST_GROUP(IEEE754ExceptionsPlugin2)
{
    void setup(void) _override
    {
        TestRegistry::getCurrentRegistry()->installPlugin(&ip);
    }
};

IGNORE_TEST(IEEE754ExceptionsPlugin2, should_not_fail_in_ignored_test)
{
    set_everything_c();
}

As a fix I can propose to merge the test to the main test group for the plugin (the same file):
TEST_GROUP(FE__with_Plugin)

But the group uses fixture instead of real test registry, so I'm not 100% sure that it is valid replacement.

If there are no test run but still tests IGNORED, then I would assume that it ought to pass.

To summarize: OK (510 tests, 0 ran, 0 checks, 1 ignored, 509 filtered out, 0 ms)

if tests is 0 -> fail;
if ran + ignored is 0 -> fail. (This covers previous 1 as well as 0 tests will result in 0 ran.)

Sorry, for clarity: if there failures also fail as before


Please add why customers get either - By Licence X

Please add to the table when customers get MCAS over O365 CAS - By licence X
Even the Licensing Datasheet doesn't have a table.

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

ID: 76a66643-56f5-dc00-5af6-3ee1d9b6f090
Version Independent ID: c319c4a4-974e-7e3a-d58a-76fd57a9efe9
Content: Differences between Cloud App Security and Office 365 Cloud App Security
Content Source: CloudAppSecurityDocs/editions-cloud-app-security-o365.md
Service: cloud-app-security
GitHub Login: @dcurwin
Microsoft Alias: dacurwin

Thanks for your comment. We'll investigate and get back to you.

@DavidTaig  - Hi - could you clarify your question? I'm interested in helping with the documentation, but I don't understand your request. Thanks.

We haven't heard back from you, so we will now close this issue. If this remains an issue, please reply and we will gladly continue the discussion.


[Bug]: Puppeteer executable not found in Google Cloud Run container

Minimal, reproducible example
await puppeteer.launch({
        headless: 'shell',
        timeout: 0,
      });

Error string
Error: Could not find Chrome (ver. 122.0.6261.57)
Bug behavior

[ ] Flaky
[ ] PDF

Background
I updated to puppeteer 22.2.0 and now my app running on Cloud Run throws that error.
It used to work well with 21.7.0, nothing change in my app code
Expectation
Puppeteer to open chrome
Reality
Launch throws an error
Puppeteer configuration file (if used)
const { join } = require('path');

/**
 * @type {import("puppeteer").Configuration}
 */
module.exports = {
  // Changes the cache location for Puppeteer.
  cacheDirectory: join(__dirname, '.cache', 'puppeteer'),
};

Puppeteer version
22.2.0
Node version
18
Package manager
npm
Package manager version
10.2.4
Operating system
Linux

This is my Dockerfile which Google Cloud uses to build the image, this was working with 21.7.0
`FROM node:18-slim As production
WORKDIR /usr/src/app
COPY package*.json ./
Install node modules
RUN npm ci --omit=dev
Bundle app source
COPY . .
Run the build command which creates the production bundle
RUN npm run build
RUN apt-get update
&& apt-get install -y wget gnupg
&& wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
&& sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
&& apt-get update
&& apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1
--no-install-recommends
&& rm -rf /var/lib/apt/lists/*
RUN npx puppeteer browsers install chrome
USER node
Start the server using the production build
CMD [ "node", "dist/main.js" ]
`

I am not sure why it worked but the issue seems to be that the user is changed after browser is downloaded so the cache folder used to install and to launch the browser are different. The following reduced Dockerfile works:
FROM node:18-slim

RUN apt-get update \
    && apt-get install -y wget gnupg \
    && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
    && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
    && apt-get update \
    && apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf libxss1 \
      --no-install-recommends \
    && rm -rf /var/lib/apt/lists/*

USER node

WORKDIR /home/node

RUN npm i puppeteer@latest
RUN npx puppeteer browsers install chrome

CMD [ "node", "-i" ]

nodnode node@d8e63713e1ab:~$ node -i
Welcome to Node.js v18.19.1.
Type ".help" for more information.
> const puppeteer = await import('puppeteer')
undefined
> const browser = await puppeteer.launch({headless: 'shell'})
undefined
> await browser.close()


Yum module can potentially lock at times

Existing lock /var/run/yum.pid: another copy is running is part of the error message.
Notes/Solutions

Make the yum module check if /var/run/yum.pid is active.  Wait a certain time and pass back a result stating yum is being used.
Could be on the user end where yum is being used by a bootstrap program
Started occuring after fix #99

Haven't seem this error occuring lately. Might have been a one-off thing. Let's re-open this if it occurs predictably.


shareConnections does not work since 2.2.3

The http config parameter shareConnections does not work in Gatling 2.2.3 and 2.2.4: connections are not being reused within one scenario.
Here's a reproducer:
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import io.gatling.core.scenario.Simulation
import scala.concurrent.duration._
class TestSimulation extends Simulation {
   val httpProtocolShareConnections = http
    .connectionHeader("Keep-Alive")
    .shareConnections
   setUp(
    scenario("Reproducer").exec(http("Reproducer").get("http://_YOUR_TEST_SERVER_HERE_/"))
      .inject(constantUsersPerSec(1) during (5 seconds)).protocols(httpProtocolShareConnections)
   )
 }

Just replace the "YOUR_TEST_SERVER_HERE" with some web server of your choice that supports keep-alive.
Sample log output when running with Gatling 2.2.3/2.2.4:
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
...
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
...
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Sample log output when running with Gatling 2.2.2:
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
...
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
...
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive

No, Gatling connection pool sharing works just fine. If something, AHC connection pooling is getting actually faster.
You can enable AHC debug logs and check if it's opening a new channel or using a pooled one:
<logger name="org.asynchttpclient.netty.channel.NettyConnectListener" level="DEBUG" />
<logger name="org.asynchttpclient.netty.request.NettyRequestSender" level="DEBUG" />

The Keep-Alive response header is non standard, even Mozilla recommend not using it for prod, even though (oh the irony) their own website uses it...
Anyway, the way the server decides to decrement the max attribute seems to be very implementation specific, and in the case of the Mozilla website, quite random... I ran your test several times and sometimes always got 1000, sometimes varying values (even sometimes increasing while I was definitively reusing the same connection) if I decrease the injection rate (rampUsers(5) over(10)).

@slandelle Sorry for the delayed reply: I've double-checked it and found that the config setting ahc.keepAlive is the key. In my test suite most scenarios should be tested without keep-alive and just a few scenarios with it. That's why I decided to set keepAlive=false in gatling.conf as default and override this setting in the very few scenarios by using connectionHeader("Keep-Alive") in the protocol setup DSL.
When running the reproducer scenario from issue description above with 2.2.2 and extra debug logging I get following output:
HTTP request:
GET http://host:19700/complexping/
headers=
Connection: Keep-Alive
Host: host:19700
Accept: */*
=========================
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
...
16:22:55.901 [DEBUG] o.a.n.r.NettyRequestSender - Using polled Channel [id: 0x2c14629d, L:/<IP_ADDRESS>:55095 - R:/host:19700] for uri http://host:19700/complexping/
16:22:55.901 [DEBUG] o.a.n.r.NettyRequestSender - Using open Channel [id: 0x2c14629d, L:/<IP_ADDRESS>:55095 - R:/host:19700] for GET '/complexping/'
16:22:55.918 [TRACE] i.g.h.a.ResponseProcessor -
...
HTTP request:
GET http://host:19700/complexping/
headers=
Connection: Keep-Alive
Host: host:19700
Accept: */*
=========================
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=999
Connection: Keep-Alive
...
16:22:56.881 [DEBUG] o.a.n.r.NettyRequestSender - Using polled Channel [id: 0x2c14629d, L:/<IP_ADDRESS>:55095 - R:/host:19700] for uri http://host:19700/complexping/
16:22:56.881 [DEBUG] o.a.n.r.NettyRequestSender - Using open Channel [id: 0x2c14629d, L:/<IP_ADDRESS>:55095 - R:/host:19700] for GET '/complexping/'
16:22:56.899 [TRACE] i.g.h.a.ResponseProcessor -

The same setup (ahc.keepAlive=false and connectionHeader("Keep-Alive") in scenario) results in following output with 2.2.4:
HTTP request:
GET http://host:19700/complexping/
headers=
Connection: Keep-Alive
Host: host:19700
Accept: */*
=========================
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
...
16:16:15.271 [DEBUG] o.a.n.c.NettyConnectListener - Using new Channel '[id: 0xb549bb41, L:/<IP_ADDRESS>:54862 - R:/host:19700]' for 'GET' to '/complexping/'
16:16:15.289 [TRACE] i.g.h.a.ResponseProcessor -
...
HTTP request:
GET http://host:19700/complexping/
headers=
Connection: Keep-Alive
Host: host:19700
Accept: */*
=========================
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
...
16:16:16.271 [DEBUG] o.a.n.c.NettyConnectListener - Using new Channel '[id: 0x2eb6bce8, L:/<IP_ADDRESS>:54863 - R:/host:19700]' for 'GET' to '/complexping/'
16:16:16.289 [TRACE] i.g.h.a.ResponseProcessor -

However, after setting ahc.keepAlive=true in 2.2.4 connections are reused indeed:
HTTP request:
GET http://host:19700/complexping/
headers=
Connection: Keep-Alive
Host: host:19700
Accept: */*
=========================
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
...
16:15:37.981 [DEBUG] o.a.n.r.NettyRequestSender - Using pooled Channel '[id: 0xbc742ea6, L:/<IP_ADDRESS>:54802 - R:/host:19700]' for 'GET' to 'http://host:19700/complexping/'
16:15:37.981 [DEBUG] o.a.n.r.NettyRequestSender - Using open Channel [id: 0xbc742ea6, L:/<IP_ADDRESS>:54802 - R:/host:19700] for GET '/complexping/'
16:15:37.997 [TRACE] i.g.h.a.ResponseProcessor -
...
HTTP request:
GET http://host:19700/complexping/
headers=
Connection: Keep-Alive
Host: host:19700
Accept: */*
=========================
HTTP response:
status=
200 OK
headers=
Keep-Alive: timeout=5, max=999
Connection: Keep-Alive
...
16:15:38.981 [DEBUG] o.a.n.r.NettyRequestSender - Using pooled Channel '[id: 0xbc742ea6, L:/<IP_ADDRESS>:54802 - R:/host:19700]' for 'GET' to 'http://host:19700/complexping/'
16:15:38.981 [DEBUG] o.a.n.r.NettyRequestSender - Using open Channel [id: 0xbc742ea6, L:/<IP_ADDRESS>:54802 - R:/host:19700] for GET '/complexping/'
16:15:38.998 [TRACE] i.g.h.a.ResponseProcessor -

So I guess it's rather an issue with the global keep-alive setting not being overridden by the local connectionHeader setup.

config param means that keep-alive should be supported or not. If you set it to false, you're disabling connection pooling.
If you want specific requests to close connection, set the Connection header to false, that's what it's for!


Idnits gives opposite suggestions

Describe the issue
A document I'm shepherding used to include in the abstract a phrase like "This document updates [RFCXXXX]" and Idnits requested to get rid of references there. The editors did the change, but now Idnits complaints (as a comment) that, considering the update field in the header, "the abstract doesn't seem to mention this, which it should".
To me, that I-D is fine to progress like this, but I'm not comfortable with that behavior of Idnits.
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

Hi Robert.
Thanks for the feedback. The analysis that triggered my comment is here: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-local-protection-enforcement-07.txt

In any case, we are working towards a replacement for idnits that will behave differently.

I saw that when filling in the shepherd write-up. If my comment is addressed as part of the rewriting, there's no reason to spend time tweaking the legacy implementation.

Ah - I see - the IESG does want the Abstract to call out the Updates/Obsoletes information, but not as references.
When the document gets that far, they will ask for a sentence that looks like "This document updates RFC5540." But note that the RFC5540 string in the sentence is not a reference.

OK, that explains! So it isn't really a bug. I hope the future releases of Idnits will make that clearer, e.g. add "without square brackets" in the output.
Thank you, Robert!


Wrong 0.9.2 Version

The 0.9.2 is not the good one on npm.
I think the npm run build was forgotten before the npm publish.
Maybe a Github Action can void similar issues in the future. What do you think about it ?

I'm sorry, but I'm on vacation with limited access, so I made this mistake :(
Yes GitHub Actions could be a good solution ;)
In the meantime I have released a new version.

Nice for the new version! It works! 🚀
No problem ! Have good vacations 🏝
I will look at Github Actions and create a PR.