Make graph payloads mandatory

Rationale
Currently, the payloads of graph nodes and edges are optional. That is, in a Graph n e, nodes contain payloads of type Maybe n and edges, of type Maybe e. There is currently, however, no use for these payloads in Verigraph, not even to allow metadata such as graph layout (since payloads are not handled and propagated by pullbacks, pushouts, overlappings and similar operations).
One of the possible uses would be to store attributes and typing information, which would reduce the number of dictionary lookups necessary to handle typed attributed graphs, simplifying code and improving performance. This, however, is not possible with optional payloads, since all nodes and edges need to have this information.
In order to allow this, graphs would need to have mandatory payloads. That is, in a Graph n e, nodes would contain payloads of type n and edges, of type e. Then, typed attributed graphs could be implemented simply as follows.
import qualified Graph as G

type AttributedGraph n e =
  G.Graph (NodeType, Map AttrName AttrValue, n) (EdgeType, Map AttrName AttrValue, e)

type Node n =
  G.Node (NodeType, Map AttrName AttrValue, n)

type Edge e =
  G.Edge (EdgeType, Map AttrName AttrValue, e)

nodeType :: Node n -> NodeType
nodeType = fst . G.nodeInfo

edgeType :: Edge n -> EdgeType
edgeType = fst . G.edgeInfo

nodeInfo :: Node n -> n
nodeInfo = third . G.nodeInfo

edgeInfo :: Edge e -> e
edgeInfo = third . G.edgeInfo

This implementation pattern has the following advantages:

A single lookup gives all information about a node or edge, simplifying code and improving efficiency.

Most of the Graph API would be immediately applicable to specialized graph types, without the need for separate functions as is currently done in for TypedGraphs

Proposed Changes
First, change the implementation of Graph so its has mandatory payloads. The impact of this change in the rest of Verigraph could be handled in two ways, based on Graph () () (unit-based) or on Graph (Maybe a) (Maybe e) (maybe-based).
Unit-Based Solution
Since no part of verigraph currently uses the payloads, they could be replaced with unit types whenever they are "ignored" by functions.  We'd have, for example:
insertNode :: NodeId -> Graph () e -> Graph () e
insertNodeWithPayload :: NodeId -> n -> Graph n e -> Graph n e

instance Morphism (GraphMorphism () ())

instance Morphism (TypedGraphMorphism () ())

Maybe-Based Solution
Alternatively, we could displace the assumption of optional payloads to the function signature. That is, whenever Nothing is required to be a possible node payload, the type signature contains Graph (Maybe n) e (analogously for edges). We'd have, for example:
insertNode :: NodeId -> Graph (Maybe n) e -> Graph (Maybe n) e
insertNodeWithPayload :: NodeId -> n -> Graph n e -> Graph n e

instance Morphism (GraphMorphism (Maybe n) (Maybe e))

instance Morphism (TypedGraphMorphism (Maybe n) (Maybe e))

The Maybe-based solution interacts better with #13. Since the following instance exists, it would allow the use and propagation of metadata by the current implementation.
instance Monoid a => Monoid (Maybe a)

I'm choosing the Maybe-based solution because of issue #13.

Solved and merged to master.


Should positionals be opt-in when strict: true?

Elsewhere I've mentioned I think the goal of strict: true should be that you can write a well-behaved script just by calling parseArgs with your options configured, with no further validation required (except validation of the values of value-taking options, which is out of scope). Here by "well-behaved" I mean it will surface an error to the user if they try to use the script in a way the author did not intend.
Right now, if I'm writing a script which does not expect positional arguments, and I do the obvious thing of
let { values } = util.parseArgs({ options });

