Escaping ';' in text block

There is a problem when I read a text block containing ; in it. There was no problem while writing the text block using the parser, but while reading it breaks.
Example This loop can't be
parsed but can be written using PyNMRSTAR without any problem
`
loop_
_Software_specific_info.Software_saveframe_ID
_Software_specific_info.Software_saveframe
_Software_specific_info.Software_specific_info_list_ID
 1

;
save_cyana_additional_data_1
_cyana_additional_data.sf_category      cyana_additional_data
_cyana_additional_data.sf_framecode     cyana_additional_data_1
cyana_additional_data.special_version  5
save
;
1
2
;
save_xplor_raw_data_T1_T2_values_1
_xplor_raw_data.sf_category   xplor_raw_data
_xplor_raw_data.sf_framecode  xplor_raw_data_T1_T2_values_1
_xplor_raw_data.file_name     input_file_name.extension
xplor_raw_data.details
;
Optional item
For comments.
Any multiline text can be put here
;
xplor_raw_data.text
;
If the string starts with a new line (as in this case) it is skipped. This avoids issues with how many initial spaces to strip
;
save
;
1
stop
`

AFAICT this is not a valid loop. So if PyNMRSTAR can write it out like that, that's the bug.
To wit, the 3rd value in the 2nd row is optional.

PS. this is why I added STAR-2012's triple-quoted values to SAS.

So if PyNMRSTAR can write it out like that, that's the bug.

Exactly.

This is resolved (pending further testing) in the pure python implementation in these commits: 69c3208 and b90667f
I need to implement it in the C library before pushing the update to pip.

This warrants further discussion. (@elulrich @perzeus  @dmaziuk @kumar-physics ) There are several ways to "resolve" this, each of which has its own benefits and drawbacks. My commit above implements one of them (2), but I think we should have consensus before I push it to the master branch. Here are the options as I see them (in no particular order):

Implement full STAR-2012 support in the library and use triple-quoted values to contain the newline+semi-colon delineated values. If triple quoted values are also inserted, then use the new bell escape sequence to escape them. The major downside of this is that all STAR parsers that don't implement STAR-2012 will fail to parse the file. My understanding is that the BMRB officially releases files in the original STAR format. If we start generating files with STAR-2012 features then other's STAR-parsing libraries will break. We can make the transition official though, and try to encourage other users to use our existing libraries. This could have other drawbacks though - we would have to start officially supporting unicode in files. Dimitri, my understanding from your comment above is that you already use this method when writing STAR which contains STAR in data values? Or do you just support parsing files with triple-quotes? Or do you have full STAR-2012 support?

Use a BMRB-defined NMR-STAR specific (not official STAR) method to escape these problematic values. I see at least two different ways to do this:

