case view: make any filterable field in the data side bar link to the search results

any search filter available for cases (except location for now) is linked to a search results page for that filter from the data side bar:

the link takes you to the search results page with results filtered for that field/key.

@jesicarson @dethe

@ascott This is rad! Is this on prod or staging?

it’s on staging now. just doing some more testing before pushing to prod.
On Wed, Aug 21, 2019 at 4:55 PM jesicarson<EMAIL_ADDRESS>wrote:

@ascott https://github.com/ascott This is rad! Is this on prod or
staging?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/participedia/api/pull/719?email_source=notifications&email_token=AAA76PQ7DNN2V7UNVJ6OLCDQFXIXXA5CNFSM4IOMHZV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD43OWCI#issuecomment-523692809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA76PSIIJR2RHRVSDZCS3TQFXIXXANCNFSM4IOMHZVQ
.


keyNotFound(code: "BCLM")

I have the same problem with "keyNotFound(code: "BCLM").

@fishcf @salted-sk
M1/M2 Mac?

dlabrie@mba ~ % bclm read keyNotFound(code: "BCLM") dlabrie@mba ~ % sudo bclm write 80 keyNotFound(code: "BCLM")

The same problem
M1, MacOs Monterey 12.5.1

same problem here.

See #20 for Apple Silicon and and #18 for Intel.

use https://github.com/actuallymentor/battery instead @eecopilot

216MB for the app that monitors battery percentage and turns off/on charging? **** it, I'm implementing it myself.


Multiple scanning of images doesn't work on latest version

After updating to
implementation 'com.google.ar.sceneform.ux:sceneform-ux:1.11.0'
I was able to detect the first image, but when I have multiple images in the database, I tried scanning one after the other without refreshing the screen, but it doesn't work like on the previous versions. It not only does not scan the image, but it slows down the app when the image is part of the database.

I tried downgrading the version to 1.10 or 1.9 but I'm still having the same problem

I tried downgrading the version to 1.10 or 1.9 but I'm still having the same problem

I used
implementation 'com.google.ar.sceneform.ux:sceneform-ux:1.8.0'
and this problem did not appear.
Maybe you can try this version instead?


Increase Cypress code coverage 232

Add Cypress spec files:

TagCreator
Landing
HowToUse

Add tests to existing spec files:

Contributors

Closes #232

I'm marking this as a draft PR because it makes several changes to TagCreator.js — and I want @shinjonathan @JafarIronclad and @stephenJeong to consider if it might get in the way of their work on #228. Some of my edits are to add data-cy attributes and we should prioritize keeping those, no matter what happens to the other edits.

I'm marking this as a draft PR because it makes several changes to TagCreator.js — and I want @shinjonathan @JafarIronclad and @stephenJeong to consider if it might get in the way of their work on #228. Some of my edits are to add data-cy attributes and we should prioritize keeping those, no matter what happens to the other edits.

Taking into account the recent changes in TagCreator, I updated this PR accordingly and it is now ready for review / merge.
The current code coverage can be seen here: https://lcov-report.kevinashworth.vercel.app/ We were at abou 50%, now we are at about 80%. There is still some low hanging fruit, but this PR really takes us a big step forward.


How could I add a button with scrollNext on each slide as in the image?

Hi,
How could I add a button with scrollNext on each slide as in the image?
I'm still new to javascript
I'm sorry for the english from google translator

Hi @lorenzecode,
Thank you for your question. Are you using Embla with Vanilla JavaScript or React?
Best,
David

Thanks for answering
Currently in Vanilla JS

Thank you for the details @lorenzecode.
For example, if your buttons have the classname .scroll-next-button, you could do something along these lines:
const scrollNextOnSlideButtonClick = () => {
  // embla.clickAllowed() only returns true if the pointer interaction is a click, not if it is a drag move.
  if (embla.clickAllowed()) {
    embla.scrollNext();
  }
}

embla.slideNodes().forEach((slideNode) => {
  const scrollNextButton = slideNode.querySelector('.scroll-next-button');
  scrollNextButton.addEventListener('click', scrollNextOnSlideButtonClick, false);
});

Let me know if it helps.
Best,
David

Thank you for the details @lorenzecode.
For example, if your buttons have the classname .scroll-next-button, you could do something along these lines:
const scrollNextOnSlideButtonClick = () => {
  // embla.clickAllowed() only returns true if the pointer interaction is a click, not if it is a drag move.
  if (embla.clickAllowed()) {
    embla.scrollNext();
  }
}

embla.slideNodes().forEach((slideNode) => {
  const scrollNextButton = slideNode.querySelector('.scroll-next-button');
  scrollNextButton.addEventListener('click', scrollNextOnSlideButtonClick, false);
});

Let me know if it helps.
Best,
David

Hi, @davidcetinkaya
Would it be too much to ask for an example with the images of the cats?
I tried your solution here but I must be doing something wrong
Thanks again and sorry for the inconvenience

Hi, @davidcetinkaya
Would it be too much to ask for an example with the images of the cats?
I tried your solution here but I must be doing something wrong
Thanks again and sorry for the inconvenience

Hello @lorenzecode,
Would you mind creating a CodeSandbox with your setup and share the link here? I can modify your sandbox and show you how to achieve what you want.
Kindly,
David

Hello @lorenzecode,
Would you mind creating a CodeSandbox with your setup and share the link here? I can modify your sandbox and show you how to achieve what you want.
Kindly,
David

@lorenzecode, here's a CodeSandbox demonstrating what you want to achieve.
Let me know if it helps.
Best,
David

@lorenzecode, here's a CodeSandbox demonstrating what you want to achieve.
Let me know if it helps.
Best,
David

Wow @davidcetinkaya is exactly that
Thank you very much

Wow @davidcetinkaya is exactly that
Thank you very much

You're welcome @lorenzecode. I'm closing this issue as resolved then. Enjoy!

You're welcome @lorenzecode. I'm closing this issue as resolved then. Enjoy!


Deletion of notify.min.js breaks apps

We use Notify.js via Symfony and Assetic. With Bower looking for ~0.3.2 we automatically fetch 0.3.4 and notify.min.js has been deleted from that. Since this breaks backwards compatibility should the deletion of that file have been saved for a minor version rather than a patch version?

Ah yes, very true. Tagged 0.3.3 to be last commit before deletion and 0.4.0 is now latest.

Let me know if there's still issues

Works nicely, thanks.


Dependency won't build on Xcode 12.4 using SPM

Describe the bug
While moving all of our dependencies from CocoaPods to SPM, the only library that won't build at the moment is RxReachability, therefore blocking us from moving all of our Rx related dependencies to the SPM.
Problem lies in the underlying dependency to Reachability.swift which does not specify the minimum version. Xcode 12 is now treating iOS8 Target as a warning, so all of SPM modules without clearly defined minimal version is resolving to iOS 9.0.
At the same time, RxReachability have a requirement still pointing to iOS 8 as a minimal version, creating an error while building:
The package product 'Reachability' requires minimum platform version 9.0 for the iOS platform, but this target supports 8.0
To Reproduce
Try to use RxReachability via SPM on Xcode >= 12.4
Expected behavior
I want to use RxReachability via SPM on newest Xcode.

I think #43 should fix this

#43 fixes


Update Documentation or program: How to config multiple playlist

Is your feature request related to a problem? Please describe.
My IP-Provider only allow one connection per account, I can easy buy more but how to I handle that in plex or xTeVe.
If I add it as a diffrent playlist i still get the warning that all provider is used when i try multiple connections
Describe the solution you'd like
I way to allow multiple connection if i add more playlist with the same channels etc.
Could a solution running multiple instanses of xTeVe and then compain them in someway in plex?
Describe alternatives you've considered
Could a solution running multiple instanses of xTeVe and then compain them in someway in plex?

Nope, you can't use xTeVe to "Hack" your Provider...Sorry.


Allow putting documentation after members

Having used Doxygen in the past, I came to like its Putting documentation after members syntax in some cases.
Here is an example:
var numbers = {
  one:   1, /**< A single item */
  two:   2, /**< Two items */
  three: 3  /**< Three items */
}

This lends itself particularly well to table-like initialisations and similar code structures where the documentation consists of just a single line or less.

Thanks for the suggestion. Unfortunately, it would be extremely difficult to implement, and I think the difficulty of implementing this suggestion outweighs the value it would add. For that reason, I'm closing this issue.


CLI

Wanted to make this more of a CLI operation. Allow users to supply command-line arguments, such as --inline-styles or -is, like the Angular CLI when creating various aspects of an Angular project.

c14a2b3 added the CLI


2019 Reporting Period

Hey there. I'm a developer for an EHR. We're updating our measures for the 2019 reporting period. Before releasing the updates, we need to confirm that our generated QRDA III files pass CMS validation.
Do you have an rough estimate on when the qpp-conversion-tool will be updated for the 2019 reporting period?
Thank you,
Ryan

@RyanGonet: Updates for the 2019 reporting period will most likely not be made until later this summer.  The goal is to have changes available in a developer preview/sandbox environment by early autumn.

Thank you @sfradkin


Adds provider’s trainee ID to bulk recommend

We've seen in the first two rounds of research that users would find it difficult to identify trainees by their TRN alone.
To avoid needing to add names to the spreadsheets, we can give users the trainee ID. This probably isn't sufficient but it would be good to rule it out before reverting to needing to use the trainee names.
Updated pre-populated file column descriptions

Updated template column descriptions

Update error page

shows both IDs
tweaks error message about missing ID
adds error message about TRN and Trainee ID not matching

Updates pending changes
Shows IDs in their own column.

Also adds trainee names to the csvs:

Adds 'First names' and 'Last names' to the csvs

Changed "Trainee ID" to "Provider ID" and made everywhere we show names "Last name, First name".
Error summary gets a lot busier, but I think its better to show all the relevant data.

Check pending — have gone back to a single column for trainee name and both IDs


Fix READMEs in each package

Codecov Report

Merging #470 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #470   +/-   ##
=======================================
  Coverage   86.15%   86.15%
=======================================
  Files          57       57
  Lines        4565     4565
  Branches      495      495
=======================================
  Hits         3933     3933
  Misses        476      476
  Partials      156      156

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 ff51954...1ef7fb7. Read the comment docs.


installation issue

Hi ,
I am getting the following issue while installing setup with Scorpio broker .

While running
./service scorpio

From which folder? There are lots of different tutorial repos.

hi,
I am facing this issue from the below repo:
https://github.com/FIWARE/tutorials.IoT-Agent/tree/NGSI-LD

Your issue is a lack of a HEALTHCHECK in the underlying Dockerfile. I am unable to reproduce. Just to check you have the latest code base try the following:
cd tutorials.IoT-Agent
git status
git log -1