but the user passes a positional argument, I'm never going to notice, and the user's input is going to be silently dropped. And it's very likely that I'll end up shipping this, because it's probably not going to occur to me to try passing a positional argument and so I will never notice this problem.
That seems contrary to the goal above. So I'd like to suggest having a positionals configuration option, which must be explicitly opted into (when strict: true). For people who want positionals, this ought to be a small hiccup: they'll notice right away that passing a positional argument doesn't work. And for people who don't, they'll get the right behavior. So neither group is at risk of shipping a script which is not well-behaved.
(Good errors help here: e.g., "this script has not been configured to take positional arguments" is clear to users that they're misusing the script, and to authors who want to take positional arguments that they need to configure it to take positional arguments.)

 If the parser encounters an unknown flag --foo, and the script author has explicitly opted in to positionals, the error message can suggest that if the user intended to pass --foo as a positional argument they can do so by putting -- --foo at the end of the command invocation. But you wouldn't want to suggest this in a script which isn't using positionals.

That seems pretty reasonable - maybe a “positionalArgs” option, that can be true, or an integer?

Would the integer be a minimum, a maximum, or a precise number of positional arguments to expect? None of those are very satisfying answers, I think.
I suppose you could allow specifying both a minimum and a maximum, at the cost of even more config knobs.

I’d expect a maximum, but yes, it could instead be true, or an object with min/max integer properties.

Quick comment. Good description! However, I don't like adding configuration to use basic features of the parser, so still thinking about it.

However, I don't like adding configuration to use basic features of the parser

Well, the other half of that is that absent this config options, scripts which don't want positionals but still want to be well-behaved will need to add extra logic to use the parser at all: const results = parseArgs({options}); if (result.positionals.length > 0) throw new Error('this script does not take positional arguments');.
So one of the two groups (expecting-positionals and not-expecting-positionals) is inevitably going to have to add something, to get the behavior they want and be well-behaved.
Not being able to configure this amounts to deciding that the not-expecting-positionals group is the one which will need to add something. Which is fine, in general, but my concern is that in this particular case that group is not even going to notice they needed to add something to be well-behaved, and consequently ship a poorly-behaved script, which is (I think) a bad outcome.
(And, separately, having this bit would allow better error messages, which I think is valuable.)

Here by "well-behaved" I mean it will surface an error to the user if they try to use the script in a way the author did not intend.

This is a thinking-out-loud comment, not fully formed. I like the concept, but I am concerned it is a slippery slope of diminishing returns. At what point do we say no?

A deliberately over-stated description of "well-behaved", but where do we draw the line?

We just need one more piece of configuration for situation x, then we could detect and display an error. And it has to be on by default or does not achieve "well-behaved" by default. So it isn't just a config knob, it is a required config knob for usage not covered by the default or not able to have a default.

And we should block some standard functionality, because it allows us to detect more errors. (Like blocking --foo VALUE.)

The extreme end-point is a safe "well-behaved" subset of functionality that requires extensive configuration and does not behave like other programs. And tutorials will say "use strict:false to simplify setup"!
Ok, please resume normal levels of cynicism and scepticism.

Why must there be a point where we say no? Zero config strict mode means that any time there’s something we discover is a footgun, we’d want to make the default behavior safe, even if that means common cases would require more configuration.

Would the integer be a minimum, a maximum, or a precise number of positional arguments to expect? None of those are very satisfying answers, I think.
I suppose you could allow specifying both a minimum and a maximum, at the cost of even more config knobs.

Some common use cases are:

no positionals. e.g. ls
an exact number of positionals. e.g. copy source dest
variadic, possibly with a minimum e.g. print *.js

Zero config strict mode means that any time there’s something we discover is a footgun, we’d want to make the default behavior safe, even if that means common cases would require more configuration.

I don't think "zero config" belongs in that sentence. 😉

Why must there be a point where we say no?

Ok, I'll bite.
Because there isn't agreement there is demand or a need for a bullet-proof argument parser built into node. That wasn't in the previous proposal, or the initial spec here, or the current spec.
Because each additional piece of safety configuration offers the potential to detect one more footgun, but makes the library harder to get started with, or less convenient for the end user. As the starting configuration gets more intimidating, the chances people start from a boiler-plate starting configuration which bypasses the protections increase. Or people use strict:false. Or people go elsewhere and the adoption of the library is lowered.
I care about the cost-benefit ratio. I think there is often a trade-off between safety and usability and some protections are not worth the penalties.
To be clear, I opened the issue about whether there is going to be a strict mode at all, and I would prefer to include a strict mode in the first implementation. But not bullet-proof.

I am concerned it is a slippery slope of diminishing returns. At what point do we say no?

Yeah, I agree this slope is pretty slippery. I think the heuristic I would use strict: true is something like:

if authors in the most common scenario would reasonably expect the validation to happen (e.g. any type: 'string' option is given a value), that validation should definitely happen
if authors in some common scenario is unlikely to notice they need to do extra validation to meet my definition of well-behaved, that validation should probably happen by default (this issue)
other kinds of validation should not happen by default, or for that matter at all (e.g. validation the values for particular options parse as numbers: because script authors must parse strings to numbers themselves, it should be obvious they need to verify that the format is as they expect)

The third thing, in particular, means that there are always going to be scripts which are not well-behaved by my definition without the author performing additional validation. That's OK, as long as it's reasonably obvious to authors that they are going to need to do that validation themselves.
I think having a boolean for positionals is the right balance on this issue. It gets rid of the sharp edge of "it didn't occur to me to check for and reject positionals" (which is a very easy mistake to make). And once you've explicitly opted in to getting an array of positional arguments, hopefully at that point you're going to think to check if you got too few or too many (if those concepts are relevant to your application). Some people still won't do those checks, but you can't save everyone.
I could see an argument [heh] for having minPositionals and maxPositionals, both defaulting to 0. I'm not advocating that, to be clear, although I'm fine with that as a resolution to this issue. But I personally can't think any other kinds of validation beyond that (other than those already planned) which would fall into either of my first two bullet points, which makes me feel better about going stopping at exactly this point on the slippery slope, and no further.

This of course hinges on author expectations, and in particular how many people we think are going to run into a given sharp edge. I think it's going to be pretty common to write applications which aren't expecting any positional arguments, so I think that's a scenario we should weight pretty highly.
There's always going to be someone out there who is surprised by, say, the fact that --foo=false gives them the string false, but I think that's a more minority case - there's just not that many applications where this behavior would result in a bug and the author probably isn't going to think check for it. So I don't think that needs to be validated by default, even though there will be some number of scripts which end up being not-well-behaved for lack of validation here.

Nice heuristic. Thanks for taking the time to lay it out!
I am up for an opt-in boolean for positionals.

There's always going to be someone out there who is surprised by, say, the fact that --foo=false gives them the string false,

If foo is type:boolean I think this will be an error in strict mode, which of particular note addresses the --explode=false concerns raised in previous proposal discussion.

What is this opt-in property named? Trying a couple of other variations:
const { values, positionals } = parseArgs({ strict: true, positionals: true, options: knownOptions });
const { values, positionals } = parseArgs({ strict: true, allowPositionals: true, options: knownOptions });
const { values, positionals } = parseArgs({ strict: true, expectPositionals: true, options: knownOptions });

I would call it positionals, I think. allowPositionals is kind of long to type.

I still prefer a longer name. A few reasons:

you only have to type it once (won't be used multiple times in code)
clearer what it does when reading code
I am uneasy about using same name for properties on input and output

I think I've been nudged towards the argument that options should default to strict=true. From an API perspective, it seems pretty natural and easy to explain that, by default, you will need to provide config for each option that you want to accept (_a nice side-effect being that it eliminates ambiguity between boolean and string options).
I'm supportive of the allowPositionals configuration, for @bakkot's use case. But I tend to agree with @shadowspawn that I'm worried about adding another config setting individuals will frequently need to set for a very common use-case.
My preference would be allowPositionals defaulting to true.

+1 for allowPositionals  and defaulting to true

It's not very useful to have the option if the default is to allow positionals. After all, if a script author remembers that they need to explicitly disallow positional arguments for their particular application, they can write if (result.positionals.length > 0) throw new Error(`unexpected argument ${JSON.stringify(positionals[0])}`) or whatever. It doesn't make much difference whether they write this or do allowPositionals: false; it's actually one of the easier kinds of validation to do manually. My concern is specifically that people won't remember that they need to check: if you are writing a script that doesn't take positional arguments at all, you're probably not going to be thinking about or testing the possibility that a user might try to give you one.
That is, I think that making positionals opt-in is in keeping with the "you will need to provide config for each option that you want to accept" design. I regard positionals as being a kind of option that you want to accept. If we don't accept this point of view, I don't think there's much benefit to have a config option to disallow them at all, since a script author can do that themselves trivially.

I also think either allowPositionals: false by default and need to opt-in to positionals, or not at all.
And I am ok either way.

Shall we just take this feature to a vote with :+1: (allowPositionals defaulting to false), :-1: (launching without allowPositionals).

@shadowspawn, @iansu, anyone else want to chime in ☝, otherwise I'd say we go the route @bakkot is suggesting by a narrow margin (2 👍, to 1 👎 ).

@bakkot @shadowspawn, looks like we might not quite make 18.0.0, unless address blockers ASAP, see:
https://github.com/nodejs/node/pull/42262#issuecomment-1097227730
If there's a chance it addresses our last open point of discussion, I'm pro allowPositionals. I also don't want to rush us, if we don't think it's realistic to get a release out the door tomorrow.
Worst case scenario, we land in an early minor release of Node 18, and people can start to rely on parseArgs in Node 19/20.

I think it would be a rush for tomorrow. We have not landed any of strict yet.
I suggest we do not attempt this now, rather than rush a decision. Reasoning:

if we add allowPositionals later we explicitly break people
if we take allowPositionals out later, we silently change behaviour and stop detecting usage errors
we haven't landed strict yet

Of historical interest, it used to be very hard to check for excess positionals in Commander including by client. It irritated me but not many issues touched on it. I added support for detecting excess with the intention of turning it on by default, but broke a number of my own unit tests and decided to make it opt-in to ship with less churn for existing users. I know that is an argument each way, but my point is that the lack of checks did come up much as a reported issue.

I suggest we do not attempt this now, rather than rush a decision.

To be clear, I suggest this issue misses out on MVP. Not that we delay MVP.

That doesn’t seem like that big a deal to me - it’ll just be listed in the docs.

I think you'd know better than I would the costs and benefits of introducing an additional restriction like this after shipping. If you think a restriction like this can be reasonably added in a post-MVP version, that's fine with me. If not - if you think people are going to depend on getting positionals, such that node wouldn't want to break those people by making positionals opt-in - well, I don't know how serious a cost it is to miss 18.0.0, so that's hard for me to weigh that against never having this restriction.
Certainly it's not the end of the world if this gets left out forever, though. It'll be another thing many consumers need to always remember to validate lest their application silently drop input, to the annoyance of their users. But we can't eliminate all of those cases, so having another big one, while in my view it would be quite unfortunate, isn't fatal.

I think you'd know better than I would the costs and benefits of introducing an additional restriction like this after shipping.

I think there's a tradeoff, my experience with adding code coverage to Node.js, which landed in a minor release, was that the feature didn't see significant adoption until the next major releases -- I think people are hesitant to deliver an application that will only work with a certain version range of runtimes.
However, I do want to be careful not to force util.parseArgs over the finish line of we don't think it's ready. I think I'm more concerned about #104, than this thread leading to a breaking change (since we've marked the feature as experimental and, furthermore, adoption will be gradual).

My concerns about landing in a minor release of Node.js might be out of date. People building GitHub actions with Node.js would be able to immediately benefit from the feature, this is a newish application of Node.js that I expect this feature will be popular in.

In my experience, pre-LTS minors of node 18 just won't matter; it's only the first LTS minor that people are likely to be "stuck" on. I think as long as we land in node 18 prior to LTS, we're perfectly fine, and I'd prefer to land with as full a featureset as we think is warranted (including this issue).

I think the timezone difference means this is a done deal with parseArgs landing 18.0.0!?
I abstained from the vote, as I am ok either way. To be clear:

I am willing to ship without this. Ever. And we have no new people asking for it from the PR viewers.
I am willing to contribute to this. I may get more enthusiastic about it from working on it and seeing it solidify! But if it doesn't come together then I will push for it to be abandoned.

A common approach for ideation is to go wide, then come narrow down again with consensus, and can focus on what is left. So for narrowing, are we agreed that:

one optional boolean configuration flag
strict:true, unless opt-in, get an error if args include positional
strict:true, opt-in to positionals, any positionals in args are returned and validation left entirely to author

This one is a suggestion, see if get consensus on first try. Making up the last case as I write it!

strict:false + no config: no error, no effect
strict:false + opt-in: no effect (i.e. like strict:true, sure have all the positionals you want!)
strict:false + opt-out (!): author usage error. Keep the story simple, strict:false means bring-your-own-validation. Not an expected setting, but it can be good practice not to rely on default behaviours. With no validation, it would be actively misleading to look like you were going to get validation so block this combination.

Naming: the opt-in configuration is named allowPositionals?
(Note: I am against positionals, so that is not an alternative that will get unanimous support!)
Please vote to gauge consensus.

I think the code will be easy. Where it gets interesting is documenting this so it delivers batteries-included benefits to the people not using positionals (as eloquently described by @bakkot), and does not prove a pain point for people who do wish positionals (a concern to @bcoe and me).

Naming: shall the opt-in configuration be named allowPositionals?

I also prefer the more descriptive allowPositionals.

I abstained from the vote, as I am ok either way. To be clear:

I'm also okay either way at this point, it seemed like we had one more vote for adding this feature than not.
@bakkot it sounded like you'd be willing to implement this feature? why don't you create a PR, and we can reference it in the PR to merge parseArgs into Node.js.
If no one makes a strong argument against allowPositionals on the open PR, I'm open to landing your recommendation.
We're calling parseArgs experimental, if user feedback says they don't like allowPositionals we can change our mind about the feature in the future.

@bcoe Happy to make a PR, but it might be a day or two.

Is there a desired timeframe @bcoe ? (I am guessing perhaps no fixed deadline, just as soon as convenient?)

Is there a desired timeframe @bcoe ? (I am guessing perhaps no fixed deadline, just as soon as convenient?)

No set deadline, but it can get annoying keeping an upstream PR in sync for too long, mid next week might be a good goal for MVP into Node.js?
We'll have an opportunity to do some follow up PRS before 18.1.0.


solved the issue of dark mode text invisiblity issue#229

ISSUE #229 solved here is the before and after

please give level 2 if possible

resolve conflicts

i think its solved now please give level 2


Update chrono depency version to 0.4.30

Replaces https://github.com/newsboat/newsboat/pull/2542. Resolves deprecation warnings caused by chrono update.

coverage: 60.059% (+0.003%) from 60.056% when pulling 7cf2dd72d31720099b1ab6c17fe6047f960bb245 on dennisschagt:update-chrono-dependency into<PHONE_NUMBER>2e409b72823ac42979d16b46c94b41 on newsboat:master.

It looks like chrono dropped their dependency on time, so we could now decide to drop the non-default feature selection:
https://github.com/newsboat/newsboat/blob/79119120812e409b72823ac42979d16b46c94b41/rust/libnewsboat/Cargo.toml#L50-L57

Thank you! And good point about the default features. I changed Cargo.toml and enabled auto-merge.


Add error emitter for user input errors

This was originally the work by @buhuitou in https://github.com/Hacker0x01/react-datepicker/pull/965
We've solved the merge conflicts, that were blocking the original PR.
From the original:

This pull request is to address the needs to manage keyboard input error outside date picker component by emitting validation error when Enter, Tab, or Esc is pressed.

This has been updated to fix the tests now.


X-Files lists integration

Can I propose to integrate X-Files lists?
Repo: https://github.com/gioxx/xfiles
Lists:
https://github.com/gioxx/xfiles/blob/master/filtri.txt
https://github.com/gioxx/xfiles/blob/master/experimental.txt
https://github.com/gioxx/xfiles/blob/master/facebook.txt
https://github.com/gioxx/xfiles/blob/master/siteblock.txt
https://github.com/gioxx/xfiles/blob/master/upd.txt
Thanks :)

I'm sorry, but I'm unable to parse Adblock formatted files. Only Hosts or domain lists at this time.

Got it, surely I can work on it because UPD is based on domains.
I'll get back to you as soon as I work on the clean domains list :)

Here we are :-)
https://github.com/gioxx/xfiles/blob/master/domains/upd_domains.txt


The what-if output does not include the creation of any VM disks

Describe the bug
I have an ARM template to deploy a new VM. Deploying the template to an empty resource group creates resources of the following types:

Microsoft.Compute/virtualmachines
Microsoft.Compute/disks

The output from the what-if analysis does not include the creation of any Microsoft.Compute/disks resources.
To Reproduce
Steps to reproduce the behavior:

Perform a what-if analysis using the following template
See the output

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "<IP_ADDRESS>",
  "parameters": {
    "vm-name": {
      "type": "string",
      "defaultValue": "[uniqueString(resourceGroup().id)]",
      "metadata": {
        "description": "Name of the VM"
      }
    },
    "nic-name": {
      "type": "string",
      "metadata": {
        "description": "Name of the VM's NIC"
      }
    },
    "admin-user": {
      "type": "string"
    },
    "admin-pwd": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Compute/virtualmachines",
      "apiVersion": "2018-10-01",
      "name": "[parameters('vm-name')]",
      "location": "[resourceGroup().location]",
      "properties": {
        "networkProfile": {
          "networkInterfaces": [
            {
              "id": "[resourceId('Microsoft.Network/networkInterfaces', parameters('nic-name'))]"
            }
          ]
        },
        "storageProfile": {
          "imageReference": {
            "publisher": "MicrosoftWindowsServer",
            "offer": "WindowsServer",
            "sku": "2016-Datacenter",
            "version": "latest"
          },
          "osDisk": {
            "createOption": "FromImage"
          },
          "dataDisks": [
            {
              "lun": 0,
              "diskSizeGB": 511,
              "managedDisk": {
                "storageAccountType": "Standard_LRS"
              },
              "createOption": "Empty"
            }
          ]
        },
        "hardwareProfile": {
          "vmSize": "Standard_B1ms"
        },
        "osProfile": {
          "computerName": "[parameters('vm-name')]",
          "adminPassword": "[parameters('admin-pwd')]",
          "adminUsername": "[parameters('admin-user')]"
        }
      }
    }
  ],
  "outputs": {
  }
}

Expected behavior
I expected the what-if output to indicate the creation of some disk resources.
Screenshots

Client [e.g. PowerShell, CLI, API)
Powershell
Additional context
None

This is a known limitation. What-If only understands the resources that are directly declared in the template. We plan to extend what-if to support resources that are created/managed by other resources (AKS is another good example), but we don't have an ETA for this right now

Going to close this and keep a reference to it in the above issue which is more generalized. Thanks for reporting!


Address issues found by golint.

No functional changes should be in this PR.

Did not modify public APIs and field names
Did not address the ALL_CAPS warnings

LGTM

This closes #221, correct?


Update jena-arq to 4.2.0

Updates org.apache.jena:jena-arq from 3.17.0 to 4.2.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.apache.jena", artifactId = "jena-arq" } ]

labels: library-update, semver-major

Superseded by #59.


Kubernetes v1.13.1

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#kubernetes-113-release-notes
https://sysdig.com/blog/whats-new-in-kubernetes-1-13/

PR includes Kubeadm refactoring because Kubernetes 1.13 requires new config format.
TODO

[x] refactor configs
[x] update cri-o
[x] fix/improve specs

Specs should now pass. PTAL (again) @jnummelin @kke.


[Question] Getting exact source accessing Bot Web API

System Information

SDK Language: <NET/C#>
SDK Version: <<IP_ADDRESS>>
Development Environment: <AZURE_APP_SERVICE>

I am using Microsoft BOT Builder to create BOT using C#. I have created by Web API and hosted in Azure. I have enabled Microsoft Teams channel for my BOT.
When i try to access my BOT in teams, my Web API gets web requests from a synthetic traffic and that provides incorrect information regarding who is trying to access my BOT. My question is - is it because of Microsoft Team or the Bot Connector which sits between the channel and my BOT web API, and is there any way i can get the real user information who is accessing my BOT web api?

@riteshbhoi You can get more detailed information by setting up App Insights in your Azure instance, then register your App Insights ID & Key in the bot portal at https://botframework.com in the Settings page.
For more information about configuring App Insights for Bot Framework, see:
https://docs.microsoft.com/en-us/bot-framework/resources-app-insights-keys

Relates to: https://stackoverflow.com/questions/44577453/incorrect-information-from-source-hitting-bot-web-api

@nwhitmont I am setting up my own Application Insights for the BOT Web API as i want to capture few more telemetry information. Please let me know if there is any way I can resolve above mentioned issue?

@riteshbhoi You would need to examine the access logs in your Azure subscription.


Invalid JsonProperty

The JsonProperty in LtiLibrary.Core.Outcomes.v2.Activity for ActivityId is set as "activity_id", however the spec for LTI Outcomes 2.0 lists this property as "activityId".

Right you are (https://www.imsglobal.org/lti/model/mediatype/application/vnd/ims/lis/v2/lineitem%2Bjson/index.html#Activity). Context too (https://www.imsglobal.org/lti/model/mediatype/application/vnd/ims/lis/v2/lineitem%2Bjson/index.html#Context).

@andyfmiller Unfortunately it was not fixed in the scope of #35.

I was about to log an issue about the fact that @context is mandatory in Outcomes 2.0 but the library does not automatically insert the default value if none is set.
Is that part of the proposed fix?
TIA

What would be a good default value? A default value might hide a logic problem in the application using this library. I think it might be better to keep the current default (null).

@andyfmiller I think that it will be a good idea to throw an exception (when sending a request) if value is not provided, what do you think?

That's a great idea. It would match the LtiLibrary behavior for launch requests. Probably outside the scope of this issue though.

Created a new issue #38 to throw an exception (when sending a request) if mandatory/required value was not provided.


unicode in parameter names

for https://github.com/yiisoft/yii2/issues/8508
just to show what i mean

update: current output for utf-8 looks like
code
$f = ActiveForm::begin();
echo $f->field($ar, 'рік');
ActiveForm::end();

response
<form id="w0" action=".." method="post">

Рік
<input type="text" id="test-рік" class="form-control" name="Test[рік]" value="2010">

</form>

i managed to get it going, but i'm not sure it worth the candles.
such approach requires dependency on app object which is not good for static method.

i looked a bit at code more. does this 'Yii::charset" do anything at all except sending useless contentType header?
imagine example: my code base is in cp1251, yii2 in utf8. i set Yii::app->charset = 'cp1251', db connection to cp1251 too. now yii2 - dies or lives?
i tried it recently on cp1251 code files. in config i put charset to cp1251.
 echo yii\helpers\Html::encode('фівїхфжівї');
 echo '
';
 echo 'фівїхфжівї';

output was with right cp1251 encoding, but Html encode failed
 пїЅпїЅпїЅпїЅпїЅ
 фівїхфжівї

how this charset option is supposed to work?
regards

it has huge chain.. it looks like better to abandon this

Hmm... indeed it looks too complicated. Let's leave this pull request open for a while. Need to think about it.

alright. whenever you please. i'll be pushing some from time to time with a study purpose.

i have a question about code -  $this->_queryParams is never reached in Request:: getQueryParams() because this var is never set. also  this class is 0% covered with tests.
what's the purpose of method Request::setQueryParams() ?

Request::setQueryParams() can be used in unit tests.

klimov-paul,
why do so? PHPUnit resets super globals on each test

this pull doesnt make any sense so far. closing
regards


Misspell the word 'permanently' in delete blobs dialog

Storage Explorer Version: 1.7.0_20190408.2
Platform/OS: Linux Ubuntu/macOS High Sierra/Windows 10
Architecture: ia32/x64
Commit: d69b9735
Regression From: Not a regression
Steps to reproduce:

Expand a non-ADLS Gen2 account -> Blob Containers(make sure the soft delete policy is disabled).
Create a blob container -> Upload a file then try to delete it.
Check the delete dialog.

Expect Experience:
The word 'permanently' spells correctly.
Actual Experience:
Misspell the word 'permanently'.

PR submitted

Merged.

Hi @jinglouMSFT, Verified this issue on the latest build 20190418.1. This issue still reproduces.

Please try with today's build. Craig just approved the new PR and should be in today's build.


feat(alexaSkill): add alexaSkill event type

Adds support for Alexa Intent, and Alexa Start/End Session event types.
Adds idx dev dependency for terse yet performant event-type check
Adds flat dep for capturing unanticipated object key/values
A few style changes, push least-anticipated event types further in the event check

fix #17

@ewindisch @kolanos back in review, added blacklisted keys requested by @ewindisch

@coreylight @ewindisch Made equivalent updates here: https://github.com/iopipe/iopipe-python/pull/218


How to stop signal loop when channel is ready

when the peer connection is successful, signaling_loop and message_loop still keep running. Is there a way to stop the signal loop when the signaling service is not needed? After the game is successfully matched, the signaling service may not be necessary, but now when an error occurs in the signaling service, message_loop will also stop working.

See #252 for some discussion on this


[d3d9] The Witcher 2 - bytecode does not match shader stage

The Witcher 2 seems to do some things which don't really get along well with either WineD3D or DXVK. I'm hoping this somehow affects performance and is something you can fix/alleviate. So, yes, this is not necessarily a Wine bug or a DXVK bug, but it will be a bug report in which I'll whine :), mostly about performance.

err:   GetShaderModule: Bytecode does not match shader stage

Shows up a lot in the DXVK logs. Admittedly, the game does not play nice with WineD3D either:
wine_output.txt
I'm playing it for a third and final time now, on a GTX 1070. I've also played it on a Nvidia 540M ages ago, then later on a 1050 Ti (both times in Windows).
Performance was as follows, at worst:

540M @ 720p: 15-20 fps (Medium settings)
1050 Ti @ 1080p: very rare drops below 60pfs (Ultra settings)

Current performance figures are (at worst):

GTX 1070 @ 1080p WineD3D: 20-25 fps (High settings)
GTX 1070 @ 1080p DXVK: 30-35 fps (High settings)

The good news is that the best way to play it is with DXVK. The game does have an eON-based Linux port, which performs a bit better than DXVK overall (they did throw money and people at it to optimize it specifically for this game, so it makes sense), but sometimes stutters annoyingly. I thought it could be the CPU governor, but it does the same thing when I'm on performance. DXVK does not have this issue.
The bad news is that it should run like a rocket, and it's not. I've tried lowering the resolution and some in-game settings, but it seems the problematic areas still perform poorly. Double checked I'm not limited by the CPU or anything else, just in case, even if this is a game from 2011.
Software information
The Witcher 2 EE (GOG version)
System information

GPU: GeForce GTX 1070
Driver: 440.59.0
Wine version: 5.2 Staging
DXVK version: v1.5.5

Apitrace file(s)
witcher2.trace.tar.xz
Log files

d3d9.log: witcher2_d3d9.log
d3d11.log: N/A
dxgi.log: N/A

err: GetShaderModule: Bytecode does not match shader stage

This is a game bug and we put that log message in there specifically because of Witcher 2.

I see. Too bad, in a way. I know I'm comparing DX9 apples to DX11 cherries by saying this, but I'm getting more fps with Witcher 3 than Witcher 2...

Double checked I'm not limited by the CPU or anything else, just in case, even if this is a game from 2011.

What's your CPU?
Please note that the game requires esync (or fsync) to be enabled in order to get any reasonable performance, so make sure you have that enabled.
I'd also recommend disabling Übersampling if you have that enabled. This option does not just increase internal rendering resolution like any normal game would, instead it renders the entire scene four times with a small sub-pixel offset applied and therefore has a very high impact on CPU performance.
That said, the game is running perfectly fine on my end. This is with Übersampling enabled, pretty much highest possible settings, on an RX 480:

What's your CPU?

i5-7300HQ. Nothing exceptional, but should be good enough.

Please note that the game requires esync (or fsync) to be enabled in order to get any reasonable performance, so make sure you have that enabled.

I see. I'm not using either at the moment, admittedly. Perhaps I'm just lazy, but I was hoping fsync would end up in the mainline kernel by now. Anyway, thanks, I'll give it a try. This is most likely why I'm not getting where I want to be with a lot of DX9 titles.

I'd also recommend disabling Übersampling if you have that enabled.

It's disabled with the "High" preset, so no, wasn't on anyway.
Thanks for taking your time to walk me through this :).