If a data value contains the string  \n; then add 3 space characters before every line in the data value. This way the existing \n; will transform into \n\ \ \ ;. (Interpret \s as   - Markdown doesn't preserve multiple spaces in a row.) During the parsing of these files, if a field is semi-colon delineated, contains the string \n\ \ \ ;, and every line starts with at least 3 spaces we can automatically replace all instances of \n\ \ \  with \n. This has the benefit of being visually clear of what is happening, and it works recursively. (I.e. STAR-in-STAR-in-STAR) I believe something like this is what we have used in the past when we have inserted STAR loops as the value of tags? The downside is that if the user inserts data into a tag that contains the literal string \n\ \ \ ; and has every line beginning with at least 3 spaces then the spaces will be removed from their data upon parsing. I think this would be extremely rare, but it is still worth acknowledging. This solution does not break existing parsers, though they would fail to properly interpret the STAR-in-STAR values. (They would not remove the whitespace and therefore if they tried to parse the inner STAR data would encounter an error.) On the other hand, I think most other people have not thoroughly implemented their parsers and therefore simply having the STAR-in-STAR may break their parsers as it is. Furthermore, upon the error visual inspection of the file should make it clear what is happening.

Borrowing from the STAR-2012 specification in a backwards-compatible way, simply replace all instances of \n; in a text value with \n\a; where \a is the BELL control character when printing. Upon parsing replace all \n\a; in a data value with \n;. Like solution 2 this does not break backwards compatibility, though it shares the same downside of preventing the inner-STAR data from being reinterpreted without updating the code to understand it. This solution has a downside in that it doesn't work recursively. To make it work recursively would require additional BELL-escaping logic.

To summarize the pros and cons:

Most robust solution, human readable, recursive, but prevents all existing parsers from parsing the file at all and means we should probably update to full STAR-2012 support everywhere.

Backwards compatible, human readable, recursive, and doesn't break existing parsers from parsing the file. It would only prevent existing parsers from properly parsing the inner-STAR values, but this is an easy fix either in code or by copying and pasting the inner STAR text. I think this also makes it clear when viewing the file what is going on.
Backwards compatible, the BELL sequence makes it clear when viewing the file that something special is happening, not recursive without additional logic that BELL-escapes the BELL character. May be confusing when viewing the file, but the BELL character is more unambiguous than spaces and wouldn't ever* be inserted into an actual data value.

Regardless of what we choose, I think that all BMRB libraries/tools should implement the same behavior and all NMR-STAR files we produce should use the same method.
My vote is for (2). Thoughts?

(Working from home today - grant proposal writing crunch mode)
I agree with Jon on using the second alternative, if we worry about existing parsers and staying within the STAR specification. I would say I prefer the idea of triple quotes as a cleaner and concise method for encoding verbatim text blocks, but as far as I understand the issue, that solution would make NMR-STAR non STAR compliant, am I right?
Cheers,
Pedro
On Feb 2, 2017, at 9:45 AM, Jon Wedell <notifications<EMAIL_ADDRESS>wrote:
This warrants further discussion. (@elulrichhttps://github.com/elulrich @perzeushttps://github.com/perzeus @dmaziukhttps://github.com/dmaziuk @kumar-physicshttps://github.com/kumar-physics ) There are several ways to "resolve" this, each of which has its own benefits and drawbacks. My commit above implements one of them (2), but I think we should have consensus before I push it to the master branch. Here are the options as I see them (in no particular order):

Implement full STAR-2012 support in the library and use triple-quoted values to contain the newline+semi-colon delineated values. If triple quoted values are also inserted, then use the new bell escape sequence to escape them. The major downside of this is that all STAR parsers that don't implement STAR-2012 will fail to parse the file. My understanding is that the BMRB officially releases files in the original STAR format. If we start generating files with STAR-2012 features then other's STAR-parsing libraries will break. We can make the transition official though, and try to encourage other users to use our existing libraries. This could have other drawbacks though - we would have to start officially supporting unicode in files. Dimitri, my understanding from your comment above is that you already use this method when writing STAR which contains STAR in data values? Or do you just support parsing files with triple-quotes? Or do you have full STAR-2012 support?

Use a BMRB-defined NMR-STAR specific (not official STAR) method to escape these problematic values. I see at least two different ways to do this:

If a data value contains the string \n; then add 3 space characters before every line in the data value. This way the existing \n; will transform into \n\ \ \ ;. (Interpret \s as - Markdown doesn't preserve multiple spaces in a row.) During the parsing of these files, if a field is semi-colon delineated, contains the string \n\ \ \ ;, and every line starts with at least 3 spaces we can automatically replace all instances of \n\ \ \ with \n. This has the benefit of being visually clear of what is happening, and it works recursively. (I.e. STAR-in-STAR-in-STAR) I believe something like this is what we have used in the past when we have inserted STAR loops as the value of tags? The downside is that if the user inserts data into a tag that contains the literal string \n\ \ \ ; and has every line beginning with at least 3 spaces then the spaces will be removed from their data upon parsing. I think this would be extremely rare, but it is still worth acknowledging. This solution does not break existing parsers, though they would fail to properly interpret the STAR-in-STAR values. (They would not remove the whitespace and therefore if they tried to parse the inner STAR data would encounter an error.) On the other hand, I think most other people have not thoroughly implemented their parsers and therefore simply having the STAR-in-STAR may break their parsers as it is. Furthermore, upon the error visual inspection of the file should make it clear what is happening.

Borrowing from the STAR-2012 specification in a backwards-compatible way, simply replace all instances of \n; in a text value with \n\a; where \a is the BELL control character when printing. Upon parsing replace all \n\a; in a data value with \n;. Like solution 2 this does not break backwards compatibility, though it shares the same downside of preventing the inner-STAR data from being reinterpreted without updating the code to understand it. This solution has a downside in that it doesn't work recursively. To make it work recursively would require additional BELL-escaping logic.

To summarize the pros and cons:

Most robust solution, human readable, recursive, but prevents all existing parsers from parsing the file at all and means we should probably update to full STAR-2012 support everywhere.

Backwards compatible, human readable, recursive, and doesn't break existing parsers from parsing the file. It would only prevent existing parsers from properly parsing the inner-STAR values, but this is an easy fix either in code or by copying and pasting the inner STAR text. I think this also makes it clear when viewing the file what is going on.

Backwards compatible, the BELL sequence makes it clear when viewing the file that something special is happening, not recursive without additional logic that BELL-escapes the BELL character. May be confusing when viewing the file, but the BELL character is more unambiguous than spaces and wouldn't ever* be inserted into an actual data value.

Regardless of what we choose, I think that all BMRB libraries/tools should implement the same behavior and all NMR-STAR files we produce should use the same method.
My vote is for (2). Thoughts?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/uwbmrb/PyNMRSTAR/issues/50#issuecomment-276993790, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKZSd-Yh85eQHj72QVg69qg7GXEZphm0ks5rYfoegaJpZM4LxmS2.

When I said triple quotes would make NMR-STAR non STAR compliant, I meant the STAR version we currently conform to. Seeing that STAR 2012 includes them, i think we should move towards implementing at least that aspect of STAR 2012. To be precise, we don't conform to the full STAR specification anyway (e.g. no nested loops). Triple quotes should be easy enough to adopt for any parser out there.
Pedro
On Feb 2, 2017, at 10:53 AM, Pedro R. Romero <promero<EMAIL_ADDRESS>wrote:
(Working from home today - grant proposal writing crunch mode)
I agree with Jon on using the second alternative, if we worry about existing parsers and staying within the STAR specification. I would say I prefer the idea of triple quotes as a cleaner and concise method for encoding verbatim text blocks, but as far as I understand the issue, that solution would make NMR-STAR non STAR compliant, am I right?
Cheers,
Pedro
On Feb 2, 2017, at 9:45 AM, Jon Wedell <notifications<EMAIL_ADDRESS>wrote:
This warrants further discussion. (@elulrichhttps://github.com/elulrich @perzeushttps://github.com/perzeus @dmaziukhttps://github.com/dmaziuk @kumar-physicshttps://github.com/kumar-physics ) There are several ways to "resolve" this, each of which has its own benefits and drawbacks. My commit above implements one of them (2), but I think we should have consensus before I push it to the master branch. Here are the options as I see them (in no particular order):

Implement full STAR-2012 support in the library and use triple-quoted values to contain the newline+semi-colon delineated values. If triple quoted values are also inserted, then use the new bell escape sequence to escape them. The major downside of this is that all STAR parsers that don't implement STAR-2012 will fail to parse the file. My understanding is that the BMRB officially releases files in the original STAR format. If we start generating files with STAR-2012 features then other's STAR-parsing libraries will break. We can make the transition official though, and try to encourage other users to use our existing libraries. This could have other drawbacks though - we would have to start officially supporting unicode in files. Dimitri, my understanding from your comment above is that you already use this method when writing STAR which contains STAR in data values? Or do you just support parsing files with triple-quotes? Or do you have full STAR-2012 support?

Use a BMRB-defined NMR-STAR specific (not official STAR) method to escape these problematic values. I see at least two different ways to do this:

If a data value contains the string \n; then add 3 space characters before every line in the data value. This way the existing \n; will transform into \n\ \ \ ;. (Interpret \s as - Markdown doesn't preserve multiple spaces in a row.) During the parsing of these files, if a field is semi-colon delineated, contains the string \n\ \ \ ;, and every line starts with at least 3 spaces we can automatically replace all instances of \n\ \ \ with \n. This has the benefit of being visually clear of what is happening, and it works recursively. (I.e. STAR-in-STAR-in-STAR) I believe something like this is what we have used in the past when we have inserted STAR loops as the value of tags? The downside is that if the user inserts data into a tag that contains the literal string \n\ \ \ ; and has every line beginning with at least 3 spaces then the spaces will be removed from their data upon parsing. I think this would be extremely rare, but it is still worth acknowledging. This solution does not break existing parsers, though they would fail to properly interpret the STAR-in-STAR values. (They would not remove the whitespace and therefore if they tried to parse the inner STAR data would encounter an error.) On the other hand, I think most other people have not thoroughly implemented their parsers and therefore simply having the STAR-in-STAR may break their parsers as it is. Furthermore, upon the error visual inspection of the file should make it clear what is happening.

Borrowing from the STAR-2012 specification in a backwards-compatible way, simply replace all instances of \n; in a text value with \n\a; where \a is the BELL control character when printing. Upon parsing replace all \n\a; in a data value with \n;. Like solution 2 this does not break backwards compatibility, though it shares the same downside of preventing the inner-STAR data from being reinterpreted without updating the code to understand it. This solution has a downside in that it doesn't work recursively. To make it work recursively would require additional BELL-escaping logic.

To summarize the pros and cons:

Most robust solution, human readable, recursive, but prevents all existing parsers from parsing the file at all and means we should probably update to full STAR-2012 support everywhere.

Backwards compatible, human readable, recursive, and doesn't break existing parsers from parsing the file. It would only prevent existing parsers from properly parsing the inner-STAR values, but this is an easy fix either in code or by copying and pasting the inner STAR text. I think this also makes it clear when viewing the file what is going on.

Backwards compatible, the BELL sequence makes it clear when viewing the file that something special is happening, not recursive without additional logic that BELL-escapes the BELL character. May be confusing when viewing the file, but the BELL character is more unambiguous than spaces and wouldn't ever* be inserted into an actual data value.

Regardless of what we choose, I think that all BMRB libraries/tools should implement the same behavior and all NMR-STAR files we produce should use the same method.
My vote is for (2). Thoughts?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/uwbmrb/PyNMRSTAR/issues/50#issuecomment-276993790, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKZSd-Yh85eQHj72QVg69qg7GXEZphm0ks5rYfoegaJpZM4LxmS2.

Yes, up to this point in time all of the 3.1 files we generate are pure STAR. (While Dimitri's code supports reading in triple-quoted values, I don't see any released entries using that feature.)
We don't use the full STAR feature set, but everything we use is currently a legal subset of it. I have to admit I'm a bit concerned with breaking existing parsers - it seemed to take a very long time to get the community to upgrade to NMR-STAR 3.x from 2. Furthermore, I believe a lot of people in the community use regular-expression based parsers they implemented themselves for simple scripts and updating those to support this might actually be a lot of work for them. (Perhaps that isn't all bad, since when they come to us to complain we could point them to use our robust tools rather than their own implementations.)
This would also mean that all of our existing software would need to be updated including ADIT-NMR.
Nevertheless, I'm happy to go this route if it is the group consensus.

On 2/2/2017 11:27 AM, Jon Wedell wrote:

Yes, up to this point in time all of the 3.1 files we generate are
pure STAR. (While Dimitri's code supports reading in triple-quoted
values, I don't see any released entries using that feature.)
We don't use the full STAR feature set, but everything we use is
currently a legal subset of it. I have to admit I'm a bit concerned
with breaking existing parsers - it seemed to take a very long time to
get the community to upgrade to NMR-STAR 3.x from 2. Furthermore, I
believe a lot of people in the community use regular-expression based
parsers they implemented themselves for simple scripts and updating
those to support this might actually be a lot of work for them.
(Perhaps that isn't all bad, since when they come to us to complain we
could point them to use our robust tools rather than their own
implementations.)
This would also mean that all of our existing software would need to
be updated including ADIT-NMR.
Nevertheless, I'm happy to go this route if it is the group consensus.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uwbmrb/PyNMRSTAR/issues/50#issuecomment-277024305,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKZSdyMdem-t8Xmqlu7kQNDg7WiuTJDlks5rYhIegaJpZM4LxmS2.

I see your point. Let's implement your solution 2 now. We will discuss
any STAR upgrades later, possibly for a new NMR-STAR major version
(NMR-STAR 4.0). Major versions typically necessitate parser upgrades anyway.
Thanks,
Pedro

I definitely agree that we should consider adopting some of the features from STAR-2012 when NMR-STAR 4.0 is released. It will be a great opportunity to resolve some of the oddities from STAR.

The other option could be to replace \n; in the embedded STAR with \n''' instead of \n\a; -- that way if someone reads it with a STAR-2012 parser it'll "just work" and if not: they have to put the \n; back anyway.
Unfortunately the triple-quotes, like most other STAR-2012 "improvements" are incompatible with previous specification. Including BELL escapes. All existing STAR software out there will need to be rewritten for STAR-2012. Personally I don't see the urgency, as the 2012 specification doesn't actually fix any of the STAR practical "oddities", it just adds more breakage,

On 2/2/2017 12:31 PM, dmaziuk wrote:

The other option could be to replace |\n;| in the embedded STAR with
|\n'''| instead of |\n\a;| -- that way if someone reads it with a
STAR-2012 parser it'll "just work" and if not: they have to put the
|\n;| back anyway.
Unfortunately the triple-quotes, like most other STAR-2012
"improvements" are incompatible with previous specification. Including
|BELL| escapes. All existing STAR software out there will need to be
rewritten for STAR-2012. Personally I don't see the urgency, as the
2012 specification doesn't actually fix any of the STAR practical
"oddities", it just adds more breakage,
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uwbmrb/PyNMRSTAR/issues/50#issuecomment-277041584,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKZSd4zR572hxuN_kCcb5Q0MkSKnCM80ks5rYiEFgaJpZM4LxmS2.

Thanks, Dimitri. This further justifies leaving STAR 2012 for later
discussions. I would say we should not worry about anyone parsing
NMR-STAR with a STAR 2012 parser. I believe we will know when that
happens, but I won't hold my breath.
Cheers,
Pedro

I vote for option 2, for now. It is not clear how many NEF files will have software specific tags and data so I am guessing that there will be little impact.
Eldon

The other option could be to replace \n; in the embedded STAR with \n''' instead of \n\a; -- that way if someone reads it with a STAR-2012 parser it'll "just work" and if not: they have to put the \n; back anyway.

That is an interesting idea, and I see the appeal in that it would work natively for STAR-2012,  but I think it could lead to confusion when looking at a file. I think it is more likely that a user would figure out the embedded-STAR needs to be shifted over versus knowing the """ is a delimeter and not part of the tag value. (I mean, it isn't that hard to figure out, but in STAR whitespace is usually not important to proper parsing, whereas quotes always are.) Also, imagine if you put a whole NMR-STAR entry in a tag and only had a STAR parser - with the spaces method you could just copy the embedded-STAR, paste it elsewhere, and shift the text over in your IDE or text editor. With the quote method you would have to go through and remove all the triple quotes with syntactic-awareness. In other words, you would pretty much need to have a STAR-2012 parser.
Finally, if there actually are triple quotes in the data value then they would need to be escaped - which would require the BELL character which we were trying to avoid.
;
"""
My doubly quoted
STAR tags.
"""
;

vs
;
   ;
   My doubly quoted
   STAR tags.
   ;
;

Well, you can't win in general, but a global search and replace of \n''' with \n; is actually easier than column-wise editing. Typically multiple quotes used in nucleic acid atom names, like H-double-prime, so you shouldn't see them at the start of a line. (And I don't think they do triple-primes; certainly not triple-double-quotes.)
If someone was silly enough to use triple-quotes in a value they'll get to keep the piece: at some point you just have to let it break. they may have used a \a, too, who knows.

Well, you can't win in general, but a global search and replace of \n''' with \n; is actually easier than column-wise editing.

Yeah, good point. You could also replace \n\ \ \  with \n globally too.

If someone was silly enough to use triple-quotes in a value they'll get to keep the pieces: at some point you just have to let it break.

I see a few entries with triple quotes within values.
I agree we can't always handle every edge-case, but it seems to me the spaces-method is less effected by them. At worst, it ensures that the file will parse okay but may return data with extra spaces. At worst the quoting method will fail to parse (even in STAR-2012).

C test implementation at f753a93.

Worst case scenario is they fail to replace \n   ; with \n; and get parse errors reading the inner file. They should be able to figure them out.
(You're right:  in general you can't use triple quotes without BELs. It could have been a quick workaround for NEF, but otherwise it potentially creates more problems than just adding space before semicolon. Like the rest of STAR-2012: not really a fix that adds more breakage.)

Completely fixed at 859b1b1.

Further improvements in edge-case behavior: ada7976


NextJS 12 fails to compile with SWC and decorators

Describe the bug
When attempting to build a NextJS 12 project with SWC, it errors out with:
Syntax error: Support for the experimental syntax 'decorators-legacy' isn't currently enabled
To Reproduce
Steps to reproduce the behavior:

Create a new NextJS 12 project
Add next-api-decorators
Add a decorator to the code
Build & Run

Expected behavior
It builds and runs.
Screenshot

Notes
When attempting to build the project with the following .babelrc:
{
  "presets": ["next/babel"],
  "plugins": [
    "babel-plugin-transform-typescript-metadata",
    ["@babel/plugin-proposal-decorators", { "legacy": true }],
    ["@babel/plugin-proposal-class-properties", { "loose" : true }]
  ]
}

it works as expected. A solution with SWC would be ideal.
The docs state that this project works with SWC by setting some flags in the tsconfig.json:
https://next-api-decorators.vercel.app/docs/#using-with-swc
This does not work, as demonstrated in the screenshot.

Hi @anthonyalayo
It seems like you have a .babelrc file in your project, is that correct? Because I could reproduce your issue only by having a .babelrc file in the project.
If you have it, indeed you have to have the correct configuration (as you posted), on the other hand if you want to use SWC, you shouldn't have a babel configuration file.

Hey @ggurkal
Sorry if it wasn't clear. I did not have a .babelrc in my project. Without it, it gave me the screenshot I put on the issue. I was forced to add the .babelrc just so I could have something working as a workaround in the meantime. I want to remove it. 😄

I just created a project with create-next-app, installed this package and used the decorators without any problem. It'd be helpful if you could create a repo that reproduces your error.

@ggurkal, how's this?
https://github.com/anthonyalayo/decorators-next-example

Upon building the example, I saw it binary pass/fail after doing this:
https://github.com/storyofams/next-api-decorators/issues/402#issuecomment-1115888121

Hey @anthonyalayo
You're using the next-superjson package which injects a babel plugin on files under the pages directory. As it's stated in their readme: https://www.npmjs.com/package/next-superjson

This plugin will inject the superjson babel plugin only on files under the pages directory so you can keep using swc for all the other files.

When I replaced module.exports = withSuperjson()(nextConfig) with module.exports = nextConfig, it started working.

Aha, interesting. So it looks like superjson isn't compatible.. that's unfortunate. Thank you!


TypeScript Pre-Emit Diagnostics

TypeScript's pre-emit diagnostics (equivalent of tsc --noEmit) are now ran before compilation, throwing an error on any TypeScript error.
Closes #138

I realized that it would be a lot better if I could use something that would work in browser, so I plan on migrating to ts-morph with the virtual file system before merging this


staging of merging upstream into fork

Guidelines
Soft Schema Freeze
The nmdc-schema and berkeley-schema-fy24 schemas are under a soft freeze, which means changes should not be made that have any downstream implications. To ensure this, all PRs created during the freeze will be closely reviewed with every component of the NMDC system in mind.
Reviewers
To ensure no changes are made unexpectedly, PR creators will use this PR template to tag and notify all task coordinators. Review should be specifically requested from all Berkeley Schema Roll Out task coordinators that you expect to be affected by this PR.
We expect task coordinators to review PRs and provide feedback/approval within 1 week of when they are identified as reviewers.
PRs will NOT be merged until all task coordinators (or their delegates) have approved it; either here on GitHub (via "Review changes > Approve" or an equivalent comment) or verbally.
Expedition, questions, and discussion can happen at any meeting.
Delays in review & merging should be addressed in meetings or with NMDC leadership.

If you expect the changes toimpact this component...
...request a reviewfrom this person

MetadataSchema
@mslarae13

RuntimeMongo databaseDatabase migrations
@eecavanna,who will pull in@shreddd as needed

PostgresIngest
@naglepuff

Data Portal
@aclum

Workflows: MG & MT
@mbthornton-lbl

Workflows: MetaB & NOM
@corilo

Workflows: LipidO
@kheal

Workflows: MetaP
@SamuelPurvine

ETL code
@sujaypatil96

Jupyter notebooks
@brynnz22

PR Information
What type of PR is this? (check all applicable)

[ ] Refactor
[ ] Feature
[ ] Bug Fix
[ ] Optimization
[ ] Documentation
[ ] Schema change: Structure and content

created, updated, or deleted a class, slot, or enum
changed whether a slot is multivalued
changed the way a slot is assigned to a class
changed the permissible_values of an enum
etc.

[ ] Schema change: Cleanup and preparation

updated the description of a class, slot, or enum
updated the mappings of a class, slot, or enum to an ontology
added an enum for future use (it is not in the range of any slot)
etc.

Description

PRs should be small and concise.
Aim to create small, focused pull requests that fulfill a single purpose. Smaller pull requests are easier and faster to review and merge, leave less room to introduce bugs, and provide a clearer history of changes.

Replace this text with a description of what this PR branch contains. Please keep in mind that all reviewers will be reading this description. Example: "In this branch, I..."

Related Issues

All PRs should relate to or fix an issue(s). Please identify the issue(s) below.

Related Issue(s): #
Fixes: #

Did you add/update any tests?

[ ] Yes
[ ] No (Add a justification below)
[ ] I need help with writing tests

Could this schema change make it so any valid data becomes invalid?

This is a question about what the schema allows. It is not a question about what happens to exists in the NMDC database right now.
Example: If, in this PR branch, you renamed a slot from foo to foo_bar, the answer to this question would be "yes," even if nothing in the NMDC database currently uses the foo slot.
More examples: slot or class name changes, changes to a slot's multivalued state, changes to a slot's range (e.g. string to integer), changes to slot assignments to classes, changes to an enum's permissible_values

[ ] Yes (A migrator is required)
[ ] No
[ ] I need help determining this

If you answered "Yes", does this PR branch include that migrator?

[ ] Yes
[ ] No, this PR is incomplete and I need help writing the migrator

Does this PR have any downstream implications?

Examples: any change here that requires a change to workflows, workflow automation, the Mongo-to-Postgres ingest process, Jupyter notebooks, the Runtime, etc.

[ ] Yes (Explain below)
[ ] No

@kheal please help with these (either Zoom or asynchronously)
poetry run linkml-validate --schema nmdc_schema/nmdc_materialized_patterns.yaml --target-class Database src/data/problem/valid/Database-interleaved.yaml

[ERROR] [src/data/problem/valid/Database-interleaved.yaml/0] 'nmdc:mscon-99-oW43DzG1' does not match '^(nmdc):chrcon-([0-9][a-z]{0,6}[0-9])-([A-Za-z0-9]{1,})$' in /configuration_set/0/id
[ERROR] [src/data/problem/valid/Database-interleaved.yaml/0] 'nmdc:mscon-99-oW43DzG2' does not match '^(nmdc):chrcon-([0-9][a-z]{0,6}[0-9])-([A-Za-z0-9]{1,})$' in /configuration_set/1/id

poetry run linkml-validate --schema nmdc_schema/nmdc_materialized_patterns.yaml --target-class Database src/data/problem/valid/Database-mass-spectrometry.yaml

[ERROR] [src/data/problem/valid/Database-mass-spectrometry.yaml/0] 'nmdc:mscon-99-oW43DzG1' does not match '^(nmdc):chrcon-([0-9][a-z]{0,6}[0-9])-([A-Za-z0-9]{1,})$' in /configuration_set/0/id
[ERROR] [src/data/problem/valid/Database-mass-spectrometry.yaml/0] 'nmdc:mscon-99-oW43DzG2' does not match '^(nmdc):chrcon-([0-9][a-z]{0,6}[0-9])-([A-Za-z0-9]{1,})$' in /configuration_set/1/id

poetry run linkml-validate --schema nmdc_schema/nmdc_materialized_patterns.yaml --target-class Database src/data/problem/valid/Database-mass_spectrometry_gc.yaml

[ERROR] [src/data/problem/valid/Database-mass_spectrometry_gc.yaml/0] 'nmdc:mscon-99-oW43DzG0' does not match '^(nmdc):chrcon-([0-9][a-z]{0,6}[0-9])-([A-Za-z0-9]{1,})$' in /configuration_set/1/id

@aclum can you please help with
poetry run linkml-validate --schema nmdc_schema/nmdc_materialized_patterns.yaml \
    --target-class Database src/data/problem/valid/Database-metatranscriptome_workflow.yaml

[ERROR] [src/data/problem/valid/Database-metatranscriptome_workflow.yaml/0] 'nmdc:dobj-11-547rwq72' does not match '^(nmdc):(bsm|procsm)-([0-9][a-z]{0,6}[0-9])-([A-Za-z0-9]{1,})$' in /workflow_execution_set/2/has_input/0

One thing I have had to work though when adding new classes from nmdc-schema (like EukEval) is that the classes require association with the type slot and the inclusion of a class_uri. The examples data files needed to assert their type. I wponder if we can add some of that stuff in nmdc-schema from the beginning, if were ever going to be in  back-merge situation again.

@turbomam  this is a general issue with ID mention constraints when the class is Database, if you make the first record a ReadQcAnalysis record i believe it will pass. @bmeluch had an comment to this effect in one of her invalid files and I just switched it from Database to the specific type but we need to get to the bottom of this.

Thanks @aclum and @SamuelPurvine . I'm looking though your comments now.
@kheal couldn't replicate the invalid response I was getting form the src/data/problem/valid files I was seeing on one of my computers. I couldn't replicate it in a fresh checkout on a different computer either. So I'm going to move them to src/data/valid

@aclum

Do we still need nmdc_schema/create_legacy_orphan_deletion_requests.py?
Does it really need to live in nmdc_schema, the root of the PyPI package?  If so, I would want to

give it a click CLI
remove hard-coded file arguments
ensure that the inputs are either checked into an appropriate subfolder of assets/, or that they can be regenerated from a Makefile target

RE nmdc_schema/create_legacy_orphan_deletion_requests.py, it has been using for other folks to have a template for generating queries:run commands, I've moved this to the task_specific_code folder as that seems more appropriate.

RE nmdc_schema/create_legacy_orphan_deletion_requests.py, it has been using for other folks to have a template for generating queries:run commands, I've moved this to the task_specific_code folder as that seems more appropriate.

Thanks for moving it. Where do the inputs come from?

Updated previous release notes

Typically some other ad hoc mongo query that is then exported in csv or json to get a list of IDs. The use cases vary. @kheal had to do it recently for some NOM records that were accidentally duplicated.

The changes in nmdc_schema/migrators/ look correct to me.


Unclear that Commit with enumerable of offsets will commit at N-1

Commit with ConsumeResult commits at Offset + 1
Commit with IEnumerable offsets commits at offset.
        /// <remarks>
        ///     A consumer at position N has consumed
        ///     messages with offsets up to N-1 and will
        ///     next receive the message with offset N.
        ///     Hence, this method commits an offset of
        ///     <paramref name="result" />.Offset + 1.
        /// </remarks>
        void Commit(ConsumeResult<TKey, TValue> result);

https://github.com/confluentinc/confluent-kafka-dotnet/blob/d65c05a5a1e6e2a0df4745cdf1c50ebc7a1aeae9/src/Confluent.Kafka/IConsumer.cs#L356

that's correct. void Commit(ConsumeResult<TKey, TValue> result); is a convenience method that 'helps' you by defaulting to the behavior you probably need. the IEnumerable overload works explicitly as defined. the docs would be better if they explicitly called out the difference.


Unable to reach backend server

Hi,
I've searched through the previous issues relating to this but so far I'm unable to understand what is wrong with my server configuration. The Hauk client works fine on the demo server, but I get the following message on the client using my server,  I'm using a domain hosted with TSOhost:
Waiting for initial GNSS fix
Waiting for high accuracy
Unable to reach backend server
The shared link issued displays:
"Location expired
The shared location you tried to access was not found on the server. If this link worked before, the share might have expired."
I only have limited access via ssh, I cannot run sudo commands on my server, but the hosting support personal assure me that Memcached is currently up and running through the command line. I have to take their word for it, I have no way to verify this.
bash-3.2$ ps aux | grep memcached
bash: ps: command not found
bash-3.2$ sudo netstat -tulpnx | grep memcached
bash: sudo: command not found
bash-3.2$ php -i | grep memcache
memcache
memcache support => enabled
memcache.allow_failover => 1 => 1
memcache.chunk_size => 32768 => 32768
memcache.compress_threshold => 20000 => 20000
memcache.default_port => 11211 => 11211
memcache.hash_function => crc32 => crc32
memcache.hash_strategy => consistent => consistent
memcache.lock_timeout => 15 => 15
memcache.max_failover_attempts => 20 => 20
memcache.protocol => ascii => ascii
memcache.redundancy => 1 => 1
memcache.session_redundancy => 2 => 2
memcached
memcached support => enabled
libmemcached version => 1.0.18
memcached.compression_factor => 1.3 => 1.3
memcached.compression_threshold => 2000 => 2000
memcached.compression_type => fastlz => fastlz
memcached.serializer => php => php
memcached.sess_binary => 0 => 0
memcached.sess_connect_timeout => 1000 => 1000
memcached.sess_consistent_hash => 0 => 0
memcached.sess_lock_expire => 0 => 0
memcached.sess_lock_max_wait => 0 => 0
memcached.sess_lock_wait => 150000 => 150000
memcached.sess_locking => 1 => 1
memcached.sess_number_of_replicas => 0 => 0
memcached.sess_prefix => memc.sess.key. => memc.sess.key.
memcached.sess_randomize_replica_read => 0 => 0
memcached.sess_remove_failed => 0 => 0
memcached.sess_sasl_password => no value => no value
memcached.sess_sasl_username => no value => no value
memcached.store_retry_count => 2 => 2
memcached.use_sasl => 0 => 0
Registered save handlers => files user memcached memcache
session.save_handler => memcache => memcache
bash-3.2$
info.php - memcache section displays
memcached support | enabled
Version | 3.1.3
libmemcached version | 1.0.18
SASL support | yes
Session support | yes
igbinary support | no
json support | no
msgpack support | no
Any help in trying to resolve would be much appreciated.
Thanks,
Andy

Web server logs?

Thanks for responding licaon-kter.
 Since you also get the "Location expired" error when trying to view the share in browser, the latter is the most likely. Do you have access to run memcached-tool on the server?

I would have to ask the hosting support staff to run that command, it returns command not found. They are pretty good at assisting with any system side stuff that I don't have the user capabilities to do myself. Is there anything I can forward for them to check, or is there any output from memcached-tool you want me to ask them to extract and forward?


STP. Infoton rate misleading

Now that statistics are persisted across restarts of the agent, the infoton rate is completely inaccurate as the calculation will incorporate all infotons previous but only consider the time the agent has run since restart. This leads to wildly inaccurate numbers. I think this figure should show as best as possible a point in time rate - or at least the rate taking into consideration the time since last restart

https://github.com/CM-Well/CM-Well/pull/947

After talking with Yan decided to use one minute moving average

Infoton rate name is a bit misleading, i would suggest to change it to Consume/Download Rate
Currently agent which is not consuming data at all, still show numbers which are greater then 0. dont quite understand how it is possible, We decided to measure rate once a minute per this minute of work. So I would expect the rate to be 0!
As I said we should monitor rate once a minute, but if refreshing the STP dashboard each second on working agent, you would see that the rate changes constantly

Good, but now the Horizon dissapeared

Separate issue - #918

Verified and Closed


Bump parity-common

Bringing in the changes from https://github.com/paritytech/parity-common/pull/859

Thanks @pgherveou. Published a new version at https://crates.io/crates/ethabi-decode/1.1.0

This should've been published as 2.0 as this is a breaking change.

This should've been published as 2.0 as this is a breaking change.

Yeah this might trip up some updates, @vgeddes we should yank it and push 2.0 instead, will push a PR for this

Yes please, this seems to be breaking. I tried to updated in https://github.com/paritytech/try-runtime-cli and encountered weird build errors.


idea: make inserting commands in the command line frictionless

Currently you are forced to copy paste commands from the LLM output back into the commandline.
It would be nice if the most likely command that you would copy paste would already be filled in so you just have to press enter.
This could be encouraged with a prompt that returns structured output, e.g. text + optional command to fill in the command line.
Alternatively a way to copy & paste command lines with some tmux plugin may also work.
I was using https://github.com/Realiserad/fish-ai until now which allows getting commands inserted into the command line only. It doesn't come with any explanations or visibility of the tmux history though.

Woah fish-ai is pretty cool! I think I figured out a way to add this using tmux tmux send-keys "your command here". I'll play around with it a bit to see if I can get it working. Thanks for the suggestion!!

@tfriedel
This is now supported via the --c flag. For example, you can now run: ssage --c How can I list all files including the hidden ones? and it will now insert the command directly into your terminal so you can simply press Enter to execute it 🤓

FYI, you will need to install shell sage from main for now until I make a new release on pypi


document support for http proxies

Here's how I configured a proxy:
credentials = MicrosoftKiotaAuthenticationOAuth::ClientCredentialContext.new(
  ENV.fetch('MICROSOFT_GRAPH_TENANT_ID'),
  ENV.fetch('MICROSOFT_GRAPH_CLIENT_ID'),
  ENV.fetch('MICROSOFT_GRAPH_CLIENT_SECRET')
)
authentication_provider = MicrosoftGraphCore::Authentication::OAuthAuthenticationProvider.new(
  credentials, nil, %w[https://graph.microsoft.com/.default]
)
request_adapter = MicrosoftGraph::GraphRequestAdapter.new(authentication_provider)
request_adapter.client.proxy = "http://example.org:8080"
graph_client =  MicrosoftGraph::GraphServiceClient.new(request_adapter)

Thanks for providing the information here. For information this is meant to go to this page but we'll add all the information in one shot for the section when we start putting documentation out there for ruby


Fixed #25239 -- Corrected makemigrations numbering if the latest migration has a number-only filename.

https://code.djangoproject.com/ticket/25239

merged in de41fbb3cf39cf24387ba03e6a6cfb697a789a2d, thanks!


Add functionSignatures.json

Nothing fancy - just copies from "which" functionSignatures.

@michellehirsch Do you want to merge this?


Restoring a project archive with two designs with Icepak(...) creates a 3rd design in the project

Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

Description of the bug
If I restore a project archive by passing the archive path to the Icepak(...) constructor, it works fine when the archived project contains a single design. However, with a project with two designs such as

the command
ipk = Icepak(specified_version="2022.2", new_desktop_session=True, projectname="C:\\temp\\ProjectWithTwoDesigns.aedtz")
erroneously restores to a project with three designs:

When I restore the archive through the native API command, e.g. by
desktop = Desktop(specified_version="2022.2", new_desktop_session=True)
desktop.odesktop.RestoreProjectArchive(archive_path, project_path, True, True)

the project is restored correctly.
Steps To Reproduce
Create a project with two Icepak designs "Design1" and "Design2". Archive the project e.g. as C:\temp\ProjectWithTwoDesigns.aedtz
Use the command
ipk = Icepak(specified_version="2022.2", new_desktop_session=True, projectname="C:\\temp\\ProjectWithTwoDesigns.aedtz")
to restore/open the archive. Three designs are now present (Design1, Design2, and a 3rd one with a random name).
Which Operating System are you using?
Windows
Which Python version are you using?
3.8
Installed packages
ansys-templates==0.5.2
arrow==1.2.3
astroid==2.15.1
attrs==22.2.0
autocommand==2.2.2
binaryornot==0.4.4
bottle==0.12.25
build==0.10.0
certifi==2022.12.7
cffi==1.15.1
cfgv==3.3.1
chardet==5.1.0
charset-normalizer==3.1.0
cheroot==9.0.0
click==7.1.2
clr-loader==0.2.5
colorama==0.4.6
contourpy==1.0.7
cookiecutter==2.1.1
coverage==7.2.3
cycler==0.11.0
dill==0.3.6
distlib==0.3.6
exceptiongroup==1.1.1
filelock==3.10.0
flake8==6.0.0
fonttools==4.39.2
gevent==22.10.2
greenlet==2.0.2
identify==2.5.21
idna==3.4
imageio==2.26.1
importlib-metadata==6.1.0
importlib-resources==5.12.0
inflect==6.0.2
iniconfig==2.0.0
isort==5.12.0
jaraco.collections==4.0.0
jaraco.context==4.3.0
jaraco.functools==3.6.0
jaraco.text==3.11.1
Jinja2==3.1.2
jinja2-time==0.2.0
kiwisolver==1.4.4
lazy-object-proxy==1.9.0
MarkupSafe==2.1.2
matplotlib==3.7.1
mccabe==0.7.0
more-itertools==9.1.0
mypy==1.1.1
mypy-extensions==1.0.0
nodeenv==1.7.0
numpy==1.24.2
packaging==23.0
Pillow==9.4.0
platformdirs==3.1.1
pluggy==1.0.0
plumbum==1.8.1
pooch==1.7.0
portend==3.1.0
pre-commit==3.2.0
psutil==5.9.4
py==1.11.0
pyaedt==0.6.61
pycodestyle==2.10.0
pycparser==2.21
pydantic==1.10.7
pyflakes==3.0.1
pylint==2.17.1
pyparsing==3.0.9
pyproject_hooks==1.0.0
pytest==7.2.2
pytest-cov==4.0.0
pytest-html==3.2.0
pytest-metadata==2.0.4
pytest-timeout==2.1.0
pytest-xprocess==0.22.2
python-dateutil==2.8.2
python-slugify==8.0.1
pythonnet==3.0.1
pytz==2023.3
pyvista==0.38.5
pywin32==306
PyYAML==6.0
requests==2.28.2
rpyc==5.3.0
scooby==0.7.1
six==1.16.0
tempora==5.2.1
text-unidecode==1.3
tomli==2.0.1
tomlkit==0.11.7
typing_extensions==4.5.0
urllib3==1.26.15
virtualenv==20.21.0
vtk==9.2.6
waitress==2.1.2
wrapt==1.15.0
zc.lockfile==3.0.post1
zipp==3.15.0
zope.event==4.6
zope.interface==6.0

Hi @clguenthe,
This is correct and has been implemented as a safety reason.
To avoid this behavior you should specify the design name when instantiating Icepack with variable "designname".
Hope this help.
Thanks!
Giulia

Hi @gmalinve , I agree, this is indented behavior. I didn't think of this when I picked up this issue. I will close this issue.
Thanks
Regards,
Siva

One question @gmalinve and @sivasu37: What is the reason for this to happen only to projects with 2 designs, not to projects with a single design? And why is this required for safety reasons? I must say that for me as a user, this behavior is completely unexpected and also not clear through the documentation. Expected behavior from my point of view would be to a) get the same behavior for projects with 1 or 2 designs, and b) have the project "unchanged" through the restore operation. Could you help me here to better understand this? Maybe I have missed an important thought here in the PyAEDT approach?

Hi @clguenthe , When an Icepak object is created it needs to have access to the Icepak design available in the electronics desktop project.
When you create a Icepak object without any argument to design name it has to look for a available design and load the design in the Icepak object.

This is clear when you have only one Icepak design, that design will be loaded into Icepak object.

But when you have multiple Icepak designs in the project. We cannot select any one of that design and load into the Icepak object (as it is not clear what design user wants to load). The safer option is to create a new design. If a user wants to load a particular design among the two designs, he has to specify the design name as an argument when creating Icepak objects. In this case, no new Icepak designs will be created.

@clguenthe , Yes, I can add an example showcasing this behavior in the documentation. We currently display the following info in the messages
pyaedt INFO: No consistent unique design is present. Inserting a new design.
pyaedt INFO: Added design 'Icepak_EGA' of type Icepak.
I am also looping in @maxcapodi78 for his comments, As I believe this behavior should be common for other designs like Maxwell and HFSS


toggle items from the  editor menu bar

I would like to remove the diffWithPrevious and related buttons from the editor menu bar, to open up valuable real estate, but can't seem to find the way to do so. Is it possible, and how, etc.

You also use the GitLens interactive settings editor from the command palette run GitLens: Open Settings, and jump to the Menus & Toolbars section


Allows creating roles with latest-policies

This PR allows to enforce latest-policies
Signed-off-by: Krishna Harsha Voora<EMAIL_ADDRESS>

@dry923 @morenod ptal

Do you have a doc link for this requirement? roles creation has been always included in the rosa create cluster command, why is now required to pre-execute it?
If it is really required, and cluster install will fail if this command fails, we need to capture command return code, and manage it to break installation or not

This was reported here
https://redhat-internal.slack.com/archives/C04EUL1DRHC/p1677855396643189?thread_ts=1677855396.643189&cid=C04EUL1DRHC
Gist of this PR, despite on latest rosa-cli GA branch, the latest policies were not in effect, as a result, HCP didn't had get any awsmachine worker pool, upon applying these changes, the nodepool came up properly.

Is this something to be executed before or after cluster is created?
I see two commands on the slack chat:
rosa create account-roles which is actually being executed, but not added on the scripts, because it is only required one time just before start creating clusters on aws (or when policies changes)
rosa create operator roles -c <cluster_id> -m auto -y -f which seems to be executed after cluster is installed, as it requires the ClusterID as parameter.
This is the same command you want to add to the script, but before cluster is installed, is that right?
Can you paste some log of this code execution?

+1 to @morenod 's comment re the timing of when it needs to be created and also I'm concerned that this is only ever creating new policy's but never cleaning them up

@dry923 @morenod Agreed, this should happen post-creation of HCP.

Can you paste some log of this code execution?

I'll be sure to get you the logs.

I'm concerned that this is only ever creating new policy's but never cleaning them up

We are already cleaning  them here:
https://github.com/cloud-bulldozer/perfscale-managed-services/blob/main/rosa-hypershift/rosa-hosted-wrapper.py#L955

This can be closed..


LWJGL3: File not found: sprites\sprites.atlas (Internal)

Issue details
AssetManager says that sprites.atlas can't be found when game is run, even though I have packed the sprites to correct directory.
Reproduction steps/code
The code is here.
To build, cd to root directory and run:
$ gradlew.bat tools:packSprites
$ gradlew.bat desktop:dist

Then, cd to ./desktop/build/libs, and run:
$ java --enable-preview -jar Innerclash.jar

Game window opens, then closes due to crash.
A crash log should appear in %APPDATA%\Innerclash\crashes.
Note that this project is made for Java 15.
Version of LibGDX and/or relevant dependencies
libGDX version is 1.9.12, and I only use gdx-tools, gdx-backend-lwjgl3, gdx-platform, and gdx-controllers-lwjgl3.
Stacktrace
Here's the crash log from a generated file:
Innerclash has crashed!
How could this be?

Stacktrace:
com.badlogic.gdx.utils.GdxRuntimeException: com.badlogic.gdx.utils.GdxRuntimeException: File not found: sprites\sprites.atlas (Internal)
	at com.badlogic.gdx.assets.AssetManager.handleTaskError(AssetManager.java:634)
	at com.badlogic.gdx.assets.AssetManager.update(AssetManager.java:413)
	at com.badlogic.gdx.assets.AssetManager.update(AssetManager.java:425)
	at innerclash.ICLauncher.update(ICLauncher.java:63)
	at innerclash.ICLauncher.render(ICLauncher.java:103)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:403)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:141)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:117)
	at innerclash.desktop.DesktopLauncher.main(DesktopLauncher.java:17)
Caused by: com.badlogic.gdx.utils.GdxRuntimeException: File not found: sprites\sprites.atlas (Internal)
	at com.badlogic.gdx.files.FileHandle.read(FileHandle.java:142)
	at com.badlogic.gdx.graphics.g2d.TextureAtlas$TextureAtlasData.<init>(TextureAtlas.java:104)
	at innerclash.graphics.ICTextureAtlas$ICTextureAtlasLoader.getDependencies(ICTextureAtlas.java:101)
	at innerclash.graphics.ICTextureAtlas$ICTextureAtlasLoader.getDependencies(ICTextureAtlas.java:74)
	at com.badlogic.gdx.assets.AssetLoadingTask.handleSyncLoader(AssetLoadingTask.java:99)
	at com.badlogic.gdx.assets.AssetLoadingTask.update(AssetLoadingTask.java:89)
	at com.badlogic.gdx.assets.AssetManager.updateTask(AssetManager.java:561)
	at com.badlogic.gdx.assets.AssetManager.update(AssetManager.java:411)
	... 7 more

Sidenotes
I am very new to both Java programming and using libGDX, I would be really grateful if you could help me. Sorry to waste your time.
I'll be back tomorrow.
Please select the affected platforms

[ ] Android
[ ] iOS
[ ] HTML/GWT
[x] Windows
[ ] Linux
[ ] MacOS

Unfortunately, gdx-tools is only compatible with the lwjgl backend ("desktop",  not lwjgl3) if used at runtime. People usually pack atlases independently of their project using either a tool like the free Texture Packer GUI or the command-line version of gdx-tools' texture packer. If they pack in code, they have to either have a separate module that depends on gdx-tools and the lwjgl, AKA desktop, backend (which is a good idea, since it means your distributable JARs are a little smaller), or use lwjgl throughout, or use PixmapPacker to pack editable images at runtime. PixmapPacker is part of libGDX, not gdx-tools, so it works with LWJGL 2 and 3, plus Android, iOS, etc.
I'll take a look at your code, since there are ways you can use gdx-tools with LWJGL3 by excluding some of its features. If you've done that, then the error could be caused by something very different.

Well, a full error log sure would have helped...
> Task :tools:packSprites FAILED
Exception in thread "main" java.lang.NoClassDefFoundError: innerclash/Innerclash
        at innerclash.tools.SpritePacker.<init>(SpritePacker.java:30)
        at innerclash.tools.SpritePacker.main(SpritePacker.java:25)
Caused by: java.lang.ClassNotFoundException: innerclash.Innerclash
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:606)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        ... 2 more

FAILURE: Build failed with an exception.

* Where:
Build file 'D:\Downloads\Innerclash\Innerclash-master\tools\build.gradle' line: 24

You've done some very strange setup that I do not feel I can fix, since you are depending on your Innerclash class (in the main project) from the tools project's buildscript. The buildscript parts of gradle are... odd, and I have never used them much. I really need to recommend crashinvaders' GDX Texture Packer GUI again; it should make the tools project unneeded. It actually looks like you might just be breaking up an image into a grid of sections, which TextureRegion can do on its own.
That said, this is not a bug in libGDX, it's a bug in your Gradle configuration, so this is not the right place for this. The discord may be more suitable.

Why didn't that happen to me

Forget it, I'm joining the discord


Add postgres 'distinct on' expression support

Postgres supports distinct on expressions but query builder does not support this fature. The only way I've found is  to use db expression in select method with some column
For example:
if ($distinctRequired) {
   $query->select(new Expression("DISTINCT ON (item.main_id) item.id"))
}

But may be it's better to add special distinctOn method?
if ($distinctRequired) {
   $query->distinctOn('main_id')
}

ебучий шляпник


docs(api.md): add note on page.pdf() color rendering behavior

Adds guidance for producing accurate colors in PDF output. page.pdf() can produce unexpected document colors unless forced to render exact colors.
References #2685

I signed it!


Fix problem with unreachable ref in submodule

If you have a submodule with a ref that is not the current HEAD, it can become unreachable and therefore the deployment fails.
Removing the --depth 1 option fixes the problem.
I added a linebreak seperating the "Deleted" statements, too, hope thats ok.
Cheers

Thanks


Remove unnecessary link

It's point to itself, should not in What's the next section.
fix #141

good catch, thanks


tests: increase code coverage in console.go

fixes #492
Signed-off-by: Julio Montes<EMAIL_ADDRESS>

Coverage increased (+0.6%) to 88.952% when pulling b6ae3591e6005504163ac82828b04c93d3c9a587 on devimc:unitTest/console into cde66af517a3d6388a14968a8d22acff818e8d61 on clearcontainers:master.

lgtm


RuntimeError: This event loop is already running

Describe the bug
I am getting a RuntimeError: This event loop is already running error after I run the code below.
To Reproduce
Here is my code:
from TikTokLive import TikTokLiveClient
from TikTokLive.types.events import CommentEvent

client: TikTokLiveClient = TikTokLiveClient(
    unique_id="lolmicv", **(
        {
            "enable_extended_gift_info": True
        }
    )
)

@client.on("comment")
async def on_comment(event: CommentEvent):
    print(f"{event.user.uniqueID} -> {event.comment}")

if __name__ == '__main__':
    client.run()

Expected behavior
Printing the comments of people on that live.
Desktop (please complete the following information):
Windows 10, Anaconda
Additional context
Here is the full version of the error i am getting:
runcell(0, 'C:/Users/arasu/Desktop/tiktok_live/tiktok_live.py')
Traceback (most recent call last):

  File "C:\Users\arasu\anaconda3\envs\tiktok_test\lib\site-packages\spyder_kernels\py3compat.py", line 356, in compat_exec
    exec(code, globals, locals)

  File "c:\users\arasu\desktop\tiktok_live\tiktok_live.py", line 17, in <module>
    client.run()

  File "C:\Users\arasu\anaconda3\envs\tiktok_test\lib\site-packages\TikTokLive\client\base.py", line 483, in run
    self.loop.run_until_complete(self._connect(session_id=session_id))

  File "C:\Users\arasu\anaconda3\envs\tiktok_test\lib\asyncio\base_events.py", line 563, in run_until_complete
    self._check_runnung()

  File "C:\Users\arasu\anaconda3\envs\tiktok_test\lib\asyncio\base_events.py", line 523, in _check_runnung
    raise RuntimeError('This event loop is already running')

RuntimeError: This event loop is already running

Hello, can you tell me what version of Python you are using? Cannot reproduce on 3.8

Also works in 3.11.....

i am using a pretty old version of anacondo for workplace purposes. I tested the code with 3.7 and 3.8. they both are giving me the same error. if it is working in your environment, it should be related to my environment. I will update my environment in some weeks and test it. Thank you for the response. If this code piece worked in your environment, this is enough for me.

Hi, yes, the library only supports >3.8 at the moment. It is likely you could solve your issue in 3.7 by using the following code snippet, though I do not have time to test it:
import asyncio

from TikTokLive import TikTokLiveClient
from TikTokLive.types.events import CommentEvent

loop = asyncio.get_running_loop()

client: TikTokLiveClient = TikTokLiveClient(
    loop=loop,
    unique_id="jakeandrich", **(
        {
            "enable_extended_gift_info": True
        }
    )
)

@client.on("comment")
async def on_comment(event: CommentEvent):
    print(f"{event.user.uniqueId} -> {event.comment}")

if __name__ == '__main__':
    client.run()

It seems that the loop is already running. Thus, it stands to reason if you just 'get' the loop, the error should go away.

thank you for the answer. I tried the code you suggested but i am still getting the exact same error. i think it will be better to test it after i update my environment. i will also test the nest-asyncio but i think i tried it before. i was getting a similar error with it. my environment is super old so i think this is the reason it is not working.


HIVE-27689: Iceberg: Remove unsed iceberg property

What changes were proposed in this pull request?

Why are the changes needed?

It makes me feel confuesd when reading the code about InputFormatConfig.OPERATION_TYPE_PREFIX. This property introduced by HIVE-26102 was originally used to indicate the operation type of a output table, e.g DELETE&UPDATE&MERGE.
But after HIVE-26202 and HIVE-26264, this property won't get actual table operation type and it only can be used to identify the output table.
We should remove this property from current code snippet as this will misunderstand the meaning of the code, and use a proper term to indicate this table is an output table.
Does this PR introduce any user-facing change?

Is the change a dependency upgrade?

How was this patch tested?

I think we could still leverage iceberg.mr.operation.type for COW

Sure, I didn't delete it InputFormatConfig.OPERATION_TYPE_PREFIX, just remove it from these code block to avoid misunderstanding.


libatomic problems causing unexpected fails

Applications may crash on startup with the following message
terminate called after throwing an instance of 'hpx::detail::exception_with_info<hpx::exception>'
  what():  big_boot_barrier has not been created yet: HPX(internal_server_error)

upon investigation, it turns out that the following exception is being thrown during initialization/startup
https://github.com/STEllAR-GROUP/hpx/blob/1527f3ba8055f795f701ddf89368f4a24199f79e/libs/full/threadmanager/src/threadmanager.cpp#L322-L329
which in turn causes the runtime destructor to be called, but the runtime has not yet started, so it throws the error that we actually see about the big boot barrier not being started. So the first exception needs to be caught somewhere and displayed, before the stack unwinds and throws the second.
Looking deeper, the problem is being caused by the following check failing during cmake configuration.
-- Looking for __atomic_fetch_add_4 in atomic
-- Looking for __atomic_fetch_add_4 in atomic - not found

which in turn means that HPX_WITH_CXX11_ATOMIC_128BIT is not set. If I manually run the cmake feature check withoout linking libatomic, we see link errors
oryx2:~/build/hpx-master$ g++ ~/src/hpx/cmake/tests/cxx11_std_atomic_128bit.cpp
/usr/bin/ld: /tmp/ccduIFup.o: in function `std::atomic<uint128_type>::store(uint128_type, std::memory_order)':
cxx11_std_atomic_128bit.cpp:(.text._ZNSt6atomicI12uint128_typeE5storeES0_St12memory_order[_ZNSt6atomicI12uint128_typeE5storeES0_St12memory_order]+0x66): undefined reference to `__atomic_store_16'
/usr/bin/ld: /tmp/ccduIFup.o: in function `std::atomic<uint128_type>::load(std::memory_order) const':
cxx11_std_atomic_128bit.cpp:(.text._ZNKSt6atomicI12uint128_typeE4loadESt12memory_order[_ZNKSt6atomicI12uint128_typeE4loadESt12memory_order]+0x40): undefined reference to `__atomic_load_16'
collect2: error: ld returned 1 exit status

but if I add -latomic all is well.
oryx2:~/build/hpx-master$ g++ ~/src/hpx/cmake/tests/cxx11_std_atomic_128bit.cpp -latomic
oryx2:~/build/hpx-master$ <links correctly>

I have only run into this problem on my new laptop using gcc 10.2.0
I'm not quite sure what the correct fix for the atomic problem is.

I opened #5113 for the threadmanager issue.
Do you find that symbol in libatomic if you check manually? I think we have that check there because libatomic isn't even always a separate library so we have to check that it's there in the first place.

I opened #5113 for the threadmanager issue.
Do you find that symbol in libatomic if you check manually? I think we have that check there because libatomic isn't even always a separate library so we have to check that it's there in the first place.

I made a small test based on the LLVM atomics cmake detection code and get this
-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Success
-- Performing Test HAVE_CXX_ATOMICS128_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS128_WITHOUT_LIB - Failed

so it appears as expected, that with my compiler -latomic is not needed for 32/64 bit operations, but is needed for 128 bit operations. Out tests do something different and I wonder if I should just replace them with the LLVM versions.

I made a small test based on the LLVM atomics cmake detection code and get this
-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Success
-- Performing Test HAVE_CXX_ATOMICS128_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMICS128_WITHOUT_LIB - Failed

so it appears as expected, that with my compiler -latomic is not needed for 32/64 bit operations, but is needed for 128 bit operations. Out tests do something different and I wonder if I should just replace them with the LLVM versions.

I think that's normal. The question is why check_library_exists(atomic __atomic_fetch_add_4 "" HPX_HAVE_LIBATOMIC) fails. Either it's not finding libatomic at all, or it's not finding __atomic_fetch_add_4 in there. Is it possible that libatomic only has the 128 bit versions since the rest are not needed? Does libatomic have __atomic_fetch_add_16 but not __atomic_fetch_add_4?

I think that's normal. The question is why check_library_exists(atomic __atomic_fetch_add_4 "" HPX_HAVE_LIBATOMIC) fails. Either it's not finding libatomic at all, or it's not finding __atomic_fetch_add_4 in there. Is it possible that libatomic only has the 128 bit versions since the rest are not needed? Does libatomic have __atomic_fetch_add_16 but not __atomic_fetch_add_4?

The checks we implement end up setting HPX_CXX11_STD_ATOMIC_LIBRARIES to atomic - but as far as I can see, not only are the tests not working, but the variable HPX_CXX11_STD_ATOMIC_LIBRARIES is never actually used anywhere!

The checks we implement end up setting HPX_CXX11_STD_ATOMIC_LIBRARIES to atomic - but as far as I can see, not only are the tests not working, but the variable HPX_CXX11_STD_ATOMIC_LIBRARIES is never actually used anywhere!

@biddisco libatomic is added here if it's available: https://github.com/STEllAR-GROUP/hpx/blob/598104732c7decfde49e9bf40429ccf724705087/CMakeLists.txt#L1788.

@biddisco libatomic is added here if it's available: https://github.com/STEllAR-GROUP/hpx/blob/598104732c7decfde49e9bf40429ccf724705087/CMakeLists.txt#L1788.

@biddisco libatomic is added here if it's available:
https://github.com/STEllAR-GROUP/hpx/blob/598104732c7decfde49e9bf40429ccf724705087/CMakeLists.txt#L1788
.

Aha. very good. Then I should modify my PR to replace that with
if (HPX_CXX11_STD_ATOMIC_LIBRARIES)
 target_link_libraries(hpx_base_libraries INTERFACE ${HPX_CXX11_STD_ATOMIC_LIBRARIES})
endif()

@biddisco libatomic is added here if it's available:
https://github.com/STEllAR-GROUP/hpx/blob/598104732c7decfde49e9bf40429ccf724705087/CMakeLists.txt#L1788
.

Aha. very good. Then I should modify my PR to replace that with
if (HPX_CXX11_STD_ATOMIC_LIBRARIES)
 target_link_libraries(hpx_base_libraries INTERFACE ${HPX_CXX11_STD_ATOMIC_LIBRARIES})
endif()


Query URL version pinning for Icecup?

Pros:

Scripts remain runnable even after breaking version changes.

Cons:

Complicates web worker setup.
Disincentive to upgrade.
Non-uniform behavior depending on URL.

Decided not to do this for now.


fix(rosetta): infuse drops first assembly

As part of a refactor, rosetta infuse no longer utilizes a single tablet file in favor of tablets at the assembly level. However the infuse command still takes in a positional argument TABLET that goes unused. This means that the first argument sent into the command gets dropped.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

btw, it looks like yargs would not "eat" an option as the first positional argument.
rosetta:infuse --cache-from='blah' assembly1 assembly2

result is TABLET=assembly1.


Improve handling of CA renewals and replacements in operands based on the Kafka clients

This proposal improves the API for configuring the trusted certificates in Strimzi Operands and should help to address strimzi/strimzi-kafka-operator#7726.
One of the things I was least sure about is the last rejected alternative: Making certificate and extension fields completely optional. So if anyone has any strong opinions about it, please let me know 😉.

This has now 3 binding and 1 non-binding +1 votes. If you have anything more, please comment. Otherwise, I will aim to close this on Wednesday EOB.

Approved with 5 binding and 1 non-binding votes.


feature gaussian cleanup

This PR contains 3 things:

a minor fix in tissue.reconstruct to check the matrix format before building the sdg.
a new FUN cleaning_expression_data using a BayesianGaussianMixtureModel in order to be able to clean reconstruction data to derive more realistic results
a notebook to demonstrate the function and changes on the data on the example of the drosophila dataset

Details:
1)
The dynamic-matrix check fixes the bug that when the input-matrix is in sparse format building the sdge can lead to wrong dimensions. The check now corrects the matrix format if the given matrix is in sparse.

