Is there a way to have global CSS classes?

Let's say I have the following in a component:
const styles = theme => ({
  alignRight: {
    "margin-left": "auto"
  }
});

Now, I might want to align something to the right side in some other place too. Using the default css in js system, I then have to define 'alignRight' class in every single component that I want to use it in.
My question is, how can I make the same class available to multiple components without having to declare it everywhere?
The customization page doesn't seem to address this.

Yeah but that doesn't play well with withStyles, right? There's no way to refer to those "global" classes through the classes object in each component.

@AdityaAnand1 JSS will generate a deterministic class name. You are free to use wherever you like. it's global CSS, like you would do it with bootstrap class names.

I was looking for a solution to this as well. It's not really a MUI problem, but withStyles seems like the correct approach so maybe it could be tweaked to make this work.
This is the API I'm looking for (it doesn't quite work as is):
import { Theme, WithStyles, createStyles, withStyles } from '@material-ui/core/styles'
import classNames from 'classnames'
import React from 'react'

interface IProps extends WithStyles<typeof globalStyles>, WithStyles<typeof componentStyles> {}

// styles defined once per app and used on many components
const globalStyles = ({ spacing }: Theme) =>
    createStyles({
        pushLeft: { marginLeft: spacing.unit },
        pushRight: { marginRight: spacing.unit },
    })
// styles specific to `MyComponent`
const myComponentStyles = () =>
    createStyles({
        root: { color: 'red' },
    })

function MyComponent({ classes }: IProps) {
    // `classes` contains typed global and component CSS classes
    return

}

// HOC gets `globalStyles` and `myComponentStyles`.
export default withStyles(globalStyles)(withStyles(myComponentStyles)(MyComponent))

// Figure out a way to wrap this to only make one HOC per Component. Maybe HOF like:
const myWithStyles = createWithStyles(globalStyles)
myWithStyles(myComponentStyles)(MyComponent)

There's no way to refer to those "global" classes through the classes object in each component.

No, you can't. But what's the point, it's global? Here is an example:
https://github.com/mui-org/material-ui/blob/7d2fadfc7b90c958d10ef89a0a3ce58cc7ff939e/packages/material-ui/src/CssBaseline/CssBaseline.js#L8-L17

@oliviertassinari in the linked example you lose type safety of your global CSS classes, no?

@christophercliff Yes, you lose type safety, it's the point with anything global no?

What if I have '.globalClass'. What do I do in that case?
For that this doesn't work on my component.

className={classNames(classes.ButtonLeft, 'mr15')}

@kushalmahajan You have two options. 1. you change the class name generator to have global classnames https://material-ui.com/css-in-js/advanced/#global-css 2. you use the @global syntax of JSS to target global class names. Your example should be working.

yes, I was in fact looking at your example given above for 2nd option i.e.
 const styles = theme => ({
 '@global': {
      '.anyGlobalCss': { ...rules}
 }

This doesn't works. Then option 1 is in alpha...probably not looking into it.

@kushalmahajan Ok, here are two example:
import React from "react";
import PropTypes from "prop-types";
import { withStyles } from "@material-ui/core/styles";

const styles = {
  "@global": {
    ".root": {
      height: 100,
      width: 100,
      backgroundColor: "red"
    }
  },
  foo: {
    "&.bar": {
      height: 100,
      width: 100,
      backgroundColor: "blue"
    }
  }
};

function GlobalClass(props) {
  const { classes } = props;

  return (
    <React.Fragment>

      <div className={`${classes.foo} bar`} />
    </React.Fragment>
  );
}

GlobalClass.propTypes = {
  classes: PropTypes.object.isRequired
};

export default withStyles(styles)(GlobalClass);

https://codesandbox.io/s/5xxmxkx1wk

@@kushalmahajan It would be great to document it in our documentation: https://material-ui.com/css-in-js/advanced/#global-css. If you want to submit a documentation pull request, we would be happy to review it!

Sure. Will implement and document this weekend

@kushalmahajan It was taken care by @n-batalha, no need :).

Great!

in the material-UI documentation, they say that you can override or add global classes through the  component
const theme = createMuiTheme({   overrides: {     MuiCssBaseline: {       '@global': {         textUpperCase: {           textTransform: 'uppercase'         },       },     },   }, });

@kushalmahajan What is the modern way of doing this for v5?


Adding GroupLayers causes PSD to fail

This happens when there's group layers present in LayeredFile_8bit class. I've looked around for any cues and found out all GroupLayer classes (8bit, 16bit and 32bit) are missing a "self" parameter in their init method.
Although I did try to manually add this myself, it seemed to still cause issues, I'm willing to provide more information, although due to how much this script I've written relies on external sources, it'll require a bit of time, but I wouldn't mind c:
Also note that I've only attempted to open the psd's created using Krita/FireAlpaca, I don't have any PS license available unfortunately
If anyone wants to give it a quick read, you here's a hastebin available c:
https://hastebin.com/share/ivuzehozit.scss

Hey @Gofven, I had a look and figured out why krita doesn't like these file.
Krita appears to expect the group layers to have empty channels even if no channels are present (just zero length) which Photoshop does itself actually write out but doesn't require (unlike krita). Seems like I even thought about that at the time of writing.
0u, // Number of channels, photoshop does appear to actually write out all the channels with 0 length, we will see later if that is a requirement

As for the constructor not taking self that's just an error on my side in the stubs, I've created a ticket to address that: #112
I'll get a fix pushed soon and then you can grab the updated wheel from the CI directly until the next release comes out. Thanks for the flag!

I've merged this now and you can grab the update wheels (until the next release comes out) from here, at the bottom you will see a PhotoshopAPI_Py zipfile which will have all the wheels.
I plan on releasing 0.5.0 fairly soon (this or next week depending on complexity) so until then you could have a bin directory in your repo which contains the wheel until 0.5.0 is out including these changes :)
To then install them simply run:
py -m pip install PhotoshopAPI-0.4.0-cp311-cp311-win_amd64.whl <-- Replace this with your py version
making sure to first
py -m pip uninstall photoshopapi
Keep in mind that I added a check that no longer allows you to specify a width and height on a psapi.GroupLayer_*bit if you dont have a mask specified so you can just leave those fields blank :)

As for FireAlpaca, it doesnt seem to support ZIP compression in its internal parser, only RLE compression. If you want to write FireAlpaca64 compliant psd files you have to unfortunately use RLE which is larger in size like this:
# Set RLE compression on all layers of the file
layered_file.compression = psapi.enum.Compression.rle
layered_file.write(Path(os.path.join(str(export_path), f"{texture_set}.psd")))

I've looked through all your comments and installed the wheel provided, it works!
Also setting the compression to rle seemed to solve the issue with FireAlpaca!
Thank you so much for the quick response and solution you provided! I look forward to the upcoming release c:

No problem, thanks for reporting!

Hey @Gofven, just wanted to let you know that v0.5.0 is out now so you can just pip install PhotoshopAPI again. Do note that there was some breaking changes on the python side


Food for thoughts based on yesterday's last piloting session

Yesterday, we ran the "HCPh_LR" protocol. Since the real acquisitions will start tonight, I decided to gather all my comments/suggestions here instead of opening up a new issue for each of them. I let you decide what would be worth it and feasible to still include and account for in the final protocol.
T1 MPRAGE:

The adjustment volume is huge: it should be reduced (I would say to match the FoV).
The FoV cuts the nose (might be problematic in the AP/PA protocols): I think we never had this issue, but I would recommend, as a general and good practice, to always check the images you acquired in order to be sure they are not corrupted (be especially careful of wrap-around artifacts in that case).

DWI & fMRI:

Since the MPRAGE is now transverse, the FoV of the DWI and fMRI sequences should now be positioned on the scout (instead of the HR MPRAGE as before). Think about using the interpolated sagittal image (labeled as "1" in the scout) and not the few, thick slices ("2"). @esavary is aware.

DWI:

@oesteban: You may want to double-check the file used to define the directions of the diffusion vectors (see: Diff - Diffusion mode: Free - Import). The current file "multishell_hcph.dvs" (from February 2023) only allows 279 directions. However, you asked me to show Elodie and Alex how to make this sequence faster with only half of the directions in case you're running out of time. I had to import a more recent "multishell_hcph_actual.dvs" file (from May 2023) that allows to reduce the number of directions to 140 (only 2 options though: 6 or 140). I showed this procedure to @acionca, but you may want to double-check the files (I'm surprised we have to import another .dvs file instead of simply changing the number of directions from a single .dvs file).
Also, you may want to double-check the quality of the images we acquired with the reduced FoVPhase (71%) as suggested by Jean-Baptiste (it was mentioned in #198 but not clear whether you had already implemented it).

Checklist:
Back in June, we defined with @celprov and @esavary a short checklist of reminders that was supposed to come besides the SOPs (e.g., to be sure we think of unchecking the derivatives of the DWI sequence before running it). I don't know whether these comments were finally included in the SOPs, but that would be good to double-check.
Suggestions:
I was able to run the field maps from the "HCPh_LR" protocol. Besides, and although #194 was marked as "won't fix", I worked on increasing the spatial resolution of the field maps. I saved two options at the end of the "20231019-Piloting_HCPh_LR" protocol (which corresponds to the one I ran yesterday):

"field_map_HR": 1.3-mm isotropic field map (TR: 4,800 ms; number of slice: 105; FoVRead: 228 mm; FoVPhase: 73.6%; slice thickness: 1.3 mm; BaseResolution: 174 voxels; bandwidth: 1690 Hz/Px)
"field_map_HR1_2mm_BW": 1.2-mm isotropic field map with a reduced bandwidth (TR: 5,300 ms; number of slice: 114; FoVRead: 228 mm; FoVPhase: 73.7%; slice thickness: 1.2 mm; BaseResolution: 190 voxels; bandwidth: 1462 Hz/Px)
@oesteban please have a look at the corresponding field maps if you're still interested in leveraging the longer TR of these acquisitions to increase the spatial resolution (the "field_map_HR" was acquired as the 7. scan of yesterday's session, and the "field_map_HR1_2mm_BW" as the 21. scan) -- I don't know if such field maps would suit your expectations.

T1 MPRAGE:
* The adjustment volume is huge: it should be reduced (I would say to match the FoV).

I have checked this and the volume is fine - it looks huge because of the tilt, but there's nothing we need to operate here. Thanks for writing down and making sure we're not making a mistake.

* The FoV cuts the nose (might be problematic in the AP/PA protocols): I think we never had this issue, but I would recommend, as a general and good practice, to always check the images you acquired in order to be sure they are not corrupted (be especially careful of wrap-around artifacts in that case).

