GUACAMOLE-1572: Match environment variables for POSTGRESQL auth plugin doesn't match guacamole.properties variable name

Fix issue described in https://issues.apache.org/jira/browse/GUACAMOLE-1572 where environment variables for POSTGRESQL auth plugin doesn't match guacamole.properties variable name

I also remarked the user variable for both 3 auth modules is named user in environment variables and username in guacamole.properties, should be updated too.
I'll update the documentation when we're ok on all changes here.
No sure if it fits in 1.5.0 or not but in case of I've set upstream on 1.5.0.

@jbpaux  This should be against master, it will not go into the 1.5.0 release.

If you have time to have a look at it @necouchman (and my question about the username environment variable too) ;)

Overall I think it looks okay to me. @mike-jumper any additional concerns?


full screen video

how to make a video full screen?
currently, it resizes based on video size

solved
.contentMode(.scaleAspectFill)


Make the @yamada-ui/button component headless

script: make-component-headless
package: @yamada-ui/button
Description
Currently, the @yamada-ui/button component has minimal styles set within the component's source code.
We want to make this style transferable to the theme and make the component headless, enabling more flexible UI customization.
Problem Statement/Justification
By making the @yamada-ui/button component headless, we can achieve more flexible styling tailored to the project.
Proposed Solution or API
The styles within the component are mostly defined by css: CSSUIObject and set to a prop named __css. We will transfer these styles to the packages/theme/src/components.
The code below is just an example and not the actual code.
packages/components/input/src/input-group.tsx
const css: CSSUIObject = {
- width: "100%",
- display: "flex",
- position: "relative",
  ...styles.container,
}

packages/theme/src/components/input.ts
baseStyle: {
  container: {
+   width: "100%",
+   display: "flex",
+   position: "relative",
  },
  field: {
    width: "100%",
    minWidth: 0,
    outline: 0,
    position: "relative",
    appearance: "none",
    transitionProperty: "common",
    transitionDuration: "normal",
    _disabled: {
      opacity: 0.4,
      cursor: "not-allowed",
    },
  },
  element: {
    color: ["blackAlpha.600", "whiteAlpha.700"],
  },
},

[!TIP]
In cases where the styles within the component are dynamically changed, there may be instances where it is not possible to transfer the styles to the theme.
In such cases, it needs to be discussed in this issue. Please feel free to send comments to this issue.

Additional Information
The @yamada-ui/button component exists in packages/components/button/src. You need to check all the components in this folder and if they contain styles internally, you need to modify them.
This change could have a significant impact on projects using Yamada UI, so we will work on it within the scope of v2.0.
Please create the branch for working on this issue from the remote branch v2.0, and direct your pull requests to the v2.0 branch as well.
Please select major for the changeset and create a pull request.

Hi @hirotomoyamada, can I work on this one?

@rikuya98
Hi, thanks for the comment!
Yes, pls!

Fixed #1990


Drop Flask 1.x support

Is there an explicit reason this was done @greyli ?

My team works on a large codebase that is slowly porting to Flask 2, but were thinking of using this library.

I want to match the Flask version (APIFlask 2 - Flask 2). You could pin APIFlask <2 if you are using Flask 1.x.


add onSessionGracePeriodElapsed to SessionBackingOff, SessionConnecting, and SessionHandshaking

Why

session should track its grace period even as it transitions between various non-connected states
otherwise, we end up in scenarios where the reconnect loop will prevent the session grace from kicking in until the retry budget is exhausted

What changed

add onSessionGracePeriodElapsed to intermediate states
add many many tests for behavior of session grace between states

Versioning

[ ] Breaking protocol change
[ ] Breaking ts/js API change

todo:

figure out if we should keep the set the session disconnect grace to 0 to force a hard reconnect behaviour or if we should make an explicit session option for this
add a test for ensuring that session grace is elapsed even in a retry loop


Implement buildx bake for build orchestration

The CI workflows for this repository have grown significantly in complexity since they were created to the point where some modifications (ex. modifying base images) have become unwieldy or downright impossible for external contributors. @costrouc recently did some prototyping work around using docker buildx bake for orchestrating simultaneous builds. I did some further investigation and found that bake can also significantly simplify our testing implementation. Implementing bake should help us resolve a lot of the complexity and confusion around image build dependencies and testing.
https://docs.docker.com/build/bake/

This implements #714


Fix unit tests

@yuyiguo , here is patch of DBS client unit tests as well as some improvements to the DBS client. All of these changes I used to be able to run python client unittest suit to test dbs2go implementation.

@yuyiguo did you have time to review this PR? I'm using it for dbs2go tests and it allows to use different DBS URLs in unit tests.

Valentin,
Can we hold this if you already ran the unit tests against das2go?

sure, I only pinged since there were no replies from you on this PR.


IDiffEditorConstructionOptions.renderSideBySide is not honored

On the latest Insiders, or OSS

Run a test that produces a diff output, e.g. with assert.deepStrictEquals('foo', 'bar')
Notice the diff editor for testing, where renderSideBySide: true, does not actually get rendered side by side

Seems to have been caused by https://github.com/microsoft/vscode/commit/4ae1914ef14d7e17c15ebcf18bfe0aad6d295fe8
Can this this perhaps be some enum for Never / Auto / Always?

you can set useInlineViewWhenSpaceIsLimited to false in the construction options.

Can this this perhaps be some enum like Never / Auto / Always?

Lets track that here:

#190150


Add support for TLS certificate packs

Adds coverage for dedicated, custom dedicated and advanced certificate
manager resources.
Screenshot

Depends on cloudflare/cloudflare-go#522 for the CertificatePackAdvancedCertificate.ID field.

This is great! I was literally just looking to see if this was supported yesterday. 🎉


Sidebar not optional

The new side bar takes space off the app and make it look cluttered. At least we should have the option of hide the side bar in the window menu.

this should be fixed in the latest update. Let me know if this still happens, but I can not reproduce anymore!


Corrigido pg.NONE

Coverage remained the same at 60.22% when pulling c9ceea6186a3fc1f653fa735885661bc9f1b44e2 on vonpupp:patch-1 into 78968785e9a8b4c901d42fd2d62e2f1ad819bed1 on rochacbruno:master.

Obrigado @vonpupp :sunglasses:

magina :+1:


Maintenance v4.0.44-2

The 4.0.44-2 bugfix maintenance branch was never merged to master...

@ahmad-shahid CI failed because of issue #411, but the unit tests passed. can be merge if you want.

Yup sounds good, I'll merge it now.


Config: Add check for duplicate parameters

@blhoward2 We can't do this - at least not easily.
https://github.com/json5/json5/pull/217
One other way would be to use the JSON schema to validate the files, but that won't pick up duplicate keys in templates.

Why not just build a Set of the parameter numbers since they have to be unqiue, then compare the size to the number of parameters? If it is less there is a duplicate value somewhere? That wouldn't identify which is the duplicate but you could at least display an error message and fail.

The thing is, after JSON5.parse we don't see the duplicate. I could change it so the comments get stripped and the file parsed with the built-in JSON class, which would throw on duplicates.

Ah, yeah I was thinking about after it's already in memory. I'm not sure it's a huge deal.

Should be easy enough to do with a regex 🤷🏻♂

I wouldn't worry about it. I can just not make mistakes, lol. Hopefully the templating would cut down on it too.


Added support for detecting new sessions

I've added some simple code to detect if the user is at the beginning of a new session. This allows me, as a web developer, to use the "amplitude.isNewSession()" function to trigger certain tracking behavior only at the beginning of a session.
The use case I'm solving here is capturing utm_* parameters only once (avoiding a back-button problem), tracking referrers, and generally attaching anything we need to in a "Started Session" event -- a key building-block for web application event tracking.

If I'm understanding this correctly, isNewSession will be true for all calls to it on the first page load for a given session, and will turn false after navigating to a new page in the same session. Is that the desired behavior?

Yes. That's the desired behavior (for us, and, if imagine, for most web clients).
It allows us to do things like process incoming utm_ URL query parameters only once (without worrying about the back button) and record referrer for all new sessions.
Does that make sense?
—
Sent from Mailbox
On Sun, Feb 22, 2015 at 9:43 PM, Curtis Liu<EMAIL_ADDRESS>wrote:

If I'm understanding this correctly, isNewSession will be true for all calls to it on the first page load for a given session, and will turn false after navigating to a new page in the same session. Is that the desired behavior?
Reply to this email directly or view it on GitHub:
https://github.com/amplitude/Amplitude-Javascript/pull/4#issuecomment-75492222

@curtisliu - any feedback on this? I'd like to use this in our instrumentation if accepted.

@kfreytag sorry for the delay. this looks good to me, thanks!

thanks @curtisliu!
How often do you do a release?

We do releases fairly soon after updates to the SDK. Should have one out with these changes by the end of the week!

Great news. Thanks, Curtis.
Kurt Freytag
Head of Product
CrunchBase - The Business Graph
c:<PHONE_NUMBER>
f:<PHONE_NUMBER>
On Wed, Feb 25, 2015 at 12:56 PM, Curtis Liu<EMAIL_ADDRESS>wrote:

We do releases fairly soon after updates to the SDK. Should have one out with these changes by the end of the week!
Reply to this email directly or view it on GitHub:
https://github.com/amplitude/Amplitude-Javascript/pull/4#issuecomment-76054920


Errors on connections with 0.128.0