sorry for the big bunch of white-space changes :}


[EMERGENCY] No Account section in responsive version of global nav

🔥  🔥 🔥
After last changes in global nav I cannot see TT under the profil-avatar nav (only responsive design, desktop is ok).
👇  new global nav responsive

👇  old global nav responsive

👇  new global nav desktop

👇 old  global nav desktop

in order to spam all of you :D
@nickfranciosi @jcreamer898
@bpotterbaum @arielcamus @chrissysievers

I was going to jump into this, but I think it needs input from UI/UX.

Thank you @thomasthesecond, I really appreciate it :)

I got some UX direction on this. Jumping back on it.

On lpstaging.com now


Fix whitespace bug in add command

Add command allows multiple whitespace between names

Resolved with PR #140.


Byte to integer conversions fail on platforms with unsigned char type

When building the C++ library on a platform where char is by default unsigned, byte-to-integer expansion is incorrect in orc::expandBytesToIntegers as well as in a few unit tests.
This can be reproduced on any CPU architecture when building with gcc by compiling with -funsigned-char.

Thank you, @johnwheffner and @wgtmac .

FYI. Apache ORC 1.8.1 is scheduled on December 3rd.
cc @williamhyun

Thank you, @johnwheffner and @wgtmac . For now, I set the milestone 1.9.0, but we can backport it to Milestone 1.8.1.