@acionca @esavary I guess this is something we may want to try to avoid, but I would give it low priority. As long as the nose does not overlap the back of the head (and it doesn't), this should be okay. It's also less problematic as now the AP/PA is readout direction (therefore more bandwidth, less problems with aliases).

DWI & fMRI:
* Since the MPRAGE is now transverse, the FoV of the DWI and fMRI sequences should now be positioned on the scout (instead of the HR MPRAGE as before). Think about using the interpolated sagittal image (labeled as "1" in the scout) and not the few, thick slices ("2"). @esavary is aware.

Thanks - already doing this :)

DWI:
* @oesteban: You may want to double-check the file used to define the directions of the diffusion vectors (see: Diff - Diffusion mode: Free - Import). The current file "multishell_hcph.dvs" (from February 2023) only allows 279 directions. However, you asked me to show Elodie and Alex how to make this sequence faster with only half of the directions in case you're running out of time. I had to import a more recent "multishell_hcph_actual.dvs" file (from May 2023) that allows to reduce the number of directions to 140 (only 2 options though: 6 or 140). I showed this procedure to @acionca, but you may want to double-check the files (I'm surprised we have to import another .dvs file instead of simply changing the number of directions from a single .dvs file).

I checked and everything is fine, you made the right call at the time.

* Also, you may want to double-check the quality of the images we acquired with the reduced FoVPhase (71%) as suggested by Jean-Baptiste (it was mentioned in #198 but not clear whether you had already implemented it).

I will double-check on my computer, but they look good on the scanner's console.

Checklist:
Back in June, we defined with @celprov and @esavary a short checklist of reminders that was supposed to come besides the SOPs (e.g., to be sure we think of unchecking the derivatives of the DWI sequence before running it). I don't know whether these comments were finally included in the SOPs, but that would be good to double-check.

Yes, those made it to the SOPs and were retained.

"field_map_HR": 1.3-mm isotropic field map (TR: 4,800 ms; number of slice: 105; FoVRead: 228 mm; FoVPhase: 73.6%; slice thickness: 1.3 mm; BaseResolution: 174 voxels; bandwidth: 1690 Hz/Px)

We finally stuck with these, I think they offer a great compromise with isotropic voxels - thanks for this!
Please reopen if there's something else we should action from here and I forgot. Thanks!


When creating substreams with testnets (tried sepolia), it is still using mainnet in the config

When creating substreams with testnets (tried sepolia), it is still using mainnet in the config.
Coauthor - @lucemans

This is when using substreams init and then the generated substreams.yaml does contain mainnet instead of the selected network, is that correct?

Yes
On Mon 3. Jun 2024 at 16:38, Matthieu Vachon @.***>
wrote:

This is when using substreams init and then the generated substreams.yaml
does contain mainnet instead of the selected network, is that correct?
—
Reply to this email directly, view it on GitHub
https://github.com/streamingfast/substreams/issues/480#issuecomment-2145374091,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJLKMZR23M7I3IHY5TVOA43ZFR5W5AVCNFSM6AAAAABIWUI5C2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVGM3TIMBZGE
.
You are receiving this because you authored the thread.Message ID:
@.***>


🚀 Feature: Improvement of OpenSSF Scorecard Score

🔖 Feature description
Hi, I'm Harshita. I’m working with CNCF and the Google Open Source Security Team for the GSoC 2024 term. We are collaborating to enhance security practices across various CNCF projects. The goal is to improve security for all CNCF projects by both using OpenSSF Scorecards and implementing its security improvements.
🎤 Context
As this project already has scorecard action, I'm here to increase the final score by going over each check. I've listed all of the checks where work needs to be done, in order of its criticality. I plan to submit each PR for each fix. Please let me know what you think and for which ones a PR is welcome that I will submit it ASAP.
Current Score: 6.3
Scorecard report: https://scorecard.dev/viewer/?uri=github.com/backstage/backstage
Here's a few checks we can work on to improve the project's security posture:

[ ] Dangerous-Workflow: Score = 0

untrusted code checkout 'refs/pull/${{ github.event.pull_request.number }}/merge': .github/workflows/automate_changeset_feedback.yml:30
untrusted code checkout '${{ github.event.pull_request.merge_commit_sha }}': .github/workflows/automate_merge_message.yml:31

[ ] Token-Permissions: Score = 0

The issue here is that many workflows doesn’t have a top-level read-only permissions block like present in the other workflows. Scorecard is quite severe in this check: a single workflow without top-level permissions gets a 0/10 for the check.

[ ] Vulnerabilities: Score = 0

After running the osv scanner locally, a significant amount of vulnerabilities were found that need to be fixed.
Open vulnerabilities are easily exploited by attackers and should be fixed as soon as possible.

[ ] Fuzzing: Score = 0

Integrating the project with OSS-Fuzz by following the instructions here. The most difficult one on the list, maintainers help, is highly appreciated. For example, helping in identifying the components where fuzz testing will be added.

[ ] Pinned-Dependencies: Score = 8

pip commands and container images in dockerfile are not pinned by hash, which results in a low score. But pinning these would introduce the risk of running outdated versions/images.

/cc @joycebrum @diogoteles08 @pnacht @nate-double-u
✌ Possible Implementation
No response
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

Thank you! 👍 definitely some opportunities here. Diving into each of them a bit
Dangerous-Workflow & Token-Permissions
Happy for any help with cleaning these up 👍. It might be hard to fix the dangerous workflow warning while maintaining the functionality, but worth a shot.
Vulnerabilities
Didn't dive into all of these but it seems like at least a majority of these are ones that we have ignored as they are not applicable, see for example
https://github.com/backstage/backstage/blob/master/packages/cli/.snyk
Best case would be if we did not need to maintain duplicate ignores as Snyk is our primary dependency scanning method.
Fuzzing
I've chatted with the fuzzing guys at KubeCon a couple of times, and at least since a year ago or so they do have at least minimal support for TypeScript. I'd say the need here is to start a ball rolling and then likely green light an effort from the CNCF side to add fuzzing to Backstage.
Pinned-Dependencies
A lot and potentially all of these are dependencies that we don't want to pin as they're part of documentation. We do recommend that users of the Dockerfiles pin the deps though, see for example https://github.com/backstage/backstage/tree/master/contrib/docker/minimal-hardened-image#pinning-digest


Added new api key + (see description of other changes/adds to code)

Changed news text size/added border radius to hero image/ added favicon to home page + added to image folder/ changed placeholder text for location search to 'Area'

reviewed


No "space" between response length and referer in audit index log

Hi,
In the audit.log, there is no space between response length and the referrer.
Like "4096-"  in the sample,  I expect it should be  "4096 -".
mysite.com <IP_ADDRESS> - - [24/May/2017:05:39:13 +0000] "GET /?cmd=/bin/sh HTTP/1.1" 403 4096- "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36"<PHONE_NUMBER>1.000000 - /var/log/modsec/20170524/20170524-0539/20170524-053913-14956043531.000000 0 4923.000000 md5:77693aae8f970b2be632583e171c9c51
I check the function toOldAuditLogFormatIndex, we may output space after "tellp()"
https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/transaction.cc#L1351
Thanks!

Hi @Pjack, Thanks for the bug report. It is now fixed - 4726912ec83c07d8482d9800dcea9b5c37c4540e


[FR] Handling missed executions

Hi!
Thanks for the plugin! Nice idea.
I was trying to use it in combination with Quickadd plugin to add monthly tasks to my Kanban board. My tasks are just cards in the Kanban plugin.
As far as I can see, there is no handling of missed executions, so it the computer is off or Obsidian closed at the time the cron job is triggered, it will fail to add the monthly tasks, not good.....
Is there any way to achieve this (handling missed executions to make sure something is really done at least at the first available opportunity) or do you have it in your future plans?

Hey @jornamon 👋
This should be already happening! If it isn't there is a bug here that I've got to fix.
The cron isn't strictly a cron but just a timer that runs every X interval. Each job is evaluated each time and the last time it was meant to run is calculated. If the last time it was meant to run is AFTER the last successful run then the module will execute the job.
If you find it isn't happening some reproduction steps would be most appreciated.

Thanks @cdloh! Yesterday I was testing the plugin but not this specifically and I got the impression it was ignoring missing executions. Let me test it properly and come back with a way to reproduce or confirming that is working.
Just to be sure of the expected behavior, if the cron is executed (which happens every Cron Interval minutes if Obsidian is running, right?) and finds a job which should have been executed since the last cron execution, it does it immediately, is this correct? What would happen if a job should have been executed several times, is it run once or all the missing executions get run?

Just to be sure of the expected behavior, if the cron is executed (which happens every Cron Interval minutes if Obsidian is running, right?) and finds a job which should have been executed since the last cron execution, it does it immediately, is this correct?

That's correct.

What would happen if a job should have been executed several times, is it run once or all the missing executions get run?

It'll only run once. It'll then update the last update time and things will continue normally from then on.
I thought about making it run for every instance it was meant to run between the last run and the current time but decided against it to keep it simple.

I thought about making it run for every instance it was meant to run between the last run and the current time but decided against it to keep it simple.

I think this is a good design decision, I just wanted to make sure I will test against the intended behavior. Maybe if the the plugin keeps growing, you could let the jobs to be configured for how to handle missed executions (skip, run once, run all), but I agree that run once is the best "default" behavior.

Yeah, it definitely works as expected. The first day I was testing with jobs scheduled every minute and somehow I got the wrong impression.
Thanks again for the plugin and for your time. I don't think people realize yet how powerful this plugin can be, specially combined with QuickAdd 🚀

Thanks for the kind words @jornamon !
Glad to hear it's all working as expected. Let me know if you hit any bugs in the future!


Types (e.g. TableMetadata) disallow valid API usage

Environment details

OS: OSX 10.13
Node.js version: v11.7.0
npm version: 6.5.0
@google-cloud/bigquery version: 2.0.6

Steps to reproduce
Write this code:
dataset.createTable(
      'name'
      {
        view: {
          query: 'any SQL string',
          useLegacySql: false,
        },
      } as TableMetadata,
    )

The Typescript compiler will complain and say that friendlyName is required, and view must be a string. The types in the API documentation say that friendlyName is optional, and view is an object with some properties.
I discovered this when updating from v1.3 of the library to v2. I'd expect my existing, working library calls to pass type checking, since everything still works if I disable type checking and run the code.

@JustinBeckwith do we anticipate getting proto files for BQ anytime soon? I can definitely create interfaces for the various types across the client, but if protos are expected soon, it might be better to wait and just generate them.

I do not believe that's on the horizon, but @tswast and @shollyman will know best.

Seth and I have a meeting about this very topic. The answer is probably eventually, but not soon. We do plan to have a subset of protos available sooner, though.

@callmehiphop you can probably yank any interfaces you need from here:
https://github.com/googleapis/google-api-nodejs-client/blob/master/src/apis/bigquery/v2.ts

@JustinBeckwith woo, thanks for the link, that should save me quite a bit of time.

What's the significance of having proto files? I'm not even sure what a proto file is.

Yes! It is intended to do all the things. Specifics here are super helpful. Are you concerned with missing typescript interfaces, or missing API endpoint support?

I'm only concerned with incomplete/missing typescript types. I haven't had any new, specific issues, despite the types being incomplete. I only know they're incomplete because I considered completing them, and found gaps.

What's the significance of having proto files? I'm not even sure what a proto file is.

You're right that from a developer perspective, proto files aren't relevant.
If you're still curious, proto files (protocol buffers) are how Google defines all of our APIs. You can browse the ones that are public at https://github.com/googleapis/googleapis. The reason they'd be relevant here is that a proto file provides a schema for all the objects in the API, so it could be translated to a typescript schema.


Fix localprod after moving to dev

Is is a fix for https://github.com/OpenSlides/OpenSlides/pull/6537
The directory localprod was moved into the directory dev. So the config has to be changed.

Closed in favor of https://github.com/OpenSlides/OpenSlides/pull/6559


expose hidden cells in the documentation

The hidden cells in the docs make some of the examples difficult (or impossible to run)
These need to be exposed

solved in #488


Proposal Logo Shelves

Hello, I want to contribute to this awesome project, and I have a new logo design for you, if you allowed I will send to you :)