Please note that the game requires esync (or fsync) to be enabled in order to get any reasonable performance, so make sure you have that enabled.

Turns out I am too lazy to patch a kernel these days, but esync is good enough for now :grin:.
 Do esync/fsync help with DX11 titles as well?
Thanks again (immensely)!

Do esync/fsync help with DX11 titles as well?

Absolutely, you pretty much always want to have it enabled (Proton enables it by default).
Some (very) old games are known to have issues, such as Crysis, but those are in the minority.


Can't get node to join cluster - support request

I have issues
I can't get the nodes to join the cluster
I'm submitting a...

[ ] bug report
[ ] feature request
[X ] support request
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
I can't get the node to join the cluster.
kubectl get nodes --watch --kubeconfig kubeconfigXXX
No nodes appear
kubectl get svc --watch --kubeconfig kubeconfig
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   <IP_ADDRESS>           443/TCP   1h
If this is a bug, how to reproduce? Please include a code sample if relevant.
module "eks_cluster" {
source       = "../module/eks"
cluster_name = "${var.cluster_name}"
subnets      = ["${module.eks_vpc.subnet1_id}", "${module.eks_vpc.subnet2_id}", "${module.eks_vpc.subnet3_id}"]
vpc_id       = "${module.eks_vpc.vpc_id}"
manage_aws_auth = true
write_kubeconfig = true
config_output_path = "./"
worker_groups = [
{
instance_type = "m4.large"
asg_max_size  = 5
}
]
tags = {
environment = "test"
}
}
What's the expected behavior?
Nodes return in kubectl
Are you able to fix this problem and submit a PR? Link here if you have already.
Environment details

Affected module version: [v2.1.0] - 2019-01-15]
OS: ubuntu 18.04
Terraform version: 11.11

Any other relevant info
I have everything working via the eks getting started guide cloud formation templates, I compared the deployments and don't see a diff between VPC, cluster, node, IAM.

Are the subnets "${module.eks_vpc.subnet1_id}", "${module.eks_vpc.subnet2_id}", "${module.eks_vpc.subnet3_id}" public? Or have routes to a NAT gateways? Can you post the TF code of the VPC module?
EKS nodes need to access the internet in order to reach the AWS EKS API endpoint.

I tried to do a 1:1 mapping of the cloud formation template flavor for eks.
resource "aws_vpc" "main" {
cidr_block       = "<IP_ADDRESS>/16"
enable_dns_support  =    true
enable_dns_hostnames = true
tags = {
Name = "${var.vpc_name}"
}
}
resource "aws_subnet" "az1" {
vpc_id     = "${aws_vpc.main.id}"
cidr_block = "<IP_ADDRESS>/18"
availability_zone = "${var.region}a"
tags = {
Name = "${var.vpc_name}-az1"
}
}
resource "aws_subnet" "az2" {
vpc_id     = "${aws_vpc.main.id}"
cidr_block = "<IP_ADDRESS>/18"
availability_zone = "${var.region}b"
tags = {
Name = "${var.vpc_name}-az2"
}
}
resource "aws_subnet" "az3" {
vpc_id     = "${aws_vpc.main.id}"
cidr_block = "<IP_ADDRESS>/18"
availability_zone = "${var.region}c"
tags = {
Name = "${var.vpc_name}-az3"
}
}
resource "aws_security_group" "eks_sg" {
name        = "${var.vpc_name} allow"
description = "Allow all inbound traffic"
vpc_id      = "${aws_vpc.main.id}"
ingress {
from_port   = 0
to_port     = 0
protocol    = "-1"
cidr_blocks = ["<IP_ADDRESS>/0"]
}
egress {
from_port       = 0
to_port         = 0
protocol        = "-1"
cidr_blocks     = ["<IP_ADDRESS>/0"]
}
}
resource "aws_internet_gateway" "gw" {
vpc_id = "${aws_vpc.main.id}"
tags = {
Name = "${var.vpc_name}-internet-gateway"
}
}
resource "aws_route_table" "r" {
vpc_id = "${aws_vpc.main.id}"
tags = {
Name = "${var.vpc_name} Public Subnets"
Network = "Public"
}
route {
cidr_block = "<IP_ADDRESS>/0"
gateway_id = "${aws_internet_gateway.gw.id}"
}
}
resource "aws_route_table_association" "a" {
subnet_id      = "${aws_subnet.az1.id}"
route_table_id = "${aws_route_table.r.id}"
}
resource "aws_route_table_association" "b" {
subnet_id      = "${aws_subnet.az2.id}"
route_table_id = "${aws_route_table.r.id}"
}
resource "aws_route_table_association" "c" {
subnet_id      = "${aws_subnet.az3.id}"
route_table_id = "${aws_route_table.r.id}"
}
output "vpc_id" {
description = "The ID of the VPC"
value       = "${aws_vpc.main.id}"
}
output "subnet1_id" {
description = "The ID of the az1 subnet"
value       = "${aws_subnet.az1.id}"
}
output "subnet2_id" {
description = "The ID of the az2 subnet"
value       = "${aws_subnet.az2.id}"
}
output "subnet3_id" {
description = "The ID of the az3 subnet"
value       = "${aws_subnet.az3.id}"
}

Update - the node joined the cluster after added the ssh key pair and public IP...


NTFS permissions give all users read access to everyone's profile

[Enter feedback here]
With a File server and Share you can disable inheritance and set permissions correctly.  Following the instructions in the article all users have read access to everyone's profile.  Which is a data breach.   you can't disable inheritance so can't remove inherited permissions.  This is concerning.  Also, I can't see any documentation to set this up correctly, I have looked at deny assignments but this is also not an option.
A suggestion was to create a custom RBAC role but this wont help with inherited NTFS permissions.

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

ID: 69769604-b1c3-a2b8-318d-354ebf0d82a1
Version Independent ID: 964330fc-1a4f-05ca-502a-a09f26e79f10
Content: Set up FSLogix Profile Container with Azure Files and AD DS or Azure AD DS - Azure Virtual Desktop
Content Source: articles/virtual-desktop/fslogix-profile-container-configure-azure-files-active-directory.md
Service: virtual-desktop
GitHub Login: @dknappettmsft
Microsoft Alias: daknappe

@M4ttLaNE
Thanks for your feedback! We will investigate and update as appropriate.

Thanks for getting back to me,
I have re-applied the NTFS permissions using icicles today and this time the permissions have worked as expected (I did exactly the same yesterday and no permissions were removed even though the DOS cmd was successful) .   Must be a weird AD sync issue or an issue yesterday in Azure. Its all working properly today.  Sorry to waste your time.
Regards Matthew Lane
From: Naveenommi-MSFT @.>
Sent: 09 November 2022 16:07
To: MicrosoftDocs/azure-docs @.>
Cc: Matthew Lane @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] NTFS permissions give all users read access to everyone's profile (Issue #101188)
@M4ttLaNEhttps://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FM4ttLaNE&data=05|01|matthew.lane%40nuneatonandbedworth.gov.uk|1e2e4c9e0e5041da719608dac26c6eb3|5ad55f5de6074e32a7dfa78d524ea7f2|0|0|638036068212110485|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=5JPTp2DjnI9mHWv7zDUoafjvXsdy14tbz98HwOOLkCk%3D&reserved=0
Thanks for your feedback! We will investigate and update as appropriate.

Reply to this email directly, view it on GitHubhttps://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F101188%23issuecomment-1308989526&data=05|01|matthew.lane%40nuneatonandbedworth.gov.uk|1e2e4c9e0e5041da719608dac26c6eb3|5ad55f5de6074e32a7dfa78d524ea7f2|0|0|638036068212110485|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=e4CllnqZ%2FIZhLh5SM4yH%2BEtHbC4Wpjg3W9iPnP%2BJGfs%3D&reserved=0, or unsubscribehttps://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAWTTOG7XCRVBTQ7O7MNP7WTWHPD2FANCNFSM6AAAAAAR3MBGZE&data=05|01|matthew.lane%40nuneatonandbedworth.gov.uk|1e2e4c9e0e5041da719608dac26c6eb3|5ad55f5de6074e32a7dfa78d524ea7f2|0|0|638036068212110485|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=i5n7hSj1O3hqEmo2D1KFr%2FWTYo0gQMGkOMXA9qReVZQ%3D&reserved=0.
You are receiving this because you were mentioned.Message ID: @.***>
DISCLAIMER The information contained in this e-mail is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply e-mail and then delete it from your system. Please do not copy it or use it for any other purposes, or disclose the content of the e-mail to any other person or store or copy the information in any medium. Email traffic may be subject to recording and/or monitoring in accordance with relevant legislation. The views contained in this e-mail are those of the author and not necessarily those of Nuneaton and Bedworth Borough Council. The information contained in this e-mail may be the subject of public disclosure under the Data Protection Act 1998, General Data Protection Regulations 2018, Freedom of Information Act 2000 or the Environmental Information Regulations 2004 - unless legally exempt from disclosure, the confidentiality of this e-mail and your reply cannot be guaranteed. ************************************************************************ This e-mail has been scanned for all viruses

@M4ttLaNE
Thanks for clarification!
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Add new option to prevent setting process.env.NODE_ENV