I can confirm that this issue only exists in the main branch, therefore we don't need backport the fix to branch-1.8.

It's great. Thank you for the confirmation, @wgtmac .

@johnwheffner FYI, this issue has been fixed in the main branch. Please let me know if there is any remaining issue. Thanks!


api docs: Add design details for muted users.

@WesleyAC @abhijeetbodas2001 @alya thoughts on this as the specification for how muted users should work?

I think in cases where we can't hide the user completely (for instance, the list of users in a group PM or stream), we should have some affordance for revealing the name of the user. Does that sound right?
Probably also worth calling out that we want to replace the muted user's avatar with some image that indicates that they're muted in cases where we replace the username with "Muted User". That doesn't happen anywhere in the webapp currently that I know of, but it does happen in mobile, and might happen in the webapp someday.

we should have some affordance for revealing the name of the user. Does that sound right?

I think we should think about this as a goal but not an absolute one.  In the "Muted users" UI, we certainly will need to show the identities of your muted users -- so that you can figure out which one is which for unmuting them -- and I think anyone will expect to see the names of people they've muted when they click on that.
There's likely to be some pretty weird/complex corner cases in administrative and stream settings UI (how do we display the unblinding feature for input pulls when you try to add a user you've muted to a stream?  And how do we manage those users for looking at who to deactivate?). Ultimately it'd be a lot of QA work to make the ~10 settings UI elements that can mention a user have a functional unblinding UI; realistically if we decide to block on that, we'll not be able to ship the feature.
I suppose an alternative strategy to blinding/unblinding UI that displays muted users to just "corrupt" your people.js database for the user with Muted user as their name, and require unmute + reload browser to unblind a muted user (i.e. not write individual unblinding UI). (Or store the data on the muted_user object and restore if needed, in a future version where we want to avoid a reload as part of our policy of having everything live-update).
It's also worth asking the question of whether an absolute "can't see this user's name in settings UI" rule would be expected?  I think realistically even if we do nothing with settings, the main weakness of "Muted users" for protecting people from a determined harasser in an an organization is going to be the fundamental one of "you can make a new account in an open organization".  (And if an organization administrator is being harassed, in most cases they will just deactivate the offending account rather than muting them, so administrative settings UI is likely to not be particularly salient -- some portion of "Mute user" usage will be for individuals in organizations where the moderators are asleep at the wheel).

