NPM list reports errors

Hi, I have some unmet dependencies on some installations when I do a npm -list, I think that latest is not handled correctly if the dependency (very common for request) is referenced by another packet in npm directory. Som users are exepriencing strnage behaviors sometimes with network issues, and reinstalling seems to fix it most of the time. I am not really used to @latest syntax in package.json,  do you have any idea if it could be a problem at all ?
+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| | +-- UNMET DEPENDENCY request@latest
| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | | `--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>deduped
| | +-- UNMET DEPENDENCY websocket@latest
| | `-- UNMET DEPENDENCY websocket-as-promised@latest
| +--<EMAIL_ADDRESS>| | `--<EMAIL_ADDRESS>| |   `--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>invalid
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>extraneous
| | +--<EMAIL_ADDRESS>| | | +--<EMAIL_ADDRESS>| | | `--<EMAIL_ADDRESS>| | +--<EMAIL_ADDRESS>extraneous
| | `--<EMAIL_ADDRESS>extraneous
| +--<EMAIL_ADDRESS>extraneous
| `--<EMAIL_ADDRESS>extraneous

It would probably be better to fix the versions.

Ok, do you want me to do a pull request ? I suggest we fixed in semver format to latest major version of each package, don't you think so ? Something like request : "^2.88.0"  for example ?

Would appreciate a pull request.

published your version 1.5.1


Enhancement: Need support for uni-directional contracts

The current contract implementation does not allow for uni directional contracts under the subject.
Currently revFltPorts is hardcoded to "yes"
Uni directional contracts are required for situations where DSR is required with a SG to return flows to a L4-7 devices, and also when configuring leaking between VRFs where consumer and provider contracts are required in both directions.
resource "aci_rest_managed" "vzSubj" {
  for_each   = { for subj in var.subjects : subj.name => subj }
  dn         = "${aci_rest_managed.vzBrCP.dn}/subj-${each.value.name}"
  class_name = "vzSubj"
  content = {
    name        = each.value.name
    nameAlias   = each.value.alias
    descr       = each.value.description
    revFltPorts = "yes"
    prio        = each.value.qos_class
    targetDscp  = each.value.target_dscp
  }
}

Unidirectional contract payload:
{
    "vzSubj": {
        "attributes": {
            "dn": "uni/tn-demo-05/brc-test/subj-test1",
            "name": "test1",
            "revFltPorts": "false",
            "rn": "subj-test1",
            "status": "created"
        },
        "children": [
            {
                "vzInTerm": {
                    "attributes": {
                        "dn": "uni/tn-demo-05/brc-test/subj-test1/intmnl",
                        "status": "created",
                        "targetDscp": "64"
                    },
                    "children": []
                }
            },
            {
                "vzOutTerm": {
                    "attributes": {
                        "dn": "uni/tn-demo-05/brc-test/subj-test1/outtmnl",
                        "status": "created",
                        "targetDscp": "64"
                    },
                    "children": []
                }
            }
        ]
    }
}

Also need support for this.  Resorting to an additional native hcl for these specific use cases.


Update boost to std

@deanberris
I took the leap ... as far as I possibly could I replaced boost classes/functions with their C++11/14 equivalents.
There's still a lot to do. I did not touch the code that depends on MPL/type traits because I think this should be eventually replaced (all the message stuff).
The thread pool still uses boost::thread_group, but I think it would be trivial to implement it ourselves (therefore we won't need to link to boost thread at all). As for the other boost static libraries, they are really only needed for some dependencies and for the examples.
Also, I did not touch the cpp-netlib MIME code (I don't know what to do with it, though I suspect it would continue to work if we used C++11/14 here).
Eventually I want to be able to build cpp-netlib without an external dependency to boost or asio. We can later use the boost-free asio, and for the rest a shrink-wrapped (header-only) boost.
Let's talk on slack if you want more info.

Wow, and Travis is green! Thanks @glynos -- I'll have a look soon!

I see you've removed the Twitter example -- did we need to update anything from the docs for that? Just wondering, I don't think we need to make the change now.

LGTM -- skimmed it, and I'm happy that Travis is green.
Thanks again @glynos!

I didn't update any documentation. We should go through that anyway, because I think it is out-od-date in a lot of ways.
twiitter_search has been a bit of an embarrassment because it just crashed, that's why I removed it completely. We need better examples.


Add warning of default QR Code provider to README.md

Optionally (and preferably) https://github.com/RobThree/TwoFactorAuth/pull/105 can be used instead of  this one, to fix issue https://github.com/RobThree/TwoFactorAuth/issues/104
To inform users of the potential security risk that comes with using the default QRServerProvider, add a small warning to the README.md

LGTM too 😉

Good point, I copied the text https://github.com/RobThree/TwoFactorAuth/commit/098dce67354809c98036b637bf0ecf81519cfa6b
Although technical a double warning now 😅 https://robthree.github.io/TwoFactorAuth/qr-codes.html


Split fuelHandlers.py into multiple scripts

Description
Reconfigured fuelHandlers.py into multiple scripts. Updated references to objects and methods as appropriate.

Checklist

[ ] The code is understandable and maintainable to people beyond the author.
[ ] Tests have been added/updated to verify that the new or changed code works.
[ ] There is no commented out code in this PR.
[ ] The commit message follows good practices.
[x] All docstrings are still up-to-date with these changes.

If user exposed functionality was added/changed:

[ ] Documentation added/updated in the doc folder.
[ ] New or updated dependencies have been added to setup.py.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Hunter Smith (Contractor) seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Heya!
Can I ask why we're splitting this stuff up?

You will need to sign the CLA before GitHub will let your PR spin up.
It looks like you have a Merge conflict.
We are trying to not use "Object" as part of the names for things in Python: armi/physics/fuelCycle/fuelHandlerObject.py. Essentially, everything in Python is an "Object", so you sometimes end up seeing codebases where every other variable or file has the word "object" in the name. So that doesn't help.

Thanks for contributing!

This PR changes the ARMI API.  And on balance, the change seems fine.
But the question here is the same as for any open-source project:

When changing the API of an open-source project, you will break a lot of downstream projects. Is the API change useful enough to warrant all the effort put upon people who are supporting downstream projects?

For instance, if the only reason to change the API here is that it seems nicer, than people who make ARMI plugins may not want to go through the effort to support this change.  But if the API change here gives us some new utility, and improves the functionality of ARMI in some way, people who support ARMI plugins and applications probably won't mind altering their code to meet the new API.

Let's say you move two classes (FuelHandlerInterface and FuelHandlerFactory) out of fuelHandlers.py.
But, instead of stopping there, at the top of fuelHandlers.py you put this:
from armi.whatever.fuelHandlerInterface import fuelHandlerInterface
from armi.whatever.fuelHandlerFactory import fuelHandlerFactory

If you did THAT then you would get what you want (cleaner code), but it would be backwards compatible.  And there would be a 0% chance of breaking someone's plugin.

For additional context, this work is being done to support implementation of the requirements for the fuel handling capabilities of ARMI drafted in the Fuel Module Management SRSD.

Due to CLA issues, this is being closed now and the code is now in https://github.com/terrapower/armi/pull/620. There were issues with the wrong email address on the git config --global user.email.


Enhancement: Improve Settings autocompletion and simplify regex in settings

After the release of version 2.0.4, I took a closer look at the extension.
Thanks here for the quick reply and the improvements.
Unfortunately, I currently have no time to set up JS myself and to learn to fix and improve things myself. Maybe in a few months time.
#29 was probably not really understandable and I had also made some wrong assumptions, therefore now again in more detail:
I understand now how it is done with the styles. In todohighlight.defaultStyle and also in todohighlight.keywords DecorationRenderOptions are used for the style .
Additionally in todohighlight.keywords there is text and regex which is defined by itself.
With this knowledge it is true that {...} for "before" cannot be removed.
Currently, the autocompletion for this looks like this:

How could the completion be improved for the styles?
We could of course define all parts from DecorationRenderOptions in the settings.json. But I would suggest to extend the documentation and show only the most important options as now.
One possibility would be to extend the following descriptions and indicate that all options from DecorationRenderOptions are possible:
https://github.com/jgclark/vscode-todo-highlight/blob/6b10ef6d5f96af9ce5fd1bf9019ad8c1f6531daa/package.json#L158 https://github.com/jgclark/vscode-todo-highlight/blob/6b10ef6d5f96af9ce5fd1bf9019ad8c1f6531daa/package.json#L110 Something like:
"markdownDescription": "... Further options can be found [here](https://code.visualstudio.com/api/references/vscode-api#DecorationRenderOptions).",

regex property improve or simplify
A quick fix is to fix the settings.json, because currently regex is not defined correctly. The following should work, but would need to be tested:
https://github.com/jgclark/vscode-todo-highlight/blob/6b10ef6d5f96af9ce5fd1bf9019ad8c1f6531daa/package.json#L135
"regex": {
+   "type": "object",
-   "pattern": {
-       "type": "string",
-       "description": "The RegEx pattern to use for matching instead of the text value.REMEMBER to escape the backslash if there's any in your regexp (using \\\\ instead of single backslash)"
+   "properties": {
+       "pattern": {
+          "type": "string",
+          "description": "The RegEx pattern to use for matching instead of the text value.REMEMBER to escape the backslash if there's any in your regexp (using \\\\ instead of single backslash)"
+       }
    }
},

But since regex is defined by us, I would suggest to simplify it permanently, since a new object for a single parameter makes little sense. This would then simplify in settings.json as follows, but also needs some code adjustments:
"regex": {
-   "pattern": {
-       "type": "string",
-       "description": "The RegEx pattern to use for matching instead of the text value.REMEMBER to escape the backslash if there's any in your regexp (using \\\\ instead of single backslash)"
-    }
+   "type": "string",
+   "description": "The RegEx pattern to use for matching instead of the text value.REMEMBER to escape the backslash if there's any in your regexp (using \\\\ instead of single backslash)"
},

Thanks for the further analysis and suggestions, @alkatar21.
Completions: will try again with the additional completions (before, after, cursor). The links to the VSCode documentation was already in most of the descriptions.
Regex property: agreed that this could and should be simplified. The challenge is that it would be a breaking change for anyone who has used custom regexes. Do you have any suggestions about how to warn those users when they upgrade to this, apart from making the next version either 2.1.0 or 3.0.0?

@alkatar21 I have now uploaded a candidate v2.0.5 vscode-todo-highlight-2.0.5.vsix file to the top level of this repo for you to test out, to see if the new completions work right for you.

This looks good so far. But there are a few small bugs. If desired, I could do a PR with a suggestion for a few more tweaks and for #31 as well. If you build this for me, I would test it.

Please do, @alkatar21!

I think this is also completed now with #62. Or at least enough to close it for now.


BackendClient.sendCommand method's rejection callback is not invoked

The BackendClient.sendCommand() currently provides the functionality of sending commands with an acknowledgment of a successful delivery and errors occurrence:

The parameterless successListener  is called if no transport errors occurred and the command message meets the validation requirements.
The errorCallback is called on transport errors, command message validation errors and server runtime errors.

The rejectionCallback that can be passed to sendCommand as a parameter is not invoked currently though.
This issue is to complete/fix the BackendClient.sendCommand() method's functionality so that a rejection callback works as designed.

@dmitrykuzmin please have a look. I think this issue is either obsolete or done.

The ability to pass this callback is still present in the new Client API.
In theory, it can be invoked - when the client app implements a custom filter which rejects the command not with Error but with a RejectionMessage. But I don't really know if it's a valid use case. Standard Spine filters never do that.
This issue, I guess, was originally about callback not being invoked after command leads to a rejection. As we can now observe the events/rejections produced by the command, it's better, in my opinion, to drop the support for this callback altogether.

@dmitrykuzmin let's schedule the removal of this callback and stick with the observation only.


R&D: RSS Feeds

Wordpress includes RSS feeds by default (add /feed to taxonomy URLs), however the items don't include some core RSS elements, like an audio enclosure, and aren't customizable.
This is a ticket to see if we should manage RSS feeds through Wordpress, or is this a good opportunity to consider what decoupled RSS feeds look like (maybe a Feeder-like approach)?

Install this pluggin for MSN: https://www.msn.com/en-us/creator/help/docs/User Guide/Content Management/WordPress.html

This ticket is about ensuring we have all the fields we need in WPs default feed functionality. Likely using hooks:

[ ] audio enclosure
<enclosure url="https://dts.podtrac.com/redirect.mp3/dovetail.prxu.org/_/300/b9f8d87a-1cea-4e6c-935b-1e27f5ead21e/2023_0809_09.mp3" length="2623537" type="audio/mpeg" />

[ ] featured image + caption/credit

 <media:text type="html">
Schoolchildren, most of them first graders, take part in a Russian national flag-raising ceremony marking the start of classes at a school as part of the traditional opening of the school year known as "Day of Knowledge" in Nakhabino, 18 miles west of Moscow, Sept. 1, 2022.
</media:text>
</media:content>```