Clear and concise description of the problem
I want to prevent vitest from setting process.env.NODE_ENV.
Because vite supports setting process.env.NODE_ENV in env files, e.g. .env files. But vite only allows setting when process.env.NODE_ENV is undefined.
I want to prevent vitest set NODE_ENV.
Because vite support process.env.NODE_ENV set in env file, e.g: .env file. but vite only allow to set when process.env.NODE_ENV is undefined
Related code
https://github.com/vitest-dev/vitest/blob/4701e0b9b07728fc64189b655c53708346ac9293/packages/vitest/src/node/cli-api.ts#L18
Related pr:
https://github.com/vitejs/vite/pull/8218
Suggested solution
Add preventSetNodeEnv option, default is false.
Don't set process.env.NODE_ENV when preventSetNodeEnv is true.
Alternative
No response
Additional context
https://github.com/vitejs/vite/pull/8218#discussion_r876491905
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Your examples shows that NODE_ENV is not set, if it was already set. So, what is the problem here?

If it is already set, causing NODE_ENV in the env file to not work.
https://github.com/vitejs/vite/pull/8218/files#diff-11e17761d4ecfee8f8fde15c6d79b7bc0260176396a30dfd8e6f6bbaf5af4745R399

I found the workaround.
We can override process.env.NODE_ENV with the env option.
https://github.com/vitest-dev/vitest/blob/4701e0b9b07728fc64189b655c53708346ac9293/packages/vitest/src/node/cli-api.ts#L35-L36


adding blurry loading

🛠 Fixes Issue (#589)
✅ Check List (Check all the applicable boxes)

[x] My code doesn't break any part of the project (Zero Octave-Javascript-Projects).
[x] This PR does not contain plagiarized content.
[x] My Addition/Changes works properly and matches the overall repo pattern.
[x] The title of my pull request is a short description of the requested changes.

📷 Screenshots

@Astrodevil , please review


Using the programmatic interface can log the wrong port

When calling
var tty = require('tty.js');

var app = tty.createServer({
  shell: 'bash',
}).listen(80, null, function(){});

you get [tty.js] Listening on port 8080. logged, but it is actually listening on port 80.
The reason is that https://github.com/chjj/tty.js/blob/0cee00a7010028dc7f908a921f4161d873f70c17/lib/tty.js#L49 uses self.conf.port but we overrode it with a custom port in the listen call.

In order for this to work properly, you're supposed to change port by adding a "port" attribute inside the config.json file.
By doing it that way, it should also change the message written to the terminal
https://github.com/chjj/tty.js/blob/0cee00a7010028dc7f908a921f4161d873f70c17/lib/config.js#L99

Changing it in the config.json is great if running tty.js directly from the command line, the issue is when calling it from the programmatic interface, for instance you might start multiple tty instances on different ports in order to offer different users or chroots, etc

what about doing it like this? this doesn't work?
var app_one = tty.createServer({"port": "1234"});
var app_two = tty.createServer({"port": "4321"});
you can give each createServer a different config file, no?


Create S3 bucket to store subtitles

@joaomcar once we have a stable version of the algorithm to extract the phrases, I think we should save the message (JSON) on S3 instead of the file, or both. Saving the message would give us the advantage of tracking any issue that might happen when it leaves trivor-subtitles.

S3 bucket created.


Add resource item description

The description of the resource may vary from country to country and needs to be added to the datastore and api outputs

Resource descriptions added and production updated with data and capability to add/edit


InventoryClickEvent error with auto Pagination

Could not pass event InventoryClickEvent to CombatData v1
org.bukkit.event.EventException: null
        at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:319) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at org.bukkit.plugin.SimplePluginManager.fireEvent(SimplePluginManager.java:589) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:576) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.PlayerConnection.a(PlayerConnection.java:2277) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.PacketPlayInWindowClick.a(SourceFile:32) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.PacketPlayInWindowClick.a(SourceFile:10) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.PlayerConnectionUtils.lambda$0(PlayerConnectionUtils.java:19) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.TickTask.run(SourceFile:18) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.executeTask(SourceFile:144) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.IAsyncTaskHandlerReentrant.executeTask(SourceFile:23) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.executeNext(SourceFile:118) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.MinecraftServer.bb(MinecraftServer.java:941) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.MinecraftServer.executeNext(MinecraftServer.java:934) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.IAsyncTaskHandler.awaitTasks(SourceFile:127) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.MinecraftServer.sleepForTick(MinecraftServer.java:918) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.MinecraftServer.w(MinecraftServer.java:850) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at net.minecraft.server.v1_16_R3.MinecraftServer.lambda$0(MinecraftServer.java:164) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        at java.lang.Thread.run(Unknown Source) [?:1.8.0_251]
Caused by: java.lang.NullPointerException
        at com.samjakob.spigui.SGMenu.nextPage(SGMenu.java:443) ~[?:?]
        at com.samjakob.spigui.SpiGUI.lambda$null$2(SpiGUI.java:94) ~[?:?]
        at com.samjakob.spigui.menu.SGMenuListener.onInventoryClick(SGMenuListener.java:64) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_251]
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_251]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_251]
        at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_251]
        at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:315) ~[spigot.jar:git-Spigot-37d799b-3eb7236]
        ... 18 more

This error occurs when moving pages with auto-pagination. Weird because the buttons actually work, and cycle pages properly and the inventory setup also is fine.
I also had a quick performance question:
Right now I'm creating a new SGMenu for every player whenever I need one. I feel as though this could cause performance issues, so I'm curious as to whether or not after the inventory is closed the menu is removed from memory. If I'm just creating a bunch of instances over and over I'd rather just store each SGMenu in a map so I only need one instance for player and can update it as I go.

I'll look into the error now.
Regarding your performance question:
That should be fine as if you don't use the old reference to the inventory after it's closed (i.e. if it's not saved anywhere in a list/map or something), it should be automatically removed from memory by Java's Garbage Collection.
I don't necessarily think it's worth keeping an instance in a map for every player unless it's one inventory per player and they're going to be accessing the inventory a lot because that will prevent the inventories from being collected by GC so you'd be forcing them to stay in memory.

I can't seem to reproduce the issue could you share the following:

how many pages your GUI has
your server version (e.g. Bukkit/Spigot version, Minecraft version)
if possible, some code that produces the error

Closing as this should have been partially resolved by a previous and completely resolved by the latest commit (at time of writing).


hide current page from breadcrumb and added schema html

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix # WRLDBAEMS-372
Test URLs:

Before: https://main--world-bank--aemsites.aem.live/ext/en/who-we-are/leadership/axel-van-trotsenburg
After: https://wrldbeams-372-breadcrumb-changes--world-bank--aemsites.aem.live/ext/en/who-we-are/leadership/axel-van-trotsenburg

@akki761 Noticed some accessibility issues with your PR https://pagespeed.web.dev/analysis/https-wrldbeams-372-breadcrumb-changes--world-bank--aemsites-aem-live-ext-en-who-we-are-leadership-axel-van-trotsenburg/jmicx3u3jg?form_factor=mobile

@mkbansal1 current styles are as per figma. In order to make this change, I need to deviate from figma.


Reduce app's database hits, and refactor

This turns each view into just one or two database queries, instead of one per Job. Hopefully, this'll speed up Moxie in production, and permit us to move all of our Open States jobs there.
:us: :fireworks:
@paultag, let me know what changes I need to make to get this up to snuff! First time using asyncio, so let me know if I've broken any rules or best-practices.

Thowin' a bone to https://github.com/paultag/moxie/issues/67.

Love it. This is awesome. Thank you, @mileswwatkins !

Totally cleans up the code, no changes needed :)

@paultag, when you get a chance, could you let me know how deployment to the Moxie machine works? The plethora of Dockerization therein has me a bit flummoxed, I feel like I'm just missing something :)


TypeScript: rename enum doesn't cascade changes

From @OliverJAsh on September 5, 2016 15:29
Version 2.1.0-dev.20160905
Given:
    enum Foo { Bar }

    type Baz = {
        type: Foo.Bar
    }

    const baz: Baz = { type: Foo.Bar };

When I rename Foo.Bar on line one, it only renames usages of the enum as a value, not as a type.
Expected result (rename to Bob)
    enum Foo { Bob }

    type Baz = {
        type: Foo.Bob
    }

    const baz: Baz = { type: Foo.Bob };

Actual result
    enum Foo { Bob }

    type Baz = {
        type: Foo.Bar
    }

    const baz: Baz = { type: Foo.Bob };

Copied from original issue: Microsoft/vscode#11548

Fixed by #15743.


Average ELO of each team per match

If you go to the match, there is a tab name analysis where you can find the ELO for the team at each match. We can use that instead of computing the average ELO based on the players


Not able to change the requestUrl

Hi,
I am new to swagger and am facing similar problem.
Am using swashbuckle 5.2.2
NugetPackage : Swashbuckle - Swagger for WebApi 5.2.2
The requested URL is always pointing to local host rather than pointing at hosted server.
(refer image )
Is it should be configurable ?
Can you please help me with the same.

Is your API hosted behind a proxy server? If so your issue is a dup of #352


Initial proposal for Zcheri SBI

The rationale for expanding the definition of ASR in this way is given in https://lists.riscv.org/g/sig-cheri/message/68, and that may be a better forum for long discussions of the underlying premise.
The SBI is considered to be in scope on the theory that this repository already contains patches to various specifications that touch CHERI, and the SBI is an expected part of the supervisor execution environment with the same status as ISA specifications.
There is an open question whether a Zcheri_legacy SBI can be implemented in a way which maintains simultaneous upward compatibility with Zcheri_purecap and the non-CHERI base ISA.

I don't think it's useful to spend too much time looking at something as boring as SBI until the ISA is more nailed down. At the end of the day it is just engineering. We have plenty of experience with system calls for CHERI, and SBI calls are just system calls at a different level of the stack.
I'll also note that the whole firmware feature enable situation is stupid and should be under S-mode control without the need to involve firmware.  We can and should do better.


NIFI-3039 Provenance Repository - Fix PurgeOldEvent and Rollover Size Limits (0.x)

Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x ] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x ] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x ] Is your initial contribution a single, squashed commit?

For code changes:

[x ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
NIFI-3039 Provenance Repository - Fix PurgeOldEvent and Rollover Size Limits
Added low water mark for purgeOldEvents() to prevent thrashing on event cleanup.
Adjusted rollover high water mark to match purgeOldEvents() to prevent overrunning "nifi.provenance.repository.max.storage.size".
Moved high/low water marks to constants.
Adjusted looping logic in mergeJournals() to use ".firstKey()" instead of ".entrySet().iterator().next()" to avoid unnecessary object creation.

@jskora  I think you are the only one who can close this PR.  Would you mind?  Thanks!

Overcome by events.


feat: implement EC recover hints

Description
Now that we have tested the full flow of an integration test with hints, we can actually run hints during stepInstruction.
Look through the math hints and math utils files in order to understand the data flow.
For reference, refer to the Rust implementation of the hints and utils.
Implement the accompanying tests.
Acceptance criteria
Add at least two programs that have the EC related hints, and ensure that the integration test passes.
Programs can be taken from here. Follow the README in the Cairo VM in Rust in order to compile the necessary files to json.

assign me

blocked by #432


Unable to deploy the web app using Deploy to IBM Cloud

Hitting with the below error while trying to Deploy the Web App using "Deploy to IBM Cloud"

That error is seen whenever theres any kind of error starting the web app, if you could share the application runtime logs linked in that screenshot, those should give a better idea of the issue you're hitting.

Please find runtime logs below: @ajbozarth

From reading the runtime log it looks like you set the model endpoint to http://<IP_ADDRESS>:5000 when you first created you instance. As stated in the instructions you need to start an instance of the model first then fill in that endpoint in the form. http://<IP_ADDRESS>:5000 is just an example endpoint and won't work itself in IBM Cloud.

I missed that Step in the README.. Thankyou @ajbozarth


Hotfix/cond update mount

Codecov Report

Merging #116 (c8d4b3e) into master (b67d793) will increase coverage by 0.11%.
The diff coverage is 44.44%.

@@            Coverage Diff             @@
##           master     #116      +/-   ##
==========================================
+ Coverage   42.71%   42.82%   +0.11%
==========================================
  Files          34       34
  Lines        4446     4439       -7
==========================================
+ Hits         1899     1901       +2
+ Misses       2547     2538       -9

Impacted Files
Coverage Δ

...mblyline_core/scaler/controllers/kubernetes_ctl.py
14.33% <33.33%> (ø)

assemblyline_core/scaler/scaler_server.py
29.15% <50.00%> (+0.11%)
:arrow_up:

assemblyline_core/scaler/controllers/docker_ctl.py
14.34% <100.00%> (+0.12%)
:arrow_up:

assemblyline_core/ingester/run_ingest.py
77.77% <0.00%> (-0.31%)
:arrow_down:

assemblyline_core/plumber/run_plumber.py
93.33% <0.00%> (-0.22%)
:arrow_down:

assemblyline_core/ingester/ingester.py
79.43% <0.00%> (-0.06%)
:arrow_down:

assemblyline_core/metrics/helper.py
0.00% <0.00%> (ø)

assemblyline_core/updater/run_updater.py
28.57% <0.00%> (+0.07%)
:arrow_up:

assemblyline_core/dispatching/dispatcher.py
79.60% <0.00%> (+0.60%)
: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 b67d793...c8d4b3e. Read the comment docs.


Hermes: Make sure hermes cannot be slowed down by packets to fake chains

If I'm not mistaken, when Hermes catches an IBC transfer to relay, it does the following:

Figure out source channel
Using source channel, query the source chain to get the counterparty's chain-id
Create packets and submit them to counterparty chain

The (potential) issue is that chain-ids are not unique, meaning it is possible for someone to create an IBC connection with a chain-id that is exactly the same as the chain-id of a "real chain". This could potentially be a problem is hermes retries multiple times if header verification fails. Consider the following scenario:

An IBC connection between Cosmos Hub and Akash is open. On Cosmos Hub, the client ID of Akash is client-1 and the chain-id is akash-1.
An attacker creates a fake Akash chain using starport and opens an IBC connection with the Hub. The attacker uses the same chain-id akash-1, only the client-id is different, client-2.

Hermes picks up the packets. It reads the counterparty chain-id for the channel, which gives akash-1.
Hermes then tries to relay the packet to the real Akash chain, but the relaying fails during header verification. Hermes then retries (how many times?).

My questions is: do we have a problem? Can this slow down Hermes significantly?
cc @ancazamfir @romac @andynog

Thanks for the clarification, I understood something different in our discussion.
So I think we can detect this and drop the send packet event early. In step 4 we find the channel end on real akash-1. Then we verify that the counterparty points back to the source_channel_id in the packet event. I looked at the code and I don't think we catch this anywhere. If there is some check it's definitely not where it should be.
I think this should work as (port ID, channel ID) -s  must be unique per chain. In fact on cosmos chains channel IDs alone are unique per chain. Same for connection IDs.
So on the hub the channel ID to the fake akash-1 should be different than the channel ID to the real chain.
Here is an example of the channel, connection and client IDs on the two akash chains
akash-1:
     (channel-10, connection-10, client-10) --> (channel-1, connection-1, client-1)
fake akash-1:
     (channel-10, connection-10, client-10) --> (channel-2, connection-2, client-2)

relayer gets the send_packet event with source_channel_id = channel-2
queries channel-2 and gets the counterparty channel ID, channel-10
gets the hub connection then client from which it figures the counterparty is akash-1
queries the real akash-1 for channel-10
checks the counterparty information of channel-10  against the event source_channel_id.

In this case the check should fail as counterparty of channel-10 on real akash-1 should be channel-1 which does not match the packet's channel-2

hermes should drop the event if the check above fails

Note also that the client updates will not fail in this case as the headers are valid hub headers for a client ID that exists on the real akash-1. With today code we will retry < 10 times.

I didn't know channel-id was unique. Is this something implementation-related, or something specified in the IBC spec. If it's the former, maybe using client-id would be more robust? In any case, the general idea of what you proposed @ancazamfir makes sense. That's what we've implemented in our own backend to verify IBC paths.

Is this something implementation-related, or something specified in the IBC spec.

It is in the  ICS24 IBC spec. There is a table that lists the keys that identify the different objects (e.g. clientState, connectionEnd, channelEnd).
We will add the check I mentioned above and will also look into doing the similar check at connectionEnd and clientState level to see if they add to the security. My concern is that these queries take time. Need to check if we can make use of the little information we cache, otherwise we would have to do more queries for each event/ packet or make a small design change.

BTW, there is a gRPC query implemented in SDK that, given a channel and port ID, retrieves the client data (includes the client ID and state). So it's faster if you don't need connection information.

I can confirm this is a problem.
After recreating the conditions, Hermes will indeed try to relay the packet to the fake chain,
> hermes -c ~/.hermes/config_fake.toml tx raw packet-recv ibc-1 ibc-0 transfer channel-0
...
Jun 08 14:44:49.478 DEBUG ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] packets that still have commitments on ibc-0: [1]
Jun 08 14:44:49.482 DEBUG ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] recv packets to send out to ibc-1 of the ones with commitments on source ibc-0: [Sequence(1)]
Jun 08 14:44:49.485 DEBUG ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] received from query_txs [Sequence(1)]
Jun 08 14:44:49.485  INFO ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] generate messages from batch with 1 events
Jun 08 14:44:49.488 DEBUG ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] ibc-0 => SendPacketEv(SendPacket - h:0-3506, seq:1, path:channel-0/transfer->channel-0/transfer, toh:1-1287, tos:Timestamp(NoTimestamp)))
Jun 08 14:44:49.496 TRACE ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] built recv_packet msg seq:1, path:channel-0/transfer->channel-0/transfer, toh:1-1287, tos:Timestamp(NoTimestamp)), proofs at height 0-3507
Jun 08 14:44:49.496 DEBUG ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] ibc-1 <= /ibc.core.channel.v1.MsgRecvPacket from SendPacketEv(SendPacket - h:0-3506, seq:1, path:channel-0/transfer->channel-0/transfer, toh:1-1287, tos:Timestamp(NoTimestamp)))
Jun 08 14:44:49.496  INFO ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] scheduling op. data with 1 msg(s) for Destination chain (height 0-3507)
Jun 08 14:44:49.496  INFO ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] ready to fetch a scheduled op. data with batch of size 1 targeting Destination
Jun 08 14:44:49.496  INFO ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] relay op. data to Destination, proofs height 0-3506, (delayed by: 47.319µs) [try 1/5]
Jun 08 14:44:49.496  INFO ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] prepending Destination client update @ height 0-3507
Jun 08 14:44:50.543 DEBUG ibc_relayer::foreign_client: [ibc-0 -> ibc-1:07-tendermint-0] MsgUpdateAnyClient for target height 0-3507 and trusted height 0-3368
Jun 08 14:44:50.543  INFO ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] assembled batch of 2 message(s)
Jun 08 14:44:56.321  INFO ibc_relayer::link: [ibc-0:transfer/channel-0 -> ibc-1] result events:
	ChainErrorEv(deliver_tx reports error: log=Log("failed to execute message; message index: 1: receive packet verification failed: packet source channel doesn\'t match the counterparty\'s channel (channel-0 ≠ channel-1): invalid packet"))

As can be seen in the last log line I pasted above, the destination chain, fake ibc-1, rejects the packet on grounds of mismatching source channel (which is the correct behavior to be expected from a chain).
The command hermes -c ~/.hermes/config_fake.toml start encounters the same problem.


add entry for Drupal Watchdog

Fixes #21 by adding an entry for the first issue of the Drupal Watchdog print magazine.

Thanks a lot for the magazine and for this entry 🙇


Fix urlquery

if request url ends up with "?",  requestBySerializingRequest method can't work perfectly. URL.query return "" instead of nil in this case.

Thanks for the PR! However, due to its age it will not be merged. However, if the issue is still occurring feel free to open a new PR.


[Xcode 11] Multiple commands produce....

Hi, please advise a solution:
error: Multiple commands produce '/Users/agmostudio/Library/Developer/Xcode/DerivedData/adsdasdas-agayvqesxbjfpvfwmwvdeqvsxmem/Build/Products/Debug-iphoneos/adsdasdas.app/Assets.car':

Target 'adsdasdas' (project 'adsdasdas') has compile command with input '/Users/aaa/Desktop/Projects/POC/adsdasdas/adsdasdas/Assets.xcassets'
That command depends on command in Target 'adsdasdas' (project 'adsdasdas'): script phase “[CP] Copy Pods Resources”

I added this line at the top of my Podfile, just below the platform statement and it fixed the duplicate assets problem
install! 'cocoapods', :disable_input_output_paths => true
See https://stackoverflow.com/questions/57740477/cant-assign-xcassets-to-the-main-target-on-xcode-11 for discussion