Probably also worth calling out that we want to replace the muted user's avatar with some image that indicates that they're muted in cases where we replace the username with "Muted User".

I think that's right.  I don't have a great idea for what that image should be.

I actually think it's fine to show the muted user's name in the settings menus. I don't think the feature will feel broken if you can still see the muted user's name there. What feels really invasive is if someone is able to abusively push information, whereas the menus are a non-interactive/"pull" part of the app.
Moreover, if the name is shown, the menus will be more usable for taking further action against the user such as deactivating the account, or looking up some information about them prior to reporting them to an administrator.

What feels really invasive is if someone is able to abusively push information, whereas the menus are a non-interactive/"pull" part of the app.

Yeah, I agree with that. I was mostly thinking about the Group PM case when I wrote that.

I think we should explicitly mention that 1:1 private messages should be completely hidden, as if they didn't exists at all. (At least that was what was decided earlier.)

OK I applied those edits and merged this; here's a screenshot of the resulting documentation:


is sse.js on npm?

I couldn't find it on npm but it seems strange that it would not be published there.

@Amasa-Delano It's published under "sse.js".

Correct, https://www.npmjs.com/package/sse.js.


ARROW-18270: [Python] Remove gcc 4.9 compatibility code

We can use std::regex now that we needn't support gcc 4.9 anymore.