Describe the bug
It appears the new organization tables (https://hub.steampipe.io/plugins/turbot/aws/tables/aws_organizations_organizational_unit) cause ERRORS getting thrown on connection startup and will error out AWS connections.  Reverting back to 0.127.0 doesnt have this issue.
Steampipe version (steampipe -v)
Example: v0.21.3
Plugin version (steampipe plugin list)
Example: v0.128.0
To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).
2024-01-19 16:33:31.663 UTC [INFO]  hub: goFdwAbortCallback
2024-01-19 16:33:31.663 UTC [INFO]  hub: Hub Abort
2024-01-19 16:33:31.667 UTC [591107] LOG:  connection received: host=<IP_ADDRESS> port=58738
2024-01-19 16:33:31.681 UTC [591107] LOG:  connection authorized: user=root database=steampipe application_name=steampipe_service_8d89 SSL enabled (protocol=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256)
2024-01-19 16:33:32.307 UTC [591027] ERROR:  syntax error at or near "USER" at character 126
2024-01-19 16:33:32.307 UTC [591027] QUERY:  CREATE FOREIGN TABLE "aws_gda_network".aws_organizations_organizational_unit (name text,id text,arn text,parent_id text,path USER-DEFINED,title text,akas jsonb,partition text,region text,account_id text,_ctx jsonb) SERVER steampipe OPTIONS (table 'aws_organizations_organizational_unit')
2024-01-19 16:33:32.307 UTC [591027] CONTEXT:  PL/pgSQL function clone_foreign_schema(text,text,text) line 56 at EXECUTE
2024-01-19 16:33:32.307 UTC [591027] STATEMENT:  select clone_foreign_schema('aws_tndr_prod', 'aws_gda_network', 'hub.steampipe.io/plugins/turbot/aws@0.128.0');

Expected behavior
Connections starting in a ready state instead of error

Hello @tinder-tder, I'm sorry to hear you're encountering issues. I've noticed that after installing the AWS plugin version v0.128.0 and using it with Steampipe CLI version v0.21.2, there were no errors in building the schema. However, upon switching to Steampipe CLI version v0.21.3, I encountered the error mentioned in the issue description.
2024-01-19 15:27:54.391 UTC [21684] ERROR:  syntax error at or near "USER" at character 121
2024-01-19 15:27:54.391 UTC [21684] QUERY:  CREATE FOREIGN TABLE "aws_nagraj".aws_organizations_organizational_unit (name text,id text,arn text,parent_id text,path USER-DEFINED,title text,akas jsonb,partition text,region text,account_id text,_ctx jsonb) SERVER steampipe OPTIONS (table 'aws_organizations_organizational_unit')
2024-01-19 15:27:54.391 UTC [21684] CONTEXT:  PL/pgSQL function clone_foreign_schema(text,text,text) line 56 at EXECUTE

It seems possible that the error we're encountering is related to the column type LTREE. Despite the error, I'm still able to query the table_aws_organizations_organizational_unit. I plan to discuss this with the team to see if we can address or suppress this error. Thank you for your patience!


Support shortcut for starting manimgl interactively based on current line

Such a command (with an assignable shortcut) could do the following
Steps

Launch a new terminal in a floating window
Execute manimgl with params based on the which line the cursor is in, that is

Find out in which file the cursor is (probably easy), e.g. path/to/file.py based on the current directory where VSCode is open
Find out in which python class the cursor is (probably a lot trickier, maybe pylance provides kind of an API for this?), e.g. SceneName
Find out the current line number (probably easy), e.g. 42
Pass everything as mangiml path/to/file.py SceneName -se 42

Additional

Before doing all of this, check if there isn't already a terminal open. If there is none open, do the steps above.
If there is already a terminal open: somehow check if manimgl was already launched in interactive mode (in any of the open terminals).

If yes: is there a way to restart it on a new line number? For this case, it is maybe easier to just kill the active session and open a new one. However, this would have the disadvantage that the window position of the OpenGL popup is lost.
If no: just start it as described above.
Special case: what if multiple terminals run manimgl? Should probably report an error in this case.

implemented here

Argh, I would really like to have this functionality as part of the extension before I publish this extension's awesome recent developments (thanks you both!) to the marketplace. However, after doing some research the CC-BY-NC-SA license is not compatible with the MIT license I am currently using. We have two options:

We can implement our own logic from scratch, without inspiration from the original implementation. Or,
We can update the extension's license to CC-BY-NC-SA

I believe this is a very important feature to have as part of the extension. Let me know your thoughts

Hi!
Really awesome contributions from @Splines !
I believe Grand has allowed to use the workflow itself without the CC license.

Yes, I'll do that in 1 h

This was closed by #17


[mini.files] Folder picker

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md

Module(s)
mini.files
Description
Would be awesome to have an folder picker with fuzzy to open mini.files direct in this folder.
The ideal is to open this folder expanded by cwd (or have an option to do that)

Thanks for suggestion!
This is out of scope for 'mini.files'. It provides open() function which can be used inside any picker of your choice.
Closing as not planned.

You can use telescope-file-browser and make it's default action to open mini.files.


[macOS/iOS export] Add option to set custom Info.plist data.

Fixes https://github.com/godotengine/godot-proposals/issues/8848

It should probably mention what format is expected (maybe simply linking to the relevant Apple docs).

Added link to the Apple docs, and example.

How does it behave on export if the user puts invalid data / syntax errors? Do we export gracefully and then the .app would fail running? Is the error then clear enough?

How does it behave on export if the user puts invalid data / syntax errors? Do we export gracefully and then the .app would fail running?

If it's completely invalid data, the app will run, but won't show info or have an icon. If it's valid fomatting but unknown keys/values, it will be ignored.

we could likely check that XMLParser is happy with the syntax at least.

It won't be enough, valid XML data is not necessarily valid part of <dict> element. Proper validation should check if it's matching http://www.apple.com/DTDs/PropertyList-1.0.dtd schema, but I do not think we have any code for this, and it probably is not worth adding for such minor feature.

It won't be enough

You're right that it won't be enough to ensure it's a valid addition. But hopefully checking that it's valid xml should at least ensure the additions are correctly closed tags so the addition doesn't risk messing up the parsing of the entire Info.plist. If we can be reasonably sure about that it's a lesser problem if the content in the addition is just ignored if it's formatted incorrectly.

Yeah if it doesn't add significant complexity to the code, I think just validating that the syntax is valid XML would be enough.

We actually have a dedicated PList parser for ad-hoc code signing (which can give more verbose error output than XMLParser), so I guess it probably better to use it.

Added validation using PList parser from ad-hoc code signer, most likely it won't catch every error, since it's not designed to for validation, but should reject completely invalid data.

Thanks!


Recommendations on missing/unknown/not recorded data in Darwin Core

This issue is inspired by Robert Mesibov's post in GBIF discourse - The vexed question of missing data in Darwin Core.
The discussions on the thread and Arctos are very insightful. (Thank you!)
In the post, Bob mentioned:

The Darwin Core recommendations don’t provide a lot of guidance. The entry “unknown” is recommended when footprintSRS, geodeticDatum, verticalDatum or verbatimSRS isn’t known. On the other hand, the recommendation for coordinateUncertaintyInMeters is Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates).

Take the term geodeticDatum for example. unknown and not recorded are recommended in different sources.
From Darwin Core Quick Reference Guide

Recommended best practice  is to use the EPSG code of the SRS, if known. Otherwise use a controlled  vocabulary for the name or code of the geodetic datum, if known.  Otherwise use a controlled vocabulary for the name or code of the  ellipsoid, if known. If none of these is known, use the value unknown.

From Georeferencing Best Practices

It is thus recommended to record the EPSG code of the coordinate reference system if possible, otherwise, record the EPSG code of the datum if possible, otherwise, record the EPSG code of the ellipsoid. If none of these can be determined from the coordinate source, record "not recorded"

Subsequently these recommendations affect downstream implementation such as:

https://github.com/tdwg/bdq/issues/60
https://github.com/gbif/occurrence/issues/84

Hence I would appreciate if there will be a general guidelines on how to treat different scenario of NITS (Nothing Interesting To Say) in Darwin Core. I appreciate Bob's suggestion on how to treat missing data in his post:

Here’s a possible answer to the “What to do with missing data?” question, and it’s one I regularly propose to the compilers whose Darwin Core data tables I audit: If a data item is missing, leave it blank. If you have a reason for the "missingness’, put it in a …Remarks field.

Thanks a lot!

In the context of transcribing labels from specimens we also made a recommendation to break down unknown into...

unknown
unknown:undigitized
unknown:missing
unknown:indecipherable
known:withheld

Quentin Groom, Mathias Dillen, Helen Hardy, Sarah Phillips, Luc Willemse, Zhengzhe Wu, Improved standardization of transcribed digital specimen data, Database, Volume 2019, 2019, baz129, https://doi.org/10.1093/database/baz129

Here's a good summary from Data Carpentry about missing values as blanks:
https://datacarpentry.org/spreadsheet-ecology-lesson/02-common-mistakes/#null

This issue has been translated into an actionable change request for geodeticDatum. Other than examples or comments on specific terms, Darwin Core does not provide generalized guidelines that might cross standards. Such documentation thus far has been promulgated by the Technical Architecture Group (for an example, see Best practices for serializing booleans). If there are other specific terms for which changes are needed, please submit Term change requests for each of them.


--dryrun should accept values or have a variant that does accept values

As documented, --dryrun expects no arguments. However, it would be useful if it also would.
Often one ends up wrapping robot command into a script of somekind. In these cases, one would want enable the user of the script to pass along arguments to robot.
Easy way to do this would be something like this:

import sys

def run_robot(**rf_args):
    # do some other stuff
    rf_args = ' '.join(f'--{arg_name}="{arg_value}"' for arg_name, arg_value in rf_args.items())
    run_command_line(f'robot --log NONE --report NONE {rf_args} my_suite/')

if __name__ == '__main__':
    run_robot(variablefile='some.file', include='mytag')

However, one is unable to support --dryrun this way, as one cannot write something like: run_robot(dryrun='yes')
Alternatively, --dotted and --quiet have alternative way to set them with --console="dotted" and --console="quiet", so similar would work as well

In my opinion you should accept dryrun=True and handle that in your code. It ought to be very easy.
I don't think rhe command line option handling could support both robot --dryrun tests and robot --dryrun true tests, because the latter cannot be differentiated from robot --dryrun tests more_tests which is also valid.
Adding a separate option that accepts a value would work, but I don't think it's worth the effort or added complexity.