fix: if Cypress env failOnSnapshotDiff is true, isFailOnSnapshotDiff is true

Issue reported here

This just needs the pipeline fixed, looks like ESLint and also the commit message needs to follow conventional commits
Thanks!

Updated! Just needed to change commit message @simonsmith

I'm still seeing an ESLint error though, relating to Prettier. Otherwise looks good

I'm still seeing an ESLint error though, relating to Prettier. Otherwise looks good

There we go, it should be solved now

Thanks for this! Will get it released with some other fixes shortly


RoutingConfig.builder(...).addResource(...) must validate parameter

Root resource classes are "plain old Java objects" (POJOs) that are either annotated with @Path or have at least one method annotated with @Path or a request method designator, such as @GET, @PUT, @POST, or @DELETE.

The addResource methods must throw IllegalArgumentException, when parameter is null or not fit requirements for Root resource classes.
FYI: methods annotated with @Path, but with no HTTP method annotation is Subresource Locator. At the moment the library not support it, so such kind of declaration should be ignored.

done.


Fix for missing escape characters for backslashes

Hi,
I had a problem with SetBytes where setting a value to a UNC path with the backslashes escaped such as "\\\\<IP_ADDRESS>" produces a JSON document with missing slashes, i.e. "\\<IP_ADDRESS>" which once escaped is \<IP_ADDRESS> This was found by using gjson.GetBytes to grab a UNC path and use sjson.SetBytes to write it to a different JSON document. The result was a different number of backslashes between the original document and new document. I also noticed that if the original value is instead "\\\\127.0.01\r" then setBytes produces the correct result.
The fix seems to be to change mustMarshalString so it returns true when a backslash is found as opposed to only if its found at the end of the string. I couldn't think why you would want to marshal the string when the backslash is at the end but not marshal if it appears anywhere else. Please let me know if you can think of a scenario
The change did break a unit test but the unit test seems to be trying to create a field with the name ":\1" which is not a valid JSON name as the \ character is an escape character and can only be followed by ", \, /, b, n, r, t or u.

Just realized there is already a pull request to fix this issue. Feel free to reject this

Thanks for alerting me to the issue.
I merging the previous pull request.


Duplicate Purchase event issue

I am sending through GTM a purchase event using the GA4 client, the event is being received as a single purchase event, but is generating 2 events in Facebook, I have 2 ad accounts but can see the separate requests, but I also see on the console the raw and mapped data, not sure what to do there is only one event on the client, and one event coming into the GTM server but 2 pixel events in Facebook. There is no other code generating a pixel purchase event

Do you send this event on Web container also or only thru server side? (If you have web pixel events might be duplicated) Other users don't have duplication issue. Look like problem with your setup.

In any way we have now deduplication solution for Facebook tag and that's why I close this issue. https://gtm-server.com/how-to-set-up-facebook-event-deduplication-in-google-tag-manager/


You cannot trade with XXX. (50)

Please guys, help me. When i try send weapon, i get the error 50
Error: There was an error sending your trade offer.  Please try again later.You cannot trade with XXX. (50)

#121


Way to interpolate entire array

Is it currently possible to create a new array from the input array transformed with a given interpolation strategy?
If not would it be possible to add such a feature please?

I am not sure what you mean by transformed do you want to resample your data? You can do this with Interp1D::interp_array or the 2D version.


 Delete the others, including these Instructions.
{{cask_file}} represents the cask file you’re submitting/editing (if applicable).
If there’s a checkbox you can’t complete for any reason, that’s OK. Just explain in detail why you weren’t able to do so.

Changes to a cask
Editing an existing cask