@github-actions crossbow -g python

@github-actions crossbow submit -g python

Will merge if CI passes.


Port to Vert.x 4 and sdk-java 2.0.0-milestone2

Signed-off-by: Francesco Guardiani<EMAIL_ADDRESS>Fixes #136

Proposed Changes

Update to cloudevents sdk-java 2.0.0-milestone2
Update to Vert.x 4

Release Note

Update to Vert.x 4.0.Beta1
Update to cloudevents/sdk-java 2.0.0-milestone2

/retest

/assign @pierDipi


fix edit text cursor

Since the drawable rather than color resource has been specified, the input cursor of EditText did not appear.
before

fixed

:eyes:

Great work! Thanks!

LGTM :+1:


Make typeof start a nested lexical scope

Fixes #10521. The inner expressions do not each reset the variable scope.
The first commit contains the entire fix. The second commit further refactors the parser so that it becomes clearer which and when variable scopes are created by the parser.

That CI error looks... interesting ;)

It seems @meta_vars's identity cannot be clobbered. Hoping this workaround passes...


Map for selecting location

Instead of just typing the location in, display a map to the user (using OpenStreetMap for example), and take the coordinates of their pin and use that to display weather information.
Make it a 2 way thing, and if a user types a location in, it displays a pin on the map as well!
If you have an API key, let @wrussell1999 know so it can be added to the Netlify website hosting it!

