Suggestion: Hide Quests, if you dont meet the requirements

Would it be possible to make an option to Hide Quests, where you dont meet the requirements?
Example:
Got NPC with Quests A, B, C and D
Without doing A, you cant do B, C, and D.
To do so, thats no Problem, Quest Requirement A, and it works fine.
But Users, dont know that they must fullfill A first.
So they look and see "Oh, A, B, C and D" ... They taking A... then want B.. they see "Oh, Requirement"... C the same, D the same.
Why not only "Show" Quest A?
And then, if the have done it, they will see "Ah, there is now another Quest" ?

Sorry to have this sit on the back burner for so long.
I believe you want to set ignore-locked-quests: true in config.yml


UI issue on compare similar item page.

Bug report
Title
UI issue on compare similar item page.
Issue Description
UI issue on compare similar item page.
Preconditions
1. framework Version.-master

Steps to reproduce
1. step1- Click on compare link

Expected result
Ui should be correct
Actual result

Fixed in master


submit example design to the next MPW shuttle?

Curious if you've consider submitting some of the examples designs in https://github.com/siliconcompiler/siliconcompiler/tree/main/examples to the Open MPW shuttle: https://efabless.com/open_shuttle_program/ ?
That would be an interesting way to ensure that not too many assumption about specific tooling are baked into the current precheck and submission process.

It's a good idea. Right now we are too swamped with contract commitments and building out the platform for other commercial nodes, but when the time is right, we will give it a shot.


Support multiple credential factory classes

❗ please do not add sensitive information in issues, you can provide extra information via email using issue number as reference ❗
Describe the issue
Related to #5438.
Currently an application instance is bound to a single ICredentialFactory instance, allowing the user to load credentials from a single source.
Within our current implementation we store Azure/AWS related keys under Websphere auth aliasses. However this is not compliant with key rotation policies many companies have. Currently this would force the Wesphere manager to update the aliasses every X days.
To solve this, the application should be able to read from AWS/Azure vaults/stores, that is requested in #5438. However this would impose that we would need to move all our credentials to AWS or Azure and a combination of both is not possible.
Ideally the application instance could be configured with multiple ICredentialFactory instances, allowing the user to load credentials from multiple sources. On each listener/sender/pipe that uses the authAlias attribute, a new attribute named authAliasFactory should be added to choose a certain instance.
Requirements:

When not specifying any additional ICredentialFactory instances, there should be no need to specify the authAliasFactory
When multiple ICredentialFactory instances has been configured, the first specified class should be considered as the default,. Developers should only set authAliasFactory for credentials that are loaded from secondary sources.

A CompositeCredentialFactory should be created, the order of the factories should dictate in which order an alias should be looked up.


ECH client side

This PR includes ECH client side code and the minimal addition to s_client to be able to test that against an ECH enabled server. So this is the first PR for the ECH feature branch that does ECH protocol things.
The bits worth calling out for this one (that likely warrant discussion) are:

The way I've wrapped tls_construct_client_hello() to do things twice (for inner and outer)
The compile-time way of deciding how to handle extensions with ECH (i.e. compress or call twice)
The use of the ECH_IOSAME macro to action the above in extension handlers

I expect that the transcript handling here might not be what we want in the end, but would suggest we try fix that after the server-side code is included (my next planned PR) so that changes can be better tested. It'd be great though to get ideas as to how the project would like to see that done better. (The current way transcripts are handled is sort-of a product of how my code evolved as the ECH spec and the master branch both evolved over the last couple of years.)
I'm sure along with the above, there'll be the usual set of fine comments and changes to make.
There's a gist that has a couple of test scripts that can be used to run openssl s_client to check this build against an ECH enabled server.
Checklist

[x] documentation is added or updated
[x] tests are added or updated

The fixup above is to reduce the number of style things CI dislikes. I didn't get them all though, as a few are down to the way I've e.g. put in a new #ifndef OPENSSL_NO_ECH condition before some existing code, so will take advice as to how best to resolve those.

@t8m thanks for the super-quick initial review! will be processing those shortly

The fixup above attempts to handle all today's @t8m and @FdaSilvaYY comments other than the tracing thing, the inclusion of statem_local.h and (maybe) some of the comments about WPACKET_cleanup() and BUF_MEM_free(). That was a lot of changes though so let's see what the CI says before addressing those. (So there may be more fixups below shortly.) It'll be tomorrow before I get to the tracing etc stuff.

The fixup above handled the cleanup/free issues from @t8m and the couple of style issues where ignoring the style checker seems the thing to do. Will look at the ssl_cipher_list_to_bytes() suggestion next...

The remaining style failures are irrelevant. Setting style: waived.

The last fixup above moves ssl_cipher_list_to_bytes() to ssl/ssl_ciph.c which just worked without any trouble - was that what you meant @t8m or something else?

forgot to take out the include

fixup above handles the tracing issue raised

Push above fixes today's typos, removes the conditionality from the move of ssl_cipher_list_to_bytes() and fixes a double-free after a malloc fail discovered via OPENSSL_MALLOC_FAILURES

push above initialises 2 vars that are traced (when OSSL_ECH_SUPERVERBSOSE set) that could be uninitialised if we see errors. Thanks again OPENSSL_MALLOC_FAILURES:-)

push above has fixes for @FdaSilvaYY's fine comments from yesterday.
And thanks for those - it was more than a "few":-)

Thanks @mattcaswell for today's comments. The push above fixes most, with some outstanding that I'll look at later Wednesday (and/or I'll argue for the current code then), but next step is on me for those.

I think the push above addresses all outstanding @mattcaswell comments from yesterday/today, if I got the changes right, but I might've gotten some wrong, we'll see:-)

Push above addresses comments from yesterday/today modulo those where I suggest punting  while to the next PR (transcript stuff).

ping for more review:-)

Another ping:-) As an FYI, I've started doing the refactor of transcript handling in the next planned PR (as that impacts both client and server code) so if we can get this one reviewed soon (while punting on transcript refactoring) that'd be great.

Cycles for reviewing this are limited, but here's a few more comments.

Understood, and I appreciate the cycles available. I've mostly done the transcript refactoring which changes the code blocks commented on above (some disappear). I still need to tidy that up and fix an issue I'm seeing with test code for ECH+HRR+early-data though, so will get back on the comments above once that's in stable place.

So I think I've done the transcript handling re-factoring now. That affects both client and server code but seems to work ok and is definitely cleaner. That branch is the ech-both-sides-now branch. (The diff from this PR is here but is substantial, (in terms of LOC: 1,869 additions and 368 deletions) as that (as stated before), includes the server-side code for ECH processing).
I'm not sure what's the best process from here to the next feature-branch PR TBH, the options seem to be:

ask me to extract the client-bits from ech-both-sides-now and include those in this PR (TBH: bit of a PITA for me;-)
approve/merge this PR and move on to processing the next one with the server-code and refactored transcript processing (with the risk that reviewers miss reviewing some block of code between the two)
something else?