Should return the following:
On branch NGSI-LD
Your branch is up to date with 'origin/NGSI-LD'.

commit aafbf8c6f981d154a792c70052291fbef652480c (HEAD -> NGSI-LD, origin/NGSI-LD)
Author: Jason Fox<EMAIL_ADDRESS>Date:   Fri Jan 7 16:22:45 2022 +0100

    Update Orion

If not you may need to change branch or git pull.
Scorpio's HEALTHCHECK can be clearly seen in the scorpio-aaio.yml.
If you open another tab and run docker ps - you should see (healthy) next to  the scorpiobroker container.
CONTAINER ID   IMAGE                                      COMMAND                  CREATED          STATUS                    PORTS                                                      NAMES
6d9d82b40dea   scorpiobroker/scorpio:scorpio-aaio_1.1.0   "/bin/sh -c 'bash ./…"   53 minutes ago   Up 53 minutes (healthy)   <IP_ADDRESS>:9090->9090/tcp                                     fiware-scorpio
4c5d458a3017   wurstmeister/kafka                         "start-kafka.sh"         53 minutes ago   Up 53 minutes             <IP_ADDRESS>:63101->9092/tcp                                    kafka
f7a3b5d340c5   fiware/iotagent-ul:1.19.0-distroless       "/nodejs/bin/node ./…"   53 minutes ago   Up 53 minutes (healthy)   <IP_ADDRESS>:4041->4041/tcp, <IP_ADDRESS>:7896->7896/tcp, 4061/tcp   fiware-iot-agent
ffed1d4211b9   fiware/tutorials.ngsi-ld                   "/nodejs/bin/node ./…"   53 minutes ago   Up 53 minutes (healthy)   <IP_ADDRESS>:3000-3001->3000-3001/tcp                           fiware-tutorial
69003b56b100   mongo:4.4                                  "docker-entrypoint.s…"   53 minutes ago   Up 53 minutes (healthy)   <IP_ADDRESS>:27017->27017/tcp                                   db-mongo
c0462485102e   httpd:alpine                               "httpd-foreground"       53 minutes ago   Up 53 minutes (healthy)   <IP_ADDRESS>:3004->80/tcp                                       fiware-ld-context
15172b06ab3a   zookeeper                                  "/docker-entrypoint.…"   53 minutes ago   Up 53 minutes             2888/tcp, 3888/tcp, 8080/tcp, <IP_ADDRESS>:63100->2181/tcp      zookeeper
5ff8e04da714   mdillon/postgis                            "docker-entrypoint.s…"   53 minutes ago   Up 53 minutes             <IP_ADDRESS>:63099->5432/tcp                                    db-postgres

Stale - unable to reproduce. Closing.


Fixed interface icons on Windows and MacOS

This PR fixes the issues with icons on Windows and MacOS.
According with the documentation

Note: By default, only X11 will support themed icons. In order to use themed icons on Mac and Windows, you will have to bundle a compliant theme in one of your themeSearchPaths() and set the appropriate themeName().

Related with this PR https://github.com/ros-visualization/rqt_plot/pull/58
Signed-off-by: ahcorde<EMAIL_ADDRESS>

Where did the icons come from and how are they licensed? I suggest documenting these things in a README.md inside the icons/ directory.

Closing this PR in favour of this other PR https://github.com/ros2/ros2/pull/928


Hope to make a set of Solarized Light themes for pycharm

Really sorry pycharm has not seen such a beautiful theme hope to migrate to pycharm on
English is not good with google translation sorry

@huilaoda I have plans to create color schemes for JetBrains IDEs. I'll write you when they will be ready :wink:


Update to the latest build conventions

add windows build
remove deprecated capitalize use.
update spotbugs suppressions

coverage: 96.075%. remained the same
when pulling ddb91965be7284c987006f27749bdc4892e26055 on conventions
into 57fe7e8d48fef0eefab1b372d2efe5c1f8c75aeb on main.


feat(spanner): add samples for UpdateDatabase

This PR adds samples and integration tests for UpdateDatabase request.

LGTM apart from a requested change in file name and a general comment: Can we remove the TODOs and keep this PR clean (having only the changes which will be merged ultimately)? You can add a comment on the PR or mention as Note in the title saying that tests are expected to fail because the feature is not enabled in /span/cloud. We can have them locally of course, to test the changes.

@harshachinta: Can we rename the PR title, and description to indicate UpdateDatabase as a feature (not Drop Database Protection)? Also, letting the user know where we are in the program flow would be a good user experience. Can we add some logs for that? Similar to link. You can refer to Node.js PR.

@telpirion Can you please review this PR on high priority?

@tritone
I have made the suggested changes and all the build pass as expected.
Can you please help me with merging the PR if there are no other questions?


Question: Static type checking and "inner"

The FAQ doesn't seem to explain the considerations behind not adding static type checking and the inner keyword from BETA that is mentioned on stuffwithstuff and in Crafting Interpreters.
@munificent Usually, I'd default to "too complicated with not enough to gain for legit-sized scripts" and "too unusual", but since you've got a blog pondering about language features in detail where things often are more fine grained than that, I though, I'd give it a shot and ask if there are more detailed reasons.
Thanks in advance and a happy new year!
Sauer2

As far as static types goes, adding a type checker adds a mountain of complexity to the language. I do like static types, especially when working on large codebases, but for a little scripting language, I think they are overkill.
As far as inner goes, I am actually pondering it for Wren and have been for years. I haven't found the time to sit down and figure out how to implement it efficiently and see if it makes sense, but it's on my mental list of features to consider before calling Wren 1.0.

Thanks!


UPD TestUtils - sleep replaced by waitingForDestinationReady

because issue #280 was fixed

shouldn't be merged before: https://github.com/EnMasseProject/enmasse/pull/391


Fix exception handling when SauceLabs goes down

Getting the number of Test cases running from sauceLabs fails
we return an empty string (after several retries to Sauce)
which causes an illegalStateException on parsing in
SeLionSauceProxy. Now log and continue.

@sebady as soon as the CI succeeds, go ahead and merge this please.


[Question] Security Consideration

Hi there,
I've been looking into a lot of methods of implementing a Paypal button, and currently I like this one the most. I have very limited knowledge on the security side of these payment options, so I was wondering if anyone can give me some insights on how secure this implementation is (in particular, the Basic and Advanced integration documented here. I know nothing is 100% secure, but a very high level discussion of what the concerns could be (if there is any significant ones), and what I can do to mitigate them, would be very very much appreciated!
Thanks in advance.

@trainerbill can you help elaborate on this one?

@mfxuus The easiest way to integrate is the basic integration which uses the REST api on the client side.  You would have to validate on your server that the totals are correct before completing your fulfillment.  If you do the advanced integration then you need to make a webservice that returns the paypal token.  In this scenario the amounts are generated on the server so you shouldn't have to validate it before fulfillment.  Here is a youtube playlist with some how to videos:
https://www.youtube.com/playlist?list=PLAlKnErU5lvhj3Fqr5hrBxm3CgsQXpEeK
I think your best bet is the basic integration which would be the fourth and fifth videos on the playlist.  If you want to talk about this in realtime head over to the gitter room and I can answer any other questions you have.
https://gitter.im/paypal/paypal-checkout


Add 'Tomorrow' with similar options as 'Yesterday'

Prerequisites

[x] I searched to see if the issue already exists.

Description
I'd like to be able to specify relative dates in the near future as per the 'Yesterday' options
Steps to Reproduce
N/A

👍 SGTM, probably won't have time to get to it any time soon, but if anyone wants to PR

I have no idea about peg, but gave it a shot: #11
There are seemingly non-trivial changes to the generated file on my branch, including an issue where RuleIn was defined twice, which might be down to a later version of peg?

awesome thanks! I forgot to add docs about peg, but I re-regenerated with my local copy anyway, thanks man!

No worries, fits my use cases so I'm happy to help :tada:
Can you please cut a release so I can keep my go.mod tidy?

done!


Radarr success no difference in space grey

should be green or dark green
i use this now:
.Label-success-1pfcC {
    border-color: #1b8033;
    background-color: #1b8033;
    color: #eee;
}

Thanks for the issue, should be good now.

i would suggest to not override the success badge style, its a state info and not an accent.


Refactor organization-contact form to be template-driven form

Description:
Organization-contact component uses template-driven approach but it will be easier to manage form's state if it will be reactive form.
Refactoring should help e.g. with this problems:

after submission form is reset and user's data that should populate the form disappear
after submission alert error for phone field is visible

Additionally, small changes in styling are needed, as inputs in this form are bigger than in most form in the app (change bootstrap classes).

Can I take it?

Sure @stanislawK


TUI build fails on OpenBSD

# uname -a
OpenBSD hi5.lan 7.2 GENERIC.MP#186 riscv64
# cc --version
OpenBSD clang version 13.0.0
Target: riscv64-unknown-openbsd7.2
Thread model: posix
InstalledDir: /usr/bin

I've tried on both dev and release branches. Both fail with this message:
# git clone --recurse-submodules https://github.com/skyjake/lagrange.git
# cd lagrange
# ./build-tui.sh
<snip>
-- Installing: /home/user/work/lagrange/build-tui/include/the_Foundation/xml.h
-- Installing: /home/user/work/lagrange/build-tui/include/the_Foundation/config.h
-- Installing: /home/user/work/lagrange/build-tui/lib/pkgconfig/the_Foundation.pc
-- Installing: /home/user/work/lagrange/build-tui/lib/cmake/the_Foundation/the_FoundationConfigVersion.cmake
-- The C compiler identification is Clang 13.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2")
-- Checking for module 'ncursesw'
--
CMake Error at /usr/local/share/cmake/Modules/FindPkgConfig.cmake:607 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindPkgConfig.cmake:829 (_pkg_check_modules_internal)
  CMakeLists.txt:10 (pkg_check_modules)
-- Configuring incomplete, errors occurred!
See also "/home/user/work/lagrange/build-tui/build-sealcurses/CMakeFiles/CMakeOutput.log".
make: cannot open Makefile.

Attached is CMakeOutput.log:
CMakeOutput.log

Hmm, is the ncursesw pkg-config module named differently on OpenBSD? Or is it just not installed on the build system?

From what I see from man 3 curses OpenBSD doesn't separate the "wide" curses routines into separate files. See section 'Routine and Argument Names' here

I checked how the build-tui.sh script works on OpenBSD and there were a couple of problems with it. However, the system-provided curses library doesn't work super well... More work is needed to make it run adequately.


Clicking on the small quota bar on the account pages should go to the plan tab