Would love to work on this issue 🚀

Interested

Would like to work on this as well


Builder running into an 'import' issue in generate_font.py

Anyone else having this problem on build where it says on line 6 of generate_font.py, "Undefined variable: import"?

Doesn't happen in v2.0.1


Data Race when rebalance notifications are enabled and a rebalance error occurs

in consumer's nextTick function:  https://github.com/bsm/sarama-cluster/blob/d98592677c0aa08d8aafb882d344fb461682b722/consumer.go#L332
A notification is conditionally sent to handleNotification if the configuration of the client calls for notifications to be returned. That same notification is then passed to rebalanceError wherein it is modified. This is altering a value on a struct that has been passed across a channel to another goroutine (the notification handler).
I believe that the notification should either always be copied before it is sent or be copied in the event of an error. This will ensure that the notification handler receives distinct notifications for the rebalance start and rebalance error notifications.

@sronderos-atlassian could you provide a PR for this?

@dim @sronderos-atlassian is there any intent on merging the mentioned change?
I was just bitten by this data race and the patch seems to fix the issue.

This library is deprecated, but I am happy to merge this change if you can you submit a PR?

@pmalekn @dim I'm no longer using this library. Feel free to take over the change that I made above. I don't recall if we ever switched to using the change in a production setting. I'm fairly confident that the change fixes the issue, but I don't have the bandwidth to test it now.

Created a PR: https://github.com/bsm/sarama-cluster/pull/295, let me know if that works.

please note https://github.com/bsm/sarama-cluster#deprecation-notice


protocol parity for audioCreateSpeech

What
protocol parity for audioCreateSpeech
Why
audioCreateSpeech was missing from OpenAIProtocol+Combine
Affected Areas
OpenAIProtocol+Combine

needed main branch merged in. ready for approval, @SunburstEnzo


Minimum text length to show options / results

Hii.
select2 has this options: 'minimumInputLength' that allows the user to open the list just after typing some text.
Do you have this kind of option?
By the way, thanks for the great plugin.

up

up

No such option.


Add shard collection keybind

Extrmely basic keybind that just copies what /shards does. can update to match #18 if needed.
tldr:

:+1: This impl fits in well with our code organization, and it was actually an objective on the design doc


Add initial CreateContainer tests