[x] Commit message includes cask’s name (and new version, if applicable).
[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.

Found more secure alternatives after improving the detection process for webpages and appcasts.

Thanks!


Update amend add content to reference pages in SDK docs - closes #550

closes #550

Agreed, thanks Mona!


Add Support for Custom Locales via Config Option in Schedule-X

Is your feature request related to a problem? Please describe.
I'm currently using Schedule-X and am finding it inconvenient to add new locales. As it stands, each new locale requires a pull request to the official repository, followed by a waiting period for review and merge. This makes it difficult to add temporary or custom locales efficiently, particularly when quick iterations are needed or when customization is unique to individual implementations.
Describe the solution you'd like
I would like Schedule-X to support a config option that allows users to add or override locale settings dynamically at runtime. For example, this could be accomplished by enabling a locales property within the config. This property would accept an object that defines locale keys and their respective translations, allowing custom locales to be added without modifying the core library or submitting pull requests.
config: {   locale: "MS",   locales: {     "MS": {       Today: 'Today',       Month: 'Month',       Week: 'Week',       Day: 'Day',       'Select View': 'Select View',       events: 'events',       event: 'event',       'No events': 'No events',       'Next period': 'Next period',       'Previous period': 'Previous period',       to: 'to', // as in 2/1/2020 to 2/2/2020       'Full day- and multiple day events': 'Full day- and multiple day events',       'Link to {{n}} more events on {{date}}': 'Link to {{n}} more events on {{date}}',       'Link to 1 more event on {{date}}': 'Link to 1 more event on {{date}}',       Date: 'Date',       'MM/DD/YYYY': 'MM/DD/YYYY',       'Next month': 'Next month',       'Previous month': 'Previous month',       'Choose Date': 'Choose Date',     }   } }
This would allow developers to directly configure and customize locale data as part of their project setup, enhancing flexibility and reducing dependency on the core repository for minor localization adjustments.
Additional context
This feature would be especially beneficial for teams working in multi-lingual environments or for those requiring region-specific terms that aren't universally relevant. Additionally, it could make Schedule-X more adaptable in enterprise settings, where custom localization requirements often need fast implementation.
Things that could speed up the process

[ ] I can picture implementing at least parts of this feature
[ ] I believe I know how to do this, and am willing to implement the whole thing.
[ ] I have a Schedule-X premium license

Thanks for opening this issue. Was having a chat with another user last week, where this would have been one of the two possible solutions. Definitely makes sense to implement, just the way you already suggested


allow page attribute block to use template for attribute

this change has the page attribute block search the templates directory to see if there is a template that matches the selected attribute's handle. If so, this template will be used automatically.
Note: this currently does not work with template in a folder.
Example:
selected attribute handle: my_attribute
works:
/application/blocks/page_attribute_display/templates/my_attribute.php
does not work:
/application/blocks/page_attribute_display/templates/my_attribute/view.php
There have been quite a few times where I have had to create a template for a specific attribute and then select it each time an instance of the block is needed. In my opinion, it would be handy (and reasonably logical) to have a template that matches the selected attribute handle automatically applied if no custom attribute was selected.
I'm not convinced this was the most elegant way to add this functionality (there is likely a way to check for the existence of a block template, but I did not happen across it)
There is the potential that this could be considered a non-backwards compatible change in the case a site has a template which has the same name as the selected attribute handle and it was not intended for them to be used all of the time.

Thanks!


SHACL - sh:hasValue

Support for sh:hasValue.

Initial support complete. Performance could be better.


Improvement - Change HelpWindow

Changes
This PR changes the HelpWindow to show command actions, formats and examples.
The commands are split into pages based on functionality.

Closes

closes #215

Codecov Report

Merging #216 (fdabbaf) into master (2997356) will decrease coverage by 1.42%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #216      +/-   ##
============================================
- Coverage     72.63%   71.21%   -1.43%
- Complexity      997     1024      +27
============================================
  Files           137      141       +4
  Lines          3062     3213     +151
  Branches        350      363      +13
============================================
+ Hits           2224     2288      +64
- Misses          775      861      +86
- Partials         63       64       +1

Impacted Files
Coverage Δ

src/main/java/seedu/contax/ui/HelpWindow.java
0.00% <0.00%> (ø)

.../main/java/seedu/contax/commons/util/DateUtil.java
95.83% <0.00%> (-0.84%)
:arrow_down:

...seedu/contax/storage/JsonSerializableSchedule.java
100.00% <0.00%> (ø)

.../java/seedu/contax/logic/commands/FindCommand.java

...a/seedu/contax/logic/parser/FindCommandParser.java

...va/seedu/contax/logic/parser/AddCommandParser.java

...seedu/contax/logic/parser/DeleteCommandParser.java

...ava/seedu/contax/logic/commands/DeleteCommand.java

.../java/seedu/contax/logic/commands/EditCommand.java

...n/java/seedu/contax/logic/commands/AddCommand.java

... and 16 more

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 2997356...fdabbaf. Read the comment docs.


Preprocess error:  could not open file '/data/uniclust30_2016_03_cs219.ffdata'

Hi!  Thank you so much for this project!  Very excited to go through your instructions.  I have run the preprocess step in docker-compose as you have in your instruction with the following command.  The only difference was:

I used a different PDB cutoff date:  export CUTOFF_DATE=2000-12-31 (maybe there are proteins there, not in Uniclust data?)

docker-compose -f docker/docker-compose.preprocess.yml run --rm -v $DATA_DIR:/data preprocess python -m nanofold.preprocess -m /data/pdb/ -c /preprocess/ -o /preprocess/features.arrow --small_bfd /data/bfd-first_non_consensus_sequences.fasta --pdb70 /data/pdb70/ --uniclust30 /data/uniclust30_2016_03/

It completed, but this error occurred at the last step for many proteins and it also did not write any chains to features.arrow.  Here is an example snippet:
...
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1sos', 'chain_id': 'I'}: CalledProcessError(2, ['/opt/hhsuite/bin/hhblits', '-i', '/tmp/tmp1q785cwf', '-d', '/data/uniclust30_2016_03', '-v', '0', '-cpu', '8', '-n', '3', '-oa3m', '/preprocess/uniclust30_cache/1sos_I.a3m'])
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1sos', 'chain_id': 'E'}: StopIteration()
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1sos', 'chain_id': 'J'}: StopIteration()
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1etz', 'chain_id': 'L'}: StopIteration()
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1etz', 'chain_id': 'H'}: StopIteration()
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1etz', 'chain_id': 'A'}: StopIteration()
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1etz', 'chain_id': 'B'}: StopIteration()
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1fbd', 'chain_id': 'A'}: StopIteration()
2024-05-28 07:15:00 ERROR: Failure while prefetching MSA for chain {'structure_id': '1fbd', 'chain_id': 'B'}: StopIteration()
- 07:15:00.155 ERROR: In /tmp/hhsuite/src/ffindexdatabase.cpp:11: FFindexDatabase:

- 07:15:00.155 ERROR: 	could not open file '/data/uniclust30_2016_03_cs219.ffdata'

2024-05-28 07:15:00 INFO: Building template features
2024-05-28 07:15:00 INFO: Writing features to /preprocess/features.arrow
2024-05-28 07:15:01 INFO: Finished writing 0 chains to /preprocess/features.arrow

My data dir has the following (where pdb, pdb70, and uniclust30_2016_03  are directories):
bfd-first_non_consensus_sequences.fasta  pdb  pdb70  uniclust30_2016_03

Any thoughts?
Thanks again!
PS, the docker-compose commands did not work with sudo for me so had to give my user permission to not use sudo for the docker commands.

Hey, sorry for the late reply - thanks for playing around with this repo and taking a look :)
It's a bit misleading but the --uniclust30 argument is passed directly to the hhblits tool - it is not enough to pass the directory of uniclust30 directory. You instead need to pass --uniclust30 /data/uniclust30_2016_03/uniclust30_2016_03 (and the hhblits tool will expand this prefix into the files it is looking for, for instance /data/uniclust30_2016_03/uniclust30_2016_03_cs219.ffdata).

Hi!  Thanks for your reply and the clarification.  I am trying again this time with the proper paths.  :)  So far it's been running about two days for ~5000 protein structures, but not sure where exactly I'm at (~10k chains is the output).  I have a single machine with 128GB RAM and 20 CPU cores (Intel i5's).  Is there any way to know how long this could run for or could you tell me how long it took for your preprocessing runs?  I might add some logging around time to your code at some point as a PR if you think that would be useful. :) Thanks, take care.

For 50k chains, this step took me about 4 weeks - I was not expecting it to be so long when I started the project! But in my case I had 16GB RAM (actually only 10GB dedicated to WSL) and 4 cores so you should be able to run this a lot faster.
The only issue is I hardcoded some metrics that are optimised for my machine - I am planning to make a change to automatically detect available RAM and CPU cores but for the meantime, could you try the following changes:
https://github.com/ogchen/nanofold/blob/master/nanofold/preprocess/__main__.py#L82 and https://github.com/ogchen/nanofold/blob/master/nanofold/preprocess/main.py#L64
For the hhblits search of uniclust30, I had num_cpu set to 8 and max_workers set to 2, as increasing max_workers would cause my system to run out of memory. Can you set num_cpu to 1, and delete max_workers (it seems like you will have enough RAM that you won't run into memory issues)
Same here: could you delete max_workers (https://github.com/ogchen/nanofold/blob/master/nanofold/preprocess/main.py#L86)

In a similar vein, if you get to training this, the model parameters are set to not exceed 6GB VRAM (https://github.com/ogchen/nanofold/blob/master/config/config.json). If you have more available, you might want to increase some parameters (https://github.com/ogchen/nanofold/blob/master/config/config.alphafold.json contains the parameters defined in the alphafold paper).
Good luck, I'm very invested to see if it works for you!

Thanks again for the great guidance.
A few more questions :)

My preprocess container has stopped without an error as far as I know.  So, where can I find the features.arrow file?
Is there a reason the docker-db-1 mongo DB is still running, but the preprocess container is removed?  I do see the use of --rm.
Do you use docker-ce or some other install of docker?  It seems my docker install may not compatible with the nvidia-container-toolkit so I have to try to install docker-ce I believe from doing some googling (can't load libnvidia-ml.so.1).
Is there a log file that I can check for the outputs from the preprocess container?

Hopefully all completed successfully.  It took 6.5 days, but I may need to rerun with some newer uniclust data perhaps (since in the README we download a 2016 version).


"Daylight saving setting": What does this feature do? How to implement it?

Please provide the details for implementation SDK method or API.

It's quite troublesome to implement this using the existing interface. We will discuss it tomorrow and get back to you as soon as possible

After setting the lock time by SDK, then call the API to update the time zone, then update the lockdata you are using.
SDK:+ (void)setLockTimeWithTimestamp:(long long)timestamp
lockData:(NSString *)lockData
success:(TTSucceedBlock)success
failure:(TTFailedBlock)failure;
note: timestamp =  currentTimeStamp + (currentTimezoneRawOffSet - key.timezoneRawOffset);
currentTimeStamp : The timestamp of the current time (in millisecond)
currentTimezoneRawOffSet：The offset between your time zone and UTC, in millisecond .For example UTC+8 is 28800000.
key.timezoneRawOffset：the lock detail returned by the server interface(https://cnopen.sciener.com/document/doc?urlName=cloud%2Flock%2Fdetail.html)
API :https://euopen.sciener.com/document/doc?urlName=cloud%2Flock%2FchangeTimezoneRawOffsetEn.html


Fix hook errors.

config-changed hook was failing because:

/srv was already created
git was not installed in the container (LXD provider)
String format errors.

Thanks!


feat(article): create the article screen

closes #16
closes #17
closes #18
closes #19

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Have loot tracker track over a login sessions rather than client lifetime

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always
frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've
considered.
Additional context
Add any other context or screenshots about the feature request here.

duplicate of #4671


Incorrectly spelled command in "Contribute to Radicle Garden" section of documentation

Hi! In the following section, there is a mismatch in the commands being specified.
Specifically, $ rad issue show 1 should be $ rad issue show 0.

This can be found here: http://www.radicle.xyz/docs/#installation-setup

Thanks for the feedback @urcades. @jameshaydon fixed the docs


DynamicRealms API

With this PR we add a draw a proposal for DynamicRealm and DynamicObject, two data structures that allow accessing a Realm with type unsafe methods. The main use of this feature would be Migrations, but it has other uses where we could not use a type safe environment, like implementing a database explorer.
This API does not cover implementing a mutable schema.

Superseded by #674


fixes for authorize after security breach Dec 2022

Fixes DCC #682 .
Changes proposed in this PR:

results from a scan of all authorize statements to try fix any further issues after #3084

thanks for cleaning these policies up!


Clean-up/simplify VIP models

Instead of having the interactor request/response models in the Interactor Boundary file they are now with the presenter's ViewModel in the Models file. The basic structure might look like:
struct ListAssets {
    struct FormattedAsset { ... } // model for the viewmodel

    // UC1: Fetch assets using a filter
    struct FetchAssets {
        struct Request {
              let filter: String?
        }

        struct Response {
            let assets: [Asset]?  // <- Example of Domain Entity getting passed to the presenter
        }

        struct ViewModel {
            let assets: [FormattedAsset]?
         }
    }

    // UC2: Fetch User's Favourite Assets
    struct FetchFavouriteAssets {

        struct Response {
            let assets: [Asset]?
        }

        struct ViewModel {
            let assets: [FormattedAsset]?
         }
    }
}

Not merging until everyone has had a chance to review.

👍


Header flickers on Android

Hey! First, this component is absolutely great. Thank you for sharing it.
I'm having a little issue, in Android devices the header flickers when scrolling, it's like it has a little delay when adjusting position. Anyone having the same issue and any ideas if we can solve it?

@juanmiret Hi, thanks!
Can you provide your Android device and version. And which lib's version do you use ?

I'm testing in an Nexus 4 emulator with android 7.1.1 and in a Moto G real device with android 6.0 and in both cases the flickering is present when you scroll. I'm using the latest release from NPM, i think it is 1.3.2
This is the code where I use the component
Some notes before:

If header background color isn't a passed prop but 'rgba(0,0,0,1)' the flicker is present anyway

If headerHeight isn't variable between platforms but is of a fixed height, let's say 54px, the flicker is present anyway

`import React from 'react'
import { View, StyleSheet, Platform, TouchableWithoutFeedback, Image } from 'react-native'
import ParallaxScroll from '@monterosa/react-native-parallax-scroll';
const PublicationLayout = ({ backgroundImageSource, onForegroundPress, children, backgroundColor }) => (
<View style={[ styles.publication, { backgroundColor }]}>
<ParallaxScroll
parallaxHeight={300}
headerHeight={Platform.OS == 'ios' ? 64 : 54}
isHeaderFixed={true}
isForegroundTouchable={true}
fadeOutParallaxForeground={true}
fadeOutParallaxBackground={true}
parallaxBackgroundScrollSpeed={5}
parallaxForegroundScrollSpeed={1}
headerFixedBackgroundColor={backgroundColor}
headerBackgroundColor='rgba(0,0,0,0.3)'
renderParallaxBackground={() => (

)}
renderParallaxForeground={() => (

)}
renderHeader={() => }
>
{children}

)
const styles = StyleSheet.create({
publication: {
flex: 1,
overflow: 'hidden'
},
header: {
height: Platform.OS == 'ios' ? 64 : 54,
paddingTop: Platform.OS == 'ios' ? 20 : 0,
},
backgroundImage: {
position: 'absolute',
top: 0,
left: 0,
right: 0,
bottom: 0,
},
foreground: {
height: 300,
alignItems: 'center',
justifyContent: 'center'
},
})
export default PublicationLayout`

@juanmiret thanks! I will try to find some solution!

@juanmiret Hi. I just tried to reproduce your problem and everything looks fine for me.
I used folowing devices: Sony Xperia Z5(Android 7.1), Samsung Galaxy Tab 2(Android 5.0), Samsung Galaxy S7 edge (Android 7.0), Asus Nexus 7(Android 6.0).
Can you ensure that you use latest version of the library? Because this problem was in the previous versions of library.


Fix ghetto for loop

Hi there,
Was just looking through the breakpoints file and noticed a comment that said "Ghetto For Loop".  I took a look at it and cleaned it up a bit.  Hope you can use it :)

Great PR!

That's awesome.  I've never had a PR merged before.  I'm so excited :)


Is there any way to show the date till yesterday in DatePicker window?

I wanted to show the date till yesterday with time 00:00:00 in Date and Time Picker window. I didn't find any proper way to get it done, so any ideas or suggestions please??

Hey!
Under the hood react-native-modal-datetime-picker uses react-native original DatePickerAndroid, TimePickerAndroid and DatePickerIOS.
This means that if your feature is not supported by these components you won't be able to use it with react-native-datetime-picker 🙍


Add TN / Trento province for ITALY

Hi, I'd like to point out that the Trento (TN) province for Italy is missing from known provinces. Its patron saint holiday is on the 26th of june.

Hi, thank you!
I've just released this update on the beta branch.
Cheers!


feat: add test handlers for ctx set/get

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