I mean this one

to be done in cartodb-central dropdowns, too

It is not the dropdown matallo, it is this one!

You don't have to do anything because it doesn't make any sense to add the link being in that page...
So, you are done!


Correction for raw affiliation Department of Anthropology, University of New Brunswick
Center for Behavior, Institutions and the Environment, Arizona State University
School of Human Evolution and Social Change, Arizona State University

Correction needed for raw affiliation Department of Anthropology, University of New Brunswick
Center for Behavior, Institutions and the Environment, Arizona State University
School of Human Evolution and Social Change, Arizona State University
raw_affiliation_name: Department of Anthropology, University of New Brunswick
Center for Behavior, Institutions and the Environment, Arizona State University
School of Human Evolution and Social Change, Arizona State University
new_rors: 03efmqc40;05nkf0n29
previous_rors: 03efmqc40
works_examples: W2519401008
contact: b8b1e0bd372de6b4b07593789fa61361:bd50221b @ ourresearch.org

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Fixed fetching session timezone.

Sorry, but why is this change needed?
How does it fail, and how does it improve upon it?
Where is the test that fails without this fix, and succeeds with it?
If we don't have such test, then please include a new one!

It fails with "unable to retrieve database timezone" here: https://github.com/rana/ora/blob/master/ses.go#L692
So the type assertion can't be done and it fails. It works properly with these fixes. I can try to write a test, but it's a bit difficult in this repo to setup a testing environment.

It is quite strange to me... This does not happen on Linux with InstantClient 11.2 or Oracle XE 12 connecting to Oracle 11g - I cannot reproduce it.
But I've added a type switch on master - please try it!

I use oracle-instantclient12.1 and Oracle 11.2


Problem with padding in the first table row

version
0.9.45
Link to minimal reproduction
No response
Steps to reproduce
Set the tdPadding setting to 0. After creating a table with two or more rows, inserting the data with a background color, you will notice that the first row has bottom padding that it shouldn't.
What is expected?
When the padding is set to 0 in the initial configuration, the entire table must have no internal spacing.
If possible, it would be interesting to define a padding/margin setting for each tr/td, directly in the data schema, so it is easier to customize.
What is actually happening?
Hello, working with a table I realized that the first tr/td have a minimum padding bottom even when defined in the initial configuration as 0. I defined the initial option "tdPadding: 0". However, the first line has a small space as shown in the image.
In the next three this does not happen, also as shown in the image the previous table that has the lines merged this detail does not happen.

Is there any way to adjust this? or is it something to be fixed?
Thank you in advance, and again congratulations on the project.
System Info
Windows, Chrome, Firefox and Edge.

Any additional comments?
No response

Edition. I added new tables in the same way, I noticed that in this second all lines are like this with a space on the right,. But if I fill in the end with blanks, on the right side everything is fine.

Doing new tests I realized that if I set row margin to 3 (maximum option in the demo app), the space at the end is compensated, but the final height of the row is greater than I would like.

One more thing, the background is only applied to the text inside, and it doesn't fill the entire cell, as shown in the screenshots. White space must be added on each side to offset and center the text.
The final result I would like would be like this, is it possible to leave it like this at the moment?

An addendum, these were the settings changed to arrive at the result above.
{ tdPadding: 0,   defaultBasicRowMarginHeight: 2,   defaultRowMargin: 1,   defaultTrMinHeight: 0,   defaultColMinWidth: 0,   marginIndicatorColor: '#ffffff'}


Get Footnotes from Dcoument

How can I find the footnotes of a Word document?

I don't think it's currently supported. Neither are endnotes.

thanks for the quick response

It's probably easier to add some support for it. Not sure if i will have time, but I'll play with it soon

@A10s while I am not done with the PR, maybe this is something that will get you started already. You can add, find foot notes and modify them for now. If you're willing to compile your own version it may be just what you need for now. I'll probably finish it in few days if i get enough time. End notes are not done either.

Thanks for the answer. I've already found how to get to the footnotes and the hyperlinks they contain

my code:
var doc=WordDocument.Load("test.docx");
var footnotesPart = doc._document.MainDocumentPart?.FootnotesPart;
if (footnotesPart != null)
{
var footnotes = footnotesPart.Footnotes.Elements();
foreach (var f in footnotes)
{
var hyperlinks = f.Descendants();
foreach (var hyp in hyperlinks)
{
var id=hyp.Id;
var hrs=footnotesPart .HyperlinkRelationships.Single(q => q.Id == id);
var uri= hrs.Uri;
........
}
}}

As long as it works for you ;) My implementation is a bit more complex, but it just simplifies things.
using (WordDocument document = WordDocument.Load(filePath)) {
    foreach (var footNote in document.FootNotes) {
        foreach (var paragraph1 in footNote.Paragraphs) {
            if (paragraph1.IsHyperLink) {
                paragraph1.Hyperlink.Text = "xxx";
            }
        }
    }
}

Thank you for your support!


[PR] Adding badges to README

This is a micro-PR just to check if Codecov is properly working in PRs

Looks good.
Merging to add a few badges and finish #1 .

It's already added

Strong pref for the flat-square badges for consistency with our other repos. 💭
But this is already much better than a "bare" repo. 👍


Web stories theme customizer settings

Summary

Add customizer settings to display web stories list.

Relevant Technical Choices

To-do

User-facing changes

Testing Instructions

Add theme support for web stories options in your theme's functions.php

add_theme_support( 'web-story-options' );

Advanced options and defaults
add_theme_support(
	'web-story-options',
	[
		'view-type'                 => [ 'circles', 'grid', 'list', 'carousel' ],
		'view-type-default'         => 'circles',
		'grid-columns-default'      => 4,
		'title'                     => true,
		'title-default'             => false,
		'author'                    => true,
		'author-default'            => false,
		'date'                      => true,
		'date-default'              => false,
		'stories-archive-link'      => true,
		'stories-archive-label'     => 'View all stories',
		'number-of-stories'         => 5,
		'order'                     => [ 'alphabetical', 'reverse-alphabetical', 'latest', 'oldest' ],
		'order-default'             => 'oldest',
		'show-story-poster-default' => true,
	]
);

Use the Customizer::render_stories method in the desired area in the theme.

echo Customizer::render_stories();

Enable show web stories option from customizer in the Web story options section.

PS: The show square corners option will not work that needs to be handled inside the Renderer classes.

Hey @ankitrox, could you make sure this is based off the correct branch? I guess it should be rebased against #5352

@ankitrox Could you rebase this against #5352 too? Otherwise difficult to know what exactly needs to be reviewed.

Couple of nitpics and changes. Nothing massive. It would also be good to fix the merge conflict.


update linux-asahi, m1n1

@yu-re-ka What is still blocking this? I would like to install nixos on my M2 macbook pro which recently got support.

I will have this done in the next couple days.


discord link is broken

Hi, the discord link seems to be private, if it is intended to be a public server, it would be better to replace it with an auto-join link instead.

nvm, i found the invite link at the bottom of the readme :D


[Bug]Abnormal screen rotation when selecting font size

https://github.com/T8RIN/ImageToolbox/assets/51242302/138e3bd0-c751-4af3-a619-bbf16ff48abd
I have turned off automatic screen rotation and my phone is always in vertical screen mode.
This bug also exists when selecting languages and fonts.

You can say that I thought so, to update the size of the system font, because simple recreation won't help, I don't like this approach either. I'll try to find a solution, it was temporary 🐸

https://github.com/T8RIN/ImageToolbox/assets/51242302/138e3bd0-c751-4af3-a619-bbf16ff48abd
I have turned off automatic screen rotation and my phone is always in vertical screen mode.
This bug also exists when selecting languages and fonts.

When selecting a language? This shouldn't be here...

https://github.com/T8RIN/ImageToolbox/assets/51242302/fa3eb381-71b7-4ff1-a898-69e0d4cbd3e4
This is a screen recording.


Draw event to include what caused the draw

I'm working to convert over the Column Filter Widgets plugin to DataTables 1.10 since it was used in all of our applications. Besides fixing many performance issues and modifying most of the code to use the new DataTables API, there is still a major performance impact with the plugin. I've ran some profiles and found that it was recreating the options for the select boxes on every draw.
Since things like sorting cause a draw, there is no reason for the plugin to redraw the options in the select. I've looked high and low to find some way to prevent redraw on these selects by using what was built into DataTables, but there doesn't seem to be a way as it sits.
I'd like to see the draw event to include an additional parameter that will specify what caused the draw. I understand that it cannot be included for every draw (since the draw API function is publicly available to be called), but for built in tasks such as sorting, this would be very useful and help us to speed up our datatables.
I need the draw event specifically in this case since I do need to redraw those select boxes on filtering and when data is changed/loaded/removed from the table, otherwise I would tap into the available events.
Might be a good idea to add events for when data has changed in the datatable, but unsure if it's setup for that.
Thanks!

@DataTables @KyleRoss
Hi guys, excuse me for bumping an old issue.
Background:
I've got a page which features 3 different datatables on 3 different tabs. If you click certain rows on the 1st datatable, it automatically filters the data in the following 2 datatables in a "drill down" sort of manner.
I use the draw.dt event for this. So, when the first table is drawn, draw the second one, when the second is drawn, drawn the third one etc.
Problem:
I now have a requirement to make an AJAX request to gather some extra information whenever the "filters" are changed and the results of the datatable have been updated to reflect those filters. Again, the draw.dt seems like a perfect candidate for this functionality.
My problem is, I would like to prevent this AJAX request from happening when paginating or sorting has caused the DataTable to be re-drawn and I was wondering if there is a way or a work around to achieve this?
Any input would be much appreciated, I'm using Datatables 1.10.7.

I don't quite understand how the draw event is being used to trigger the child row update. Would you not trigger the child update when the click occurs on the parent table?

Something tracking how the draw was triggered would make the other events more useful as well. I wanted to track how often a user ordered the table to find out if it's reasonable to do our ordering/paginating server side. order.dt is triggered when someone orders a column (awesome!), but it's also triggered by draw every time a search is run. I've searched the docs and objects available in the callback, but haven't been able to find a differentiator between the two events.


_7zz: fix update script; 23.01 -> 24.05

Description of changes
Fix the update script, run it, and update the relevant patches
Also, clean up some existing code

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1651


[test] Remove karma

test_browser is looks nice in theory but in practice we don't get any value from it. Even facebook does not run unit tests in the browser (hence why jest isn't supported in the browser). If a website with over a billion users is still functional without unit tests in the browser I'd say we can live without it as well.
Removing it reduces the number of false positive failures, CI runtime in general and just less code we have to maintain. All of this should improve productivity. Just the commit messages in the evaluated PRs speak for themself ("fix test (hopefully)" or "give up on test").
when does a test suite provide value?
The test suite has value if it finds bugs that other tests didn't find.
Methodology:

assumes test_browser failures are not fixed locally
for each PR check the first 100 commits and see if test_unit succeeded while test_browser did fail
repeat until GitHub API rejects further request because abuse

Results
In the last 6_000 PRs 129 had different results for test_browser and test_unit. I evaluated the 17 most recent of those 129 and found only 1 actual issue. Most of them were either flaky (restart fixed it) or the test needed to be implemented differently. I can evaluate more if the removal is contested.

Actual issue:

https://github.com/mui-org/material-ui/pull/15589/commits

Indeterminate (e.g. force-push?)

https://github.com/mui-org/material-ui/pull/15287/commits

Fixed by changing test:

https://github.com/mui-org/material-ui/pull/15495/commits
https://github.com/mui-org/material-ui/pull/15634/commits
https://github.com/mui-org/material-ui/pull/15716/commits
https://github.com/mui-org/material-ui/pull/15344/commits
https://github.com/mui-org/material-ui/pull/15484/commits
https://github.com/mui-org/material-ui/pull/14865/commits
https://github.com/mui-org/material-ui/pull/14878/commits
https://github.com/mui-org/material-ui/pull/15017/commits
https://github.com/mui-org/material-ui/pull/14682/commits

Test skipped:

https://github.com/mui-org/material-ui/pull/15090/commits

Flaky:

https://github.com/mui-org/material-ui/pull/15996/commits
https://github.com/mui-org/material-ui/pull/16061/commits
https://github.com/mui-org/material-ui/pull/15546/commits
https://github.com/mui-org/material-ui/pull/15469/commits
https://github.com/mui-org/material-ui/pull/15003/commits

Not evaluated (yet; in those PRs docs:api is still part of test_browser):

https://github.com/mui-org/material-ui/pull/14758/commits
https://github.com/mui-org/material-ui/pull/14862/commits
https://github.com/mui-org/material-ui/pull/14465/commits
https://github.com/mui-org/material-ui/pull/14534/commits
https://github.com/mui-org/material-ui/pull/14606/commits
https://github.com/mui-org/material-ui/pull/14617/commits
https://github.com/mui-org/material-ui/pull/14300/commits
https://github.com/mui-org/material-ui/pull/14350/commits
https://github.com/mui-org/material-ui/pull/14379/commits
https://github.com/mui-org/material-ui/pull/14025/commits
https://github.com/mui-org/material-ui/pull/14059/commits
https://github.com/mui-org/material-ui/pull/14100/commits
https://github.com/mui-org/material-ui/pull/14123/commits
https://github.com/mui-org/material-ui/pull/14158/commits
https://github.com/mui-org/material-ui/pull/13722/commits
https://github.com/mui-org/material-ui/pull/13723/commits
https://github.com/mui-org/material-ui/pull/13730/commits
https://github.com/mui-org/material-ui/pull/13816/commits
https://github.com/mui-org/material-ui/pull/13821/commits
https://github.com/mui-org/material-ui/pull/13828/commits
https://github.com/mui-org/material-ui/pull/13877/commits
https://github.com/mui-org/material-ui/pull/13905/commits
https://github.com/mui-org/material-ui/pull/13923/commits
https://github.com/mui-org/material-ui/pull/13945/commits
https://github.com/mui-org/material-ui/pull/13430/commits
https://github.com/mui-org/material-ui/pull/13458/commits
https://github.com/mui-org/material-ui/pull/13483/commits
https://github.com/mui-org/material-ui/pull/13534/commits
https://github.com/mui-org/material-ui/pull/13536/commits
https://github.com/mui-org/material-ui/pull/13584/commits
https://github.com/mui-org/material-ui/pull/13590/commits
https://github.com/mui-org/material-ui/pull/13592/commits
https://github.com/mui-org/material-ui/pull/13651/commits
https://github.com/mui-org/material-ui/pull/13229/commits
https://github.com/mui-org/material-ui/pull/13238/commits
https://github.com/mui-org/material-ui/pull/13317/commits
https://github.com/mui-org/material-ui/pull/13350/commits
https://github.com/mui-org/material-ui/pull/13389/commits
https://github.com/mui-org/material-ui/pull/12955/commits
https://github.com/mui-org/material-ui/pull/12967/commits
https://github.com/mui-org/material-ui/pull/13012/commits
https://github.com/mui-org/material-ui/pull/13023/commits
https://github.com/mui-org/material-ui/pull/12673/commits
https://github.com/mui-org/material-ui/pull/12680/commits
https://github.com/mui-org/material-ui/pull/12725/commits
https://github.com/mui-org/material-ui/pull/12790/commits
https://github.com/mui-org/material-ui/pull/12848/commits
https://github.com/mui-org/material-ui/pull/12905/commits
https://github.com/mui-org/material-ui/pull/12454/commits
https://github.com/mui-org/material-ui/pull/12459/commits
https://github.com/mui-org/material-ui/pull/12533/commits
https://github.com/mui-org/material-ui/pull/12556/commits
https://github.com/mui-org/material-ui/pull/12590/commits
https://github.com/mui-org/material-ui/pull/12600/commits
https://github.com/mui-org/material-ui/pull/12601/commits
https://github.com/mui-org/material-ui/pull/12605/commits
https://github.com/mui-org/material-ui/pull/12638/commits
https://github.com/mui-org/material-ui/pull/12223/commits
https://github.com/mui-org/material-ui/pull/12295/commits
https://github.com/mui-org/material-ui/pull/12415/commits
https://github.com/mui-org/material-ui/pull/11931/commits
https://github.com/mui-org/material-ui/pull/11986/commits
https://github.com/mui-org/material-ui/pull/12026/commits
https://github.com/mui-org/material-ui/pull/12035/commits
https://github.com/mui-org/material-ui/pull/12147/commits
https://github.com/mui-org/material-ui/pull/11603/commits
https://github.com/mui-org/material-ui/pull/11613/commits
https://github.com/mui-org/material-ui/pull/11633/commits
https://github.com/mui-org/material-ui/pull/11691/commits
https://github.com/mui-org/material-ui/pull/11694/commits
https://github.com/mui-org/material-ui/pull/11728/commits
https://github.com/mui-org/material-ui/pull/11863/commits
https://github.com/mui-org/material-ui/pull/11357/commits
https://github.com/mui-org/material-ui/pull/11446/commits
https://github.com/mui-org/material-ui/pull/11449/commits
https://github.com/mui-org/material-ui/pull/11501/commits
https://github.com/mui-org/material-ui/pull/11519/commits
https://github.com/mui-org/material-ui/pull/11544/commits
https://github.com/mui-org/material-ui/pull/11582/commits
https://github.com/mui-org/material-ui/pull/11003/commits
https://github.com/mui-org/material-ui/pull/11031/commits
https://github.com/mui-org/material-ui/pull/11035/commits
https://github.com/mui-org/material-ui/pull/11211/commits
https://github.com/mui-org/material-ui/pull/11264/commits
https://github.com/mui-org/material-ui/pull/10703/commits
https://github.com/mui-org/material-ui/pull/10705/commits
https://github.com/mui-org/material-ui/pull/10807/commits
https://github.com/mui-org/material-ui/pull/10877/commits
https://github.com/mui-org/material-ui/pull/10936/commits
https://github.com/mui-org/material-ui/pull/10454/commits
https://github.com/mui-org/material-ui/pull/10470/commits
https://github.com/mui-org/material-ui/pull/10541/commits
https://github.com/mui-org/material-ui/pull/10578/commits
https://github.com/mui-org/material-ui/pull/10594/commits
https://github.com/mui-org/material-ui/pull/10629/commits
https://github.com/mui-org/material-ui/pull/10694/commits
https://github.com/mui-org/material-ui/pull/10328/commits
https://github.com/mui-org/material-ui/pull/10355/commits
https://github.com/mui-org/material-ui/pull/10408/commits
https://github.com/mui-org/material-ui/pull/10420/commits
https://github.com/mui-org/material-ui/pull/9955/commits
https://github.com/mui-org/material-ui/pull/9983/commits
https://github.com/mui-org/material-ui/pull/10023/commits
https://github.com/mui-org/material-ui/pull/10049/commits
https://github.com/mui-org/material-ui/pull/10084/commits
https://github.com/mui-org/material-ui/pull/10090/commits
https://github.com/mui-org/material-ui/pull/9729/commits
https://github.com/mui-org/material-ui/pull/9730/commits
https://github.com/mui-org/material-ui/pull/9796/commits
https://github.com/mui-org/material-ui/pull/9832/commits
https://github.com/mui-org/material-ui/pull/9862/commits
https://github.com/mui-org/material-ui/pull/9926/commits

Notes
With our methodology we will not find all builds with flaky test_browser because they are usually restarted manually from the CircleCI dashboard. Unless we can query failed CircleCI builds we have to sift PRs.
It also does not catch cancelled test_browser where test:karma failed but the job couldn't finish (should be very rare).
/cc @mui-org/core-contributors
Future work
Actual interactions should be tested in the browsers (e.g. keyboard a11y). I'm looking into cypress to test these more advanced scenarios.
TODO:

[ ] remove test_browser from required GitHub checks

On a side note, browser support for Jest is the most requested feature ever on the project.

Thanks for linking the Facebook link. When I read this section:

To cover browser testing we do a lot of things ranging from web driver tests, manual QA and especially employee dogfooding. These things have in general provided more value than a flaky browser test engine that is hard to scale for thousands of tests.

I'm wondering, how will we cover browser testing? I could think of adding Sentry on the documentation website, but most of our traffic comes from Chrome. Ultimately it will be GitHub issues and reactivity from our part?

Actual interactions should be tested in the browsers (e.g. keyboard a11y). I'm looking into cypress to test these more advanced scenarios.

I'm confused. Aren't the interaction tests the ones that are the flakiest? So is this about replacing karma with cypress then?

If the pain point is with flaky tests, I can think of a simple approach: automatic retries. We were facing this problem at Doctolib. hundreds of tests, a lot of flaky ones. In the first place, we have tried to make the test less flaky, but it was very time-consuming. At some point, we introduced 3 auto-retry while monitoring the tests that are retried the most often. It was the perfect soluting we needed at Doctolib. Is this something we can reproduce here? I only know two cases of flaky tests:

The browser stack tunnel is down
The SwipeableDrawer test fail.

cc @nathanmarks (who first introduced karma)