Signed-off-by: Justin Terry (VM<EMAIL_ADDRESS>

@kevpar - FYI this fixes the pull image problem on clean install and adds tty/non-tty create/start cases. Still need to submit the rest but this is a good starting point.

I am merging since its just tests. Let me know if you think I missed something.


some problems

When I run the program, Maltab gives an error
testShuttle
vehicleTools found a violation of lower throttle limit! Time calculated by this call will likely overestimate true burn time.
 Error: ()-indexing must appear last in an index expression.

 Error flightSim3D (line 391)
        plots().DEBUG = struct();

 Error flightManager (line 47)
    powered(1) = flightSim3D(vehicle, 1, init, s1guidance, events, dt);

 Error testShuttle (line 14)
STS = flightManager(vehicle, site, target, 0.2, stage1, 2, 0, []);

I don't know how to solve it, would you help me?

What MATLAB version are you using? The program was designed using ver. 2013a which is quite old by now.

the version is matlab 2018a

Would you please interpret this codes
" plots().DEBUG = struct()"

The way to solve the problem is to remove the brackets after PLOTS
plots().DEBUG = struct();
transfer to:
plots.DEBUG = struct();

Another question:
Can this matlab programs support multi-ignitions during the launch mission?

Thank you for bringing this to my attention, @GYskyfall, and sorry it took me so long to respond (I'm not very active in this repo these days).
I took a look into it and pushed a fix. There are a few lines where the brackets should be omitted, see 26dba6a for details. To be honest, I don't know why it was necessary in 2013a - I just remember it didn't work without them.
To answer your question: yes, you can program multiple ignitions - you just need to define each iginition as a separate stage (yes this involves doing some math on masses and stuff).


Error: Unable to find a valid app

Getting this error when opening my packaged OS X app:
Uncaught Exception:
Error: Unable to find a valid app

Which version of electron-packager are you using?

5.2.1

What CLI arguments are you passing? Alternatively, if you are using the API, what parameters are
you passing to the packager() function?

electron-packager ./electron \"Some App\" --platform=darwin --arch=x64 --version=0.36.8 --icon=./electron/icons.icns

What is the host platform are you running electron-packager on?

OS X 10.11

What target platform(s)/architecture(s) are you building for?

OS X, x64

Is there a stack trace in the error message you're seeing?

Uncaught Exception:
Error: Unable to find a valid app
    at Object.<anonymous> (/Users/.../Some App-darwin-x64/Some App.app/Contents/Resources/atom.asar/browser/lib/init.js:111:9)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)
    at Function.Module.runMain (module.js:457:10)
    at startup (node.js:151:18)
    at node.js:1007:3

Please provide either a failing testcase or detailed steps to reproduce your problem.

Oh think that's a duplicate of https://github.com/maxogden/electron-packager/issues/264. I don't have a package.json in my ./electron dir.


V5 Beta 3 - Floating labels bad overflow

Floating labels are buggy in Bootstrap 5 Beta 3:
The textarea content is overlapping the label, please refer to the attached screenshot from the official Bootstrap 5 documentation page:

Searched again for that issue and found the following: https://github.com/twbs/bootstrap/issues/32800 - Should be it, already known since 14. January

Closing as a dupe


feat: add hover effect and proper spacing to about modal

add hover effect and proper spacing to about modal
https://user-images.githubusercontent.com/69431456/145682478-d566a3e4-58cd-4ff0-a79c-e410e8e066d7.mov

/cc @samuveth @bonustrack


CLI config option stomps on --output param

The docs suggest that CLI options override config options but when I specify --config [jso].config it ignores the --output out.js which otherwise works fine.  Then it just spews all the obfuscated code to the console. If I omit the --config option that output is properly written to the spec'd file.
Running on Centos Linux.  Using this:
~/node_modules/javascript-obfuscator/bin/javascript-obfuscator in-src.js --config low-ob-high-perf.config --output out.js
The config file low-ob-high-perf.config is just a cut-n-paste of the suggested options from here under Preset Options:
https://github.com/javascript-obfuscator/javascript-obfuscator
Note: it might be useful to add a CLI param --perf-level [low|med|hi] or something like that with the preset options.
Thanks.

You should use js or json extension for the config file. I don't know why it works with the production bundle, it doesn't work with my dev bundle. Will add a check for the valid extensions.

Thanks for fast response!
I tried the .js extension for the config and it still spews to the console. Just for grins I tried omitting the --output out.js hoping it would write to in-obfuscated.js but it still spews to the console.  So appears any config causes it to output to STDOUT. Curious.
But ya know, it looks like the default options pretty much give me the low-obfuscation-high-performance settings so I'm going to just go with no config.  Thanks.
Dennis

Show me content of your config file with JS extension

Just cribbing from here: https://github.com/javascript-obfuscator/javascript-obfuscator
For example, my low-ob-high-perf.js file contains:
{
    compact: true,
    controlFlowFlattening: false,
    deadCodeInjection: false,
    debugProtection: false,
    debugProtectionInterval: false,
    disableConsoleOutput: true,
    identifierNamesGenerator: 'hexadecimal',
    log: false,
    renameGlobals: false,
    rotateStringArray: true,
    selfDefending: true,
    shuffleStringArray: true,
    splitStrings: false,
    stringArray: true,
    stringArrayEncoding: false,
    stringArrayThreshold: 0.75,
    unicodeEscapeSequence: false
}

Running: node: 14.5.0
Like I said this is non-critical as I think I've determined the default options pretty much set up for low-obfuscation high-perf.

This not a valid exproted config. With THIS content of file, rename it to json file, or keep is as js file but export object with config with module.exports

Additional check released as 1.3.0

Ah ha, that config needs to be valid JSON.  Didn't even think about it, just cut-n-paste from that page.
Making it valid JSON and using .json suffix makes it work.  Otherwise the big source barf up is not my source, it's apparently the obfuscator source.
And the stack trace is:
ReferenceError: Given config path must be a valid `.js` or `.json` file path
    at Function.getUserConfig (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:431466)
    at Function.buildOptions (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:420605)
    at F.initialize (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:420961)
    at F.value (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:11871)
    at F.value (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:11871)
    at F.value (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:11871)
    at F.value (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:11871)
    at F.value (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:11871)
    at Function.obfuscate (/home/denny/node_modules/javascript-obfuscator/dist/index.cli.js:24:429390)
    at Object.<anonymous> (/home/denny/node_modules/javascript-obfuscator/bin/javascript-obfuscator:3:30)

If the input .js is not valid, same dealie, big source barf up to stderr.
It's working now but it would be cool if instead the program said:
Error: invalid Javascript input file
or:
Error: config file is not valid JSON with .json suffix
Or something like that.  Anyhow, thanks for your help.
Dennis


Include the outcome in a re-proposal instead of re-executing.

Motivation
It must always be possible to re-propose the locked block, even if the committee that certified a blob which the new block reads has been deprecated in the meantime. This would currently fail, in theory, because the validator tries to execute the proposal even if it includes a validated block certificate, and during execution it doesn't have access to the included blobs.
Proposal
Include the whole execution outcome in the proposal and don't re-execute it.
Test Plan
CI should catch any regressions.
The bug itself can't actually be triggered due to https://github.com/linera-io/linera-protocol/issues/2351: The validator would wrongly accept the deprecated blob.
Release Plan

Nothing to do / These changes follow the usual release cycle.

Links

Fixes https://github.com/linera-io/linera-protocol/issues/2993.
reviewer checklist

It is sent along with the proposal, and we check that, and then store it in the chain manager. So an alternative to this PR would be to add a new kind of temporary storage for those blobs and make them available during execution.


Styling for BookListing

          <CardText expandable>
            {book.publisher ? `Publisher: ${book.publisher}` : null}
            <br />
            {book.publishedDate ? `Published Date: ${book.publishedDate}` : null}
            {book.description}
          </CardText>
        </Card>


[now-static-build][now-build-utils] Add python static generators

This adds support for running detecting requirements.txt and running pip install -r requirements.txt so that Python static generators can be used.
In particular, the two most popular have been added as test fixtures:

Pelican
MkDocs

Codecov Report

Merging #3048 into canary will decrease coverage by 2.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           canary    #3048      +/-   ##
==========================================
- Coverage   13.46%   11.33%   -2.14%
==========================================
  Files         267      267
  Lines       10296    10034     -262
  Branches     1211     1308      +97
==========================================
- Hits         1386     1137     -249
+ Misses       8848     8805      -43
- Partials       62       92      +30

Impacted Files
Coverage Δ

src/util/output/create-output.ts
31.25% <0%> (-12.34%)
:arrow_down:

src/util/dev/server.ts
60.69% <0%> (-5.74%)
:arrow_down:

src/util/prefer-v2-deployment.ts
56.25% <0%> (-5.66%)
:arrow_down:

src/util/dev/yarn-installer.ts
85.71% <0%> (-5.03%)
:arrow_down:

src/util/dev/builder.ts
73.07% <0%> (-4.35%)
:arrow_down:

src/util/dev/router.ts
78.57% <0%> (-4.13%)
:arrow_down:

src/util/get-files.ts
87.77% <0%> (-3.89%)
:arrow_down:

src/util/projects/get-project-by-id-or-name.ts
25% <0%> (-3.58%)
:arrow_down:

src/util/dev/builder-cache.ts
77.27% <0%> (-3.48%)
:arrow_down:

src/util/metrics.ts
70.58% <0%> (+2.4%)
:arrow_up:

Continue to review full report at Codecov.

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


Events annotated by #[dojo::event] are not annotated as event in ABI

Describe the bug
Sozo events subcommand uses the ABI to parse the events, but since custom dojo events are not annotated sozo currently cannot parse them.
Once this issue is fixed we need to update sozo accordingly so it can parse those events. Also note in dojo events we add the system address which emitted it as the key in event ourself, that also needs to be considered.

To solve this, we should add a "phantom" method on models that are dojo::event to ensure we have a way to determine that from the ABI.

Events are now emitted differently than before, with their own ABI file, and they are not starknet event anymore. 👍


Accepting rp trees with no splits

The code now accepts trees with no splits (previously an exception was raised) and computes the dimension of the hyperplane directly (from data.shape[1]) - as discussed in #178

Locally, the tests now pass (Windows 10, python 3.7) (after the commit a851071 - before that, even 1D test haven't passed).  Looking into it ...

Just found out that if all data are updated, the code does not work. Of course, this is not the intended usecase, but will try to fix this anyway.

Unintended corner use cases are always an issue. Good job on managing to catch this one early.


Unable to find a specification for SwipeMenuViewController

platform :ios, '8.0'
target 'testSwift' do
use_frameworks!
pod 'SwipeMenuViewController'
end

pod install
Unable to find a specification for SwipeMenuViewController

Same here, Unable to find specification for SwipeMenuViewController (using Objective-C)

Please, try this.
$ pod repo remove master
$ pod setup
$ pod install

with reference to https://stackoverflow.com/questions/25913733/unable-to-find-a-specification-in-cocoapods

It worked. Thank you