def format_arg(name, value):
    if value is True:
        return f'--{name}'
    if value is False:
        return f'--no{name}'
    return f'--{name}={value}

rf_args = ' '.join(format_arg(name, value) for name, value in rf_args.items())

The above is untested, but ought to handle both dryrun=True and also statusrc=False.

Notice also that Robot itself has robor.run() that you could possibly use directly like robot.run('tests.robot, dryrun=True)`.

Yes, this is definitely a very minor thing as it is quite easy to handle yourself. I just found it surprising that --dryrun and --statusrc work this way apart from other arguments.
Given there is no value, I'll close this issue. Thanks for insight!


U3D - BabylonJS Editor Toolkit

U3D - BabylonJS Editor Toolkit - Initial Release

Hey Delta... Please do not change any folder or filenames. I have an update system built into the toolkit. Filenames are hardcoded in Unity C# Toolkit.
Thanks :)

as an open source project you need to provide all tools required to build the unity package

I mean as a contributor, if I change a .cs file, what should I do to update the package?

Nothing... the .cs files are RAW unity source script files... they are compiled in unity ... Just like the original unity exporter.

Thats why is under the main Unity 'Assets/Babylon' folder

but do tou have a script or a gulp taks to build the package?

how to build the package in redist folder?

There is nothing to build outside of unity itself. The package in the reset folder a standard unity package. You dont 'BUILD' it... The files in the Assets/Babylon folder are standard unity assets as well... You dont build anything outside of unity.
This is the same thing as the current Unity3D2Babylon exporter... I just added ALOT of code to the existing unity scripts (plus added a few new ones). But its all pretty standard unity stuff.

Just to clarify... You dont build unity script files outside of the unity editor. The Assets folder contains the raw project files... You would manually COPY that folder to your unity project (Just like you would with the original exporter). The preferred unity way is to use unity packages (basically the assets foles in a zip file... Then unity will proper install all the packge assets... Either by Import Package command or by store in your asset store folder and you CHOOSE BabylonJS Edit Toolkit as a packe to inlcude in creating a new project... It all prety standard unity stuff)

yep I get that but I was wondering how yo build the unitypackage. so if I want to update the one in redist, I just need to zip the assets folder correct?

Inside unity... to build ANY package your just RIGHT-CLICK Any content your want... scripts, models, textures, materials... ANYTHING... And you say "Export Package"...
This is way ALL packages on the asset store are created... from a source project.
Its really kool.. because WE can now use the packaging feature to package up AND ENTIRE babylonJS game... With all the assets and scripts and textures and EVERYTHING... and simple pass that package to our dev team members... the just open unity and do a "Import Package" and they will have the whole project... OR WHATEVER PARTS you select to export.

huge... I'll merge tomorrow

K

Yeah... It does ALOT now... Complete U3D Style BabylonJS Game Development is wrapped in there :)

Now the next step is documentation. We have a separate repo for it:
https://github.com/BabylonJS/Documentation
and more precisely: https://github.com/BabylonJS/Documentation/blob/master/content/exporters/Unity/Unity.md
You can edit it in the website or using this guide:http://www.html5gamedevs.com/topic/16365-contributing-to-documentation-101/


TypeError: Cannot read properties of undefined (reading 'params')

Describe the bug
plugins: ["collapseGroups", , ] crashes with a TypeError
ib/svgo/plugins.js:21
    const params = { ...plugin.params, ...globalOverrides, ...override };
                               ^

TypeError: Cannot read properties of undefined (reading 'params')
    at invokePlugins (/home/me/monorepo/node_modules/svgo/lib/svgo/plugins.js:21:32)

Desktop (please complete the following information):

SVGO Version 3.0.2
NodeJs Version 18.0.0

Wops, my mistake. ["collapseGroups", ,] breaks.

Would you be able to provide a full config?
I'm unable to reproduce this with the information in the issue.

When plugins are null, plugin.params was empty and acessing params property fails. I believe the bug is still there looking at https://github.com/svg/svgo/blob/main/lib/svgo/plugins.js#L21

When plugins are null

I'm testing this on both v3.0.2, and main (b15da27af4832bbe9efbec2bef03eff0c0ed110d), with Node 14, 16, 18 (latest), and 18.0.0 as reported in the initial issue.
Doesn't occur for me when plugins is null.

    const params = { ...plugin.params, ...globalOverrides, ...override };

I don't see an immediate issue with this code. It only iterates when plugins are defined anyway, and when there is a plugin without params, destructuring null or undefined is valid in Node.js.
However, I see the problem. You probably had a weird configuration.
module.exports = {
  plugins: [
    null
  ]
}