Heck yeah. I'll take any graphics. 😅


Little Flocker is now Beta

Hey @drduh just wanted to drop a line and let you know LF is at beta 2 now, looking pretty good, lots of good user feedback to help fix bugs. Not much new to put into beta 3 yet, which is a good sign.

Thanks a lot. I have some ideas in mind about re-arranging the guide in a way to showcase the various available Mac security software, maybe with a feature comparison matrix, or the like. I'll be sure to take a look at LF soon and include it more formally.

Just to let you know that the Little Flocker link is dead. It looks like the owner moved from github to gitlab and decided to close the source and charge for the software

Hello @drduh, Little Flocker is now out out of beta, and is now at version 1.0.0..


Can't find craft.so

Installed on Ubuntu 18.04 the version tsduck_3.17-1189_amd64.deb.
Tried to do: tsp -I craft
-> tsp: craft.so: cannot open shared object file: No such file or directory
Looking for:  locate tsplugin_craft -> nothing found
But other plugins seem to exist:
locate tsplugin_
/usr/bin/tsplugin_aes.so
/usr/bin/tsplugin_analyze.so
/usr/bin/tsplugin_bat.so
/usr/bin/tsplugin_bitrate_monitor.so
/usr/bin/tsplugin_boostpid.so
/usr/bin/tsplugin_cat.so
/usr/bin/tsplugin_clear.so
/usr/bin/tsplugin_continuity.so
/usr/bin/tsplugin_count.so
/usr/bin/tsplugin_datainject.so
/usr/bin/tsplugin_decap.so
/usr/bin/tsplugin_dektec.so
/usr/bin/tsplugin_descrambler.so
/usr/bin/tsplugin_drop.so
/usr/bin/tsplugin_duplicate.so
/usr/bin/tsplugin_dvb.so
/usr/bin/tsplugin_eit.so
/usr/bin/tsplugin_encap.so
/usr/bin/tsplugin_file.so
/usr/bin/tsplugin_filter.so
/usr/bin/tsplugin_fork.so
/usr/bin/tsplugin_hides.so
/usr/bin/tsplugin_history.so
/usr/bin/tsplugin_hls.so
/usr/bin/tsplugin_http.so
/usr/bin/tsplugin_inject.so
/usr/bin/tsplugin_ip.so
/usr/bin/tsplugin_limit.so
/usr/bin/tsplugin_merge.so
/usr/bin/tsplugin_mpe.so
/usr/bin/tsplugin_mpeinject.so
/usr/bin/tsplugin_mux.so
/usr/bin/tsplugin_nit.so
/usr/bin/tsplugin_nitscan.so
/usr/bin/tsplugin_null.so
/usr/bin/tsplugin_pat.so
/usr/bin/tsplugin_pattern.so
/usr/bin/tsplugin_pcradjust.so
/usr/bin/tsplugin_pcrbitrate.so
/usr/bin/tsplugin_pcrextract.so
/usr/bin/tsplugin_pcrverify.so
/usr/bin/tsplugin_pes.so
/usr/bin/tsplugin_play.so
/usr/bin/tsplugin_pmt.so
/usr/bin/tsplugin_psi.so
/usr/bin/tsplugin_reduce.so
/usr/bin/tsplugin_regulate.so
/usr/bin/tsplugin_remap.so
/usr/bin/tsplugin_rmorphan.so
/usr/bin/tsplugin_rmsplice.so
/usr/bin/tsplugin_scrambler.so
/usr/bin/tsplugin_sdt.so
/usr/bin/tsplugin_sections.so
/usr/bin/tsplugin_sifilter.so
/usr/bin/tsplugin_skip.so
/usr/bin/tsplugin_slice.so
/usr/bin/tsplugin_spliceinject.so
/usr/bin/tsplugin_stuffanalyze.so
/usr/bin/tsplugin_svremove.so
/usr/bin/tsplugin_svrename.so
/usr/bin/tsplugin_t2mi.so
/usr/bin/tsplugin_tables.so
/usr/bin/tsplugin_teletext.so
/usr/bin/tsplugin_time.so
/usr/bin/tsplugin_timeref.so
/usr/bin/tsplugin_tsrename.so
/usr/bin/tsplugin_until.so
/usr/bin/tsplugin_zap.so

Hi @DenisVounckx,
The plugin craft is new. It is included in version 3.18, as indicated in the release notes. So, it is normal you cannot find it in version 3.17.
Version 3.18 is still under development but stable. You can easily rebuild the .deb installer from the source repo, as described here. The process is straightforward: install the pre-requisite building tools, clone the repo, build.
On Ubuntu 18.04, this is as simple as:
apt install git g++ dpkg-dev doxygen dos2unix graphviz curl pcscd libpcsclite-dev libcurl4 libcurl4-openssl-dev
git clone https://github.com/tsduck/tsduck.git
cd tsduck
make deb

And you collect the .deb in the installers subdirectory.

Hi @
Thanks for the rapid response.
Trying to build from source I have 2 errors:
[CXX] tsPacketizer.cpp
In file included from /usr/include/string.h:494:0,
                 from /usr/include/c++/4.9/cstring:42,
                 from tsPlatform.h:850,
                 from tsMPEG.h:37,
                 from tsPacketizer.h:36,
                 from tsPacketizer.cpp:34:
In function 'void* memset(void*, int, size_t)',
    inlined from 'bool ts::Packetizer::getNextPacket(ts::TSPacket&)' at tsPacketizer.cpp:207:44:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:67:32: error: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror]
       __warn_memset_zero_len ();
                                ^
cc1plus: all warnings being treated as errors
../../Makefile.common:903: recipe for target 'release-x86_64/tsPacketizer.o' failed

To get pasted I disabled the Werror flag.
But then during linking I got following error:
  [LD] release-x86_64/tsanalyze
