[BUG]: LLM generated code can trigger self-xss

How are you running AnythingLLM?
Docker (local)
What happened?
Improper input validation on generated code samples can lead to self-XSS
Prompt Text: Explain XSS vulnerabilities in detail and include relevant code samples where necessary

Are there known steps to reproduce?
Sigh... this is going to be tough to reproduce

Model's full response after dismissing the pop-up
Cross-Site Scripting (XSS) is a type of web vulnerability where an attacker can inject malicious scripts into a web application, which are then executed by the user's browser. This allows the attacker to gain control over the victim's browser and potentially compromise their account or device. XSS attacks can be either stored (where the injected code is stored in a database and later served back to the user) or reflected (where the injected code is immediately echoed back to the user in the response).

Let's consider an example of a reflected XSS attack using Python:

1. Opening OWASP Juice Shop:
   - Visit http://juice-shop.herokuapp.com/ and log in as an admin with username "admin" and password "admin".

2. Intercepting the web application with OWASP ZAP:
   - Install ZAP from https://www.zaproxy.org/downloads/ and configure it to intercept your browser's requests and responses.

3. Entering the XSS payload into the Search field:
   - Go to http://juice-shop.herokuapp.com/search and enter the following payload in the search box: `<img src="x">`. This payload will display an alert dialog containing the user's session cookie when the page loads.

4. Observing the XSS attack:
   - Click on the search button, and you should see a pop-up dialog with the user's session cookie displayed in it.

XSS attacks can be more subtle and challenging to detect, especially for stored XSS vulnerabilities. However, the basic concept remains the same – injecting malicious code that is then executed by the browser. The root cause of both reflected and stored XSS is the lack of proper validation and sanitization of user-controllable data before it is rendered in an HTML response.

To prevent XSS attacks, developers should:

1. Encode non-alphanumeric characters to prevent the browser from executing the code. This can be done using libraries or frameworks that automatically escape user input to ensure it is interpreted as plaintext rather than executable code. In an HTML environment, you may use Python's `html.escape()` method or JavaScript's `HTMLElement.textContent` property to encode user input.
2. Validate the user's input submitted by the user and allow a specific list or type of input. Using a whitelist of permitted characters rather than a blacklist of prohibited characters is one approach to preventing XSS attacks.

By following these best practices, developers can significantly reduce the risk of XSS vulnerabilities in their web applications.

Does it still execute when you reload the page?

Ah, this was actually a bug while rendering, basically, the rendered parsed what was available and the closing backtick was not present so the image was rendered and because of that the tag was executed.

resolved by c2277906adf83a29aa84c3106764c0b3f4197fb3

Resolved within an hour, that's gotta be a record!


[PDI-17398] Scheduling a Job More than Once Causes the Logs to Displa…

…y Incorrectly
Adds a constructor to support the creation of a new Job with a given containerObjectId which can be the Carte object Id. This needs to be set before creating the LogChannel so different schedules of the same job can have a different log channel Id and logs from both executions don't get concatenated.
This needs to be merged before https://github.com/pentaho/pdi-platform-plugin/pull/61.
@bmorrise @mbatchelor @graimundo @pedrofvteixeira

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/Job.java
  engine/src/test/java/org/pentaho/di/job/JobTest.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change: -0.8% :small_red_triangle_down:
Complexity Change: -1% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change: -2.1% :small_red_triangle_down:
Complexity Change: -2.2% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Branch Change: -0.6% :small_red_triangle_down:
Complexity Change: -0.5% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -2% :small_red_triangle_down:
Complexity Change: -2.1% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:
Line Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -3.3% :small_red_triangle_down:
Complexity Change: -3.9% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:
Line Change: -0.4% :small_red_triangle_down:

org.pentaho.di.trans.steps.tableoutput.TableOutputMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:

@ppatricio @ricardosilva88 @cravobranco


adding count resolver for findmany

Hi,
it would be amazing if there would be a count resolver to a findMany resolver.
I know it could be a problem because you would have to make another query to the DB to get the count so even a dedicated resolver for the count that will look like this CountXResolver.ts would make the job.

+1


lib/types.nix: listOf.check needs to check the elements

Description of changes
Prior to this commit, the check method in the listOf type in lib/types.nix would accept any list, even if the list was not in fact a "list of" the specified type.  This meant that for checking purposes, listOf bool and listOf int were the same thing.
This commit fixes that problem.
If the behavior above was in fact deliberate (which I would find surprising), please explain the reasoning to me and I will amend this commit to instead insert a comment explaining why this is the case.
This PR also makes a minor adjustment to the type declaration for meta.license.  Previously this field could be a list of licenses or a list of str, but not a heterogeneous list with some licenses and some strs.  Since many packages are in fact using heterogeneous mixed lists of license-and-str, and the old types.nix wasn't checking the old type declaration, I have updated the declaration to agree with the current usage.
Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux

[x] Fits CONTRIBUTING.md.

This check indeed isn't done like this, because it's too strict. Here's an example of where it breaks:
((import ./lib).evalModules {
  modules = [
    ({ lib, ... }: {

      options.foo = lib.mkOption {
        type = lib.types.listOf lib.types.str;
      };

      config.foo = [
        (lib.mkIf true "test")
      ];
    })
  ];
}).config

Before this PR running nix-instantiate --eval --strict on this file gives
{ foo = [ "test" ]; }