I can reproduce it with this, which is an invalid/unsupported configuration. The plugins property can be set to null, but this tries to add a null plugin` in the array.
To avoid issues in future, I'll add a warning whenever this happens and ignore it.

I'm sorry but the bug states perfectly like the following: plugins: ["collapseGroups", , ] causes a TypeError. It's a common pattern in JS to filter an array and it produce an array of 3 items but 2 of the are empty.

the bug states perfectly like the following: plugins: ["collapseGroups", , ]

Ahh, you're right. Honestly, I didn't know this syntax could be used outside destructuring an array, so I thought it was a typo. I should've tested it as-is.
Thanks for clarifying this for me.


Allow "(" in unescape macros

So I finally figured out an example that is simple enough to demonstrate
Here is a minimal dashboard with problem I am dealing with:
{
  "panels": [
    {
      "datasource": "clickhouse",
      "id": 2,
      "targets": [
        {
          "format": "table",
          "query": "SELECT\n  $unescape($f) AS b\nFROM (\n  SELECT * FROM system.numbers LIMIT 1\n)"
        }
      ],
      "type": "singlestat"
    }
  ],
  "templating": {
    "list": [
      {
        "current": {
          "text": "count",
          "value": "count()"
        },
        "multi": true,
        "name": "f",
        "options": [
          {
            "selected": true,
            "text": "count",
            "value": "count()"
          },
          {
            "selected": false,
            "text": "sum",
            "value": "sum(number)"
          },
          {
            "selected": false,
            "text": "other",
            "value": "concat('a', toString(number))"
          }
        ],
        "type": "custom"
      }
    ]
  },
  "title": "New dashboard"
}

Looks like a problem
In this case macros will add additional ) after function call and it also will replace '' symbols in the variable (see other option)
Originally posted by @podshumok in https://github.com/Vertamedia/clickhouse-grafana/issues/49#issuecomment-440370421

Hi @podshumok
Yep, looks like a bug

https://github.com/Vertamedia/clickhouse-grafana/releases/tag/1.8.1


The Grammar pages do not mention the implicit setting of $/.

The problem
The Grammar pages do not mention the implicit setting of $/.
Suggestions
This wording should be added somewhere in the routine sections for parse and subparse:
"This routine, like m//, implicitly sets $/".

Yes, besides, we now have two page about Grammars, that is "Grammars" and "Grammars Tutorials".

Not sure that would go to the Grammar pages. Either $/ gets a page by
itself, or to regexes...

I was planning on adding this to the routine descriptions for parse and subparse.

It's OK it's mentioned there, but $/ is also set by regexes.


Kismatic fails with non-useful error when SSH key has wrong permissions

I have run into various SSH-related issues during the validation phase, and the error message returned by kismatic is just "UNREACHABLE".
This makes me think that the node is unreachable on the network. My first instinct is to ping the machines, and once that passes I am out of ideas.
After some investigation, I found that the issue was related to the SSH key having wrong permissions.

Yes I agree this is frustrating; I've run in to it myself on a few occasions. At the moment we're relying on Ansible to deliver this error message and it has a tendency to treat a whole host of SSH problems as "unreachable," with the real reason hidden in a stream of verbose logging.
And to be fair, there are lots of reasons why SSH can fail, but we could probably identify some of the top culprits (bad key negotiation, wrong host, username rejected). What was your actual SSH issue?
If you don't mind, could you give me a quick walk through of how you discovered the problem? I would love to help improve the debug process as well.

The error in this case was due to wrong permissions on the ssh key file (permissions were too broad).
The troubleshooting steps I took were:

Ping the machines (success)
Reading the documentation, it does claim that SSH errors will result in an unreachable error so I tried to log in to one of the nodes from the machine running the installer using the key and that's when I saw the actual error of the permissions.


C++ support

User platform support for C++-based services.

WIP: working on it with a collaborator having idiomatic C++ support.
Nothing to show actively show yet until the TCK gets passed and having documentation. Mentioning here if others want to join.

Awesome @marcellanz


Unauthenticated user can skip tracks

If I'm not logged in, I can skip tracks.

Correction - if I WAS logged in, but the app restarts (for example, maybe other cases where I get disconnected or lose my cookie somehow), I can skip songs but not do anything else.  The Skip button is active and seems to work OK in this case.  If I reload the page and I'm not logged in, it disables as expected.

ok, I understand what's happening her. and I'm torn on whether or not to fix it. It will only be available if you were logged in as an admin this session. that means its not exposing to other users, only those who were once signed in as admins since the last kick.
I'm kind of ok with this, since that means admins can skip even if the sockets lose their mind

I would rather fix the issue of socket disconnects, so I'm going to abandon this one for now.


Metrically Scaled Depth Renders from Depth-Nerfacto

After training depth-nerfacto on metrically scaled depth images (in millimetres) with corresponding aligned camera poses, I would like to be able to render out depth images that are represented in the same way i.e single-channel 16-bit depth image (in millimetres) instead of a colour map. Is there a way to achieve this?

The outputs['depth'] from the model is a real float depth value, the viewer just converts it to a colormap. If you want the raw values you can save it in some other format like a numpy array


apm command not found

What is the problem. Be specific.
The APM command cannot be found for listing and installing packages. Seems like a lack of environment present in the child_process being exec'd.
Any context someone looking into this issue should know?
Provide info on any attempts (with links to PRs) to resolve this issue.

Commit 38abf89 fixed this issue. Just needed to also specify the user's shell in the exec options.

Turns out, this is only fixed when Atom is launched from the command line. When not launched from the command line the path doesn't include /usr/local/bin which is where the apm command gets put on OS X.

On Windows 8.1 the following doesn't work:
exec(${PATH} ${command} .........
Patch provided
0001-issue1-fixing.txt


HDDS-2200 : Recon does not handle the NULL snapshot from OM DB cleanly.

Fix NULL OM snapshot handling in Recon.
Bootstrap Recon startup with last known OM snapshot DB and Recon container DB.
Add more useful log lines.

cc @vivekratnavel / @shwetayakkali / @swagle

/label ozone

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
82
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 5 new or modified test files.

_ trunk Compile Tests _

-1
mvninstall
48
hadoop-hdds in trunk failed.

-1
mvninstall
41
hadoop-ozone in trunk failed.

-1
compile
19
hadoop-hdds in trunk failed.

-1
compile
13
hadoop-ozone in trunk failed.

+1
checkstyle
60
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
958
branch has no errors when building and testing our client artifacts.

-1
javadoc
19
hadoop-hdds in trunk failed.

-1
javadoc
16
hadoop-ozone in trunk failed.

0
spotbugs
1048
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
33
hadoop-hdds in trunk failed.

-1
findbugs
17
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
31
hadoop-hdds in the patch failed.

-1
mvninstall
34
hadoop-ozone in the patch failed.

-1
compile
21
hadoop-hdds in the patch failed.

-1
compile
15
hadoop-ozone in the patch failed.

-1
javac
21
hadoop-hdds in the patch failed.

-1
javac
15
hadoop-ozone in the patch failed.

+1
checkstyle
52
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
806
patch has no errors when building and testing our client artifacts.

-1
javadoc
22
hadoop-hdds in the patch failed.

-1
javadoc
18
hadoop-ozone in the patch failed.

-1
findbugs
31
hadoop-hdds in the patch failed.

-1
findbugs
19
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
27
hadoop-hdds in the patch failed.

-1
unit
24
hadoop-ozone in the patch failed.

+1
asflicense
34
The patch does not generate ASF License warnings.

2561

Subsystem
Report/Notes

Docker
Client=19.03.2 Server=19.03.2 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1577

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 64c3bf470a41 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 685918e

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/branch-findbugs-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/testReport/

Max. process+thread count
334 (vs. ulimit of 5500)

modules
C: hadoop-ozone/recon U: hadoop-ozone/recon

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/1/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
75
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 5 new or modified test files.

_ trunk Compile Tests _

-1
mvninstall
28
hadoop-hdds in trunk failed.

-1
mvninstall
32
hadoop-ozone in trunk failed.

-1
compile
19
hadoop-hdds in trunk failed.

-1
compile
13
hadoop-ozone in trunk failed.

+1
checkstyle
46
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
920
branch has no errors when building and testing our client artifacts.

-1
javadoc
19
hadoop-hdds in trunk failed.

-1
javadoc
17
hadoop-ozone in trunk failed.

0
spotbugs
1007
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
29
hadoop-hdds in trunk failed.

-1
findbugs
17
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
31
hadoop-hdds in the patch failed.

-1
mvninstall
34
hadoop-ozone in the patch failed.

-1
compile
21
hadoop-hdds in the patch failed.

-1
compile
16
hadoop-ozone in the patch failed.

-1
javac
21
hadoop-hdds in the patch failed.

-1
javac
16
hadoop-ozone in the patch failed.

+1
checkstyle
52
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
793
patch has no errors when building and testing our client artifacts.

-1
javadoc
19
hadoop-hdds in the patch failed.

-1
javadoc
16
hadoop-ozone in the patch failed.

-1
findbugs
28
hadoop-hdds in the patch failed.

-1
findbugs
17
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
24
hadoop-hdds in the patch failed.

-1
unit
23
hadoop-ozone in the patch failed.

+1
asflicense
28
The patch does not generate ASF License warnings.

2448

Subsystem
Report/Notes

Docker
Client=19.03.2 Server=19.03.2 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1577

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 50632eedcc48 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 53ed78b

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/branch-findbugs-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/testReport/

Max. process+thread count
340 (vs. ulimit of 5500)

modules
C: hadoop-ozone/recon U: hadoop-ozone/recon

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1577/2/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

+1 LGTM

Thank you for the contribution. @vivekratnavel  Thanks for the review.


object literal types and enumerations

A literal type is a value that is also a type with only the value as member. The documentation mentions String and Number literals:
signatureName(param1: String, param2: 'value1' | 'value2' | 'value3') => -1 | 0 | 1

Object literals (e.g. {}) might be used as type, too. Unlike String and Number literals, object literals are not equal:
{} === {} // false

Therefore, object literals have to be treated different. Each object literal defines it's own type.
Example
Object literals might be used to describe an enumeration type Weekday
interface Weekday: Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday

which might be defined like this
const Monday = {};
const Tuesday = {};
const Wednesday = {};
const Thursday = {};
const Friday = {};
const Saturday = {};
const Sunday = {};

which might be used in a function isWeekend
isWeekend(Weekday) => Boolean

that might look like this
function isWeekend(day) {
  return (Saturday === day || Sunday === day);
}

Since those values belong together, they might be grouped as an object
const Weekday = {
  Monday: {},
  Tuesday: {},
  Wednesday: {},
  Thursday: {},
  Friday: {},
  Saturday: {},
  Sunday: {}
};

or similar as a module:
Weekday.js
module.exports = {
  Monday: {},
  Tuesday: {},
  Wednesday: {},
  Thursday: {},
  Friday: {},
  Saturday: {},
  Sunday: {}
};

In other languages (Java, TypeScript, etc.) this is called an enumeration (short enum). We can type this object as enum Weekday
// enum Weekday
const Weekday = {
  Monday: {},
  Tuesday: {},
  Wednesday: {},
  Thursday: {},
  Friday: {},
  Saturday: {},
  Sunday: {}
};

where enum Weekday is an abbreviation for
interface Monday
interface Tuesday
interface Wednesday
interface Thursday
interface Friday
interface Saturday
interface Sunday

interface Weekday: Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday

interface WeekdayEnum {
  Monday: Monday,
  Tuesday: Tuesday,
  Wednesday: Wednesday,
  Thursday: Thursday,
  Friday: Friday,
  Saturday: Saturday,
  Sunday: Sunday
}

resulting in
// WeekdayEnum
const Weekday = {
  Monday: {},
  Tuesday: {},
  Wednesday: {},
  Thursday: {},
  Friday: {},
  Saturday: {},
  Sunday: {}
};

Since an enumeration is a set (union) of types, we can express subsets using the same types:
interface WorkingDay: Monday | Tuesday | Wednesday | Thursday | Friday

interface WeekendDay: Saturday | Sunday

Thus, we can define Weekday as:
interface Weekday: WorkingDay | WeekendDay

your example would be better with string literals

I admit, this example is not the best, but some people prefer object literals due to easier refactoring. I like to type such code, too.

This makes a lot of things really hard.
Your effectively adding nominal typing to a structural type system. Previously all interfaces were just sugar that could be denormalized into a single structural type.

Nominal types, meaning identity or name-based types, are generally not a good fit for JavaScript because it's common to use interfaces across execution contexts (such as iFrames, web workers, etc...). Identity based type checks produce false negatives across such contexts, whereas structural type checks work fine.
Keep in mind, that rtype is intended to be usable for runtime checks, so even if there's a way to get around such issues in static analysis, such a feature would cause undesirable runtime behavior.
This:
interface Weekday: Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday

Is less reliable than this:
interface Weekday: 'Monday' | 'Tuesday' | 'Wednesday' | 'Thursday' | 'Friday' | 'Saturday' | 'Sunday'

@maiermic check http://speakingjs.com/es5/ch08.html#id1061835
It doesn't take into account symbols but it should clarify some things out for you.

You are all right. It is a bad idea.


Could the static and dynamic import syntaxes be more symmetric?

Reading through the readme, I'm confused about the syntax, as it seems inconsistent between static and dynamic imports.
import json from "./foo.json" assert { type: "json" };
import("foo.json", { assert: { type: "json" } })

Then, there's also this mentioned, but it appears to be a separate proposal (?):
import json from "./foo.json" assert { type: "json" } with { transformA: "value" };

There is no equivalent dynamic import shown, so it's unclear which of the following it would be:
import("foo.json", { assert: { type: "json" }, with: { transformA: "value" } })
import("foo.json", { assert: { type: "json" }, transformA: "value" })

My questions based on this:

Why are assert and with separate keywords in the static import case? Could assert be an option within the with options object? This seems like it would be more symmetric with the dynamic import syntax:
import json from "./foo.json" with { assert: { type: "json" }}
import("foo.json", { assert: { type: "json" } })

In the dynamic import syntax, is assert the only supported key like it appears to be for static imports? Will engines throw if other keys are added?

We're interested in using custom attributes in Parcel to indicate bundle preload/prefetch hints: https://github.com/parcel-bundler/parcel/pull/5158. Webpack currently does this via their magic comments, but we'd like a less hacky syntax and this proposal looks very promising for that.
My questions above are based on this use case. If assert is the only supported attribute at the parser level, then we likely won't be able to use it. I'm mainly wondering why it needs to be limited in this way (if it is), and why a more general proposal was rejected. Please feel free to point me to other threads if this was already discussed! 😄

What you're talking about are evaluator attributes, that can impact how a module is loaded - assertions, by spec, must not alter how a module is loaded/interpreted.

My thought was that, if we add this separate proposal for transformation, it would support dynamic import in the way you suggest, with a second option for the transformations. This all hasn't been written up yet. Would you be interested in working together on this proposal?

I guess I'm wondering why they are separate syntactically? Why is assert a keyword rather than just a property?
As I mentioned in the issue, this seems much more symmetric and extensible.
import json from "./foo.json" with { assert: { type: "json" }}
import("foo.json", { assert: { type: "json" } })

That's not entirely symmetric in that there's no "with" appearing in the dynamic form. Your first example in the OP seems the most symmetric and consistent to me, since the only difference is some curly braces and whatnot.

Sure ok, we can bikeshed all day but honestly I don't care too much about the actual syntax. I am really looking for a reason why this is two proposals rather than one. It seems to me that adding two separate more specific keywords to the language is more work/less elegant than adding a single one that's general purpose.
The point I am making is that the dynamic import syntax is extensible: you can add additional options without going through the spec process to add it to the syntax. The static import syntax is less flexible in that way, and I'm wondering whether it can be made equivalently extensible without changing the syntax each time a new option is added.

Is there anything more that you can say about the extensions you're interested in? I thought that, between assertions and with, the space would be covered. We are starting with just assertions since they are more regular and easier to understand, and we have concrete use cases for them. Additional use cases would help drive further development.

I think the preload usecase above is interesting. I guess it could fall into the with category if you think there is really a need to categorize these things syntactically (that's what I'm asking). All the examples I've seen of with made it seem like it was meant for transforms or something, and preloading/prefetching hints don't really affect that. Another example is webpack's chunk name magic comment that can be used to influence the output filename for a bundler at a dynamic import callsite. I imagine there could be more examples as well, so I was wondering whether categorizing these options separately made sense.

Does preloading affect module evaluation order?

No. It essentially injects a <link rel="preload"> or <link rel="prefetch"> element, which fetches the script but does not evaluate it. There's also <link rel="modulepreload"> which also parses the script in advance but still does not execute it until it is actually imported. We do this when the script containing the dynamic import with this attribute loads, therefore preloading these scripts before the dynamic import is actually called. It's very similar to what webpack does but with a different syntax.

Preloading, then, seems like neither an assertion nor an evaluator, but an annotation - which could be done by a comment, but could also be done by a no-op assertion. Would either of those be satisfactory?

It sounds like these preload options are neither assert nor with logically, and they only are needed for dynamic import. Is that accurate?

Correct, it doesn't seem to fit either category. With dynamic import it seems like maybe we can do this as long as extra top-level options passed to the second argument are ignored, but it's not clear from my reading whether this is the case. Given that only assert and with are allowed in the static import case, I wasn't sure whether this was also the case for dynamic imports.

I've only just come across this proposal, so I might not be qualified to make a comment here, but while going through the readme I immediately had the same thought as @devongovett. As Devon said, the dynamic import's option object is easily extendable with other properties (e.g. for sub-resource integrity, if that ever gets an in-band version):
import "./foo.mjs" with { assert: { type: "json" }, integrity: "...", referrerPolicy: "..." };
import("./foo.mjs", { assert: { type: "json" }, integrity: "...", referrerPolicy: "..." });

The non-object-literal syntax unnecessarily limits the declarative power of the static import options to a subset of the dynamic import's. In particular, hierarchical or array-like values would require brand new syntax. Developers are accustomed to a JSON-like format, and will already be using it for the dynamic import, so this seems like the most intuitive and future-proof syntax.

I think integrity fits into assertions, and preload fits into transformations. We already have an extensible key/value format; it is just sorted into whether we are talking about assertions or transformations. So I am not convinced that more generalization is needed.


[Bug]: Even when the batch size is 1, CUDA is out of memory. What should I do?

Describe the bug

I want to train a sepformer model for speech separation, path: speechbrain/recipes/LibriMix/separation/hparams/sepformer-libri2mix.yaml
I have 4 RTX3090 graphics cards, each with 24G memory, as shown below:

The training reported the following error:
RuntimeError: CUDA out of memory. Tried to allocate 212.00 MiB (GPU 0; 23.70 GiB total capacity; 21.03 GiB already allocated; 96.81 MiB free; 22.07 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF

Expected behaviour
normal training
To Reproduce
python train.py hparams/sepformer-libri2mix.yaml
Versions
No response
Relevant log output
No response
Additional context
No response

@zuowanbushiwo gradient checkpointing (https://pytorch.org/docs/stable/checkpoint.html) might help

@lucadellalib
Thank you very much, I can train normally after following your modification.

@ycemsubakan @lucadellalib   trian_loss and val_loss seems wrong？
epoch: 1, lr: 1.50e-04 - train si-snr: 1.96 - valid si-snr: 8.69e-02
epoch: 2, lr: 1.50e-04 - train si-snr: 3.85e-02 - valid si-snr: -1.75e-01
epoch: 3, lr: 1.50e-04 - train si-snr: -1.57e-01 - valid si-snr: -2.32e-01
epoch: 4, lr: 1.50e-04 - train si-snr: -2.04e-01 - valid si-snr: -2.66e-01
epoch: 5, lr: 1.50e-04 - train si-snr: -2.18e-01 - valid si-snr: -2.82e-01
epoch: 6, lr: 1.50e-04 - train si-snr: -2.29e-01 - valid si-snr: -2.76e-01
epoch: 7, lr: 1.50e-04 - train si-snr: -2.43e-01 - valid si-snr: -2.71e-01
epoch: 8, lr: 1.50e-04 - train si-snr: -2.34e-01 - valid si-snr: -2.61e-01
epoch: 9, lr: 7.50e-05 - train si-snr: -2.51e-01 - valid si-snr: -2.85e-01
epoch: 10, lr: 7.50e-05 - train si-snr: -2.45e-01 - valid si-snr: -2.72e-01
epoch: 11, lr: 7.50e-05 - train si-snr: -2.38e-01 - valid si-snr: -2.80e-01
epoch: 12, lr: 7.50e-05 - train si-snr: -2.40e-01 - valid si-snr: -2.88e-01
epoch: 13, lr: 7.50e-05 - train si-snr: -2.53e-01 - valid si-snr: -2.86e-01
epoch: 14, lr: 7.50e-05 - train si-snr: -2.49e-01 - valid si-snr: -2.77e-01

# Generated 2023-02-27 from:
# /home/yangjie/speechbrain/recipes/LibriMix/separation/hparams/sepformer-libri2mix.yaml
# yamllint disable
# ################################
# Model: SepFormer for source separation
# https://arxiv.org/abs/2010.13154
# Dataset : Libri2mix
# ################################
#
# Basic parameters
# Seed needs to be set at top of yaml, before objects with parameters are made
#
seed: 1234
__set_seed: !apply:torch.manual_seed [1234]

# Data params

# e.g. '/yourpath/Libri2Mix/train-clean-360/'
# the data folder is needed even if dynamic mixing is applied
data_folder: /data/yangjie/LibriMix/Libri2Mix

# this is the base folder for dynamic mixing
base_folder_dm: /data/yangjie/LibriMix

experiment_name: sepformer-libri2mix
output_folder: results/sepformer-libri2mix/1234
train_log: results/sepformer-libri2mix/1234/train_log.txt
save_folder: results/sepformer-libri2mix/1234/save
train_data: results/sepformer-libri2mix/1234/save/libri2mix_train-360.csv
valid_data: results/sepformer-libri2mix/1234/save/libri2mix_dev.csv
test_data: results/sepformer-libri2mix/1234/save/libri2mix_test.csv
skip_prep: false

ckpt_interval_minutes: 60

# Experiment params
auto_mix_prec: true # Set it to True for mixed precision
test_only: false
num_spks: 2
noprogressbar: false
save_audio: false # Save estimated sources on disk
sample_rate: 8000

# Training parameters
N_epochs: 200
batch_size: 4
lr: 0.00015
clip_grad_norm: 5
loss_upper_lim: 999999  # this is the upper limit for an acceptable loss
# if True, the training sequences are cut to a specified length
limit_training_signal_len: false
# this is the length of sequences if we choose to limit
# the signal length of training sequences
training_signal_len: 32000000

# Set it to True to dynamically create mixtures at training time
dynamic_mixing: false
use_wham_noise: false

# Parameters for data augmentation
use_wavedrop: false
use_speedperturb: true
use_rand_shift: false
min_shift: -8000
max_shift: 8000

speedperturb: !new:speechbrain.lobes.augment.TimeDomainSpecAugment
  perturb_prob: 1.0
  drop_freq_prob: 0.0
  drop_chunk_prob: 0.0
  sample_rate: 8000
  speeds: [95, 100, 105]

wavedrop: !new:speechbrain.lobes.augment.TimeDomainSpecAugment
  perturb_prob: 0.0
  drop_freq_prob: 1.0
  drop_chunk_prob: 1.0
  sample_rate: 8000

# loss thresholding -- this thresholds the training loss
threshold_byloss: true
threshold: -30

# Encoder parameters
N_encoder_out: 256
out_channels: 256
kernel_size: 16
kernel_stride: 8
d_ffn: 1024

# Dataloader options
dataloader_opts:
  batch_size: 4
  num_workers: 4

# Specifying the network
Encoder: &id003 !new:speechbrain.lobes.models.dual_path.Encoder
  kernel_size: 16
  out_channels: 256

SBtfintra: &id001 !new:speechbrain.lobes.models.dual_path.SBTransformerBlock
  num_layers: 8
  d_model: 256
  nhead: 8
  d_ffn: 1024
  dropout: 0
  use_positional_encoding: true
  norm_before: true

SBtfinter: &id002 !new:speechbrain.lobes.models.dual_path.SBTransformerBlock
  num_layers: 8
  d_model: 256
  nhead: 8
  d_ffn: 1024
  dropout: 0
  use_positional_encoding: true
  norm_before: true

MaskNet: &id005 !new:speechbrain.lobes.models.dual_path.Dual_Path_Model

  num_spks: 2
  in_channels: 256
  out_channels: 256
  num_layers: 2
  K: 250
  intra_model: *id001
  inter_model: *id002
  norm: ln
  linear_layer_after_inter_intra: false
  skip_around_intra: true

Decoder: &id004 !new:speechbrain.lobes.models.dual_path.Decoder
  in_channels: 256
  out_channels: 1
  kernel_size: 16
  stride: 8
  bias: false

optimizer: !name:torch.optim.Adam
  lr: 0.00015
  weight_decay: 0

loss: !name:speechbrain.nnet.losses.get_si_snr_with_pitwrapper

lr_scheduler: !new:speechbrain.nnet.schedulers.ReduceLROnPlateau
  factor: 0.5
  patience: 2
  dont_halve_until_epoch: 5

epoch_counter: &id006 !new:speechbrain.utils.epoch_loop.EpochCounter
        # lr_scheduler: !ref <lr_scheduler>

  limit: 200

modules:
  encoder: *id003
  decoder: *id004
  masknet: *id005
checkpointer: !new:speechbrain.utils.checkpoints.Checkpointer
  checkpoints_dir: results/sepformer-libri2mix/1234/save
  recoverables:
    encoder: *id003
    decoder: *id004
    masknet: *id005
    counter: *id006
train_logger: !new:speechbrain.utils.train_logger.FileTrainLogger
  save_file: results/sepformer-libri2mix/1234/train_log.txt

# If you do not want to use the pretrained separator you can simply delete pretrained_separator field.
# pretrained_separator: !new:speechbrain.utils.parameter_transfer.Pretrainer
#     collect_in: !ref <save_folder>
#     loadables:
#         encoder: !ref <Encoder>
#         decoder: !ref <Decoder>
#         masknet: !ref <MaskNet>
#     paths:
#         encoder: speechbrain/sepformer-wsj02mix/encoder.ckpt
#         decoder: speechbrain/sepformer-wsj02mix/decoder.ckpt
#         masknet: speechbrain/sepformer-wsj02mix/masknet.ckpt

Hmm it's probably due to some quirk in gradient checkpointing (see https://discuss.pytorch.org/t/checkpoint-with-no-grad-requiring-inputs-problem/19117/9). Try to checkpoint the MaskNet only:
# Separation
mix_w = self.hparams.Encoder(mix)
# est_mask = self.hparams.MaskNet(mix_w)
est_mask = torch.utils.checkpoint.checkpoint(
    self.hparams.MaskNet, mix_w,
)

@lucadellalib
thanks， The above modification will still  CUDA out of memory，batch size =1，  num_workers = 0

@zuowanbushiwo you can try to apply gradient checkpointing to all the operations. To do so, replace line 42 with (starting from the original script):
def compute_forward(self, mix, targets, stage, noise=None, dummy_tensor=None):

and code blocks at lines 125 and 159 with:
#predictions, targets = self.compute_forward(
#    mixture, targets, sb.Stage.TRAIN, noise
#)
#loss = self.compute_objectives(predictions, targets)
predictions, targets = torch.utils.checkpoint.checkpoint(
    self.compute_forward, mixture, targets, sb.Stage.TRAIN, noise, torch.empty(1, requires_grad=True)
)
loss = torch.utils.checkpoint.checkpoint(
    self.compute_objectives, predictions, targets
)

If you still get an out-of-memory error, you could try to split the model onto different GPUs (see https://pytorch.org/tutorials/intermediate/model_parallel_tutorial.html).

@lucadellalib
Thanks, I will try!


refactor: replaced duplicating literals with constants

Defining constants instead of duplicating string literals
The zwave_js component's api.py file contains eight code smells, all of which are duplicated string literals. As a result, constants are defined to increase code quality.
Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[ ] New feature (which adds functionality to an existing integration)
[ ] Deprecation (breaking change to happen in the future)
[ ] Breaking change (fix/feature causing existing functionality to break)
[x] Code quality improvements to existing code or addition of tests

Checklist

[x] The code change is tested and works locally.
[x] Local tests pass. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist
[x] I have followed the perfect PR recommendations
[x] The code has been formatted using Black (black --fast homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
[ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

[ ] I have reviewed two other open pull requests in this repository.

Very nice


Homework 0

I think you already saw this, but I just wanted to make sure! Do I have to make a pull request every time?

No need to make pull requests :) I wouldn't pull your submissions into the main repo. I am cloning your repos in my local machine and checking your homeworks from there. Also, you don't need to move the homework from the homeworks/ directory. Just copy it to submissions. Anyways, it doesn't make a huge difference for you.

cool thanks! I wasn't sure how it worked on your end!
On Tue Feb 10 2015 at 2:02:23 PM Harry Mavroforakis <
<EMAIL_ADDRESS>wrote:

Closed #4 https://github.com/dataminingapp/spring-2015-homeworks/pull/4.
—
Reply to this email directly or view it on GitHub
https://github.com/dataminingapp/spring-2015-homeworks/pull/4#event-233438312
.

:+1:


Fix namespace

Had two problems setting a new namespace for Twill (App\Admin):

It could not find some classes anymore, because they were hardcoded.
When making a new module it did not respect the new namespace path.

This PR fixes both.

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

Hi @antonioribeiro, thank you so much for this!
It fixes #193.


Add explanation of ‘random_tie_break’ to documentation

It’s not clear to me what the argument ‘random_tie_break’ exactly does. Could you please add a few lines to the documentation or examples about it?

in uncertainty sampling, we rank the data points by informativeness as measured by an acquisition function such as entropy or margin. In case there are several data points that are ranked equally, which ones should you choose? you can either take the ones returned by uncertainty.argsort()[:n] or you can first shuffle the data and then use argsort. that is what random tie break does here.


feature: allow developers to customize the implementation of third-party routers

The current route is implemented on the basis of r3. Although it is powerful, it cannot be fully compatible for different user scenarios.
So we also support router plugins, allowing users to implement different routers according to their needs.
目前的路由是在 r3 基础上实现的，虽然它比较强大，不过针对不同用户场景也无法做到全部兼容。
所以我们也支持路由器插件，允许用户根据自身需求实现不同的路由器。

now we support radixtree router.

APISIX allows users to customize different routers.


refactor(behavior_velocity_planner): update launch and parameter files for plugin

Description
Update launch and parameter files. See https://github.com/autowarefoundation/autoware.universe/issues/3724 for details.
This PR depends on https://github.com/autowarefoundation/autoware.universe/pull/3811.
Tests performed
Check autonomous driving in planning simulator.
Effects on system behavior
None.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[x] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@isamu-takagi it seems there are some missing modules in the PR. Is there a reason for that?

@mehmetdogru Thank you. It seems that the merge did not work well because the no_drivable_lane module was added during this PR. I'll add it. Are there any other missing modules?

Under launch modules only no_drivable_lane.
In planning_component.launch.xml there are a few missing:
virtual_traffic_light
occlusion_spot
run_out
speed_bump
no_drivable_lane
Thank you :pray:

Ah, I see. Always load all module parameters and only change launch_modules.


Travis is getting slow again

See for example https://travis-ci.org/CCI-MOC/hil/builds/364351101, which took ~17 minutes. This is approaching double what it was a couple months ago.
We should figure out what's slowing it down and fix it; it's starting to get annoying.
See also #833 and #834 for general optimization ideas, though obviously measure first...

Caching seems like a good idea to me.
Another idea: The new CLI integration tests and the client library tests take a good amount of time. We could test both of those in a different build by setting an env variable (maybe with only postgres). That way we can run CLI+client lib test  (and other integration tests) in parallel with the rest of the tests.

Might make sense to close this one now; we've got it down to 4-6 minutes, which is the fastest it's been in forever. Further performance improvements are always welcome, I think always welcome, but I don't think this issue is still something that needs an open ticket.


Errors in the examples

Hi,
I am trying to make use of this wonderful tool, but I keep getting errors for the provided examples, mostly because of the dependence of ParaMol on many external helper codes, like ASE, DFTB+, etc. I wonder if you have recently tested the examples and if you can list the exact versions of the auxiliary codes you have used and if you can provide some interactive Jupiter notebooks with these examples,
Thanks,
Marawan

Hi,
Can you please specify what are the errors you are getting?
All examples are updated and have been recently tested. The DFTB+ version is 19.1, though more recent ones should still work if ASE has been updated accordingly. The ASE version is the most recent one, 3.21.1 .
Best regards,
João

Hi Joao,
For example,
1- The OpenMMEngine argument does not accept "crd_format" keyword.
TypeError: init() got an unexpected keyword argument 'crd_format'
This is in all examples
2- from ParaMol.Utils.Symmetrizers.amber_symmetrizer import * does not call and has to change to "from ParaMol.Utils.amber_symmetrizer import *"
3-The psi/orca ase calculators.
4-Example 5 gives this error:
Traceback (most recent call last):
File "example_5.py", line 22, in
norfloxacin.force_field.create_force_field(ff_file="norfloxacin_symm.ff")
File "~/anaconda3/envs/paramol/lib/python3.7/site-packages/ParaMol/Force_field/force_field.py", line 95, in create_force_field
assert os.path.exists(ff_file), "\t * ERROR: .param file provided - {} - does not exist."
AssertionError: 	 * ERROR: .param file provided - {} - does not exist.
This is in all examples with the symmetrization consideration.
5-There is no Example 6 (not sure if this is intentional).
It would be great if you can provide even a single conventional working example for norfloxacin/aspirin etc (the drug-like molecule space everyone is working with), without any advanced functionalities, such as symmetry consideration or something, particularly for the torsional and bonded parameters. Just a vanilla-like example. I tried to use the CO example to generalize to for example Norfloxacin, but it did not work.
Your help is much appreciated and your tool is truly remarkable, cannot wait to use it,
Thanks,
Marawan

Hi,
All examples are working just fine, what is happening is that you have to update your ParaMol version. Just download this github repo and point to it by using the following code snippet at the top of your scripts:
import os
import sys
# Path to ParaMol
sys.path.insert(0, os.path.abspath(path_to_paramol))

4 - It gives you that error because you have not create the .ff file. My advise is that you read the full documentation at https://paramol.readthedocs.io/en/latest/Examples/Example_5/Example_5.html .
5 -Example 6 exists and you can find it on the webpage.https://paramol.readthedocs.io/en/latest/Examples/Example_6/Example_6.html

Hi Joao,
Adding the os.path.abspath did not help.
Now the DFTB+ and the PSI4 calculators in the adaptive parametrization example gives this error:
Traceback (most recent call last):
File "example_3.py", line 58, in
adaptive_parametrization.run_task(paramol_settings, [caffeine], rmsd_tol=0.0001, max_iter=100, structures_per_iter=100, )
File "~/anaconda3/envs/paramol/lib/python3.7/site-packages/ParaMol/Tasks/adaptive_parametrization.py", line 96, in run_task
system.create_qm_engines(settings.qm_engine["qm_engine"], settings.qm_engine[settings.qm_engine["qm_engine"].lower()])
AttributeError: 'Psi4' object has no attribute 'lower'
or(AttributeError: 'Dftb' object has no attribute 'lower')
I will read the documentation again and see if the issues persist. I am sure there is an incompatibility issue somewhere between ASE/DFTB+/PSI4 and ParaMol. Perhaps the more the users start using the tool, the issue will be more clear.
Thanks

Hi,
There no incompatibility. I have just tried with both code DFTB+ and Psi4 without any issue.
The way you set, e.g., the DFTB+ ASE calculator is by using the following code:
# Create the ASE calculator
from ase.calculators.dftb import *

calc = Dftb(Hamiltonian_='DFTB',
			Hamiltonian_MaxAngularMomentum_='',
			Hamiltonian_MaxAngularMomentum_O='p',
			Hamiltonian_MaxAngularMomentum_C='p',
			Hamiltonian_SCC='Yes',
			Hamiltonian_SCCTolerance=1e-8,
			Hamiltonian_MaxSCCIterations=10000)

# Set the calculator in the settings; alternatively the QM engine could be created manually
paramol_settings.qm_engine["ase"]["calculator"] = calc

I have no access to your script, but it seems me that you are setting paramol_settings.qm_engine["qm_engine"] to the ASE calculator instance itself, whilst you should be setting paramol_settings.qm_engine["qm_engine"]="ase" and paramol_settings.qm_engine["ase"]["calculator"] = calc, where calc is the ASE calculator instance.
Hope this helps.

Mostly, it was a DFTB+ issue. Mine was  20.2 and the script seems to be compatible with 19.1.

If that is the case, I encourage you to report those errors in the ASE repository as they are not related to ParaMol.


Add a pre-commit for validating zarf schema

Description
Add a pre-commit hook that will validate that the ZarfInitConfig ./zarf.yaml confirms to the schema defined at ./zarf.schema.json. This will help prevent issues where developers update the init config without updating the schema.
Related Issue(s)
Fixes #216

This is the result of the pre-commit hook if you change the zarf.yaml without changing the schema definition.

We will need to look into this some more. This only checks the zarf.yaml for init packages and isn't fully verifying that the generated schema actually is correct. Would it be simpler to just run zarf tools config-schema > zarf.schema.json in a pre-commit step?

It's not quite this simple, but yes, it should be along these lines. pre-commit is already smart enough to know that a changed file means a failed hook.

I would like to merge this PR, as what it is doing is still valuable, just without closing #216.

Though, it would be better to have the hook check all zarf.yaml files that get changed in the repo, rather than just the root one. I haven't looked closely at the hook's capabilities, but if it does what I think it should we can change the work here to run the hook an all files named zarf.yaml

This hook will run against any file named zarf.yaml that has been staged for commit.

Cool, then yeah, I'd like to merge this, just without closing #216

Would it be simpler to just run zarf tools config-schema > zarf.schema.json in a pre-commit step?

If we're going to do something like that I would rather do it in an automated pipeline instead of a pre-commit hook.

I don't want the pre-commit to be dependent on having the CLI built and building it in the hook would be too slow which seems like a lot of friction.
We could probably do it without the zarf CLI but that would require dependencies to be manually installed which is also too much friction IMO.

It doesn't need to "be built", it could be go run cli/main.go tools.  But 🤷

The pre-commit hooks don't have to be run locally, though once we turn on verification of them in the pipeline it will be a lot easier to run them locally then get the feedback loop on what still needs to be fixed from the pipeline.
My vision for the pipeline is that it will run pre-commit run -a which will fail if any of the hooks fail, which would easily and automatically get us linting, checking for secrets, code style (after we add a styler similar to how Prettier or Black work), and other great automated checks.

Doing so will require certain CLI tools to be installed on the developer's machine, such as golangci-lint.

pre-commit hook now verifies the zarf-schema is up-to-date if the cli/types/types.go file is ever updated. It also still verifies any modified zarf.yaml conforms to the schema.


fix(KFLUXBUGS-752): skip signing if already signed

This commit updates the rh-sign-image task to
skip signing an image

Closing this PR as #585 will cover the 'skip-signing if already signed' task.
Scott’s approach seems better - to check directly in Pyxis rather than via skopeo inspect


deprecation log message

Since doctrine/doctrine-bundle 2.12: The default value of "doctrine.orm.controller_resolver.auto_mapping" will be changed from true to false. Explicitly configure true to keep existing behaviour
After update, I receive this log message.
In doctrine.yaml this auto_mapping exist, not sue what is wrong.
maybe it should be in this format:
doctrine:    orm:         controller_resolver:             auto_mapping: true

Can you check if the deprecation message vanishes, when you update your config like in #1508?


Mad Productivity 0.0.2 crashes on startup on Pop!_OS with Nvidia card

The previous version of MadProductivity worked fairly well on my system. I downloaded the latest and it is crashing on startup.
I'm running on Pop!_OS 21.04 with (I think) all the latest updates installed. I unzipped the file in my Downloads/ folder, changed the file to executable, ran it and it crashed. I started on the command line and got the following error:
./MadProductivity.x86_64
Godot Engine v3.4.stable.official.206ba70f4 - https://godotengine.org
OpenGL ES 2.0 Renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2
OpenGL ES Batching: ON
WARNING: Debanding is not supported in the GLES2 backend. To use debanding, switch to the GLES3 backend and make sure HDR is enabled.
at: render_target_set_use_debanding (drivers/gles2/rasterizer_storage_gles2.cpp:5643)
directory exists!
directory exists!
directory exists!
Resource exists!
Resource exists!
Resource exists!
Segmentation fault (core dumped)

I wonder what this could be a problem with! I suspect it might be colliding with the previously saved time tracking data from the previous version. Easiest way to try would be to go to your local data folder an rename the one where mad productivity has its data. Then try running mad productivity again. If it works then the issue was with data, if not it's going to be a different problem.
Perhaps, could I send you a debug build, to see more info when you run it?
Thanks!

I believe I had this same issue but with an Intel HD Graphics 620 and W10. Moving out all files from my user data settings: /AppData/roaming/Godot/MadProductivity/ got it to launch, and afterwards it launches like normal while remembering what I entered in the new version. I haven't tried migrating my 0.0.1 userdata to 0.0.2, but I don't really have a mighty need to. Maybe there's some discrepancy in how it's stored?

The time tracking and Todo resources have a new structure, those should have a function that'd migrate data. This is something that needs to be implemented.
If possible, would you send the resources from 0.0.1?

@DeerTears looks like Linux keeps the data in $HOME/.local/share/godot/app_userdata/MadProductivity I zipped up a copy of it for troubleshooting and removed it and the app launched fine. Luckily I only had one item I tracked any time against since I've just started trying this out.

The time tracking and Todo resources have a new structure, those should have a function that'd migrate data. This is something that needs to be implemented. If possible, would you send the resources from 0.0.1?

Removing the previous data fixed it! I've got the data zipped up, just not sure what is the best way to send that to you?
Also I'm curious if you've messed with migrating the data structures. Is that something fairly easy to do in Godot?

@kennydrobnack feel free to send me a zip with the time tracking and too resources, I'll take care of the rest.
I have dabbled with data migrating, only once before but it was pretty straight forward, each resource will have a version number and if they dont line up there are methods that move the data around in a way that'll make it accessible (hopefully)

Here's my zipped folder from
~/.local/share/godot/app_userdata/MadProductivity
On Sat, Nov 13, 2021 at 4:06 AM Krystof Klestil @.***>
wrote:

@kennydrobnack https://github.com/kennydrobnack feel free to send me a
zip with the time tracking and too resources, I'll take care of the rest.
I have dabbled with data migrating, only once before but it was pretty
straight forward, each resource will have a version number and if they dont
line up there are methods that move the data around in a way that'll make
it accessible (hopefully)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Mad-Cookies-Studio/mad-productivity/issues/10#issuecomment-967876796,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAZ5YPBKYDUIMRUTYDPKKLULYTBXANCNFSM5H35HO6Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thank you very much, sadly I cant see the file, can you try sending it again? Thanks!

Thank you very much, sadly I cant see the file, can you try sending it again? Thanks!

Shoot. It looks like the attachments sent to Github emails when I reply to them get dropped. Sorry about that. Let me try attaching one directly.
MadProductivity-kenny.tar.gz


Atom Editor Plugin

Hi,
do you have plans to make a Atom Plugin?
tks

No plans yet, though contributions are certainly welcome.

I'm using your excellent gotests utility with Atom, and made a simple plugin for it - https://atom.io/packages/gotests. It resembles the Sublime Text plugin functionality. Hope it helps!

Thanks! I'll like to your plugin in the README.


Re-work file links

Currently, file links are:
"links": {
                "self": "http://localhost:7777/file?path=/169174_10100665350888296_1186161238_o.jpg&nid=xaqjm&provider=dropbox&cookie=553949f0f89ab6fbc6928e32.SDRtwDvjCgbmRxvkbjEQHZg5lW8",
                "related": "http://localhost:8000/nodes/xaqjm/files/?path=%2F169174_10100665350888296_1186161238_o.jpg&provider=dropbox"
            }

They should be more like node links with the extra level.
"links": {
                "files": {
                    "related": "http://localhost:8000/nodes/xaqjm/files/"
                },
                "contributors": {
                    "count": 1,
                    "related": "http://localhost:8000/nodes/xaqjm/contributors/"
                },
                "pointers": {
                    "count": 1,
                    "related": "http://localhost:8000/nodes/xaqjm/pointers/"
                },
                "registrations": {
                    "count": 0,
                    "related": "http://localhost:8000/nodes/xaqjm/registrations/"
                },
                "self": "http://localhost:8000/nodes/xaqjm/",
                "html": "http://localhost:5000/xaqjm/",
                "children": {
                    "count": 1,
                    "related": "http://localhost:8000/nodes/xaqjm/children/"
                }
            }

I think the extra level will include things like (wording may change) "Add", "Delete", "List". We may also want to do a methods object at the same level as links that would include the same items as the links but with things like "POST", "DELETE", and "GET".
Also consider ditching the JSONAPI labels (self, related, etc) in favor or something that's good.

For now, I've moved the valid_self_methods inline with the self, much the same way we're doing the counts. I still need to handle anonymous users a bit better, and I need to remove the link if there are no valid methods.

Looks like this for now.
{
    "data": [
        {
            "provider": "dropbox",
            "path": "/169174_10100665350888296_1186161238_o.jpg",
            "item_type": "file",
            "name": "169174_10100665350888296_1186161238_o.jpg",
            "metadata": {
                "size": 217413,
                "modified": "Tue, 09 Apr 2013 12:07:11 +0000",
                "content_type": "image/jpeg",
                "extra": {
                    "revisionId": "18b5e41d001aac1c"
                }
            },
            "links": {
                "self_methods": [
                    "GET",
                    "POST",
                    "DELETE"
                ],
                "self": "http://localhost:7777/file?path=/169174_10100665350888296_1186161238_o.jpg&nid=xaqjm&provider=dropbox&cookie=554d11b0f89ab6e715e4c5cb.mCPDkgcr6pHZFc8DfLbvif5uJ9I",
                "related": "http://localhost:8000/nodes/xaqjm/files/?path=%2F169174_10100665350888296_1186161238_o.jpg&provider=dropbox"
            },
            "type": "files"
        },
        {
            "provider": "dropbox",
            "path": "/1509023_10202067600584752_1687864329_n.jpg",
            "item_type": "file",
            "name": "1509023_10202067600584752_1687864329_n.jpg",
            "metadata": {
                "size": 55156,
                "modified": "Wed, 05 Mar 2014 17:46:24 +0000",
                "content_type": "image/jpeg",
                "extra": {
                    "revisionId": "18b607fb001aac1c"
                }
            },
}


Fix the permission denied error in postgres_wait_install script in security bootstrapper

🐞 Bug Report
Affected Services [REQUIRED]

 The issue is located in `postgres_wait_install` entrypoint script in security bootstrapper while running Postgres service with Security mode is enabled.
Is this a regression?

 No.
Description and Minimal Reproduction [REQUIRED]
Add the following edgex-postgres to docker-compose.yml to start Postgres service with Security and start the EdgeX services with docker compose up -d command:
edgex-postgres:
    container_name: edgex-postgres
    depends_on:
      security-bootstrapper:
        condition: service_started
        required: true
      security-secretstore-setup:
        condition: service_started
        required: true
    entrypoint:
      - /edgex-init/postgres_wait_install.sh
    environment:
      DATABASECONFIG_NAME: create-users.sh
      DATABASECONFIG_PATH: /tmp/postgres-init-scripts
      EDGEX_SECURITY_SECRET_STORE: "true"
      PROXY_SETUP_HOST: edgex-security-proxy-setup
      SECRETSTORE_HOST: edgex-vault
      STAGEGATE_BOOTSTRAPPER_HOST: edgex-security-bootstrapper
      STAGEGATE_BOOTSTRAPPER_STARTPORT: "54321"
      STAGEGATE_DATABASE_HOST: edgex-postgres
      STAGEGATE_DATABASE_PORT: "5432"
      STAGEGATE_DATABASE_READYPORT: "5432"
      STAGEGATE_PROXYSETUP_READYPORT: "54325"
      STAGEGATE_READY_TORUNPORT: "54329"
      STAGEGATE_REGISTRY_HOST: edgex-core-keeper
      STAGEGATE_REGISTRY_PORT: "59890"
      STAGEGATE_REGISTRY_READYPORT: "54324"
      STAGEGATE_SECRETSTORESETUP_HOST: edgex-security-secretstore-setup
      STAGEGATE_SECRETSTORESETUP_TOKENS_READYPORT: "54322"
      STAGEGATE_WAITFOR_TIMEOUT: 60s
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: edgex_db
    hostname: postgres
    image: postgres:16.3-alpine3.20
    networks:
      edgex-network: null
    ports:
      - mode: ingress
        host_ip: <IP_ADDRESS>
        target: 5432
        published: "5432"
        protocol: tcp
    read_only: true
    restart: always
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /run
      - /tmp
    user: root:root
    volumes:
      - type: volume
        source: postgres-data
        target: /var/lib/postgresql/data
        volume: { }
      - type: volume
        source: edgex-init
        target: /edgex-init
        read_only: true
        volume: { }
      - type: bind
        source: /tmp/edgex/secrets/security-bootstrapper-postgres
        target: /tmp/edgex/secrets/security-bootstrapper-postgres
        read_only: true
        bind:
          selinux: z
          create_host_path: true

🔥 Exception or Error
Got the following error in the edgex-postgres service log:

level=INFO ts=2024-09-04T08:52:41.87796327Z app=security-bootstrapper-postgres source=secret.go:216 msg="load token from file"
level=WARN ts=2024-09-04T08:52:41.877982603Z app=security-bootstrapper-postgres source=secret.go:132 msg="Retryable failure while creating SecretClientt: open /tmp/edgex/secrets/security-bootstrapper-postgres/secrets-token.json: permission denied"

🌍  Your Environment
Deployment Environment: Ubuntu 20
EdgeX Version [REQUIRED]: 3.2

Issue fixed via https://github.com/edgexfoundry/edgex-go/pull/4906/


[CON-257] .prompt file prompt is not seen by the LLM in later messages

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS:*
- Continue:*
- IDE:*

Description
When using a .prompt file, later messages are not aware of the prompt because it is hidden within the slash command.
We don't want to show the entire prompt file prompt in the user input box, so we need a way of saving the "resolved" prompt like we do with context providers
To reproduce

Write a prompt file
Use it with a slash command

Log output
No response
CON-257

I think the way of doing this would be to add a return value to the slash command run function which tells how to replace the prompt for use in LLM history going forward in the chat


New project structure

With this strucutre, the plugin can support more than one version in one jar.
It requires to remove ALL nms stuff from the main module.
This process will take a while but once finished, it will be easy to add support for any version.
For testing do the following:
Remove the paperweight-paperDevBundle dependency in ./build.gradle.kts
By the way I'll just dump out commits into this branch and once this is done, I'll do a big Squash-commit

starting again


Blocked esbuild.exe executable breaks Angular projects

🐞 Bug report
The issue originates in esbuild (see: https://github.com/evanw/esbuild/issues/1561), but since Angular adopted esbuild as part of build system it stopped companies with strict binary execution policy on Windows to continue updating Angular projects.
Command (mark with an x)

[x] new (as it does installation of dependencies, postinstall fails)
[x] build
[ ] serve
[ ] test
[ ] e2e
[ ] generate
[ ] add
[ ] update
[ ] lint
[ ] extract-i18n
[ ] run
[ ] config
[ ] help
[ ] version
[ ] doc

Is this a regression?
In some scope, yes. Earlier versions of Angular do not use esbuild and because of that the issue does not exist in Angular workspaces.
Description
On Windows machines with restricted binary execution policy (quite common setup in enterprise companies) execution of esbuild.exe is being blocked. This results in (1) failed postinstall and (2) failure to build projects.
Postinstall failure:

esbuild comes as a transitive dependency from Angular:

Build failure (output is full of identical errors):

Executable is blocked:

🔬 Minimal Reproduction
Ideas to reproduce similar behaviour:

Block execution of esbuild.exe on Windows (?)

Ideas how this issue could be solved:

Angular could provide an option to fallback to esbuild-wasm. Ideally, the fallback should happen only on Windows and other environments could benefit from full potential of esbuild.
Support esbuild project to code sign executable (More info: https://github.com/evanw/esbuild/issues/1561). Having code signed executable would provide a way for companies to create execution exception rules for all future versions  of esbuild.exe.

Hi, getting the same issue myself and this is a major problem for us, we have just upgraded to Angular 12.2.4 and now unable to install on any machine due to our McAfee blocking esbuild.  This is a significant problem and needs some kind of resolution.

As a workaround if you use Yarn, you can use "resolutions"
"resolutions": {
  // Note: this has to match the esbuild version in @angular-devkit/build-angular/package.json
<EMAIL_ADDRESS><EMAIL_ADDRESS>}

Thank you @alan-agius4 for your suggestion! This definitely could help for some companies.
Unfortunately, not all companies use Yarn. Also, this would make all environments to fallback to esbuild-wasm. Ideally, CI (on Linux) and Linux/Mac users should not suffer because of Windows users in their organisation.

I think this needs to be on opt-in bases and it doesn't make sense top  to force this on all Windows users as esbuild-wasm can be up to 10x slower.

Me too!  As a temporary solution I have forced @angular-devkit/build-angular to be 12.1.4 which seems to be the newest version before the dependency on esbuild.


fix: fix the label generating style of VGGFace2

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
7803

Relevant Lines:
9029

💛  - Coveralls