/home/dvo/tsduck/src/libtsduck/release-x86_64/tsduck.so: undefined reference to `__warn_memset_zero_len'
collect2: error: ld returned 1 exit status
../../Makefile.common:910: recipe for target 'release-x86_64/tsanalyze' failed
make[2]: *** [release-x86_64/tsanalyze] Error 1

What version of GCC do you have? Did you install some non-standard version of the compiler or the library?
It used to work on Ubuntu 18.04 with the "standard" GCC (I can't remember which version it was and now I use Ubuntu 19.04 with GCC 8.3.0). The code which triggers the error has not changed for years.
I ask the question about the compiler version because this really looks like a compiler error. The code is:
    // Fill the packet payload
    while (remain_in_packet > 0) {
        ....
            if (do_stuffing) {
                break;
            }
        ....
    }

    // Do packet stuffing if necessary.
    ::memset(data, 0xFF, remain_in_packet);  <--- error reported here

The error complains about warning: memset used with constant zero length parameter.
Here, the length parameter is remain_in_packet. The previous while (remain_in_packet > 0) may give the impression that remain_in_packet is always zero at the end of the loop. But, in fact, the break on do_stuffing proves the contrary.
So, this really looks like a compiler pretending to be very clever but failing miserably. A buggy compiler.

Hi Thierry,
Trying with the default gcc on Ubuntu 18.04 (which is now gcc version 7.4.0) I received following messages:
#error "GCC versions 6 and 7 are broken and fail to properly handle some template substitutions, use another version of GCC, see https://tsduck.io/doxy/building.html#reqraspbian"

So I tried to install gcc 4.9 via "apt install gcc-4.9 g++-4.9" but didn't work so fall back to the following procedure
This gave me "gcc version 4.9.3".
And indeed with compiler bug around memset. As a quick workaround changed the line to:
if (remain_in_packet > 0) ::memset (data, 0xFF, remain_in_packet);

And then it compiles. Will try later today with gcc 4.9.4
Thanks a lot for the help !

Glad to hear that it works now.
Just out of curiosity, which compiler did you use when you got the "memset" error?
I have never seen this and I am curious to understand where does it come from.

Glad to hear that it works now.
Just out of curiosity, which compiler did you use when you got the "memset" error?
I have never seen this and I am curious to understand where does it come from.
On Ubuntu 18.04, you can also use GCC 8, see https://packages.ubuntu.com/bionic/gcc-8. I use GCC 8 on Ubuntu 19.04 and GCC 9 on Fedora 30, they are all fine.

Hi Thierry,
When the memset error appeared, I was using gcc version 4.9.3 (Ubuntu 4.9.3-13ubuntu2).
Thanks for the gcc 8 tip.

Hi @DenisVounckx,
For the record, the compilation is fine for me with GCC 4.9.3 (Raspbian 4.9.3-14) on my Raspberry Pi. This is not the same compiler because this is an ARM back-end. But the type of error you got is typically detected by the front-end. So, I would have expected to get the same error on ARM. For instance, GCC 6.x and 7.x have front-end bugs in the template substitutions and the same errors appear on Intel and ARM. So, your GCC 4.9.3 seems a weird one.


Bug "App cutover to App Center"

When trying to upload our generated builds using the HockeyApp plugin for jenkins, we started receiving an error response. This is a copy of the jenkins job:

Got unexpected response code from HockeyApp: 400
{"errors":{"app":["App cutover to App Center"]}}
Build step 'Upload to HockeyApp' marked build as failure

I've verified that the app was actually built, and that the upload step is failing.
I don't know when the issue started as we don't do daily builds, we noticed yesterday.
Thanks

Same problem here. Worked perfectly until 2020-02-20 15:30 UTC when our upload failed for the first time and has been failing ever since.
DEBUG	Uploading: https://rink.hockeyapp.net/api/2/apps/REDACTED/app_versions/upload
ERROR	Upload failed: StatusCodeError: 400 - "{\"errors\":{\"app\":[\"App cutover to App Center\"]}}"

POST request form-date being:
  status: 2,
  notify: 1,
  notes: "REDACTED long string with changelog",
  notes_type: 0,
  commit_sha: "REDACTED git hash",
  build_server_url: "https://REDACTED",
  repository_url: "https://REDACTED",
  ipa: REDACTED

Same problem here, built one on Friday the same way and did not change anything on the script side of CircileCi.  Monday build fails to deliver the RC to appcenter due to this JSON error
{"errors":{"app":["App cutover to App Center"]}}

Same here. Does it mean that we should move from hockey app and use the appcenter command line tool ?

HockeyApp has been completely retired, so yes that would be the proper course of action to take.

They said we were okay with that and that it would not be killed off just yet.  But apparently someone turn the switch off.

This was not marked as deprecated. Not cool.

facing same issue  {"errors":{"app":["App cutover to App Center"]}}

I too am facing this issue :(

I am also facing same issue how to we upload build to App Center. I have tried App Center pluging but luck

I have two questions for the App Center team:

Where (if there was any) was the communication that this upload functionality (in my case the puck command-line utility for submitting builds) was in effect deprecated, and turned off seemingly without warning on 2020-02-20?

If this is in fact a bug, and the intention was that the Hockey API shouldn't be returning this error response, what is the timeline for a restoration of the service?

HockeyApp has been shut down, consequently the HockeyApp plugin using the old API doesn't work anymore. There's a new Jenkins plugin for App Center. If you're facing any issues please create a ticket in the Jenkins issue tracker.
The steps required to upload to App Center via API are described in our documentation.


[FEATURES] Support image encoder with image caption as example

Support image encoder with image caption as example.
Try model: BLIP with Salesforce/blip-image-captioning-bas
Discussion:

the name of arch_type: visionEncoder_decoder
format the data with image_text
Should we generate another class inherited from HFEncoderDecoder?

I have fixed the code style issues.
Regarding to "[Question] line 286, 294: will this cause problem for inference of encoder-decoder models?", the pad_token_id argument is added to the kwargs, so it will not cause the problem for inference of encoder-decoder models.
I will add more features in this pr.


NumberFormatException: For input string: "" under radix 16

  [INFO] >> Caused by: java.lang.NumberFormatException: For input string: "" under radix 16
  [INFO] >>     at java.lang.NumberFormatException.forInputString (NumberFormatException.java:67)
  [INFO] >>     at java.lang.Integer.parseInt (Integer.java:672)
  [INFO] >>     at org.eolang.jeo.representation.xmir.HexString.decodeAsInt (HexString.java:87)
  [INFO] >>     at org.eolang.jeo.representation.xmir.XmlClassProperties.version (XmlClassProperties.java:122)
  [INFO] >>     at org.eolang.jeo.representation.xmir.XmlClassProperties.toBytecodeProperties (XmlClassProperties.java:133)
  [INFO] >>     at org.eolang.jeo.representation.xmir.XmlBytecode.bytecode (XmlBytecode.java:87)
  [INFO] >>     at org.eolang.jeo.representation.XmirRepresentation.toBytecode (XmirRepresentation.java:143)
  [INFO] >>     at org.eolang.jeo.Assemble.apply (Assemble.java:59)
  [INFO] >>     at org.eolang.jeo.LoggedTranslation.apply (LoggedTranslation.java:84)
  [INFO] >>     at org.eolang.jeo.BachedTranslator.translate (BachedTranslator.java:71)
  [INFO] >>     at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:197)
  [INFO] >>     at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:197)
  [INFO] >>     at java.util.stream.ReferencePipeline$2$1.accept (ReferencePipeline.java:179)
  [INFO] >>     at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:197)
  [INFO] >>     at java.util.Spliterators$ArraySpliterator.forEachRemaining (Spliterators.java:1024)
  [INFO] >>     at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509)
  [INFO] >>     at java.util.stream.ForEachOps$ForEachTask.compute (ForEachOps.java:291)
  [INFO] >>     at java.util.concurrent.CountedCompleter.exec (CountedCompleter.java:754)
  [INFO] >>     at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:387)
  [INFO] >>     at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1312)
  [INFO] >>     at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1843)
  [INFO] >>     at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1808)
  [INFO] >>     at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:188)

I'm getting this after the following element in XMIR:
<o base=".string" name="signature">
               <o base=".eolang">
                  <o base=".org">
                     <o base="Q"/>
                  </o>
               </o>
               <o as="0" base=".bytes">
                  <o base=".eolang">
                     <o base=".org">
                        <o base="Q"/>
                     </o>
                  </o>
                  <o base="org.eolang.bytes" data="bytes"/>
               </o>
            </o>

This line (<o base="org.eolang.bytes" data="bytes"/>), I believe, is a legal representation of an empty chain of bytes. It must be correctly processed by JEO.

@volodya-lombrozo please, check this out. I found it here: https://github.com/objectionary/hone-maven-plugin/actions/runs/10663836285/job/29553850114

@volodya-lombrozo btw, jeo:disassemble generates this (which is correct):
...
         <o abstract="" name="j$foo-KClE">
            <o base="int" data="bytes" line="592052178" name="access">00 00 00 00 00 00 00 00</o>
            <o base="string" data="bytes" line="859086335" name="descriptor">28 29 44</o>
            <o base="string" data="bytes" line="821201258" name="signature"/>
...

@yegor256 I'm still trying to reproduce the problem now. But to be honest, <o base="org.eolang.bytes" data="bytes"/> isn't such a good object. What this originally should be? null value?  0 value? If it's an object, it's ok, but if its a primitive value like int or byte - we can't allow it.

@volodya-lombrozo this EO code:
send --

must render in XMIR as such:
<o base="send">
  <o base="org.eolang.bytes" data="bytes"/>
</o>

It's perfectly legal.

@yegor256 I've finally checked the entire logs of this job https://github.com/objectionary/hone-maven-plugin/actions/runs/10663836285/job/29553850114
And it seems, that you completely skip opeo step.
From logs:
....
jeo:disassemble
....
eo:xmir-to-phi
....
eo:phi-to-xmir
....
jeo:assemble
....

Here is the problem. xmir-to-phi (instead of just printing PHI expressions,) also dramatically changes the original XMIR ("optimises" it), so the new representation of XMIR isn't suitable for jeo.

@volodya-lombrozo yes, this is true, but the problem still exists: jeo:assemble must understand this XMIR correctly.

@yegor256 It's not jeo:disassemble produces it, it eo:xmir-to-phi and eo:phi-to-xmir. If you run your pipeline without them:
....
jeo:disassemble
....
....
jeo:assemble
....

You will see, that everything works fine without exceptions.

@volodya-lombrozo checkout this repo, run mvn clean test and then see the content of target/simple-app/target/generated-sources/ directory. In the jeo-disassemble you will find Hello.xmir file with this line inside: <o base="string" data="bytes" line="1094858495" name="signature"/>. If I'm not mistaken, this file is generated by jeo:disassemble.

@yegor256
git clone git@github.com:objectionary/hone-maven-plugin.git
cd hone-maven-plugin
mvn clean test

[ERROR] Tests run: 7, Failures: 2, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE

find . -name "Hello,xmir"
<nothing is found>

@volodya-lombrozo I'm getting this:
$ find . -name Hello.xmir
./target/simple-app/target/generated-sources/unphi/Hello.xmir
./target/simple-app/target/generated-sources/jeo-disassemble/Hello.xmir

@volodya-lombrozo do you have docker installed?

@yegor256 Yes, I have:
docker --version
Docker version 20.10.11, build dea9396

@yegor256 Maybe It's a valid XMIR, but it has invalid format for jeo.

@volodya-lombrozo we have only one XMIR format :) It must work for all tools. Empty byte-arrays are valid elements of EO/XMIR.

@volodya-lombrozo try to use this EO program:
# this is object.
[] > app
  QQ.io.stdout > @
    ""

Then, compile it with eoc. You will get this app.xmir:
<?xml version="1.0" encoding="UTF-8"?>
<program dob="2024-05-22T13:54:22"
         ms="84"
         name="app"
         revision="48e8be4"
         source="/Volumes/sec/code/tmp/eo/app.eo"
         time="2024-09-02T13:22:41.335753Z"
         version="0.38.2"><!--This is XMIR - a dialect of XML, which is used to present a parsed EO program. For more information please visit https://news.eolang.org/2022-11-25-xmir-guide.html-->
   <listing># this is object.
[] > app
  QQ.io.stdout > @
    ""
</listing>
   <errors>
      <error check="comment-length-check" line="1" severity="warning">Comment must be at least 64 characters long</error>
      <error check="comment-start-character-check" line="1" severity="warning">Comment must start with capital letter</error>
   </errors>
   <sheets/>
   <license/>
   <metas/>
   <objects>
      <o abstract="" line="2" name="app" pos="0">
         <o base="QQ" line="3" pos="2"/>
         <o base=".io" line="3" method="" pos="4"/>
         <o base=".stdout" line="3" method="" name="@" pos="7">
            <o base="string" data="bytes" line="4" pos="4"/>
         </o>
      </o>
   </objects>
</program>

See the line:
<o base="string" data="bytes" line="4" pos="4"/>

@volodya-lombrozo please, fix the bug then. I can't proceed with the HONE plugin because of it. Also, keep in mind that HONE plugin is going to use this pipeline for now: Bytecode -> JEO -> Normalizer -> JEO -> Bytecode. No OPEO involvement for now.

@yegor256 How? There is no bug in jeo. It's a bug in phi/unphi that breaks the format of XMIR. Let me try to explain it differently.

jeo:disassemble generates the following "signature":

<o base="string" data="bytes" line="727201432" name="signature"/>

phi/unphi transforms this signature to the something like the following (approximately):

<o base=".string" name="signature">
               <o base=".eolang">
                  <o base=".org">
                     <o base="Q"/>
                  </o>
               </o>
               <o as="0" base=".bytes">
                  <o base=".eolang">
                     <o base=".org">
                        <o base="Q"/>
                     </o>
                  </o>
                  <o base="org.eolang.bytes" data="bytes"/>
               </o>
            </o>

jeo:assemble still expects

<o base="string" data="bytes" line="727201432" name="signature"/>

or maybe I don't understand something?

@volodya-lombrozo now I understand. The problem is that jeo:disassemble uses old representation of objects in XMIR. This is not valid:
<o base="string" data="bytes" line="1739939615" name="descriptor">28 29 56</o>

It should be this:
            <o base=".string" name="descriptor">
               <o base=".eolang">
                  <o base=".org">
                     <o base="Q"/>
                  </o>
               </o>
               <o as="0" base=".bytes">
                  <o base=".eolang">
                     <o base=".org">
                        <o base="Q"/>
                     </o>
                  </o>
                  <o base="org.eolang.bytes" data="bytes">28 29 56</o>
               </o>
            </o>

This is how it looks in EO:
Q.org.eolang.string > descriptor
  Q.org.eolang.bytes:0
    28-29-56

We switched to this new format a few minor versions of EO ago. Now, we can't do base="string" or base="int".

@yegor256 Do you have documentation on how XMIR elements should look? Maybe a specification, decisions made, or at least something that I can use to develop these transformations?
Moreover, I need a clear understanding—not of the "initial" representation of XMIR. As I’ve already mentioned, the eo-maven-plugin applies many different optimizations that change this XMIR dramatically.
https://github.com/objectionary/jeo-maven-plugin/issues/687#issuecomment-2324297355
When you do phi/unphi, the eo-maven-plugin actually applies these optimizations.
https://github.com/objectionary/eo/issues/3257#issuecomment-2272882054
I don’t think you can predict how XMIR will look after these optimizations.
Do you expect me to predict it?
Moreover, tomorrow you could invent an entirely different "view" on XMIR and how some objects should be represented, and all my findings might be thrown into the bin. I’ve already done this "rewriting" many times:
https://github.com/objectionary/jeo-maven-plugin/issues/656
https://github.com/objectionary/jeo-maven-plugin/issues/627
That’s only in jeo-maven-plugin. I’m not even mentioning opeo-maven-plugin.
So, to be honest, I’m extremely frustrated with these requirements. And even if you insist on them and decide to "rewrite" it again, I can do it, but you should be aware that it might take a significant amount of time.

@volodya-lombrozo I understand. How about we make JEO more strict by writing the documentation for it. Basically, we must explain to the users of JEO-output what is possible to do with it in order to keep it understandable by JEO. If you publish such a documentation, we will make sure our normalizations/optimizations send to JEO only the XMIR it is prepared for.

@yegor256 I agree. What do you think if we move a bit further and invent some sort of XSD for it?

@volodya-lombrozo XSD is a rather weak format, it won't allow you to define complex rules. It's mostly about types of data. Maybe a collection of XPath assertions (both "positive" that must be in the incoming XMIR and "negative" that are not allowed). Just an idea.

@yegor256 Is this issue still relevant? I moved all the conclusions made in this discussion to a separate issue: https://github.com/objectionary/jeo-maven-plugin/issues/716


Create a brew install for macos

As we have done with snaps, we should with Brew and maybe chocolatey for Windows. These should be automated using goreleaser.

https://github.com/jasonBirchall/crypto/commit/d8602a07fe6c05e9ba52fb72a7908ab58c8d83e9


Iot policystore client

This PR contains an implementation of the client for the IoT policystore along with some simple test cases. The test cases are perhaps overkill but I wanted to include them because I'm not running the full app and the test cases provide me with some reassurance that I'm not pushing completely broken code.
Following this PR will be a second one containing the stream encoder client, separated for clarity.
I know @jordibuj you are primarily concerned with test coverage for the "business logic" in the redux core, so I'm hoping this implementation is straightforward for you to integrate (as redux makes my head hurt). Any questions obviously please let me know

@jordibuj - I couldn't add you as a reviewer on https://github.com/thingful/decodev2/pull/1 - but that is the second part of my proposed changes. Hopefully you can see that PR as well by following the above link

Mostly looks good to me, just 2 comments.

If the ‘meta’ field in an error contains data that should be shown to an end user as part of an error message, then it should be added as another field in the PolicystoreError. Can you confirm if this is the case?
Are those typdefs in the comments used by your IDE, or generated by some tool by exploring the service API? If not, I would prefer not to have them because the real documentation is already available in the service (https://decodeproject.github.io/iot-policystore-docs/).

Same comments apply for the other service

@jordibuj - The meta information is probably not relevant to the end user, it's more information that would be useful for the app developer. An example of it's content might be:
{"twirp_invalid_route":"POST /twirp/decode.iot.policystore.PolicyStore/ListEntitlementPoliciez"}

for a request that happened to hit an invalid URL or perhaps another example might be a specific error message related to the DB connection.
I can remove those typedef statements if you'd like - I only added them as a courtesy to whoever was implenting the redux logic to use these clients to try and make it as easy as possible. I think my editor (VSCode) also has the capacity to use these definitions for some autocomplete stuff, but I haven't tested that so I've no idea really.

Thank you @smulube for removing the typedefs. Regarding the meta field, I agree it's not necessary to append it to the PolicystoreError

closing to squash into fewer commits


j-rate output

j-rates names are the "CESM" names, such as "jO2_b=userdefined,"
For music box output we should figure out a strategy for naming these reactions and matching them to the environmental conditions files.

Closing as this does not apply to the new version of chemistry cafe.


update readme

update readme

(Jove Github Bot) moved this ticket out of the GitHub project(up to 1200 tickets for one project).


Download file attachments to a default location.

You have tested this PR on:

[ ] Windows
[x] Linux/Ubuntu
[ ] macOS

Merged, thanks @abhigyank. We should document this in the web app/usage guide somewhere.


Look for aglio binary in project local Node modules

This adds the projects local node_modules/.bin folder to the env PATH, so that if the user only has Aglio installed locally for the project, the plugin will still work.
Also fixes an issue with how the env was passed to exec.

Thanks!


Change subscription uri

index.tsx:28 should be: service: 'wss://bsky.network', rather than service: 'wss://bsky.social',

Thanks for letting me know. I made this as a quick PoC one afternoon. Don't really have any interest in fixing it. Feel free to submit a PR if you like, or just fork it / use as inspiration for your own version :-)


Create widget screenshots

idk if I'm going to upload them to the git repository, but I do have the screenshots taken and uploaded to App Store Connect.


Reduce cron job frequency for emulation regression

The nightly frequency of emulation regression testing often doesn't finish in one day due to the size of data and slowness of RNN training.  Switch to twice weekly (W, F) to keep tabs on behavior.

Resolved by https://github.com/ai2cm/vcm-workflow-control/pull/127


For B2C and Desktop clients do we have to use http://localhost

For B2C and Desktop clients do we have to use http://localhost for system browser for production environments as well. Somehow it is not working with below as redirect URI, it works only with http://localhost (non ssl)

https://login.microsoftonline.com/common/oauth2/nativeclient
https://localhost
[Enter feedback here]

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

ID: b752cf45-0564-8145-d260-2cb5a9847878
Version Independent ID: c8845ffb-2d1b-ce46-5543-d2d9c9ad510f
Content: Configure authentication in a sample WPF desktop application by using Azure Active Directory B2C
Content Source: articles/active-directory-b2c/configure-authentication-sample-wpf-desktop-app.md
Service: active-directory
Sub-service: b2c
GitHub Login: @kengaderdus
Microsoft Alias: kengaderdus

@kapil-george-by , Thank you for your query . We will investigate and update the thread.

@kapil-george-by Redirect URI must be matching with the reply_url parameter in the authentication request to work. If the reply_url parameter matches with the Redirect URI configured in the registered app, a token is posted to this URL/URI after successful authentication.


🚧Project and ci improvements

Complete The Item Below

[X] I have updated the title without removing the 🚧 emoji.

Description
Make various improvements throughout the project such as ide config, cicd workflows, and more.
Acceptance Criteria

[ ] Workflows updated
[ ] IDE config updated
[ ] Readme updated

ToDo Items

[X] Change type labels added to this issue.  Refer to the Change Type Labels section below.
[X] Priority label added to this issue.  Refer to the Priority Type Labels section below.
[X] Issue linked to the correct project (if applicable).
[X] Issue linked to the correct milestone (if applicable).
[X] Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies
No response
Related Work
No response
Additional Information:
Change Type Labels

Change Type
Label

Bug Fixes
🐛bug

Breaking Changes
🧨breaking changes

New Feature
✨new feature

CICD Changes
♻cicd

Code Doc Changes
🗒documentation/code

Product Doc Changes
📝documentation/product

Priority Type Labels

Priority Type
Label

Low Priority
low priority

Medium Priority
medium priority

High Priority
high priority

Code of Conduct

[X] I agree to follow this project's Code of Conduct.

[run-sync]

[run-sync]


a temporary fix to work with Rocket

see #80

Thanks for the PR!
I've fixed the underlying issue now, so we should no longer need this patch.


Add option to only display when overlay is toggled

Several users asked about this specific option, hoping it would be included as a feature, as the two step process to show / hide the display is cumbersome, should be easy enough to add!

Added in latest Release!

It's perfect! 100% essential tool for vive.


Error get hostedcontents notes-chat

I'm trying to get bytes of hosted content by application.
I receive information normally from<EMAIL_ADDRESS>but if i try to get bytes from<EMAIL_ADDRESS>I get response status 403.
I checked the permissions according to the documentation(Application | Chat.Read.All, Chat.ReadWrite.All)
for example with oneOnOne chats all work normal
{     "error": {         "code": "Forbidden",         "message": "UnknownError",         "innerError": {             "date": "2024-02-01T12:03:46",             "request-id": "eaa13c7c-4916-43ee-8329-17276df74097",             "client-request-id": "eaa13c7c-4916-43ee-8329-17276df74097"         }     } }

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

ID: f67cabe4-bade-9a07-90ec-15adaeab3de2
Version Independent ID: dfbbddfe-f113-1ae1-9d21-77ab976ddc20
Content: Get chatMessageHostedContent - Microsoft Graph v1.0
Content Source: api-reference/v1.0/api/chatmessagehostedcontent-get.md
Product: microsoft-teams
Technology: microsoft-graph
GitHub Login: @RamjotSingh
Microsoft Alias: MSGraphDocsVteam

We checked this at our end for One-One chat and group chat, it is working fine in both cases.
Below is a screenshot for Group chat.

Could you please confirm if you are still facing this issue?

chat_id<EMAIL_ADDRESS>This is the user's chat with himself (notes)

Currently there is no Graph API support for chat with self.

Currently there is no Graph API support for chat with self.

But receiving messages for example works fine. The problem is permissions. I can receive messages with application permissions, and if the message contains hosted content, it is only available with delegated permissions. I think this is strange.

We will check this internally and get back to you.

Hello @ZUS666 - Sorry for delay in response.
We area actively checking the updates on your issue with engineering team and let you know the updates if any.

@ZUS666 - We received the following update from engineering team.
The hosted content for self chat in application context is not currently supported.


Implement shell state machine

Needs to support the following:

[ ] Mutability
[ ] Raw markdown source
[ ] Parsed json
[ ] Command history
[ ] Last result

I think for this we can "just" replace the quit bool with a mutable State struct ...


is MEDIAPIPE_DISABLE_GPU necessary?

Does this mean that it is not possible to accelerate mediapipe with by using the GPU?

You can use GPU acceleration for mediapipe, I'm just not sure which platforms support it. I believe mobile does, but I'm not sure on PC what is supported and what is not.
This information probably exists somewhere out there.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add experimental crypto backend

Experimental Crypto Backend for gopass
This PR contains an experimental crypto backend for gopass.
The goal is to provide an implementation that is feature complete
compared to the GPG backend but doesn't require any external binaries,
especially no GPG. Of course this would break compatilibity to existing
GPG deployments and users of different pass implementations, but
especially for closed teams with no existing GPG deployment this should
make little different.
Motivation
While GPG is believed to be very secure and it supports a wide range of
applications and devices, it's not really user friendly. Even passioned
crypto experts don't enjoy working with GPG and for
newcomers it's a major hurdle. For the gopass developers it's about the
most time consuming task to provide support and implement workaround for
GPG issues. This doesn't mean that GPG is bad, but security is hard and
complex and GPG adds a lot of flexiblity on top of that so the result
is complex and complicated.
Status
Working, light testing. Disk format unstable.
Design

Hybrid encryption

Symmetric encryption for payload (secrets)
Using Chacha20Poly1305 AEAD
Random session key
Asymmetric encryption per recipient
Using Curve25519, XSalsa20, Poly1305 (NaCL Box)
(optional) Unencrypted Metadata

Disk format uses proto3 encoding for the header and the body

Keystore

Unencrypted public keys / metadata
Private Keys encrypted with XSalsa20, Poly1305 (NaCL Secretbox)
Using Argon2 KDF
Key ID similar to GnuPG, using the low 64 bits of a SHA-3 / SHAKE-256 hash
Disk format uses proto3 encoding

Agent

(optional) Listens on Unix Socket
Invokes pinentry if necessary, caches passphrase

Wow, that's a large one, don't know if I've got time to review it in full. Crypto primitives choice and design looks solid to me at first sight. Use of gob is a sane choice, but slightly disadvantegeous IMHO when interacting with other languages. Also I understand the secret format is now binary? That might make it a little harder interacting with a tool made for text files like git.

Thank you for the input so far. I'll definitely have another look at the on disk format. The current approach is neither very interoperable nor does it properly solve the backward/forward compatibility.

I've changed to on-disk format to use protobuf (version 3). This makes the seralization a lot cleaner, but still the whole branch needs a lot of testing.

The code should be mostly fine now, but I still need to do some testing wrt. the new backend as well as the refactored old backends.

This PR should be OK to merge. There may be some issues due to the huge refactorings, but we'll fix them when we encounter them. At least the stuff that's unit and integration tested (and that's quite a lot by now) seems to work well.


Is this possible to tag a new version to release latest feature?

Hi,
Is this possible to tag a new version to release latest feature? (I'm looking for custom timeout)
Thanks a lot,
Manuel

Hi @boillodmanuel!
We did not plan a release yet but thanks to remind us that it could be a nice idea.
Until then, feel free to use the latest version from the master.
if you are using NPM, npm install --save tcort/markdown-link-check will add the master branch version in your package.json.
Once the release will be out, you can switch to it of course.

It would be great to have a release that includes #106.

I've published version 3.8.4


Cannot access extensions marketplace clone

I downloaded and installed code server on a Digital Ocean droplet following this guide. Everything works except when I go to the Extensions tab to install extensions from the marketplace clone (as I understand it). It’s unable to connect.
I know I can install manually from the VSIX files but it’s a huge hassle and since I am limited to command line (running on iPad) I need to find a wget link which is not always available.

@nsadeh What exactly does it say? Could it not resolve the host? Could it not connect to the IP?
Would be a good idea to check the debug console as well.
@code-asher any other debugging tips?

It says "cannot connect to the extensions marketplace at this time, please try again later".
I tried to get to the docs through the VSCode terminal but copy-paste didn't work so I gave up.
Through Blink, most of the files in log-dir are empty, but the render logs had TypeError: Cannot read property clientWidth of type Undefined. I assume that has nothing to do with it. exthost.log had an info line for ExtensionService.doActivateExtension with startup: false in the JSON.
Debugger couldn't start because of no extension access.

See https://github.com/cdr/code-server/issues/1106 for some potential copy/paste workarounds.
Running code-server with --log trace or --log debug and then checking the logs directory in ~/.local/share/code-server might give some hints. Installing directly from the command line with code-server --install-extension <extension id> might also show something helpful.
It can also be helpful to open the browser devtools and go to the network tab to see what requests VS Code is trying to make to extensions.coder.com and what exactly the responses are.

I get the following out of the Chrome network tab headers:
Accept: application/json;api-version=3.0-preview.1
Content-Type: application/json
Referer: http:///
Sec-Fetch-Dest: empty
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36
X-Market-Client-Id: VSCode 1.33.1
X-Market-User-Id: user-id
Will run with logs in a second

Ok so running with the log option didn’t work, code-server says it does know about it. Here is what ./code-server —install-extension scalameta.metals gave:
INFO  code-server v1.1119-vsc1.33.1 ERROR (node:8650) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use  the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. ERROR  ERROR connect ECONNREFUSED <IP_ADDRESS>:88 ERROR  ERROR Failed Installing Extensions: scalameta.metals
Looks like I need to give it access to port 88. I don’t know how to do that off my head because I never learned how networking on computers works but I can google more into it.

After ufw allow I get
ERROR  ERROR Uncaught Exception:  { Error: spawn ENOMEM ERROR     at ChildProcess.spawn (internal/child_process.js: 366:11) ERROR     at spawn (child_process.js:538:9) ERROR     at /src/packages/server/out/cli.js:259:2339 ERROR     at /src/packages/server/out/cli.js:259:2295 ERROR     at /src/packages/server/out/cli.js:504:22829 ERROR     at /src/packages/server/out/cli.js:504:23213 ERROR     at /src/packages/server/out/cli.js:504:24010 ERROR     at FSReqWrap.oncomplete (fs.js:155:5) errno: 'ENO MEM', code: 'ENOMEM', syscall: 'spawn' } ERROR  ERROR connect ECONNREFUSED <IP_ADDRESS>:88 ERROR  ERROR Failed Installing Extensions: scalameta.metals

Oh interesting that's a rather old version of code-server. If you can, trying out the 3.0.1 pre-release might be worth a shot.
It looks like that might be your own IP address? When I browsed to it I was able to access an instance of code-server without any authorization. I removed the IP from your posts and the post revision history just in case but you might want to add some password authentication.
I'm not sure why it's trying to connect to itself over port 88. It's supposed to be connecting to  extensions.coder.com for v3 and v1.extapi.coder.com for v1 & v2 (which I believe now just redirects to extensions.coder.com).
When I try v1 and v2I get a different error; unable to get local issuer certificate. v3 works without a problem. :thinking:

Really appreciate it @code-asher - I started running without auth as I was using multiple devices and got careless with the IP. I'll try the newer version.
Where would I go to change the address it's trying to connect to?

There is an environment variable SERVICE_URL that can be used to set the address for the marketplace but I'm not sure setting that will change anything. It's almost as if the marketplace is being redirected by a proxy or something.

I redid the installation and now I can, but my extension doesn’t work with code-server.


Let animateScroll take an element rather than a selector

Lets say you want to scroll to an element, which does not have a unique id or name.
You could figure out some unique selector using:
https://github.com/ericclemmons/unique-selector (I was unable to use that module due to babelify issues)
But I think it would be much nicer if you could simply pass along the element to smoothScroll...

Smooth Scroll deliberately uses IDs so that it can behave an an enhancement to browser-native anchor link behavior. It's a progressive enhancement. If the script fails or breaks, your links still work.
This would not be the case with what you're proposing. As such, I'm closing this out as wontfix.

So I guess smoothScroll should be renamed to smoothScrollToAnchor then...
Cause I'm not talking about links, but dynamic content.
On Wed, Jun 8, 2016 at 2:49 PM, Chris Ferdinandi<EMAIL_ADDRESS>wrote:

Closed #260 https://github.com/cferdinandi/smooth-scroll/issues/260.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cferdinandi/smooth-scroll/issues/260#event-685722508,
or mute the thread
https://github.com/notifications/unsubscribe/AAHQP0kL9zk5UHEICYYHGkJ1QnG3Eawpks5qJrpBgaJpZM4Iw5Wo
.

A lightweight script to animate scrolling to anchor links.

Also it's poorly documented but animateScroll accepts a scrollTo position. If you can calculate that in your own you can animate to dynamic content with it: https://github.com/cferdinandi/smooth-scroll#animatescroll


Static Code Analyzer : Streams

fix with using() statement

using( var fs = new Stream())
{
    // do something
}

This looks like it was done already - didn't see any cases without "using"

Moving this to impeded just until we can see the original report and verify this is no longer an issue

@jmccausland was able to provide the SCA report - this has been posted to https://esri.app.box.com/folder/46853195584

Addressed in PR #502 and can be verified with #456 (see: https://github.com/Esri/distance-direction-addin-dotnet/issues/456#issuecomment-366808136).

This has been verified.  There are no longer any references to this build warning on the latest build.


Fix build by fixing vendoring

According to my testing, this fixes #1
Tested on darwin and Linux (using the golang docker container)
Vendoring with dep is really strange.

LGTM Thanks!


remove os.o_append and add os.Stdout, so that the log file will be ov…

Remove "os.o_append" and Add "STDOUT"
Remove os.o_append, so that the logs in log file will be overwrite, and it will not go into fat issue.

This change is

Since I have some issue with my ubiquity build ENV, I tested in a simple file, however I will try to build the ubiquity build and  verify the ubiquity logs out put
Test Code:
package main
import (
"fmt"
"io"
"log"
"os"
"path"
)
func SetupLogger(logPath string, loggerName string) (*log.Logger, *os.File) {
logFile, err := os.OpenFile(path.Join(logPath, fmt.Sprintf("%s.log", loggerName)), os.O_WRONLY|os.O_CREATE, 0640)
if err != nil {
fmt.Printf("Failed to setup logger: %s\n", err.Error())
return nil, nil
}
log.SetOutput(logFile)
logger := log.New(io.MultiWriter(os.Stdout, logFile), fmt.Sprintf("%s: ", loggerName), log.Lshortfile|log.LstdFlags)
return logger, logFile
}
func CloseLogs(logFile *os.File) {
logFile.Sync()
logFile.Close()
}
func main(){
logger, logFile := SetupLogger("/tmp/test", "testlog")
logger.Printf("Provisioner %s specified", logFile)
logger.Printf("aaaa %s", logFile)
logger.Printf("bbbb %s", logFile)
logger.Printf("cccc %s", logFile)
logger.Printf("dddd %s", logFile)
CloseLogs(logFile)
}

Coverage remained the same at 52.784% when pulling 194ae657966bc398397ccf2e72c4db4879cb3bb1 on feature/UB-254_disable_ubiquit_log_to_file_only_to_stdout into 24fceb69226285c5f9455ff05f986f4efd38ce9f on dev.

pull a new request, abandon this.

abandon this, please review in the new one


Make backwards compatible with elixir 1.14.1

Remove for: __MODULE__ to remain backwards compatible with Elixir 1.14.1
https://github.com/obmarg/kazan/issues/81

Thanks @gabrielpedepera


Casting Timestamp scalar does not preserve UTC Suffix

Describe the bug, including details regarding any error messages, version, and platform.
>>> ts = pd.Timestamp('2000-12-01 00:00:00+0000', tz='UTC')
>>> scal = pa.scalar(ts, type=pa.timestamp("ns", tz="UTC"))
>>> scal.cast(pa.string())
<pyarrow.StringScalar: '2000-12-01 00:00:00.000000000'>
>>>

No UTC "Z" suffix is present, but will be present when casting using arrays:
>>> dt_arr = pa.array([ts], type=pa.timestamp("ns", tz="UTC"))
>>> dt_arr.cast(pa.string())
<pyarrow.lib.StringArray object at 0x000002268498B340>
[
  "2000-12-01 00:00:00.000000000Z"
]
>>>

When using the Timestamp array cast, the UTC "Z" suffix is preserved, when using the scalar, it's not preserved.
Component(s)
Python

Good catch! I can reproduce the bug. The scalar code path does not handle timezone info. The pyarrow scalar cast uses a different implementation (arrow/cpp/src/arrow/util/time.h::ConvertTimestampValue()) than the pyarrow array cast (arrow/compute/kernels/scalar_cast_string.cc::TemporalToStringCastFunctor). Ideally, all functionality should be migrated to the compute kernel implementation. That will be a pretty big change, so the quickest option is to patch the current code path to add support for timezones.

A somewhat related issue: https://github.com/apache/arrow/issues/35040

Fixed as part of https://github.com/apache/arrow/pull/35395


choices in pane 3

In pane 3, when in manual generation mode, show the probability next to each word; display it as a percentage, e.g., "saw 33.5%". Use one digit after the decimal point.
Rename the "Random Choice" button to "Computer choice"

Skip item 2 but do item 1. Use the same format as pane 4, i.e., 0.35 instead of 35%.

Done.

Done for bi-grams - bug present for tri-and-tetra-grams. Resolving.

Tested and verified.


Specialize Range.contains(_)

Creates a specialization for Range.contains(_) that is a bound check rather than using Sequence's implementation which uses iteration instead.
This came up when I was implementing some Project Euler stuff when and I noticed the pathological behavior in some of those problems as well. Particularly problem 17 was about 1000x slower using ranges (I had like 6 different ranges).
I didn't add any new tests since this method is pretty extensively covered. I did create a pathological benchmark for it though.
Benchmark included below uses ./bin/wren_test. I wasn't sure if I should include it in the benchmarks folder since it looks like that is for comparing against different languages.
Looks like it's roughly 300x faster in this pathological case, but I reran it for (0...10) and it still is about 5x faster.
Anyway, let me know if I should change anything here! This isn't too big of a change and I think it can help all users of the language.
var start = System.clock
var total = 0
for (i in 0..1e5) {
    if ((0...1e3).contains(i)) {
        total = total + 1
    }
}
System.print(total)
System.print("elapsed: %(System.clock - start)")

// Before
// 1000
// elapsed: 2.968864

// After
// 1000
// elapsed: 0.010275

Looks like some great performance improvement here! Thanks a lot.

@mhermier What do you mean? It's passing all the tests. So as far as the tests are concerned the behavior is the same.

@ConfusedSky I mean that the tests are not sufficient. Range is an iterable, not the continuous mathematical object that represents all the numbers within 2 numbers that are the limits.
As a general rule, always consider what you are writing and testing against. If a test does pass or not always look at the tests you are referring to. They are human products, and can be broken/insufficient/whatever...

@mhermier I guess I hadn't considered that, however in that case really the only thing that would need to be checked is if the number was an integer.
Although I do think continuous range checking is valuable. Potentially this could be split into two methods, where something like isInRange (probably want a better name where) could be as written, and contains would require the number to be an integer. But I agree now, the behavior is inconsistent.

@ConfusedSky well situation is more complicated than that. Since there is no requirement for Range bounds to be integers, so one has to iterate the range, in case the accumulation brings accumulation errors...
I also guess there is a potential need for isInRange functionality, but it can be implemented externally. So unless there is a feasibility issue I didn't see, or a use case where it is proven to be a real performance issue, there is no need for inclusion in core.

@mhermier Ah yea I see. But it does appear to always increment by one. I'll revisit this.

See/use calculateRange it handles all the corner cases, and in case we add customized step value support, it would be the place to handle the situation.

It appears that the implementation in main doesn't work either

Floating point precision error?
That being said also, the specialization for contains for string, isn't consistent with the one for sequence.

Where do you think there is an error? I don't see it...

For fun this statement can be verified in c++ using:
static_assert((2.2-1)==1.2);

which produce in compiler explorer for example:
<source>:1:22: error: static assertion failed
    1 | static_assert((2.2-1)==1.2);
      |               ~~~~~~~^~~~~
<source>:1:22: note: the comparison reduces to '(1.2000000000000002e+0 == 1.2e+0)'

I tried node and python as well, same deal. Since presumably, it has more to do with IEE-754 than the behavior of wren.
As written, contains doesn't seem to be very useful for ranges that have from values that aren't integers.

About String, it is consistent, as it produce the expected behavior with parameters of a specific shape. So if you check that the searched string is a one character String (even UTF-8 ones), it produce the normal behavior of contains(). The fact that it also search do substring is an interesting side effect that augment the behavior. But more importantly the user can act on the parameter to ban the unwanted effect.
On the other hand with the original patch, one has to act on the Range to see if the behavior was correct.
The nuance is subtle, I agree. It is a question of "does it work as expected with any valid argument" (as one could trivially guess from the API naming convention), and the original Range patch was not.
That said, the lack of a proper Char class make String a little bit to much complex to apprehend, since it is a ball of mud mixing string, character and byte array data. But that another story, and huge can of worms...


sync to live

OPS Build status updates of commit a047ba6:
:clock10: Preparing: average preparing time is 43 sec(s)

OPS Build status updates of commit a047ba6:
:clock10: Incremental building: average incremental building time is 18 sec(s)

OPS Build status updates of commit a047ba6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/Resources.md
:white_check_mark:Succeeded

windows-iotcore/TOC.md
:white_check_mark:Succeeded

windows-iotcore/learn-about-hardware/iotnxp.md
:white_check_mark:Succeeded

windows-iotcore/release-notes/CurrentCommercial.md
:white_check_mark:Succeeded

windows-iotcore/release-notes/CurrentInsider.md
:white_check_mark:Succeeded

windows-iotcore/release-notes/Insider/17763.md
:white_check_mark:Succeeded

windows-iotcore/release-notes/Insider/RPi3BP.md
:white_check_mark:Succeeded

windows-iotcore/release-notes/commercial/17763.md
:white_check_mark:Succeeded

windows-iotcore/release-notes/commercial/October2018Update.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Always show the legacy associations box

Rather than making it show up only when you can't tag to the Worldwide
taxonomy, as this doesn't make sense.

LGTM 👍


Stopped errors when no event is present

Because of the jQuery calling nature of GoldenLayout you always expect an event. But when a user calls toggleMaximise from their code it may not be appropriate to pass any event and therefore no need to prevent any default action.

This should fix issue #242

Thanks for your contribution!


Update update-deps.yml to run update dependencies job at 5 pm every T…

…hursday
Update update-deps.yml to run update dependencies job at 17pm every Thursday

Could you squash your commits?

close it


delete all files if all resources are deleleted

fix #1460

@droot I think we need to note it in the fn eval doc.


Scaling issues on devices with fractional device pixel ratios

Expected Behavior
On devices which have fractional device pixel ratios (ie. Pixel 2 which has a device pixel ratio of 2.625), I expect PIXI to scale the application correctly.
Current Behavior
When setting the renderer resolution using window.devicePixelResolution on devices which have fractional device pixel resolutions (ie. Google Pixel 2 is 2.625), the application is getting skewed on the X-axis is seems. If I Math.floor(window.devicePixelResolution) it works fine, but we're not using the true resolution capable on the device.
When resolution: window.devicePixelRatio ie. 2.625

When resolution: Math.floor(window.devicePixelRatio) ie. 2

I can't see where the application is getting skewed. The values for canvas size seem correct (5040 x 2835) which is 1920 x 1080 * 2.625. The canvas uses CSS styling and sets the width and height correctly to 732 x 411 px.
Possible Solution
Allow fractional device pixel ratios.
Steps to Reproduce
Create a renderer using the following:
let rendererOptions: RendererOptions = {
width: 1920,
height: 1080,
resolution: window.devicePixelRatio
};
this._app = new PIXI.Application(rendererOptions);
Test on any devices which uses fractional device pixel ratios.
Environment

pixi.js version: 4.5.6
Browser: Chrome 66.0.3359.126
Device: Google Pixel 2

Please look at https://github.com/pixijs/pixi.js/issues/4153 , maybe its your issue.

Also, look at CSS dimensions in chrome in PC with same resolution, maybe its wrong. How do you resize the canvas?

did you specify "autoResize:true" in renderer options? make sure its false, or pixi will override your settings: https://github.com/pixijs/pixi.js/blob/dev/src/core/renderers/SystemRenderer.js#L225

No, we're not using autoResize. Tried setting to false to make sure, and doesn't make any difference. When testing on a Mac in Chrome emulator, the scaling issue doesn't replicate. Only on device itself.

You can see on the screenshot below, the canvas size and style size all seem correct.

I suspect that it cant create framebuffer larger than 4096.

Yes.

Great Ok, so the only solution for now is as per this ticket - https://github.com/pixijs/pixi.js/issues/4153 whereby we have to resize the renderer and resolution if the buffer size is too small?
Is it a common strategy just to limit the resolution to 2 for Android devices?

For games on mobile, I disagree with the idea of a direct link of window.devicePixelRatio and the PIXI resolution setting.
You say limiting the resolution to 2... But that's still rendering at 4k! A punishing resolution causing poorer performance and battery drain to push more pixels than the device actually has. The actual number of pixels on the pixel 2 is 1920x1080. So if you're game is natively at that resolution, then your resolution should be 1.

Hi all, I work with Dan and we're trying to figure this out. We were having problems with blurry images and pixelated text and read a ton of threads earlier this week suggesting that the best way to get quality sharp rendering on devices was to set the renderer's resolution to be the devicePixelRatio (In particular this one: https://github.com/pixijs/pixi.js/issues/621). So how do these 2 solutions reconcile with each other?
Thanks in advance.

@frankmcpolin A higher resolution helps, and also roundPixels can help. If a global setting doesn't work, I had a PR for v4 that i'll update for v5 https://github.com/pixijs/pixi.js/pull/4833 that allowed Text objects to always be rendered to a whole pixel whilst leaving other sprites alone.
If you're still having issues, feel free to re-open with a jsfiddle with an example of what you have so far, and we could look at best solutions to get your game looking sharper


Players don't move except when bumped by the ball

Seeing this error:
UnityAgentsException: The Heuristic method was not implemented for the Agent on the AgentBlue GameObject.
UnityAgentsException: The Heuristic method was not implemented for the Agent on the AgentRed GameObject.
MLAgents.Agent.Heuristic () (at /home/shawn/Documents/Shawn/AI/ml-agents-versions/ml-agents-0.14.1/com.unity.ml-agents/Runtime/Agent.cs:450)
MLAgents.HeuristicPolicy.RequestDecision (MLAgents.AgentInfo info, System.Collections.Generic.List`1[T] sensors) (at /home/shawn/Documents/Shawn/AI/ml-agents-versions/ml-agents-0.14.1/com.unity.ml-agents/Runtime/Policy/HeuristicPolicy.cs:26)
MLAgents.Agent.NotifyAgentDone (System.Boolean maxStepReached) (at /home/shawn/Documents/Shawn/AI/ml-agents-versions/ml-agents-0.14.1/com.unity.ml-agents/Runtime/Agent.cs:279)
MLAgents.Agent.OnDisable () (at /home/shawn/Documents/Shawn/AI/ml-agents-versions/ml-agents-0.14.1/com.unity.ml-agents/Runtime/Agent.cs:267)
Also in the Agent properties panel the message:
"There is no model for this Brain, cannot run inference. (But can still train)"
Is there a trick to getting the brain connected to the rods?