The whole point of all this data is  that we dont do browser integration tests at the moment. karma does not test anything jsdom doesnt test. Yes I am working on tests with cypress but those would be new tests. If your takeaway here is that we loose some testing then you havent looked at the data

I think I have been helped by karma twice most of the time it failed due to different css syntax or flaky tests. I think at the very least we could trial not having them. Nothing stops us from adding them back if we notice a regression.

Yeah if I say it doesnt do anything I mean the number of true positives is near zero. Compared with a high number of false positives it really hurts productivity

If your takeaway here is that we lose some testing then you haven't looked at the data

I'm not challenging what we lose but what we will gain. I'm challenging that cypress will be better than some of the other options we can try at a cheaper cost:

(browser stack flakiness) removing browser stack to only keep Chrome headless or add a retry logic on browser stack
(minimizing the number of tools) we already write integration tests with enzyme, in the future we can write them with react-testing-library. Unit and integration tests could be solved with the same tools.
(integration tests are flaky) cypress tests will be flaky too, we will need a retry logic no matter what?

@dmtrKovalenko works for Cypress, I'm sure you can provide his perspective (biased of course :p).

From my experience solving flaky tests at Doctolib, the problems were 50% of the time coming from tests not written correctly and 50% wrong core logic. Maybe investigating the flaky tests would be a valid direction too? I have seen one recently on a Menu timeout.

we already write integration tests with enzyme, in the future we can write them with react-testing-library. Unit and integration tests could be solved with the same tools.

I need to write it down at some point that this distinction makes no sense for a component library. Every component is a unit. There is not a single integration test here. Just unit tests with different APIs.

we already write integration tests with enzyme, in the future we can write them with react-testing-library.

The inherent issue with these is that they are designed for jsdom not an actual DOM. They are not fit for browser test because in a browser environment we don't mock events. We use the browser API for that.

cypress tests will be flaky too, we will need a retry logic no matter what?

Unsourced and therefore ignored from this argument.

options we can try at a cheaper cost:

Also: All of these still have karma in mind so the original statement seems still not accepted: Karma's value dwarfed by the reduction in productivity. The cost is multiple orders of magnitude higher than the value gained. That is what I'm expressing in this PR. Not that there are other options we explore. If we don't acknowledge this issue we don't have to explore other solutions.