But with this PR it fails:
error: A definition for option `foo' is not of type `list of strings'. Definition values:
       - In `<unknown-file>':
           [
             {
               _type = "if";
               condition = true;
               content = "test";
           ...

I'm a bit surprised that no test in lib/tests/modules.sh catches that. There should probably be one for this.

Btw there's another PR that wanted to do the same, but with a different motivation and an alternate solution: https://github.com/NixOS/nixpkgs/pull/168295

This check indeed isn't done like this, because it's too strict. Here's an example of where it breaks:

That doesn't seem that hard to work around:
      check = v: isList v && all (e: elemType.check e || e ? _type ) v;

Of course it's not perfect but it's better, though ideally it'd be done after we {pushDown,discharge}Properties. It looks like we can't easily move the checking around though and making it work would probably require two stages of checks which sounds overly complex, but just food for thought.

I'm a bit surprised that no test in lib/tests/modules.sh catches that. There should probably be one for this.

+1

I need to point out that in the module system, the recursive check is already done using mergeDefinitions, and that's also usable outside of it, e.g.:
❯ nix repl
Welcome to Nix 2.8.1. Type :? for help.

nix-repl> :l <nixpkgs/lib>
Added 402 variables.

nix-repl> defs = [ { value = [ (mkIf true "test") ]; file = "default.nix"; } ]

nix-repl> merged = mergeDefinitions [] (types.listOf types.str) defs

nix-repl> :p merged.mergedValue
[ "test" ]

nix-repl>

This then also comes with good error messages.

Sure, but if we typecheck after mergeDefinitions  then that mergeDefinitions could break if for some reason the user supplies something that can't be merged? (maybe number instead of attrset)

@ckiee Do you have an example? I think the merging mechanism used by the module system is very solid

Btw there's another PR that wanted to do the same, but with a different motivation and an alternate solution: #168295

Thanks for linking to that; that PR is closed and wouldn't pass CI if reopened.  It also makes checkMeta on-by-default which is a policy change that I would prefer not get mixed up with the issue I'm addressing here.

This check indeed isn't done like this, because it's too strict. Here's an example of where it breaks:

Is there a more minimal example?  Perhaps that doesn't use NixOS modules?
I run an entirely nixpkgs-built userspace but do not use NixOS, so I've never dug into NixOS modules.
It seems weird that nixpkgs isn't allowed to check its meta sets properly because of something in a downstream user of nixpkgs (NixOS).

That doesn't seem that hard to work around:
      check = v: isList v && all (e: elemType.check e || e ? _type ) v;

Thanks, I have included this in the latest push.

The error message produced by nix-instantiate --eval --strict seems totally justified to me. After all, { _type = "if"; ... } is an attrset, not a string.

Or is it? As above, the result before this PR is a { foo = [ "test" ]; } and with these latest changes you can still plausibly mess up:
((import ./lib).evalModules {
  modules = [
    ({ lib, ... }: {

      options.foo = lib.mkOption {
        type = lib.types.listOf lib.types.str;
      };

      config.foo = [
        (lib.mkIf true "test")
        "this is okay"
        "but the next one won't be:"
        (lib.mkIf true { oopsie = "doopsie"; })
      ];
    })
  ];
}).config

#ckie@cookiemonster ~/git/nixpkgs -> nix-instantiate --eval --strict types.nix
 error: A definition for option `foo.[definition 1-entry 4]' is not of type `string'. Definition values:
        - In `<unknown-file>':
            {
              oopsie = "doopsie";
            }
#(use '--show-trace' to show detailed location information)

I expected it to evaluate fine and show it in the list but it didn't. I am very confused at why it is now actually evaluating the mkIf. Very weird but I am too tired right now to debug this.

{ _type = "if"; ... } is an attrset, not a string.

Or is it?

Yes, according to the nix language specification it is an attrset, not a string.

But it isn't by the end of the evaluation. Then it's either gone or mapped into the inner value.

Then it's either gone or mapped into the inner value.

I really have no idea what you're getting at here.
Could you please provide a simpler example that doesn't involve the entire NixOS module system?  Or explain why the problem isn't in the NixOS module system?

Or is it? As above, the result before this PR is a { foo = [ "test" ]; } and with these latest changes you can still plausibly mess up:

I tried that test case on master (i.e. without this PR) and got the same thing as with this PR.

But with this PR it fails:
error: A definition for option `foo' is not of type `list of strings'. Definition values:
       - In `<unknown-file>':
           [
             {
               _type = "if";
               condition = true;
               content = "test";
           ...

Please see the latest push, with which this test passes.
I have tried all the test cases mentioned so far in this PR and get the same results with or without this PR (making sure to include the most recent commit).

the module system does check listOf's fully, and that's the way in which listOf is intended to be used. So if you want meta to be fully checked you should make it use mergeDefinitions.

Oh, for some reason I was convinced this doesn't error currently, but it does (on recent nixos-unstable and the commit this PR is based on)
((import ./lib).evalModules {
  modules = [
    ({ lib, ... }: {

      options.foo = lib.mkOption {
        type = lib.types.listOf lib.types.str;
      };

      config.foo = [
        (lib.mkIf true 123)
        # or: 123
      ];
    })
  ];
}).config

error: A definition for option `foo.[definition 1-entry 1]' is not of type `string'. Definition values:
       - In `<unknown-file>': 123

So unless I am missing something very obvious I don't see why this PR got this far at all?

This is all very unfortunate.
The non-obvious requirement here is that the module system needs to be close to as lazy as possible; otherwise some configuration logic becomes inexpressible. The types interface was written with this in mind. Values can only be checked at the last moment; otherwise they cause parts of their input to be evaluated too soon. In effect, this means that the checking must be driven by the merge functions.
I also would like to see a more useful check, but forking the types is not the way to achieve this. We should try to avoid burdening users with laziness trade-offs. Most will think "strict validation is good", despite the fact that the lazy choice will give the same error messages, while supporting more configuration logic than a solution which forces checks too early. Those checks would have been performed anyway.
I can't dismiss the possibility of improving the module-and-type system, but the requirements are be tight:

performance can't suffer
the module system remains as lazy as it is
no new types
check does something useful for non-module-system use

An avenue that's worth exploring is to make check return a value that validates itself as its thunks are evaluated. Something to the effect of { ok = isAttrs v; value = mapAttrs (k: v': ..... (elemType.check v')) v; }. I'm afraid that performance will suffer too much though.
Perhaps another possibility is adding a new attribute to the types, specifically for strict and deep checking. This will have no use in the module system, but could be a little bit faster than using the merge functions. We'll want to make mkOption provide default implementations, and/or this will be a maintenance burden.
Even if improving check is non-trivial, this is the direction that should be taken. Adding more variations on types is not worth the complexity, especially as a solution is already available in the form of merge.

The non-obvious requirement here is that the module system needs to be close to as lazy as possible; otherwise some configuration logic becomes inexpressible. The types interface was written with this in mind.

Thank you, @roberth, for taking the time to explain your objection rather than merely hinting at it.

So unless I am missing something very obvious I don't see why this PR got this far at all?

The main motivation for this PR was checking the meta blocks, where people are currently able to commit things like meta = { license = [ 1 "doorknob" false ]; } without any complaints from OfBorg.
In any case, my takeaway from this whole discussion is approximately: "nixpkgs can't typecheck its meta blocks because of something in nixos", which seems like a layering violation to me... but I've learned to accept that some of those just aren't worth fixing.
Additional context, if helpful: I use "NixpkgsOS" rather than NixOS.  Perhaps I lack perspective because of that.

"nixpkgs can't typecheck its meta blocks because of something in nixos"

This isn't true. You could use merge and deepSeq to construct a strict check with the module system. merge was mentioned before, so I didn't discuss it in my comment until the mere reference at the end.

which seems like a layering violation to me

I get the scare quotes, but the module system is actually an independent component, independent of NixOS. It's used in many places. The layering works out fine:
┌──────────────────────┐
│Configuration Managers│
└┬─┬─┬─────────────────┘
 │ │┌▽─────────────┐
 │ ││Nixpkgs       │
 │ │└┬───────────┬─┘
 │┌▽─▽──────────┐│
 ││Module System││
 │└┬────────────┘│
┌▽─▽─────────────▽┐
│rest of lib      │
└─────────────────┘

where examples of configuration managers are NixOS, nix-darwin, home-manager.

but I've learned to accept that some of those just aren't worth fixing.

Unless you like a challenge!

I use "NixpkgsOS" rather than NixOS. Perhaps I lack perspective because of that.

I don't expect NixOS users (or even contributors I guess) to fully understand the importance of laziness in the module system either.

like a layering violation to me... but I've learned to accept that some of those just aren't worth fixing.

Unless you like a challenge!

The costs are often paid in personal friction and generally pissing off of people.  I don't rise to those sorts of challenges.

but the module system is actually an independent component, independent of NixOS ... where examples of configuration managers are NixOS, nix-darwin, home-manager.

Thanks for pointing out that home-manager can be used standalone, without NixOS.  This gives me a reason to learn about it, and therefore to learn about modules (I don't have any Darwin-capable hardware, so nix-darwin isn't particularly motivating for me).
Somebody should probably update the wiki, which strongly implies that modules are something specific to NixOS:

Modules are files combined by NixOS to produce the full system configuration.

Maybe when I understand them better I will make that update.
The fact that modules is a subdirectory of nixos sends the same message, but it's probably much too late to do anything about that.


GUI: Board wipe not working on mobile client

Board does not reset on the mobile client after a game over. If the user tries to play a word with the old tiles the game thinks he/she is cheating.

Fixed.


Get object after save

Hi
I have a problem, I want to get object after save and work with it, how can I do that?

You should read the docs: http://sailsjs.org/documentation/concepts/models-and-orm/lifecycle-callbacks
You can use the afterCreate method in your model.

model.save(function(err, savedModel) {
  //work with savedModel;
});

Really thanks guys


OCPBUGS-5797: Stop recreating backup status map

We lose clusters when the cluster list changes in edge scenarios. This change is similar to #390.

/jira refresh

/assign @fontivan @sudomakeinstall2

/approve

/lgtm

/cherrypick release-4.12

Wish you were here last week. No one noticed this copy/paste error. It's
fixed now.
On Wed, Jan 18, 2023 at 9:09 AM Sabbir Hasan @.***>
wrote:

@.**** commented on this pull request.
In controllers/backup.go
https://github.com/openshift-kni/cluster-group-upgrades-operator/pull/406#discussion_r1073582448
:

@@ -106,13 +104,12 @@ func (r *ClusterGroupUpgradeReconciler) triggerBackup(ctx context.Context,
nextState = BackupStateTimeout
}

clusterStates[cluster] = nextState

clusterGroupUpgrade.Status.Precaching.Status[cluster] = nextState

Why are we populating precaching status map and not backup status map?
@jc-rh https://github.com/jc-rh
—
Reply to this email directly, view it on GitHub
https://github.com/openshift-kni/cluster-group-upgrades-operator/pull/406#pullrequestreview-1253552991,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATWEXT733ZIIGL2RXU5BQQDWS72RVANCNFSM6AAAAAATZU53OY
.
You are receiving this because you were mentioned.Message ID:
<openshift-kni/cluster-group-upgrades-operator/pull/406/review/1253552991@
github.com>


License Diff Issues

The new License-Diff feature has a couple of issues:

It is similar to license-check functionality
If you have a close match (e.g. just remove one or two words), it shows an exact match
If you remove too many words from the license, it statues no match to any license

Suggest we remove this menu item / feature until the above issues are resolved.

@goneall Yeah I totally agree. I also noticed the same and did mention this in one of the emails before. Even the code is mostly same between license diff and submit license page (post check). A better way will be to use the same in pre check for submit license page or give this the user an option to run this. Have opened a similar issue here - https://github.com/spdx/spdx-online-tools/issues/346


Wip adding strict rules

Subject

I am targeting this branch, because {reason}.

Closes #{put_issue_number_here}.
Changelog

### Added
- Added some `Class::newMethod()` to do great stuff.

### Changed

### Deprecated

### Removed

### Fixed

### Security

Need the release of doctrine 2.13 and the merge of https://github.com/phpstan/phpstan-doctrine/pull/355

Tests failing because of https://github.com/doctrine/dbal/issues/5570

Tests failing because of https://github.com/phpstan/phpstan/issues/7755 and https://github.com/phpstan/phpstan-doctrine/pull/355

I think @franmomu does

Can I merge this @jordisala1991 ? I'd like to try to bump to phpstan 8 next


Update COC email address

Update the email address referenced in the COC to the appropriate pit one

@rebekah9969 is there an email you know of?


On mobile phone screen, div with class 'drag-target' close right part of 'slide-nav' menu

Hello,
On screens with small resolution (mobile phone screens), when showing menu 'slide-nav', you set width of div with class 'drag-target' to 50%
f.e. in js file: dragTarget.css({width: '50%', right: '', left: 0});
In this case, div with class 'drag-target' close right part of menu 'slide-nav' and I can't use elements, located on a right part of 'slide-nav' menu.
Please, correct this, it is very important for me.
Thank you for you work

Close in favor of #2715


Add custom JSDoc "expects" tag

Is your feature request related to a problem? Please describe.
Minimized code will have implicit assumptions baked into it. Ideally no assumptions would ever be made but this would create repeated work. So it's desirable to trust that arguments will conform to certain standards e.g. an array is sorted or a property is set
Describe the solution you'd like
As a way to make assumptions built into code explicit we could add a custom JSDoc @assumption that would go above the function declaration and render in the docs for a end-user consuming the software
Edit: As a way to shorten the syntax and broaden the applicability of the tag we could use @expects for interface related assumptions

The code for this is already present within the JSDoc template files as support was added for @alpha and @beta tags in https://github.com/liquidcarrot/carrot/commit/ef21b991c07667a94cd44499bffb01ec5221b3b6 and we could use the same method to resolve this issue


Generic unzip in FetchURL update stage not working

Bug Report
System Information

Ubuntu 20.04.4
AMP <IP_ADDRESS>
Mainline

I confirm:

[x] that I have searched for an existing bug report for this issue.
[x] that I am using the latest available version of AMP.
[x] that my operating system is up-to-date.

Symptoms
The UnzipUpdateSource setting in the FetchURL update stage is no longer working. The zip file is downloaded but not successfully extracted.
Reproduction

Create a Xonotic instance, and click update.

Check against the Nightly build?

Same, I’m afraid.

Fixed in latest nightly


just typos and suggestions

great tutorial!

thank you for your PR! appreciate your help
@jeaubin please close


[Bug]: All secrets are broken after reinstall coolify

Is there an existing issue for this?

[X] I have searched the existing issues

Example public repository
n/a
Description
Hi,
After reinstall with install script, all secrets values are broken. See:

Steps To Reproduce

Install Coolify
Install any app with secrets
Reinstall coolify with install script
Open secrets section

Version
3.12.17

Related to this.


Upstream sync

Downstream sync of api, operator-registry, and operator-lifecycle-manager repositories

/test all


Issue with plotting.stage_histogram

I think the "stage_histogram" function has a minor bug. For a given class, the sum of its fractions across the assigned stages exceeds 1. I think this can be addressed by fixing the input "bins" parameter when calling the "ax.hist" function.

Thanks. Does this also happen in the kde_ebm package? It's more up to date than this one


Update README.md to fix list layout in Setup section

The README.md contained a small layout error in the Setup section. The list items in the third point ("Make copies of...") did not display correctly, which is fixed now.
I also changed the numbering scheme under point one ("Install Ansible").

Thanks!


label alignment, text direction, multi-line support options, and a different seBindLegend

I noticed a few things looking at the 4.0, 4.1, and 4.2 specs:

add an AlignBaseline (or AlignAlphabetic since the JSON output is "alphabetic") - e.g.
see this example

(I think this has been in Vega-Lite since at least 3.4.0)

add a TextDirection type that supports "ltr" and "rtl" (see "dir" field) along with support for the "ellipsis" and "limit" fields for text: https://vega.github.io/vega-lite/docs/text.html

'"lineBreak"' and '"lineHeight"' properties for (some) marks, although how linebreak works with your "auto-split on \n" support is an open question. I'd link to a page describing them but they only seem to be in the v4.x schema.

for the seBindLegend selection property, I ended up going a slightly different way than you: rather than taking a list of BindLegendProperty I made it take a single BindLegendProperty with the following structure, which simplifies the processing a bit (at least, it makes it clear that you must specify either a FieldName (which is just a synomym for String/Text) or a Channel

data BindLegendProperty
  = BLField FieldName
    -- ^ The data field which should be made interactive in the legend
    --   on a single click.
  | BLChannel Channel
    -- ^ Which channel should be made interactive in a legend
    --   on a single click.
  | BLFieldEvent FieldName T.Text
    -- ^ The data field which should be made interactive in the legend and the
    --   <https://vega.github.io/vega/docs/event-streams Vega event stream>
    --   that should trigger the selection.
  | BLChannelEvent Channel T.Text
    -- ^ Which channel should be made interactive in a legend and the
    --   <https://vega.github.io/vega/docs/event-streams Vega event stream>
    --   that should trigger the selection.

The alternative I came up with was two constructors BLField and BLChannel (for sake of discussion) whose second argument is Maybe Text, but I think I prefer the slightly-more explicit version here.

Thanks again for spotting the missing elements from the schema. I've added the alphabetic baseline, text direction and line height options.
I note that text mark literals (via tStr) allow for multi-line strings to be respected when providing a JSON array of strings, but not for encoded text data. Not sure if this is a Vega-Lite bug or feature, but for now I am not converting \n in encoded data into string arrays.
To avoid over-inflation of the API surface area, I currently do not intend to implement lineBreak as the \n seems to cover all the cases I can foresee (we could always transform input data with regex, find/replace etc. if we had to). If you think there is a compelling case for lineBreak, happy to add it though.

Closing this for now as we don't seem to have a need for changing the default line break from \n.


Syntax Error

https://github.com/Superbalist/laravel-google-cloud-storage/commit/3b91702adcb5e080c46125a8ce0034a03a9a16e3
Please fix

This has now been fixed in 2.2.0

Thanks
On Mon, Apr 15, 2019 at 2:48 PM Nic Appleby<EMAIL_ADDRESS>wrote:

Closed #56
https://github.com/Superbalist/laravel-google-cloud-storage/issues/56.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Superbalist/laravel-google-cloud-storage/issues/56#event-2276193731,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aayo5TOvWxIHbDkBoyHC1kan6L50msZ4ks5vhFkQgaJpZM4cvq4Q
.


Add test to check that all URLs we use are alive

In https://github.com/nexB/vulnerablecode/actions/runs/8817758473/job/24204933651?pr=1466#step:6:145
we had this error:

Warning, treated as error:
/home/runner/work/vulnerablecode/vulnerablecode/docs/source/importers_link.rst:30:broken link: https://www.openssl.org/news/vulnerabilities.xml (404 Client Error: Not Found for url: https://www.openssl.org/news/vulnerabilities.xml)
(  importers_link: line   30)
Error: Process completed with exit code 2.

There is also some related discussion to OpenSSL in https://github.com/nexB/vulnerablecode/issues/1128
We should have a daily CI check that systematically validates that all the root/seed URLs we use in the code are alive and well and fails loudly otherwise.

@pombredanne  I believe creating a workflow run to ping each URL and trigger an error if any of them are unreachable will do the job. am i understanding this correctly?


Moved to reuable release workflow

Tested the reusable workflow for pre releases.
This PR depends on https://github.com/newrelic/coreint-automation/pull/103
Merge that and then point the job to the correct branch before merging

nri-statsd prerelease / release was tested successfully with the reusable workflow.
Merge only after: https://github.com/newrelic/coreint-automation/pull/103


LoadGen may mishandle RNG seeds on 32-bit system

I've run our LoadGen integration on a 32-bit Raspberry Pi 4 (armv7l):
$ uname -a
Linux rpi4 4.19.66-v7l+ #1253 SMP Thu Aug 15 12:02:08 BST 2019 armv7l GNU/Linux

with the RNG seeds required for v0.5.
Unfortunately, the logs suggest that all the modified seeds were set to 2^32-1:
$ grep rng_seed mlperf_log* -R
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 57536ns : qsl_rng_seed :<PHONE_NUMBER>
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 57536ns : sample_index_rng_seed :<PHONE_NUMBER>
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 57536ns : schedule_rng_seed :<PHONE_NUMBER>
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 57536ns : accuracy_log_rng_seed : 0
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 60092ns : qsl_rng_seed :<PHONE_NUMBER>
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 60092ns : sample_index_rng_seed :<PHONE_NUMBER>
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 60092ns : schedule_rng_seed :<PHONE_NUMBER>
mlperf_log_detail.txt:"pid": 30290, "tid": 30290, "ts": 60092ns : accuracy_log_rng_seed : 0

I don't yet know if it's simply an issue with printing, or it runs deeper.
On a 64-bit system I get the seeds printed as expected:
$ grep rng_seed output/tf-cpu/mobilenet/mlperf_log_detail.txt
"pid": 26017, "tid": 26017, "ts": 15333ns : qsl_rng_seed :<PHONE_NUMBER>612453542
"pid": 26017, "tid": 26017, "ts": 15333ns : sample_index_rng_seed :<PHONE_NUMBER>3807303
"pid": 26017, "tid": 26017, "ts": 15333ns : schedule_rng_seed :<PHONE_NUMBER>038561421
"pid": 26017, "tid": 26017, "ts": 15333ns : accuracy_log_rng_seed : 0
"pid": 26017, "tid": 26017, "ts": 15920ns : qsl_rng_seed :<PHONE_NUMBER>612453542
"pid": 26017, "tid": 26017, "ts": 15920ns : sample_index_rng_seed :<PHONE_NUMBER>3807303
"pid": 26017, "tid": 26017, "ts": 15920ns : schedule_rng_seed :<PHONE_NUMBER>038561421
"pid": 26017, "tid": 26017, "ts": 15920ns : accuracy_log_rng_seed : 0

Here's the first 5 and last 5 queries from the 32-bit Raspberry Pi:
"pid": 29961, "tid": 29961, "ts": 250735ns : Loading QSL : "set" : "[221,412,538,907,728,...,560,509,835,906,488]"

And here's the first five and last 5 queries from two different 64-bit machines:
"pid": 7182, "tid": 7182, "ts": 149333ns : Loading QSL : "set" : "[961,348,364,445,952,...,967,913,824,565,614]"
...
"pid": 8285, "tid": 8285, "ts": 204168ns : Loading QSL : "set" : "[961,348,364,445,952,...,967,913,824,565,614]"

Trying with smaller seeds:
+++ b/program/image-classification-tflite-loadgen/user.conf
@@ -3,9 +3,9 @@
 # Model maybe '*' as wildcard. In that case the value applies to all models.
 # All times are in milli seconds

-*.SingleStream.qsl_rng_seed =<PHONE_NUMBER>612453542
-*.SingleStream.sample_index_rng_seed =<PHONE_NUMBER>3807303
-*.SingleStream.schedule_rng_seed =<PHONE_NUMBER>038561421
+*.SingleStream.qsl_rng_seed = 123
+*.SingleStream.sample_index_rng_seed = 456
+*.SingleStream.schedule_rng_seed = 789
 *.SingleStream.target_latency = 10
 *.SingleStream.target_latency_percentile = 90
 *.SingleStream.min_duration = 60000
@@ -16,9 +16,9 @@ ssd-mobilenet.SingleStream.performance_sample_count_override = 256
 ssd-resnet34.SingleStream.performance_sample_count_override = 64
 gnmt.SingleStream.performance_sample_count_override = 3903900

running this with a debugger on windows ... I see issues too.
I see that we have the correct string in hand but strtoul() is returning the wrong value.
Looking.

std::mt19937 ought to be the same everywhere, but potentially std::uniform_distribution is different? If people end up with slightly different random numbers, I'm basically okay with it.

@tjablin Care to specify 32-bit seeds?

strtoul() should be strtoull() - at least that fixes it for me.

Specifying 32-bit seeds won't resolve the issue. std::mt19937 requires 64-bit seeds. Even if the inital seed is less than 2^32, the seed will be 64-bits after the first round through the pseudo-rng.

I have a PR here https://github.com/mlperf/inference/pull/489 ... I know, its a little late for v0.5.

Even if the inital seed is less than 2^32, the seed will be 64-bits after the first round through the pseudo-rng.

OK, maybe I got lucky with the example above.

Specifying 32-bit seeds won't resolve the issue. std::mt19937 requires 64-bit seeds. Even if the inital seed is less than 2^32, the seed will be 64-bits after the first round through the pseudo-rng.

The issue is in the initial parsing of text -> number - if a long is only 32 bits on a given platform, strtoul will only output a 32-bit result

Yes,  after some debugging we found the same and #489 uses now strtoull().


Add Artifact Staging Endpoint to PrepareJobResponse

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

This allows the Job Server to point the client at the appropriate
endpoint without having to have any foreknowledge in the client.

R: @herohde @kennknowles

Changes Unknown when pulling 043bedb29ce0bdcb4b41649035b1bdf5755f61bf on tgroh:artifact_api_endpoint_prepare into ** on apache:master**.

LGTM

LGTM


Student profile - add 'none' for read-only notes and interventions

Also removes placeholder "add" buttons to make clear this is read-only at the moment.
Before:

After:

Working on https://github.com/studentinsights/studentinsights/issues/5


[FEATURE] Add possible values to ConnectorAction.ActionType enum, or make generic

Is your feature request related to a problem?
A clear and concise description of what the problem is, e.g. I'm always frustrated when [...]
When registering a ML model, you can specify an actions parameter that is an array of objects, however there is currently no point to do so since the action_type only supports predict currently. For example, what if I wanted to add in the same model, actions for embed and predict?
"actions": [
    {
      "action_type": "predict",
      "method": "POST",
      "url": "https://api.cohere.ai/v1/chat",
      "headers": {
        "Authorization": "Bearer ${credential.cohere_key}",
        "Request-Source": "unspecified:opensearch"
      },
      "request_body": "{ \"message\": ${parameters.message}, \"model\": \"${parameters.model}\", \"connectors\": \"${parameters.connectors}\", \"conversation_id\": \"${parameters.conversation_id}\" }"
    },
    {
      "action_type": "other..",
  ]

What solution would you like?
A clear and concise description of what you want to happen.
Solution 1:

Increase the ActionType enum values we can use

Solution 2:

Remove the ActionType enum, and allow the use the flexibility to define the action_type to url mapping generically

What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.
Two solutions above
Do you have any additional context?
Add any other context or screenshots about the feature request here.

When registering a ML model, you can specify an actions parameter that is an array of objects, however there is currently no point to do so since the action_type only supports predict currently.

Thanks @tianjing-li , you are correct. We built connector action as list for future extension. Check my response  https://github.com/opensearch-project/ml-commons/issues/1926#issuecomment-1916351976

@ylwu-amzn Thank you! will make a note of that ticket


Playground mode does not generate response.

The error:
Error: Trying to load an object that doesn't implement serialization: $.kwargs.last.kwargs.bound.kwargs.http_client -> {"id":["httpx","AsyncClient"],"lc":1,"repr":"<httpx.AsyncClient object at 0x7f4033d5c970>","type":"not_implemented"}
The prompt used:
System: Do what user asks
Human: Write hello

Could you share a reproducible example?

Will re-open if we have more informaiton


Issue with creating/deleting NSG to secure Application Gateway V2 (only private frontend IP)

Hi,
I have tried to create the NSG as specified on the Application Gateway FAQ.
However, it is not possible to delete the NSG, and it fails with the following error:
Network security group blocks incoming internet traffic on ports 65200 - 65535 to subnet associated with Application Gateway. This is not permitted for Application Gateways that have V2 Sku.
I followed the exact steps on the page, did I do something wrong or is there something missing in the steps for me to be able to create and delete this NSG properly ?
Thanks

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

ID: 88466307-81b8-1e5b-7f2c-191d8e818071
Version Independent ID: 08ad49f3-6a57-b925-794a-37215e985aba
Content: Frequently asked questions about Azure Application Gateway
Content Source: articles/application-gateway/application-gateway-faq.yml
Service: application-gateway
GitHub Login: @greg-lindsay
Microsoft Alias: greglin

Sorry, I now understand the issue, my mistake, was trying to delete the NSG, without deleting the AGW first. Sorry again for any disturbance.

No worries at all @caimez, glad to know the issue was resolved.


Update stream-analytics-introduction.md

Trying a close/reopen to clear the validation error.

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

#sign-off


MQTT Light - Do not throw if property is missing from templated MQTT message

Description:
Do not throw if property is missing from templated MQTT message.
This avoids errors in the log when same topic is used for, for example, both brightness and state and it's not guaranteed that both brightness and state is always present in the message.
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox.

(Close/Open to re-trigger broken travis build)

I don't think that this is good . A topic is dedicated to a certain value, we should not try to silently approve of certain errors, instead users should change their configuration.

We should also not render templates twice

@balloob Let me explain the problem in more detail with an example.
Discovery message sent by the device:
Topic: homeassistant/light/sonoff_0FDD9A_1/config
Message:
{
   "name":"Kitchen Sink",
   "command_topic":"tasmota/sonoff_0FDD9A/cmnd/POWER",
   "state_topic":"tasmota/sonoff_0FDD9A/stat/RESULT",
   "value_template":"{{value_json.POWER}}",
   "payload_off":"OFF",
   "payload_on":"ON",
   "availability_topic":"tasmota/sonoff_0FDD9A/tele/LWT",
   "payload_available":"Online",
   "payload_not_available":"Offline",
   "brightness_command_topic":"tasmota/sonoff_0FDD9A/cmnd/Dimmer",
   "brightness_state_topic":"tasmota/sonoff_0FDD9A/stat/RESULT",
   "brightness_scale":100,
   "on_command_type":"brightness",
   "brightness_value_template":"{{value_json.Dimmer}}"
}

Change brightness update:
Topic: tasmota/sonoff_0FDD9A/stat/RESULT Message: {"POWER":"ON","Dimmer":66}
Turn off update - this will throw because there is no dimlevel:
Topic: tasmota/sonoff_0FDD9A/stat/RESULT Message: {"POWER":"OFF"}

Ah okay, yeah that does make sense.


Move Project ComputedFile generation logic from Project::load_data to new method inside ComputedFile model

Context

The load_data method inside the Project model accomplishes a variety of different tasks. Among those tasks includes writing readmes, parsing metadata, writing metadata, and generating computed files.
Computed file generation is carried out after metadata parsing, metadata writing, first at the sample level, and then at the project level.
Problem or idea

The file computation logic is too tightly coupled with the other tasks within the load_data method.
Solution or next step

All file computation logic should be moved out of the load_data method in the Project model into its own method, and then transferred to the ComputedFile model.

Issue addressed in PR https://github.com/AlexsLemonade/scpca-portal/pull/702


Fixed error when adding a domain tag which has already been added (Close #267)

Previously, if you attempted to add a domain tag to a domain that already had that tag, you'd get a traceback. Now, you'll simply get a warning stating that the tag was already there.

CI failure


Proposal: Accessing nth element of an array

Only some implementations of mustache have the feature of accessing the nth element of an array. Such a feature is useful, and it should be included in the spec so that all up-to-date implementations have this feature.

I agree. I believe that this behavior is worth explicitly stipulating as required functionality. ~As of now, not only array access, but nested object access is not mentioned anywhere in the spec. As such, foo.bar is currently undefined behavior, but many specs implicitly support it already.~ This is untrue, cf. https://github.com/mustache/spec/issues/138#issuecomment-1237324389. In reality, the documentation on https://mustache.github.io/mustache.5.html just doesn't mention this, so I thought it was implementation-specific behavior. Perhaps I can make a PR to update that page to explicitly mention dot-access?)
In JavaScript, since I believe accessing an array by an index is roughly the same as accessing an object by key (because Arrays in JavaScript are just Objects), we get foo.0 "for free". But that seems to be a happy implementation-specific coincidence? Can we formally specify this behavior so that we can rely on it across implementations? (There might need to be two different syntaxes, though: one for objects (e.g.: foo.bar), and one for arrays (e.g.: foo[0]), as I'm sure many already-existing parsers might not like variable names that start with a number (e.g.: foo.0).
I think @jgonggrijp might suggest a power lambda implementation like in https://github.com/mustache/spec/issues/138#issuecomment-1286225095, but accessing array items by index is SO common, and already supported by implementations, so I'm hoping we can just formally specify it at this point?

I agree. I believe that this behavior is worth explicitly stipulating as required functionality by the spec.

Do keep in mind that adding required functionality to the spec implies issuing a major version upgrade. This, in turn, implies a lot of coordination and a long delay.

(...) the documentation on https://mustache.github.io/mustache.5.html just doesn't mention [dotted names], so I thought it was implementation-specific behavior. Perhaps I can make a PR to update the doc on that page to explicitly mention dot-access?)

I already went that route, but the update got stuck on the way to actual publication (see https://github.com/mustache/mustache/pull/266 and https://github.com/mustache/mustache.github.com/pull/149). In the meanwhile, I'm hosting an up-to-date version of the mustache(5) manpage over here, which does include dotted names. Feel free to tell other people about it. If the need arises, you can submit a pull request to https://github.com/jgonggrijp/mustache.

In JavaScript, since accessing an array by an index is roughly the same as accessing an object by key (because Arrays in JavaScript are just Objects), we get foo.0 "for free". But that seems to be a happy implementation-specific coincidence?

Yes, that's exactly what it is.

Can we formally specify this behavior so that we can rely on it across implementations? (There might need to be two different syntaxes, though: one for objects (e.g.: foo.bar), and one for arrays (e.g.: foo[0]), as I'm sure many already-existing parsers might not like variable names that start with a number (e.g.: foo.0).

It's complicated. Some programming languages start at 1 instead of 0, for example R. Some implementations will trip over dotted name parts starting with digits, as you already suggested. Some programming languages already use square brackets for different syntactic functions (for example Mathematica, which uses them for function calls) and/or have a different native syntax for array subscripts.
I'm not saying these complications couldn't be overcome or that specificying array subscription is necessarily a bad idea. I'm just saying that it isn't as straightforward as it may seem.

I suspect @jgonggrijp could say that a power lambda implementation is possible, like in #138 (comment),

Technically, this is true; I do think such a feature could be implemented using power lambdas and I might even say that. However, I don't really believe this would be a good application for power lambdas.

but accessing array items by index is SO common,

Is it really? I think I have done {{#someList.0}} a couple of times in order to check for list nonemptiness, but this use case could be addressed in better ways without array subscripting (see #147). Other than that, I don't think I ever use array subscripts and I don't remember seeing them in other people's templates, either. Could you suggest a usecase?

and already supported by implementations, so I'm hoping we can just formally specify already-existing behavior at this point?

As stated before, while several implementations do support such a notation, it is far from universal. Formally specifying it won't be simple.

(Thanks for letting me know about the new documentation location. Will spread it.)
My train of thought here, is that formally specified behavior is better than implementation-specific or undefined behavior. So if even the spec said something like, "Implementations MAY interpret integer dotted names as array indices", that would be sufficient and something we could get in a minor semver bump (and then maybe talk about requiring this behavior later). In my own personal experience, since mustache.js supports this (again, by happy coincidence), I thought that it was supported in all implementations, but was in for quite the surprise when that was not the case. Since the spec remains silent, the user is unsure as to whether they can rely on indexing across implementations. "Implementations MAY" is better than unspecified, right?

It's complicated. Some programming languages start at 1 instead of 0, for example R. Some implementations will trip over dotted name parts starting with digits, as you already suggested. Some programming languages already use square brackets for different syntactic functions (for example Mathematica, which uses them for function calls) and/or have a different native syntax for array subscripts

I totally get implementation complexity, but I don't think mustache should be "held back" by implementations, per se. For example, python doesn't support dotted syntax for regular Python objects (rather foo["bar"]), but its up to implementers to conform to mustache's spec, not the mustache spec to conform to various languages. Nevertheless, I do see your point, because although mustache shouldn't be limited by implementations, it should certainly be "informed" by them, and try to reduce implementation load where possible. That being said, I think indexing notation, like foo[0], if supported, is common enough in programming to be understood as sub-scription, regardless of the language.

I don't think I ever use array subscripts and I don't remember seeing them in other people's templates, either. Could you suggest a usecase?

Perhaps you're right. Maybe it's not as common as I'm thinking it is. However, with index access, you can alleviate some conditional logic in the middle of an array. For example, if you know foo[5] has some special value or is falsy, you can switch on foo[5] specifically. I don't think this is possible currently otherwise (without tons of if/else logic, or lots of superfluous lambdas).
What I think is a stronger argument for allowing this is the Zero One Infinity rule: we already allow indexing by key, why arbitrarily limit what else can be indexed? Index all of the things - as some implementations already allow you do to - but as I mentioned at the start, formal specification is better than implementation-specific (or undefined) behavior.
I know, if approved, it will take some time before a 2.0, which is why I think the discussion is worth visiting now, so it can be hashed out if/when that milestone.

In my own personal experience, since mustache.js supports this (again, by happy coincidence), I thought that it was supported in all implementations, but was in for quite the surprise when that was not the case.

mustache.js is confusing a lot of people, because it seems official while it is actually rather nonstandard. While it has been around for a long time, it was never a reference implementation (that honor goes to the original Ruby Mustache), it moved in a different direction than the spec and the author does not intend to bring mustache.js closer to the spec again. People wrote alternative Mustache implementations for JavaScript for this reason (Twitter employees wrote Hogan, now end-of-life, and I wrote Wontache).
In this light, it is also rather unfortunate that the (outdated) Mustache website still uses mustache.js for the demo feature. You can use the Wontache playground instead; it supports lambdas and partials and it follows the spec 100%.

Since the spec current remains silent, the user is unsure as to whether they can rely on indexing across implementations. Explicit is better than implicit, right?

True. In that case, the text you suggested above should probably explicitly end with "... but you cannot rely on it".

I don't think I ever use array subscripts and I don't remember seeing them in other people's templates, either. Could you suggest a usecase?

Perhaps you're right. Maybe it's not as common as I'm thinking it is. However, with index access, you can alleviate some conditional logic in the middle of an array. For example, if you know foo[5] has some special value or is falsy, you can switch on foo[5] specifically. I don't think this is possible currently otherwise (without tons of if/else logic, or lots of superfluous lambdas).

I understand the technical implications, but my question remains: why would anyone actually want to do this? What is so special about this individual element of a list, and if it is so special, why is it in a list buried between other, seemingly equivalent things in the first place? I would like to see a concrete example where an element is extracted somewhere from the middle of a list and there isn't a better solution.

What I think is a stronger argument for allowing this is the Zero One Infinity rule: we already allow indexing by key, why arbitrarily limit what else can be indexed?

Sorry to nitpick, but if I understand that rule correctly, supporting indexing only by keys is perfectly fine: it is the "one" case.

Index all of the things - as some implementations already allow you do to -

Which implementations do this, according to you? I know that the JS implementations allow numeric keys, but that's because arrays in JS are actually just objects with property names containing only digits. None of the JS implementations allows accessing Set or Map entries, as far as I know.

but as I mentioned at the start, formal specification is better than implementation-specific (or undefined) behavior.

This is not a universal truth. Leaving something undefined or implementation-defined is often a conscious, deliberate choice.

mustache.js is confusing a lot of people...

That's for sure. Thanks for clearing that up. My primary reason for advocating for this was because I did indeed think mustache.js was the spec reference implementation. As such, my PoV was "since this behavior is already in the "official" implementation, why isn't it in the spec??"

I understand the technical implications, but my question remains: why would anyone actually want to do this?

To be honest, I can't think of any use cases right this second (maybe @alanyee can), although I'm glad you necessarily aren't strictly opposed to adding it at some point. I know that I have needed this in the past, I just can't remember how at this current second.

Sorry to nitpick, but if I understand that rule correctly, supporting indexing only by keys is perfectly fine: it is the "one" case.

Leaving something undefined or implementation-defined is often a conscious, deliberate choice.

You're right about that first part. As per my first paragraph in this comment, I think I have a "problem" more with the undefined, unspecified, half-supported behavior than whether or not this is actually permitted in the spec. It would be nice to have the behavior explicitly quantified, like with a "Implementations MAY..." statement. As of right now, I'd argue the silence of the spec is worse than implementation-defined behavior: in C, for example, the spec will say "such and such is undefined, or implementation-specific". But we've got nothing.
As you've noted, thanks to mustache.js' current supremacy (and the corresponding outdated doc), users can be fooled into thinking that whatever mustache.js does is The Blessed Way(TM), and all differing implementations are therefore non-compliant, hence my request for specification. The spec's silence lulls you into a false sense of security, as we both have observed.
So, at minimum, even if this doesn't get implemented, I feel like a "Implementations MAY interpret integer dotted names as array indices" statement could be very helpful for clearing up confusion (and as per https://datatracker.ietf.org/doc/html/rfc2119#section-5, we wouldn't necessarily need to state that the behavior isn't to be relied upon, since it would be implicit).

Alright, feel free to submit a pull request. Let's see whether we can reach a consensus on how to formulate this.

Update to the official website being outdated: it is much less outdated now! The mustache(5) manpage is now current with version 1.3.0 of the spec. It does not mention dynamic names yet, but I can now merge updates to the website myself thanks to @locks and I will address the remaining bits of outdatedness sometime in the near future.


Fix markers array's indexes and slider bounds

The problem was
The slider first step was the first marker. But the next step didn't display any. ( mentioned here : https://github.com/dwilhelm89/LeafletSlider/issues/20 )
That's because the indexes of the options.markers[ ] are 24 to 24+X (with X=markers number) but with 25 empty.
I changed it to 0 to X-1 like a normal array by incrementing a variable. No hole in the array anymore.
Current version : http://kara.62.free.fr/slider_fixbounds/old.html
Demo with fix : http://kara.62.free.fr/slider_fixbounds/

Thanks for the demos. Makes merging much more easy =)


change dynamic to object in operator check -> fix open issue

Since it does not make sense to compare a null object with the version, dynamic and object does not make any difference in this case


Implementation of the Paging System

This pull request shall implement the newly created paging system into the main game.
I'll wait for merge until someone else tested it as well.

I am going to merge this now. I did not encounter any bugs.


Coverity NULL pointer fixes.

Fix possible NULL dereference issues.

[x] tests are added or updated

Merged to master.  Thanks.


Changed configs for adminrouter and dcos-config-windows.yaml

High-level description
Delete detec_ip and detect_ip_public from dcos-config-windows.yaml. Changed config files for adminrouter.
Corresponding DC/OS tickets (required)

DCOS-ID JIRA title / short description.

Related tickets (optional)

DCOS-ID JIRA title / short description.

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain.
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

@mesosphere-mergebot changelog-not-required

@mesosphere-mergebot label Work In Progress

@mesosphere-mergebot label Ready For Review


Stability Margin may give incorrect results with FRD system

When calling stability_margins() with an FRD system, or with a (mag, phase, omega) system that is converted to FRD, the phase crossover frequency in particular (and consequently the gain margin) can be radically inaccurate. Sometimes I even get the phase crossover as a negative frequency! I am working with a fairly simply system with a zero, a couple poles, no resonances, etc., so I looked to see if I could figure out what was going on.
I found that changing lines 207 and 208 in margins.py from:
wc = np.array([sp.optimize.fsolve(mod, sys.omega[0])])[0]
w_180 = np.array([sp.optimize.fsolve(arg, sys.omega[0])])[0]

to:
wc = np.array([sp.optimize.fsolve(mod, np.median(sys.omega))])[0]
w_180 = np.array([sp.optimize.fsolve(arg, np.median(sys.omega))])[0]

Always produces the expected result. It makes sense to seed the fsolve function with the median frequency in the defined FRD system because one would expect the crossovers to generally be in "the middle" of the bode plot instead of at the lowest frequency.
Just an improvement I'm using myself, but it may be worth incorporating.

Thanks for pointing this out, and for the proposed fix!  Would you mind providing a small example that reproduces the problem, especially for phase crossover being reported as negative?

I don't know the best way to do this, but here goes... I can't find the results where I was getting negative crossover, but here is an example that gives an incorrect result. I have this data in a tab-delimited file and I'm reading it in using csv.reader. Units are: Frequency (Hz), Phase (degrees), Gain (dB).
Frequency  	Phase      	Gain
100<PHONE_NUMBER> 	43.06807989
109.6478196<PHONE_NUMBER> 	42.37155698
120.2264435 	98.85676169 	41.63518924
131.8256739 	96.83932633 	40.86066824
144.5439771 	94.91939983 	40.05043469
158.4893192 	93.12429171 	39.20762079
173.7800829 	91.47734077 	38.33597267
190.5460718 	89.99718051 	37.43974492
208.9296131 	88.69710208 	36.52356256
229.0867653 	87.58460986 	35.59225128
251.1886432 	86.66126281 	34.65064515
275.4228703 	85.92286595 	33.70338705
301.995172  	85.36002671 	32.75474152
331.1311215 	84.95903335 	31.80843951
363.0780548 	84.70296207 	30.86757002
398.1071706 	84.57288874 	29.93452656
436.5158322 	84.54907594 	29.01100785
478.6300923 	84.61202512 	28.09806535
524.8074602 	84.74331839 	27.19618483
575.4399373 	84.92621557 	26.30538791
630.9573445 	85.14600904 	25.42533996
691.8309709 	85.39016601 	24.55545369
758.577575  	85.64830295 	23.69498098
831.7637711 	85.91204143 	22.84308923
912.0108394 	86.17479059 	21.99892097
1000        	86.43149378 	21.16163764
1096.478196 	86.67836708 	20.33044954
1202.264435 	86.91264832 	19.50463444
1318.256739 	87.1323675  	18.68354726
1445.439771 	87.33614389 	17.8666232
1584.893192 	87.52301123 	17.05337596
1737.800829 	87.69227026 	16.2433926
1905.460718 	87.84336693 	15.4363261
2089.296131 	87.97579429 	14.63188622
2290.867653 	88.08901697 	13.82982947
2511.886432 	88.1824171  	13.02994854
2754.228703 	88.25526157 	12.23206178
3019.95172  	88.30668969 	11.43600352
3311.311215 	88.33571985 	10.64161579
3630.780548 	88.34127168 	9.848742581
3981.071706 	88.32219777 	9.057227176
4365.158322 	88.27731684 	8.266913195
4786.300923 	88.20543824 	7.477649292
5248.074602 	88.10536811 	6.689296868
5754.399373 	87.97588939 	5.901739583
6309.573445 	87.81571164 	5.114893007
6918.309709 	87.62339133 	4.328712685
7585.77575  	87.39722755 	3.54319908
8317.637711 	87.13514081 	2.758398335
9120.108394 	86.83454379 	1.97439828
10000       	86.49221247 	1.191319551
10964.78196 	86.10416535 	0.409301937
12022.64435 	85.66555743 	-0.37151378
13182.56739 	85.1705959  	-1.15100814
14454.39771 	84.61248508 	-1.92910903
15848.93192 	83.98340901 	-2.70582044
17378.00829 	83.27455988 	-3.48125268
19054.60718 	82.47621855 	-4.2556517
20892.96131 	81.57788786 	-5.02942492
22908.67653 	80.56847148 	-5.80316029
25118.86432 	79.43648092 	-6.57763583
27542.28703 	78.17024372 	-7.35381804
30199.5172  	76.75808096 	-8.13284953
33113.11215 	75.18842394 	-8.91602866
36307.80548 	73.44985008 	-9.70478597
39810.71706 	71.5310346  	-10.5006634
43651.58322 	69.42063348 	-11.3053023
47863.00923 	67.10712915 	-12.1204434
52480.74602 	64.57867868 	-12.9479428
57543.99373 	61.82300494 	-13.7897991
63095.73445 	58.82736381 	-14.648193
69183.09709 	55.57860879 	-15.5255308
75857.7575  	52.0633624  	-16.4244883
83176.37711 	48.26829145 	-17.3480502
91201.08394 	44.18047418 	-18.2995391
100000      	39.78783823 	-19.2826308
109647.8196 	35.07964153 	-20.3013523
120226.4435 	30.04696098 	-21.3600614
131825.6739 	24.68314927 	-22.4634063
144543.9771 	18.98421873 	-23.6162696
158489.3192 	12.94911698 	-24.8236988
173780.0829 	6.579871835 	-26.0908316
190546.0718 	-0.11839618 	-27.4228233
208929.6131 	-7.13757058 	-28.8247845
229086.7653 	-14.4666996 	-30.3017333
251188.6432 	-22.0921622 	-31.8585632
275422.8703 	-29.9977838 	-33.5000241
301995.172  	-38.1648652 	-35.2307055
331131.1215 	-46.5721209 	-37.0550127
363078.0548 	-55.1955628 	-38.9771244
398107.1706 	-64.0083973 	-41.000923
436515.8322 	-72.9810243 	-43.1298932
478630.0923 	-82.0812319 	-45.366991
524807.4602 	-91.274666  	-47.7144845
575439.9373 	-100.525631 	-50.1737739
630957.3445 	-109.798257 	-52.7451928
691830.9709 	-119.058023 	-55.427788
758577.575  	-128.273639 	-58.2190684
831763.7711 	-137.419195 	-61.1146994
912010.8394 	-146.476493 	-64.1081069
1000000     	-155.437328 	-67.189935
So I convert the system as follows, noting that I need to add 180 degrees to the phase because the raw data is actually from a measured closed loop gain, which includes the negative feedback summing junction:
sys = control.frdata.FRD(10 ** (gain / 20) * np.exp(1j * (phase + 180) * np.pi / 180), freq, smooth=True)

Then call stability_margins() and get the following:
>>> control.stability_margins(sys)

C:\Python34\lib\site-packages\scipy\optimize\minpack.py:237: RuntimeWarning: The iteration is not making good progress, as measured by the
improvement from the last ten iterations.
warnings.warn(msg, RuntimeWarning)
>>> Out[8]:
(0.03453522430472155,
85.88099319950949,
0.91495418706639464,
426.84141880874506,
11506.88822765755,
77515.758056640625)
So the phase crossover is incorrectly identified as 426.8 Hz, resulting in a gain margin of 0.0345 or -29 dB. In reality, plotting the system shows that the phase doesn't crossover until ~190 kHz, giving a gain margin of 23.4 (or 27 dB).
By the way, this all comes from what may be an unorthodox source for working with the control toolbox. I am using SIMetrix to run Monte-Carlo simulations of a system loop gain, then post-processing the data in order to calculate the gain and phase margins for each run, then perform statistics on the results. So I'm not designing or simulating a system using the control toolbox, but rather post-processing simulation data. I've also used it to post-process data taken from actual system measurements in the lab, but that's a different story.

Is this the same issue?
L = TransferFunction([1e15], [1e1, 1.01e7, 1e11])
mag, phase, omega = bode(L, omega=2*pi*logspace(log10(10**2), log10(10**8), 500), dB=True, Hz=True)
gm, pm, sm, wg, wp, ws = stability_margins((mag, phase, omega))

wg should be "Gain margin crossover frequency (where phase crosses -180 degrees)".  From the graph, it should be around 100 MHz, but wg is 1.58 MHz.
wp should be "Phase margin crossover frequency (where gain crosses 0 dB)".  From the graph, this should be around 1.5 MHz, and wp is 1.498 MHz, so that looks right.
(Also, gm, pm, sm, wg, wp, ws = stability_margins(L) gives different results, with gm and wg == None.  I don't see anything in the docstring about why this would happen.)

Related to #87


Bug with Podfile Yoga

Hi,
I follow this tuto : https://codeburst.io/react-native-google-map-with-react-native-maps-572e3d3eee14
When i run pod install I have this error :

Fetching podspec for Yoga from ../node_modules/react-native/ReactCommon/yoga/Yoga.podspec
[!] The name of the given podspec yoga doesn't match the expected one Yoga

I d'ont understand because I have the file Yoga.podspec
EDIT : Solution
Sorry for this post i found the solution
in Podfile -> change pod 'Yoga', :path => '../node_modules/react-native/ReactCommon/yoga/Yoga.podspec'
in -> pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga/yoga.podspec'

@Alp4ga please close the issue.
@christopherdro can close.

@christopherdro - is the resolution to this to use the lowercased name? If that's the case, then all other pods with dependencies on Yoga would need to use that custom podspec as well.
Is there a reason that React needs to use a custom naming convention? If not it seems easier and less confusing to just use the name Yoga instead of yoga in React.

In case anyone else is following the tutorial mentioned above and still getting the error, try removing the "/Yoga.podspec" from the path in your Podfile
pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'

nice @aliu1212 DOES solution work fine
easy fix.
just do
ls node_modules/react-native/ReactCommon/yoga/
and see where is the yoga podspec, mine had a capital letter
Yoga.podspec
so wise words: Yoga is bad, practise Kung Fu instead"
Master Shifu

I renamed Yoga.podspec to yoga.podspec AND changed line 18 inside podspec file from spec.name = 'Yoga' to spec.name = 'yoga'


Getting CreatedAt date from GraphQL List operation while not breaking mutate/create

I've been battling this for a while, and I've kinda hit a brick wall, so I'm hoping to get some help here.
I've got an Amplify integrated iOS app that can fetch data from DynamoDB (not using datastore), with a GraphQL operation.
The Amplify iOS version is 1.93
Models have been built using codegen and work as expected (mostly)
Without doing anything, the createdAt field does not show on returned items when performing a list operation on a DynamoDB resource.
If manually add the corresponding entries in the Model as optional and modify the Type+Schema file, for the corresponding Type and add a field for createdAt, like this (also adding a case for the codingKeys):
      .field(track.createdAt, is: .optional, ofType: .string),

I can then receive values with createdAt.
Note that I've not actually modified the schema on the backend, as this app is using a shared backend and the schema is maintained elsewhere.
The problem occurs when I then try to create a new Item with the above changes in place.
In brief, I get the following error on any mutation of an Item:
The variables input contains a field name \'createdAt\' that is not defined for input object type

And that makes sense, because I've not modified the backend schema, which I don't want to do because createdAt is auto-generated on the backed at time of item creation.
If I remove the above changes, I can create Items, but then I can't get the createdAt in my return values, which is back to square one.
I've tried several forms of juggling to try to get this to work, but I'm not sure that it's possible after all my efforts.
This leads me to believe that as a workaround, I will need to need to create a new createdOn field in the schema and use that, which I'm loath to do, since createdAt is right there doing exacty what I want it to do.
In sum, I want to be able to receive items with createdAt and mutate items without any errors.
Any advice on how to achieve what I'm trying to do would be most appreciated.
Thanks.

HI there,
It's been a while since I opened this, and it appears that a response is not imminent.
I've since created a work around by implementing a new field on the type in the graphQL schema, rather than trying to use what's there.
It just seems that the createdAt and updatedAt weren't intended for use "outside" of DynamoDB, and creating a new field was the easiest way forward.
If there is a "better" solution, I'd love to hear it; othewise, fell free to close this issue.
Thanks.

Hello,

Could you please share the GraphQL schema you're using so that I can reproduce the issue.
Are you using Amplify.API.query(request: .paginatedList()) ?
I see that you're using Amplify version 1.9.3. Currently the latest version is 1.19.1. We've made several improvements on DataStore/API over time. Could you please update to the latest version and see if you're still facing the issue.

Closing due to inactivity.


Join Section | UX Improvements

Issue
The join section has a few issues which hinder the user experience and may cause chaos for users while filling them.
Files that will change

js/join.js
css/join.css
/join.html

Description:
The join section is live at Real Dev Squad | Join.
While browsing through the section we found some issues listed below:

[x] Data validation:

Current behavior:  The validator runs and sets the background color of all the input fields to red as soon as the page loads.
Expected behavior: The validator should run and set the background color when the user starts entering the data.

[x] Display word limit:

Current behavior: There is no word limit/ words left shown in any input field.
Expected behavior: The UI must show how many words are left while they are providing their input.

[x] Dropdown for location:

Current behavior: The form currently accepts any data in location fields.
Expected behavior: As soon as the user starts entering the data they should get a dropdown to select from.

[x] Placeholders:

Current behavior: None of the input fields currently have a placeholder.
Expected behavior: All the input fields must have a placeholder.

[x] Correct and incorrect data indicator:

Current behavior: When the data is correct the background of the input field changes to green. In case of incorrect data, it is red.
Expected behavior: When the data is correct just remove the red color rather than adding the green background.

[ ] Focus on a field:

Current behavior:  The user lands on the page/clicks the next page the page just appears and none of the input fields have a cursor
Expected behavior: As soon as the user lands on any page of the join section the cursor must be present in the first / previously entered input field.

Validation errors at field level should also be visible below the input label

Validation errors at field level should also be visible below the input label in red color

yes @samarpan1738 that is what I meant by display word limit, Please checkout the PR that I have raised it contains the video for the same


[GoRouter] ShellRoute state does not take pushed route into account.

import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';

void main() => runApp(App());

final GoRouter _router = GoRouter(
  routes: <RouteBase>[
    ShellRoute(
        builder: (context, state, child) {
          print("Shell: ${state.location}");
          return child;
        },
        routes: <GoRoute>[
          GoRoute(
            path: '/',
            builder: (BuildContext context, GoRouterState state) {
              return MyHomePage();
            },
          ),
          GoRoute(
            path: '/b',
            builder: (BuildContext context, GoRouterState state) {
              return MyHomePageB();
            },
          ),
        ])
  ],
);

class App extends StatelessWidget {
  App({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp.router(
      routerConfig: _router,
      title: 'GoRouter Example',
    );
  }
}

class MyHomePage extends StatelessWidget {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {
    final st = GoRouterState.of(context);
    print("locA: ${st.location}");
    return Scaffold(
        appBar: AppBar(
          title: const Text("A"),
        ),
        body: Column(children: [
          TextButton(child: Text("go A"), onPressed: () => _router.go('/')),
          TextButton(child: Text("push A"), onPressed: () => _router.push('/')),
          TextButton(child: Text("go B"), onPressed: () => _router.go('/b')),
          TextButton(
              child: Text("push B"), onPressed: () => _router.push('/b')),
        ]));
  }
}

class MyHomePageB extends StatelessWidget {
  const MyHomePageB({super.key});

  @override
  Widget build(BuildContext context) {
    final st = GoRouterState.of(context);
    print("locB: ${st.location}");
    return Scaffold(
        appBar: AppBar(
          title: const Text("B"),
        ),
        body: Column(children: [
          TextButton(child: Text("go A"), onPressed: () => _router.go('/')),
          TextButton(child: Text("push A"), onPressed: () => _router.push('/')),
          TextButton(child: Text("go B"), onPressed: () => _router.go('/b')),
          TextButton(
              child: Text("push B"), onPressed: () => _router.push('/b')),
        ]));
  }
}

Launch, click on pushA or pushB, observe that the shell state doesn't take the pushed route into account.

If this is the expected behavior, how do I get the state of the last pushed route?

feel free to close if this is the expected behavior.

I did implement my own navigation history and stopped using push.
(grabbing the history was also a bit challenge, the only official way I found was to rely on NavObserver which emits multiple operations for a single router.go() and generally does not map well to go router).
So I did subscribe to a few "addListener" (not sure how correct this is):
    router.routeInformationProvider.addListener(onChange);
    router.routerDelegate.addListener(onChange);
    router.addListener(onChange);

So I guess I'll close, as I dont have issue anymore. I can open separate bugs for other parts I mention if needed.
Thanks for this great package.

Hi @cgestes , i ran into the same problem, would be great to get an answer here, which is maybe not possible if you close the issue after just 4 hours...


Assertions to check dataframe joins

Checking the results of a join can be a lifesaver for otherwise cryptic bugs, even if that's just that the result should be an m x n table, so you assert res.shape = (expected_rows, expected_columns).
Originally posted by @afmagee42 in https://github.com/CDCgov/cfa-viral-lineage-model/pull/15#discussion_r1711995886

I like this idea, but while implementing it, I learned that LazyFrames don't have shape, and I don't know if it's worth collecting the object in memory just to perform this check?


Upgrade GitHub PRs plugin in sample app

Upgrade from 0.3.0 to 0.4.3. Adds tab routing and uptakes the new dependency injection API. This should also help solve issues like this one: https://github.com/RoadieHQ/backstage-plugin-github-pull-requests/issues/13
See the README for more info.
:heavy_check_mark: Checklist

[ ] All tests are passing yarn test
[ ] Screenshots attached (for UI changes)
[ ] Relevant documentation updated
[ ] Prettier run on changed files
[ ] Tests added for new functionality
[ ] Regression tests added for bug fixes

@stefanalund The plugin version was pinned for some reason. I've undone it.


How to add new field

Case

Issue
Hello, how to add an additional field for example company website in experiences section?
Thank you
Info

Operating System: LINUX
Node-Version: 9.3.0

Hi @rainolf
This is a basic vue-js-project.
Please start here to learn how to modify it.


feat(ingest): clickhouse - add metadata modification time and data size

Add metadata modification time and data size
Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

I tried to modify the test file but my native run code environment wasn't working very well


Separate file operand logic into uucore

This pull request includes the changes from #1324, which are included so that the stdin checking functionality is used in the codebase. As there are no guidelines for contributing to uucore, I am making this pull-request as an RFC on using uucore to implement such functionality in this way.

As a side note continuing the point at the end of the above summary, I feel like CONTRIBUTING.md could be expanded to discuss procedure and standards for contributions other than to implementing a new utility.

Also, yes, that's a good idea.  If you have time to open an issue that would be great.  If not, I can open one later.

@Arcterus I think it might be worth waiting on this issue until we can get a generalized system for processing - in argstrings. I assume that's what you were reffering to in your previous comment.

Yeah, that'd probably be a good idea.  I think we might be able to do something where a function takes a filename and two callbacks (one for stdin, one for an actual file) as arguments, like so:
fn process_file_arg<T, U>(file: &Path, stdin_cb: T, file_cb: U) -> Result<(), String>
where
    T: FnMut() -> Result<(), String>,
    U: FnMut(&Path) -> Result<(), String>,
{
    if file == Path::new("-") {
        stdin_cb()
    } else {
        file_cb(file)
    }
}

I haven't tested this, so keep that in mind.  Also, it can obviously be tuned more (e.g. the return type probably shouldn't be limited to Result<(), String>).
If we use something like this function, basically we'd just call it repeatedly in the loop over the file arguments.  We might be able to make another general function to first check if the file list is empty and delegate based on that (basically replacing the if uucore::coreopts::is_stdin(&files) { /* ... */ } else { /* ... */ } in tail.

No action for a while, closing.
And maybe clap can do that out of the box


move nsx attributes to its tab

Description
Move nsx attributes represented as NSX_ from host info tab to nsx tab
Use case
Interface Changes
Additional Context

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

@tinova PRs to be approved:

One: https://github.com/OpenNebula/one/pull/4816
Docs: https://github.com/OpenNebula/docs/pull/1149


CLI - Enable "use" command

This commit enables the "use" command to specify and switch to databases.
It also now properly displays an error if you issue a query that results in an error and you haven't specified a database.

@otoolep This is ready for review.

LGTM.


Improve support for Ven's Stock Revamp

Add radiation emitter to nuclear engines added by VSR. Radiation amount balanced around max thrust vs. stock nuclear engine. Not sure if those numbers actually make any kind of sense.
Add entertainment to  PPD-20 Jumbo Kerbal Can. It's basically 10 person hitchhiker, so add the same amount of entertainment as on 10 Kerbal inflatable hab IKU-03. Flavour text could use some improvement.
Provide workaround for VSR 1.9.5 having multiple instances of CrewCapacity on IKU-03. Ven already accepted pull request with fix, but I have no idea when he'll release. This patch will still work correctly after fixed VSR is released.

Good stuff. And the entertainment description is not bad at all.


RT Tweet

Checklist

[X] I am able to reproduce the bug with the latest version.
[X] I made sure that there are no existing issues - open or closed - which I could contribute my information to.
[X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
[X] This issue contains only one bug, that only occurs in Squawker

Affected version
v3.1.3
Steps to reproduce the bug
Find a tweet that was RTed
Expected behavior
Quotations of RT tweets appear to be broken.
Actual behavior
Quotations in RT tweets should be displayed properly.
Screenshots/Screen recordings

Logs
No response
Affected Android/Custom ROM version
LineageOS A10
Affected device model
Redmi K20
Additional information
No response

Just to be clear.
When you write that the text of a retweet is broken, do you mean the end of the text with twitter.com/... ?

The link at the end is another tweet content. However, it looks corrupted because of RT.

Version 3.1.4 should fix the issue.

https://github.com/j-fbriere/squawker/assets/60405617/1dbc7ad6-9dd2-4866-8526-bede71649ad7

the problem continues

Maybe you should flush the feed cache by scroll down from the top.
If that doesn't work, please provide a twitter user id with the problem with a recent tweet, I will test it.

I cleared the cache and tried again and it was fine. Thanks.

I'm glad that everything is fine.
I did some more tests with the asaf__agah user but this user has problems.
Now the feeds with this user returns empty response: no tweet, no retweet, nothing.
I tested it on nitter: same problem.
This do not apply for profile timeline request, only feed request.
Since this user has problems with feed that do not look related to the current issue, I will close the issue.


[pylint] Preserve original value format (PLR6104)

Summary
Resolves #11672.
Test Plan
cargo nextest run and cargo insta test.

I'd like to believe it isn't my fault that the mdformat check failed. A simple uvx pre-commit run --all-files commit should fix it, but I won't submit a PR as I'm not interested in finding the cause.

I believe it's due to one of the mdformat plugins we use having released a new version. We don't have these pinned in our pre-commit config file; we probably should.
Two of the plugins we use cut new releases a couple of hours ago, one of them a major version bump:

https://github.com/KyleKing/mdformat-mkdocs/commit/ce6710808d35248d1419f5db89cb6e7a3fc6fd3d
https://github.com/KyleKing/mdformat-admon/commit/f6f2c231072bf5f55ce6b4237f4ee908ba44eed2

I filed https://github.com/astral-sh/ruff/pull/14992 to fix the pre-commit issue.


<IP_ADDRESS> make check fails with parallel builds

I am building <IP_ADDRESS> like this:
LD_LIBRARY_PATH=/usr/local/lib CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib CC=mpicc ./configure --enable-parallel-tests --enable-logging --prefix=/usr/local/netcdf-<IP_ADDRESS>
make check fails like this:
mpicc -DHAVE_CONFIG_H -I. -I..  -I../include   -I/usr/local/include   -MT tst_h_par.o -MD -MP -MF $depbase.Tpo -c -o tst_h_par.o tst_h_par.c &&
mv -f $depbase.Tpo $depbase.Po
tst_h_par.c: In function ‘main’:
tst_h_par.c:89:54: error: ‘ERR’ undeclared (first use in this function)
if ((fapl_id = H5Pcreate(H5P_FILE_ACCESS)) < 0) ERR;
^
tst_h_par.c:89:54: note: each undeclared identifier is reported only once for each function it appears in
tst_h_par.c:226:7: error: ‘SUMMARIZE_ERR’ undeclared (first use in this function)
SUMMARIZE_ERR;
^
tst_h_par.c:231:7: error: ‘FINAL_RESULTS’ undeclared (first use in this function)
FINAL_RESULTS;
^
Makefile:907: recipe for target 'tst_h_par.o' failed
make[2]: *** [tst_h_par.o] Error 1
config.log.txt

I believe this issue was related to a missing #include in tst_h_par.c  I don't recall the commit offhand that fixed this, but it is currently fixed in master.

Hi, I'm writing just to tell you that the official stable release download is still with this bug.


[v2] Bump @mozaik/ui version and publish it on npm

The npm version is outdated

I've published<EMAIL_ADDRESS>


getsolvetime is missing

CplexMathProgModel complains that getsolvetime is not implemented, if this can be added to CPLEX.jl I would really appreciate, many thanks in advance!

Want to try out a PR?

I can't find a function to return time in CPLEX C API (I found cplex.getTime in C++ though), do we need to hack something to the optimize! call ourselves or is there something that we can call from CPLEX??

If it's accessible from the C++ api then it's almost surely also accessible
from the C api.
On Nov 12, 2015 6:02 PM, "emreyamangil"<EMAIL_ADDRESS>wrote:

I can't find a function to return time in CPLEX C API (I found
cplex.getTime in C++ though), do we need to hack something to the optimize!
call ourselves or is there something that we can call from CPLEX??
—
Reply to this email directly or view it on GitHub
https://github.com/JuliaOpt/CPLEX.jl/issues/58#issuecomment-156264549.

It doesn't have a clear definition but CPXgettime might do it? :) I will try it anyways!

Hopefully there's a better way, but you might have to use cpxgettime before and after a call to the optimizer and take the delta...

http://www-01.ibm.com/support/docview.wss?uid=swg21399982
So just use tic and toq.

Or safer to use time().

ugh

@emreyamangil, you can add a field to CplexMathProgModel to save the execution time inside optimize!

yupp, you just answered my question!!

Closed by https://github.com/JuliaOpt/CPLEX.jl/pull/59


Improve Hyperlinker's 'spanToNewline'

spanToNewline is used to help break apart the source into lines which
can then be partioned into CPP and non-CPP chunks. It is important that
spanToNewline not break apart tokens, so it needs to properly handle
things like

block comments, possibly nested
string literals, possibly multi-line
CPP macros, possibly multi-line

Comments in string literals in particular were not being properly handled.
The fix is to to fall back on Text.Read.lex to help lex things that are not
comments.
Fixes #837.

Wow, tricky. And what consequences! Thanks for the patch!

This brittleness is a bit frustrating - our lexer should not segfault, it should produce ugly output (and hopefully get back on its feet eventually). The segfaulting behaviour should have been fixed by https://phabricator.haskell.org/D4336, but it looks like there is one other place where GHC's lexer's internal position is modified: old-style line pragmas:
# 17 "/nix/store/p85kjy91dfvs4in358zyfxlksvibw0zn-glibc-2.26-131-dev/include/stdc-predef.h" 3 4

Do you think it is worth shoehorning these into ITline_prag for GHC's lexTokenStream (the same way {-# LINE ... #-} also get put into ITline_prag)?

If that makes things more stable then I am all for it!

Merging this for now. We can iterate once you adjusted GHC.

@alexbiehl Can this fix be backported to 8.2? Haddock segfaults often on current nixpkgs.


OA URL cannot be updated on Admin

The admin UI does not have the ability to update the open access url that is obtained from Open Access Button. In some cases these values are wrong and it would be helpful if the admins could update (or delete) the URL.

We should skip over OAB imports when the open_access_button_last_checked_at timestamp has been set and open_access_url is blank.  This indicates that an admin deleted the open_access_url.
Since the OAB import already ignores Publications that have an open_access_url set, the import will skip any Publications that have simply been edited by an admin (not deleted).
We may need to update the existing logic to not update open_access_button_last_checked_at if the url we receive from OAB is blank.  If we are receiving blank urls and updating the open_access_button_last_checked_at timestamp, these could be skipped over and we would not receive an OA url if one was added in the future.


[FEAT REQ.] - GeoMap Boundaries

I'd like to talk to the devs in private about ERAM GeoMap boundaries.

I appears there is no private message system on GitHub. Are you on VATSIM? If so, what is your name?-we could meet on the VATUSA Discord server or do you have some other proposed way to speak in private?


jenkins job names are different when running with the github org plugin, lets support this format too

[merge]


Title of page not appearing using FreshNavigationContainer after upgrade

The first page that loads in my app is using FreshNavigationContainer:
var mainPage = FreshPageModelResolver.ResolvePageModel<LoginPageModel>();
var navigationContainer = new FreshNavigationContainer(mainPage, "LoginContainer");

After updating Xamarin Forms  to <IP_ADDRESS>203 and FreshMvvm  to 2.2.4, the title does not show in my Xamarin Forms Android application but it used to do that before the upgrade.
I've tried using mainPage.Title = "Login"; and navigationContainer.Title = "Login"; to set them manually, but it makes no difference.
I've tried other Containers like the FreshMasterDetailNavigationContainer and the title does show so I'm thinking that the issue is only with FreshNavigationContainer.

The issue was with styling. For some reason, the BarBackgroundColor and BarTextColor and were both white. I had to change these in App.cs as the style in App.xaml that sets BarBackgroundColor andBarTextColor aren't being applied properly.


Msal for angular has enormous bundle size

Core Library
MSAL.js (@azure/msal-browser)
Core Library Version
13.2.0
Wrapper Library
MSAL Angular (@azure/msal-angular)
Wrapper Library Version
2.5.9
Public or Confidential Client?
Public
Description

The size of the msal bundle is 30% of my whole app (350KB+)
MSAL Configuration
No response
Relevant Code Snippets
No response
Identity Provider
Azure AD / MSA
Source
External (Customer)

@markostojkov We have been working on reducing the bundle size for the next version of MSAL. Can you please try upgrading to the beta versions of MSAL Browser and MSAL Angular and see if that helps?

@jo-arroyo You are very generous with your time, thanks for the quick response.
I installed
"@azure/msal-angular": "^3.0.0-beta.1",
"@azure/msal-browser": "^3.0.0-beta.1",
Cleaned up my node_modules and reinstalled all
Build with source maps and I still get 320KB
Is there anything else that I am supposed to do?
Here is a tree of the @azure folder in node modules https://pastebin.com/QH2Lh9aK
Here is my sourcemap

@markostojkov Thank you for providing the breakdown. Unfortunately, that is all we are able to reduce the bundle size at the moment. We are aware that this is a frustration to our customers, but we do not have further work prioritized in this regard.

@jo-arroyo I am no expert in angular, I am curious whether I am allowed as person not belonging to your organization to make a pull request?


getInitialNotification() returning error

Updated to 2.0.1 today and when I tried to use FCM.getInitialNotification() app returns the following error:
Cannot convert argument of type class android.content.Intent
Does anyone have the same issue?

I can confirm this

@evollu I think Intent is not serializable https://github.com/evollu/react-native-fcm/blob/master/android/src/main/java/com/evollu/react/fcm/FIRMessagingModule.java#L53

looking into this

fixed with v2.0.2

Seems to be fixed with v2.0.2


Pass custom arguments when creating an endpoint

I'd like to create an endpoint and be able to control, for example, the number of worker processes spawned by gunicorn. I'd like to be able to change this parameter along with instance type (the latter is already parametrizable in AWS CLI) to match SLAs. On the one hand, I want the cheapest instance, but on the other I'd like to have more than one worker process (to handle greater loads). Autoscaling incurs additional costs, so I'd rather have a single instance with as many workers as possible.
A concrete example: here is a config that contains the worker_processes. Currently, the only solution I see is to build several images that would differ only in the number of worker nodes.
But that's absurd, there has to be another way...
Right? ;)

You can achieve this by changing having the worker_processes config take a value from an environment variable, and then specify that environment variable in the Environment field of the CreateModel API.

@fm1ch4 thanks!


A hash of svg-file as a template variable

It would be convenient to have a variable {{hash}} in style templates for alternative cache busting:
sprite.svg?55db8b07 (instead of existing sprite-55db8b07.svg via bust: true)

@desigens If you want to roll your custom cache busting mechanism, what keeps you from disabling the builtin one (via bust: false) and send your cache busting {{hash}} variable into the rendering process as a custom templating variable? Of course you would have to use a customized template anyway ...

Thank you for rapid answer! Works like a charm:
variables: {
    hash: function() {
        return crypto.createHash('md5')
            .update(this.shapes.map(shape => shape.svg).join(), 'utf8')
            .digest('hex')
            .substr(0, 8);
    }
},

@desigens I'm glad it works out for you. Happy spriting! :)


the google-services.json file is missing

I can't run the application because there is no google-services.json file, is there a solution?

HI @AgungPrabowo
Sorry for the late reply, I have pushed a new commit with that file. It should work now.


updates selecting display to new architecture

@Incin so that's gonna be fixed during the related displays ticket since that's where selectable applies