Hi, I haven't looked at this in three years and struggle with getting the correct barracuda version imported into the project. Judging from ml-agents' 0.14 release date, it should be around 0.6 for barracuda. Newer barracuda versions have breaking namespace changes and don't work with ml-agents 0.14 -- Are you able to run any of the example projects that ship with the ml-agents 0.14 release?

Thanks for getting back to me about this! I was able to get things running. It was user error. Many of the other examples come with pre-trained brains but not the foosball one. So I was erroneously expecting it to just "play".  Utilizing mlagents-learn I've got some brains training and the training process seems to be moving along.


CentOS 7: Node 10.12.0 requiring zlib 1.2.9

Have a look at this thread.
https://github.com/barisusakli/nodebb-plugin-imgur/issues/35
I had to revert to node 10.8.0 in order for this component not to cause a problem.
I did not try the versions in between.

I'm having the same issue on 6.14.3, also on CentOS 7.  Same ZLIB 1.2.9 requirement, but the OS only provides 1.2.7.  Was working till a recent app update.

Hello, the Error: /lib64/libz.so.1: version ZLIB_1.2.9' not found message is caused by something other than sharp depending on an older system-level zlib shared library before require('sharp') is used.
Known causes of this are:

When using Electron on Linux - see #892
When node-canvas is a (transient) dependency - see #843
When Node has been compiled using the --with-system-zlib flag - see #1405