I am working for Cypress only because it is the only tool, (really only) that allows not flaky tests for browser.
You know I am trying to integrate cypress for material-ui-pickers. And it works well, but still some troubles on making test environment. (Right now using a separate page for that https://material-ui-pickers.dev/regression). Want to try https://github.com/bahmutov/cypress-react-unit-test by @bahmutov.
But anyway Cypress is really good choise, Especially because of the entierly free plan for open-source. With included unlimited parallelization and test recordings.

Also: All of these still have karma in mind so the original statement seems still not accepted: Karma's value is dwarfed by the reduction in productivity. The cost is multiple orders of magnitude higher than the value gained. That is what I'm expressing in this PR. Not that there are other options we can explore. If we don't acknowledge this issue we don't have to explore other solutions.

It seems that we get to the bottom of it.
Do we agree that the core issue is flakiness, not anything else?
If I read your methodology correctly, we have a flakiness rate of +2%. We would like to go below 1%. If we agree, then I think that we should categories where these flaky tests come from. Having this data, we can then prioritize. If 80% of the flakiness comes from browserstack.  If 80% if the flakiness comes from the Menu or SwipeableDrawer tests, we can auto retry them. Problem solved.

@dmtrKovalenko Thanks for the feedback!

Removing it reduces the number of false positive failures

OK, I have only convered this one in my previous message

CI runtime in general

Removing browser stack would yield 80% of the value. At Doctolib, we killed it for this reason. It was initially introduced for screenrecording, but that was useless.

and just less code we have to maintain.

Cypress won't be less code to maintain

If I read your methodology correctly, we have a flakiness rate of +2%.

50% of the evaluated test failures were caused by flaky test.

If 80% of the flakiness comes from browserstack.

And what is the purpose of karma at that point? It's just running tests twice at that point.

I believe that removing browser stack would yield 80% of the value.

No data, no rationale provided. Also not part of this argument.

 If 80% if the flakiness comes from the Menu or SwipeableDrawer tests, we can auto retry them. Problem solved.

It will further reduce CI times only worsening the problem. It's not as easy as you think it is.

Will cypress be less code to maintain?

It's starting again. This is not the scope of the PR. Please don't move the goal post and stay on topic. I urge you again don't put your opinion on a pedestal and expect everyone else to come to you. What actual value does the karma test provide? And not just your believes or feelings but actual hard data. Do the extra work please and not just discredit the work of others.

50% of the evaluated test failures were caused by flaky test.

So over the last 6000 pull requests, we had 129 failures, and 50% of the failures were because of flakiness. So the current "flakiness rate" is 129 / 2 / 6000 = 1.075%. What number should we target? Is 1% a problem?

And what is the purpose of karma at that point? It's just running tests twice at that point.
What actual value does the karma test provide?

It provides the value that you have highlighted in the pull request description: "Actual interactions should be tested in the browsers" (Chrome headless).

No data, no rationale provided. Also not part of this argument.

Let's breakdown the "Tests real browsers" test. It takes 20s to build the assets. The ChromeHeadless takes about 10s. The BrowserStack tests take about 1 minute. Assuming there is another 10s of misc CPU done. The "Tests real browsers" task takes about 20 + 60 + 10 = 90s.
Now, if we remove BrowserStack, it should be 20 + 10 + 10 = 40s. We win 50s. It's an x2.25 speedup. Can we consider that 1:30 is slow?

It will further reduce CI times only worsening the problem. It's not as easy as you think it is.

Will it reduce CI times 1% of the time? Why will it worsen the problem?

This is not the scope of the PR.

Can we have a holistic view of the problems we solve? I believe that how we test interactions in the browsers is key to the issue, hence we should consider Cypress part of the solution.
We are navigating the scope of the tradeoffs available maximizing these dimensions:

Fast CI feedback loop
Low flakiness rate
Low Maintainer overhead (long term)
Low Cost of change (short term)
Avoid regression
Maximize test coverage

I would also add Jest as part of the equation. I belie that Karma is preventing us from using it. It worth mentioning.

Alright different proposal:
jsdom for "unit" tests i.e. the tests that live next to the component, karma for integration tests when jsdom is insufficient. It was a common pattern that I observed when I evaluated the failures: Some assertion was made based on jsdom implementations that don't hold up in the browser.
Basically let test:unit only run src/**/*.test.jsand let karma run ontest/**/*.test.js`. We kill test duplication between jsdom and actual DOM and avoid writing tests for the jsdom.

@eps1lon Do you have an example of this distinction between a unit and integration test?

I am sorry to getting into your discussion. But. I am sure that for the components library - any test that runs in the browser will be end-to-end. Anything else is integration and unit.
This is kinda philosophical theory - the distinction between test types :D

@eps1lon Do you have an example of this distinction between a unit and integration test?

I'm not a fan of this distinction for a component library. Because components are already a unit. Or the whole app if you think of it in terms of public vs. private.
My main concern is more that anything that heavily relies on jsdom should only run in the browser. Especially anything related to event dispatching tends be very far removed from what's actually happening in the browser.
I'd probably go with render1 output => jsdom tests, interactions => browser. And for browser test you can make some trade offs if you don't have the infra for actual e2e tests e.g. dispatch click events or keydown events.
1 Basically markdown only. Styles support is very limited in jsdom.

any test that runs in the browser will be end-to-end

As soon as you're using imperative DOM  APIs to act you're not doing e2e tests. The user isn't using the DOM API but the browsers. For example anytime you're writing a test where you dispatch a change event you no longer have a full picture of what's happening. In an actual e2e test you would click into the textfield and start typing.

From my perspective, we shouldn't make any distinction, we shouldn't make an empirical distinction between when a test should run in a browser or now. I think that the simplest option is to run everything in the browser. Our +2000 tests run in 10s in Chrome. It's nothing, we had 65 minutes of e2e tests at Doctolib, tests we had to split between 15 parallel workers.

we shouldn't make an empirical distinction between when a test should run in a browser or not.

We could do that but we still only have the jsdom. Until something better comes along what's important in the browser will always be brittle. The rest is redundant.
Still missing an argument for browser test. It's never been made theoretically nor empirically.

@eps1lon They shouldn't be any argument for browser test, we need them, it's not an option. The argument should be on: Is JSDOM good enough to approximate browser tests? Not always but does it worth it the tradeoff?
From my perspective, running the browser tests is a low hanging fruit. It doesn't cost much (<1% rate of flaky test right now, + the potential to improve it with retries).
We can't pick the same tradeoffs as Facebook without considering the context. We don't have the same canary release control as they have. They can deploy to 0.05% of the population, have instant bug feedback and revert. They can have 30k employees report problems on unreleased versions. We can't. We have significantly fewer tests than they have.
It also works on people psychology, you will feel safer seeing the library you depends on having tests in the browsers you want to support.

They shouldn't be any argument for browser test, we need them, it's not an option

Says who?

Our users?

I’ve been thinking about the browser test situation, I think we should probably keep them. Stuff like style specific testing should probably only be tested on jsdom or removed and the rest tested on actual browsers. As a UI library it makes sense to have browser tests.

There is probably a better test architecture that could deploy. There is no question that by investing more time, we could improve our tests.
However, I believe that we have now is good enough. I don't think that we should invest more time on it. Let's build more features instead.

Thanks, guys for the discussion!

Thanks, guys for the discussion!

There was none. There was evidence from me and some claims from other people that weren't justified. Dangerous precedent but maybe I can do the same.


codgen: verify custom element handling in containers

[x] By placing an X in the preceding checkbox, I verify that I am a PayPal employee or
I have signed the Contributor License Agreement

Add a test to verify custom element handling in containers
other minor cleanup in codegen

merged to v_1.2.0.. thanks!


Revisit docs

We have many docs, but they are inconsistent in level of detail, and are not organized into an approachable, navigable whole.
Let's revisit this, and ensure we have a curated, extremely useful set of user-focused docs. When possible, leverage existing docs for our recommended fuzzing tools (e.g. libFuzzer). Distinguish between the user scenarios of (1) instance admin, (2) non-specialist template-focused users, (3) users who will leverage customized tasks and the SDK.
AB#35963

Closing this as nebulous. We have had some specific targeted improvements to docs recently.


Create roadmap

Hi @iyobo, I think we need some roadmap to define project scope and features. The last one is necessary to prevent us from working on same issue simultaneously. I don’t have much time but I want to help with PR’s (if you want). Also I think it’s important to keep this project simple as now, but it need better documentation and existing features support.
The problem of other frameworks such as nestjs is their complexity. Not all projects need all this features, but really most rest API needs features provided by this project, such as input validation and injection of parameters.
I think this module has bright future after some polishing and popularization.
Regards, George

Done


improve ribbon performance(touch device)

touch device process ->
touchstart -> touchmove -> touchend
so add some judgment to avoid changing in every touch screen
targetA = judgment
touchstart => targetA = true
touchmove => if the touch have move, it ain't click screen, so it ain't to change ribbon. targetA = true | false
touchend => if targetA = true will change ribbon, on the contrary not to do.

Thanks!


feat!: remove the survey link

Before merging, need to confirm both of these suspicions:

Admin access to the Google form (and thus its results) were lost during the Axim/2U decoupling and subsequent edX->2U Google migration.

There is currently no desire by either Axim or 2U to recreate and manage the survey.

I'm asking if the form and data can be rescued.

(a test comment)

(this is another test comment.)

2U IT reports that they cannot retrieve the old form or data.

Thanks Ned. I'll ask the team today whether we want to make a new form, or just nix it.

Good news--we found the data, and it's still coming in, so turning off the survey is less urgent than I had thought.
I wrote up a follow-up task for the future: https://github.com/openedx/openedx-webhooks/issues/259


Fix 8074

An example fix for #8074.
Right now there are .show s on individual primitives but there's also the scene's primitives.show.
This fix treats the scene's primitive.show like a master switch and would be the simplest fix for this.
localhost sandcastle

Thanks for the pull request @loshjawrence!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

This fix treats the scene's primitive.show like a master switch and would be the simplest fix for this.

  So I assume that means this is the "right" fix?

@OmarShehata can you confirm everything is good on your end?
@lilleyse will you have time to look at this soon?

I can confirm this fixes the original issue, but you can still get this effect to happen by using tileset.show instead of scene.primitives.show. See this localhost Sandcastle as brought up here https://github.com/AnalyticalGraphicsInc/cesium/issues/8074#issuecomment-522562440.

@Omar I added @dennisadams other fix for this

Where are we at here.  @OmarShehata please merge if this is ready so it can sit in master before the release to make sure it fully fixes the problem.  CC @lilleyse any thoughts

Looks fine to me.

@OmarShehata please merge once you confirm the issue you could still reproduced is fixed.  Thanks!

Works great, thanks @loshjawrence !


Change version info in github action

Do this to make it clear that the github action job is a tester version.
Note we will probably want a separate job for exes that are formally released (releases and distributed fixes)

Thanks @kellijohnson-NOAA and @Rick-Methot-NOAA ! These are all great thoughts. I really like the idea of making more things automated.
I was thinking maybe everything would just be labeled experimental (maybe with the last commit number), unless it is tagged and in the main branch? That way, when we are ready to do a release, we can just add the tag manually, as we normally do (if it is a prerelease, maybe we put that in the tag?) and the github action will take care of the rest? This isn't quite as automated as what  Kelli is proposing, but I think it would basically allow us to work in the same way while automating this extra piece (the version numbering).

This would create a lot more MINOR and PATCH increments in between releases and it begs question of whether what we label as a "release" is automatically a MAJOR increment. So far, MAJOR is stuck at .30 and I do sometimes think about what would constitute .31. Conceptually, 4.0 will be FIMS, but I'll refrain from calling FIMS SS<IP_ADDRESS>

Good point...I wonder if bumping the major version would indicate to folks a big I/O change, which we (thankfully) haven't had? So perhaps given the way we have been doing versioning, it makes sense to be stuck at .30?

@Rick-Methot-NOAA , how should we implement this? Here are two options I am thinking about, but feel free to suggest another

by default, says experimental
In the files,

#V3.30.experimental; not an official version of SS;_safe;...

by default, says a placeholder, like 3.30.xx.yy.
In the files,

#V3.30.xx.yy;_safe;...

I think this matters because this is what would show up when compiling locally. I'm leaning towards 1, but what are your thoughts?

I already am doing something like (1), but using beta rather than
experimental.
3.30.17.beta
but should it be beta developments after .17
or 3.30.18beta   as a beta for .18 in development?
On Wed, Sep 8, 2021 at 12:46 PM Kathryn Doering @.***>
wrote:

@Rick-Methot-NOAA https://github.com/Rick-Methot-NOAA , how should we
implement this? Here are two options I am thinking about, but feel free to
suggest another

by default, says experimental
In the files,

#V3.30.experimental; not an official version of SS;_safe;...

by default, says a placeholder, like 3.30.xx.yy.
In the files,

#V3.30.xx.yy;_safe;...
I think this matters because this is what would show up when compiling
locally. I'm leaning towards 1, but what are your thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/202#issuecomment-915521296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPV4ICYYMW2ZNFYNW2PFS3UA64SXANCNFSM5C6HZZEQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Hmm, good point! I think leaving it as 3.30.17.beta makes sense given how we number fixes currently.
I was hoping to take all numbers except 3.30 out of the file  and have github actions automate the other numbers for us; but this would mean any locally compiled exes would be missing the .17 (it would either look like 3.30.beta or 3.30.xx.yy). Does this seem ok?
The other option is we could leave in the .17 and would just manually change the file upon every release. I don't like this as much, but we could do it.

3.30.beta seems very ambiguous if we are to send it to someone for testing.
Richard D. Methot Jr. Ph.D.NOAA Fisheries Senior Scientist for Stock
Assessments
Mobile:<PHONE_NUMBER>
On Wed, Sep 8, 2021 at 12:58 PM Kathryn Doering @.***>
wrote:

Hmm, good point! I think leaving it as 3.30.17.beta makes sense given how
we number fixes currently.
I was hoping to take all numbers except 3.30 out of the file and have
github actions automate the other numbers for us; but this would mean any
locally compiled exes would be missing the .17 (it would either look like
3.30.beta or 3.30.xx.yy). Does this seem ok?
The other option is we could leave in the .17 and would just manually
change the file upon every release. I don't like this as much, but we could
do it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/202#issuecomment-915528235,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPV4IHVL7R3WIPYSXGIMO3UA654VANCNFSM5C6HZZEQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

yes, that is true... I am thinking the github actions could add in the .17, since we more and more have been sending exes compiled by it?

...and the github actions would get this from the last tag in the repo, so wouldnt be hard coded anywhere.

Of course, this ended up being a bit more of a rabbit hole than expected! I have automatic versioning added in all the jobs except for the linux one (having some issues because I need to use centos 8 for a new version of git, but then admb will only work on centos 7. Still working to solve it).  This is done by editing the tpl file right before compiling based on the current commit and the last tag made. Here is how the automatic versioning works currently:

The line in the tpl is #v3.30.xx.yy. This is how it will look if you compile locally without modifying the file.
If the last commit made is tagged with the form v3.30.xx.yy, v3.30.xx, or v3.30.xx-prerel (for prereleases), this commit will be added to the version info. For example, if the last commit was tagged as v3.30.18, then the line in the version info would read #v<IP_ADDRESS>. If the tag is v3.30.18-prerel, then th line in the version info would read #v<IP_ADDRESS>-prerel.
If the last commit made is tagged with something of another form, "unknown" will be appended. For example, if the last commit was tagged as my_bad_tag , the line in the version info would read #v3.30.unknown.unknown we could change this if there was a valid reason for wanting to use other tags.
If the last commit made does not have a tag associated with it, only the .xx will be used from the last tag made, and beta will be appended. For example, if the last tag is v.<IP_ADDRESS>, but the tag is on an earlier commit than the current one, then the line in the version info would read #v3.30.17.beta

@Rick-Methot-NOAA , let me know if this needs any tweaks?
I will submit a PR once I figure out a solution to the centos build.

This seems quite complex if it needs to interact with tags.  Currently tags
are only added for releases.  So I am missing a piece of the logic.
The changes being proposed here seem to supercede the changes already in a
branch for adding DATE.   Has that branch already been merged into main?
On Fri, Sep 10, 2021 at 10:09 AM Kathryn Doering @.***>
wrote:

Of course, this ended up being a bit more of a rabbit hole than expected!
I have automatic versioning added in all the jobs except for the linux one
(having some issues because I need to use centos 8 for a new version of
git, but then admb will only work on centos 7. Still working to solve it).
This is done by editing the tpl file right before compiling based on the
current commit and the last tag made. Here is how the automatic versioning
works currently:

The line in the tpl is #v3.30.xx.yy. This is how it will look if
you compile locally without modifying the file.
If the last commit made is tagged with the form v3.30.xx.yy,
v3.30.xx, or v3.30.xx-prerel (for prereleases), this commit will be added
to the version info. For example, if the last commit was tagged as
v3.30.18, then the line in the version info would read #v<IP_ADDRESS>.
If the tag is v3.30.18-prerel, then th line in the version info would
read #v<IP_ADDRESS>-prerel.
If the last commit made is tagged with something of another form,
"unknown" will be appended. For example, if the last commit was tagged as
my_bad_tag , the line in the version info would read
#v3.30.unknown.unknown we could change this if there was a valid
reason for wanting to use other tags.
If the last commit made does not have a tag associated with it,
only the .xx will be used from the last tag made, and beta will be
appended. For example, if the last tag is v.<IP_ADDRESS>, but the tag is on
an earlier commit than the current one, then the line in the version info
would read #v3.30.17.beta

@Rick-Methot-NOAA https://github.com/Rick-Methot-NOAA , let me know if
this needs any tweaks?
I will submit a PR once I figure out a solution to the centos build.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/202#issuecomment-917067807,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPV4IDQECCHUN2QQFDSPP3UBI3TXANCNFSM5C6HZZEQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I'm thinking going forward we should also add some tags for any fixes that we post for the community? I did this for the last one (https://github.com/nmfs-stock-synthesis/stock-synthesis/releases/tag/v<IP_ADDRESS>).
My logic was we just call anything that we don't want to distribute to the community .beta, instead of giving a fix number. I think this is sort of what we are doing already. We could also append a last commit number, if that would be helpful.
I didn't change anything about the date formatting, just the version number. So unless the code for adding date also changes version number, I think this proposal is separate.
The changes are in a branch: https://github.com/nmfs-stock-synthesis/stock-synthesis/tree/gh_actions . Note I plan on cleaning this up (squashing commits), before submitting a pull request, as testing out things on github actions is a lot of trial and error.

Also, here is a link to a working file, that just builds the one windows exe: https://github.com/nmfs-stock-synthesis/stock-synthesis/blob/8a55415fc246d5c1845f1fe950ecdffc53e76144/.github/workflows/build-win-basic.yml . Pulling the information from tags is actually only 2 lines of code; most of what needed to be written was logic statments in R to format the version as desired.

agree with tagging things that are released to the community.
the code I am working now with Nathan and Max for predators should be
labelled beta.  Right?   But it is just to them and not to the public.
I have not been attentive to keeping a branch that is only fixes to
the last release separate from a branch that is implementing new features.
All are getting merged into main and it is getting released to public with
this co-mingling.
Richard D. Methot Jr. Ph.D.NOAA Fisheries Senior Scientist for Stock
Assessments
Mobile:<PHONE_NUMBER>
On Fri, Sep 10, 2021 at 11:31 AM Kathryn Doering @.***>
wrote:

Also, here is a link to a working file, that just builds the one windows
exe:
https://github.com/nmfs-stock-synthesis/stock-synthesis/blob/8a55415fc246d5c1845f1fe950ecdffc53e76144/.github/workflows/build-win-basic.yml
. Pulling the information from tags is actually only 2 lines of code; most
of what needed to be written was logic statments in R to format the version
as desired.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/202#issuecomment-917121646,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPV4IGHH4J5EMBXAJNNDJTUBJFINANCNFSM5C6HZZEQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

the code I am working now with Nathan and Max for predators should be
labelled beta.  Right?   But it is just to them and not to the public.

Yes, that is what I was thinking! And that is what would happen in the github action. Basically, if it is not tagged, it's labeled beta.

I have not been attentive to keeping a branch that is only fixes to
the last release separate from a branch that is implementing new features.
All are getting merged into main and it is getting released to public with
this co-mingling.

Yeah, I remember we discussed this a while back! I think it is ok as-is. We would need a lot more branches and rules on what to put where and how to merge them to keep everything separate. In my opinion, right now it isn't worth the extra effort at this moment. I think keeping new development in branches until we've tested it out a bit has gone a long way to make sure the new features are somewhat stable before they get into a fix incidentally.

I should add, the solution to getting the linux version was Johnoel was able to replace the admb 12.3 exe so that it would also work with gcc-8 (which was needed to get the linux job working in a centos 8 container). That solved the issue.


Connections to the Portal from Docker containers can't be upserted

Gateways started within a Docker container don't have access to the system's SMBios or any other identifiable parameters (such as a hostname) suitable to identify the Gateway for upserting (this is the idea of containers, after all)
By default, a containers hostname is its container ID:
jamil@Jamils-MacBook-Air:~ % docker run -it alpine uname -a
Linux 69361b814d9b 6.4.16-linuxkit #1 SMP PREEMPT Tue Oct 10 20:38:06 UTC 2023 aarch64 Linux
jamil@Jamils-MacBook-Air:~ % docker run -it alpine uname -a
Linux a39f13381d89 6.4.16-linuxkit #1 SMP PREEMPT Tue Oct 10 20:38:06 UTC 2023 aarch64 Linux

This means a new Gateway is created each time a Docker container is created, so the list of Gateways belonging to a particular Instance group grows unbounded if a Gateway with --restart=always is crash looping.
This creates a major usability issue with admins trying to understand which Gateways authorized which flows because authorizations are tied to the instances.
We may need another token or some form of state that can be used to identify Gateway instances for upsert

This is actually part of a larger issue -- anything running inside a Docker container can't be upserted unless we maintain some form of state to identify it.
UI clients don't have this issue because they maintain state.

The plan to solve this one is to introduce two options to fix the external ID:

CLI argument/ENV variable to pass it explicitly
Any generated value should be persisted in a file at well known location.

This way devops people that don't like to the a mess can either attach persistent volume or get identifier from a higher level environment.

Gotcha. If I'm understanding correctly -- the ID of the gateway instance will be supplied by the user? In that case, should we require this parameter at runtime if SMBios isn't available? Or perhaps just always require it and not rely on SMBios Should we enforce this ID parameter to be unique within an Account? Or just unique within the Instance Group?
I think the common case is that users will be expecting Gateway sessions to be sticky and reliably upserted.
Would the docs then be something like:
# Create a unique identifier for this gateway
id="$(uuidgen)"

# specify the instance group token
token=<token from portal>

# now launch a sticky gateway instance
firezone-gateway --token $token --id $id

cc @bmanifold

What happens if two gateways are started with the same id?  Does the last gateway to come online with that id win?

@bmanifold right now they both will join and receive all the messages (connection requests, ice_candidates, etc) which might break everything most likely or be called a feature hot-standby-gateways 🤣


Add kubernetes instructions to "Get started"

Documents a quick-start workflow for getting influxdb running locally in Kubernetes using minikube.
Closes #630.

this is awesome and a great first step!

this is awesome and a great first step!

YES!!!

This is a great start. I'll let you know when the Helm chart is ready 😀


Fix resin whisperer's build speed

About the PR

Title.
Why / Balance

Parity. Resin whisperer at hivelord build speed...marine nightmare
Technical details

Media

Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

<!--
no cl

Nvm this is in the component so I guess it works?

When close, it is regular hivelord speed; at distance it's slower.

good to know


Reuse Established Connection

Currently each function to query status (e.g. saltLevel, saltLevelPercent, waterUnits) makes a call to _get() and subsequently establishes a new server connection/login.  This not only makes querying multiple server status values time consuming, the vendor may identify this resource strain and take decisive action.
Is it possible to re-use an already established server connection to query every X number of seconds for updated status values, or is the connection forcibly closed after every server query?
Alternatively, a more conservative server resources approach might be to create class variables for each status value of interest, updating ALL of the class variables via a single call to _get() once they are determined stale.  The server call to "/Dashboard/UpdateFrequentData" already returns all possible status values.  Use this single call to update the class variables.
Perhaps 'staleness' could be given by a user defined value?  Function calls for each status value of interest (e.g. saltLevel, saltLevelPercent) would simply return the current value of the class variable (if not stale, else obtain new values from server).
Thank you for the effort given to this and I greatly look forward to a future HomeAssistant integration.

@mblauser Currently each function to query status (e.g. saltLevel, saltLevelPercent, waterUnits) makes a call to _get() and subsequently establishes a new server connection/login.

What I can do is add a function that returns all of the data as a dictionary so all you need to do is pull the correct data with the right keys. This would only use one request.

What I can do is add a function that returns all of the data as a dictionary so all you need to do is pull the correct data with the right keys. This would only use one request. Would that work for you?

That seems much more efficient.
I recently discovered your implementation for HACS which similarly employs a dictionary for attributes. Thank you for your efforts toward this development.

Solved in commit fa9dc39 by the introduction of the getData() function.
Thanks 👍


Custom Emoticons

Can we have a way to add custom emoticons?
I'd like to have smileys, like :) this, convert to either emoji or the IRCCloud emoji image replacements, but only on my end (I know I can already change it to send emoji by using Send With Style). Preferably, I'd like to manage this list myself.
Something like Send with Style, where I can enter a list of mappings would probably be perfect, so I can do something like this:
:-),: smiley:
;-),Kappa
This would change both what I type and what others type into the correct emoticon, but only on my end. Support for IRCCloud image replacements would be good, since I'm using Chrome.

The image replacements with proper naming are here btw: https://github.com/irccloud/emoji-cheat-sheet.com/tree/master/public/graphics/emojis

Do you have any particular emoticon / image set in your mind?
e.g. MSN emoticons

Sure, so here are the replacements I currently run:
http://i.imgur.com/XLTNqKU.png
All of the images are available here:
https://github.com/WebpageFX/emoji-cheat-sheet.com/tree/master/public/graphics/emojis

So if I understand you right,
you want to use these characters: <3, </3, 8), D:)
and turn them to: :heart:, :broken_heart:, :sunglasses:, :anguished:
You can already do this in SWS

If you want ALL emojis as shortcuts as <3 or :-), that's not possible because I'm not you can use turn :car: into (o_o)/////(o_o)

The problem with using SWS is that it will change it for not just me, but for everyone. Most of the people I chat with don't have emoji support yet, so I just want to change it on my screen, like the twitch emoticons in this plugin. Does that make sense? The only ones I want to change are the ones in the image above (text to image, not the other way round).

So you want to see :heart:, and others to see <3.
I'm a little busy right now but I can do this next week.
I want to add this set as a emoticon pack so other people can enjoy too.
If the code doesn't get big or complicated, I'll allow users to create their own emoticons. So people can make theirs and/or share :smiley:
Thanks for the suggestion :+1:

No problem, thanks for investing time in it, my own solution is very hacky :smile:
BTW, the Github I linked with images are the ones used by IRCCloud and a ton of other services, so they are good images to use.
Here's the json I use:
http://pastebin.com/raw/6BCjVNkK
And this is the html I use to render them:
var templateSmileys = ':name';

I also had to edit this function to make the regex work correctly. From testing done so far, this seems to work more or less:
function getWordRegex(key, opts) {   if (typeof opts === 'undefined') {     opts = 'g';   }   var t = new RegExp('(\\S)?' + escapeRegExp(key) + '(?!\\S)', opts);   return t; }

Don't worry, I'll take care all of these :)

Yeah, just wanted to give you the result of my experiments, so you didn't have to do double work :smile:
I'm quite sure you'll do a better job or I wouldn't suggest it here :wink:

Hey Simon, I have been busy so I didn't have chance to push the changes, here's a early preview:
Currently, it only supports online URLs, so you can't use local files.
Still you can use a private Gist URL to use your emoticon pack.
irccloud-emoticons.user.js
Don't forget to check irccloud-ext/emoticon-packs for additional emoticon packs.

Thanks for the hard work! You're the champ. I'll play around with it a bit and try to find you on IRC :+1:

Here's MSN emoticon pack, you can look at source code here

You need to add /msn/msn to Active Packs to enable MSN pack like below

(ignore discoloration on GIF)
I published your set as a custom pack so you can use this URL /simon in Settings

Seems to work awesomely here! Great job!

Then we can close this 😄


Rare and seemingly random crashes - 0xc0000005 (Access Violation)

Godot version:
3.1.1.stable.official
OS/device including version:
Windows 10 1903 (OS Build 18362.295)
Radeon VII (Windows Driver Store Version 26.20.13001.29010)
Issue description:
It's worth noting that this is a GLES 2 project, and that no other games crash like this.
Godot is crashing without any stack traces. Sometimes it takes a few minutes to crash, sometimes it takes ten, but more often than not it doesn't crash. I'm at a loss for what this could be but hopefully the files I've provided below can identify the issue, whether it be due to a bug or something I'm doing incorrectly.
Crash in export:
Faulting application name: Aquarius.exe, version: <IP_ADDRESS>, time stamp: 0x00000000
Faulting module name: Aquarius.exe, version: <IP_ADDRESS>, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00000000002d3194
Report Export.wer
Crash in editor:
Faulting application name: Godot.exe, version: <IP_ADDRESS>, time stamp: 0x00000000
Faulting module name: Godot.exe, version: <IP_ADDRESS>, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000001979478
Report Editor.wer
Steps to reproduce:
Unknown. Play the game until crash occurs. (Chance of crashing is less than 5%)
Minimal reproduction project:
Bug Hunting

I am unable to post the full project publicly but I can provide a cut down version if necessary.

Yeah, isolating the issue could be helpful.

I am unable to post the full project publicly but I can provide a cut down version if necessary.

Yeah, isolating the issue could be helpful.

Added the project.

Looks like the game has procedural generation. First time I tried it, it stuttered a lot and eventually froze. On three more tries, it worked perfectly and then ultimately froze again, spamming
ERROR: SelfList<class CollisionObject2DSW>::List::remove: Condition ' p_elem->_root != this ' is true.
   At: X:\Inne\Godot\Source\godot\core/self_list.h:83

into the console. Didn't crash for me (unless that freeze is a crash).
Tested in 093798c97

Tested in 093798c

Looks like a different bug on your end. Run the project in 3.1.1.

Well, in 3.1.1 I didn't have any crashes. Also I had a feeling there were more sharks swarming me :/
(fun game btw)

I was able to get additional information with WinDbg by following this guide:

0:016> lm
start             end                 module name
00000000`00010000 00000000`032d6000   godot_windows_opt_tools_64 T (export symbols)       C:\Godot\Godot.exe
. . .
0:016> ln 10000+1979478
Browse module
Set bu breakpoint
(00000000`001db160)   Godot!FT_Glyph_To_Bitmap+0x17ae318   |  (00000000`0220b340)   Godot!NvOptimusEnablement

Caught it! I was lucky enough to have the crash occur while debugging in WinDbg.

(8320.3840): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
godot_windows_opt_64!FT_CeilFix+0x49e113:
00000000`006143d3 488b5110        mov     rdx,qword ptr [rcx+10h] ds:feeefeee`feeefefe=????????????????
0:000> g
(8320.3840): Access violation - code c0000005 (!!! second chance !!!)
godot_windows_opt_64!FT_CeilFix+0x49e113:
00000000`006143d3 488b5110        mov     rdx,qword ptr [rcx+10h] ds:feeefeee`feeefefe=????????????????

Every time I resume the program it breaks and spams the errors above.

I receive the same crash when using dynamic fonts + bbcode.
Stack:
[0x0]   godot_windows_opt_64_mono!FT_CeilFix + 0xdd304
[0x1]   godot_windows_opt_64_mono!FT_CeilFix + 0x912214
[0x2]   godot_windows_opt_64_mono!FT_CeilFix + 0x11b5ca7
[0x3]   0x15a2bdb8
[0x4]   0x15a2bd13
[0x5]   0x159f9033
[0x6]   0x159f404b
[0x7]   0x159f3bc3
[0x8]   0x159f3ae2
[0x9]   0x159f0b1b
[0xa]   0x15a43a63
[0xb]   godot_windows_opt_64_mono + 0x3cfba
[0xc]   godot_windows_opt_64_mono + 0x142712
[0xd]   godot_windows_opt_64_mono + 0x14e381
[0xe]   godot_windows_opt_64_mono + 0x14e909
[0xf]   godot_windows_opt_64_mono!FT_Load_Glyph.constprop.824 + 0x5975
[0x10]   godot_windows_opt_64_mono!FT_CeilFix + 0xd92b93
[0x11]   godot_windows_opt_64_mono!FT_CeilFix + 0xa31911
[0x12]   godot_windows_opt_64_mono + 0x2b0e14
[0x13]   godot_windows_opt_64_mono!FT_CeilFix + 0xd3c2ea
[0x14]   godot_windows_opt_64_mono!FT_CeilFix + 0xd90c5c
[0x15]   godot_windows_opt_64_mono!FT_CeilFix + 0x14676f3
[0x16]   godot_windows_opt_64_mono!FT_CeilFix + 0x14df176
[0x17]   godot_windows_opt_64_mono!FT_CeilFix + 0x152ff03
[0x18]   godot_windows_opt_64_mono + 0x13c5
[0x19]   godot_windows_opt_64_mono + 0x14fb
[0x1a]   KERNEL32!BaseThreadInitThunk + 0x14
[0x1b]   ntdll!RtlUserThreadStart + 0x21

I am use Roboto-Black, the generic android font.  Changing the underlying font did not help.

I am use Roboto-Black, the generic android font. Changing the underlying font did not help.

Try setting Hinting to None in the DynamicFont. Does this fix the crash for you? I haven't crashed once since making this change.

I'll attempt it.
I just removed all dynamic fonts and let them be the default font.
The crash reproduced with a slightly different callstack:
[0x0]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0xa877d
[0x1]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x972b44
[0x2]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x1af0b87
[0x3]   0x1efc91d3
[0x4]   0x1efc90c3
[0x5]   0x1f030fbb
[0x6]   0x1efef9db
[0x7]   0x1efeeeb3
[0x8]   0x1efeec22
[0x9]   0x1efe9ab3
[0xa]   0x1efd5b84
[0xb]   Godot_v3_1_1_stable_mono_win64 + 0x3cfba
[0xc]   Godot_v3_1_1_stable_mono_win64 + 0x142712
[0xd]   Godot_v3_1_1_stable_mono_win64 + 0x14e381
[0xe]   Godot_v3_1_1_stable_mono_win64 + 0x14e909
[0xf]   Godot_v3_1_1_stable_mono_win64 + 0x2e1d49
[0x10]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x1e51ad0
[0x11]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0xf8f8b3
[0x12]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x12f0611
[0x13]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x1cdbf5
[0x14]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0xe2abfd
[0x15]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0xe71a24
[0x16]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x1f2f263
[0x17]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x201808f
[0x18]   Godot_v3_1_1_stable_mono_win64!FT_Glyph_To_Bitmap + 0x2107bd3
[0x19]   Godot_v3_1_1_stable_mono_win64 + 0x13c5
[0x1a]   Godot_v3_1_1_stable_mono_win64 + 0x152b
[0x1b]   KERNEL32!BaseThreadInitThunk + 0x14
[0x1c]   ntdll!RtlUserThreadStart + 0x21

Your issue may be a separate bug. My crashes happen(ed) much less frequently and in the non-Mono version of Godot.

I think you're correct.
Converted all fonts in the game to a non-hinted version. Same issue. Happens very often (every session 10sec to 1 min in) and randomly.  I don't see any pattern.

Fixed by replacing the font files.


ID - Onboarding

The following items, generally in order, must be completed to successfully onboard a receiver to ReportStream:

[ ] Added to organization.yml
[ ] Added to organizations-local.yml
[ ] Added to staging settings table
[ ] Added to prod settings table
[ ] Added at least one receiver
[ ] Added OKTA group to download site
[ ] Added customers to OKTA group for download site
[ ] Is customer contact made?
What doc format are we supporting for the receiver (HLV, CSV, other)? (Add comment below)
What transport(s) are we supporting for the receiver (SFTP, other)? (Add comment below)
[ ]  Got credentials?
[ ] Tested ELR connection locally?
[ ] Tested ELR connection from Azure?
[ ] Has the receiver accessed the download site?
[ ] Has the receiver been sent at least one test file?
[ ] Has the receiver signed off on file formatting?
[ ] Are there labs sending data?
[ ] Has the receiver confirmed receipt of the data?
[ ] Have the files processed successfully?
[ ] Are we in production?
[ ] Update customerStatus flag in production settings to active

fyi @MauriceReeves-usds @brick-green-agile6 @Adrian-Brewster @sarahnw

3/1: ID requested the following information from RS to initiate the onboarding process:
contact names, email addresses, and phone numbers
@MauriceReeves-usds shared the public key on 3/1


fatal error: concurrent map read and map write

Version: 2.11.0
Date: 2019-08-03T10:06:44Z
(also happens with 2.10)
2015-01-benthos-crash-stack.log
benthos_yaml.zip
I've attached what I'm sure is a pretty horrible yaml file that could be simplified. Its a process that reads some data from stdin, then uses subprocess a lot to retrieve data from a database (not postgres), find paths to documents and their types, convert the documents to normalized pdfs, concatenate them and write out a final pdf
What's interesting about this is that the crash occurs when logger level = INFO, but does not occur when logger level = DEBUG
I'm sure that's just random.
There's only one location where regex is used in the yaml file
I have not set any environment variables, so threads = 4 (also crashes with threads = 8, and threads = 1)
Also crashes when level=DEBUG and threads=1 ..
this might be helpful. This graph is what I expect
Resolved DAG: [[get_ca_customs_document_path get_us_backup_document_path get_us_customs_document_path get_us_tif_backup_document_path get_ca_backup_document_path] [convert_us_tif_backup_document_path_to_pdf] [write_final_output_pdf]]

I removed the regex from the config file, but the program still crashes with the same stack.

Hey @bkcsfi,
Taking a look. Would it be possible for you to also share the config snippets from: ./benthos_append_errors.yml#/pipeline/processors/0?
One thing that immediately stands out is that multiple parallel stages in your DAG are setting errors and warnings in their postmap stages. This is a problem as Benthos sets those values by overriding the previous value, whereas what you'd want in this case is to append to the previous value.
One potential solution to this would be to refactor so that each stage, if an error occurs, populates a namespaced field within errors, which would be an object. So for example, it might look like this:
{
  "errors": {
    "get_us_customs_document_path": [
      "foo", "bar", "baz"
    ]
  }
}

And your postmaps would look like this:
postmap_optional:
  errors.get_us_customs_document_path: errors

Then you can check for total error counts with this jmespath:
jmespath:
  query: 'length(values(errors)[]) > `0`'

Think I got it. It looks as though this was caused by the process_map processors that are nested within your DAG stages. They weren't correctly isolating their postmap stages so it opened up the possibility of race conditions versus parallel DAG stages. I've fixed the race condition in v2.11.1 so you shouldn't see the crash anymore. Can you give it a try?
Fixed: https://github.com/Jeffail/benthos/commit/b810be514147ac9d9b69ad129930f94c6d1531ce
Released: https://github.com/Jeffail/benthos/releases/tag/v2.11.1

Hi,
Thanks for the quick fix. Version 2.11.1 does work now w/o error. I tried variations of thread count and log level and it worked every time.
Also thanks for the suggestion on how to handle merging lists from dag stages into a single 'list'. I hit that issue with temporary_documents, your solution is much nicer than mine.