Closing as a wontfix


Add context throughout graphql

It would be useful to have a context that was maintained through the graphql library so when resolving fields we can change what we want to return based on the context of the request.
See https://blog.golang.org/context for use cases.

I like the concept you're going after. But I don't agree with using a context. I think it would better if the request were attached to the GQLFRParams struct then one could implement whatever form of context they wanted. Such as loading session data from a database based on a session cookie or something.
Essentially what I"m getting at is that I think the use case of this change is far too small to suit a general purpose library, where as providing the `http.Request

The only issue I can see with that is if there were several resolve functions that needed to be run to return a request, wouldn't each of them need to independently lookup the session data from the database (sure there could be a caching layer to make it that efficient but that is just one use-case).
Having a context would allow you to store and share any state between all functions needed to resolve an http request. Context also has the other benefits such as being able to manage a request deadline and kill slow resolve functions which you couldn't do by just passing the http_request round.
The context could be put on GQLFRParams instead and that would be a more transparent change, passing it as a first argument is just a convention that google adopted and mentioned in the blog article, so I applied it here.

+1. Love to have this. Needed for GAE apps where all the operations are request bounded.

Hi guys,
@tallstreet Thanks for the PR! Really appreciate you putting your time to contribute to this project.
I agree that having a per-request context would be really useful, so the question now is how do we allow user to store context for them to use.
Currently,  GraphQLFieldResolveFn, GraphQLResolveInfo and GQLFRParams are defined as the following
type GQLFRParams struct {
	Source interface{}
	Args   map[string]interface{}
	Info   GraphQLResolveInfo
	Schema GraphQLSchema
}
type GraphQLFieldResolveFn func(p GQLFRParams) interface{}
type GraphQLResolveInfo struct {
	FieldName      string
	FieldASTs      []*ast.Field
	ReturnType     GraphQLOutputType
	ParentType     GraphQLCompositeType
	Schema         GraphQLSchema
	Fragments      map[string]ast.Definition
	RootValue      interface{}
	Operation      ast.Definition
	VariableValues map[string]interface{}
}

So right now we have the following possibilities:

Proposal 1: Add context to GraphQLFieldResolveFn args
As proposed by @tallstreet. This conforms with convention set by google as mentioned.

Proposal 2: Add context to GQLFRParams struct
As proposed by @bbuck.

May I proposed that we look into using root params to store context?

Proposal 3: Use root to store context

This was brought up by an issue in https://github.com/graphql/graphql-js/issues/56 and it seems that it was designed for this particular use-case.
The issue for graphql-go here though is that there is lack of documentation for this and unclear/inconsistent API in passing root value.

package gql
type GraphqlParams struct {
	...
	RootObject     map[string]interface{}
}

package executor
type ExecuteParams struct {
	...
	Root          interface{}
}

package types
type GraphQLResolveInfo struct {
	...
	RootValue      interface{}
}

One benefit is that it does not force user to use a particular context library.
What you guys think?
/cc @chris-ramon

It indeed work now, but involves unnecessary casting.
at the handler
	ctx, err := NewContext(r)
	if err != nil {
		panic(err) //TODO
	}

	// execute graphql query
	resultChannel := make(chan *types.GraphQLResult)
	params := graphql.GraphqlParams{
		Schema:         *h.Schema,
		RequestString:  opts.Query,
		RootObject:     map[string]interface{}{"ctx": ctx},
		VariableValues: opts.Variables,
		OperationName:  opts.OperationName,
	}
	go graphql.Graphql(params, resultChannel)
	result := <-resultChannel

and in the field config
Resolve: func(p gt.GQLFRParams) interface{} {
			rv := p.Info.RootValue.(map[string]interface{})
			ctx := rv["ctx"].(context.Context)
...
}

like @sogko  suggested, the API should be consistent and should retain the name and the type  map[string]interface{} throughout. This will at least avoid the need for rv := p.Info.RootValue.(map[string]interface{}) casting.

My original comments were uneducated. After I remarked here I went looking for how graphql-js handled sessions (for authentication purposes) and from there attempted to use the RootValue piece as demonstrated for graphql-js but with little success (mostly probably my own fault but I haven't had a significant amount of time to look at it again recently).
So I'm totally on board with @sogko's suggestion of doing it through the RootValue and I think I agree with @bsr203, if I understand his post correctly. Keeping that as a general purpose map[string]interface{} opens it up to any implementation chosen by consumers - not just Context, or Request, etc...

I was just going to post an issue on the inconsistent API passing root value,
In the Executor params you specify Root as an interface{} here https://github.com/chris-ramon/graphql-go/blob/master/executor/executor.go#L15
But in the GraphqlParams you specify it as a map[string]interface{} here https://github.com/chris-ramon/graphql-go/blob/master/graphql.go#L15
Maybe the RootObject should be an interface because anyway we are going to attach structs to it like session data or some other context which we will be typecasting to anyway.

Any update on this one?

I think it would be great to see this. context.Conext is quickly becoming the standard for controlling goroutine cancellation and passing data down a chain of handlers. It's easy to use and implement :)
I built GitHub.com/pressly/chi which shows you those benefits as an http service. You can picture how the http endpoint to graphql would pass it's context to graphql for timing out, passing some state by composition, graceful shutdowns, or invoking a cancellation of a running goroutine.
Please :)

On Nov 24, 2015, at 2:58 AM, Francis Chuang<EMAIL_ADDRESS>wrote:
Any update on this one?
—
Reply to this email directly or view it on GitHub.

I think having this and Resolve returns an error an error in addition to the response will improve the API better. see the dicussion at https://github.com/graphql-go/graphql/issues/44