If the only thing that has changed is the version of Node then the latter could be part of the reason. Perhaps the way in which Node is packaged for Centos 7 has recently changed?
If you're able to narrow down the specific version of Node when things start to break that will be very helpful.

In my case, Node was not updated.

@sorvani @scottalanmiller Were either of you able to make any progress with this?

I changed versions of node to get around it. I will look at updates in a bit and see what it does now.

Same here, went to a lower version of NodeJS to avoid the issue.

Thanks for the updates. How is Node installed on these machines? From source or a prebuilt package from a repo? If from a repo, with what config?
I suspect a --with-system-zlib build flag was added somewhere between Node 10.8.0 and 10.12.0 to whatever is building it. If you're able to determine the specific version of Node at which it stopped working, that would be very helpful.

I installed node with nvm, and nvm was isntalled with form here: https://github.com/creationix/nvm

This afternoon, I went through and installed node versions v10.8.0 through v10.13.0.
nvm install v10.9.0
..
nvm install v10.13.0

I then tried each one with this process.
nvm use v10.8.0
npm rebuild
./nodebb stop
./nodebb build
./nodebb start

Then I tried to paste in an image to a post. Now it works for every single version.
The only difference in my system related to node, is I updated npm after seeing this alert.

I have no idea why everything seems to now work normally with all versions.