I'd obviously be happier with (2), the 'merge/move-on' option, but that does include a risk of code being merged that hasn't really had two maintainer reviews. (One mitigation there is that I will be asking our funder (OTF) to arrange a pentester to review the diff between the feature branch and the master branch once the former is close to complete, so there's an additional layer of review here perhaps not normally available.)
Also worth noting - once the ech-both-sides-now code gets merged to the feature branch, it'll be credible to start making PRs for other upstream projects (apache, lighttpd, nginx etc) that don't feature any @sftcd dependencies, which will be a bit of a positive milestone.
And lastly, given the time of year, people will be taking deserved breaks so we mightn't pick 1 or 2 for a bit. (And happy crimbo/new-year to all too of course!)

ask me to extract the client-bits from ech-both-sides-now and include those in this PR (TBH: bit of a PITA for me;-)

While recognising this to be a PITA, this would be my preferred option. I was spending quite a lot of cycles trying to get my head around the transcript handling - so reviewing the refactored code would probably help me a lot.

On 23/12/2024 16:32, Matt Caswell wrote:

ask me to extract the client-bits from [ech-both-sides-now]
(https://github.com/sftcd/openssl/tree/feature/ech-both-sides-now)
and include those in this PR (TBH: bit of a PITA for me;-)

While recognising this to be a PITA, this would be my preferred
option. I was spending quite a lot of cycles trying to get my head
around the transcript handling - so reviewing the refactored code
would probably help me a lot.

Fair enough. Will likely be end of the week before I get to it.
Cheers,
S.

Will likely be end of the week before I get to it.

I'm working tomorrow, but then won't be looking at anything until 2nd Jan.

OK, I think the push above has the client-only transcript refactoring stuff. The branch with the server stuff is the same and will be the next PR and  the diff between this as-is and that is here


Use API Gateway HTTP API instead of Rest

Describe the feature you'd like
Use APIGateway HTTP API  in order to decrease the overall cost of this solution.
Additional context
I am not an expert but I don't see any disadvantages or possible blockers in using HTTP api instead of rest.

@niqo01 thanks for your feedback.
I've put this one into our backlog items, and we will discuss this one.


Fixed some menu colors.

Fixed colors of menu items being inconsistent and low visible depending of the theme applied.
This should fix #21

@AlbertoCasasOrtiz These numbers/colors were pulled directly from the pdf with all the logos that I sent you earlier, I can't tell where these new numbers are applied so if you can describe that I'll review the effect of the change. Thanks


Templater insert briefly appears then disappears

Pressing the following button briefly shows the text. The text is not added to the document when switching to edit `mode.
name Log
type append text
action Hello
templater true

The following works, appending text to the doc:
name Log
type append text
action Hello

Obsidian: 1.1.16
Buttons: 0.4.19

I am also having this issue - any button that includes "templater true" causes the appended/prepended text to flash in then immediately delete. This includes both simple text as in the example above, and content pulled from a template note. Button works as intended when "templater true" is removed from the code.
Obsidian: 1.1.16
Buttons: 0.4.19

I think I'm seeing this, too: https://forum.obsidian.md/t/button-template-insertion-briefly-flashes-the-message-and-erases-it/66037
Mentioned here as well: https://github.com/shabegom/buttons/issues/191


docs: caching node_modules vs cache directory

The docs guides to cache .npm or $(yarn cache dir) for nodejs.
Node - npm
Node - Yarn
This lets people feel it the "RIGHT" way to cache node dependencies, without clearly explaining whether caching node_modules directly is not recommended.
I want to know 1) if this is a wrong impression or not and 2) why.
Thanks!

Yes. I would like to know the answer here as well. From experience caching node_modules/ saves a lot more time, than just caching $(yarn cache dir) :thinking:

There are some answers on stackoverflow. Agree docs could explain slightly more.
Presumably raw caching the actual installation may be fragile to changes occurring elsewhere in the environment, whereas npm provides some version management over its own supported cache (it can decide to invalidate some of those contents)?

Docs should include a brief explanation, that caching the downloaded packages (the cache dir) facilitates the package manager (npm) overriding parts of the cache in a granular manner as necessary. Caching the actual installation dir would be much more performant (skipping some steps) but unreliable as the install could spontaneously break (e.g. if a dependency among the system libraries gets upgraded to an incompatible version, while still hitting the old cache).

@benjimin Would you be willing to open a PR for that?

This has already been added to Node example at https://github.com/actions/cache/blob/main/examples.md#node---npm . Hence, going ahead and closing this. Thank you for opening this issue.


Proposal: Add flag --ignore-kubeversionto install/upgrade command

Some chart maintainer are quite aggressive when it comes to setting their chart's kubeVersion range.
Here is a reference discussion illustrating this problem: https://github.com/kokuwaio/helm-charts/issues/21
We can't upgrade our cluster to the required 1.16 yet but want to use the helm-chart which only requires Kubernetes 1.16 for the PodSecurityPolicy which can also be disabled.
However, we can't install it without forking the repo because we can't disable the kubeVersion check knowingly.
Therefore, I propose adding a flag called --ignore-kubeversion to the install and upgrade command of Helm. I would also be willing to create a PR for it + tests + docs.
What do the Helm maintainers think about this?

@crunchtime-ali Helm has a process for proposal called Helm Improvement Proposal. Do you mind creating a HIP for this proposal?

I agree that a HIP would be a great way to iron out some of the design concerns.
In particular, I'm concerned that the chart author clearly set their kubeVersion range to restrict which Kubernetes versions this chart is supported on, then by "breaking out" of that supported range, the consumer is bypassing the restrictions which the chart author clearly set upon the chart. This seems like a concerning design case: the author clearly did not design the chart to work with that version of Kubernetes, and now the consumer is trying to bypass that control.
For example, one of our assumptions when we wrote up Helm User Profiles is that the chart author (Application Distributor) knows more about the internal workings of the chart than the chart consumer (Application Operator). This proposal appears to break that assumption, which I do not agree with.
If it's just a matter of "some chart maintainer set their kubeVersion too aggressively", then perhaps a PR or a test case to confirm that the chart works with future iterations of Kubernetes is more appropriate, in which case this is not a technical issue, but an issue with their process or test infrastructure.
Again, a write-up in a HIP might be more helpful to carefully consider these design cases and how the author of said feature intends to address them.

+1 - I need this feature, I use k3s and this catches most charts.

+1 - I need this feature, I use k3s and this catches most charts.

I encountered a situation that needs this, and it appears no HIP has been made. The authors of a chart set restrictive versions, only going up to the latest release at the time when setting the version. I would normally just upgrade to the chart to latest, but due to how this particular operator works, the resource upgrade has to be done in stages.
With my kubernetes being upgraded to 1.31, I could only support the operator 1.13, but operator 1.13 required resources to have been upgraded to 1.11, something that Id not done as I didnt realize it was a requirement. Installing chart 1.11 was not possible as I had already upgraded my k8s. Thus I was in a deadlock.
I managed to get out of this situation by downloading the chart and manually setting the kube-version. The kube-version restriction was entirely un-necessary (on the chart maintainers side), and the ability to bypass it would have saved me several hours.


Container for streamlit app

I wonder if it would be fun to make a container (podman/docker) for the code so that it can be hosted elsewhere (SURF maybe?). This gives us a bit more control over the installation over what streamlit cloud has to offer. Just a thought.

Sounds good, especially when we would gain some additional speed in running the app and processing the images

Sure, shouldn't be too difficult.

Perfect!


Add support for X-Forwarded-Proto to identify HTTPS protocol

Support X-Forwarded-Proto header since it is used in some proxy or
load balancer environments to identify HTTPS protocol - nor HTTPS,
nor SERVER_PORT variable is available in those scenarios to
identify the protocol used.
More info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto

before mergeng, please update readme.md with a new line into the changelog, eg.
:diamond_shape_with_a_dot_inside: Update | Add support for X-Forwarded-Proto to identify HTTPS protocol |

I've just added the line to the readme.md, thank you for the advice.

Thanks, but please add the new line at the end of the list

Sorry, but there is the new line at the end of the list, should I add another one?

Move your line at the end of the list. We add  all change at the end of the list.

Ah, sorry, didn't get it... done.

does it is affects nginx?

@karlsoon : I just checked the commits in this PR, and it doesn't seem nginx was included.
There would need to be an additional "if" added in PgCache_Environment.php#1048, but I'm not a big fan of the use of "if's" in nginx (see If is Evil).
You can give it a try and let us know if it works.


'disallowCreate' included in saveFileDialog example but not spec

In this page in the docs: https://docs.beakerbrowser.com/apis/beaker.shell
the example for beaker.shell.saveFileDialog shows disallowCreate being used as one of the options, but the actual list of options directly above that doesn't mention it. (Though, an option with the same name DOES appear in the list of options for beaker.shell.selectFileDialog...)

Ah that was a docs bug, thanks. Will push fixed docs in a bit.


Request improvements

Some request improvements.

@bluszcz - some tests in the last commit :)

@bluszcz - some tests in the last commit :)

Sweet. Let me go through it today! <3

Finished in 0.0620244 seconds.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9 tests, 12 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
145.10 tests/s, 193.47 assertions/s

Nice. Today will finish the review.

I am getting this during rake - do you have any idea why, by any chance?
........Error reading file /tmp/jekyll-strapi-src/_layouts/post.html: No such file or directory @ rb_sysopen - /tmp/jekyll-strapi-src/_layouts/post.html

Fixed on the last commit :)
The issue was in config directory setup. By the way - your UT config might also load directory in a similar way.

Thank you, that's great contribution <3


SharePoint Framework - SPFX Webpart is not visible under the root sitecollection

Hey all,
I have SharePoint 2019 (on-prem) and one web app; one root site collection for Intranet Portal and other one /sites/apps for the app catalog, where I deployed react-script-editor (Modern Script Editor).
The issue is that the webpart is only visible under the apps site collection but NOT under the root site collection.
Any help???
Thank you.

Have you added the app to the root site collection for Intranet Portal where you need it?

@mhijazi I hope that @sudharsank 's answer helped you solve this issue.
I'll go ahead and mark this as closed, but if you still need help with this, feel free to re-open the issue.
Thanks @sudharsank for your help!


incoming and outgoing message should be distinct

incomming message should be at left side and out going message should be at right side.

This is not expected and it's not how Rocket.Chat works, thanks for the suggestion but we don't plan to make the change right now! 👍


[greenhouse] greenhouse area/app which displays error messages. Errors are related to kubernetes plugin configs loading or mismatches between config and plugin to show.

I would like to switch the demo info div to a warning message so it can be integrated with the global messages provider and together with other messages we want to display @edda within the notifications container I have created.

https://github.com/sapcc/juno/pull/503


CowAxess - GoAccess for Windows

Please consider to list CowAxess as a GoAccess implementation on Windows:

CowAxess is a GoAccess implementation for Windows systems. It is a packaging of GoAccess, Cygwin and many other related tools to make it a complete and ready-to-use solution for real-time web log analysis, all in a 4 MB package. We have followed standard instructions available at the GoAccess website.
CowAxess is available as a free solution licensed under simplified BSD. Enjoy!

That's awesome, thanks for sharing this and having this implementation. I've added to the downloads page. I'll keep this open for a while just as a reference as well.

CowAxess is now updated to GoAccess 1.4.

Thanks a lot for updating this!

Unable to paste longer commands in cowaxess. ctrl+v and right click, both not working.

@saptarshisd Not sure this is an issue with goaccess as I don't recall having a ctrl+v functionality. What was it doing before?

I might have framed my question wrong apologies. The correct way to put it would be, Is there a way to paste commands in the cowaxess terminal? I have tried ctrl+v and right click, but none seemed to work. Hence curious

CowAxess  is now updated with GoAccess 1.4.3 and Mintty is introduced as terminal with better cut/paste support . You may give it a try.

@tevkar Thank you again for putting this together!

CowAxess is now updated with GoAccess 1.5.1

Hi,
has anyone ever managed to create a batch to schedule the generation of the static html report on a windows server?

@fbollon create a batch as in running through all the logs?

Hi,
cowAxess is now taken out of our solution offerings. It will not be maintained any longer.
Kind regards
itefix.net

@tevkar Thanks a lot for supporting the Windows version all this time!

Hi folks,
just to let you know cowAxess is made available again at our site https://itefix.net/cowaxess. We can't guarantee timely updates though.
Kind regards,
Itefix team

@tevkar Thanks a lot!


Added null geometry type

Added a null type geometry - related to original discussion on #28.
It is a contentious topic in some ways, but I think that we should consider using a null geometry type again. The biggest reason I keep running into using this is frankly that it is very difficult to try to use a geometry object that is not wrapped in a pointer (through an optional) and it is very difficult to initialize an empty geometry prior to having your data prepared.
Additionally, I think it might be useful to have as a geometry type in general. In the OGC simple feature spec, there is the concept of an empty set which could mean a null geometry in the case of a point geometry. Otherwise we have no way to represent this currently.
/cc @artemp

As before, I'm opposed to doing this. Making geometry effectively nullable weakens the invariants of the type, meaning that all code that uses it must either explicitly guard against null, define what its behavior is in that case (and often there's no clear correct behavior), or risk behaving unexpectedly in the face of an input that was assumed not to be null. It's trouble-making for the same reason that nullable-by-default pointers are the "billion dollar mistake".

As @flippmoke mentioned having a null geometry is often useful in code. I see the problems @jfirebaugh mentions as less of a problem in this case, because geometries always have a type and basically every piece of code has to switch on this type anyway. There is different code for points, linestrings, polygons, whatever. One more option isn't a big deal. C++ compilers will warn you if you don't  cover all types in the switch. This is very different from the nullable pointer where the typical operation is accessing data through the pointer where the check is an extra operation you might miss.

@artemp I really like these changes very nice!

@joto Null geometries are never wanted in Mapbox GL. I don't want the types Mapbox GL uses to allow the possibility of null geometries; that would introduce non-trivial complexity and possibility of bugs. If this change is merged, we will need to fork geometry.hpp for use in Mapbox GL.

As an example of the accidental complexity null geometries introduce -- this changes the possible results of the envelope function. It can now return an invalid box<T> (min > max), and all downstream code will need to be prepared for that possibility.

@jfirebaugh wouldn't an isEmpty() method work for preventing  empty/null geometries? Do you not already have to deal with this logic in some ways for invalid points and other problems?

That would be a runtime check. It can a) be easily forgotten and b) is an extra code branch that you have to figure out how to handle -- e.g. what do you return in that case? Null geometries force you to have to remember to make the check, and force you to make a decision about what to do if it fails, everywhere. That's accidental complexity that permeates your whole program. Using optional<geometry> only where you actually want and need the possibility of a null is more flexible and less complex overall. It may appear more complex in localized areas, but I submit that that's not actually complexity caused by optional<geometry> itself, but optional<geometry> forcing you to deal with the inherent complexity that a nullable type introduces. When you build that inherent complexity into the base type, that complexity can't be localized -- it's everywhere in your program, waiting to produce bugs because you forgot to add an isEmpty() check, or because you forgot to account for the possibility that a geometry algorithm encountered a null geometry and returned an unexpected result, like in the envelope example.

@jfirebaugh on the algorithms end a lack of null can introduce a lot of complexity as well and forces us to either throw exceptions or use pointers in the case of null or empty geometries. This is extra complex when we deal with the fact that we have geometry collections:
For example lets use a intersection (with a polygon) visitor example -- I will attempt to reasonably show both sides here.
Example with empty
template <typename T>
struct intersection_visitor {

   polygon<T> const& poly;

   intersection_visitor(polygon<T> const& poly_) : poly(poly_) {}

   geometry<T> operator() (empty const&) {
         return geometry<T>(); // empty default constructor
   }

   geometry<T> operator() (point<T> const& pt) {
         if (intersects(pt, poly)) {
             return geometry<T>(pt);
         }
         return geometry<T>();
   }

   // Other geometry types here... multipoly, linestring, polygon, etc.

   geometry<T> operator() (geometry_collection<T> const& gc) {
        geometry_collection<T> new_gc;
        new_gc.reserve(gc.size());
        for (auto const& g : gc) {
              // use move operation instead of a copy here
              new_gc.push_back(apply_visitor(g, *this));
             // could also possibly be:
             /*
             auto new_g = apply_visitor(g, *this);
             if (!new_g.is<empty>()) {
                 new_gc.push_back(new_g);
             }
             */
        }
        return geometry<T>(new_gc);
   }

};

Example with optional
template <typename T>
struct intersection_visitor {

   polygon<T> const& poly;

   intersection_visitor(polygon<T> const& poly_) : poly(poly_) {}

   optional_geometry<T> operator() (point<T> const& pt) {
         if (intersects(pt, poly)) {
             return optional_geometry<T>(pt);
         }
         return optional_geometry<T>();
   }

   // Other geometry types here... multipoly, linestring, polygon, etc.

   optional_geometry<T> operator() (geometry_collection<T> const& gc) {
        geometry_collection<T> new_gc;
        new_gc.reserve(gc.size());
        for (auto const& g : gc) {
             auto new_optional_g = apply_visitor(g, *this);
             if (new_optional_g) {
                 new_gc.push_back(*new_optional_g);
             }
        }
        return optional_geometry<T>(new_gc);
   }

};

Summary
Both of these sets of code are reasonably easy to program however, lets look at the interface that each of these would expose in the end.
template <typename T>
geometry<T> intersects(geometry<T> const& geom, polygon<T> const& poly);

or
template <typename T>
optional_geometry<T> intersects(geometry<T> const& geom, polygon<T> const& poly);

This means that more then likely the optional_geometry object is the real object we will be using when storing and managing the geometry objects. As we look how to write more algorithms around this, we will increasingly need to support methods and functions that work with this object.
This concerns me in some ways, because suddenly we have a wrapper structure around our variant. Why do we need another layer? This extra structure seems like something we could be diving in and out of quickly if we chained operations, because we will need to operate on the variant quite a lot. Why not just have a null/empty case in the geometry object?
There are already cases where we can have empty or invalid data in our geometry object. For example, what does a multi_point or line_string mean with out any points? I don't feel like having a clear case of empty really adds much complexity.

We will increasingly need to support methods and functions that work with this object.

For me, this is neither true nor desirable. I want to write as few methods and functions that need to deal with nullable geometries as possible. Don't you? It's much easier not to have to think about that additional case, decide upon a strategy for handling it, document the decision, and handle that ramifications of that decision everywhere downstream.
Where nullability is actually an inevitable possibility, like in the intersection case, I want that called out very explicitly with a distinct and unusual type -- optional<geometry> -- so that I don't forget to account for it. Then I can dispose with that possibility as soon as possible, ideally in a single place, and go back to not having to be concerned or think about nullability.
But even if you do feel like you do need to write a lot of code that allows nullability -- then just write that code using optional<geometry>. As you've shown, it's not significantly more verbose or burdensome. But the advantage is that you can do so without issue, and I can continue to write code that doesn't allow for nullability. With optional<geometry>, nullability is easy to opt in to, but nullability baked into the lowest-level definition is impossible to opt out of.
Regarding validity -- first off, I see validity as an orthogonal concern to nullability. An invalid geometry could be represented by a null geometry, but a null geometry can represent something else as well (e.g. no intersection), and conversely, an invalid geometry is not necessarily null. So they are two separate concepts, and shouldn't be conflated. I think it's still a great win if we can statically eliminate some edge cases by disallowing nullability, even if there are other edge cases that stem from invalid geometry that we can't statically eliminate.
Secondly, if it were reasonably possible to statically enforce validity via the type system, I would absolutely want to do that as well. That would eliminate whole other swaths of possible bugs and programmer errors. Sadly, I don't think it is reasonably possible in the C++ type system. But where we can enforce constraints, as we can with nullability, I think we should do so.

What I found annoying about empty geometry in Mapnik is that empty geometry doesn't have the same interface as other geometry types. I mean coordinate_type in particular.
This will compile fine:
mapnik::geometry::line_string<double> geom;
mapnik::box2d<double> bbox = mapnik::geometry::envelope(geom);

But this will end up with error: no type named ‘coordinate_type’ in ‘struct mapnik::geometry::geometry_empty’:
mapnik::geometry::geometry_empty geom;
mapnik::box2d<double> bbox = mapnik::geometry::envelope(geom);

Per voice with @jfirebaugh and @flippmoke - this is now merged into the algorithms branch (not master). More review and discussion will be needed before a merge to master, since this would be a breaking change for users of the variant wrapping the geometry types (aka mapbox::geometry::geometry_base.
Echoing @flippmoke's comment in https://github.com/mapbox/geometry.hpp/pull/52#issuecomment-337988126, this algorithms branch will be a testbed @artemp and @flippmoke will use to refine the code as they actively work to ensure geometry.hpp will work seamlessly within https://github.com/mapbox/spatial-algorithms. Once that work is farther along, we'll circle back to resolve how to best enable geometry.hpp to balance the equally important needs of the spatial-algorithms and mbgl-native.
@talaj - Thanks for noticing that Mapnik compile issue. Please follow along with the work at https://github.com/mapbox/spatial-algorithms, which is where a design will emerge to avoid a compile error like that in the future (since spatial-algorithsm is standalone from mapnik and @artemp and @flippmoke are iterating on improved designs there).
Also, for users familiar with Mapnik (one of the main targets in the original design of geometry.hpp and the source of the original implementation inspiration - https://github.com/mapbox/geometry.hpp/issues/16), I want to clarify that Mapnik 3.1.x is now based on/working with geometry.hpp v0.9.x. However Mapnik does not yet use the mapbox::geometry::geometry_base. So, to my knowledge only Mapbox GL and deps at this point is using mapbox::geometry::geometry_base. Mapnik is currently using all the geometry types, but carrying its own geometry_base that stores an geometry_empty type: https://github.com/mapnik/mapnik/blob/f02a259011ec397f8152b0ad9b353483e80d5f96/include/mapnik/geometry.hpp#L49


Delta 7B Aethersprite does not exist in translation

I'm trying to use the project for RollBetter.gg. I have a few questions.

Is the translation.json file regenerated on each semver increment?
The delta 7b aethersprite does not show up in the translation.json file as I would expect. AMG treats it as a separate ship. There is a separate ship file for it in the source data. Is this an error? Should I expect to see a translation for it? My expectations are based on XWS coming from popular list builders that use the stringdelta7baethersprite as the ship identifier.
If I should not expect to see that string in the translation.json, how should I go about translating it when I see it using this project?

No, the translation file is manually neglected and is not actively maintained. The release process is outlined here
As above, the translations are old and outdated. They have not been touched since AMG changed the 7b from a config to a ship
I'm not aware of any projects which actually use that translation file (I assume that if it was under active use it would have active contributors). From an xwing-data2 perspective, the "correct" approach is probably to update the file with 7b and other recent changes. This work could be performed by yourself or other contributors - the active maintainers of this repo only have enough time for new card data entry, and we don't all have access to alternate-language cards.


Option to specify reward delay reset at a specific time of day

Basically add a new thing to the /pa rewarddelay   where you can specify a time like 14:00 where any players who received the parkour reward before that time of day can now get it again. So for example if you did the parkour and got the reward at 13:59, you could do the parkour again and get the reward at 14:00, but if you did the parkour at 14:01 you would need to wait until the next day at 14;00. Could be cool to have in some situations.

I agree


"Make objects have private/protected members" section should be improved

This section doesn't provide any useful explanation when and why to use public, private and protected access modifiers.
Consider adding explanation that

public methods and properties are most dangerous for changes, because some outside code may easily rely on them and you can't control what code relies on them. Modifications in class are dangerous  for all users of class.
protected methods are as dangerous as public, because they are available in scope of any child class. This effectively means that difference between public and protected is only in access mechanism, but encapsulation guarantee is the same (3rd party developers are affected). Modifications in class are dangerous for all descendant classes.
private methods are your safe harbor in this doubtful world. They guarantee you that code in your methods is dangerous to modify only in boundaries of single class (which means that when you have tests for your protected/public methods that cover all calls of your private method, and as long as you don't do magic, like side effects or usage of global state, you are safe for modifications and you won't have Jenga effect).

Therefore, use private by default and public/protected when you need to provide access.
There is also one modern trend that I discovered. People, who practice TDD and cover 100% LOC with tests, usually end up with almost 0 private methods, because private methods are hard to test. Encapsulation is then usually guaranteed by usage of shim classes.
This leads to good thing - implementation can be replaced with more performant/maintainable/flexible/better class easier; but this also leads to bad thing - people try to create very thin layers of functionality, like 100 classes of 10 LOC, and every such class performs a single for loop or a single call to real class, with usually too technical name and too thin focus.
Instead, it is better to hide your implementation behind private method first and when it has grown too much (e.g. dependencies for class with private method have grown too much, or LOC are too many) or when you require more flexibility, or you start seeing that it is starting to have different focus than original class - don't hesitate to extract it to separate class.

Hey, thanks for nice summary.
Could you put it into short PR that would explain it on examples for entry-level programmers?

Yep, but this is just draft, so I wouldn't include it in current state. I will clean it up and provide references to respected sources, and then open PR :+1: .

Opinion on the matter from Fabien Potencier: http://fabien.potencier.org/pragmatism-over-theory-protected-vs-private.html
Guys, I don't have time to clean it up, sorry. You can use what I wrote here, extend/copy-paste, if needed. However, as always in life, there is no single proper way to write code. I feel that my first post is incomplete and requires more in-depth discussion (and it can easily become as long, as current Readme.md). So instead of overthinking, I would suggest you to share whatever works for you in Readme.md. Thanks.

Since PR is already merged and issue is long due, I close it.
Thank you for your effort in building a comprehensive guide to best practices for PHP devs! This helps a lot!

Glad to help :+1: I always miss simple clear example on how to code.
The credit belongs to @peter-gribanov who came up with this idea, boosted it and spread it over the internet :+1:


Request: vnStat as a tab in System Info

Hey,
Title says it all. Is it possible we can have vnStat tables shown inside the System Info page as a tab next to disk and processes? I think this would make sense, make use of the space already available to us and clean up the menu.
Kind Regards,
Jay

I agree that having enough space for all the apps are a issue if your running many of the apps. The current solution is to shorten the name to prevent the menu from wrapping. Dunno if anybody is using the vnstat module.
I don't think I will intregrate this in stats module, I'm working on a very (very, very) simple script module. This one will be added next to the smart report tab.

Just to chime in, I use the vnstat module :)

Nice, its was a pita getting the dates right, so i glad someone uses it.

@brando56894 Would you mind posting a screen shoot of the vnstat module. I would like to update the images in the forum thread and here, but its not that pretty when you dont have any graphs..

I do not have a large backlog of stats, but hopefully this is of some use to you?

Thanks!


v1.4_2018-11-28 is now available!!

Dear Developers,
We managed to release the v1.4_2018-11-28 version. This release adds support new features such as find phone, find smart-band, incoming message notifications, and remote shutters (release notes here).
Kindly check it~
Many thanks.
-- GOLiFE GoFIT SDK Team.

Suppose this issue can be closed. Many thanks.


Monitor zerotier

Monitor zerotier daemon with 0-Watchdog

automatically respawns on the node throught zero-os itself

Actually core0 return process back in the moment u kill it
Software version
8124cc51afc8f1f6e1431f50e4e83894954e4091


feature req: const Buffer::getData() and ADatatype::getRaw; clarify Buffer::setData() copy and move

Request api adjustment to enable more code uses. Change dai::Buffer::getData() -> dai::Buffer::getData() const
Made in a separate PR (trivial I can make) or as part of the zerocopy buffer effort.
Code change needed is add the 6 chars to the signature declaration in Buffer.hpp and its signature in the implementation.
The change enables code like...
void myfunc(const dai::ImgFrame& frame) {
    const auto size = frame.getData().size();
    const auto ptr = frame.getData().data();
    ...
}

@diablodale
I'd suggest opening a PR, separate, for this, to merge faster, without zerocopy - I'm not sure how soon I'll be able to get back to zerocopy and Messages refactor (probably next week, more likely week after that...)

forthcoming PR has above change and two additional changes

add same const ADatatype::getRaw() const
add/clarify copy and move overloads for Buffer::setData()

verified the fix was merged into develop and all tests are passing using 04d5149e7cfddc4dc871d55d1a3d9ee270b76835


Lra 44 setup required fields in tables

This is not a pull request yet because the Infrastructure group hasn't added required fields to the [It Security Incidents] tab in the [Security Tracking Tool - Database fields] spreadsheet. But I want you to review the code.

I merged LRA-42-device-creation-for-main-tables to this branch because I had to change the database tables (and hence views) in this branch and therefore couldn't work in LRA-42-device-creation-for-main-tables branch (tables and view didn't match).
The following I added to the device-create function:

search the TDX assets database by serial number and hostname (user enter a serial or hostname into [Add device] field)
error message in case multiple records are returned by TDX API
create a device with hostname or serial

I improved the TDX API method (get_device_data) a lot:

moved it to a module
call it from controllers: legacy_os_record create and show and device create methods
Added incomplete scope and incomplete? method to the device model  (not sure if queries are correct)


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


return offset-aware modification time

Closes #817

Merging this, having decided that keeping information should always be preferable (even though the timezone is always UTC).


Particles stop emitting if set a initial velocity [macOS]

Godot version:
Master (6c9ccf1)
OS/device including version:
macOS 10.14.5
RX 580
Issue description:
Particles stop emitting if set a initial velocity
(it works before)
Steps to reproduce:

create a Particles node
assign a Mesh and ParticleMaterial
it start emitting
set Velocity in Initial Velocity to any value
it stop emitting

I can't reproduce in current master becbb7b525e1cc9bf1520a0ac94b9e9f799f6169
When you set initial_velocity does the emitting checkbox get unchecked?
Also what value are you setting initial_velocity to? When I set it above 600 the particles move so fast I don't see them.

I set it to 1 only~
I will try it at current master later (becbb7b)

Tested in current master (becbb7b)
have same issue in Mac.
but I test in Windows PC. It work fine.
maybe a Mac only issue.
Machine Detail:
MacBook Air
1.6 GHz intel Core i5-8210Y
16GB Ram
RX 580 External GPU

I was unable to reproduce on linux. Try with CPUParticles to see if it's an error with the graphics?

CPUParticles work fine.
no error message in console

Almost definitely a platform issue with OSX then.

Could you test if #36031 fixes it for you?

yes, it's fixed after apply that commit, thanks👍🏻


Diff options

Allow diff collapsed and prefilter (deep-diff)

This change is

Codecov Report

Merging #222 into master will decrease coverage by 3.79%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master     #222     +/-   ##
=========================================
- Coverage   68.38%   64.58%   -3.8%
=========================================
  Files           5        5
  Lines         136      144      +8
=========================================
  Hits           93       93
- Misses         43       51      +8

Impacted Files
Coverage Δ

src/core.js
69.56% <0%> (-9.13%)
:arrow_down:

src/diff.js
8% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Add initial support for sparc-unknown-linux-gnu

While the Rust compiler already supports the sparc-unknown-linux-gnu target, the libc crate is missing support for it. Let's add it so that Rust can built for this target as well.

r? @gnzlbg
(rust_highfive has picked a reviewer for you, use r? to override)

r? @alexcrichton

Can we try to re-run the rust-lang.libc test? The failure seems unrelated.

@bors: r+

:pushpin: Commit 25e71b1feb2bcf8fa725a55d6555997d69c58523 has been approved by gnzlbg

:hourglass: Testing commit 25e71b1feb2bcf8fa725a55d6555997d69c58523 with merge 1b179f2b2c658cbbb8c8470408653b9f1750253a...

:broken_heart: Test failed - status-azure

Looks like there are unrelated test failures for some tests. Would a manual merge be possible?

Looks like there are unrelated test failures for some tests

Yes, looks like nightly Rust broke a couple of libc jobs. Need to fix that upstream.

Would a manual merge be possible?

Sadly no, all PRs are blocked on the build being green, too many crates depend on libc.

@gnzlbg Any idea when the CI will be working again?

Just rebased and force-pushed, should be good for merge after CI has finished.

@bors: r+

:pushpin: Commit 7b2e915b01385b909b9194aa98937f7a7a55fbac has been approved by gnzlbg

:hourglass: Testing commit 7b2e915b01385b909b9194aa98937f7a7a55fbac with merge c881cacd64ba5f4baa7fd1b7a557364aa1c3b012...

:boom: Test timed out

@bors: retry

:hourglass: Testing commit 7b2e915b01385b909b9194aa98937f7a7a55fbac with merge c23c9115ec484a2bbad47a63a7f0fefb63440c95...

:broken_heart: Test failed - status-azure

Failure is unrelated, the CI process for "DockerLinuxTier2 aarch64-unknown-linux-android" failed to install build dependencies due to a time out.

@bors: retry

:hourglass: Testing commit 7b2e915b01385b909b9194aa98937f7a7a55fbac with merge 9c6d0856fb76e4dfefc6fda7e051d0b21e147b73...

:broken_heart: Test failed - status-azure

Same failure: same target and package that failed to download.

@bors: retry
Let's try one more time.

:hourglass: Testing commit 7b2e915b01385b909b9194aa98937f7a7a55fbac with merge fac614d54290b2fa801b8559519031193c2dedcb...

:broken_heart: Test failed - status-azure

Rebased and pushed. Let's see if the CI is happier today.

@bors: r+

:pushpin: Commit 8b3b17ffb0821d673befc093a8262b6a9894d145 has been approved by gnzlbg

:hourglass: Testing commit 8b3b17ffb0821d673befc093a8262b6a9894d145 with merge a5b6656ba4f3a4c0fc2707ee1e6baad994d0a6af...

:broken_heart: Test failed - checks-cirrus-freebsd-11

CI failed again for unrelated reasons :(.

@gnzlbg Can you approve again?

Every time the source code is modified I need to review, and with the re-bases it is unclear to me what changed from the previous time I reviewed, so I kind of need to review all of it, which takes time. It would be simpler if new commits were independent commits.

@bors: r+

:pushpin: Commit 034574cc52ba12cf7b11a6a76488da587d8deb63 has been approved by gnzlbg

:hourglass: Testing commit 034574cc52ba12cf7b11a6a76488da587d8deb63 with merge 7a12eedd522e09903745e41ca1f0bbef385a77bd...

@gnzlbg I'm just rebasing every time and then force-pushing to retrigger the testsuite. No changes.

Ah, please don't do that. That re-triggers the test suite here, blocking the queue and preventing from bors from trying to merge it, and requires re-reviewing the PR instead of just retrying it.
It's better just to ping me :)

:sunny: Test successful - checks-cirrus-freebsd-10, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, status-azure
Approved by: gnzlbg
Pushing 7a12eedd522e09903745e41ca1f0bbef385a77bd to master...


testng-adapter picking up the old version of the extent reports from mvn repo.

Hi,
I can see  the new POM of extentreports-testng-adapter is been updated with the latest extent reports ver 4.0.9. when used from the mvn repo its still picking up the old version 4.0.6 Please see the screenshot.
Many Thanks,

In case you are still having this issue, I would suggest:

Doing a rebuild of project so maven can download all dependencies
Excluding extentreports dependency from the adapter and explicitly using 4.0.9


timeframe for custom datetime properties

Hi guys!
I already found the notice inside the docs (https://keen.io/docs/api/#timeframe) that says timeframes can only applied to the keen.timestamp property.
Why did you choose this restriction? And is there any solution to make intervals (+ timeframes) work with my custom datetime property?

It is because the only property that supports a Datetime type is the keen.timeframe.
One alternative is that you can send it in with the Datetime enrichment and then do a filter with that. See more here: https://keen.io/docs/streams/datetime-enrichment/

thank you for the hint, @tbarn ! I'll check out the datetime enrichment :)


Glow Preview completely blank in Powershell

Describe the bug
I try running :Glow on Windows with Powershell 7.1.3 but the popup window is completely blank.
If I go into insert mode in the floating window and press enter I get the message An unknown element "" was received. This can happen if the remote process closed or ended abnormally
Weirdly enough, it works perfectly well with the original cmd shell.
While this plugin probably doesn't have Windows too high on its compatibility list, I would appreciate any help.
To Reproduce
Set the shell to pwsh or powershell
Run :Glow
Expected behavior
There will be a markdown preview in the pop up window
Additional context
Neovim Version: NVIM v0.5.0-dev+1233
OS: Windows 10
Terminal: Windows Terminal 1.8.14444.0

So you are saying that the glow command works outside neovim but not inside? can you share some screenshots please? Unfortunately I don't have a way to test on Windows machines now.

PowerShell in regular terminal:

CMD in regular terminal:

Neovim with CMD shell:

Neovim with Powershell shell:
Initial:

After going into insert mode and pressing enter 2 times:

Can reproduce this issue...


add schema to control asym/sym

Type of Change
add params in examples scripts

mistral autoround nf4: https://inteltf-jenk.sh.intel.com/view/nlp-toolkit-validation/job/nlp-toolkit-validation-top-mr-extension/1608/

https://inteltf-jenk.sh.intel.com/job/nlp_toolkit_optimize_validation_localtest/7115/


Lint for invalid datum[] indexing

Closes #1876
Invalid in BYOND 515.1641+
Don't want to make it fatal since it'd brick OD compilation of codebases targeting older versions.

CI failure is unrelated.

This is warning on goon's /datum/db_record which has operator[] defined.

Fixed it.


Add mirror method to BexPairCore which returns a new BexPair with left and right swapped

Will be part of 0.4


fix(getWeeksBetween): correctly handle differing timezones

getWeeksBetween could return incorrect results if the two dates are in different timezones, for example around the Daylight Savings Time transition. This PR makes it adjust them to be in the same timezone before calculating.


feat(md-fab-speed-dial): implementation

Fixes #860

Hi @jefersonestevo
As outlined in our contributing guide, the first step in working on a large feature like this is to open an issue for discussion. Going from there, we always start with a design document and design review with the team. We go through these steps to ensure that everything in the library meets our standards for accessibility, i18n, and consistency with the rest of the code-base.
Feel free to open a new issue (or start a discussion on the existing one) to start discussion on your proposed feature.


(Help needed) Running tRPC and React app on server

Hi,
I have a question regarding architecture.
After pulling code I updated tRPC to the latest version and updated everything accordingly.
Now when I do tauri dev build for desktop app (macos in my case) it works just fine, tRPC is spinning on port 3000 and app is open on port 1420 the comunicate.
This way web app also works. But as soon as I kill tauri dev and try running tRPC separately by just running server:watch or manually trying to run index.ts or any other way backend (trpc) is just not up I can't reach it on port 3000 on separately run React with vite dev.
watch-server.js completes build and everything seams fine but tRPC is not available at port 3000
Am I missing something here
Thank you in advance

Thank you, that works like a charm!
I made something similar with tsc building it and running then with node, but I like this single line approach with tsx more
Much appreciated 😊


stripe.paymentIntents.create not implemented

Stacktrace
No matching path: /v1/payment_intents
  at Function.generate (../../node_modules/stripe/lib/Error.js:40:16)
  at IncomingMessage.<anonymous> (../../node_modules/stripe/lib/StripeResource.js:190:33)

Yup.  Payment Intents is a very large undertaking.  A lot of the resources are basic CRUD, but the state here is more complicated.

Yup.  Payment Intents is a very large undertaking.  A lot of the resources are basic CRUD, but the state here is more complicated.

Starting without the state would be a step forward and better than failing requests.

I don't know if I agree.  Having paths that can't store state in a library whose whole purpose is being stateful would be confusing.  People would rightly expect it to be stateful, write tests against it, and then be unhappy when it doesn't work.


Remove link locales

This matches the link localization guidance

@nschonni : PR spans a lot of content areas within the repo, owned by different individuals. Need to survey to make sure that there are no cases where a link is intentionally pinned to a US-English version.
@msatranjr : can you review?


Desktop notifications

The application should show a desktop notification when there's a new message (from any visitor) so they don't have to watch the application.

I'm interested in this and will try and tackle it.

[ ]
[ ]
[ ]
[ ]

This was completed in #61


Fed Node 9.49.3->Develop: counterpartyd can't run after Rebuild

Rebuilt using develop counterpartyd_build scripts to simulate the upgrade from 9.49.3.
It all worked well, except that counterpartyd can't start and judging by the log it hasn't started ever since I shut it down as v9.49.3:
rippler@ubuntu:~$ sudo su -s /bin/bash -c 'counterpartyd -V' xcpd
/home/xcp/counterpartyd_build/env/bin/python: can't open file '/home/xcp/counterpartyd_build/dist/counterpartyd/counterpartyd.py': [Errno 2] No such file or directory
rippler@ubuntu:~$ sudo dir -la /home/xcp/.config/counterpartyd/counterpartyd.log
-rw-rw-r-- 1 xcpd xcp 9371842 Jan 22 17:37 /home/xcp/.config/counterpartyd/counterpartyd.log
rippler@ubuntu:~$ date
Fri Jan 23 03:05:23 UTC 2015
rippler@ubuntu:~$ ll /home/xcp/counterpartyd_build/dist/counterpartyd/counterpartyd.py
ls: cannot access /home/xcp/counterpartyd_build/dist/counterpartyd/counterpartyd.py: No such file or directory

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

The newest version removed the counterpartyd.py file. Run.py will probably go away or change a lot at the least... If you got to this point, we should be good

is this still an issue?

I didn't notice it in recent days (and I did try to upgrade from 9.49.3), so I think it's been fixed.


strange failure trying to run railway up

running on railway 2.0.7
when I try to run railway up for a linked project, I get this error
🚞 Laying tracks in the clouds...
🚨 open /Users/samgrund/.docker/run/docker-cli-api.sock: operation not supported on socket

any ideas what's wrong?

Maybe try the same command with sudo or higher permission as the Run as Administrator command.
sudo railway up

Still an issue on my end.

Same here. This is a fresh Homebrew install on macOS:
»  railway up
🚨 open /Users/bradpurchase/.Trash: operation not permitted

Same issue my end too.
.Trash: operation not permitted


merge from arlac77/template-github,arlac77/template-kronos-component

package.json

chore(deps): add ^13.1.0 remove ^13.0.2 (devDependencies.documentation)

Codecov Report

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

@@           Coverage Diff           @@
##           master     #781   +/-   ##
=======================================
  Coverage   91.28%   91.28%
=======================================
  Files          12       12
  Lines         792      792
  Branches       94       94
=======================================
  Hits          723      723
  Misses         69       69

Continue to review full report at Codecov.

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


[APIView] Process for tooling update

Tooling update can create diff on the views in two ways:

View "glitches" that didn't interfere with the API approval
View major bug fixes, that now shows API that should have been reviewed but have been missed.

For those reasons, we believe we should have a process in place to tooling update:

Tooling updates should trigger an email of diff update to review for architects, to confirm what the tolling discovered
Tooling updates should not happen on code complete week for clarity
Tooling updates should start by using new version of the tool on the same version of the code, to clarify if there is a diff induced by the tool itself, before using a new version of the code. Otherwise it is not clear where the diff is coming from (from new code or new toling or both)
Tooling version should be pinnable as necessary for clarity

APIView changes are not deployed to production in last week of release unless there is a critical issue that blocks release. We will ensure this is followed thoroughly.
Most of the time parser version is updated when a change is made in Python parser that makes a view change. APIView also has a mechanism to update existing reviews using this new parser so diff against a new revision is using same parser version. I have a found a gap in this process and updated the code to refresh all automatic and pull request revisions when a new parser version is available. We will keep an eye on this change if this is not enough. I have noticed that this fix has already auto updated python reviews to latest parser version today when a new change is made to 0.2.5.


RDS updates failed

See https://github.com/cisagov/crossfeed/actions/runs/5047173120/jobs/9053662052, for https://github.com/cisagov/crossfeed/pull/1925

Being handled in PR #1940 .  Missed this before starting that work


Support ESM like ECharts v5.5

Currently, this repo is not maintained.
I also encountered #181 in nuxt, because of the missing of js extension when import module from echarts.
Many users cannot use this plugin (#141) which may be due to a dual package hazard (register liquidFill in umd while echarts is esm).
I believe both can be easily solved by migrate to a modern library bundler like unbuild or tsup.
ECharts 5.5 has already changed to default esm package https://github.com/apache/echarts/pull/19513. I think it makes sense to also follow this change in this repo
Is PR welcomed？ I would like to solve this issue.

Does this support echarts's version which is "echarts": "^5.5.0" ? It seems does not support for now, right ?

Does this support echarts's version which is "echarts": "^5.5.0" ? It seems does not support for now, right ?

It can be used with v5.5 but may not be out-of-box in some cases. It depends on your environment.


fix: display name instead of url as the publishercard title

Describe the changes you have made in this PR
Currently the website url is displayed twice. Instead we want to show the website name as the title of the publisher card.

Let's make sure we show the host somewhere prominent, too. Ultimately the host is the only thing that can not be changed and we have to be careful about phishing.


"Unable to locate glslangValidator at 'glslangValidator'" when I try to load shader

I can use toggle feature :+1:
But, then, running load-shader / watch-shader to load another .frag, I got an error.
Unable to locate glslangValidator at 'glslangValidator'

Hm,,,seems that it fails to resolve the path of glslangValidator.
 I fixed this by mv /home/entyo/VulkanSDK/<IP_ADDRESS>/x86_64/bin/glslangValidator /usr/local/bin :smile:

hi there, where can I find path on mac?


Feature Show Days

It would be nice if one could additionally display the days on the left side. Like on github.
like Mon, Wed and Fri or so.

I'll try to submit PR with this feature in the next few days

Hey, I've submitted PR with this feature implementation.
Can you check it? #37

It's done now, I guess this can be closed


New rule prefer-named-backreferences

Backreferences to named groups should probably refer to the group by name and not by number.
// valid
- /(a)\1/u
- /(?<foo>a)\k<foo>/u

// invalid
- /(?<foo>a)\1/u
//          ^~

The rule should be auto-fixable.

I like this rule!


Predict Take a long time

Thanks for your great library but i use this library in web api project and it take a long time and at the end it cant predict anything. i run your test code and its not work.

Hey,
Thanks for the first issue. What are the specs (CPU, GPU, RAM, OS) of the system you're running NsfwSpy on?

Core I7-12700H
16 GB RAM
Windows 11 pro
OS build 22621.1848
NVIDIA GeForce RTX 3060 Laptop GPU

That should be plenty enough power wise. Does an exception get thrown? If you put a breakpoint in the code, does it ever get past the classification?

No i dont get any exception. When i run my app it take 8 minutes to go my breakpoint and after this I waited for an hour but nothing happened.

Do you know if you have a version of CUDA installed on your system? You should be able to check by running the following command in a command prompt window:
nvcc --version

Yes, I had installed it
This is a command result
"nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2019 NVIDIA Corporation
Built on Sun_Jul_28_19:12:52_Pacific_Daylight_Time_2019
Cuda compilation tools, release 10.1, V10.1.243"

That looks to be right too. Might be worth trying to use it in a Console application as that should show some logging and may give a hint as to what is going wrong.

I run it in Linux and it worked correctly. Incredible

Wonder what the issue was for your Windows setup. If you ever get round to running it as a Console application on Windows and get any useful logs, just let me know and I can continue investigating 😊


Propagate --no-pty to the bootstrap --pty flag

buildkite-agent start has a --no-pty flag which prevents the bootstrap from being run as a PTY process.

Seperately, buildkite-agent bootstrap has a default-true --pty flag which determines whether commands run within the bootstrap are run as PTY processes.
Presumably, buildkite-agent start --no-pty should propagate to buildkite-agent bootstrap --pty=false, but that was not happening. That meant that builds running under buildkite-agent start --no-pty invoked a bootstrap as a non-PTY process, but the bootstrap invoked commands in PTY mode. On systems with no PTY capability (e.g. AWS Lambda) that was causing severe errors:

This pull request propagates the flag into the bootstrap via the internal BUILDKITE_PTY environment variable.
Here's that previously failing build step:

Thanks @pda  :heart:


'devise_for' directive in routes.rb gives 'relation "users" does not exist' error

devise_for directive in routes.rb gives relation "users" does not exist error.
When I try to load database via db:schema:load command, If routes.rb have this lines (or equivalent):
 devise_for :users, .. controllers: {
      sessions......
       ...
  }...

then I get PG::UndefinedTable: ERROR:  relation "users" does not exist error. If I remove that devise_for directive then everything works perfectly. This behavior made our deployment on new machines painful.
Something is triggering deivse OR sequel before load happens.
Ruby 2.4.2 on Windows (and linux) with latest version of devise, seqyuel (5.2) and Sequel-Rails used.
Trace:
Caused by:
PG::UndefinedTable: ERROR:  relation "users" does not exist
LINE 1: SELECT * FROM "users" LIMIT 1
                      ^
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/rack-mini-profiler-0.10.6/lib/patches/db/pg.rb:90:in `async_exec'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/rack-mini-profiler-0.10.6/lib/patches/db/pg.rb:90:in `async_exec'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:145:in `block in execute_query'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/bundler/gems/sequel-rails-3fe1f449c968/lib/sequel_rails/sequel/database/active_support_notification.rb:17:in `block in log_connection_yield'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/notifications.rb:166:in `block in instrument'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/notifications.rb:166:in `instrument'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/bundler/gems/sequel-rails-3fe1f449c968/lib/sequel_rails/sequel/database/active_support_notification.rb:11:in `log_connection_yield'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:145:in `execute_query'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:133:in `block in execute'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:109:in `check_disconnect_errors'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:133:in `execute'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:449:in `_execute'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:273:in `block (2 levels) in execute'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:471:in `check_database_errors'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:273:in `block in execute'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/database/connecting.rb:264:in `block in synchronize'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/connection_pool/threaded.rb:87:in `hold'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/database/connecting.rb:264:in `synchronize'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:273:in `execute'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/dataset/actions.rb:1085:in `execute'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/adapters/postgres.rb:559:in `fetch_rows'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/dataset/actions.rb:151:in `each'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/dataset/actions.rb:85:in `columns!'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/dataset/actions.rb:75:in `columns'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:242:in `columns'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:802:in `block (2 levels) in get_db_schema'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:718:in `block in check_non_connection_error'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/database/transactions.rb:151:in `block in transaction'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/database/connecting.rb:264:in `block in synchronize'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/connection_pool/threaded.rb:91:in `hold'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/database/connecting.rb:264:in `synchronize'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/database/transactions.rb:145:in `transaction'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:718:in `check_non_connection_error'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:802:in `block in get_db_schema'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:835:in `get_db_schema'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:637:in `set_dataset'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/model/base.rb:492:in `inherited'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/sequel-5.2.0/lib/sequel/plugins/subclasses.rb:70:in `inherited'
D:/testapp/web/app/models/user.rb:1:in `<top (required)>'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:476:in `load'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:476:in `block in load_file'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:661:in `new_constants_in'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:475:in `load_file'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:374:in `block in require_or_load'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies.rb:36:in `block in load_interlock'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/dependencies/interlock.rb:12:in `block in loading'
D:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/activesupport-5.1.4/lib/active_support/concurrency/share_lock.rb:149:in `exclusive'

There is a workaround for this issue (as far as I discover):
wrap devise_for directive with:
if Sequel::Model.db.table_exists?(:users)
    devise_for ...
end

This will make sure that devise_for directive only run after :users table gets loaded successfully. So, schema load will work, frontend also will work too.
It seems, User model and devise gets loaded just before hooks runs. They should be delayed.

I confirm the issue and the workaround

I have permanent Sequel::Error: No database associated with Sequel::Model: have you called Sequel.connect or Sequel::Model.db= during rake db:drop/create/migrate. So, my variant of workaround:
  unless Rake.application.top_level_tasks.present?
    devise_for :users
  end


RangeError: Offset is outside the bounds of the DataView

Please provide steps or model files to reproduce this issue.

Same Issue

@steven0129 can you share the model file to reproduce the issue?

@lutzroeder The problem seems to have been gone for now.

model.json from:
https://tfhub.dev/tensorflow/tfjs-model/posenet/mobilenet/float/075/1/default/1
will reproduce (expand the filter weight of the first conv)

@TomWildenhain-Microsoft this seems to be a corrupt model file. After extracting posenet_mobilenet_float_075_1_default_1.tar all files are compressed in Gzip format even though the file extensions suggest otherwise. Can you clarify this with the model author?

Yep the weights are gzip compressed.  There are actually a lot of tfjs models on tfhub with gzip compression, even on .json files.  I didn't make the model. I have no idea why Google likes to do it this way.  It's fine with me if Netron doesn't handle these ones, just posting since the dialog box requested it.


⚠ Bofrost.at has degraded performance

In 31f4410, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2378 ms

Resolved: Bofrost.at performance has improved in 1ca123b after 8 minutes.


I need some help from you..

from .__ext import lib as _lib, ffi as _ffi
i can't find the ._ext/lib and ._ext/ffi
this error arise: No module named 'libs._ext._ext'
could you fix the problem for me?

Have you compiled the inplaceABN before using the code?
Compiling
Some parts of InPlace-ABN have a native CUDA implementation, which must be compiled with the following commands:
cd libs
sh build.sh
python build.py

The build.sh script assumes that the nvcc compiler is available in the current system search path.
The CUDA kernels are compiled for sm_50, sm_52 and sm_61 by default.
To change this (e.g. if you are using a Kepler GPU), please edit the CUDA_GENCODE variable in build.sh.

I will close this issue. You can contact me if you have any other questions.

@irfanICMLL Hi, I complied the InPlaceABN but got an error "ImportError: torch.utils.ffi is deprecated. Please use cpp extensions instead." when I try to run 'python build.py', the pytorch version is 1.5.0.


[BUG]: Power BI - Power Platform Admin Dashboard - Cloud Flows - Part of report doesn't show Team environment flows

Describe the bug
Power BI Dashboard – “Cloud flows”, bottom left report does not display flows that are in Teams environments. Have tried different filters and resetting the filters. See screenshot.
Component (please tell us which flow or app you are experiencing issues with):

Solution Core
Version 1.98
App or Flow Power BI Dashboard

To Reproduce
Steps to reproduce the behavior:

Go to 'Power BI Dashboard'
Click on 'Cloud flows'
Select a Team environment.
Part of the dashboard is reporting there are flows, and another part isn't. See screenshot

Expected behavior
Report should display flows from all environments.
Screenshots

Additional context
NA

Hello. Did you select that dot? If so it filters the date of creation. Did you have any flows made in teams on that day?

Hello,
can you try removing the # of actions column so only the below are selected for the table visual?

We had an issue with this visual in that if we didn't sync the # of actions for flows, the flows wouldn't show up there but this will be fixed in the next release. In the meantime, you can fix this yourself by removing the # of actions column from this table visual.
Thank you for using the CoE
Manuela

Fixed with the current release, shipped today. Thank you for using the CoE!


FY2020Q3 content refresh

Updated screenshots, slides & dependencies where necessary.

Ready for merge @jasonjoh ... associated MS Learn module PR already submitted: https://github.com/MicrosoftDocs/learn-m365-pr/pull/1030


no release file for Ubuntu 22.10 (Kinetic)

I have your PPA in my sources from pre-upgrade to Ubuntu 22.10. When I try to check for updates post-upgrade, the system says that there is no release file for your PPA. Only way I can get around this is to open the alesandroastrada.list file and comment out your PPA entry. Is there an updated PPA I should be using, or should I just clone the git repository and build from source?
Thanks in advance,
Guy

I just published the packages for kinetic.

That is great news! Thank you for replying so quickly.JAWS Certified, 2021, https://www.freedomscientific.com/Training/CertificationOn Nov 15, 2022, at 7:07 AM, Alessandro Strada @.***> wrote:
I just published the packages for kinetic.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>


Typo in documentation: fist -> first

Under "Get started":
"Here is the perfect moment to add the send_page_view property to false if you don't want to send the fist page hit on load of your application"
should be:
"first page hit"

thanks a lot :)


Icon names containing ~ are not replaced

There are now redirects that contain single tildes. They are not being replaced because of [^\\~\n]+? in the regular expressions.

It might be possible simply to remove ~ from that part of the regular expression. Even with icon names starting and ending with ~, the regular expression seems to work (and in some cases the tildes would have to be separated by a space anyway to prevent signature generation).

Taking ru:Template:Малое кольцо Московской железной дороги as a testcase, that change results in the following new regex matches (icon part only): ['~~', '~~1,2', '~~3,8', '~~4,9', '~~6,5', '~~13,8', '~~18,6', '~~20,3', '~~', '~~21,2', '~~', '~~', '~~', '~~25,5', "~~''{{ст.|Симоново}}'', ''{{ст.|Лизино}}''", '~~27,9', '~~30,2', '~~31,0', '~~33,4', '~~33,9', '~~35,0', '~~37,5', '~~37,9', 'exlv-BHF~g', '~~38,6', '~~39,3', 'exlvBST~g-', '~~', 'dBHF~R yellow', "~~''{{ст.|Октябрьские Казармы}}''", 'dBHF~R yellow', '~~44', '~~46,5', '~~', '~~48,0', '~~49,5']. Since most of those don't represent BSicons, we are left with ['exlv-BHF~g', 'exlvBST~g-', 'dBHF~R yellow', 'dBHF~R yellow'] to check if they should be replaced.
@jc86035 Please confirm this is the desired change.

I think this should be fine. BSicon names can't contain two consecutive tildes anyway (due to {{Routemap}} restrictions), although it might help to filter out matches containing two consecutive tildes to prevent indirect vandalism (e.g. from the creation of [[File:BSicon ~~.svg]] as a redirect).

(?=((?:\n|! !|!~|\\)[ \t]*)((?:[^\\~\n]|~(?!~))+?)([ \t]*(?:\n|!~|~~|!@|__|!_|\\))) should do it and gives ['exlv-BHF~g', 'exlvBST~g-', 'dBHF~R yellow', 'dBHF~R yellow'] as new icon matches for the testcase.

@JJMC89 the icons are still not being replaced; e.g. w:en:Template:Duckmanton Junction. Interestingly this still happens in BS-map diagrams where the regex shouldn't affect tildes at all; e.g. w:en:Template:Dublin-Waterford railway line. I suspect this might be because the redirect list is not being downloaded due to being too long. Its length has tripled since 19 May. Maybe another mass deletion of unused redirects is needed.

the icons are still not being replaced

That is unrelated to the code change here. See https://github.com/JJMC89/JJMC89_bot/issues/29#issuecomment-393929449.


Fix GPU CI so that it runs on Python 3.8

This fixes https://github.com/pytorch/vision/issues/2972.

After merged, we might have to flush some CI caches. I recommend not to utilize CI cache functions.
https://github.com/Licht-T/vision/commit/5aa7d87709730f8cf9084fc7f42ee173527be6c6

@Licht-T
Could you add an anchor to the original environment definition and alias that in GPU CI job definitions? That way, at least new definition to environment will be propagated to the VM. (still manually have to pass these environment variables to docker container though)
Something like https://github.com/pytorch/audio/pull/1014/files

Thanks for the PR @Licht-T ,
looking at some more recent CI jobs, it looks like CircleCI is properly able to run GPU  tests on 3.8: https://app.circleci.com/pipelines/github/pytorch/vision/9150/workflows/5e911ca3-f0ef-409e-8437-d7b8649398c1/jobs/669225.
I'll close the PR, thanks again!


use innerText to escape htmlString when showRawCode is on

Description
fix #26
Linked Issues
#26
Additional context

If anyone could review my PR when they have time, I'd really appreciate it. Thank you!


How to write/enable two finger tap using hammer.js?

Closing this due to age and inactivity this is from V1. V2 adds mult touch support with multiple instances which would allow this.


[Entensibility Enhancement] Enum 362 "Analysis Period Type".  Extensible Property

Can the Extensible property be added Enum 362 "Analysis Period Type" so that we can add additional values via an enum extension please.
enum 362 "Analysis Period Type"
{
    AssignmentCompatibility = true;
    Extensible = true;

    value(0; "Day") { Caption = 'Day'; }
    value(1; "Week") { Caption = 'Week'; }
    value(2; "Month") { Caption = 'Month'; }
    value(3; "Quarter") { Caption = 'Quarter'; }
    value(4; "Year") { Caption = 'Year'; }
    value(5; "Accounting Period") { Caption = 'Accounting Period'; }
}

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Was this ever actioned?

Hi Jesper,
Was this ever actioned as I can’t see the change in my latest release of 20.8 Build 49971
Rgds

Michael Clarendon
Senior Consultant
@.***
+442083289818
@.***
07436 144708
@.https://www.facebook.com/thenavpeople
@.https://www.linkedin.com/company/the-nav-365-people
@.https://www.twitter.com/TheNAVPeople
@.https://www.youtube.com/channel/UC4D1Fxl_SwyFX7abeIjaI-A
Disclaimer: www.the365people.com/disclaimerhttps://the365people.com/disclaimer
@.***
Cyber Essentials Plushttps://www.cyberessentials.ncsc.gov.uk/about
From: Jesper Schulz-Wedde @.>
Sent: 04 April 2022 09:41
To: microsoft/ALAppExtensions @.>
Cc: Michael Clarendon @.>; Author @.>
Subject: Re: [microsoft/ALAppExtensions] [Entensibility Enhancement] Enum 362 "Analysis Period Type". Extensible Property (Issue #16801)
Caution: This email was sent from an EXTERNAL source. Do not click links or open attachments unless you are certain the content is safe.
Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/ALAppExtensions/issues/16801#issuecomment-1087278015, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AU3YP6KVO7O7V5MTVORBCDDVDKTLBANCNFSM5RLQI3DQ.
You are receiving this because you authored the thread.Message ID: @.***>

It is addressed from 21.0:

Hi Jesper,
Thanks for confirming it is in version 21.0
Rgds

Michael Clarendon
Senior Consultant
@.***
+442083289818
@.***
07436 144708
@.https://www.facebook.com/thenavpeople
@.https://www.linkedin.com/company/the-nav-365-people
@.https://www.twitter.com/TheNAVPeople
@.https://www.youtube.com/channel/UC4D1Fxl_SwyFX7abeIjaI-A
Disclaimer: www.the365people.com/disclaimerhttps://the365people.com/disclaimer
@.***
Cyber Essentials Plushttps://www.cyberessentials.ncsc.gov.uk/about
From: Jesper Schulz-Wedde @.>
Sent: 13 December 2022 08:37
To: microsoft/ALAppExtensions @.>
Cc: Michael Clarendon @.>; Author @.>
Subject: Re: [microsoft/ALAppExtensions] [Entensibility Enhancement] Enum 362 "Analysis Period Type". Extensible Property (Issue #16801)
Caution: This email was sent from an EXTERNAL source. Do not click links or open attachments unless you are certain the content is safe.
It is addressed from 21.0:
[Image removed by sender. image]https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F19796701%2F207266535-3b9cad1b-287b-440f-b444-b2485741abc4.png&data=05|01|michael.clarendon%40thenavpeople.co.uk|134e45c4208a40e6a0ee08dadce53052|c40d0f216bee41e89156f14592043ad0|0|0|638065174174736844|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=EfBheIm%2Fd0j71MsRkna2LE7VSEtXW7hWoaPICE72WD4%3D&reserved=0
—
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FALAppExtensions%2Fissues%2F16801%23issuecomment-1347930390&data=05|01|michael.clarendon%40thenavpeople.co.uk|134e45c4208a40e6a0ee08dadce53052|c40d0f216bee41e89156f14592043ad0|0|0|638065174174893072|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=aqNLONZlSoEOHz9V6Dtzgaow3KmXLGO5jYyRHn2Amlo%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAU3YP6IFVHDXHOXKIJ5QGNTWNAYSJANCNFSM5RLQI3DQ&data=05|01|michael.clarendon%40thenavpeople.co.uk|134e45c4208a40e6a0ee08dadce53052|c40d0f216bee41e89156f14592043ad0|0|0|638065174174893072|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=x978vPYK33F6MDKSJF1ePjpJgPi5ad61SMqBDAIKTa4%3D&reserved=0.
You are receiving this because you authored the thread.Message ID: @.***>


The Ender with Travel does not always work properly with travel anchors

My The Ender sword with Travel sometimes teleports me to a travel anchor when I just press shift, rather than pressing shift and right-clicking. It also sometimes shows the travel anchor even when I’m not holding the sword in my hand.
Minecraft version: 1.10.2
Ender IO version: 3.1.179
Forge version: <IP_ADDRESS>4

Are you standing on a travel anchor when these things happen?

Oh yeah, that’s probably it. Whoops.


Error in CMake generated build script

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10 1709
TensorFlow installed from (source or binary): source
TensorFlow version (use command below): 1.4.0-rc1
Python version: 3.5
Bazel version (if compiling from source): - (I use cmake)
CUDA/cuDNN version: 9.0/7
GPU model and memory: Notebook 1070 8G
Exact command to reproduce:
Use cmake to generate build script for Visual Studio 2017 Win64
CMAKE_C_COMPILER, CMAKE_CXX_COMPILER and CUDA_HOST_COMPILER should be set manually, otherwise, it will failed the compilation phase calling to NVCC

Describe the problem
This problem happens when building with Visual Studio 2017.4 + CUDA 9.0 + cuDNN 7 + CMake + GPU build.
Sorry for lack of information. I build it yesterday (and failed) and it take so long the compile through and I didn't keep the log. This problem is LINK ERRORs. What I can identify is they are in the generated build script. The problems happens exactly  in
_beam_search_ops.vcxproj
_gru_ops.vcxproj
_lstm_ops.vcxproj
_nearest_neighbor_ops.vcxproj

e.g. in  _beam_search_ops.vcxproj around line 103
    <Link>
      <AdditionalDependencies>\pywrap_tensorflow_internal.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\cudart_static.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\cuda.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\cublas.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\cublas_device.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\cufft.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\curand.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\extras\CUPTI\libx64\cupti.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\cusolver.lib;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\lib\x64\cudnn.lib;kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib</AdditionalDependencies>
      <AdditionalLibraryDirectories>%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
      <AdditionalOptions>%(AdditionalOptions) /machine:x64 /ignore:4049 /ignore:4197 /ignore:4217 /ignore:4221</AdditionalOptions>
      <GenerateDebugInformation>false</GenerateDebugInformation>
      <IgnoreSpecificDefaultLibraries>%(IgnoreSpecificDefaultLibraries)</IgnoreSpecificDefaultLibraries>
      <ImportLibrary>D:/workspaces/tensorflow/tensorflow/contrib/cmake/build/Release/_beam_search_ops.lib</ImportLibrary>
      <ProgramDataBaseFile>D:/workspaces/tensorflow/tensorflow/contrib/cmake/build/Release/_beam_search_ops.pdb</ProgramDataBaseFile>
      <SubSystem>Console</SubSystem>
    </Link>

You can see a \pywrap_tensorflow_internal.lib in <AdditionalDependencies> cause the LINK ERROR, since the linker can't find file pywrap_tensorflow_internal.lib.
The prefix backslash seems to be the cause. I suspect it should be some ${BLAH_env_VARIBALE}pywrap_tensorflow_internal.lib and this ${BLAH_env_VARIBALE} happens to be empty string and results to a \pywrap_tensorflow_internal.lib.
All four .vcxproj files comes from function call AddUserOps in tf_python.cmake , where the AddUserOps is defined in tf_cc_ops.cmake file. Due to my poor eye sight, I can't decide where is the problem from here...
Notice, I CAN see the file pywrap_tensorflow_internal.lib in some directory so it should be problem related with the path .

Unfortunately, we (TensorFlow maintainers) do not have enough expertise or bandwidth to support builds on Windows right now (as per https://www.tensorflow.org/install/install_sources - "We don't officially support building TensorFlow on Windows; however, you may try to build TensorFlow on Windows if you don't mind using the highly experimental Bazel on Windows or TensorFlow CMake build.").
So, I'm going to mark this as "community support", in the hope that someone with more familiarity with Windows and CMake builds can chime in.


NA Enhancements 2 - Electric Bugaloo

xgamer.dll downloads correctly now, and no longer gets overwritten with a 0kb file
"local config" support
small ui edit that doesn't completely break this time

Pending unit tests don't merge yet


Netherlands Antilles (ANT) country code is missing

Hi, after using your library on flight booking site I've noticed that there is one country missing on the list:
Netherlands Antilles
ISO Alpha-3: ANT
https://laendercode.net/en/3-letter-code/ant
Is it possible for you to add the missing country?

We already had the request
AN - Netherlands Antilles is missing


The value given by [Bug Report] color picker does not correspond to the value selected in the component

Element UI version
1.3.4
OS/Browsers version
chrome
Vue version
2.3.3
Reproduction Link
https://jsfiddle.net/pqjbLyqn/
Steps to reproduce
ColorPicker 给默认的值，组件里面显示的值不一致
What is Expected?
ColorPicker 给默认的值，组件里面显示的值应该一致
What is actually happening?
ColorPicker 给默认的值，组件里面显示的值不一致

Fixed in #5183.


fix(icon): namespace error when registering an icon on the server

Fixes the MatIconRegistry throwing a namespace error on the server due to the xmlns attribute. These changes remove the attribute, because it's optional under HTML5.
Fixes #10170.

This is great, I hope to see it in the next release...


Latest version of d3 breaks d3-cloud-nd

Use
"d3": "~3.5.16"
for a quick fix.

Unfortunate these kind of breaking changes. Can you provide the error message you were getting? I'd like to dig a little deeper to whether this is just a regression of d3(-cloud), or maybe an api change..

angular.js:12798 TypeError: Cannot read property 'category20' of undefined
at Dispatch.r (d3-cloud-ng.min.js:1)
at Dispatch.end (d3.layout.cloud.js:486)
at step (d3.layout.cloud.js:76)
at Object.cloud.start (d3.layout.cloud.js:53)
at Scope.t.createCloud (d3-cloud-ng.min.js:1)
at d3-cloud-ng.min.js:1
at Scope.$digest (angular.js:16218)
at Scope.$apply (angular.js:16482)
at done (angular.js:10862)
at completeRequest (angular.js:11060)
undefined would be d3.scale

This seems to be a similar issue. I need to rethink whether to fix on v3 for now, or move forward to v4. Or maybe there is a way to run compatible with both?
http://stackoverflow.com/questions/38536456/angular-nvd3-gives-various-errors-saying-that-d3-scale-is-undefined

Looking into it in more detail, it seems d3.scale.category20() was renamed to d3.schemeCategory20(). Should be relatively simple to use (d3.schemeCategory20 ? d3.schemeCategory20() : d3.scale.category20()). That would allow supporting both d3 v3 and v4..

On further testing above change was insufficient. d3.on does no longer take a hash with multiple event callbacks, and even if you fix that, it still doesn't paint anything. I'll open a separate ticket for d3 v4 support..

Solved via bower.json.


sh: 1: glusterfs: not found

If your compose app or docker run statement fails to launch and you inspect your docker hosts and see the following error:
2016/04/21 19:00:37 Mounting volume myvol on /var/lib/docker-volumes/_glusterfs/myvol
2016/04/21 19:00:37 sh: 1: glusterfs: not found
The reason is that you do not have the glusterfs mount driver installed on the host that the container is attempting run (or be scheduled) on. To remedy this, run the following commands on all the hosts in your cluster on which you expect to run a container with the glusterfs volume plugin:
Debian based:
sudo apt-get install -y glusterfs-client
RHEL based:
sudo dnf install -y glusterfs-client

It would be awesome if you could add this to the README.md or start a docs/installation.md file so other people know how to properly install glusterfs' client.


Getting catapult style json events nested within each other.

Our profiler writes the longer scopes after the nested ones, since it's a scoped based profiler.  And occasionally we see events displayed nested inside them.   So this is an image where SkinMesh and SimMesh should be underneath the brown scope called AvatarBarn.    Note the later start time "ts" of SimMesh vs. the parent AvatarBarn.  This prevents selecting the sub events, and causes confusing when trying to read the flame chart.  It's like Perfetto periodically isn't tracking the timing stack correctly, but the profile in the same capture for the same events later on is correct.

This is the pink and brown bar in the json.
{
            "dur": 1222.31,
            "name": "SimMesh",
            "ph": "X",
            "tid": 2,
            "ts": 38538.161
        },

{
            "dur": 2490.403,
            "name": "AvatarBarn",
            "ph": "X",
            "tid": 2,
            "ts": 37747.046
        },

This should be supported - can you share a minimal trace which demonstrates the issue?

I have a huge capture, but it's proprietary.  I tried splitting out the json above, and it's rendered correctly.

Here's the bigger picture of that thread, but these timings shouldn't all overlap like this within a the thread, or even on their own tracks.

Okay, so looks like the AvatarBarn scopes do overlap, but that's how they are in the file. Maybe we're looking up the wrong thread id, since there is no work on the job thread below this one.  Still might be something you could flag during parsing.
{
    "displayTimeUnit": "ms",
    "traceEvents": [

        {
            "args": {
                "name": "Job2"
            },
            "name": "thread_name",
            "ph": "M",
            "tid": 2
        },

{
            "dur": 1.473,
            "name": "AvatarBarn",
            "ph": "X",
            "tid": 2,
            "ts": 37743.714
        },

{
            "dur": 18.973,
            "name": "AvatarBarn",
            "ph": "X",
            "tid": 2,
            "ts": 37742.281
        },

{
            "dur": 63.476,
            "name": "AvatarBarn",
            "ph": "X",
            "tid": 2,
            "ts": 37762.248
        },

{
            "dur": 2490.403,
            "name": "AvatarBarn",
            "ph": "X",
            "tid": 2,
            "ts": 37747.046
        },

}

There's no affinity control on macOS or iOS, so maybe the task scheduler is moving this work to another core before/after we record the timing.

We had two different tracing system recording timings with the same names and overlapping times.  So I think I fixed that by renaming one of them.   This may be a case where the event start timings aren't always within the scope of the part.

There are just too many weird cases like this.  Where we buffer scope with a threadID, and then write these out en-masse, but they end up overlapping.  So I have buffering like this disabled.

Sorry this is a data producer problem at this point not a trace processor or UI problem. The JSON spec [1] is very clear that B/E/X events cannot have overlaps only nesting.
You need to use async events (b/e) if you want to allow overlapping to happen.
[1] https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview