Local non-md file links are still hashed by docsify

TL;DR: How do I create links in my .md files that are not hashed by docsify?
Details: I have a link in my .md files that looks like: [hello world](/tutorial/?hello)
The /tutorial/index.html uses a query string to select the js file to run, here hello.js.
Clicking on the link gives a 404 error due to hashing the url:

GET http://localhost/src/asx/docs/tutorial/README.md 404 (Not Found)
http://localhost/src/asx/docs/#/tutorial/?hello=undefined

If I convert to [hello world](/tutorial/index.html?hello) I still get a hash conversion and an undefined error:

http://localhost/src/asx/docs/#/tutorial/index.html?hello=undefined
GET http://localhost/src/asx/docs/tutorial/_sidebar.md 404 (Not Found)

If I remove the hash to either of:

http://localhost/src/asx/docs/tutorial/?hello
http://localhost/src/asx/docs/tutorial/index.html?hello

and directly paste into the url bar, both work as expected.
If I use either of these complete urls in the .md file, it also works, but that fails to work on both my local system and github due to the differences in the url paths.
I also tried building an alias for /tutorials that uses document.location

'/tut': ${document.location.href.replace(/#.*/,'')}tutorial/,

.. which produces:

/tut: "http://localhost/src/asx/docs/tutorial/"

..thus solves the issue of github/localhost differences.
but using [hello world](/tut/?hello) fails, apparently the alias needs to be the entire path?
How do I create links in my .md files that are not hashed by docsify?

More info: I tried the markdown renderer option:
    markdown: {
      renderer: {
        link: function (href, title, text) {
          console.log('link', href, title, text)
          return `<a href="${href}"> </a>`
        }
      }
    },

as a test to see if I could simply capture the links and make sure the ones I cared about were not hashed. To my surprise, I did not get these links, apparently docsify uses the same marked hook and it does not get allow docsify users to use it too.
It seems to me this is a docsify bug, it should chain the user's link renderer to the end of it's use.
The bottom line is this: user's markdown should Just Work, just as if it were in any other markdown environment .. like the github wiki.
Hashifying the links should be controllable in the docsify index.html file. At least the window.$docsify should allow some way for the user to specify links/dirs to not be hashed.

Would a hook work for this? I.e. use one of the hooks to remove the /#/'s where I don't want docsify to manage my links?

TL;DR: How do I create links in my .md files that are not hashed by docsify?

Currently you can solve this problem by writing the full URL. For example
# This is full URL

[hello world](//example.com/tutorial/?hello)

Thank you for the quick response! I appreciate it.  And I really love docsify, brilliant project.
I would like us to consider this a bug or enhancement, but also hope we can find a work-around.
Why? It is very natural for us to include examples in our documentation. If I use the docs/*.md files by themselves, without docsify (github for example, or my own use of marked.js), I naturally do not have this problem. So I believe you will find users of docsify expecting (foo)[bar/baz.html] to Just Work as markdown expects.
The full url solution does not work well because while developing on localhost, I will need a different full URL than when deployed on github.
Workaround:

markdown: I should be able to write my own markdown.renderer.link function which converts my tutorial/?hello link into a full link based on document.location. I believe, however, I would still need to call your link renderer too, right? My experiment above did write the link info to console but caused docsify to fail. Possibly I should repeat it, converting the result to a full URL, and that should work?
hook: I haven't tried it yet, but .. do you think I could use a hook to convert a relative link to a full URL? I'm not certain which hook would be appropriate.
aliases: I could not make them work, and I would prefer to not use them because they create .md files that would not work elsewhere, such as the github wiki.

Solution:

Documentation: Possibly we find a workaround we like and simply document it. This should not require changes to the .md if at all possible, but instead use window.$docsify settings.
Docsify Ignore: have an ignore feature in window.$docsify which tells docsify to not hashify certain directories within docs/
Convention: If a relative url is used in a .md link, and does not point to a .md file itself, then do not hash. I think you already handle this for image files, right?
Your better solution! I'm sure you could derive a good solution based on the architecture.

Goal: To have a solution for certain relative links within docs/ not be hashed, all within the window.$docsify object. This can be a workaround, or a new feature. It should not require changes to the markdown .. the markdown files should work well wherever they are used such as on github itself.
Let me know if there is a workaround I can try now! Thanks!

OK, I found a workaround using a hook. It's pretty hacky but is good enough for now:
  // before defining $docsify:
  const root = document.location.href.replace(/#.*/,'')
...
    plugins: [
      function(hook, vm) {
        hook.beforeEach((markdown) => {
          const result = markdown.replace(/]\(tutorial\//g, `](${root}/tutorial/`)
          return result
        })
      }
    ],

The regex is likely not the safest, and it really should take an array of directory names to be more general. And probably I should use the vm to get the docs/ URL.

I have a idea. We know that markdown's link syntax can pass three parameters, likes
[abc](/abc?hello "title")

will be compiled to
abc

So, I can provide a special placeholder (likes :ignore) that tells docsify that does not need to compile this. For example
[abc](/abc?hello ":ignore title")

will be compiled to
abc

Perhaps this can solve your problem, and I think it is easier to use (we only need to explain in the documentation).

Interesting!

Pros: Simple, no JS computation of global URL
Cons: Docsify-specific markdown, .md's may be odd in other contexts, CDNs

I would prefer to not solve it in a docsify-specific way. But I would use it if it were available, for sure. Possibly :nodocsify to distinguish from other md based CDNs? No big deal tho.
But lets look at this from a higher, architectural, point of view.
Users will not be surprised that images work correctly. They do not appear to be hashed.
For example, I have a data/ dir for images and other resources. When I write:
![image with patches, turtles, links](data/allagents.jpg)
it does not produce a hashed URL.
However, users will be surprised when their relative links act differently.
So my question is: Do we need to treat anchor  md links differently than image links?
 I'm sure there are places where users do want docsify to manage the link, for example when linking to other .md files. Are there others?
So is there a middle ground here? A way to not hashify all relative links? I would be fine with a rule that only hashified .md links for example. Or a special syntax for when I do want docsify to manage the link .. maybe /#/foo/bar/ say?
Finally, the issue of not modifying the .md files for docsify. I think the main issue was, as far as I can tell, both the user and docsify use the link marked renderer function. Is there a safe way for us to share link function?
Thank you for your patience!

I think the main issue was, as far as I can tell, both the user and docsify use the link marked renderer function. Is there a safe way for us to share link function?

Now you can only override the default rendering function by configuration. Maybe I can provide another special rendering function, such aspostLink? But I do not think it's a good idea. If you think it can be solved, I will provide it.

Or maybe I can provide a option to Ignore to compiled the link, for example
window.$docsify = {
  noCompileLinks: [
    '/foo',
    '/data/.*' // support regular expression
  ]
}

No, let's go with your idea, I think it's fine. To tell the truth, I didn't even know there was a title included with the url! Blush. :)
Docsify is really fun to work with, btw. I've been working on documenting my repo and so far so good!

That would be really interesting if it is possible. Very sophisticated,
IMHO.
I don't really understand the hashed urls and how they fit into the CMS you
are using. I noticed you have contributed to Vue so I presumed it was
related, somehow.
Is Vue as interesting as it seems? I read an article that said that both
React and Angular were built by large companies interested in large
projects, while Vue was written by a single person interested in small,
simple projects.
I like it!

Because in fact we have only one entry file which is the index.html in the root directory. If we use  the usual url, likes //example.com/foo, It will not be accessible because /foo.html does not exist at all.
So we need hash router. We need an entry file, the route is managed in js.

Very clear, thanks!


Update how-to-create-appointments-in-a-specific-time-zone-by-using-ew…

…s-in-exchange.md
When the second example is used to create meeting requests and the recipient is external, the meeting is created fine the first time. If the meeting is update using OWA or EWS (Without outlook touching the meeting first) the TimeZone Description is updated to UTC and causes the meeting to shift unless we stamp the TimeZone Description extended property, the first time correctly. We do have an associated bug open and can provide reference if needed.

@lindalu-MSFT - What are the next steps on this one for me?

Hi @akash-bhargava Thanks for @-ing me so I can see this! I will review this and other PRs and merge to the production site. Should be live shortly!


Properly comparing multiline queries

This fixes the build. Two of my PRs yesterday didn't play well together. Bonus: We're now able to preserve multiline queries through the parser/deparser.

:+1:


Selector not finding DOM element

I'm doing a simple test here, but I've seen a lot of people stumbled into this problem, but unfortunately I wasn't able to find a solution, so, therefore, I'm asking for your opinion.
Now, I have this string object, inside a link:

12,45 €

I created this small test, to check the string value:
import { t, Selector } from 'testcafe';

fixture `OfferPage`.page `https://www.verivox.de/applications/broadband/#/offer?i=eyJmaWx0ZXIiOltudWxsLDE2MDAwLDEsbnVsbCwiMDIyMSIsMSwxLDEsbnVsbCwxLDEsbnVsbCwtMSxudWxsLG51bGwsInByaWNlLWFzYyIsMixudWxsLG51bGwsbnVsbCxudWxsLG51bGwsbnVsbCxudWxsLG51bGwsNl0sImRpYWxvZyI6W251bGxdLCJvZmZlckNyaXRlcmlhIjpbIjYxMzQ0NyIsIjE4MjkyIixudWxsLCIyNCIsMywyLCI1MDAwMCIsIjEwMDAwIixudWxsLG51bGwsMSxudWxsLG51bGwsbnVsbCwiMiIsMSxudWxsLCIwMjIxIixudWxsLG51bGwsbnVsbCxudWxsLG51bGwsMSw2LG51bGwsbnVsbCxudWxsXX0%3D`;
    test('1', async () => {
        const string = Selector('div.price');
        await t.expect(string.innerText).eql('12,45 €');
});

The error I get in terminal is this one:
AssertionError: expected '12,45 €' to deeply equal '12,45 €'
I tried also other options, like the ones below, but with no luck unfortunatelly:
let price = Selector('div').withAttribute('class', 'price');
const result = price.parent('div.centered-content effective-price-wrapper');
console.log(result);
await t.expect(result.innerText).eql('12,45 €');

err:
Cannot obtain information about the node because the specified selector does not match any node in the DOM tree.
another try:
const string = await Selector('div.price')();
let pret = await Selector(string).innerText;
const rgx = / /gi;
await t.expect(pret.replace(rgx, '')).eql('12,45 €'.replace(rgx, ''));

err
AssertionError: expected '12,45 €' to deeply equal '12,45 €'
I'm running put of ideas here :)

It is a duplicate of the issue on StackOverflow. I've already answered there.


signal.h is missing on FreeBSD

Hi there!
I've just ported inputplug to FreeBSD (https://www.freshports.org/x11/inputplug/) and I noticed that the signal.h header is missing. I am not sure how to detect it using mk-configure so I've not submitted a PR for that. Currently, we just have a patch like this in the ports tree: https://svnweb.freebsd.org/ports/head/x11/inputplug/files/patch-inputplug.c?view=markup&pathrev=551917
Cheers!

DragonFly needs a similar fix, see https://github.com/DragonFlyBSD/DeltaPorts/commit/d9a528ade23b
Why not include <signal.h> unconditionally? It's available on all POSIX systems.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

Why not include <signal.h> unconditionally? It's available on all POSIX systems.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

Oh, I've not thought about checking that. It makes sense.

Closing as signal.h is no longer used.


History does not work with Oracle

I suspect two problems:

Instant values cannot be used directly in Oracle
Oracle does not support limit 500 syntax

It would be good to replace the querybuilder with some generic query engine that maps to the underlying dialect.

should be fixed with https://github.com/bekk/db-scheduler-ui/issues/107 2.0.0


Route request fails if edge_based is not set to false and there is a turn cost encoder

If we use multiple encoders out of which one has turn_costs=true, e.g. foot,car|turn_costs=true,  we have EncodingManager#needsTurnCostsSupport()===true and the GraphHopper#traversalMode field will be EDGE_BASED (see GraphHopper#setEncodingManager). This traversalMode field is then used to determine the traversal mode in GraphHopper#calcPaths.
It can be overwritten using the edge_based or the traversal_mode parameters, but since these are optional it might remain EDGE_BASED even when using a vehicle without turn costs (like foot). So we use edge-based routing for foot, just because there is another encoder with turn_costs=true.
This used to be odd behavior, but with #1696 this is now even more problematic because we now get an exception in this case.
I think we should remove the GraphHopper#traversalMode field entirely, because it seems very counter-intuitive to determine the 'default' traversal mode based on the presence of some encoder that supports turn costs.
Related: #1637

Why can't I do edge-based routing when I don't have turn costs?
I mean, I know I can only have turn costs when I do edge-based routing, but why the other way round?

When we do not use a TurnWeighting u-turns will have any cost (because instead of using manual u-turn checks the u-turn costs are now applied in TurnWeighting.
Is there a need for edge-based routing when there are no turn costs ? If yes should "no turn costs" also mean "u-turns are allowed (and free)" ? We can probably support this when we remove TurnWeighting, #1520.

Is there a need for edge-based routing when there are no turn costs ?

Not sure if need, but I'm currently doing it in one experiment and it works nicely, when I just want to enumerate (directed) edges rather than nodes.

If yes should "no turn costs" also mean "u-turns are allowed (and free)"

Yeees. At least that's what I would think is consistent. I mean, with node-based traversal, you can't have U-turns on shortest paths because.. well, you've already been there. But with (directed) edges.. No problem.
I like that this is an actual weight now, and not a hard constraint, but I think a default of 0 would be no problem, would it?

Alternatively, it could be (conceptually) infinity and behave like before. :)

when I just want to enumerate (directed) edges rather than nodes.

you mean you are looking at the discovered edges when running dijkstra or something ?
I don't think there is a real reason to not be able to run an edge-based algorithm without turn costs. I just spent an hour wondering why I was always getting u-turns (although I was using edge_based=true) until I figured out that my encoder did not use turn_costs=true and thought it would be better to get an error in this case (#1696). To make it crystal clear we would need edge_based=true&turn_costs=false ?. I think there are a few places where we do not clearly make a distinction between edge_based=true and (the hypothetical) turn_costs=true (as request parameter).

I'm not even sure why edge_based is on the API at all. I mean, from that layer, it's an implementation detail. We must know when we need to use which algorithm. In particular, when there are non-zero turn-costs.
Why do we let the user decide that?

On the other hand, on the Java layer, it does make a difference, because there I get different things into my shortest-path tree.

you mean you are looking at the discovered edges when running dijkstra or something ?

Yeah, exactly.

I'm not even sure why edge_based is on the API at all.

I think I agree. edge_based is also very technical and its rather counter-intuitive one has to set edge_based=true to enable 'turn costs'. Maybe this parameter should be called turn_costs=true. But then how would you enable edge based routing without turn costs ?
To make matters a bit more complicated there is also a traversal_mode parameter (but it is overwritten by the edge_based parameter)...

I opened #1698 for the question about edge-based without turn_costs. The (probably more urgent) issue here is to prevent the error that we are currently getting without setting edge_based=false.

Puh this all seems rather tricky (sorry long post)...
When we make a request we basically have these parameters that are relevant to the algorithm selection (I am leaving out the traversal_mode parameter for now, because it does not do anything the edge_based parameter cannot do).

edge_based=true/false/not set
choose a vehicle
enable/disable CH

Choosing the vehicle makes a difference, because we check encoder.supports(TurnWeighting.class), which is the same as checking whether or not the encoder was specified with |turn_costs=true, and use the result to determine the algorithm.
But what do we even expect ?  Let's have a look at this table:

edge_based
encoder supports turn costs
expected without CH
expected with CH

not set
false
what should be the default ? node-based ?
node-based! (there is no edge-based CH)

not set
true
what should be the default? edge-based because the encoder supports turn costs ?
what should be the default ? node-based because its faster ?

false
false
node-based
node-based

false
true
node-based
node-based

true
false
error ? or edge-based without turn costs ?
error! (no CH profile)

true
true
edge-based, with turn costs
edge-based, with turn costs

With CH we are a bit more constrained than without: When an encoder supports turn costs there can be two different CH profiles (one for edge-based and one for node-based). So we can still ask whether or not the chosen encoder/vehicle supports turn costs or not, but just because we use car|turn_costs=true it does not mean that we are (only) interested in edge-based routing, because we have to specify it like this even when we want both node- and edge-based CH... Therefore using this information to determine the traversal mode for the algorithm seems wrong to me.
In the current state it is even more intricate: The traversalMode field in GraphHopper asks whether or not some of the encoders supports turn costs (this is what this issue is about), but in my opinion this should not be considered at all and even without this its not entirely clear to me what we expect in the different cases.
I think it is important that specifying ch.disable=true/false does not change whether or not turn costs are applied or not (the algorithm should just do the same except faster/slower). So from this point of view it seems reasonable to use the expectations we have for CH ?!
I am hoping we can simplify the whole matter when we no longer look at the vehicle to determine the traversal mode: So what if we did this:

edge_based=false -> node-based routing
edge_based=true -> edge-based routing

Looks simple, but what are the corner cases ?

did not specify edge_based at all
edge_based=true/false and CH is enabled, but no corresponding profile is present
edge_based=true but no turn cost extension for this vehicle

regarding 1): if edge_based is not specified we need to use some default. node-based is faster, edge-based supports turn-costs, IMO we cannot know what is the 'better' default. So lets make this configurable in config.yml via a new property defaultTraversalMode. Maybe we can add a special value auto that determines a good default (like in 2) and 3)). btw to have 'not specified' with a post request (#1689) we need to allow null.
regarding 2): when there is no CH profile for the settings that were used we should simply get an error. but there is an ugly special case: e.g. when only one profile is used (say car|edge) and the default for edge_based is different to this (say edge_based=false) we get an error, this is #1637.
regarding 3): throw an error.
tldr
To make the algorithm selection consistent between CH/non-CH and make the behavior more transparent I suggest to:

remove all the encoder.supports(TurnWeighting.class) checks that are used to determine the traversal mode. This includes the traversalMode field in GraphHopper (I mentioned already).
remove the traversalMode request parameter (save it for later, #1698)
add a new property defaultTraversalMode with an auto option to `config.yml'

Actually, I think ch.disable should go away as well. Or at least be demoted to something unimportant, where there's never an error if this option isn't specified at all. The default should be picked based on what's possible and necessary to satisfy the user's question.
So when the user asks for least-cost path with turn costs on bikes, then we should pick our fastest algorithm that supports least-cost paths with turn costs on bikes. Only if answering the user's question isn't possible should there be an error.
I define "different algorithms" as "different ways of solving the same problem (same input -> same output)". I'm not sure why the API user should have a say in that. It is fine as a technical parameter, of course, for experiments, debugging, and such. But we should never be required to set it to get a specific result.

I think ch.disable should go away as well.

GraphHopper documentation mentions several cases which can work only without CH (e.g. heading, alternative routes).

The default should be picked based on what's possible and necessary to satisfy the user's question.

So mean that the requests can be inspected and the proper mode be selected afterwards based on their parameters?

GraphHopper documentation mentions several cases which can work only without CH (e.g. heading, alternative routes).

Exactly my point.
If you look at Google's API, for instance -- they don't mention the algorithms they use. They just mention the problems they solve. So you can pick "our best estimate of travel time, considering current traffic", which probably requires a much more expensive algorithm, so it is more expensive.
But you pick the problem you want to solve, not the way it is solved.


Make commit status creation into an option, rather than always.

This adds per-project and global options to create GitHub commit statuses. We use a lot of pull request triggers for things that don't actually trigger test runs or app code "builds", and so these lead to a lot of pull request status noise if ghprb-plugin creates statuses each time.
No test coverage yet beyond making the existing test suite work. I don't have the time right now to spin up on adding a new test.
Thanks!

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

This appears to be a duplicate of https://github.com/janinko/ghprb/pull/243

I'm not sure what's causing these to fail, it was passing locally. @s0undt3ch any interest in helping this get through? :)

The test suite uses anonymous calls to GitHub which are throttled. Close and re-open to trigger another build.

Thanks. It's stale now, I'll update soon...


remove seccompProfile

part of https://github.com/kiali/kiali/issues/5409

this works on 4.11... will next test on 4.10

works on 4.10, too.


Update create-auto-stopping-rules-for-terraform.md

Harness Developer Pull Request
all tf examples use different versions, none match the version the docs have you download
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Preview environment: https://ci.pr.harness.io/pr-669


Revert "Add generation of enum array in query"

Reverts microsoft/kiota#4226
From conversation at https://github.com/microsoftgraph/msgraph-sdk-typescript/pull/512

The select,expand and orderBy parameters are small set though so the change could be made relatively quickly.
In my head, reverting this PR was going to always be a temporary measure, given that Kiota is technically doing the right thing.
I can close this for now and let this get sorted out at the metadata end.

(please keep the branch for now, I have queued typescript generation)


Library does not work with android.app.Fragment, only with android.support.v4.app.Fragment

Library does not work with android.app.Fragment, only with android.support.v4.app.Fragment

@pepe-pa using the support library is considered best practice, could you provide some more information as to why that does not work for your application>

Yes, of course, but with minApiLevel 15 it is not necessary to use support fragment and system permission system does not work only with support Fragments

The minSdk of this library is 9.  I would suggest using android.support.v4.Fragment in your app rather than changing this library to support system Fragments (which I do not intend to do currently).

how about Preference Fragment?

@k0shk0sh not currently supported but that's a valid feature request.  I'll open a new issue for that.

@pepe-pa @k0shk0sh as of #21 this library now works with android.app.Fragment


Feature request: installer script, or .app bundle

https://github.com/shockone/black-screen/releases/tag/v0.0.1

Please read https://github.com/shockone/black-screen#installation for an instruction how to install from source.


Cannot group tests by category/traits

I am adding properties to the tests, but they are not showing up in Test Explorer. You can also not add multiple properties, so tests with multiple categories cannot work.

This is blocked by dotnet/cli#2252

This is reported fixed in VS 2015 Update 3. Need to test in this project.


Roll Flutter Engine from 8d51b64e9440 to 40aee62d7d39 (4 revisions)

https://github.com/flutter/engine/compare/8d51b64e9440...40aee62d7d39
2023-10-18<EMAIL_ADDRESS>Roll Skia from d561b276b5d9 to 85971b25cf4b (1 revision) (flutter/engine#47076)
2023-10-18<EMAIL_ADDRESS>[Impeller] Guard execution of ReactorGLES operations with a mutex (flutter/engine#47068)
2023-10-18<EMAIL_ADDRESS>[Impeller] Document ReactorGLES. (flutter/engine#47070)
2023-10-18<EMAIL_ADDRESS>[web] Ensure handled key event is not propagated to IME (flutter/engine#46829)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jimgraham@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


fix(ast): put decorators before everything else.

Won't fix #4142
It is similar to #3994 but for those types that weren't relying on this order. It seems to be the right order.
technically speaking it is a breaking change but I know as a fact that it won't have a big difference on our downstream. If you want it to be chronically correct feel free to merge as a breaking change.

#4143  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rzvxa and the rest of your teammates on  Graphite

LOVE the fact that we don't need to touch all the boilerplate code anymore, it wasn't even possible last week.


Remove docker dependency for build_and_extract_is_noop test

We use docker only to pull the ubuntu:latest image, which can be done by a combination of skopeo and umoci:
something like
skopeo copy docker://ubuntu:jammy oci:oci:ubuntu
^ copy ubuntu:jammy into image called 'ubuntu' in directory 'oci/'
umoci unpack --rootless --image oci:ubuntu ubuntu
^ unpack the image called "ubuntu" in directory oci/ into directory ubuntu/rootfs/

We can store the ubuntu image and unpack the rootfs into $XDG_DATA_HOME/puzzlefs (defaults to $HOME/.local/share)


I can not read numbers

When I calculate for example 13000/30, I see that

I can not read the first numbers,

I suggest to specify the decimal number like that

Hmm, I think you mean not all numbers are present since the result is larger and you need to scroll for that. For that I will probably provide a font setting in the near future. See issue #48
But I do not understand that you show a screenshot of precision setting which has nothing to do with it.
Anyway, thanks for your report @heberjeur

Yes, sorry for my bad English

Results are left aligned as of v1.1.2 . Can be changed in settings as well. #107


Update windows.yml (allow ghc downgrade)

I think I found a fix in #2144. Thanks @angerman for your help.


SignUP UI Improvement

#1
There is a user Signup  page, app/sign-up/page.js , Your Task is to make it Better
Comment below /Attempting and Start working on it

Please assign me the issue

I would like to work on it.

Go On,
All the Best.
After Contributing Please Add your data in    Contributing

/Attempting #10

All the Best.
After Contributing Make shure to  Add your data in Contributing

/Attempting #10

All the Best.
After Contributing Make shure to Add your details in Contributing/README.md

Can you assign me this task?

All the Best.
After Contributing Make shure to Add your details in Contributing/README.md


fix: update to eye v4.13.3

fix: update to eye v4.13.3

:tada: This PR is included in version 6.3.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v6.3.3

Your semantic-release bot :package::rocket:


use tweaked tm-db

I think that if each validator on the testnet applies this version of tm-db, block times will be reduced further.
Little information about that build of tm-db:
It is much faster. We currently use it on our osmosis validator, our Juno validator and our evmos validator so it is quite fair to say that it is tested, but because it is a giant PR, it has not been merged into tm-db and can't really blame them for that.  The majority of the work comes from Notional and Terra.
In addition to that, this is what we used to host our RPCs. The feedback that we get from RPC users is that ours perform extremely well and I think that this is why.  So that's about another 100 nodes that use this successfully.
Likely of particular interest, is the fact that this made it possible for a number of evmos validators and evmos rpc providers to actually stay in sync up to the tip of the chain.

closing this out in favor of seidb project we're releasing


Added line to systemd config template to start Nebula before sshd

During shutdown, this will keep Nebula alive until after sshd is finished. This cleanly terminates ssh clients accessing a server over a Nebula tunnel. h/t @nbrownus
I tested this on Ubuntu 20.04.1 LTS and Raspbian GNU/Linux 10 (buster).

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I assume that the Before= still means that sshd.service won't be blocked from starting if Nebula fails to start?

@wadey correct. I also tested this on raspbian by moving ca.crt and rebooting:
Oct 29 20:34:38 officepi nebula[428]: {"error":"unable to read pki.ca file /etc/nebula/ca.crt: open /etc/nebula/ca.crt: no such file or directory","level":"error","msg":"Failed to load ca from config","time":"2
Oct 29 20:34:38 officepi systemd[1]: nebula.service: Main process exited, code=exited, status=1/FAILURE
Oct 29 20:34:38 officepi systemd[1]: nebula.service: Failed with result 'exit-code'.
Oct 29 20:34:38 officepi sshd[477]: Server listening on <IP_ADDRESS> port 22.
Oct 29 20:34:38 officepi sshd[477]: Server listening on :: port 22.
Oct 29 20:34:38 officepi systemd[1]: Started OpenBSD Secure Shell server.

I could SSH to host on LAN without issue.


add python 3.12 to unit tests and pyauditor builds

This PR adds Python 3.12 to the unit tests and pyauditor builds.

Codecov Report

Merging #488 (0c33fff) into main (dfc8c52) will decrease coverage by 1.17%.
The diff coverage is n/a.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #488      +/-   ##
==========================================
- Coverage   56.68%   55.52%   -1.17%
==========================================
  Files          44       43       -1
  Lines        3902     3530     -372
  Branches       58        0      -58
==========================================
- Hits         2212     1960     -252
+ Misses       1690     1570     -120

Components
Coverage Δ

apel_plugin
∅ <ø> (∅)

auditor
81.72% <ø> (-0.06%)
:arrow_down:

slurm_collector
36.52% <ø> (ø)

slurm_epilog_collector
0.00% <ø> (ø)

htcondor_collector
∅ <ø> (∅)

priority_plugin
37.46% <ø> (ø)

Python 3.12 is not (yet?) included in the Windows runner:
https://github.com/actions/runner-images/blob/releases/win22/20231002/images/win/Windows2022-Readme.md#python


Create dashboard general view

Simple view of a listing/summary of the found social/appication registrations

#46 introduced just 3 simple links

Applications - from Agent Registry
Peers - Social Agents from Agent Registry
Data - Data Registrations from Data Registries

We don't need separate Access Authorizations list since those are always associated with some registered agent and this seems a more intuitive way of navigating for the user.


Fix Testnet Chainspec: make initial set invulnerable

Description of proposed changes

Practical tips for PR review & merge:

[ ] All GitHub Actions report PASS
[ ] Newly added code/functions have unit tests

[ ] Coverage tools report all newly added lines as covered
[ ] The positive scenario is exercised
[ ] Negative scenarios are exercised, e.g. assert on all possible errors
[ ] Assert on events triggered if applicable
[ ] Assert on changes made to storage if applicable

[ ] Modified behavior/functions - try to make sure above test items are covered
[ ] Integration tests are added if applicable/needed

Note to self: we can pull-in https://github.com/gluwa/creditcoin/blob/dev/integration-tests/src/test/danger-will-brick-the-blockchain.test.ts as part of this PR and/or do a bit more sanity checking. Will take another look into it once done with CSUB-978


Forum header still shows old Legacy theme search bar

This was a result of merge conflict — Sorry!


windows ImportError: No module named absl

Happy holidays to everyone,
I am using Windows 10 and when i run  command py -m pysc2.bin.agent --map Simple64
i get error
File pysc2-master\pysc2\maps\lib.py line 35 in
from absl import logging
ImportError: No module named absl
could you please help me?
Thank you, Marry Christmas and Happy new year.

sorry, i just fixed it by pip install absl-py


added quadratic equation calculator

Description 📜
I have made a quadratic equation calculator, that finds the root of the given equation. The equation must be entered through numbers A, B & C, in the respective places. It also says the nature of the root along with finding the root also points out the error while entering the Equation. Completely responsive and supports all devices
Fixes #48
Live working link
Quadratic Equation Calculator

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GSSOC'22 contributor
[x] Have you added a working link of your calculator ?

Screenshots / Gif (Optional) 📸

@Chayan-11 I have made the suggested changes. Kindly look into it.


Does scaling storage require a restart?

Does scaling storage require a restart? This doc says

Scaling vCores causes a server restart.

However, according to another doc, it says scaling storage also requires a restart.

Scaling the storage works the same way, and also requires a short restart.

Does scaling storage lead to a downtime, like connections termination or failure?

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

ID: f9a48d73-9910-d474-f382-f24948e99609
Version Independent ID: 74dbd253-1436-dfff-cb6d-2ec30a278e22
Content: Manage server - Azure portal - Azure Database for PostgreSQL - Flexible Server
Content Source: articles/postgresql/flexible-server/how-to-manage-server-portal.md
Service: postgresql
GitHub Login: @mksuni
Microsoft Alias: sumuth

@LifeRyuto Thank you for your feedback . We will investigate and update the thread.

@LifeRyuto Please check the other thread for these details:
Does scaling storage require a restart?

Thank you.

@LifeRyuto We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


[PRFC] Add backend support for Backstage events

Backstage Events
Backstage plugins and external systems connecting to Backstage would benefit from an event system. This allows reactive, push-style integrations rather than polling and synchronizing with the Backstage catalog, for example.
For the catalog in particular, #8219 describes a need for an API endpoint to expose these such events. This PRFC takes a different approach than the database table described there, instead adapting the events-backend concepts to provide a core EventService that any plugin can use.
The EventBroker and related types have been hoisted to backend-common, and backend-app-api now provides a default in-memory event service/broker. The events are published to subscribers in real-time; this does not provide any storage mechanism. I posit that storage would be achieved by replacing the in-memory event service with an external system (Pub/Sub, SQS, SNS, Kafka, etc).
For a backend using the experimental backend system, no change is needed; the core event service has a defaultFactory to create the in-memory event broker. Backends using the previous system must add an EventBroker to makeCreateEnv (and update the PluginEnvironment):
function makeCreateEnv(config: Config) {
  const root = getRootLogger();
  ...
  return (plugin: string): PluginEnvironment => {
    const logger = root.child({ type: 'plugin', plugin });
    const database = databaseManager.forPlugin(plugin);
    const cache = cacheManager.forPlugin(plugin);
    const scheduler = taskScheduler.forPlugin(plugin);
+   const eventBroker = new InMemoryEventBroker(logger);

    return {
      logger,
      permissions,
      scheduler,
      identity,
+     eventBroker,
};

Services in the new backend system can add a dependency on coreServices.events; backends using the previous system can use the eventBroker added in the environment.
This is perhaps a prerequisite for a notification system; events are discussed in #10652 in relation to notifications. This branch aims to maintain compatability with the existing events-backend rather than modifying the event shape. A new BackstageEvent type is introduced that extends the generic EventParams to add an event type and originatingEntityRef as potential Backstage-related data of interest.
Backend events have the potential to become a firehose of information, and given an external event broker this also has the potential to rack up real costs. The cost consideration is skirted by the default in-memory event broker, but it's unclear if this default is suitable for production systems. It certainly is only applicable to Backstage instances that run in a single process (e.g. not horizontally scaled to multiple pods).
The review the PR, I suggest starting with the changes in backend-common and catalog-backend. Due to moving types from events-node, there are a great deal of import-only changes.
The event type for catalog events added in this PRFC are similar to catalog permission names. It's unclear if these concepts overlap enough to consider how they might fit together.
Alternatives
Plugin extension points
I explored using extension points instead, such that events might be opt-in to enable for each plugin. For example, a plugin could expose an addEventListener extension point and only send events when event listeners are registered:
backend.add(catalogPlugin());
backend.add(catalogModuleEventsPublisher());

The downside is that each plugin must implement an extension point and corresponding publishing module, and Backstage adopters must add event publishers for each plugin. It feels like events should be a bit more built-in and require little effort on the part of plugin developers.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Thanks for the reviews @freben @Rugvip and @pjungermann! I think I addressed most of the feedback. There are two outstanding, related issues around the same piece of code (the "mother of all queries" heretofore MOAQ).
The first is that I added returning to the MOAQ, which @freben pointed out won't work in MySQL. We're trying not to intentionally make life more difficult for eventual MySQL support, should it come, so this is undesirable.
The second is that, after discussion with @freben, I added originatingEntityUid to catalog events alongside originatingEntityRef, as both may be of interest. The MOAQ deleteWithEagerPruning is the one place I haven't added the uid to events yet (see TODO).
To solve both of these, I think we essentially need to do a select-then-delete in the MOAQ instead of a straight delete, so that we can pluck off the entity_refs and uids to return without a returning clause. This is a bit scary though, certainly for me who hasn't worked closely with this piece of code before. This also seems like a riskier change than the other additions here that are opt-in and fairly innocuous additions. I've run into things in the past like WHERE IN clauses having a limit on the number of parameters supported, so I'm a bit paranoid about this kind of change to a fundamental function.
What do you think is the best way to proceed?

@timbonicus yep deleting is tricky, the way I approached it in #10115 is to separate out deletion, plugins/catalog-backend/src/processing/DefaultCatalogProcessingEngine.ts. Honestly I think for sanity it may make sense to move over to something similar to that to avoid large queries 😅

@Rugvip So https://github.com/backstage/backstage/pull/10115 essentially makes the entity_id in final_entites NULL (through foreign key onDelete) when the refresh_state row with the same entity_id is deleted by MOAQ, right? So rather than fiddle with MOAQ, we can just observe the results after the fact in the processing engine.
Makes sense to me, just want to make sure I understand correctly before taking a stab at this.

@timbonicus yep iirc 😅, along with a cleanup job that takes care of the actual deletion. There it's done with a plain interval, but I think it makes sense to do through a scheduled task instead.

bump

bump

@timbonicus Is there anything I can help you with to get this closed?
Can we extract some parts into separate PRs maybe?
E.g., exposing the EventBroker at PluginEnvironment was already merged.

@pjungermann Absolutely, would love help getting this across the line. This was a hack project that I haven't been able to get back to yet.
There are two major things in this PRFC - moving the event types into core packages, and adding catalog events. I could see separating these into two PRs, as I think the first seems to be uncontroversial in the comments here so far.
The second bit of catalog events is currently failing a bunch of database checks and needs more work due to schema changes. That's a result of stealing work from #10115 which had the same failures. Isolating those changes away from the bazillion import statement changes from moving types would be nice, though.

FYI: I will be on vacation myself, however, I plan to spend some time on it when I'm back.

@pjungermann have a good holiday!

Closing for now as this is a bit stale, PR available for reference if anyone has time to hack on this 😄


Set a rule on the config and split names

should we actually allow characters like spaces? maybe it's better to add validation for whitespace symbols and directly in datasets and raise

https://github.com/huggingface/datasets-server/issues/853

I imagine that we should stop supporting them, and help the user fix them?

See a report where the datasets server fails: https://huggingface.co/datasets/poloclub/diffusiondb/discussions/2#6374ff55b93cbdf65675f564
The config name is random_10k [2m]!


Cam -> Raspi (Homebridge) -> AppleTV -> Firewall -> iPhone (Internet) ... please help !

I have running a cam with the ffmpeg plugin.
In LAN everything is OK.
But i have problems to getthe rtsp traffic through the firewall.
From outside, when i open the room in the Home App, i get the snapshot, but when i open the cam, there is no stream. its probably blocked by the FW.
When i am outside, the log in Homebridge is as follows:
<IP_ADDRESS>: Cam
<IP_ADDRESS>: AppleTV
Feb 04 19:16:53 homebridge-raspi homebridge[16971]: -re -i rtsp://<IP_ADDRESS>:554/mjpeg.sdp -threads 0 -vcodec h264_omx -an -pix_fmt yuv420p -r 30 -f rawvideo -tune zerolatency -vf scale=640:360 -b:v 132k -bufsize 132k -payload_type 99 -ssrc 1 -f rtp -srtp_out_suite AES_CM_128_HMAC_SHA1_80 -srtp_out_params EfRDtvIzqbTENsvWutLYc9wTvgZCNT srtp://<IP_ADDRESS>:51903?rtcpport=51903&localrtcpport=51903&pkt_size=1378
so my question: is the stream established from cam through raspi through AppleTV to iPhone ?
I see blocked incoming udp packets on firewall (dst-port 16403 or 16407 or 16405) .. i think these are  ports from Apple for RTP ?....
but when in NAT this traffic to the appleTV, i still have no stream.
Has anybody a similar installation behind a firewall (i use mikrotik)
thx for help
Richard

so my question: is the stream established from cam through raspi through AppleTV to iPhone ?

yes and no
cam streams to AppleTV (the hub) that has an (already established) IPv6 tunnel to iPhone through Apple cloud servers
the actual technology/infrastructure/frameworks/library used is the same as FaceTime
so there should be no problem being behind a nat/firewall
can't remember if 6on4 tunnel uses tcp or udp
and still don't know what happens if both iPhone and AppleTV, or cam, are on IPv6 or WAN (in such a case a direct streaming is possible without fancy nat/firewall punching...)

i have internal disabled ipV6 .... should i enable this ?

no, it's not necessary, everything is supposed to work over IPv4
anyway does your mobile provider use IPv6?

ok, facetime works without problem......
what now ?
Richard

so it's very unlikely that's a firewall/nat problem
anyway you can still try disabling firewall just for testing purposes!
do you have other homekit/homebridge devices? do they work from remote?

i use homebridge-homematic plug in ... all devices works perfectly
ATV ist the latest 4k modell
initiating the stream from external i see always this in FW log:
09:48:38 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:46 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:47 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:48 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:49 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:50 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:51 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:52 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:54 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:55 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:57 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80  09:48:58 firewall,info drop-not-LAN-packets input: in:ether1_WAN out:(unknown 0), src-mac 00:01:5c:22:78:81, proto UDP, <IP_ADDRESS>:55688->212.286.51.125:16403, len 80
212.286.51.125 is my external IP
even when i forward all UDP traffic ... no change
even when i port forward UDP Port 16403 to internal IP ATV Port 16403 - no change

disable firewall and try again

so..... with FW deactivated it works.. but this is not an option ;-)
Here the log ... initiated the stream from external (iPhone on LTE).
No video until it shows "camera not available" in Home App
syslog.txt
Hope the log can help to find the problem :-)
Richard

found the following........
My ports for the two cams are: 42819, 34253
when i do a netstat -lnpt i see this ports listening tcp6 ?? tcp6 is disbaled on my router ... why ?
pi@homebridge-raspi:~ $ netstat -lnpt (Not all processes could be identified, non-owned process info  will not be shown, you would have to be root to see it all.) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name tcp        0      0 <IP_ADDRESS>:9090       <IP_ADDRESS>:*               LISTEN      - tcp        0      0 <IP_ADDRESS>:22              <IP_ADDRESS>:*               LISTEN      - tcp6       0      0 :::41313                :::*                    LISTEN      - tcp6       0      0 :::40003                :::*                    LISTEN      - tcp6       0      0 :::42819                :::*                    LISTEN      - tcp6       0      0 :::18088                :::*                    LISTEN      - tcp6       0      0 :::44137                :::*                    LISTEN      - tcp6       0      0 :::18089                :::*                    LISTEN      - tcp6       0      0 :::38635                :::*                    LISTEN      - tcp6       0      0 :::34253                :::*                    LISTEN      - tcp6       0      0 :::45135                :::*                    LISTEN      - tcp6       0      0 :::39377                :::*                    LISTEN      - tcp6       0      0 :::51826                :::*                    LISTEN      - tcp6       0      0 :::22                   :::*                    LISTEN      - tcp6       0      0 :::44221                :::*                    LISTEN      - tcp6       0      0 :::43581                :::*                    LISTEN      - tcp6       0      0 :::33823                :::*                    LISTEN      -

Disabling IPv6 on router basically means two things

the router doesn't route ip6
the router doesn't assign routable ip6 addresses to clients

The IPv6 stack has to be eventually enabled/disabled on the clients themselves, and if enabled they auto assign local addresses, i.e. addresses that work only on local lan.

so..... with FW deactivated it works.. but this is not an option ;-)
Here the log ... initiated the stream from external (iPhone on LTE).
No video until it shows "camera not available" in Home App
syslog.txt
Hope the log can help to find the problem :-)
Richard

from your log everything between cam, ffmpeg and <IP_ADDRESS> (AppleTV?) works fine

yes .... .244 is appleTV
so its a firewall problem ?

i have only one NAT rule .... masquerade WAN
thats it .... hmmmmmm

problem solved ;-)
it was the "up" Cache from my Internet Modem.
Modem reset .... and everything works fine now .....
Richard


Fix #1174 TemplateGenerator fail to parse template Fn::Sub with variable

Fix #1174
TemplateGenerator was unable to load a template who contains a Fn::Sub with variables
Sample:
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Resources": {
    "MySNS":{
      "Type" : "AWS::SNS::Topic",
      "Properties" : {
        "DisplayName" : "Display Name",
        "TopicName" : {
          "Fn::Sub": [ "MySNS-Test-${ABC}",
            {
              "ABC": "abc"
            }
          ]
        }
      }
    }
  }
}

The issue come from the definition of function Sub
As define here:
https://github.com/cloudtools/troposphere/blob/91dc3b5f8916b96ead45783c58d24ce7305c1701/troposphere/__init__.py#L474-L478
When the function is call from the TemplateGenerator, it will always have one or two arguments, never more, and if the second argument are present, it will be a dict (and it's dict are not unpackaged)
exemple:
Sub('MySNS-Test-${ABC}-${DEF}', { 'ABC': 'abc', 'DEF': 'def' })

When the function is call from the unit-tests, the second argument are unpackaged
https://github.com/cloudtools/troposphere/blob/91dc3b5f8916b96ead45783c58d24ce7305c1701/tests/test_basic.py#L406-L423
This is equivalent of:
Sub('MySNS-Test-${ABC}-${DEF}', ABC='abc', DEF='def')

So, how should we fix it ?
If we change Sub to
def __init__(self, input_str, *values):

the template generator will work fine, but we will have a broking change!
We can also supporte both of them with more code:
class Sub(AWSHelperFn):
    def __init__(self, input_str, dict_values=None, **values):
        # merge dict
        if dict_values:
            values.update(dict_values)
        self.data = {'Fn::Sub': [input_str, values] if values else input_str}

Any suggest ? Any comment ?

Is this getting merged soon?
Would this explain why !Sub 'arn:aws:s3:::${BucketName}/* where BucketName is parameter does not work?

Hey - sorry for the delay here, I haven't been super involved in the TemplateGenerator stuff, so had to spend some time familiarizing myself.  This looks good to me - going to go ahead and merge!  Thanks!


Add lerna_v1.1.x.js definition

@thejameskyle -- mind giving this a review?

Woah, what are you using this for?


Adding support to shared tables

The Redshift extractor works by first discovering what tables and views are available to sync. This is done by querying information_schema to get table names, columns, etc. However, metadata on shared table views are not available so the extractor fails. Additionally, shared table is set up in its own database on Redshift and we cannot connect to it directly.
Cannot connect to shared database "...". Connect to the databases in your cluster instead and use cross-database query notation .

So in this PR we are replacing the INFORMATION_SCHEMA.Tables by SVV_ALL_TABLES and replacing INFORMATION_SCHEMA.Columns by SVV_ALL_COLUMNS that shows shared table information.
The only limitation that we still have is that we still didn't get the table constraints/PKs for shared tables.

@ytanaka6174 has executed the tests.
https://nosaraproject.wordpress.com/2022/11/17/sdp-limitations-with-meltano-redshift-extractor/#comment-18133


Fix our enums

Here are changes that are not really part of the enum change, or are just follow-on changes:

source\android\...\objectmodel\*: SWIG'd changes
source\android\...\renderer\registration\CardRendererRegistration.java: Slight change to how object model is projected
source\ios\*: changes for build
source\shared\cpp\.clang-format: auto-format escaped newlines
ColumnSet.h: remove unused std::unordered_map<> member
FactSet.cpp: use const
SharedAdaptiveCard.cpp: create local var to make it clear what's happening (cppcoreguidelines rule)
Util.h: remove using statement that would leak our namespace usage, fix namespacing
Util.cpp: add missing using statement, fix up namespacing, add const
uwp\renderer\lib\util.h: fix namespacing (previously leaked here by shared model's Util.h)
pch.h: add Enums.h to save on build perf
EverythingBagel.json: mix a couple of cases for values to make sure enum mapping is case insensitive

Why?
Enums.[cpp|h] is a bit tricky from an authoring perspective. It's easy to copy/paste the wrong thing and end up with incorrect behavior. It's also difficult to make changes across the entirety of enums usage without lots of editor heavy lifting.
I recently found a minor mistake that caused our enums to be copy constructed every time a lookup is performed. After initially fixing the problem by robofixing all of our implementations, it became clear that this was an unsustainable model. To that end, I've redone our enums with an eye towards maintainability.
The Problem Space
The problem that we need to solve breaks down like this: C++ doesn't have native support for mapping enum values <-> string representations of enum values. This is a problem for us because we need to be able to perform this mapping in both directions to support serialization and deserialization. Unfortunately, the STL doesn't provide a data structure that can provide this functionality. So instead, we have to maintain two std::unordered_map<>s -- one mapping from the enum type to a string, and the other providing mapping in the other direction. We could just use one map, but then we would have O(1) lookup in one direction, and O(N) lookup in the other, which isn't ideal.
It's worth noting that there are a couple of cases where the mapping isn't 1:1 -- there are a couple of enums where we map additional string(s) to an enum value for backwards compatibility reasons (see e.g. ImageSize).
The Old Way
The way that this previously worked was that we had a series of Get*EnumMappings() functions that had static instances of maps. The mapping from enum type to string was handled via a hand-rolled initializer list. Mapping in the other direction was either generated via the GenerateStringToEnumMap<>() function (1:1 mapping case) or was likewise hand-rolled (back-compat case). Get*EnumMappings() would hand out copies of our unordered_maps to callers. Those callers? Hand-rolled *FromString() and *ToString() functions. The *FromString() functions were responsible for handling what to do in the case of a string that wasn't in the map. This handling falls into three classes:

Throw an exception
Return *::Default
Return some other enum value as the default

To be crystal clear: If one needs to add a new enum in this system, one must:

Create a new enum class in Enums.h
Add forward declarations for *ToString() and *FromString() functions in Enums.h
Create Get*EnumMappings() function in Enums.cpp
Create *ToString() function in Enums.cpp
Create *FromString() function in Enums.cpp

Old Example
Enums.h:
enum class ImageStyle
{
    Default = 0,
    Person
};
const std::string ImageStyleToString(ImageStyle style);
ImageStyle ImageStyleFromString(const std::string& style);

Enums.cpp:
void GetImageStyleEnumMappings(std::unordered_map<ImageStyle, std::string, EnumHash>* imageStyleEnumToNameOut,
                               std::unordered_map<std::string, ImageStyle, CaseInsensitiveHash, CaseInsensitiveEqualTo>* imageStyleNameToEnumOut)
{
    static std::unordered_map<ImageStyle, std::string, EnumHash> imageStyleEnumToName = {{ImageStyle::Default, "default"},
                                                                                {ImageStyle::Person, "person"}};

    static std::unordered_map<std::string, ImageStyle, CaseInsensitiveHash, CaseInsensitiveEqualTo> imageStyleNameToEnum = {
        {"default", ImageStyle::Default},
        {"person", ImageStyle::Person},
        {"normal", ImageStyle::Default} // Back compat to support "Normal" for "Default" for pre V1.0 payloads
    };

    if (imageStyleEnumToNameOut != nullptr)
    {
        *imageStyleEnumToNameOut = imageStyleEnumToName;
    }

    if (imageStyleNameToEnumOut != nullptr)
    {
        *imageStyleNameToEnumOut = imageStyleNameToEnum;
    }
}

const std::string ImageStyleToString(ImageStyle style)
{
    std::unordered_map<ImageStyle, std::string, EnumHash> imageStyleEnumToName;
    GetImageStyleEnumMappings(&imageStyleEnumToName, nullptr);

    if (imageStyleEnumToName.find(style) == imageStyleEnumToName.end())
    {
        throw std::out_of_range("Invalid ImageStyle style");
    }
    return imageStyleEnumToName[style];
}

ImageStyle ImageStyleFromString(const std::string& style)
{
    std::unordered_map<std::string, ImageStyle, CaseInsensitiveHash, CaseInsensitiveEqualTo> imageStyleNameToEnum;
    GetImageStyleEnumMappings(nullptr, &imageStyleNameToEnum);

    if (imageStyleNameToEnum.find(style) == imageStyleNameToEnum.end())
    {
        return ImageStyle::Default;
    }

    return imageStyleNameToEnum[style];
}

The Magic
The core set of changes to get us out of dealing with enums comes from the contents of EnumMagic.h. Its contents can be broken down into these parts:

A templated class, EnumMapping<>, responsible for constructing and providing access to our two maps.

Can be constructed either with a single initializer list, which generates both maps (1:1 case), or with two initializer lists, which will create the string to enum map as the union of the reverse mapping and the supplied list.

A macro, DECLARE_ADAPTIVECARD_ENUM, which provides forward declarations of our mapping functions
A set of macros for defining our mapping functions

_DEFINE_ADAPTIVECARD_ENUM_INVARIANT: Helper macro used by other DEFINE_* macros. Supplies implementations that don't vary by enum style.

Generated function to provide access to the appropriate static const EnumMapping<> instance, named get*Enum()
Generated *ToString() function

DEFINE_ADAPTIVECARD_ENUM_THROW: Defines *FromString() function that throws an exception if supplied string doesn't map
DEFINE_ADAPTIVECARD_ENUM_DEFAULT: Defines *FromString() function that returns a specified default value if supplied string doesn't map
DEFINE_ADAPTIVECARD_ENUM: Defines *FromString() function that returns ENUM::Default if supplied string doesn't map

The New Way
Adding an enum in the new system looks like this:
Enums.h
enum class NewThingy
{
    thing1,
    thing2,
    Default
}
DECLARE_ADAPTIVECARD_ENUM(NewThingy); // provides all necessary fwd decls

Enums.cpp
In the case where there exists NewThingy::Default:
DEFINE_ADAPTIVECARD_ENUM(NewThingy, {
    { NewThingy::thing1, "thing1" },
    { NewThingy::thing2, "thing2" },
    { NewThingy::Default, "Default" }});

That's it!
If there's no ::Default, it might look something like this (here we're saying that NewThingy::thing1 should be used as the default):
DEFINE_ADAPTIVECARD_ENUM_DEFAULT(NewThingy, NewThingy::thing1, {
    { NewThingy::thing1, "thing1" },
    { NewThingy::thing2, "thing2" }});

If you need to supply a list of additional mappings for back-compat:
DEFINE_ADAPTIVECARD_ENUM(ImageStyle, {
    {
        { NewThingy::thing1, "thing1" },
        { NewThingy::thing2, "thing2" }
    },
    {
        {"normal", NewThingy::thing1} // NB: other reverse mappings computed automatically
    }});

Or if you need to throw on a failed mapping, it would look like this:
DEFINE_ADAPTIVECARD_ENUM_THROW(NewThingy, {
    { NewThingy::thing1, "thing1" },
    { NewThingy::thing2, "thing2" }});

Our ImageStyle example from above in new form
Enums.h:
enum class ImageStyle
{
    Default = 0,
    Person
};
DECLARE_ADAPTIVECARD_ENUM(ImageStyle);

Enums.cpp:
    DEFINE_ADAPTIVECARD_ENUM(ImageStyle, {
            {
                {ImageStyle::Default, "default"},
                {ImageStyle::Person, "person"}
            },
            {
                {"normal", ImageStyle::Default} // Back compat to support "Normal" for "Default" for pre V1.0 payloads
            }});

Conclusion
Benefits

In developing this change, I took some (admittedly unscientific) perf stats. Overall runtime for our unit tests (run in serial, N=12) came down about 10% with this change.
Future improvements can be made across all of our enums without having to edit every single function
No chance of a whoopsie where a new enum is added that doesn't have the same behavior as all of the others

Downsides
As with anything, there are tradeoffs:

Somewhat slower build time (due to heavy use of macros and templates)
Less debuggable than the hand-rolled versions, at least in Visual Studio
If a new class of enum or new scenario arises, we may have to write some new macros, and they can be a bit of a pain

Anyone else care to look?


Add optional UMI handling

From @ewels on August 21, 2017 8:46
It would be nice to add optional handling of UMIs, probably using this project: https://github.com/CGATOxford/UMI-tools
Copied from original issue: SciLifeLab/NGI-RNAseq#145

Thanks @TomSmithCGAT! Yes I was just reading over it this morning. I particularly like the TL;DR; section at the top 😉
Whilst the single-cell / 10X analysis looks great, we're not currently running single cell projects in our facility so I think that we should probably keep things simple and just run umi_tools extract and umi_tools dedup if the pipeline is run with --bc-pattern. To be honest, my gut feeling is that single-cell data is different enough to warrant a totally separate pipeline anyway.
Phil

From @TomSmithCGAT on August 21, 2017 9:31
Hi @ewels - Let us know how you get on integrating UMI-tools into your pipeline. Very happy to help out via GitHub issues if you have any questions/issues etc
If you haven't already seen it, we have just released a quick scRNA-Seq tutorial: https://github.com/CGATOxford/UMI-tools/blob/master/doc/Single_cell_tutorial.md

From @TomSmithCGAT on August 21, 2017 10:8
Oh yeah, I'd assumed you were wanting to support UMIs for bulk RNA-Seq. Agree a separate pipeline is the best approach for scRNA-Seq.
I sporadically check who the new github stars are from (the speed was just by chance!). I saw you were at SciLife so I searched for "UMI-tools" in the organisation's github just to see what you were using UMI-tools for as we don't really have a very good idea what our user base actually is. We only really hear from people who have issues/questions etc - hopefully that's not everyone!

ps. How did you find this issue so quickly..??

Aha, ok good to know - I was wondering if there was some magic notification service that I wasn't aware of 😉

From @TomSmithCGAT on August 21, 2017 13:17
No, that would be brilliant though!

Can we close this issue now @grst due to the work you done in #435?

Yes, this is resolved. Too bad auto-close only works on the master branch...


Google thinks we have too many versions of each page because of locale-switching

https://pennydreadfulmagic.com/people/bakert99 and https://pennydreadfulmagic.com/people/bakert99?locale=en and https://pennydreadfulmagic.com/people/bakert99?locale=sv and https://pennydreadfulmagic.com/people/bakert99?locale=ru, etc.
We should either (a) change how locale switching works (probably best), or (b) put something in the head to let google know the non-localized version is canonical.

Switching it to a POST request is definitely the correct solution here


harcoded https

Fix issue https://github.com/SamirHodzic/ngx-embed-video/issues/9

Seems good, let me just check and fix this Travis issue.

it seems there are issues with dailymotion API but not related to this PR

Thanks 👍


Please add Parplexity API capability

https://www.perplexity.ai/ https://api.perplexity.ai/chat/completions
Perplexity is a popular AI service with its LLMs. Having it with llm as a plugin will add much value to the project.
I tried to API into Perplexity pretending it's OpenAI API, but no go as for now...

I've been looking for an opportunity to shoot a YouTube video showing how to build a plugin, so I think llm-perplexity might be the right plugin for that!

This is great @simonw ! You can close indeed, works!


[Tracking] Partial parsing polish

This is the list of work we want to complete to polish off partial parsing before we put it down and GA the v0.20.0 release
Todo:

[ ] TBD: @gshank and @kwigley to create checklist and create issues for those items

This is the list of work we want to complete to polish off partial parsing before we put it down and GA the v0.20.0 release
Todo:

[ ] TBD: @gshank and @kwigley to create checklist

Handle doc references
Test macros
Test data tests, analyses
Test snapshots
Test seeds -- what happens with big files?
Test disabled/enabled
More logging, event data, including flag that partial parsing is actually happening
More granular handling of dbt_project.yml file (hooks, etc)
Minimum validation of yaml file: expected keys point to lists containing dictionaries with 'name' key
Figure out what's going on with to_dict and schema_source_file (pp_dict is supposed to be skipped but isn't)
Make all file_id methods properties so we are consistent in how they're called

Thanks so much for the enumeration @gshank. Let's organize these into three priority groups:

p0: Add test cases, handle buggy behavior (i.e. errors that brick entire parse)
p1: Fast-but-wrong edge cases (e.g. changes to docs, nested macros, vars, env vars, "volatile" Jinja context variables)
p2: Correct-but-slower-than-strictly-necessary cases (e.g. changes to profile/target, certain behavior around vars)

Some known edge cases:

Nested macro dependencies (gist)
Volatile Jinja variable dependencies (gist)

Handling of vars, env variables, etc.

We should split this up into more subtasks, and I think some of those subtasks should actually be p1s: dependencies on nested macros, env vars, and volatile Jinja variables are fast-and-incorrect today.

I'm going to close this, given that it's the end of the cycle and we managed to hit all our P0s. Nice work team!


Codeship does not fail when mup deploy fails

In Codeship I have configured deployment via a custom script with the content mup deploy. I use mup 0.9.6.
Here is the log of a failing deploy where Codeship still reports success: https://gist.github.com/Sanjo/6c702cd17db1ab5422e7.
How can I make Codeship fail when this happens?

May be we are not sending proper exit codes when deploy failed. Need to
check.
On 2015 මාර්තු 20, සිකු at පෙ.ව. 9.22 Jonas Aschenbrenner <
<EMAIL_ADDRESS>wrote:

In Codeship I have configured deployment via a custom script with the
content mup deploy.
Here is the log of a failing deploy where Codeship still reports success:
https://gist.github.com/Sanjo/6c702cd17db1ab5422e7.
How can I make Codeship fail when this happens?
—
Reply to this email directly or view it on GitHub
https://github.com/arunoda/meteor-up/issues/324.

Glad, if you can look at it.
On 2015 මාර්තු 20, සිකු at පෙ.ව. 9.23 Arunoda Susiripala <
<EMAIL_ADDRESS>wrote:

May be we are not sending proper exit codes when deploy failed. Need to
check.
On 2015 මාර්තු 20, සිකු at පෙ.ව. 9.22 Jonas Aschenbrenner <
<EMAIL_ADDRESS>wrote:

In Codeship I have configured deployment via a custom script with the
content mup deploy.
Here is the log of a failing deploy where Codeship still reports success:
https://gist.github.com/Sanjo/6c702cd17db1ab5422e7.
How can I make Codeship fail when this happens?
—
Reply to this email directly or view it on GitHub
https://github.com/arunoda/meteor-up/issues/324.


when touching an object, also touch the actable object (fix #87)

I couldnt write a spec for this case because I couldn't expect a call to super

The canonical repo for this gem is https://github.com/krautcomputing/active_record-acts_as
Could you file an issue there with a code example please?


add tag filter for project list

@Roshanjossey that's check this feature.

@genexu, Gimme a little time to review this

@genexu, Can you change filter logic such that only projects having all the tags are displayed?
This is the pattern I see in most filters and what user will be familiar with.

@Roshanjossey, update completed. sorry for my late response, quite busy recently.

Awesome @genexu, Merging this PR. We'll be working on a bit of styling changes soon


[V4][Android]🔧 sdk 33 no more supported

How were you trying to build the app?
I upgraded from v3 to v4 and now when I try to run the application the build fail asking to increase the compileSdkVersion to 34.
I'm using the feature code scanner
Full build logs
Execution failed for task ':app:checkProdDebugAarMetadata'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckAarMetadataWorkAction
   > 7 issues were found when checking AAR metadata:

       1.  Dependency 'androidx.camera:camera-extensions:1.4.0-alpha04' requires libraries and applications that
           depend on it to compile against version 34 or later of the
           Android APIs.

           :app is currently compiled against android-33.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.4.2 is 33.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 34, then update this project to use
           compileSdkVerion of at least 34.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       2.  Dependency 'androidx.camera:camera-video:1.4.0-alpha04' requires libraries and applications that
           depend on it to compile against version 34 or later of the
           Android APIs.

           :app is currently compiled against android-33.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.4.2 is 33.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 34, then update this project to use
           compileSdkVerion of at least 34.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       3.  Dependency 'androidx.camera:camera-lifecycle:1.4.0-alpha04' requires libraries and applications that
           depend on it to compile against version 34 or later of the
           Android APIs.

           :app is currently compiled against android-33.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.4.2 is 33.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 34, then update this project to use
           compileSdkVerion of at least 34.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       4.  Dependency 'androidx.camera:camera-camera2:1.4.0-alpha04' requires libraries and applications that
           depend on it to compile against version 34 or later of the
           Android APIs.

           :app is currently compiled against android-33.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.4.2 is 33.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 34, then update this project to use
           compileSdkVerion of at least 34.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       5.  Dependency 'androidx.camera:camera-core:1.4.0-alpha04' requires libraries and applications that
           depend on it to compile against version 34 or later of the
           Android APIs.

           :app is currently compiled against android-33.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.4.2 is 33.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 34, then update this project to use
           compileSdkVerion of at least 34.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       6.  Dependency 'androidx.camera:camera-view:1.4.0-alpha04' requires libraries and applications that
           depend on it to compile against version 34 or later of the
           Android APIs.

           :app is currently compiled against android-33.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.4.2 is 33.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 34, then update this project to use
           compileSdkVerion of at least 34.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       7.  Dependency 'androidx.annotation:annotation-experimental:1.4.0' requires libraries and applications that
           depend on it to compile against version 34 or later of the
           Android APIs.

           :app is currently compiled against android-33.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.4.2 is 33.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 34, then update this project to use
           compileSdkVerion of at least 34.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

Project dependencies
"dependencies": {
    "@invertase/react-native-apple-authentication": "^2.2.2",
    "@react-native-async-storage/async-storage": "^1.19.3",
    "@react-native-firebase/app": "^19.2.2",
    "@react-native-firebase/app-check": "^19.2.2",
    "@react-native-firebase/auth": "^19.2.2",
    "@react-native-firebase/crashlytics": "^19.2.2",
    "@react-native-firebase/firestore": "^19.2.2",
    "@react-native-firebase/functions": "^19.2.2",
    "@react-native-firebase/messaging": "^19.2.2",
    "@react-native-google-signin/google-signin": "^10.1.0",
    "@react-navigation/bottom-tabs": "^6.5.11",
    "@react-navigation/material-top-tabs": "^6.6.5",
    "@react-navigation/native": "^6.1.9",
    "@react-navigation/native-stack": "^6.9.17",
    "dayjs": "^1.11.10",
    "jwt-decode": "^3.1.2",
    "lodash": "^4.17.21",
    "patch": "^0.0.1",
    "react": "18.2.0",
    "react-native": "0.72.14",
    "react-native-bootsplash": "^5.0.4",
    "react-native-keyboard-aware-scroll-view": "^0.9.5",
    "react-native-pager-view": "^6.2.2",
    "react-native-paper": "^5.11.1",
    "react-native-safe-area-context": "^4.7.4",
    "react-native-screens": "^3.27.0",
    "react-native-tab-view": "^3.5.2",
    "react-native-vector-icons": "^10.0.1",
    "react-native-vision-camera": "^4.0.3"
  }

VisionCamera Version
4.0.3
Target platforms
Android
Operating system
MacOS
Can you build the VisionCamera Example app?
I didn't try (⚠ your issue might get ignored & closed if you don't try this)
Additional information

[ ] I am using Expo
[ ] I have enabled Frame Processors (react-native-worklets-core)
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Yea, so set your compileSdk to 34.
CameraX needs it, there's no way around it other than to bump it in your build.gradle

I know the error log is self explanatory but still @mrousavy I will recommend updating https://react-native-vision-camera.com/docs/guides/troubleshooting for removing such confusion.

ah its outdated in the docs - well if you can shoot over a PR that'd be much appreciated :)

@francesco-clementi-92 Hi did you find any solution? Because updating is not working working


Fixed a typo in the invalid parameters message

Coverage remained the same at 83.3% when pulling b2e4dfdee3814173fe7660dd45e07726c4576b01 on eytanbiala:master into da6e7469238acfc7530b8528a04a86a46f604c29 on KrauseFx:master.

Coverage remained the same at 83.3% when pulling b2e4dfdee3814173fe7660dd45e07726c4576b01 on eytanbiala:master into da6e7469238acfc7530b8528a04a86a46f604c29 on KrauseFx:master.

Thank you @eytanbiala :+1:

Glad to help and looking forward to contribute more!


Fix collapse function of folders

Collapsing folders currently just throws a console error
index.js?v=1.19.0~dev-403-gb6b8feb3d:10 TypeError: this.$set is not a function
    at Proxy.handleClick (index.js?v=1.19.0~dev-403-gb6b8feb3d:58:7159)
    at index.js?v=1.19.0~dev-403-gb6b8feb3d:58:6466
    at index.js?v=1.19.0~dev-403-gb6b8feb3d:10:93922
    at ce (index.js?v=1.19.0~dev-403-gb6b8feb3d:10:1472)
    at Q (index.js?v=1.19.0~dev-403-gb6b8feb3d:10:1567)
    at HTMLDivElement.$e (index.js?v=1.19.0~dev-403-gb6b8feb3d:10:79198)

This PR fixes this and allows folders to be collapsed again.
Also:

better cursor interaction with folders
added some color to the diff detail stats.
remove green link color from all the file names

Screenshots:

Oh, the $set was left there from Vue2, I missed that.
But the new UI seems too colorful? GitHub is very restrained for UI colors. They only show necessary colors on icons.

Alright, then I'll remove the green link color which it had previously, because that was too colorful for my taste and I don't think it's really helping the user understand that the files are anchors.
Updated the screenshots.

Codecov Report

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

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main   #22864   +/-   ##
=======================================
  Coverage        ?   47.33%
=======================================
  Files           ?     1113
  Lines           ?   150173
  Branches        ?        0
=======================================
  Hits            ?    71091
  Misses          ?    70647
  Partials        ?     8435

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

But the new UI seems too colorful? GitHub is very restrained for UI colors. They only show necessary colors on icons.

Is that really a good thing?
I just had a look at the original screenshots, and I personally found it a lot more intuitive:
That way, you don't even have to look for the icon anymore (while potentially confusing which line to look on) and files are easily separated visually from folders.
However, I agree that it looks nicer in the dark theme.
In the light theme, it doesn't look as good, especially because of the yellow color for changed.

That's just my personal opinion, I wonder what others think about it.

Initially I wanted to have the Icons (right) disappear when a file was marked as "Viewed" which I already had working.
But then I ran into the issue of updating state across components. I don't know how you handle that kind of global state in the project yet.
Reloading the page worked fine, but if you click viewed on a file you would expect it to directly be marked as read in the sidebar.
Old Screenshots with more colors for reference:
https://user-images.githubusercontent.com/9765622/218268367-cec6cc9a-16f0-44e6-9d39-70a7f027d861.png
https://user-images.githubusercontent.com/9765622/218268364-20f31019-dece-488d-a96f-95833b37ca00.png

We can continue this discussion, but I would like this to get merged sooner than later to fix the actual bug here. I can make another PR for the colors if there is agreement how we should do it.

@delvh I did still leave that change in.
It's at the very top of the screenshots. I colored the long text.

added some color to the diff detail stats.

Please send backport


Systyem UI icon birghtness not changing with theme

Hi There,
My assumption is that System UI icon brightness would change when my theme changes but it does not appear to be happening.
If that is not the case please let me know, can write some manual detection but would prefer not to.
Thanks :)

Have you been able to solve this?
We've had a few issues, outside of stacked with the system brightness not following some code on certain platforms. .ie. iOS needs different code than Android to change the system brightness.

Main.dart
statusBarColorBuilder: (theme) => theme?.colorScheme.onSurface,
navigationBarColorBuilder: (theme) => theme?.colorScheme.onSurface,

Dark Mode:
onSurface: Colors.black.withOpacity(0.001),

Light Mode:
onSurface: Colors.white.withOpacity(0.001),

I did this roughly pretty soon after asking this comment, Cannot remember exactly why I did it this way.
I also removed any reference to:
SystemChrome.setSystemUIOverlayStyle

Yeah, the Flutter Theme stuff is confusing sometimes. I've had to do similar things just to get the system tray icons to be the way that I want it to be on certain views.


image in contact us was compress and was looking bad now it is …

Fixes: #2980
Description
This pull request addresses the issue of the compressed image in the "Contact Us" section, which resulted in a poor visual appearance. The image has now been corrected to ensure it displays clearly and maintains its intended quality.
Motivation and Context
The motivation for this change was to enhance the user experience by ensuring that all images, particularly in key sections like "Contact Us," are displayed at their best quality. This helps in presenting a professional and visually appealing interface.
Dependencies
No additional dependencies are required for this change.
Type of PR
Bug fix
Screenshots / videos
Before:
https://github.com/user-attachments/assets/94ef6818-189a-4e18-9c04-9abad23a9174
After:
https://github.com/user-attachments/assets/9ed11329-0fb1-4eb9-91ef-c39f5cff08c8
Checklist:
I have made this change from my own.
My code follows the style guidelines of this project.
I have performed a self-review of my own code.
I have commented my code, particularly in hard-to-understand areas.
My changes generate no new warnings.
I have tested the changes thoroughly before submitting this pull request.
I have provided relevant issue numbers and screenshots after making the changes.

i have corrected the code which was there firstly , making the image compress as well as we were not able to see it in our local server because file(image) path was wrongly entered. i have corrected all this problem.

no conflict now @sailaja-adapa

Merging Done ✅


indent (Maybe offtopic but i am new)

History: I switched from Vim in InteliJ to Vim in VSCode to Nvim in two weeks.
Reason to do it: I really need a/any proper surround.
(So that i can copy a inline SQL into the clipboard so i can run it into a (Oracle) SQL Developer).
Tl;DR: I am very new to NVIM. After 5 Hours i still can not figure out the indent on init.lua (If i use Tab, i can get highlighted, but when i save :w than it transforms the whitespace to something similar to >> (most of the time) but single symbol). (This does not happen on .py files so i am confused).
=> Use tab in init.lua and then use :w to save. (Now it uses >> to indent).

I basically want to show tab instead of >>  and indent lines to work.

using kickstart, will auto-format all lsp enabled filetypes by the conform plugin. lua lsp is enabled by default.
perhaps related to:
https://github.com/nvim-lua/kickstart.nvim/issues/686
https://github.com/nvim-lua/kickstart.nvim/pull/694
as for the >> I assume that is space, but indent-blankline which you enabled shows it as such.

» is just a character to denote there is a tab, but it's not part of the code. You can change that symbol if you don't like it changing this line in the config:
line 143: vim.opt.listchars = { tab = '» ', trail = '·', nbsp = '␣' }
Or just turn it off setting vim.opt.list to false

Do you have a .stylua.toml file in .config/nvim/? Without it, my lua file was being formatting to use tabs instead of spaces. Ensuring I had the style config file locally fixed that for me.

From the issue I infer they wanted a tab, as that's what's being pressed.


[FEATURE] Replace the FastAI notebook by a cartesian product with PyTorch and remove the FastAI dependency

Description

We had some issues with the FastAI dependency #2182. And realised that the fastai notebook is just a fancy wrapper on PyTorch cartesian product between user and item embeddings.
https://github.com/recommenders-team/recommenders/blob/main/examples/00_quick_start/fastai_movielens.ipynb
Expected behavior with the suggested feature

We want replace the FastAI notebook with a PyTorch version
Willingness to contribute

[ ] Yes, I can contribute for this issue independently.
[ ] Yes, I can contribute for this issue with guidance from Recommenders community.
[ ] No, I cannot contribute at this time.

Other Comments
Related to #1713

@miguelgfierro  I am unclear with the requirements. Do we just want to replace the Cartesian product or we want to completely replace fast-ai with the PyTorch?

@rohan-rajput-ai the idea is to remove all the code related to FastAI, and replace it with the underlying PyTorch. The output of this work needs to be a remade notebook, the removal of https://github.com/recommenders-team/recommenders/blob/main/recommenders/models/fastai/fastai_utils.py and the removal of the fastai dependency https://github.com/recommenders-team/recommenders/blob/main/setup.py#L54.
If you need to create any function, feel free to create a pytorch_utils.py file.


clarify and fix README description of dim_inactive in config

dim_inactive seems to be incorrectly explained and example provided in README.
It could mislead many people since it does result in a broken config.

Can you re-format the compile section too?
I am very bad at writing readme 😅


BE AS CLEAR AND CONCISE AS POSSIBLE.
describe the bug
what is the bug - what happens?
Whenever I click Enhancements, the small window starts loading but it keeps on loading forever. It used to work just fine until I updated the enhancer to the latest version.
expected behaviour
why is this a bug - what should be happening?
The window with the possible enhancements should open.
screenshots
if applicable, add screenshots of your problem.

platform
what OS are you using? e.g. windows 7, windows 10, WSL, ubuntu, arch linux, macOS
Windows 10

had the same problem. It was fixed following comment issue #235, you just need to click on relaunch notion, and after two times, it was fixed for me.


[docs] Clarify derive dependency recommendation

Clarify advice for how to speed up compile times by importing zerocopy and zerocopy-derive separately. The updated advice avoids the risk of duplicate import errors if one of a crate's transitive dependencies adds zerocopy's derive feature.
Closes #1587

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

Project coverage is 88.01%. Comparing base (dcf90f3) to head (cb384d2).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1672   +/-   ##
=======================================
  Coverage   88.01%   88.01%
=======================================
  Files          16       16
  Lines        5805     5805
=======================================
  Hits         5109     5109
  Misses        696      696

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


./Configure is not able to pic xlC_r compiler in AIX 7.1 while compiling Openssl 3.0.7

I am trying to compile OpenSSL 3.0.7 using AIX 7.1 with xlc_r compiler(13.1.3)  using below command
CC="/usr/vac/bin/xlc_r -q64" ./Configure  --prefix=/pathtodir --enable-fips
When the above command executed , am getting error like "pick os/compiler flags" .
The above command is perfectly working with openssl 1.1.1 in the same machine

I strongly doubt that the given configuration command works with OpenSSL 1.1.1.  Either you used the config script rather than the Configure script, like this:
CC="/usr/vac/bin/xlc_r -q64" ./config --prefix=/pathtodir --enable-fips

Or you had an explicit config target for AIX, like this:
CC="/usr/vac/bin/xlc_r -q64" ./Configure --prefix=/pathtodir --enable-fips aix-cc

(where aix-cc may be another of the aix config targets)

Either way, we did change how Configure works in 3.0.  All the guessing capabilities from config have moved to Configure, so it can do the platform guess on its own...  and we may have omitted something AIX related in that transfer.

I am not quite sure why it shouldn't work. It works for me in an AIX 7.2 with xlc 16.0.1. Try to cleanup a few things in your environment before running Configure and make. What I do since ages is resetting the search paths for binaries and libraries. You could start with ...
CC="xlc_r"
PATH="/usr/vac/bin:$(getconf PATH)"
unset LIBPATH
unset LD_LIBRARY_PATH

... and then append paths until no more things are missing.
Ah ... and you should use aix64-cc as configure target. That will take care for the necessary 64bit setup of all tools.


Recording not working?

Are there any known issues with using scrcpy in python scripts, specifically in how subprocess.Popen() has trouble with recording to file? I can record from command line, but when I try from within my script, the behaviour is unpredictable, recording only about 1% of the time, with the other 99% of the time being either 0 KB, 1KB, some variable number of KB, but always corrupt. I have tried python's terminate(), kill(), as well as process.send_signal(signal.CTRL_C_EVENT), all in conjunction with combinations of join() and wait() to ensure the process is completed. I have also used both processes and process groups, and threading. Has anyone else run into this issue, and if you solved it, how?

#5195

@rom1v Thank you for the quick reply! I tried os.kill(pid, signal.SIGINT), but that isn't working. When using os.kill(pid, signal.CTRL_C_EVENT), it hangs indefinitely because I'm using join().
The strange thing is, although my script is supposed to open and close (and save) recordings 6 times during its execution, they all stay open. When the script terminates, they are all closed at that point and are saved correctly (!). Could it be that the script is cleaning up in a way that any individual call for close/terminate/kill is not doing properly? What signal does scrcpy need to terminate gracefully?

There seems to be an issue in ffmpeg driver that isn't working well (returns non-zero code). If having issues, try to switch to using a different format, such as mkv. Also, using thread or process termination through any non-windowed closing doesn't seem to work to save the recording gracefully. Instead, use python modules win32gui and win32con, find the name of the window using win32gui.FindWindow(), and then close the window using win32gui.PostMessage(windowName, win32con.WM_CLOSE, 0, 0)


NonReadable must be set on write-only storage images

When DXVK uses a write-only storage image, it needs to set the NonWriteable decoration.  The Vulkan 1.1.78 spec, Appendix A, "Images and Samplers", says,

If shaderStorageImageReadWithoutFormat is not enabled and an OpTypeImage has “Image Format” operand of Unknown, any variables created with the given type must be decorated with NonReadable.

This missing decoration is causing misrendering of Skyrim on Intel.  We don't support shaderStorageImageReadWithoutFormat and depend on that decoration for proper descriptor set setup.  I hacked up the driver to implicitly set the decoration on all images with an unknown format and it fixes all the rendering issues in Skyrim.
Software information
Skyrim Special Edition
System information

GPU: Intel Skylake GT4e
Driver: Intel Vulkan driver, Mesa 18.1.0

Thanks for the detailed report, c370eea9486445ea1ca97fc85eff47179cc3e605 should fix this - please let me know whether that works.

Wow! Thank you, I do not know whether this fixed issues in Murdered: Soul Suspect.
But since 0.61, in game works HDAO and in some places, the game has not artifacts when the character / environment turns white gradient.

@MrChebik I just pushed an optimization to mesa master which helps Skyrim out massively:
https://gitlab.freedesktop.org/mesa/mesa/commit/06412bfc9869247f33b6bba8e256cf33f71f6973
It's still not going to run great on a Broadwell GT2 but it'll be a lot better than it is now.

@jekstrand Thank you! I wish you success!