Thank you for the update. Perhaps there was something temporarily wrong with one of the CentOS 7 versions of Node. Please feel free to re-open if you're able to narrow this down to a specific release of Node.

I had the same story with CentOS 7 and zlib 1.2.7
I tried to update system zlib which as a very bad idea. My VPS stopped work at all, then I recover the server with backup and stumble upon this article: https://unix.stackexchange.com/questions/476450/trying-to-resolve-dependency-on-libz-so-1zlib-1-2-9
I just repeat the answer that helped me out:
I created these directories:
mkdir /opt/zlib
cd /opt/zlib
mkdir /1.2.11
mkdir /src

I then moved into /opt/zlib/src and:
wget https://github.com/madler/zlib/archive/v1.2.11.tar.gz

I then decompressed it and moved into the directory containing the config just as I'm sure you did and then ran this:
tar -zxf v1.2.11.tar.gz
cd zlib-1.2.11
./configure --prefix=/opt/zlib/1.2.11

Then I ran make and make install.
make; make install;

That put the libraries in:
/opt/zlib/1.2.11/lib

I then ran this command to see ZLIB_1.2.9 available:
strings -d /opt/zlib/1.2.11/lib/libz.so | grep ^ZLIB

Lastly, I modify  ~/.bashrc and append this:
export LD_LIBRARY_PATH=/opt/zlib/1.2.11/lib:/usr/lib64:$LD_LIBRARY_PATH