@bsr203 I saw that issue too. I agree an error should be returned instead of panic`ing.

Well, I totally missed this PR and went off and did the same thing.  Now that I'm all caught up, my 2 cents:

We should use context.Context directly instead of providing a generic map.  The context.Context provides both an arbitrary metadata mechanism and a goroutine cancellation/management mechanism that is quickly becoming the standard.  We will almost certainly want to use the goroutine mechanisms in the future.  If we also provide a generic map, we will have redundant mechanisms for arbitrary metadata.  Boo.
Root appears to be an appropriate place to put this, but should be renamed to 'Context' or something to be clear that it's request-scoped, not global.  I would normally expect Root* to be a single entity shared amongst all in-flight request handlers, which is explicitly NOT what the context is.

(minor side note:  humorously, of the three possible locations to insert a Context (func signature, Params, or Info), I happened to pick the the third one that nobody else did.  d'oh)

closing this one in favor of #98 - thanks a lot for the feedback :+1:


fix(headers): Fix overflow with empty cookies

fixes: https://github.com/hyperium/hyper/issues/374

Thanks!


Update F1 keyword

Since timestamp is a deprecated name, I think the F1 keyword should reflect this.

@MikeRayMSFT
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Infinite loops/recursion are optimised incorrectly

I accidentally coded a recursion which then results in a segmentation fault. The difficulty is not so much that it crashes, but that there is very little feedback as to why it crashed. In my case, since I did this completely inadvertently (some over enthusiastic copy-paste before I reworked the code), I wasn't expecting to find a recursion. Once I found it, it was obvious.
So, my question is really one of is there any way for the compiler detect and warn about the problem, or the run-time to provide better feedback rather than simply a segmentation fault.
The following code triggers a segmentation fault.
actor Main

        new create(env: Env) =>
                recursion()

        fun recursion() =>
                recursion()

When run this results in generally results in the following output under Linux:
$ ./recursion
Segmentation fault (core dumped)

And on some occasions Linux responds with the following slightly more helpful response:
$ ./recursion
*** stack smashing detected ***: ./recursion terminated
Aborted (core dumped)

Admittedly, this is no worse than 'C' so maybe I'm just being hopeful:
void r() {
	r();
}

int main() {
	r();
}

$ gcc r.c -o r
$ ./r
Segmentation fault (core dumped)

Where as Java would at least provide a StackOverflowError:
public class Recursion {

    public static void main(String[] args) {
	    r();
    }

    private static void r() {
	    r();
    }

}

$ javac Recursion.java
$ java Recursion
Exception in thread "main" java.lang.StackOverflowError
	at Recursion.r(Recursion.java:8)
        ...
	at Recursion.r(Recursion.java:8)

This is a hard problem, and I don't think there is an ideal solution.

is there any way for the compiler detect and warn about the problem

It is possible, but there is no general solution. The basic idea is to look for cycles in the program's Control Flow Graph (CFG, the compiler's view of the "atomic" blocks of code in the program, like a branch of a conditional). Trivial cases like your example can be solved with relative ease but the general case is equivalent to the halting problem, which is undecidable (with some subtleties on actual computers but that doesn't change anything for us).
LLVM is able to do some limited CFG analysis for infinite recursion (or infinite loop, which are the same problem), often for optimisation purposes. The current implementation can cause surprising and even undesirable behaviour. For example, with optimisations enabled, your code is compiled down to this:
; Function Attrs: norecurse nounwind readnone
define fastcc void @Main_tag_create_oo(%Main* nocapture dereferenceable(264), %Env* noalias nocapture readonly dereferenceable(64)) local_unnamed_addr #5 {
  ret void
}

The recursion was completely eliminated and if you run the program, it will simply exit immediately. This won't cause much trouble but some cases are much more concerning. For example:
actor Main
  new create(env: Env) =>
    foo()

  fun foo(): U32 =>
    foo()

The Main.foo method is compiled down to:
; Function Attrs: nounwind readnone
define fastcc i32 @Main_ref_foo_I(%Main* nocapture readnone dereferenceable(264)) #0 {
  ret i32 undef
}

undef is LLVM's language for a garbage value that could be anything.
These problems aren't new in LLVM land, both Rust and Swift (and probably many others) have been (and still are) subject to them.
The undef problem and other similar ones definitely are cases that we should strive to eliminate. The best approach that I can see would be to do our own CFG analysis before handling things to LLVM. The hard part would be to ensure we're covering every case that LLVM would screw up, and I don't see a solution for that.

is there any way for [...] the run-time to provide better feedback rather than simply a segmentation fault

There are various way to do that based on the platform. There is libsigsegv on Linux, structured exceptions on Windows, and probably something on OSX that I don't know of. I've not dug into it much further but I think it would be possible to integrate these systems into the Pony runtime, assuming that a stack overflow always causes a segmentation fault or a structured exception.

Right that makes sense with regard to the compile time checks causing more trouble than they might solve and therefore probably not being appropriate.
However, taking a quick look at libsigsegv, it does actually seem like a viable solution for providing better feedback - it also seems to support OSX. It looks like it would introduce essentially no extra overhead into the runtime and the binary footprint change is only around 4K apparently (for static linking). However, skimming over the docs it was not immediately clear how easy it is to introduce in a heavily multithreaded application.
Also, I assume that if one were to try provide more feedback than simply "stack overflow" then one would need to hook into internal Pony bookkeeping in order to find the actor that triggered the overflow, and possibly the method.
All in all, probably not a high priority, but possibly still a nice-to-have.

Support for tail-call elimination would be nice. Having yield or call/cc for coroutines is also nice. I'm not sure Pony needs either as while, for & repeat would be used instead of recursion and an actor be would be used whenever you need to trampoline.

@sgebbie I do think that we'll need some compile-time stuff to solve some of the problems, particularly the undef stuff and the "semantics" of crashing (more on that below).
@agarman These are all very interesting subjects, but let's keep this issue on topic (the problems arising from infinite recursion). If you'd like to discuss an idea about the language, I'd suggest the development mailing list. Also, note that Pony already supports tail-cail elimination through LLVM's optimisations (and the crux of the problem here is that these optimisations aren't modeling infinite recursion as we'd like them to).

The issue with the optimisation here is the absence of side-effects. That is, LLVM transforms any infinite recursion (or infinite loop) that doesn't contain side-effects into something that "doesn't happen". We can exploit that behaviour by making the code generator add no-op side-effects (an equivalent to a Pony DoNotOptimise.observe() call) to infinitely recursive functions.
Another issue here is that other optimisations can transform a seemingly halting construct into an infinite one. The naive answer to that would be to add our no-op side-effect to every function and to every loop but that would simply kill optimisation, even in halting cases (example in C++ with a loop). We could add a custom IR transformation pass running at key points between LLVM's passes and adding side-effects at the correct places. I'm not sure where these key points would be, we'd have to investigate.
Also, this seems very likely to change between different versions of LLVM. Because of that and other issues with optimisation changes across various versions of LLVM, maybe the right thing to do would be to support only one version of LLVM at a time and upgrade only when we have a plan to adapt our custom optimisation stuff. I'll give some more thoughts to that idea and probably open an issue for discussion at some point.
Also, I think there is an underlying semantic issue with crashes related to memory exhaustion (whether it is exhaustion of the heap due to too many allocations or exhaustion of the stack due to too much recursion) and crashes in general. My biggest problem is with the "no crashes" claim, which is very good from a marketing standpoint but isn't accurate.
First, we aren't preventing memory exhaustion crashes and I don't think we realistically can. Because of that, I think memory exhaustion crashes should be treated as a separate category of crashes. There also is a problem with the semantics of an overflowing collection that we should discuss at some point.
Second, there are cases where we want to do something that could crash in order to save a runtime check (e.g. /~ (unsafe division), which doesn't prevent division-by-zero crashes), and we don't want to do that thing in C for some reason (the most compelling one being that Pony offers better optimisations in some cases (e.g. alias analysis)). In these cases the imprecise "no crashes" claim is a problem.
A possible reformulation of the claim could be "no non-memory exhaustion crashes by default". What I mean by "by default" is that the user should intentionally go out of their way and badly use a particular feature documented as causing crashes if used outside of its contract in order to cause a crash. This kind of feature should be guarded either via object capabilities or the --safe compiler flag. I think it should also have a convoluted syntax in order to discourage the user from using it unless they really need to. By this logic, the unsafe arithmetic sugar (op~) should be removed and unsafe operations should be guarded in some way. This ties into another idea I've been exploring for some time, which is compiler intrinsics exposed to the user with FFI-like syntax and guarded with --safe.
The last thing to consider is the semantics of crashes with regards to undefined results and the trust boundary (which we discussed a while back.) That is, which crashes should be considered deterministic "side-effects" of the program and which should be left as possible results of violating the trust boundary (i.e. in undefined behaviour land). Ideally, every crash should be deterministic but that's not possible in every case. An unsafe division crash could be deterministic (and that solves the problem in the undefined results definition about hardware traps), but if we were to give direct access to Pointer manipulation to users, crashes from that would have to be results of undefined behaviour and trust bounday violation. To sum it up, the various categories of nasty stuff from unsafe operations could look like this:

Undefined result: a garbage value that should be stable (i.e. not magically change between evaluations). There are some complications here, see this for example
Deterministic crash: A crash that should always happen regardless of the underlying implementation (i.e. by resulting from a scenario that the specification defines as provoking abnormal program termination)
Trust boundary violation: Anything can happen

And then we'd have memory exhaustion crashes aside of that. Infinite recursion would be defined as possibly causing a memory exhaustion crash (possibly because of tail-call elimination).

This is blocked.

This has been fixed in LLVM 12. Compilling the original code should now produce an infinite loop. Compiling in debug mode might still throw "bus error" when run.

When we upgrade to LLVM 12, we should include a CHANGELOG entry for closing this as part of that PR.
@ergl @jemc @kulibali

Note: #2592 can be reverted when we upgrade to LLVM 12


AUI-1818

Hey @zenorocha,
Attached is an update for http://issues.liferay.com/browse/AUI-1818.
Please let me know if you have any questions.
Thanks!

Just started reviewing :) :octocat: Sent from GH.

Merged into liferay/alloy-ui: https://github.com/liferay/alloy-ui/commits/2.0.x


NIFI-10530 MiNiFi: Add option to compress c2 requests

Summary
NIFI-10530
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[x] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[x] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[x] Pull Request based on current revision of the main branch
[x] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[x] Build completed using mvn clean install -P contrib-check

[x] JDK 8
[ ] JDK 11
[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Could you add a few words about this change to the minifi-docs?


Fix documentation after setting plugin as module

This Pr should fix the issue related to the documentation where the chart instances are not available because the chart.js elements are not registered.
The issue sounds to be related to vuepress-theme-chartjs and how imports are managed.
Not clear to me why (apologize) but adding the import names where missing, the app built by webpack/vue seems to have the registration and is importing everything as it should.

@kurkle @LeeLenaleee let me know what you think. Not sure why this update should solve the issue but weirdly the vue app JS is not built correctly if we omit the names of the imports.

@kurkle @LeeLenaleee I didn't relate the PR to the issue because I would like to see how it works on GHP before to close the issue.

@kurkle @LeeLenaleee I can confirm you that the development version on doc (master) is now rendering the charts.... The problem is that version 3.0.0 is broken :(
Let me know if you think we can fix in same way, otherwise we could release version 3.0.1.


Volume gets set to zero after unlocking the session on GNOME

My session locks automatically after 10 minutes, and I noticed that after unlocking it, mpd always get muted.
How to reproduce (tested on GNOME 3.18.1):

Leave any song playing on mpd
Hit Super+L to lock the session
Type your password and unlock the session

After that, mpd-mpris will set mpd's volume to zero:
$ journalctl -b
[...]
nov 16 18:28:08 arch gdm-password][11530]: gkr-pam: unlocked login keyring
nov 16 18:28:10 arch mpd-mpris[4020]: 2020/11/16 18:28:10 Shuffle changed to true
nov 16 18:28:10 arch mpd-mpris[4020]: 2020/11/16 18:28:10 Volume changed to 56
nov 16 18:28:10 arch mpd-mpris[4020]: 2020/11/16 18:28:10 Shuffle changed to false
nov 16 18:28:10 arch mpd-mpris[4020]: 2020/11/16 18:28:10 LoopStatus changed to Track
nov 16 18:28:10 arch mpd-mpris[4020]: 2020/11/16 18:28:10 LoopStatus changed to Playlist
nov 16 18:28:10 arch mpd-mpris[4020]: 2020/11/16 18:28:10 Volume changed to 0
[...]

Very interesting. Does it happen on other MPRIS-supported players? (try Rhythmbox for example)

Does it happen on other MPRIS-supported players

Nope...
FWIW, I was using mpDris2 for a long time and this doesn't happen there either. I gave up on it for other reasons though and now I'm giving mpd-mpris a try. :P

That log looks very chaotic! I'll take a look at GNOME to see if I can reproduce

Thanks! There's this other odd behavior with playback flags too, I think. But I'm not sure if it's somewhat intentional, so please let me know if you want me to open a new issue:
Basically, I mostly use ncmpcpp to control mpd, and I don't like to leave any of these playback flags enabled:

However, if I keep restarting the mpd-mpris service, those flags seem to randomly enable/disable themselves. I recorded a video of this behavior as well, just in case:
https://streamable.com/ndrrjq

Sorry, I could not reproduce it either on GNOME or with ncmpcpp... I really wonder what's going on there. Maybe a player add-on for GNOME? Does it happen on other desktop environments?

Maybe a player add-on for GNOME?

Sh*t, I should've tested with all my extensions disabled before opening a new issue. I do indeed use this extension called Mpris indicator button. After disabling it, mpv-mpris doesn't mute mpd after unlocking the session.
I wonder why this doesn't happen with mpDris2 though. :(
Regardless, as this doesn't seem to be mpd-mpris' fault, let me close this one. Sorry!

@guihkx, if you ever wanted to open an issue on their side (https://github.com/JasonLG1979/gnome-shell-extension-mpris-indicator-button), feel free to ping me. This might really be something related to mpd-mpris, and I would be willing to co-operate for a fix.

Will do it later, thanks!


2 ways binding on Input text

When angular set a value to input text from javascript since control scope change, the input text don't add the class 'valid'. The label should use too the 'active' class for proper operation.

Sorry, I simple don't get what it is you are trying to say should happen.

I have a problem, that i have given ng-model="data" to textbox and trying to access it from controllore as  var data1=$scope.data; an getting undefined, can anyone please suggest the solution.

Okay, for both of these of these I need some more info.
Make an example on a site like JSFiddle. You can use this as a starting point: http://jsfiddle.net/Lvc0u55v/4071/
@Saravana-Kumar-putta That goes for you too. And how does your issue have anything to do with the original issue?
(Your issue might be because you havn't initialized $scope.data in your controller)
This is closed until example is given.


[tests] [by Artem] Enabled PCH for testing builds that have COMGR enabled (removed WORKAROUND_ISSUE_898)

Reinstate #1478 after blocking issue has been fixed (#1481 and #1419)

@JehandadKhan  need another approval to merge

Gentle ping for @JehandadKhan @asroy @zjing14 wo need this to fix some existing issues. Urgency is high.

Update all ROCm 5.2 targeted PR/issues as blockers.
Closely monitoring CI, and this one should be able to land in timeframe.


Mouse button customization for node translate vs viewport translate not finished

As discussed in sirolf2009/fxgraph issue #7, the mouse buttons to use for node translation vs the button to use for viewport translation (panning) should be customizable.
However, the implementation is not yet complete, as setting both node translation and viewport pan to the same button causes behavior like so:
https://user-images.githubusercontent.com/17031438/129619546-38639f70-5a35-4d3c-83cb-c5558dde5794.mp4

I believe these sections are at least part of the issue:
https://github.com/ogallagher/fxgraph/blob/4643e37e5b4ff04c54180f2e20ce60073e57e9be/src/main/java/com/fxgraph/graph/NodeGestures.java#L54-L75
Above, in the case that the panning button and the node translation button are the same, then the panning has priority and the node is marked transparent.
https://github.com/ogallagher/fxgraph/blob/4643e37e5b4ff04c54180f2e20ce60073e57e9be/src/main/java/com/fxgraph/graph/NodeGestures.java#L77-L101
Above, when the drag is continued, the viewport pan no longer prevents a node from being dragged, even though NodeGestures.dragContext was never set.

I will attempt to solve this by prioritizing the node translation when the node is dragged, given that the node drag and viewport drag are set to trigger with the same mouse button.

The proposed changes fix cell vs viewport dragging, but cell resize handles also need to be fixed to consume the drag event.

I believe custom mouse buttons for different drag interactions is complete. See demo below:
https://user-images.githubusercontent.com/17031438/129625123-43162f6c-f95f-4d0b-8021-76072b0ae14e.mp4


Hope this tool into pypi

pysed is an awesome tool, hope this tool could into pypi, so user could install using pip;
but pypi has already had an same name tool, so I think your tool could be renamed to other name like: sed-python、sedy.......

Agree, I installed pysed but it was referring to https://pypi.org/project/pysed/ and this is not usable within python code


safari: dont call chrome legacy stats

do not attempt to call chrome style legacy stats in Safari

released as 1.0.2


Project Level Datasets

Epic to track issues related to project level datasets

#1382
#1383
#1384
#1385
#1386
#1387
#1388
#1389
#1390


[DESIGN] Add clickable things to reader pages

To decrease bounce rate and increase pages per session from organic search (the majority of our organic search traffic goes to reader pages)
A few ideas:

add featured entries (ie: to right column sidebar, or as a horizontal banner popup from bottom of screen) so there's more to click on
add medium posts to page
add a "like what you see? search for more entries like this" popup with a search bar / highlight the search bar with a tool tip
automatically generate "related" entries (ie with matching search filters??) and serve them up on the page as "more entries like this one" or similar (right side bar or popup)
add a subscribe to our newsletter popup
add a popup that shows people they can edit the entry - highlight the edit button

months ago, alanna and I agreed that we'll use the quick submit fields as search filters for related content, take the top 3 most recently edited and most complete and display them on the right as cards with a header. mobile may be a popup tooltip style thing or a button for "related content" that could open a modal.

MIT tech review site - Related content (probably hard coded, not auto generated, but still) in article body text on mobile. Will check how they do desktop too.

Mockup draft

Could add a search element

Clickable things mockups here: https://drive.google.com/drive/folders/128iQiRgxMOP_F_jhJ1BXFzv0LSURvjwt?usp=sharing

If we collapsed the case data into an accordion on desktop (the same way we do on mobile) we would have more real estate for related / popular content.
mit tech review places related content throughout the narrative, while popular content is listed on the right sidebar:


Configure logcat metadata [Feature Request]

We use the rollbar-java SDK in our Android app. One of the features that we find useful is the ability to attach a device's logcat output to crashes. However, the number of lines logged is capped at 100. In many cases the 100 lines preceeding the crash are consumed with stack traces and uninformative data.
We would like to have the choice to upload more than the current default of 100 lines.
The relevant class in the SDK appears to be com.rollbar.android.provider.ClientProvider.
private ArrayList<String> getLogcatInfo() {
        ArrayList<String> log = null;
        int pid = android.os.Process.myPid();
        try {
            Process process = Runtime.getRuntime().exec("logcat -d");
            InputStreamReader isr = new InputStreamReader(process.getInputStream());
            BufferedReader br = new BufferedReader(isr, 8192);
            List<String> lines = new ArrayList<>();
            String line;
            while ((line = br.readLine()) != null) {
                if (line.contains(String.valueOf(pid))) {
                    lines.add(line);
                    if (lines.size() > MAX_LOGCAT_SIZE) {
                        lines.remove(0);
                    }
                }
            }
            log = new ArrayList<>(lines);
        } catch (IOException e) {
            Log.e(Rollbar.TAG, "Unable to collect logcat info.", e);
        }
        return log;
    }

Is it possible for us to increase MAX_LOGCAT_SIZE (and potentially the buffer) so that we can export more of the logcat output?

Before we make a change, this is possible without forking the library. You can use a ConfigProvider which can be passed to the Rollbar constructor. That provider can use your own custom client provider which can handle logcat however you want.
We can provide a configuration option to set the max logcat size at some point in the future. It might just increase the payload size which will eventually run up against the API payload limit if the number of logcat lines is too high.


Integration Test - Release - 2019/02/07 20:06:09

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

@PRMergerTest2 : Thanks for your contribution! The author, @v-caxian, has been notified to review your proposed change.


[PSA] Capping the bitwidth of PSA core types to 64

The bitwidth of PSA core types is currently unspecified. This is because different HW may have different port bitwidth etc. However, can we agree on capping this number to 64 so that we can safely use uint64 for the metadata fields in the API?

We can bring this up at the next PSA meeting to be sure, but I would be very surprised if any PSA implementation would voluntarily choose a width larger than 64 bits for any of the types defined in psa.p4 as 'bit'.  Having an explicit statement in the PSA that for types X, Y, Z, etc. that the P4 Runtime API only supports up to 64 bits for each of those types, thus an implementation would potentially be throwing away bits if they made it wider than that, seems reasonable.

Are you sure? What if you want to represent a copy of an ipv6 address as metadata? Don't you need 128 bits?

I think we are only targeting the so-called PSA_CORE_TYPES (https://github.com/p4lang/p4-spec/blob/master/p4-16/psa/psa.p4#L50) which are used for PSA metadata fields. This does not apply to user-defined metadata fields.
The PSA metadata fields obviously have a special status because they are a property of the architecture and are referred by name in the P4 Runtime API (e.g. the multicast group id). It is much easier to manipulate them in software if they fit in a 64-bit integer. All user-define fields (protocol or metadata) remain arbitrary bitstrings.

If that's the case, it seems reasonable.

@cc10512
Yes, this is only for the core types that appear in the standard input/output metadata. Specifically, we want the PRE P4Runtime to use uint64 for ports, clone session ids, class of service, multicast group ids and egress instance

Closing this issue, resolved by this PR: https://github.com/p4lang/p4-spec/pull/539


[0] Bring up a CentOS 7 test instance

https://github.com/Shippable/pm/issues/10194

Reopening. I need to another machine to test from scratch.

Added, closing this.


Renaming a library in the library list, doesn't add the renamed library to the list

I renamed the library tmpuitest2 to tmpuitest3, but we can see the iproj.json and the library list did not reflect this change.
https://github.com/IBM/vscode-ibmi-projectexplorer/assets/42983653/fdff8126-afe3-43fa-8f92-9dd4332ae3f7

Found in libraryListTest

LIkewise @SanjulaGanepola understands this limitation and plans to address it


Uncaught Please upgrade to react-redux v6, electron package build

The electron-boilerplate package build on mac fails with the above error. This is despite the below versions plus passing the context={ReactReduxContext} to the Provider and ConnectedRouter.
Any ideas why this would fail for an electron packaged build would be appreciated.
My dependencies are:
"connected-react-router": "6.5.2",
"core-js": "2",
"devtron": "^1.4.0",
"electron-debug": "^3.0.1",
"electron-log": "^3.0.8",
"electron-updater": "^4.1.2",
"history": "^4.9.0",
"react": "16.9.0",
"react-dom": "16.9.0",
"react-hot-loader": "^4.12.15",
"react-redux": "^7.1.1",
"react-router": "^5.1.2",
"react-router-dom": "^5.1.2",
"react-router-redux-dom-link": "^0.3.0",
"redux": "^4.0.4",
"redux-thunk": "^2.3.0",
"source-map-support": "^0.5.13"

yarn why is your friend! Downstream dependency brought in an older version of react-router which only caused an issue in a package build


[core] Adding Datadog tracing

Description
With that, we should be able to see our core logs inside traces starting from front or connectors on Datadog.
This will generate the Datadog trace and span ids for each HTTP request, and will re-use the one sent by front if they exists in the HTTP headers (this is automatically done in front by the library dd-trace, which is monkey patching the fetch() and axios libraries).
We can also create a span for tracing using the #[tracing::instrument] attribute.
If we want to have the full trace when core makes an HTTP call to front, we will need to use a middleware for reqwest.

Risk

Deploy Plan

After investigating, this would keep the logs finished processing request, latency=... but would remove the BEFORE and AFTER request logs, along with the request_span_id.
Since datadog seems to not expose the dd.trace_id field, it would be hard to correlate all logs of a given HTTP request outside of the trace view, and traces are sampled at different rates given the volume of the service sending them (eg: as of today, we only store 5% of the front traces).
Keeping the request_span_id would require to build our own datadog_tracing::init() function to have multiple tracing layers.
I am putting that PR on the side for now and I will try to find time for it in the next few days.


Update Glia Core SDK to 0.20.0

The audio permission has been fixed in the Glia Core SDK version 0.20.0. Fix consists of adding new queueForEngagement.
An additional change that has been made during these changes is related to Bintray closing its services.

Update [July 4, 2021]
Thanks for supporting Bintray! This service has now been sunset.

https://status.bintray.com/

@deniss-mc AAR file added: https://github.com/salemove/android-sdk-widgets/compare/a27372cd5fbfc29655174516012ff7ea88e9471e..f2d3855110c85ddab2681f5c76e6fe7850bc7b4e

I have tested it many times. But the engagement request does not reach the operator on the first attempt after a clean install of the app.

To be more specific. Engagement request is not sent to the operator if permissions have been not granted in advance. Issue reproducible only in the Widget SDK example app

So I have been investigating the issue and found out that for some reason even though the permissions are getting requested correctly from the Core SDK side. For some reason, once the permissions have been granted (or even declined) the Widget SDK Example app method onRequestPermissionsResult is not getting triggered.
I first tried to debug it but failed. As this fix is needed ASAP I have created fast and dirty implementation to handle the permissions directly from the Widget SDK CallACtivity.

!merge


Child that receives new props wont update if father wont update

hey!
do you still maintain the library?
please look at this sandbox:
https://codesandbox.io/s/43lzn1nr5x
looks like updating children without updating their father doesn't work.

Hi @vzaidman, this is how React (and this library) works.
see: https://github.com/NoamELB/shouldComponentUpdate-Children#our-solution (the bold parts)
AButton won't render, because you implemented the shouldComponentUpdate in it and only 'children' prop is changing. This means that ChildComponent won't render, as it only rendered inside AButton (line 24 in your sandbox example).
If you want AButton to be rendered when 'counter' prop is changing, you should explicitly do so: https://codesandbox.io/s/qln4rk5nnw (see line 61 for my addition).
ChildComponent has no shouldComponentUpdate implementation, therefore it will render every time  AButton is rendered.


Detect CyVerse maintenance windows

Or we can hard-code maintenance windows if they're regular enough (e.g., first Tues. of every month as they currently do), but probably better to detect automatically
Currently we just get stuck loading here

Added in 62b6038


Add a pending test for a modified member of a trait

The test shows that name hashing optimization is broken for members
defined in traits. The problem is that modification of a member of a trait
triggers change of a hash of trait's name.
The behavior covered by this test regressed in
40ebc825317ed29a2ab87be07246fcdcfc6d1e3d
The bug is tracked in #2436.

Review by @Duhemm

Can one of the admins verify this patch?

Shouldn't this test be located in source-dependencies rather than compiler-project?
Apart from that, LGTM

I put it into compiler-project to emphasize that this test doesn't check if dependencies are tracked correctly but whether invalidation is done correctly. However, many tests in source-dependencies test for invalidation too so probably makes sense to put everything in one place. I'll move it.

@gkossakowski Could you please update your branch? It looks like GitHub forces you to have an up-to-date branch when using required status check: https://github.com/blog/2051-protected-branches-and-required-status-checks

Do you mean you cannot merge my PR? I see the merge button here (I still have merge rights to sbt).

That's strange. Maybe it's because Travis has not finished running the build... I have a grayed out merge button.

@gkossakowski as an owner you can override the status check requirement.

Ok, in that case I'll just merge it.


Auto split messages when over char limit

Feature Request

Current behavior is that it silently fails
Feature: auto splits the message and sends it as many messages

I will be implementing this feature (if approved)

Sure, you can do it, as already mentioned on Discord.


Do not sort qubits by default in pauli_string to fix inconsistencies with pauli_string.gate

Fixes #4270
Note that the fix relies on the fact that python dicts maintain insertion order from python 3.6+ [link]

IIRC they changed it in 3.7 to be part of the standard

Yes, it's part of the standard from 3.7+ (see my original link) and hence I think it should be fine to rely on this?


Update to kickstart file, build using ks2rootfs

Make necessary update to kickstart file so that rootfs can be generated using AlmaLinux docker utility ks2rootfs. This will enable windows users can create and customize rootfs using docker.
This will also help for build automation

Building KS using KS2ROOT wia docker
docker run --rm --privileged -v "$PWD:/build:z" \
    -e BUILD_KICKSTART=rootfs/kickstart/almalinux-8-wsl.ks \
    -e BUILD_ROOTFS=almalinux-8-default-wsl.x86_64.tar.gz \
    -e BUILD_OUTDIR=work/default84 \
    almalinux/ks2rootfs

Output
Build output files will be in './work/default84' folder ...
Output directory ./work/default84 created successfully

ks2rootfs - Script input summary:

FLAGS
-----
FLAG_OUTOUT_PWD : false
FLAG_WRITE_META : true
FLAG_RETAIN_LOG : false

VARIABLES
---------
BUILD_WORK_DIR  : ./
BUILD_OUTDIR    : ./work/default84
BUILD_LOGDIR    : ./work/default84/logs
INPUT_KICKSTART : ./rootfs/kickstart/almalinux-8-wsl.ks
OUTPUT_ROOTFS   : ./work/default84/almalinux-8-default-wsl.x86_64.tar.gz

2021-07-16 11:45:01,579: livemedia-creator v28.14.58-1
2021-07-16 11:45:01,580: selinux is Disabled
2021-07-16 11:45:01,704: disk_img = /var/tmp/almalinux-8-default-wsl.x86_64.tar.gz
2021-07-16 11:45:01,704: Using disk size of 2MiB
2021-07-16 11:45:01,711: Running anaconda.
2021-07-16 11:45:05,769: Processing logs from ('<IP_ADDRESS>', 35394)
2021-07-16 11:45:05,836: Starting installer, one moment...
2021-07-16 11:45:05,837: terminal size detection failed, using default width
2021-07-16 11:45:05,837: anaconda <IP_ADDRESS>-1.el8.alma for Linux 8 (pre-release) started.
2021-07-16 11:45:05,837: 11:45:05 Not asking for VNC because of an automated install
2021-07-16 11:45:05,838: 11:45:05 Not asking for VNC because we don't have Xvnc
2021-07-16 11:45:19,697: Starting automated install.............
2021-07-16 11:45:19,698: ================================================================================
2021-07-16 11:45:19,698: ================================================================================
2021-07-16 11:45:19,698: Installation
2021-07-16 11:45:19,698:
2021-07-16 11:45:19,698: 1) [x] Language settings                 2) [x] Time settings
2021-07-16 11:45:19,699: (English (United States))                (UTC timezone)
2021-07-16 11:45:19,699: 3) [x] Installation source               4) [x] Software selection
2021-07-16 11:45:19,699: (https://repo.almalinux.org/alma         (Custom software selected)
2021-07-16 11:45:19,700: linux/8/BaseOS/x86_64/os/)
2021-07-16 11:45:19,700: 5) [ ] User creation
2021-07-16 11:45:19,700: (No user will be created)
2021-07-16 11:45:19,700:
2021-07-16 11:45:19,700: ================================================================================
2021-07-16 11:45:19,700: ================================================================================
2021-07-16 11:45:19,700: Progress
2021-07-16 11:45:19,700:
2021-07-16 11:45:19,700: Setting up the installation environment
2021-07-16 11:45:19,709: ..
2021-07-16 11:45:19,709: Configuring storage
2021-07-16 11:45:20,729: ...
2021-07-16 11:45:20,729: Running pre-installation scripts
2021-07-16 11:45:20,735: .
2021-07-16 11:45:20,736: Running pre-installation tasks
2021-07-16 11:48:22,876: ..
2021-07-16 11:48:22,876: Installing.
2021-07-16 11:48:22,876: Starting package installation process
2021-07-16 11:48:22,877:
2021-07-16 11:48:22,877: The installation was stopped due to an error which occurred while running in non-interactive cmdline mode. Since there cannot be any questions in cmdline mode, edit your kickstart file and retry installation.
2021-07-16 11:48:22,879: The exact error message is:
2021-07-16 11:48:22,880:
2021-07-16 11:48:22,880: Non interactive installation failed:
2021-07-16 11:48:22,880: Problem: package iputils-20180629-7.el8.x86_64 requires systemd, but none of the providers can be installed
2021-07-16 11:48:22,880: - package systemd-239-45.el8.i686 requires libip4tc.so.2, but none of the providers can be installed
2021-07-16 11:48:22,880: - package systemd-239-45.el8_4.1.i686 requires libip4tc.so.2, but none of the providers can be installed
2021-07-16 11:48:22,880: - package systemd-239-45.el8.x86_64 requires libip4tc.so.2()(64bit), but none of the providers can be installed
2021-07-16 11:48:22,880: - package systemd-239-45.el8_4.1.x86_64 requires libip4tc.so.2()(64bit), but none of the providers can be installed
2021-07-16 11:48:22,880: - package iptables-libs-1.8.4-17.el8.i686 requires libpcap.so.1, but none of the providers can be installed
2021-07-16 11:48:22,881: - package iptables-libs-1.8.4-17.el8.x86_64 requires libpcap.so.1()(64bit), but none of the providers can be installed
2021-07-16 11:48:22,881: - package libpcap-14:1.9.1-5.el8.i686 requires libibverbs.so.1, but none of the providers can be installed
2021-07-16 11:48:22,881: - package libpcap-14:1.9.1-5.el8.i686 requires libibverbs.so.1(IBVERBS_1.0), but none of the providers can be installed
2021-07-16 11:48:22,881: - package libpcap-14:1.9.1-5.el8.i686 requires libibverbs.so.1(IBVERBS_1.1), but none of the providers can be installed
2021-07-16 11:48:22,881: - package libpcap-14:1.9.1-5.el8.x86_64 requires libibverbs.so.1()(64bit), but none of the providers can be installed
2021-07-16 11:48:22,881: - package libpcap-14:1.9.1-5.el8.x86_64 requires libibverbs.so.1(IBVERBS_1.0)(64bit), but none of the providers can be installed
2021-07-16 11:48:22,881: - package libpcap-14:1.9.1-5.el8.x86_64 requires libibverbs.so.1(IBVERBS_1.1)(64bit), but none of the providers can be installed
2021-07-16 11:48:22,881: - package libibverbs-32.0-4.el8.i686 requires rdma-core(x86-32) = 32.0-4.el8, but none of the providers can be installed
2021-07-16 11:48:22,882: - package libibverbs-32.0-4.el8.x86_64 requires rdma-core(x86-64) = 32.0-4.el8, but none of the providers can be installed
2021-07-16 11:48:22,883: - package rdma-core-32.0-4.el8.i686 requires pciutils, but none of the providers can be installed
2021-07-16 11:48:22,883: - package rdma-core-32.0-4.el8.x86_64 requires pciutils, but none of the providers can be installed
2021-07-16 11:48:22,883: - conflicting requests
2021-07-16 11:48:22,883: - package pciutils-3.7.0-1.el8.x86_64 is filtered out by exclude filtering.
2021-07-16 11:48:22,883:
2021-07-16 11:48:22,883: The installer will now terminate.
2021-07-16 11:48:23,009: Running anaconda failed: process '['anaconda', '--kickstart', '/build/rootfs/kickstart/almalinux-8-wsl.ks', '--cmdline', '--loglevel', 'debug', '--product', 'Kickstart to Rootfs', '--dirinstall', '--remotelog', '<IP_ADDRESS>:60707']' exited with status 1
2021-07-16 11:48:23,010: Shutting down log processing
2021-07-16 11:48:23,025: Install failed: novirt_install failed
2021-07-16 11:48:23,025: ERROR: Image creation failed: novirt_install failed
2021-07-16 11:48:23,026: Image creation failed: novirt_install failed


Investigate possibilities to provide API for Commits browsing

[ ] Check for possibilities to host API on desktop client
[ ] Investigate possibility to use .NET Core (check advantages and disadvantages)

No need for those investigations.


Add a CA Chain certificate for gitea for SSL

Gitea version (or commit ref): Gitea version 1.4.3 built with: bindata, sqlite
Git version: 1.8.4
Operating system: CentOS 6
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[X] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[X] Not relevant

Log gist:

Description
I am trying to enable SSL on gitea with a certificate that requires a CA Chain certificate.  I found #2744 that talks about a CA for webhooks, and thought that might help.  I tried adding that certificate to the ca-trust on Cent 6 but even if I do that and restart gitea, I still cannot verify the certificate remotely using: openssl s_client -connect my.host.domain:3000 -showcerts </dev/null
This setup works with apache, but I do not understand how to add the CA Chain certificate to gitea.

FWIW, I was able to "work around" the issue since I had an apache instance that worked with SSL.
I added:
<Location /git/>
                ProxyPass http://localhost:3000/
                ProxyPassReverse http://localhost:3000/
                Order deny,allow
                Deny from all
                Allow from all
 </Location>

To my port 443 configuration in apache and that let's me get around this issue.
However, it would still be nice to know how to get gitea to use a CA Chain cert correctly, since I may one day move this to a server without apache and it would be nice to not have to rely on the Proxy stuff.
I thought the apache stuff might help someone else one day though, just in case.

@lafriks would kind/question be more appropriate for the forum? Consolidating support requests in a central location ought to help in the planned dogfooding effort by severing ties with GH.

@jhabdas If someone has a question like this it usually means that the existing documentation is insufficient to answer their question. Some questions are appropriate for discourse, however some are needed as issues so that documentation can be updated.

@uberlinuxguy
you'll need to combine the cert with the full chain, and use the settings such as:
CERT_FILE        = fullchain.pem
KEY_FILE         = privkey.pem

Closing as answered, reopen if needed


Uncaught TypeError: Cannot read property 'define' of undefined on Azure Web App.

I use the last version of select2 4.0 on a mvc project this work all ok in debug and release mode with BundleTable.EnableOptimizations = true; Select2 is insert in AngularJs 1.4.
When i publish on Azzure Web App give this
Uncaught TypeError: Cannot read property 'define' of undefined
5angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:111TypeError: element.select2 is not a function
at link (http://.azurewebsites.net/Scripts/app.js:240:25)
at $ (http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:76:278)
at M (http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:65:341)
at g (http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:58:300)
at g (http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:58:323)
at g (http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:58:323)
at http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:57:330
at http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:59:283
at m (http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:63:479)
at http://.azurewebsites.net/bundles/angular?v=IbVO5agGI_WWrgrI2VAScz3MiGFhOC78m6iBUC9GUDo1:281:428

Why? What missing?

This appears to be more of a usage question than a bug report or common feature request.  As we continue to keep the Select2 issue tracker geared towards these two areas, bug reports and common feature requests, we are redirecting usage questions to other communities such as the mailing list, IRC, or Stack Overflow.

same problem!

@farshadsharifjob please post it


[WIP] Small multiples - ready for initial review

fixes #519
Small multiples, makes pretty charts :-)

The small multiples component is actually quite similar to cartesian chart, it shares similar axis orientation logic, margins etc ...
The code is at a point where it would be good to get a bit of feedback. Here is my current TODO list:

[x] Try out using flexbox layout for rendering the multiples - this might give a more flexible label placement, conclusion: this was too complex, requiring nested elements (i.e. column containers), with a nested datajoin for the layout and nasty logic to determine which series to plot in each multiple container
[x] Modify stack / grouped series types. Currently these expect an array of arrays, where the nested arrays have a key property. Small multiples is more flexible, having key and values accessors. This is much more compatible with the way d3.nest works.
[ ] The logic here is similar to our spread component, however rather than create a series for each column, it creates a series from each row. Perhaps spread should have an orient property and include this logic?
[ ] Add small multiples to website and update stack / group (if required)
[ ] Check the website for breaking changes!

On another note, does the way the domain line within the axis renders end 'caps' bother anyone else?

I've updated stacked / grouped to use accommodate the same data format. One side effect is that the extent function is now more complex:
var yDomain = fc.util.extent(series.map(function(d) { return d.values; }), function(d) { return 0; }, 'y');

The extent function accommodates arrays of arrays, but not arrays where the nested array is within an object property (in this case values. Perhaps extent and spread could collaborate somehow?
I've also standardised the CSS for charts, where each chart has the chart class and a more specific class, e.g. chart multiples, chart cartesian

Not had a chance to look over the rest but this definitely annoys me. Feels
like there should be a d3 issue...
On Thu, 22 Oct 2015 21:47 Colin Eberhardt<EMAIL_ADDRESS>wrote:

On another note, does the way the domain line within the axis renders end
'caps' bother anyone else?
[image: screen shot 2015-10-22 at 21 46 05]
https://cloud.githubusercontent.com/assets/1098110/10677799/6c506bb2-7906-11e5-9e44-beee9aa67054.png
—
Reply to this email directly or view it on GitHub
https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150351570.

http://stackoverflow.com/questions/13669239/remove-end-ticks-from-d3-js-axis
On Fri, 23 Oct 2015 08:06 Chris Price<EMAIL_ADDRESS>wrote:

Not had a chance to look over the rest but this definitely annoys me.
Feels like there should be a d3 issue...
On Thu, 22 Oct 2015 21:47 Colin Eberhardt<EMAIL_ADDRESS>wrote:

On another note, does the way the domain line within the axis renders end
'caps' bother anyone else?
[image: screen shot 2015-10-22 at 21 46 05]
https://cloud.githubusercontent.com/assets/1098110/10677799/6c506bb2-7906-11e5-9e44-beee9aa67054.png
—
Reply to this email directly or view it on GitHub
https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150351570.

We have our own svg axis implementation, so could fix this one quite simply ...
axis.endCaps(false)
On Fri, Oct 23, 2015 at 8:07 a.m., ScottLogic/d3fc
<EMAIL_ADDRESS>wrote:
http://stackoverflow.com/questions/13669239/remove-end-ticks-from-d3-js-axis
[http://stackoverflow.com/questions/13669239/remove-end-ticks-from-d3-js-axis]
On Fri, 23 Oct 2015 08:06 Chris Price<EMAIL_ADDRESS>wrote:

Not had a chance to look over the rest but this definitely annoys me.
Feels like there should be a d3 issue...
On Thu, 22 Oct 2015 21:47 Colin Eberhardt<EMAIL_ADDRESS>wrote:

On another note, does the way the domain line within the axis renders end
'caps' bother anyone else?
[image: screen shot 2015-10-22 at 21 46 05]
<
https://cloud.githubusercontent.com/assets/1098110/10677799/6c506bb2-7906-11e5-9e44-beee9aa67054.png
[https://cloud.githubusercontent.com/assets/1098110/10677799/6c506bb2-7906-11e5-9e44-beee9aa67054.png] >
—
Reply to this email directly or view it on GitHub
< https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150351570
[https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150351570] >.

—
Reply to this email directly or view it on GitHub
[https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150494017] .[https://github.com/notifications/beacon/ABDBfjX18YcrtU1eMq50SPlOcCrDPhxEks5o-dRGgaJpZM4GUFPv.gif]

Ah, just looked at the implementation, it is already possible via outerTickSize.
I think it is just a problem of poor naming and choice of defaults.
On Fri, Oct 23, 2015 at 8:11 a.m<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
We have our own svg axis implementation, so could fix this one quite simply ...
axis.endCaps(false)
On Fri, Oct 23, 2015 at 8:07 a.m., ScottLogic/d3fc
<EMAIL_ADDRESS>wrote:
[http://stackoverflow.com/questions/13669239/remove-end-ticks-from-d3-js-axis] http://stackoverflow.com/questions/13669239/remove-end-ticks-from-d3-js-axis
[http://stackoverflow.com/questions/13669239/remove-end-ticks-from-d3-js-axis]
On Fri, 23 Oct 2015 08:06 Chris Price<EMAIL_ADDRESS>wrote:

Not had a chance to look over the rest but this definitely annoys me.
Feels like there should be a d3 issue...
On Thu, 22 Oct 2015 21:47 Colin Eberhardt<EMAIL_ADDRESS>wrote:

On another note, does the way the domain line within the axis renders end
'caps' bother anyone else?
[image: screen shot 2015-10-22 at 21 46 05]
<
[https://cloud.githubusercontent.com/assets/1098110/10677799/6c506bb2-7906-11e5-9e44-beee9aa67054.png]
https://cloud.githubusercontent.com/assets/1098110/10677799/6c506bb2-7906-11e5-9e44-beee9aa67054.png
[https://cloud.githubusercontent.com/assets/1098110/10677799/6c506bb2-7906-11e5-9e44-beee9aa67054.png] >
—
Reply to this email directly or view it on GitHub
< [https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150351570] https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150351570
[https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150351570] >.

—
Reply to this email directly or view it on GitHub
[https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150494017] .[https://github.com/notifications/beacon/ABDBfjX18YcrtU1eMq50SPlOcCrDPhxEks5o-dRGgaJpZM4GUFPv.gif]

Looks good, a few comments from creating my own example -

The default settings render an axis on the left but don't leave any padding for it -

The default settings also seem not to fill the vertical space very well (on closer inspection this looks like an off-by-one error in the positioning calculations) -

Thanks Chris, that's a good example too. I'll sort out those defaults.
Regarding axis end-ticks, I'm considering simply making ours zero by default. This way we would still match the standard D3 API, but have different opinions about what a suitable default is. What do you think?

Don't have a strong opinion either way
On Fri, 23 Oct 2015 13:11 Colin Eberhardt<EMAIL_ADDRESS>wrote:

Thanks Chris, that's a good example too. I'll sort out those defaults.
Regarding axis end-ticks, I'm considering simply making ours zero by
default. This way we would still match the standard D3 API, but have
different opinions about what a suitable default is. What do you think?
—
Reply to this email directly or view it on GitHub
https://github.com/ScottLogic/d3fc/pull/664#issuecomment-150556089.

@ScottLogic/d3fc all done and ready for review :-)

Looks great, seems that setting up the number of columns is really easy and usage is quite simple overall.

Thanks Bartosz - glad you like it.
On Mon, Oct 26, 2015 at 4:27 p.m., ScottLogic/d3fc
<EMAIL_ADDRESS>wrote:
Looks great, seems that setting up the number of columns is really easy and
usage is quite simple overall.
—
Reply to this email directly or view it on GitHub
[https://github.com/ScottLogic/d3fc/pull/664#issuecomment-151196773] .[https://github.com/notifications/beacon/ABDBfreSs2VgnlGfIkJ016dOClkJ2oZMks5o_kvVgaJpZM4GUFPv.gif]

Thanks for the feedback Chris and Bartosz, merging it in to avoid the need for yet more rebasing!


(Worker pool) Show number of successful tasks in progress bar

Attempts to address #173

Here are some sample outputs with various combinations of invoking the push command with/out --skip and with/out  | cat while one of the language files has a syntax error:
➜  tx push -taf

  # Getting info about resources

  kb_clitest.en_1_json - Done
  [##############################] (1 / 1)

  # Pushing translations

  kb_clitest.en_1_json [aln] - Done
  kb_clitest.en_1_json [de_AT] - Done
  kb_clitest.en_1_json [en_BD] - upload of resource 'o:tx_internal_gluon:p:kb_clitest:r:en_1_json', language 'l:en_BD' failed - parse_error: Expecting ':' delimiter: line 5 column 5 (char 90)
  kb_clitest.en_1_json [en_GR] - Done
  kb_clitest.en_1_json [es_PR] - Done
  kb_clitest.en_1_json [ig] - Done
  [################--------------] (5 / 9)

➜  tx push -taf --skip

  # Getting info about resources

  kb_clitest.en_1_json - Done
  [##############################] (1 / 1)

  # Pushing translations

  kb_clitest.en_1_json [aln] - Done
  kb_clitest.en_1_json [de_AT] - Done
  kb_clitest.en_1_json [en_BD] - upload of resource 'o:tx_internal_gluon:p:kb_clitest:r:en_1_json', language 'l:en_BD' failed - parse_error: Expecting ':' delimiter: line 5 column 5 (char 90)
  kb_clitest.en_1_json [en_GR] - Done
  kb_clitest.en_1_json [es_PR] - Done
  kb_clitest.en_1_json [ig] - Done
  kb_clitest.en_1_json [lfn] - Done
  kb_clitest.en_1_json [scn] - Done
  kb_clitest.en_1_json [ta_LK] - Done
  [##########################----] (8 / 9)

➜  tx push -taf | cat

  # Getting info about resources

  kb_clitest.en_1_json - Getting info
  kb_clitest.en_1_json - Getting stats
  kb_clitest.en_1_json - Fetching remote languages
  kb_clitest.en_1_json - Done
  Completed 1 / 1 tasks

  # Pushing translations

  kb_clitest.en_1_json [aln] - Uploading file
  kb_clitest.en_1_json [en_BD] - Uploading file
  kb_clitest.en_1_json [de_AT] - Uploading file
  kb_clitest.en_1_json [en_GR] - Uploading file
  kb_clitest.en_1_json [es_PR] - Uploading file
  kb_clitest.en_1_json [es_PR] - Done
  kb_clitest.en_1_json [ig] - Uploading file
  kb_clitest.en_1_json [en_BD] - upload of resource 'o:tx_internal_gluon:p:kb_clitest:r:en_1_json', language 'l:en_BD' failed - parse_error: Expecting ':' delimiter: line 5 column 5 (char 90)
  kb_clitest.en_1_json [en_GR] - Done
  kb_clitest.en_1_json [de_AT] - Done
  kb_clitest.en_1_json [ig] - Done
  kb_clitest.en_1_json [aln] - Done
  Completed 5 / 9 tasks

➜  tx push -taf --skip | cat

  # Getting info about resources

  kb_clitest.en_1_json - Getting info
  kb_clitest.en_1_json - Getting stats
  kb_clitest.en_1_json - Fetching remote languages
  kb_clitest.en_1_json - Done
  Completed 1 / 1 tasks

  # Pushing translations

  kb_clitest.en_1_json [aln] - Uploading file
  kb_clitest.en_1_json [en_BD] - Uploading file
  kb_clitest.en_1_json [de_AT] - Uploading file
  kb_clitest.en_1_json [es_PR] - Uploading file
  kb_clitest.en_1_json [en_GR] - Uploading file
  kb_clitest.en_1_json [en_BD] - upload of resource 'o:tx_internal_gluon:p:kb_clitest:r:en_1_json', language 'l:en_BD' failed - parse_error: Expecting ':' delimiter: line 5 column 5 (char 90)
  kb_clitest.en_1_json [ig] - Uploading file
  kb_clitest.en_1_json [en_GR] - Done
  kb_clitest.en_1_json [lfn] - Uploading file
  kb_clitest.en_1_json [aln] - Done
  kb_clitest.en_1_json [scn] - Uploading file
  kb_clitest.en_1_json [de_AT] - Done
  kb_clitest.en_1_json [ta_LK] - Uploading file
  kb_clitest.en_1_json [es_PR] - Done
  kb_clitest.en_1_json [ig] - Done
  kb_clitest.en_1_json [scn] - Done
  kb_clitest.en_1_json [ta_LK] - Done
  kb_clitest.en_1_json [lfn] - Done
  Completed 8 / 9 tasks

The tx push command is used to push translations to the remote translation platform. Based on the sample outputs you provided, it seems that there is a syntax error in one of the language files, which is causing the push command to fail for that particular language.
When you use the --skip option, the push command skips the failed language file and continues pushing translations for the remaining languages. On the other hand, when you don't use the --skip option, the push command stops when it encounters the failed language file and doesn't push translations for the remaining languages.
The | cat at the end of the command is used to output the results of the command to the console in real-time. It doesn't affect the behavior of the command itself.
To fix the issue, you need to correct the syntax error in the language file that is causing the push command to fail. Once you've fixed the error, you can run the push command again without the --skip option to push translations for all languages including the one that failed previously.
If you continue to experience issues while pushing translations, you can contact the support team of the translation platform you're using for further assistance. They may be able to provide more specific guidance on resolving the issue.


Improving UX Guide (ongoing)

@frantic wrote in https://github.com/facebook/react-native/issues/14979

As discussed with @brentvatne and other during ChainReact '17, it would be great to have a section in the docs that lists mobile-specific important UX details.

This is a rough checklist:

[x] hitSlop
[ ] tab bar

tab selected tab to pop
if empty stack, scroll to top

[x] touchable with ripple
[ ] keyboard:

[x] autofocus and return key
[x] space under keyboard and dismissing
[x] keyboard type, capitalization and autocorrect

[ ] animated with useNativeDriver

only some properties supported -- no layout properties. use
transforms whenever you can rather than width/height/margin,
so you can take advantage of this

[ ] nativedriver for animated.event in scroll view or it'll be janky
[ ] loading states

onPressIn trick for preloading
placeholder elements
using data that you already have to partially render
loading state for image: what do you see when it's not there? maybe
grey placeholder, maybe gradient, maybe activity indicator, maybe
low-res version

[ ] deferring rendering expensive (eg: maps) when possible
[ ] status bar color, size
[ ] fading in network images
[ ] cancellable gestures
[ ] meaningful animations -- shared transitions for example
[ ] respect battery state
[ ] prompt before asking permissions
[ ] portrait / landscape: lock if you don't support
[ ] android back button: navigation library can do some things but not all
for you, need to consider where else users expect it to work
[ ] compress images properly, provide 2x/3x
[ ] sometimes text should be selectable
[ ] ellipsize truncated text
[ ] respect network status
[ ] splash screen (white flash)
[ ] maybe don't add an inline submit button to your form (use keyboard submit or add to navbar!)
[ ] iphonex safe areas

This is a great idea and I support you fully in your endeavors.

Any guidelines for anyone who wants to contribute towards completing the above checklist?
I've worked on a lot of the above in my react native apps, would love to help others save a bunch of time (and/or face).

@brendanv
Hi Brent, I wanted to know if the repo was open to PRs with added content for the above list? If yes, what are the constraints within which the new content should be added (length, screenshots, links to resources, etc)?
As I've mentioned above, I'd love to contribute towards completing the above checklist. Look forward to your response!
Thanks

Just seen this right now, sorry @raunaqss !

Any guidelines for anyone who wants to contribute towards completing the above checklist?

AFAIK there are no big constraints, but by looking at the current page ideally every point of the list should have a GIF showing the improvement & a link to an Expo Snack that shows the code to improve the UX.
cc @brentvatne

To be honest I think we set the bar for this document a little too high, I
myself stopped contributing because I simply didn’t have enough time to
craft gif+snack for every example.
On Tue, Mar 6, 2018 at 5:59 PM Lorenzo Sciandra<EMAIL_ADDRESS>wrote:

Just seen this right now, sorry @raunaqss https://github.com/raunaqss !
Any guidelines for anyone who wants to contribute towards completing the
above checklist?
AFAIK there are no big constraints, but by looking at the current page
ideally every point of the list should have a GIF showing the improvement &
a link to an Expo Snack that shows the code to improve the UX.
cc @brentvatne https://github.com/brentvatne
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native-website/issues/47#issuecomment-370830006,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALu3iAO_fJNMWUkxgM9uLeRF-5gQtfuks5tbrJPgaJpZM4Q6Mr_
.

maybe worth closing this since it's been open for over 2 years. We should probably instead open small issues per each actionable.


Change workflow for releases

What does the PR achieve/Which part improves the PR?

This makes a small adjustment in order to make future releases less error prone.
:thinking: DOD Checklist

[ ] My code passes the lint checks.
[ ] My changes are covered with proper tests.
[ ] All tests are pass.
[ ] My changes update the documentation.
[ ] My changes are reflected in the changelog.

Violation of the branch name schema


add sudoers support

As a DevOps
I want to configure group access to sudo
So that I can control sudo access on the boxes

done in #6


[BUG] Comments with more than 5 images do not embed properly

When a comment has more than 5 images, the bot does not separate these images into 5 per message, resulting in only 5 images being embedded.

I did not account for having more than 5 links, nor did I know that the embed limit is 5. Will work on fixing this


[Question] How ceep run olvays?

I running it local, wizhout docket, from tmux, i change in config like runOnce: false, but it continue close after check free games(, how can i make alive it olvays wizhout crons or something?

Without Docker, you'll need to configure the cron scheduling yourself.
timezone, runOnce, runOnStartup, and cronSchedule are all used outside of the Node process, and they will do nothing when running without Docker.


DF Manual Rolls: lib Wrapper, Skill Customization for 5e, Token Action HUD, Tool Proficiencies for DnD5e

Conflicting Module(s)

DF Manual Rolls
libWrapper
Skill Customization for 5e
Token Action HUD
Tool Proficiencies for DnD5e

Describe the conflict
When DF Manual Rolls is activated along these other modules, the error "Canvas Drawing Failed for the TokenLayer. See the console for details.". This prevets many behaviours, as the tabletop is malformed. Eg. conditions markers fail to display, targeting of tokens not possible.
Expected behavior
No error

Caused by the DnD5e Flavour text feature. Follow the same workaround as was developed for #70.
This issue will hopefully be fixed after the next version of DnD5e is released


Azure AD Oauth Provider  is reusing Authorization code

Describe the bug
We are using the AD Azure Provider. For most users it is working, but for some users we get
"errorCode": 54005 with the message "Oauth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.",
We compared the tokens but did not see a big difference. It is also not related to the users machine since we tested another account on the users Browser and it works there.
Any idea?
To Reproduce

Not sure how to reproduce

Expected behavior
It should work for all users

This can be closed. The problem was that our identity provider in azure is returning quite a big response which our nginx in the Kuberentes cluster could not handle. Increasing the proxy_buffer_size of nginx to 16k helped. I suppose this is not directly related to Chainlit.
However I strongly support @dokterbob initiative to NOT roll your own auth and instead use existing libraries


I wanted to send my translation because I saw that I was looking for a translator in the document of Thunderstorm, but I don't know how to use github. I'm sorry if it's not like this.
P.S. This message was written using a translator, so it might be a little awkward :(
Sniper.txt
I'll leave a file.
And I don't know if I can upload it here, but I will also upload the translation of HAN-D mode.
HAN-D.txt

Thanks! I'll be adding the HAN-D one as well.


Socket closed unexpectedly after 5 seconds

Description
I'm running redis with replication, with the simple client configuration createClient({ url }).  After the initial connection is successfully established, the socket is closed after 5 seconds. I guess this is because the socket connectTimeout is by default 5s, and in packages/client/lib/client/socket.ts, it'll close it based on the property.
async #createSocket(): Promise<net.Socket | tls.TLSSocket> {
    const socket = this.#socketFactory.create();

    let onTimeout;
    if (this.#connectTimeout !== undefined) {
      onTimeout = () => socket.destroy(new ConnectionTimeoutError());
      socket.once('timeout', onTimeout);
      socket.setTimeout(this.#connectTimeout);
    }
    ....
    return socket;
  }

I've already taken a look into other related issues, and I tried setting pingInterval and setting socket connectTimeout to 0, and as expected, the socket is closed regardless. What is the recommended way to keep the socket connection alive?
INFO:
Redis is deployed via Helm (bitnami 20.1.4) into kubernetes cluster, with one master node and 3 replicas.
Node.js Version
20.14.0
Redis Server Version
7.4.0
Node Redis Version
4.7.0
Platform
Linux
Logs
No response

Same


Primitive debug bounding sphere hidden behind ellipsoid

At a certain point, tilting the camera seems to make the debug bounding sphere primitive only appear behind the ellipsoid.  This has made debugging bounding sphere issues for small primitives kind of difficult.
https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/?src=Cesium Inspector.html

@bagnell this first appeared as a problem in the 1.45 release.  Is this also related to the log depth changes?

Probably. If you ever think it's a log depth issue, you can set scene.logarithmicDepthBuffer = false;.

Cool, yeah setting scene.logarithmicDepthBuffer = false; fixes the issue so it must be related to that


unsupported operand type(s) for |: 'type' and 'type'

When I import twikit, it throws exceptiion bellow.
unsupported operand type(s) for |: 'type' and 'type'
Python version 3.9
OS Windows 11
IDE Visual Studio 2022
How can I fix this exception?

Try updating your Python version to 3.10 or later - Python 3.9 doesn't support PEP-604 to annotate union types, which is used by Twikit.

It works. thank you.


[DROOLS-1377] remove reteoo implementation

ok to test

I think this definitely qualifies as a backwards-incompatible change and as such should be documented in the upgrade recipe https://github.com/droolsjbpm/drools-website/blob/master/download/upgradeRecipe/upgradeRecipe7.0.adoc


Adding media to on-chain metadata

As decided per sprint dev sync, not gonna continue this for now.


Kixiro master fix 124

Codecov Report

Merging #130 into master will decrease coverage by 0.12%.
The diff coverage is 25%.

@@            Coverage Diff             @@
##           master     #130      +/-   ##
==========================================
- Coverage   60.25%   60.13%   -0.13%
==========================================
  Files          25       25
  Lines        1170     1174       +4
  Branches       98      100       +2
==========================================
+ Hits          705      706       +1
+ Misses        459      444      -15
- Partials        6       24      +18

Impacted Files
Coverage Δ

selene/wait.py
23.07% <25%> (+0.34%)
:arrow_up:

selene/elements.py
50.42% <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 7656668...ca59201. Read the comment docs.


Don't allow null values for experienceable columns

Context
Now that all application experiences have an experienceable value, this column should not allow null values
https://github.com/DFE-Digital/apply-for-teacher-training/pull/9679 needs to be merged first
Changes proposed in this pull request
Migrations to set not null on experienceable type and id following the strong migrations guidelines https://github.com/ankane/strong_migrations?tab=readme-ov-file#setting-not-null-on-an-existing-column
Guidance to review
Run migrations and check schema
Things to check

[ ] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
[ ] API release notes have been updated if necessary
[ ] If it adds a significant user-facing change, is it documented in the CHANGELOG?
[ ] Required environment variables have been updated added to the Azure KeyVault
[x] Inform data insights team due to database changes
[x] Make sure all information from the Trello card is in here
[x] Rebased main
[x] Cleaned commit history
[x] Tested by running locally
[x] Add PR link to Trello card

 Edit work experiences - Change db structure to accommodate work experience edits


Design of backend needs to have better color combination.

We have focused mainly on our functionality and not on how our design is looking. So, if anybody can assist us in changing or altering the color theme with a good one. We will appreciate it.
For doing changes in CSS of the project, you need to update the custom-style.css file in public/css folder.
You can run npm run watch to do changes and not do npm run dev again and again.
You will have to do above as our custom style file is in webpack.js.
Thanks for your help.
Looking forward.

For now, we will stick with AdminLTE. in future we will integrate any new theme, when we will start migrating to vue.js


chore(ci): introduce the release drafter

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 38.51%

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
1091

Relevant Lines:
2833

💛  - Coveralls


Number 100 Bug

Anyone can win the game by entering number 100 two times .

Thank you @prasoonjain006 for finding this bug. There may be some callback issues. Would you like to work on it?

yes I can try

I am assigning you the issue. Hope you find the solution soon !
Wish you Good Luck!


feat(titleProp): add titleProp option

Closes #88

Hi @neoziro !
Well, the titleProp option is working and I writed all the tests.
But, I have seen that  does not exist for React Native, so for the moment, the feature is only supported on React.

Thanks :) Yes no problem :)

@neoziro Readme updated ! :)

@MarquesDev can you rebase it please? It has some conflicts :s

@neoziro Done :)


remove extra hyphen in dns1123LabelFmt

Remove the extra hyphen in dns1123LabelFmt.

Hi @knight42. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


chore(package): update openshift-rest-client to 1.0.1

Coverage remained the same at 96.154% when pulling 0e272c3cb7f6ebd972f6254e97ae0fb5e35519cc on lholmquist:openshift-rest-client-1.0.1 into c15aacaa6b055933d0584f5a67a5ddf5224ad75a on bucharest-gold:master.