PLAT-104574: Apply ilib formatter to DateTimePicker (ilib date format)

Bring AM and PM strings from ilib resource by locale
Fix to display date format by locale

Enact-DCO-1.0-Signed-off-by: Baekwoo Jung<EMAIL_ADDRESS>

functionality covered by #317


Support TypeHandleFixupAttribute and MethodAddrFixupAttribute

The code adds TypeHandleFixup/MethodAddrFixup and abstraction for fixups. It is mostly straight-forward but testing is rather annoying:

The data blobs for fixups are pointer-size and therefore dependent on CPU architecture. I haven't found anything in ILAsm that is similar to ifdef so I have to conditionally include 32-bit or 64-bit copies. I suppose we'll need to deal with the fun that is indian-ness at some point.
Updating IL is quite annoying as I don't want to write test code in IL. I end up splitting the IL in two sections, and I compile the corresponding C# code into exe, ildasm it, and incrementally copy/paste the code that I want into the IL.
I need to use internal types such as FixupRuntimeTypeHandle / NativeCallable, so those need to be manually fixed up from my internal copy to the right reference System.Private.CoreLib

@MichalStrehovsky @jkotas PTAL
/cc @davidwrighton

Thanks for review! I believe I've addressed all feedbacks. Let me know if you have more feedback. Otherwise I plan to merge this EOD.


Improved footer design

Issue:

Hello @Dhiraj3118 thank you for your contribution. Someone already tried this design but I don't think it's that much of an improvement.


Stricter warnings and avoid warnings of external libs

This PR cleans the code a bit by introducing stricter warnings. Surprisingly, we had very few parts in our code that needed alteration.
TO-DO left: group includes and use #pragma GCC system_header instead of #pragma GCC diagnostic push/pop.

@jbmouret @Aneoshun is this OK for you? This will make us easier to follow good coding styles for the main code of robot_dart.


[kinetic] geometric_shapes source and devel branches fix.

Addresses https://github.com/ros/rosdistro/pull/12246#issuecomment-244250325

Thanks for the fast response.


Fix for Issue #775: Prevent Duplicate Import Statements in Generated Templates

This PR addresses issue #775, where duplicate import statements in generated templates caused go build to fail.
Changes Made:

Updated the template generator to check for existing import statements before adding new ones.
Added tests to ensure that import statements are only included once, even if explicitly imported in the template file.

With these changes, the generator will no longer produce duplicate import statements, ensuring successful builds.

Thanks a lot for for putting this together, but we realised that we needed to sort out the organisation of imports too, so we've implemented a fix for the imports more generally at https://github.com/a-h/templ/pull/793
It makes it so that there's only two imports - templ, and templruntime, so the generated code won't have magic imports that you can't see like io etc. Additionally, any missing imports will be added automatically.


SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.

This issue is closed but I still get it and the suggested way to resolve it does not work for me I still get the same error message.
SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
https://github.com/facebook/create-react-app/pull/8079

Please fill out the issue template.


Improve the codesandbox example display

Currenlty the codesandbox example does not show a nice search bar (in terms of design):

Wouldn't it be better to display two results only in a single line like for the other codesandbox examples?

It has been fixed: https://codesandbox.io/s/im-angularis-7xipe?file=/src/main.ts:0-48
could you confirm this is what you want?

Awesome!!!!


Highlight block interface handles

To help users know where they can place which blocks

Microsoft/pxt-blockly#11

Fixed


Update docs assets

I only left out holder.js since it results in black background. (@imsky)
/CC @cvrebert

I'll look into what's going on

@XhmikosR holder 2.9.2 should have this fixed. i tested it with a local build of bootstrap docs

Thanks I will have a look as soon as possible!
On Feb 28, 2016 00:01, "Ivan Malopinsky"<EMAIL_ADDRESS>wrote:

@XhmikosR https://github.com/XhmikosR holder 2.9.2 should have this
fixed. i tested it with a local build of bootstrap docs
—
Reply to this email directly or view it on GitHub
https://github.com/twbs/bootstrap/pull/19333#issuecomment-189735697.

@XhmikosR hold on, there's an issue with the BS docs code

@XhmikosR PR opened: https://github.com/twbs/bootstrap/pull/19336

Thanks I see now why it failed. I'll merge it when I'm at home.
On Feb 28, 2016 00:29, "Ivan Malopinsky"<EMAIL_ADDRESS>wrote:

@XhmikosR https://github.com/XhmikosR PR opened: #19336
https://github.com/twbs/bootstrap/pull/19336
—
Reply to this email directly or view it on GitHub
https://github.com/twbs/bootstrap/pull/19333#issuecomment-189739288.


Help using library

Hi there, I'm looking to add city/state autocomplete search to my app and this looks like the perfect library! Thanks for picking up where Algolia left off.
I'm having trouble integrating this with my stack. I'm using Rails with esbuild, if it matters.
If I copy-paste the <script> tag mentioned in the README I get the following error in the console. I'm running Safari v15.2.
SyntaxError: Unexpected keyword 'export'

If I try to use the dynamic import I get the following error in both Safari and Chrome.
Error: Dynamic require of<EMAIL_ADDRESS>is not supported

Is there some other configuration I am missing to getting it working?

Hey @joemasilotti thanks for the kind words and posting issue #1! And a legit issue, no less.

If I copy-paste the

I'm not sure how to set up the module type script, so I can't comment on that.
But for the CDN, if I use your new import script I get the following errors:
[Error] Load cannot follow more than 20 redirections
[Error] Cross-origin script load denied by Cross-Origin Resource Sharing policy.
[Error] Failed to load resource: Load cannot follow more than 20 redirections (re.places.core.js, line 0)
``

Where you able to get the minimal examples working?
On Wed, 16 Feb 2022, 8:56 am Joe Masilotti, @.***>
wrote:

I'm not sure how to set up the module type script, so I can't comment on
that.
But for the CDN, if I use your new import script I get the following
errors:
[Error] Load cannot follow more than 20 redirections
[Error] Cross-origin script load denied by Cross-Origin Resource Sharing policy.
[Error] Failed to load resource: Load cannot follow more than 20 redirections (re.places.core.js, line 0)
—
Reply to this email directly, view it on GitHub
https://github.com/theprojectsomething/re.places/issues/1#issuecomment-1040880164,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAM5YFGFVYDWLWY36OKCGATU3LK3NANCNFSM5OPOJAFQ
.
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.
You are receiving this because you commented.Message ID:
@.***>

Hi @joemasilotti I've just pushed an update that should (hopefully!) resolve your issue, can you try importing the latest version of the library using the following tag:
<script type="module" async src="https://cdn.jsdelivr.net/npm/re.places.js@0.1.3/re.places.js?global"></script>

You should then be able to use replaces in a standard script tag, no module wizardry required.
If you'd prefer to name the global variable something other than replaces (for semantics, beauty, whatever), you can specify it as a search parameter of the script src, e.g. global=groovynewname
I've updated the minimal example I put together for you to show this working: https://codepen.io/theprojectsomething/pen/eYeeNmE?editors=1010

Got it, thanks for the help!


Can I call Phalcon functions from my extension?

All in the header; "Can I call Phalcon functions from my extension?".

https://github.com/phalcon/zephir/issues/304


Add dashboard link to check run results

Now that there's a prototype in development for a v2-compatible Kashti, this gateway can be enhanced to include links to events/jobs in Kashti in the check run results sent to GitHub.
We can actually make this more general -- not Kashti specific.
If we allow operators to configure this gateway deployment with an optional URL template -- something like https://kashti.brigade2.io/events/{:event_id}/jobs/{:job_name}, then -- then they can fill in an appropriate URL template for any v2 compatible web-based UI / dashboard and this gateway can just make the proper substitutions.

Removing this from the v0.6.0 milestone because there's no urgency to this until some sort of web UI / dashboard exists. One does exist, but it's merely a prototype at this point.


promise returned by main(). reject on unexpected errors, resolve on expected errors

From https://github.com/thefrontside/bigtest/pull/627

The way that this was implemented was to catch all non MainErrors, but that felt not so great. It occurred to me that what might even be better would be to have the Promise returned from @effection/nodealways resolve on both successful exits _and_ onMainError` exits since these are still expected outcomes. Only on an unexpected error would the promise actually reject. This would have the benefit of allowing custom error handling of unexpected exits, but baked in handling of all expected exits. In other words, we would have been able to write this as:

import { CLI } from './cli';
import { main } from '@effection/node';
import { unexpectedExit } from './unexpected-exit';

main(CLI(process.argv.slice(2)))
  .catch(unexpectedExit);

From the perspective of the main() operation, it would be consider a successful exit when the operation either completes, or finishes with a MainError which indicates that the program raised the error. The only time the operation would fail would be on an unexpected error. Other things to consider:

Don't return a raw Context, but a Promise implementor that has a reference to the context. That way, when you install a catch handler, it erases the default catch handler, or when you install a then handler, it erases the default tach handler. That way, there is full control about what to do when the process resolves.

Makes sense to me 👍

@cowboyd is this something we want to tackle for v2?

@cowboyd is this something we want to tackle for v2?

Yeah, that would really clean things up, and I think it would also solve the "unhandled failure" problem we had seen before where unexpected errors get completely dropped on the floor because if main() returns a promise, and you don't have a catch handler, then it will get reported when an unexpected error happens.
Of course, if we just returned a promise and not a task, that would reduce the power of the caller, but maybe that's not a bad thing since main() really is intended to be a root entry point and nothing else.

Of course, if we just returned a promise and not a task, that would reduce the power of the caller, but maybe that's not a bad thing since main() really is intended to be a root entry point and nothing else.

Hmm, this is actually a pretty significant downside, IMO. I've actually used the fact that main returns a task from time to time. For example with our toString debugging, it's pretty useful.


support nested errors object

Nested errors object is provided in RHF since version v4
This component must also support it!
codesandbox: https://codesandbox.io/s/rhferror-support-nested-errors-object-bsm0e

@bluebill1049 Do you plan to export RHF's utils?
If RHF exports utils, we can reduce the amount of code.

wow! nice one @kotarella1110

actually let's deprecated this one! and create a new component in RHF!

I let you drive that 👍

actually let's deprecated this one! and create a new component in RHF!

amazing!!

actually let's deprecated this one! and create a new component in RHF!

amazing!!

You drive @kotarella1110 !

actually let's deprecated this one! and create a new component in RHF!

amazing!!

You drive @kotarella1110 !

OK! I will.

few suggestions:

remove default  tag, just <>{message}</>
let's support render Props {(msg) => msg}, so it's more flexible
still support as

going to close this PR here :)


[NSThread] Implement name property

On Darwin, this calls a pthread non-posix API (pthread_setname_np) to give the name to the pthread library for debugging purposes. Is there an equivalent we can use on other platforms?

That was my initial plan for the implementation, but seeing Darwins pthread_setname_np and pthread_getname_np not having a pthread_t parameter I wasn't quite sure how to implement it correctly.
Linux equivalents are:
int pthread_setname_np(pthread_t thread, const char *name);
int pthread_getname_np(pthread_t thread, char *name, size_t len);

On Darwin, the current thread is the implicit argument. We actually only set the name in pthread if the current thread is the same as the NSThread receiver.

@parkera Implemented your suggestion.

Cool! Is it possible to get a test case along with this?

@parkera somehow pthread_setname_np and pthread_getname_np aren't found on Ubuntu? Do you have any ideas?

I believe those are darwin-only extensions. Is there anything equivalent in the pthread library on used on ubuntu?

@parkera I got it working on Ubuntu, the only problem was they weren't found in Swift. Calling the function form CoreFoundation fixed the problem.

Done

Should I add a test to the test case, to see if the pthread name is set correctly?

Sure, that'd be useful.

Should I use const char* or CFStringRef in CF, e.g.
CF_SWIFT_EXPORT const char* _CFThreadGetName();
or:
CF_SWIFT_EXPORT CFStringRef  _CFThreadGetName();

Generally we like to use the CF types for CF API. So CFStringRef

Sorry, I couldn't quite get CFStringRef to work right so I used the other approach, hope thats fine. Also I have one question: Why should those function be decorated with CF_SWIFT_EXPORT, when all other _CFThread functions are marked with CF_EXPORT?

@parkera could you test?

Sure, sorry about that.

@swift-ci please test

@parkera I did some small improvements and cleanups to the test code. Could you review and test, please?

@swift-ci please test and merge


Update README.md

Fix a typo in README file

I don't think I am going to sign any of additional agreements, so I am closing this.


ImportError: cannot import name 'format_date'

Details

Project URL: http://oidcp.readthedocs.io/en/latest/
Build URL (if applicable): https://readthedocs.org/projects/oidcp/builds/5089159/
Read the Docs username (if applicable): decentral1se

Expected Result
My docs would build.
Here's my pinned dependency list which I have configured to install in the 'Advanced Configuration'.
I was able to build on Sphinx 1.5.2, is this an issue with 1.5.3?
Actual Result
 Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/bin/sphinx-build", line 11, in <module>
    sys.exit(main())
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/lib/python3.5/site-packages/sphinx/__init__.py", line 51, in main
    sys.exit(build_main(argv))
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/lib/python3.5/site-packages/sphinx/__init__.py", line 61, in build_main
    from sphinx import cmdline
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/lib/python3.5/site-packages/sphinx/cmdline.py", line 23, in <module>
    from sphinx.application import Sphinx
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/lib/python3.5/site-packages/sphinx/application.py", line 38, in <module>
    from sphinx.environment import BuildEnvironment, SphinxStandaloneReader
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/lib/python3.5/site-packages/sphinx/environment/__init__.py", line 33, in <module>
    from sphinx.io import SphinxStandaloneReader, SphinxDummyWriter, SphinxFileInput
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/lib/python3.5/site-packages/sphinx/io.py", line 16, in <module>
    from sphinx.transforms import (
  File "/home/docs/checkouts/readthedocs.org/user_builds/oidcp/envs/latest/lib/python3.5/site-packages/sphinx/transforms/__init__.py", line 18, in <module>
    from sphinx.util.i18n import format_date
ImportError: cannot import name 'format_date'

Mmm... It's seems to be something else, since I can do that in a local-isolated virtualenv with Sphinx 1.5.3
(tmp-33534d18a9c45825) [11:19] humitos: tmp-33534d18a9c45825> python
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sphinx.util.i18n import format_date
>>> import sphinx
>>> sphinx.__version__
'1.5.3'
>>>

and
(tmp-9e048896320f583b) [11:19] humitos: tmp-9e048896320f583b> python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sphinx.util.i18n import format_date
>>> import sphinx
>>> sphinx.__version__
'1.5.3'
>>>

Marking this as a bug since I was able to reproduce it in my local venv without problems.

I was able to build the documentation by using my local development instance with docker build. So, it seems to be something related with the server.
Another idea that I have is that it could happen that you env on RTD uses a different version of Sphinx and then you updated it and now there is a conflict with some old .pyc files. Maybe we can fix that by doing a Wipe of that version and re-build?
@lwm can you try that?

Maybe we can fix that by doing a Wipe of that version and re-build?

That did the trick! Clean build on the go now :beers:
Thanks for taking a look at this @humitos. Much appreciated.


Modify the doc

php artisan optimize has been removed from laravel 5.6

@barryvdh readme has already been updated, issue can be closed :}


consensus_encode should return the written length

I think this can be closed with https://github.com/rust-bitcoin/rust-bitcoin/pull/265.


Spherical obstacles

Implement spherical obstacles types, microbe-surface interactions (sticking, gliding, bouncing...), routines for standard usage, and provide examples

bounce! is wrong, not priority now but needs to be re-implemented

first results look nice (here using glide!)

might need review to deal with cases where the microbe can get stuck in between 2 spheres


No more FOUC!

Definitely fixes the flash of unstyled content but now the font doesn't load at all for me (trying on the heroku deploy -- I'll try again locally).

before
after

I am a fan, but 🤷♂

There are arguments against inlining fonts, but I don't think we're going to be too affected by this.
Our initial HTML request balloons to a larger size, but it'll be smaller once it's gzipped by the production server (heroku doesn't do gzipping for us).
Do you have any thoughts, @timarney?

Visually yes this is better (good connection + newer devices).
Looks like at least on Heroku this seems to add roughly 3 secs to the load time.
And we still get dinged this this error (not too concerned but noting)

Given the work we've done to get the bundle size down the fonts being loading in raw are bigger than the bundle now (not due to this PR).
Would be nice to get them loading outside of the bundle to take advantage of HTTP2 which we have on the live server.
Didn't look over these but might be worth looking here:
https://github.com/zachleat/web-font-loading-recipes

Reverted back to preloading fonts


Fix for anonymous typed functions

Now tests like q"(..$params) => $expr" are passing successfully.

The test failure is spurious, so we shouldn't worry much about it - I'll test everything manually before merging.

@Dveim Could you sign https://www.typesafe.com/contribute/cla/scala, so that we could get going? In order to facilitate our collaboration, I didn't mention that in the first PR that you submitted, but this time let's do it right.

Done.
2015-07-04 10:28 GMT+03:00 Eugene Burmako<EMAIL_ADDRESS>
@Dveim https://github.com/Dveim Could you sign
https://www.typesafe.com/contribute/cla/scala, so that we could get
going? In order to facilitate our collaboration, I didn't mention that in
the first PR that you submitted, but this time let's do it right.
—
Reply to this email directly or view it on GitHub
https://github.com/scalameta/scalameta/pull/187#issuecomment-118479196.

@Dveim Congrats with the first complicated pull request! I've added some comments to your code. After you address them, could you rebase the PR so that it has only one commit per piece of functionality + so that all commits have sharp titles and descriptions that briefly motivate them?

Sorry, I broke whole structure with git rebase. I'll repair it and make new PR soon.


Drop Events only when certain conditions are met

Is your feature request related to a problem? Please describe.
The new drop processor drops all Events, but Data Prepper currently doesn't support any form of conditionals. Thus, the drop processor probably has little value in 1.3.0.
Describe the solution you'd like
The upcoming #1007 Conditional Routing feature is targeted for 1.4.0 and may only cover Sinks then. However, expression parsing ( #1003 ) will be available in 1.3.0. The drop processor should have its own custom conditional support for dropping events. I propose adding a drop_when condition that only drops events meeting a given condition.
For example, to drop all successful HTTP responses.
drop:
  drop_when: "/status_code < 400"

Describe alternatives you've considered (Optional)
Using the #522 conditional logic would be reasonable. However, Data Prepper efforts are being re-oriented toward Conditional Routing of sinks. And we may reconsider the approach taken for processors.

This seems reasonable and straight forward to implement once the expression parsing falls into place. We may want to go ahead and implement #816 - Add percentage support - to the drop processor while we are in there. I can see it having value to customers who want a sampling of say error messages but not necessarily want every event sunk.

Closing this issue in favor of #1105.


Syntax Error

Trying to enable a plugin but an error is  appears

This plugin only works on Blender version 3.2 or higher, which uses a later version of python that supports match syntax. Please update your Blender version to at least 3.2 and try again!

hi im trying to get the plugin on blender but all i get when it open up on roblox is Internal client error.
No module named 'pyjwt_key_fetcher' can you help me please

hi im trying to get the plugin on blender but all i get when it open up on roblox is Internal client error. No module named 'pyjwt_key_fetcher' can you help me please

Please add your comment to this other more relevant issue, and follow the debugging steps I added as a reply: https://github.com/Roblox/roblox-blender-plugin/issues/14


Doesn't work with cyrillic symbols

Maybe I need to configure PAPI? Anyways, it's confusing

What are you trying to put in the join mesage?

What are you trying to put in the join mesage?

&e%player% приспичило посрать &6[+]

Don't translate this phrase btw 💀


I18nProvider: create new Context

Consider this PR more of a discussion than a statement.
We've talked in the past about the annoyance of certain props that exist only to get translations for common strings, like Sheet's accessibilityDismissButtonLabel, SearchField's accessibilityClearButtonLabel, etc. This PR creates a new Context to attempt to solve this issue: we provide translations for these strings at the root level of the app, then read that context to get the string value within the component. This will allow us to remove existing props and obviate the need for new ones for new features/components.
The shape of the Context value is just a suggestion. I think most of these annoying props are at the base level of component APIs (not a field on a prop), but if that assumption doesn't prove true then we'll need to revisit the Context value shape to accommodate those nested translations.
I'm making some assumptions about how we handle translations in Pinboard that I'd love confirmation or (or tell me I'm wrong please!). I'm assuming I can do something like this in Pinboard:
// GestaltI18nProvider.js
import { I18nProvider } from 'gestalt';
import useI18n from 'app/packages/i18n/useI18n';

export default function GestaltI18nProvider({ children }) {
  const i18n = useI18n();
  const translations = {
    Text: {
      accessibilityShowPasswordLabel: i18n._('Show password', ...),
      accessibilityHidePasswordLabel: i18n._('Hide password', ...),
    },
  };

  return (
    <I18nProvider value={translations}>
      {children}
    </I18nProvider>
  );
}

// App.js
import GestaltI18nProvider from './GestaltI18nProvider';

function App({ children }) {
  return (
    <GestaltI18nProvider>{children}</GestaltI18nProvider>
  );
}

This PR creates a new Context to attempt to solve this issue: we provide translations for these strings at the root level of the app, then read that context to get the string value within the component. This will allow us to remove existing props and obviate the need for new ones for new features/components.

Is the idea here that we would insert all translations at the root of the app for the various accessibilityLabels we have in the app?  i.e. let's say a certain tree has 4 Sheet components, each one currently needing its own accessibilityDismissButtonLabel prop.  Would this approach mean that we use the same label for each one of those instances or would we inject all four different translations at the root of the tree?
Based on the changes in this PR, my assumption is the former (all Sheets use the same accessibilityDismissButtonLabel value) but I wonder if that would still allow us to provide a good experience from an accessibility perspective?

This PR creates a new Context to attempt to solve this issue: we provide translations for these strings at the root level of the app, then read that context to get the string value within the component. This will allow us to remove existing props and obviate the need for new ones for new features/components.

Is the idea here that we would insert all translations at the root of the app for the various accessibilityLabels we have in the app? i.e. let's say a certain tree has 4 Sheet components, each one currently needing its own accessibilityDismissButtonLabel prop. Would this approach mean that we use the same label for each one of those instances or would we inject all four different translations at the root of the tree?
Based on the changes in this PR, my assumption is the former (all Sheets use the same accessibilityDismissButtonLabel value) but I wonder if that would still allow us to provide a good experience from an accessibility perspective?

That's the idea, yeah. This wouldn't replace every accessibility label, just the ones that will always be the same (e.g. "Close modal", "Show password", etc). The goal is to reduce the prop burden at each individual callsite where possible.
There's also nothing precluding us from overriding these values and treating the Context translations as a default, allowing for more specific labels where helpful. If the component both registers a label with this Context and accepts an optional prop value, we could make (translated) "Close modal" the default if no prop is provided, but allow setting "Close PinBuilder modal" at the callsite.

This PR creates a new Context to attempt to solve this issue: we provide translations for these strings at the root level of the app, then read that context to get the string value within the component. This will allow us to remove existing props and obviate the need for new ones for new features/components.

Is the idea here that we would insert all translations at the root of the app for the various accessibilityLabels we have in the app? i.e. let's say a certain tree has 4 Sheet components, each one currently needing its own accessibilityDismissButtonLabel prop. Would this approach mean that we use the same label for each one of those instances or would we inject all four different translations at the root of the tree?
Based on the changes in this PR, my assumption is the former (all Sheets use the same accessibilityDismissButtonLabel value) but I wonder if that would still allow us to provide a good experience from an accessibility perspective?

Not all accessibility labels would go here. Just some accessibility labels that  could all be the same text. For example, we are planning on adding an appendix to the accessibilityLabels in  Links that are external that would say "opens in an external link". That labels should be identical in all Links, and the regular engineers shouldn't worry about adding an extra prop. This solutions let us handle a few cases like this were we can built the labels in for free, and handle their translations.

That's the idea, yeah. This wouldn't replace every accessibility label, just the ones that will always be the same (e.g. "Close modal", "Show password", etc). The goal is to reduce the prop burden at each individual callsite where possible.

There's also nothing precluding us from overriding these values and treating the Context translations as a default, allowing for more specific labels where helpful. If the component both registers a label with this Context and accepts an optional prop value, we could make (translated) "Close modal" the default if no prop is provided, but allow setting "Close PinBuilder modal" at the callsite.

Not all accessibility labels would go here. Just some accessibility labels that could/should all be the same. For example, we are planning on adding an appendix to the accessibilityLabels in Links that are external that would say "opens in an external link". That labels "apendix" should be identical in all Links, and the regular engineers shouldn't worry about adding an extra prop. This solutions let us handle a few cases like this were we can built the labels in for free, and handle their translations.

Gotcha, thanks for the clarification.  I like the idea of treating these more as "default" values and allowing callsites to override since that provides consumers the flexibility of giving a component a more specific label.
The approach here should be fine with how we handle translations in Pinboard.  We're actively trying to move away from front-loading translations in the App (part of the reason for my question) but given the total number of translations this would likely have, I think that's okay.


Feature: Statistics

Description
Now there's content in the database, can we get statistics about the scripts. What are the most popular demons, minions etc?

patters created some interesting stats from the NRB scripts

Some things I'd still like to add here:
Would be good if we could display a table of scripts for each character at /script/
That could also include stats about the character such as most popular partnerships and least popular partnerships.
The general stats page could also still have a distribution of num Demons and num Minions etc, but there's no easy way to do this in the database without a lot of work.

These have pretty much all been implemented now. New statistics should be raised as a new feature request.


Ability to view allergy

🚀 Feature Proposal
Currently, the list of allergies are not clickable. This issue is to make them clickable and create a component that allows a user to view the allergy.
Technical notes

the routing should work similar to how care plan routes work

@jackcmeyer if this issue is still available I can do it

If this is still available, I would like to take a shot. Could you assign me?

@gdemu13 I've assigned this to you.


Inference on video

Hi, Thanks for the amazing work. I was wondering if there is a way to test it on user-passed video as input. Please highlight the steps to run inference.
Thanks.

I'd also be interested in this, I tried to use the existing code to run one of my own videos, but the results were basically noise - hopefully I just did something wrong!

@danielcrane just use transnet v2, it's very easy to use the pytorch version

@danielcrane just use transnet v2, it's very easy to use the pytorch version

@eisneim Indeed yes I'm currently making use of that, it's very good, just wanted to test performance differences!

@danielcrane just use transnet v2, it's very easy to use the pytorch version

@eisneim Indeed yes I'm currently making use of that, it's very good, just wanted to test performance differences!

well I use transnet v2 and autoshot both for my own dataset , but I find noise and misjudge for gradual transition ,do you know how to fix it?

@lrbk for long transitions i found no solutions, so what i did is cut them manually;  but for the most part TransnetV2 is saving me a lot time

@lrbk for long transitions i found no solutions, so what i did is cut them manually; but for the most part TransnetV2 is saving me a lot time

@eisneim I follow the training instruction of TransNetV2, but i found some problem with gin and its config parameters.Could you tell me which version of gin and other library you used?

@lrbk i didn't do any training, just use the pretrained weights

@lrbk for long transitions i found no solutions, so what i did is cut them manually; but for the most part TransnetV2 is saving me a lot time

@eisneim I follow the training instruction of TransNetV2, but i found some problem with gin and its config parameters.Could you tell me which version of gin and other library you used?

Hello, I am also trying to copy the training of transnetv2. Have you succeeded? Are there any special configurations that need to be paid attention to?

i didn't do any training, just use the pretrained weights

i didn't do any training, just use the pretrained weights to find cut point and divide the video into small parts


fix Behat Tests

Hi @kilip ,
Behat tests are currently failing. Can you take a look please.

@kilip Also please drop some explanation, what the logs are supposed to contain.
In the latest build there are three logs from /build/behat/*.log that just contain the html of the start page, but no information about which scenario they belong to or what was expected....
Same for the screenshots...

@kilip do you know when you can do this task?

@TiSiE failed scenario already reported in the end of behat tests:
https://travis-ci.org/cross-solution/YAWIK/builds/285696741#L1447

Thank you!


Updating to laravel 5.2.8 multi authentication not working

hi,
Today i've update my laravel version to 5.2.8 and made the multi authentication not working. I revert to 5.2.7 it's working perfectly.
here is my auth:
'guards' => [
        'client' => [
            'driver'   => 'session',
            'provider' => 'users',
        ],

        'admin' => [
            'driver'   => 'session',
            'provider' => 'admins'
        ],
]

'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model'  => App\User::class,
        ],

        'admins' => [
            'driver' => 'eloquent',
            'model'  => App\Admin::class,
        ],
]

My Controller
$auth = auth()->guard('admin');
if ($auth->attempt(['email' => $request->email, 'password' => $request->password])) {

And i got this error:

Is this a bug or i make a mistake?

what is auth() outputting?

as in if you run
dd(auth());

and does Auth::guard() work?

Default working perfectly. But if I specify it with guards name it became error .

I add 2 image for the dd result. is it enough? because the result is too long.

@ssuhat can you please send me entire working code.
I have been trying to implement but laravel is not creating session for my admin table. https://github.com/laravel/framework/issues/11831 here's my code. please correct me if I'm doing it wrong.

hi @imrealashu i've update my above code. you can use it. :)

@ssuhat did you see any errors in my issue. Please have a look.

@imrealashu what laravel version (5.2.*) are you using? if you using like mine (5.2.8), you not alone.
and i make the authentication from scratch instead of using laravel provide.

I'm using 5.2.8 and default laravel's authentication still not working. I will use yours. Thanks :+1:

Fixed in 5.2.10.

@taylorotwell
For user table, After authentication Auth::user() return json of logged in user. But if authenticated from another table lets say admin then its not returning any json.

I've resolved it.
If you're authenticating from admin table then use admin guard to get logged in admin's details.
e.g.,
Auth::guard('admin')->user() will return logged in admin's json.

@ssuhat I've done it here. http://stackoverflow.com/questions/34614753/can-anyone-explain-laravel-5-2-multi-auth-with-example/34783443#34783443 you can use default AuthController to authenticate Admin.

hi whatsup :)


Debugger adapter crashes in print completions

OS: arch linux (rolling release)
VSCode version:  1.73.1 (commit<PHONE_NUMBER>f055b99068d3688932416f2346dd3b)
CodeLLDB version: 1.7.0
Compiler: gcc 12.2.0
Debuggee: native c++
The adapter crashes consistently every time whenever I try to print something through the VSCode's Debug Console. Practically, crashes as soon as the p is typed, followed by the space. The stacktrace suggests that command completion fails.

Verbose log
configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'Debug',
  program: '${workspaceFolder}/build/tests/clsc_tests',
  args: [ '--gtest_filter=*simple_tokens/besc_parser_tests.all/IDENTIFIER*' ],
  cwd: '${workspaceFolder}',
  __configurationTarget: 6,
  relativePathBase: '/home/ag/clsc'
}
liblldb: /home/ag/.vscode-oss/extensions/vadimcn.vscode-lldb-1.7.0/lldb/lib/liblldb.so
environment: {}
params: { evaluateForHovers: true, commandCompletions: true }
[2022-12-01T21:55:17.391Z DEBUG codelldb] New debug session
INFO(Python) 22:55:17 formatters: Initializing
INFO(Python) 22:55:17 formatters.rust: Initializing
[2022-12-01T21:55:17.538Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Code - OSS","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true,"supportsMemoryReferences":true,"supportsArgsCanBeInterpretedByShell":true},"type":"request","seq":1}
[2022-12-01T21:55:17.538Z DEBUG codelldb::dap_codec] <-- {"seq":1,"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true,"supportsWriteMemoryRequest":true}}
[2022-12-01T21:55:17.544Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Debug","program":"/home/ag/clsc/build/tests/clsc_tests","args":["--gtest_filter=*simple_tokens/besc_parser_tests.all/IDENTIFIER*"],"cwd":"/home/ag/clsc","__configurationTarget":6,"relativePathBase":"/home/ag/clsc","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null,"evaluateForHovers":true,"commandCompletions":true,"reproducer":false},"__sessionId":"f3bb07d4-52a4-4f90-af8e-613df01ad222"},"type":"request","seq":2}
[2022-12-01T21:55:17.545Z DEBUG codelldb::dap_codec] <-- {"seq":2,"type":"event","event":"capabilities","body":{"capabilities":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true,"supportsWriteMemoryRequest":true}}}
[2022-12-01T21:55:17.545Z DEBUG codelldb::dap_codec] <-- {"seq":3,"type":"event","event":"output","body":{"output":"Console is in 'commands' mode, prefix expressions with '?'.\n"}}
[2022-12-01T21:55:17.598Z DEBUG codelldb::debug_session] Debug event: 0x556fe67d7c20 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {clsc_tests}
[2022-12-01T21:55:17.598Z DEBUG codelldb::dap_codec] <-- {"seq":4,"type":"event","event":"initialized"}
[2022-12-01T21:55:17.599Z DEBUG codelldb::dap_codec] <-- {"seq":5,"type":"event","event":"module","body":{"module":{"addressRange":"FFFFFFFFFFFFFFFF","id":"FFFFFFFFFFFFFFFF","name":"clsc_tests","path":"/home/ag/clsc/build/tests/clsc_tests","symbolFilePath":"/home/ag/clsc/build/tests/clsc_tests","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:17.599Z DEBUG codelldb::dap_codec] <-- {"seq":6,"type":"request","command":"runInTerminal","arguments":{"args":["/home/ag/.vscode-oss/extensions/vadimcn.vscode-lldb-1.7.0/adapter/codelldb","terminal-agent","--connect=34517"],"cwd":"","kind":"integrated","title":"Debug"}}
[2022-12-01T21:55:17.607Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"algorithm_tests.cpp","path":"/home/ag/clsc/tests/algorithm_tests.cpp"},"lines":[186],"breakpoints":[{"line":186}],"sourceModified":false},"type":"request","seq":3}
[2022-12-01T21:55:17.610Z DEBUG codelldb::debug_session] Debug event: 0x556fe73bbd60 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.610Z DEBUG codelldb::dap_codec] <-- {"seq":7,"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":188,"message":"Resolved locations: 0","verified":true}]}}
[2022-12-01T21:55:17.610Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"besc_parser.cpp","path":"/home/ag/clsc/bes/besc_parser.cpp"},"lines":[602,607,615],"breakpoints":[{"line":602},{"line":607},{"line":615}],"sourceModified":false},"type":"request","seq":4}
[2022-12-01T21:55:17.610Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"besc_tests.cpp","path":"/home/ag/clsc/tests/besc_tests.cpp"},"lines":[214],"breakpoints":[{"line":214}],"sourceModified":false},"type":"request","seq":5}
[2022-12-01T21:55:17.610Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":6}
[2022-12-01T21:55:17.610Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":7}
[2022-12-01T21:55:17.610Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":8}
[2022-12-01T21:55:17.612Z DEBUG codelldb::debug_session] Debug event: 0x556fe7416c50 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.612Z DEBUG codelldb::dap_codec] <-- {"seq":8,"type":"response","request_seq":4,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":2,"line":602,"message":"Resolved locations: 0","verified":true},{"id":3,"line":607,"message":"Resolved locations: 0","verified":true},{"id":4,"line":615,"message":"Resolved locations: 0","verified":true}]}}
[2022-12-01T21:55:17.614Z DEBUG codelldb::debug_session] Debug event: 0x7f4e9c001b30 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.614Z DEBUG codelldb::debug_session] Debug event: 0x556fe76e2790 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.614Z DEBUG codelldb::debug_session] Debug event: 0x556fe7416c50 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.614Z DEBUG codelldb::dap_codec] <-- {"seq":9,"type":"response","request_seq":5,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":5,"line":214,"message":"Resolved locations: 0","verified":true}]}}
[2022-12-01T21:55:17.614Z DEBUG codelldb::dap_codec] <-- {"seq":10,"type":"response","request_seq":6,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2022-12-01T21:55:17.614Z DEBUG codelldb::dap_codec] <-- {"seq":11,"type":"response","request_seq":7,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2022-12-01T21:55:17.614Z DEBUG codelldb::dap_codec] <-- {"seq":12,"type":"response","request_seq":8,"success":true,"command":"setExceptionBreakpoints"}
[2022-12-01T21:55:17.614Z DEBUG codelldb::debug_session] Debug event: 0x556fe7416c50 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.638Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":9,"command":"runInTerminal","request_seq":6,"success":true,"body":{"shellProcessId":3105}}
[2022-12-01T21:55:17.705Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":10}
[2022-12-01T21:55:17.705Z DEBUG codelldb::dap_codec] <-- {"seq":13,"type":"event","event":"output","body":{"output":"Launching: /home/ag/clsc/build/tests/clsc_tests --gtest_filter=*simple_tokens/besc_parser_tests.all/IDENTIFIER*\n"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe69f3e90 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {ld-linux-x86-64.so.2}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe69e1f90 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {[vdso](0x00007ffff7fc8000)}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe69da910 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":14,"type":"event","event":"output","body":{"output":"Launched process 9931\n"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":15,"type":"response","request_seq":2,"success":true,"command":"launch"}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe696d990 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":16,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FCA000","id":"7FFFF7FCA000","name":"ld-linux-x86-64.so.2","path":"/usr/lib/ld-linux-x86-64.so.2","symbolFilePath":"/usr/lib/ld-linux-x86-64.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":17,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FC8000","id":"7FFFF7FC8000","name":"[vdso]","path":"[vdso]","symbolStatus":"Symbols not found"},"reason":"new"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe696dae0 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe696e030 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":18,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":1,"line":188,"message":"Resolved locations: 1","verified":true},"reason":"changed"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe696e240 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":19,"type":"response","request_seq":10,"success":true,"command":"configurationDone"}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe696e2e0 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {clsc_tests}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":20,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":2,"line":602,"message":"Resolved locations: 1","verified":true},"reason":"changed"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::debug_session] Debug event: 0x556fe69f3200 Event: broadcaster = 0x556fe6b073f8 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x556fe6b073c0 (pid = 9931), state = running}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":21,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":3,"line":607,"message":"Resolved locations: 1","verified":true},"reason":"changed"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":22,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":4,"line":615,"message":"Resolved locations: 1","verified":true},"reason":"changed"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":23,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":5,"line":214,"message":"Resolved locations: 1","verified":true},"reason":"changed"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":24,"type":"event","event":"module","body":{"module":{"addressRange":"555555554000","id":"555555554000","name":"clsc_tests","path":"/home/ag/clsc/build/tests/clsc_tests","symbolFilePath":"/home/ag/clsc/build/tests/clsc_tests","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:17.764Z DEBUG codelldb::dap_codec] <-- {"seq":25,"type":"event","event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90020f30 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {ld-linux-x86-64.so.2}
[2022-12-01T21:55:17.769Z DEBUG codelldb::dap_codec] <-- {"seq":26,"type":"event","event":"module","body":{"module":{"addressRange":"FFFFFFFFFFFFFFFF","id":"FFFFFFFFFFFFFFFF","name":"ld-linux-x86-64.so.2","path":"/lib64/ld-linux-x86-64.so.2","symbolFilePath":"/lib64/ld-linux-x86-64.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90013a10 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e9001eb90 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90033c80 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90033d30 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90033de0 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90033e90 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90033fd0 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000004 (modules-unloaded), data = {ld-linux-x86-64.so.2}
[2022-12-01T21:55:17.769Z DEBUG codelldb::dap_codec] <-- {"seq":27,"type":"event","event":"module","body":{"module":{"id":"FFFFFFFFFFFFFFFF","name":""},"reason":"removed"}}
[2022-12-01T21:55:17.769Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90013a10 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {[vdso](0x00007ffff7fc8000)}
[2022-12-01T21:55:17.769Z DEBUG codelldb::dap_codec] <-- {"seq":28,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FC8000","id":"7FFFF7FC8000","name":"[vdso]","path":"[vdso]","symbolStatus":"Symbols not found"},"reason":"new"}}
[2022-12-01T21:55:17.789Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":11}
[2022-12-01T21:55:17.789Z DEBUG codelldb::dap_codec] <-- {"seq":29,"type":"response","request_seq":11,"success":true,"command":"threads","body":{"threads":[{"id":9931,"name":"1: tid=9931 \"clsc_tests\""}]}}
[2022-12-01T21:55:17.851Z DEBUG codelldb::debug_session] Debug event: 0x7f4e902c9de0 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:17.852Z DEBUG codelldb::dap_codec] <-- {"seq":30,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":6,"message":"Resolved locations: 0","verified":true},"reason":"changed"}}
[2022-12-01T21:55:17.852Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90318500 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {libasan.so.8}
[2022-12-01T21:55:17.852Z DEBUG codelldb::dap_codec] <-- {"seq":31,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7800000","id":"7FFFF7800000","name":"libasan.so.8","path":"/usr/lib/libasan.so.8","symbolFilePath":"/usr/lib/libasan.so.8","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.003Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90aa2b90 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:18.004Z DEBUG codelldb::dap_codec] <-- {"seq":32,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":6,"message":"Resolved locations: 0","verified":true},"reason":"changed"}}
[2022-12-01T21:55:18.004Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90aa9670 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {libstdc++.so.6}
[2022-12-01T21:55:18.004Z DEBUG codelldb::dap_codec] <-- {"seq":33,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7400000","id":"7FFFF7400000","name":"libstdc++.so.6","path":"/usr/lib/libstdc++.so.6","symbolFilePath":"/usr/lib/libstdc++.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.007Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90aaad00 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {libm.so.6}
[2022-12-01T21:55:18.008Z DEBUG codelldb::dap_codec] <-- {"seq":34,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7EB9000","id":"7FFFF7EB9000","name":"libm.so.6","path":"/usr/lib/libm.so.6","symbolFilePath":"/usr/lib/libm.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.025Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90ace3c0 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {libubsan.so.1}
[2022-12-01T21:55:18.025Z DEBUG codelldb::dap_codec] <-- {"seq":35,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF6C00000","id":"7FFFF6C00000","name":"libubsan.so.1","path":"/usr/lib/libubsan.so.1","symbolFilePath":"/usr/lib/libubsan.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.032Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90dcab00 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {libgcc_s.so.1}
[2022-12-01T21:55:18.032Z DEBUG codelldb::dap_codec] <-- {"seq":36,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF77E0000","id":"7FFFF77E0000","name":"libgcc_s.so.1","path":"/usr/lib/libgcc_s.so.1","symbolFilePath":"/usr/lib/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.041Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90dc8520 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {libc.so.6}
[2022-12-01T21:55:18.041Z DEBUG codelldb::dap_codec] <-- {"seq":37,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF6A19000","id":"7FFFF6A19000","name":"libc.so.6","path":"/usr/lib/libc.so.6","symbolFilePath":"/usr/lib/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90002700 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:18.043Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90dc9150 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":38,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":6,"message":"Resolved locations: 3","verified":true},"reason":"changed"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":39,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":6,"message":"Resolved locations: 3","verified":true},"reason":"changed"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::debug_session] Debug event: 0x7f4e90dc84f0 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":40,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":6,"message":"Resolved locations: 3","verified":true},"reason":"changed"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::debug_session] Debug event: 0x7f4e9023db70 Event: broadcaster = 0x556fe66aa408 (lldb.target), type = 0x00000002 (modules-loaded), data = {libasan.so.8, libstdc++.so.6, libm.so.6, libubsan.so.1, libgcc_s.so.1, libc.so.6}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":41,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7800000","id":"7FFFF7800000","name":"libasan.so.8","path":"/usr/lib/libasan.so.8","symbolFilePath":"/usr/lib/libasan.so.8","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":42,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7400000","id":"7FFFF7400000","name":"libstdc++.so.6","path":"/usr/lib/libstdc++.so.6","symbolFilePath":"/usr/lib/libstdc++.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":43,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7EB9000","id":"7FFFF7EB9000","name":"libm.so.6","path":"/usr/lib/libm.so.6","symbolFilePath":"/usr/lib/libm.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":44,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF6C00000","id":"7FFFF6C00000","name":"libubsan.so.1","path":"/usr/lib/libubsan.so.1","symbolFilePath":"/usr/lib/libubsan.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":45,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF77E0000","id":"7FFFF77E0000","name":"libgcc_s.so.1","path":"/usr/lib/libgcc_s.so.1","symbolFilePath":"/usr/lib/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.043Z DEBUG codelldb::dap_codec] <-- {"seq":46,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF6A19000","id":"7FFFF6A19000","name":"libc.so.6","path":"/usr/lib/libc.so.6","symbolFilePath":"/usr/lib/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-12-01T21:55:18.065Z DEBUG codelldb::debug_session::breakpoints] Callback for breakpoint location 5.1: where = clsc_tests`besc_parser_tests_all_Test::TestBody() + 711 at besc_tests.cpp:214:17, address = 0x0000555555afcc8b, resolved, hit count = 1
[2022-12-01T21:55:18.065Z DEBUG codelldb::debug_session] Debug event: 0x7f4e900143d0 Event: broadcaster = 0x556fe6b073f8 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x556fe6b073c0 (pid = 9931), state = stopped}
[2022-12-01T21:55:18.065Z DEBUG codelldb::dap_codec] <-- {"seq":47,"type":"event","event":"stopped","body":{"allThreadsStopped":true,"reason":"breakpoint","threadId":9931}}
[2022-12-01T21:55:18.086Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":12}
[2022-12-01T21:55:18.086Z DEBUG codelldb::dap_codec] <-- {"seq":48,"type":"response","request_seq":12,"success":true,"command":"threads","body":{"threads":[{"id":9931,"name":"1: tid=9931 "clsc_tests""}]}}
[2022-12-01T21:55:18.093Z DEBUG codelldb::dap_codec] --> {"command":"stackTrace","arguments":{"threadId":9931,"startFrame":0,"levels":1},"type":"request","seq":13}
[2022-12-01T21:55:18.095Z DEBUG codelldb::dap_codec] <-- {"seq":49,"type":"response","request_seq":13,"success":true,"command":"stackTrace","body":{"stackFrames":[{"column":17,"id":1001,"line":214,"name":"besc_parser_tests_all_Test::TestBody()","source":{"name":"besc_tests.cpp","path":"/home/ag/clsc/tests/besc_tests.cpp"}}],"totalFrames":15}}
[2022-12-01T21:55:18.526Z DEBUG codelldb::dap_codec] --> {"command":"stackTrace","arguments":{"threadId":9931,"startFrame":1,"levels":19},"type":"request","seq":14}
[2022-12-01T21:55:18.530Z DEBUG codelldb::disassembly] libc.so.6___lldb_unnamed_symbol3141 + 128 [2022-12-01T21:55:18.530Z DEBUG codelldb::disassembly] libc.so.6__libc_start_main + 138
[2022-12-01T21:55:18.531Z DEBUG codelldb::disassembly] clsc_tests`_start + 37
[2022-12-01T21:55:18.532Z DEBUG codelldb::dap_codec] <-- {"seq":50,"type":"response","request_seq":14,"success":true,"command":"stackTrace","body":{"stackFrames":[{"column":27,"id":1002,"line":2443,"name":"void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const)","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":52,"id":1003,"line":2479,"name":"void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const)","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":50,"id":1004,"line":2517,"name":"testing::Test::Run()","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":14,"id":1005,"line":2693,"name":"testing::TestInfo::Run()","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":31,"id":1006,"line":2811,"name":"testing::TestCase::Run()","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":46,"id":1007,"line":5177,"name":"testing::internal::UnitTestImpl::RunAllTests()","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":27,"id":1008,"line":2443,"name":"bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::)(), char const)","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":52,"id":1009,"line":2479,"name":"bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::)(), char const)","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":55,"id":1010,"line":4786,"name":"testing::UnitTest::Run()","source":{"name":"gtest.cc","path":"/home/ag/clsc/external/googletest/googletest/src/gtest.cc"}},{"column":49,"id":1011,"line":2341,"name":"RUN_ALL_TESTS()","source":{"name":"gtest.h","path":"/home/ag/clsc/external/googletest/googletest/include/gtest/gtest.h"}},{"column":25,"id":1012,"line":33,"name":"main","source":{"name":"main.cpp","path":"/home/ag/clsc/tests/main.cpp"}},{"column":0,"id":1013,"line":29,"name":"___lldb_unnamed_symbol3141","presentationHint":"subtle","source":{"name":"@___lldb_unnamed_symbol3141","sourceReference":1000}},{"column":0,"id":1014,"line":44,"name":"__libc_start_main","presentationHint":"subtle","source":{"name":"@__libc_start_main","sourceReference":1001}},{"column":0,"id":1015,"line":15,"name":"_start","presentationHint":"subtle","source":{"name":"@_start","sourceReference":1002}}],"totalFrames":15}}
[2022-12-01T21:55:18.632Z DEBUG codelldb::dap_codec] --> {"command":"scopes","arguments":{"frameId":1001},"type":"request","seq":15}
[2022-12-01T21:55:18.632Z DEBUG codelldb::dap_codec] <-- {"seq":51,"type":"response","request_seq":15,"success":true,"command":"scopes","body":{"scopes":[{"expensive":false,"name":"Local","variablesReference":1016},{"expensive":false,"name":"Static","variablesReference":1017},{"expensive":false,"name":"Global","variablesReference":1018},{"expensive":false,"name":"Registers","variablesReference":1019}]}}
[2022-12-01T21:55:18.639Z DEBUG codelldb::dap_codec] --> {"command":"variables","arguments":{"variablesReference":1016},"type":"request","seq":16}
warning: (x86_64) /home/ag/clsc/build/tests/clsc_tests 0x001087df: DW_AT_specification(0x000f4862) has no decl
[2022-12-01T21:55:18.665Z DEBUG codelldb::dap_codec] <-- {"seq":52,"type":"response","request_seq":16,"success":true,"command":"variables","body":{"variables":[{"evaluateName":"this","memoryReference":"0x6030000074E0","name":"this","type":"besc_parser_tests_all_Test *const","value":"{...}","variablesReference":1020},{"evaluateName":"param","memoryReference":"0x7FFFFFFFDB40","name":"param","type":"std::pair<clsc::bes::token_stream, std::basic_string<char, std::char_traits, std::allocator<> > >","value":"{...}","variablesReference":1021},{"evaluateName":"tokin","memoryReference":"0x7FFFFFFFDAB0","name":"tokin","type":"clsc::bes::token_stream &","value":"{...}","variablesReference":1022},{"evaluateName":"raw_program","memoryReference":"0x7FFFFFFFDAB8","name":"raw_program","type":"const std::basic_string<char, std::char_traits, std::allocator<> > &","value":"{_M_string_length:1}","variablesReference":1023},{"evaluateName":"parser","memoryReference":"0x7FFFFFFFDAE0","name":"parser","type":"clsc::bes::parser","value":"{m_in:0x00007fffffffdb40, m_raw_program:0x00007fffffffdb58}","variablesReference":1024}]}}
[2022-12-01T21:55:19.675Z DEBUG codelldb::dap_codec] --> {"command":"evaluate","arguments":{"expression":"clsc::bes::token_stream","frameId":1001,"context":"hover"},"type":"request","seq":17}
ERROR(Python) 22:55:19 codelldb: Traceback (most recent call last):
File "/home/ag/.vscode-oss/extensions/vadimcn.vscode-lldb-1.7.0/adapter/codelldb.py", line 152, in evaluate
value = evaluate_in_context(pycode, is_simple_expr, context)
File "/home/ag/.vscode-oss/extensions/vadimcn.vscode-lldb-1.7.0/adapter/codelldb.py", line 288, in evaluate_in_context
return eval(code, eval_globals, eval_locals)
File "", line 1, in
File "/home/ag/.vscode-oss/extensions/vadimcn.vscode-lldb-1.7.0/adapter/codelldb.py", line 269, in missing
raise VariableNotFound(name)
codelldb.VariableNotFound: Variable 'clsc::bes::token_stream' not found
[2022-12-01T21:55:19.677Z ERROR codelldb::debug_session] Variable 'clsc::bes::token_stream' not found
[2022-12-01T21:55:19.677Z DEBUG codelldb::dap_codec] <-- {"seq":53,"type":"response","request_seq":17,"success":false,"command":"","message":"Variable 'clsc::bes::token_stream' not found","show_user":true}
[2022-12-01T21:55:22.492Z DEBUG codelldb::dap_codec] --> {"command":"completions","arguments":{"frameId":1001,"text":"p","column":2,"line":1},"type":"request","seq":18}
[2022-12-01T21:55:22.492Z DEBUG codelldb::dap_codec] <-- {"seq":54,"type":"response","request_seq":18,"success":true,"command":"completions","body":{"targets":[{"label":"p"}]}}
[2022-12-01T21:55:23.399Z DEBUG codelldb::dap_codec] --> {"command":"completions","arguments":{"frameId":1001,"text":"p r","column":4,"line":1},"type":"request","seq":19}
Received signal: SIGSEGV
0: codelldb::hook_crashes::handler
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43: ZN4lldb20SBCommandInterpreter32HandleCompletionWithDescriptionsEPKcS2_S2_iiRNS_12SBStringListES4
44: _ZN4lldb20SBCommandInterpreter16HandleCompletionEPKcS2_S2_iiRNS_12SBStringListE
45: __cpp_closure_10031222636214441753
46: lldb::sb::sbcommandinterpreter::SBCommandInterpreter::handle_completions
47: codelldb::debug_session::DebugSession::handle_request_args
48: codelldb::debug_session::DebugSession::handle_request
49: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
50: tokio::runtime::task::harness::Harness<T,S>::poll
51: std::thread::local::LocalKey::with
52: tokio::task::local::LocalSet::tick
53: <tokio::task::local::LocalSet as core::future::future::Future>::poll
54: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
55: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
56: tokio::park::thread::CachedParkThread::block_on
57: tokio::runtime::thread_pool::ThreadPool::block_on
58: tokio::runtime::Runtime::block_on
59: entry
60: codelldb::main
61: std::sys_common::backtrace::__rust_begin_short_backtrace
62: std::rt::lang_start::{{closure}}
63: std::rt::lang_start_internal
64: main
65:
66: __libc_start_main
67: _start
Debug adapter exit code=255, signal=null.

The stacktrace (see verbose log) kind of hints at roughly this place. Given that it's an unsafe c++ block, that might indeed have some magic tricks happening in there.

Yeah, LLDB is known to do that sometimes.   Seems to be some sort of incompatibility with gcc-emitted debug info.
You can disable auto-evaluation via lldb.commandCompletions and lldb.evaluateForHovers.   https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#advanced

Oh, thanks for the lldb.evaluateForHovers! Tried messing with lldb.commandCompletion (before submitting a bug) but it didn't seem to help. Will try the other one.

Finally got to testing this again:
Disabling lldb.commandCompletions seems to help. Somehow (?) it didn't work before when I toggled that option but oh well. Guessing that would do as a workaround for the time being.


Parse error should be thrown in case of scenario heading in concept

Expected behavior
If a scenario heading (markdown equivalent: H2) is present in a concept file, a parse error should be thrown.
Actual behavior

While execution, Gauge is treating the text starting with scenario heading as comments.
While refactoring, Gauge changes the scenario heading to concept heading and hence a new concept is created.

Steps to reproduce

Create a new concept file. Add a new scenario to it. Here's a sample concept file.

# Test Concept
* Step1
* Step2

Scenario Heading
----------------
* Scenario step 1
* Scenario step 2

Use this concept in some spec.
Execute gauge specs. It should throw parse error.

Please check concept_should_not_contain_scenario_heading.spec and close

Fixed the FT(concept_should_not_contain_scenario_heading.spec), the fix should be available in the nightly > 20/04/2016


Show realm name on cards grid card

https://github.com/cardstack/boxel/assets/12637010/6488010e-8fce-48cc-9759-4afddad649f3
(EDIT)
I decided to use a different approach to display the title of the cards grid. Unlike other card titles that are defined in the operator mode header, the title of the cards grid is defined in the card itself from the realm name field.

@jurgenwerk you have to ensure the latest runtime common is installed.
Fixed inconsistency design. https://github.com/cardstack/boxel/pull/393/commits/6ce506c716b47303a28266632b24cc9a7eb10269
Add a test. https://github.com/cardstack/boxel/pull/393/commits/93843fe4f8464d0132890c52ddc02f4a609d7359

@burieberry I think we could add a new static function in CardBase class and override it in CardsGrid class. Here is an example.
CardBase
static getDisplayName(
    instance: CardBase,
  ): any {
    return instance.constructor.displayName;
  }

CardsGrid
static getDisplayName(
    instance: CardBase,
  ): any {
    return instance[realmInfo]?.name;
  }

@burieberry I think we could add a new static function in CardBase class and override it in CardsGrid class. Here is an example.
CardBase
static getDisplayName(
    instance: CardBase,
  ): any {
    return instance.constructor.displayName;
  }

CardsGrid
static getDisplayName(
    instance: CardBase,
  ): any {
    return instance[realmInfo]?.name;
  }

This is a good idea but I realized we don't need to make this specific change right now, since the changes that I'm making with the card boundary moves the header higher up in the hierarchy. I'm fine with your changes as is.


Add height attribute to mj-button

In order to make perfect pill-shaped buttons, the height should be either explicit, or the border-radius shoud allow % units.

@fabien thanks for sharing! We'll look into it for a future release.
Meanwhile, we would love to review a contribution from you :)!

Hi there, height is now available on mj-button in MJML3 !


Sprint challenge

Spring challenge submission

Can you please review my latest commits on the pull request, thank you.


gpfit should accept mesh vectors

per @ltrollinger, they are a nice interpretable transpose-invariant input.

reference?


⚠ Bofrost.at has degraded performance

In 63997d7, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1014 ms

Resolved: Bofrost.at performance has improved in 8eb4a5a.


Remove duplicate TestLogger*

There are duplicate TestLogger* types in Microsoft.Extensions.Logging.Testing and Microsoft.Extensions.Logging.Test. They don't seem too different so maybe we can remove the duplication.
cc @BrennanConroy looks like when you moved these types to the testing repo, you didn't remove them from this repo so when @kichalla moved them back to this repo, we now have duplicates.

Fixed in #542


bug 1800609: add cpu limits to become guaranteed

The kubelet requires cpu and memory limits both specified to become guaranteed.

/lgtm

/bugzilla refresh


Missing file units/kube-register.service

In https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/3-install_k8s_fleet_units.sh#L43 you write fleetctl start ./units/kube-register.service but in https://github.com/rimusz/coreos-multi-node-k8s-gce/tree/master/units is no such file.
I get Error creating units: unable to find Unit(kube-register.service) in Registry or on filesystem when starting the units.

@soupdiver thanks for reporting, got it fixed


32bits g++ -static is broken

Hello
I try to build a program both in 32-bits with mingw32\bin\g++.exe and in 64-bits with mingw64\bin\g++.exe using options "-static -static-libgcc -static-libstdc++". The 64-bits executable runs perfectly, while the 32-bits executable keeps requiring libgcc_s_dw2-1.dll to run. Also I don't understand why I have a libgcc_s_dw2-1.dll only in folder msys64\mingw32\bin and not in folder msys64\mingw64\bin.
Please repair.
Regards,

The 32-bit and 64-bit versions differ in exception handling, 32-bit uses DW2, 64-bit uses SEH. libgcc_s_dw2-1.dll is related to DW2 and therefore not part of the 64-bit mingw-w64 gcc.
I just wanted to clarify. I'll leave the bug itself to someone else (or to some other time).

This name confuses me: is that DLL necessary for C programs only? I mean I built a pure C DLL without "-static", could it be because linking with it I have this problem?

GCC is "C" compiler, G++ is "C++" compiler so I don't know why it's name would confuse you.
Both C and C++ 32-bit programs use DW2.

My apologies! And thanks for answering me.
It seems this time the bug was, as we often say, between the chair ans the screen. So, after rebuilding correctly SDL_gfx.dll I could get rid of this nasty dll dependency.
Issue solved.


How to change tint color

It only changes after the first tap

Nevermind solved it!
button.normalColor = .white
button.isSelected=false


⚠ gorzdrav.org has degraded performance

In 4abe982, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 9277 ms

Resolved: gorzdrav.org performance has improved in 2552819 after 11 minutes.


bump login/sync plugin versions for pom repository URL fix

@bparees @adambkaplan @nstielau fyi
after this, I'll need to open an issue on the ART board to get them to pull these new versions into our RPM

Installed plugins:
ace-editor:1.0.1
apache-httpcomponents-client-4-api:4.5.5-3.0
authentication-tokens:1.3
blueocean-autofavorite:1.2.2
blueocean-bitbucket-pipeline:1.10.2
blueocean-commons:1.10.2
blueocean-config:1.10.2
blueocean-core-js:1.10.2
blueocean-dashboard:1.10.2
blueocean-display-url:2.2.0
blueocean-events:1.10.2
blueocean-github-pipeline:1.10.2
blueocean-git-pipeline:1.10.2
blueocean-i18n:1.10.2
blueocean-jira:1.10.2
blueocean:1.10.2
blueocean-jwt:1.10.2
blueocean-personalization:1.10.2
blueocean-pipeline-api-impl:1.10.2
blueocean-pipeline-editor:1.10.2
blueocean-pipeline-scm-api:1.10.2
blueocean-rest-impl:1.10.2
blueocean-rest:1.10.2
blueocean-web:1.10.2
branch-api:2.0.20
cloudbees-bitbucket-branch-source:2.2.15
cloudbees-folder:6.6
conditional-buildstep:1.3.1
config-file-provider:3.5
credentials-binding:1.15
credentials:2.1.19
display-url-api:2.2.0
docker-commons:1.11
docker-workflow:1.14
durable-task:1.26
favorite:2.3.1
git-client:2.7.3
github-api:1.90
github-branch-source:2.3.6
github:1.29.2
github-organization-folder:1.6
git:3.9.3
git-server:1.7
handlebars:1.1
handy-uri-templates-2-api:2.1.6-1.0
htmlpublisher:1.16
jackson2-api:<IP_ADDRESS>
jenkins-design-language:1.10.2
jira:3.0.5
job-dsl:1.72
jquery-detached:1.2.1
jsch:<IP_ADDRESS>
junit:1.26.1
kubernetes-credentials:0.3.0
kubernetes:1.12.8
lockable-resources:2.5
mailer:1.21
mapdb-api:<IP_ADDRESS>
matrix-auth:2.2
matrix-project:1.14
mercurial:2.3
momentjs:1.1
openshift-client:1.0.30
openshift-login:1.0.19
openshift-sync:1.0.38
parameterized-trigger:2.35.2
pipeline-build-step:2.7
pipeline-github-lib:1.0
pipeline-graph-analysis:1.7
pipeline-input-step:2.8
pipeline-milestone-step:1.3.1
pipeline-model-api:<IP_ADDRESS>
pipeline-model-declarative-agent:1.1.1
pipeline-model-definition:<IP_ADDRESS>
pipeline-model-extensions:<IP_ADDRESS>
pipeline-rest-api:2.10
pipeline-stage-step:2.3
pipeline-stage-tags-metadata:<IP_ADDRESS>
pipeline-stage-view:2.10
pipeline-utility-steps:2.1.0
plain-credentials:1.4
pubsub-light:1.12
run-condition:0.10
scm-api:2.2.8
script-security:1.56
sse-gateway:1.16
ssh-credentials:1.14
structs:1.17
subversion:2.10.3
token-macro:2.6
variant:1.1
workflow-aggregator:2.6
workflow-api:2.32
workflow-basic-steps:2.11
workflow-cps-global-lib:2.11
workflow-cps:2.65
workflow-durable-task-step:2.26
workflow-job:2.29
workflow-multibranch:2.20
workflow-remote-loader:1.5
workflow-scm-step:2.6
workflow-step-api:2.19
workflow-support:3.2

ART req for RPM update https://jira.coreos.com/browse/ART-671

ART req complete
dist git http://pkgs.devel.redhat.com/cgit/rpms/jenkins-2-plugins/commit/?h=rhaos-4.2-rhel-7&id=4caffd3dd34032cc751e00bdcf74c3d70bc82f72

for reference master PR https://github.com/openshift/jenkins/pull/867 merged 7 days ago


question: wlr_cursor button events are not sent to toplevel?

Hi! I'm kind of puzzled by an issue that I'm facing, I apologize if this has nothing to do with pywlroots. If there's a better place where I can ask such questions, please do redirect me.
I'm current writing a compositor and I copied a lot from tinywl to get to a somewhat usable state and that includes the cursor setup.
I created a Cursor (self.cursor) object in my server class and attached the button event to it.
The event triggers as per my logs without any errors.
However my focused toplevel doesn't get any click events? I have checked and made sure that the surface has focus (surface.set_activated(True), seat.keyboard_notify_enter(....))

There are a few independent state changes involved here that truly are independent:

surface.set_activated tells the client whether or not it is activated, but that's all that does. It doesn't change any behaviour, it's primarily used by clients to draw themselves different, for example GTK windows fade-out a bit when they become 'deactivated' (whatever that means for the compositor)
seat.keyboard_notify_enter this tells the seat where key events should go
seat.pointer_notify_enter this is what you're missing, it tells the seat where pointer events should go

Note that these truly are independent - you could have 3 different clients that are activated, have keyboard focus, and have pointer focus respectively (if that made sense to the compositor)

you could have 3 different clients that are activated, have keyboard focus, and have pointer focus respectively (if that made sense to the compositor)

If I understand this correctly, does this mean 3 toplevels can receive keyboard events if the compositor allowed so?

No, the 3 bullet points above are 3 independent processes that do not necessarily have any interplay. Up to 1 surface can have pointer focus. Up to 1 surface can have keyboard focus (could be the same one, could be a different one). Any number of surfaces can be 'activated' because it isn't a functionality, it's just a message to the surface to tell it to look activated.

No, the 3 bullet points above are 3 independent processes that do not necessarily have any interplay. Up to 1 surface can have pointer focus. Up to 1 surface can have keyboard focus (could be the same one, could be a different one). Any number of surfaces can be 'activated' because it isn't a functionality, it's just a message to the surface to tell it to look activated.

Got it. I have one last question to ask but it's offtopic for the thread, should I open another ticket or just ask here?

Easier to just ask here


Update office-365-groups.md

Calendars are not supported. See FAQ, https://support.microsoft.com/en-us/office/calendar-sharing-in-microsoft-365-b576ecc3-0945-4d75-85f1-5efafb8a37b4

@nickadam the article refers to the shared calendar that is included as part of a Microsoft 365 group, not the sharing of individual calendars with groups.


[BUG] Node tag and disk tag are not available in to enter while 'Activate Disaster Recovery Volume.'

Describe the bug
Node tag and disk tag are not available while activating a disaster recovery volume.
To Reproduce
Steps to reproduce the behavior:

Take a volume backup.
Go to backup page and click 'Create disaster recovery volume'.
Go to volume page and click 'Activate Disaster recovery volume'.
A form opens and allow user to enter Frontend

Expected behavior
There should be option to enter Node tag and Disk tag
Environment:

Longhorn version: master

When DR volume was created, the scheduler is already get involved and the scheduling decision (include disk/node tag) has been made. So when you activate the volume, there won't be an option for disk/node tag.
But I found creating DR volume doesn't provide the input option for disk/node tag in the latest UI. That's a bug there.

Filed https://github.com/longhorn/longhorn/issues/1567 for DR volume with disk/node tag option.


No Projection for Numerical Attributes with an Uploaded Dataset

Version: Develop
OS: Linux/openSUSE
Browser: Google Chrome (Version 89.0.4389.90)
Date: 16-03-2021 15:55
Dataset: Coral_raw.zip
Problem
Selecting numerical attribute creates an error and no projection is done.
Uncaught TypeError: Cannot read property 'indexOf' of undefined
    at Dataset.ts:194
    at Array.forEach (<anonymous>)
    at Dataset.ts:180
    at Array.forEach (<anonymous>)
    at Dataset.asTensor (Dataset.ts:178)
    at UMAPEmbeddingController.init (UMAPEmbeddingController.ts:11)
    at onStart (EmbeddingTabPanel.tsx:123)
    at onClick (GenericSettings.tsx:81)
    at HTMLUnknownElement.callCallback (react-dom.development.js:188)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:237)

GIF

The dataset contains NULL values in the "Age" attribute. I think there is no easy way to project it numerically if it contains NULL values.


[Feature Request] Helm Chart for discord Bot

What does this feature MR do?
Create helm chart to deploy the discord bot in Kubernetes environments.
What problem does this MR solve?
Enables a new way to deploy.
Additional context
At the root of the project, a charts directory containing the Helm Chart will be created.

I created a repository to create the helm chart of amongusdiscord. I can deploy the container and expose it through a ingress.
Initially we have:

deployment
ingress
server
secret (discord-bot-token)

For more information access.

Create a namespace in K8S

Install helm chart

Listing pods in namespace amongusdiscord-demo

List secrets in namespace amongusdiscord-demo

List services in namespace amongusdiscord-demo

Hey thanks for posting this! I have very minimal experience with K8, but I really appreciate you sharing the details as to how to install this chart, much appreciated! :)


CFE: Missing error when awaiting a void expression

The snippet below should be an error per the static analysis section of https://github.com/dart-lang/sdk/blob/master/docs/language/informal/generalized-void.md .
import 'dart:async';

void returnsVoid() {}

main() async {
  await returnsVoid();
}

per #33415, this is not caught by the analyzer.

Closing as unplanned since it's a breaking change to fix it and we've decided it's not worth the effort to clean up. As per https://github.com/dart-lang/sdk/issues/33823 we will hopefully be able to make this show up in the analyzer but can't add it to CFE.


getValue() : return items or selected choices

Maybe it can be useful :)

Nice addition, thanks

why I get always object of selected value. I need to get array of options


fixed issue #37

solution for highlight between paragraphs based on code from @ajeenats for Android

There a problem when reopen ebook and click highlight on highlight list, the problem maybe was on population highlights

Fixed adding
html = html.replacingOccurrences(of: "
", with: "

")
html = html.replacingOccurrences(of: "
", with: "")

after
let toInject = "\n\(cssTag)\n\(jsTag)\n"
html = html.replacingOccurrences(of: "", with: toInject)

in FolioReaderCenter.swift  line 407

@EmersonCarpes have you look at this ^^

@hebertialmeida i tested this fix, and the "" solution for para paragraphs works well but broken the reading feature


Server takes a long time to start

Takes more than 90s to start (in release mode):
2023-02-23T00:45:38.357Z  INFO quickwit_grpc_clients::balance_channel: Adding `control_plane` servers to client pool. server_addresses={<IP_ADDRESS>:7281}
2023-02-23T00:47:12.523Z  INFO quickwit_ingest_api::ingest_api_service: Ingest API partition id ingest_partition_id=ingest_partition_01GSTHS4CVQG71KNJ44DPQV8CB

It looks like it's coming from the ingest_api_service  initialization. Does it help if you remove the queue directory?

Yeah, this most likely the result of the truncation bug in mrecordlog.

Fixed via lazy init of ingesters.


Logic Pro X 10.4.2 not satisfied with mandatory installed items

After initial install of mandatory sounds Logic Pro X 10.4.2 still asks to download sounds worth of roughly 330 MB.

Command used:
appleLoops.py --deployment -m

Version:
2.2.3

Debug log output:
Loops downloading to: /tmp
Skipping garageband as it does not appear to be installed.
Processing loops from: logicpro1042.plist
Processing loops from: mainstage340.plist
Installed 0 packages, downloaded 0.00 B, install size 0.00 B

Tried to remove all Apple Loops pkg receipts which is not succeeding for some reason?
IFS=$'\n'
for aReceipt in $(pkgutil --pkgs | grep apple.pkg.MAContent)
do
pkgutil --forget "$aReceipt"
done

Apple loop package receipts get out in a SIP protected location. Please use the forced deployment argument and the debug argument and post logs back. Use --help to see how.

Is this still an issue?

Inconvienence mostly but cannot be fixed with appleLoops.py


cmd/cgo: ${SRCDIR} doesn't properly handle paths with spaces

Given a cgo directive like the following
//#cgo CFLAGS: -I${SRCDIR}/../../include

I get the following error

malformed #cgo argument: -IC:/Users/Joe Sylve/go/src/go4n6/disk/vmdk/../../include

Neither of the following seem to make much of a difference
//#cgo CFLAGS: -I"${SRCDIR}/../../include"

//#cgo CFLAGS: -I\"${SRCDIR}/../../include\"

Tested on go1.5beta2 on both 32 and 64 bit Windows.

Please, provide instructions to reproduce your issue. Thank you.
Alex

C:\>mkdir "foo bar"

C:\>cd "foo bar"

C:\foo bar>type con > main.go
package main

//#cgo CFLAGS: -I${SRCDIR}/../../include
import "C"

func main() {
}
^Z

C:\foo bar>go build
can't load package: package .: c:\foo bar\main.go: malformed
#cgo argument: -IC:/foo bar/../../include

This is depend on behavior of escape arguments on unix-shell or cmd.exe.

Thank you @mattn. This is how it works on linux too:
# pwd
/root/src/issue 11868
# cat main.go
package main
//#cgo CFLAGS: -I${SRCDIR}/../../include
import "C"
func main() {
}
# go build
can't load package: package issue 11868: /root/src/issue 11868/main.go: malformed #cgo argument: -I/root/src/issue 11868/../../include
#

It appears we don't allow space inside of #cgo line parameters. I don't know why is that. Leaving for others to explain.
Alex

It's a bug.
I don't know if changing safeCgoName in go/build/build.go is sufficient, or whether we need to add quoting somewhere.

gcc doesn't allows "-I/path/to directory". it should be -I"/path/to directory". (at least, on windows)

Has there been any more thoughts on how this can be fixed?  If someone could point me in the right direction, I'd be happy to try to fix it myself.

@jtsylve Thanks--I would start with my suggestion above: look at safeCgoName in go/build/build.go.  Fix that to accept spaces.  Then make sure any necessary quoting is done.

It is important that an attempted fix here does not allow spaces in other places. Changing safeCgoName sounds dangerous.
It does seem reasonable that ${SRCDIR}'s expansion should be properly handled even when that variable contains spaces.

The issue is more complicated than just changing safeCgoName, unfortunately.  In order to make it work correctly with gcc we need to allow quotes.  splitQuoted tends to affect this negatively.  I have yet to come up with a reasonable solution.

Under which cases is splitQuoted needed and when should we avoid spaces as @rsc mentioned?


Pass in github provider settings from env variables

Summary
https://github.com/stacklok/minder/pull/3410 removed manually-registered
command line flags we were using to set these. Let's set them as env
variables instead.
Change Type
Mark the type of change your PR introduces:

[x] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 51.964%. remained the same
when pulling a97fd0c13b01202d12b94c7c58693a941ea3a7cd on files-from-envs
into 1d4f1e4d93c5d7cc71845f3e8af1ef2afdc01549 on main.

This didn't work


split_qscore.py ignoring reads

Hello,
I'm having issues with the split_qscore.py script. I wanted to filtered the output from basecalling done by Dorado using this:
I completed with no error message and I got a stats.txt file like this:

pass_reads: 20080458
fail_reads: 1350286
total_reads: 21430744
pass fraction: 93.7%

#!/bin/bash
#SBATCH --job-name=split
#SBATCH --output=split_%j.out
#SBATCH --error=split_%j.err
#SBATCH --ntasks=1
#SBATCH --time=05:00:00
#SBATCH --mem=2G

module load StdEnv/2023 scipy-stack/2023b
module load python
module load samtools
samtools view -h dorado_basecalling_merge.bam | python3 split_qscore.py -q 10 -f fastq - ./ > stats.txt

Issue is, the bam file contains 4 times the total read number in the split file (real number of reads 85722924) and only a fraction of the reads were actually filtered.

Hey,
Switch the -f fastq argument to -f Sam, as the output of samtools view on a bam file is Sam format.
The difference in reads is because the fastq format is 1 read per 4 lines and Sam is 1 read per line.
Hope that helps.
James

yes! output is now correct!


tekken crush

tekken crushes when trying to show maven's parry frame date

Can you provide the version of Tekken Overlay you are using. To me it sounds like you are using an old version that is not compatible with the current version of Tekken.

Closing this due to inactivity.


Add cronjob to synchronize GitHub teams with the team repo

This PR is the followup to https://github.com/rust-lang/team/pull/88, adding a cronjob on RCS that synchronizes GitHub teams with the team repo every 5 minutes.
We can't merge this right away, as we first need to create the bot account that will do the synchronization and add its token to RCS's secrets.toml.
r? @Mark-Simulacrum
cc https://github.com/rust-lang/team/issues/2

I think that happens automatically with the current set of APIs, but it'd be good to make sure we don't send out N invitations or break dry runs if someone has not yet accepted an invitation.

I tested this on a separate org: each time the tool is run the API call to add the outsider to the org is going to be executed, but GitHub doesn't send them multiple notifications (it's basically a noop as long as the invitation exists).

I think we can merge this when ready then -- we'll need to create the github user and such but that shouldn't be too problematic.

Added a comment about the multiple invites.


psa switch minimal changes for basic unicast/multicast demo

Derek is the author of all these changes despite what the commit log says.
changelog:

in psa_switch's main control-flow functions (receive_, ingress_thread, egress_thread, transmit_thread), v1model standard metadata references were removed, replaced with psa arch-specific metadata needed for unicast/multicast
ingress deparser and egress parser added and applied in appropriate parts of main control-flow
minimal logging added for debugging purposes

Codecov Report

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

@@           Coverage Diff           @@
##           master       #5   +/-   ##
=======================================
  Coverage   74.48%   74.48%
=======================================
  Files         115      115
  Lines        9988     9988
=======================================
  Hits         7440     7440
  Misses       2548     2548

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 8c6f852...d8cee87. Read the comment docs.


Update GPS external connection

existing documentatiton is misleading after merging https://github.com/lutraconsulting/input/pull/1886 and related
https://github.com/MerginMaps/docs/blob/main/src/field/external_gps.md

What to add to documentation:

the safest way how to connect any device is:

set up your device based on instructions of its manufacturer. You should continue only when you are sure that the device is working and sending data
pair the device via system settings (note: it is possible to it directly via Input, but it is much easier to first go to settings on Android and pair it and then continue to Input)
select the receiver in Input

if whatever goes wrong, make sure:

your bluetooth is turned on
your device is turned on, has battery and is sending data
you can try to remove the device in Input and add it again from Input

(if the device is working, uses classic bluetooth (not BLE), is discoverable during pair and feeds data, there should not be any problem )

Also, add a list of vendors that work with iOS, see discussion starting here: https://github.com/lutraconsulting/input/pull/1906#issuecomment-1023191497

Also we can start building a database of supported devices. Currently known to work:

Emlid Reach RS+ - directly via bluetooth connection. Android only. It can connect to phone's hotspot and it has internal ntrip client to receive corrections. Supports 1cm accuracy with corrections.
Leica FLX100 - through Leica Zeno Connect app (https://play.google.com/store/apps/details?id=com.leica.zenoconnect&hl=en&gl=US) which also acts as a ntrip client and sends the corrections to the device. The app will set mock location in Android. It is also possible to connect directly via bluetooth (even multiple phones can be connected at once), but if no phone has Zeno app running, there will be no corrections available. Supports 1cm accuracy with corrections. Android only (even though zeno app is on iOS too, it's not supported, at least this device)


Multi-cluster support feature - Registry WEB changes

Due to the unit test snapshot updates
/bot-ignore-length

@sbathgate thanks for your review. I've checked in the code for your suggested changes except uppercasing the cluster names. I can work on that once all the feature priorities are in place.