After this steps problem disappeared.


Inconsistent quote marks

Found by @chrisalleng
note for future us, it looks like some quoted names in xws are escaped:
"name": ""Slider"",
vs others that are using the quote symbols:
"name": "“Mauler” Mithel"

@chrisalleng do you have a preference here? I think quote symbols might be more "correct", and given that they are inside of a string field I'm kindof ok with using them even though I much prefer ascii to unicode

I agree, I think the quote symbols are more correct, despite being a bigger headache.

Closed in #590


Data catalog and shown data

The tick in the catalog is missing and the geocat link / legend throws an error. Also loading the cross sections that change to the hydrological bacckground map results in strange opacity settings of the the base map.

@vladyslav-tk tried to address your feedback, there is still one open remark. it was quite tedious to keep up with the new_ui branch. also it has some conflicts with the tooling rework. can you have a look and merge if it is fine with you?


Diff previous/next change arrows not bindable to keyboard

I want to be able to bind diff navigation arrows (right top corner when diff opened) to be bindable to keyboard, so I don't have to look for mouse.

VSCode Version: Code 1.12.2 (19222cdc84ce72202478ba1cec5cb557b71163de, 2017-05-
10T13:20:36.315Z)
OS Version: Windows_NT ia32 10.0.10240
Extensions:

Extension
Author
Version

project-manager
alefragnani
0.18.0

vscode-simpler-icons
davidbabel
1.3.0

githistory
donjayamanne
0.2.0

xml
DotJoshJohnson
1.8.0

gitlens
eamodio
3.6.1

scriptcsRunner
filipw
0.1.0

code-runner
formulahendry
0.6.18

vscode-awk-hint
hangxingliu
0.0.2

AWK
luggage66
0.0.2

cpptools
ms-vscode
0.11.4

csharp
ms-vscode
1.10.0

PowerShell
ms-vscode
1.2.1

vscode-run-git-difftool
narekmal
0.0.4

vscode-clearcase
OpenNingia
1.9.2

vscode-format
ryannaddy
0.0.6

partial-diff
ryu1kn
0.3.1

code-settings-sync
Shan
2.8.1

code-spell-checker
streetsidesoftware
1.1.0

Steps to Reproduce:

Closing as dup of #24390 and #24389.


Requested value 'admin' was not found.

When I try to modify/create user, I always got error information 'Requested value 'admin' was not found.'    (modify/create other entity is ok)

And it even cannot get into the create EndPoint.

When I tried with Google Chrome, it work.
Wehn I tried with Firefox, it didnot work, and came with the error 'Requested value 'admin' was not found'

I've seen this before and I think you need to turn off the autofill/auto complete options in Firefox.
You should be able to do it on the browser level, and also on a site level.
Try fiddle around with those settings and let me know if it helps?

It works, thanks very much

Good to hear.
I have also seen this happen on Safari where the quicksearch fields are autocorrected and you can't actually search what you want to search for. In case you use Safari and experience this issue, you must disable autocorrect like so:

Uncheck this menu item.
@Nathan2020-0126 if you're happy please close the issue.
Thanks!

ok, thanks very much for your further infomation.