Tracking issue regarding changes required to support new modules

We have discussed the usage of Nushell for developing modules here: https://github.com/blue-build/modules/issues/212
We're working on a v2 of the default-flatpaks module here: https://github.com/blue-build/modules/pull/336
Here's a quick list of things that need to be implemented in CLI to finish off the support for the new types of modules and default-flatpaks v2:

[ ] Support for modules published as separate images under the source image path

See https://github.com/blue-build/modules/pkgs/container/modules%2Fdefault-flatpaks

[ ] Support for specifying the version of the module to use (corresponding to the image tag)

Proposed syntax: type: default-flatpaks@v1, type: default-flatpaks@v2, type: default-flatpaks@latest etc.
Fetch @latest by default
Needs schema changes

[ ] Support for module scripts without .sh suffix

A script in Nushell should not use the .sh suffix.
Need to figure out how to handle existing modules, including custom modules
Ideas:

Expect .sh to be there by default, unless the module.yml declares that the module is in Nushell
Expect .sh to not be there, rename the script files of all modules (would break builds with earlier versions, but could be mitigated with symlinks) (local modules might need a different procedure)
Run the Nushell module with a bash wrapper (using an .sh file that is a shim for the .nu script) (no CLI changes required)

[ ] Support for modules written in Nushell

https://github.com/blue-build/nushell-image shall be used as the distribution mechanism for Nushell

Ex. COPY --from=ghcr.io/blue-build/nushell-image:0.98.0 /nu/nu /usr/bin/nu

Ideally the supported Nu version is declared by the repository (or possibly even the module)
But it would be wasteful to ship multiple Nu binaries in the images
It would be wasteful to ship a Nu binary at all if the module does not have any post-boot elements
Ideas:

Modules using Nushell declare the version the want in their module.yml, that is read by the CLI, and that image is bind-mounted to their RUN-step. If a module needs Nushell post-boot, it can cp the binary to the appropriate location.
Modules using Nushell declare the version the want in their module.yml, that is read in the build process for the module repository, and the binaries are added into the image for the module alongside the source code. If a module needs Nushell post-boot, it can cp the binary to the appropriate location.
Nushell replaces yq (and possibly others) and goes alongside bluebuild as one of the binaries that gets included in every image. The version is the same across all builds and modules (need to make sure all modules support the newer version before upgrading, but wasting resources on shipping multiple versions becomes impossible).

So if we're wanting to have a way to declare the version of NuShell used for the module, this might require having the binaries mounted for version and module call. We could then have the run_module script set the PATH variable with the mounted path for the nushell bins.
If the property for the nushell version doesn't exist, we could assume either:

No NuShell binary image is mounted
We default to the latest version

If we're going to go the route of allowing NuShell version specification, I don't think we would be able to ship images with a NuShell binary as they could be very different versions used. Which would mean that for runtime modules (modules that run when the user is booted), we should rely soley on using Bash since we can pretty much guarantee that shell will be available.
On another note, I think for ease of use we should have a label on the image containing the contents of module.yml as JSON so that the CLI can have an easier time getting that information for each versioned image.

If we're going to go the route of allowing NuShell version specification, I don't think we would be able to ship images with a NuShell binary as they could be very different versions used.

Could we set the version to be same for the whole repo? Keeping it updated while slightly controlling it such that the builds don't break would be ideal. Not having to re-release the CLI on every version change would be nice too.
Maybe a recipe parameter to set the Nushell version tag in the same vein as we can set the CLI version from the recipe. The default could be a special tag in our Nushell repo that points to the currently supported version.

Could we set the version to be same for the whole repo? Keeping it updated while slightly controlling it such that the builds don't break would be ideal. Not having to re-release the CLI on every version change would be nice too.

I don't think that would work well with keeping versioned modules. If we ended up making a v2 of a module and started using a new version of nu, anyone using the v1 module could end up running into an issue where the code for that version is using features that are different/no longer exist in the new nu version.

Maybe a recipe parameter to set the Nushell version tag in the same vein as we can set the CLI version from the recipe. The default could be a special tag in our Nushell repo that points to the currently supported version.

I'd like to keep most maintenance burdens away from the user. They shouldn't have to manage which version of nushell they need to use for the different versions of modules. Remember the goal is to try to make image generation easy for users.

I'd like to keep most maintenance burdens away from the user. They shouldn't have to manage which version of nushell they need to use for the different versions of modules.

That was not my point; it was more that if one of our users would like to use a later version of Nushell for their own purposes they could do that, and that we could more effectively test using different Nushell versions with existing modules to see what, if anything, breaks.

I don't think that would work well with keeping versioned modules. If we ended up making a v2 of a module and started using a new version of nu, anyone using the v1 module could end up running into an issue where the code for that version is using features that are different/no longer exist in the new nu version.

There is nothing stopping us from changing the code of the v1 module to accommodate for the breaking changes. Nushell release blog posts neatly highlight all the breaking changes in a specific release, and being able to test modules on any arbitrary Nushell version would also help with that.

There is nothing stopping us from changing the code of the v1 module to accommodate for the breaking changes. Nushell release blog posts neatly highlight all the breaking changes in a specific release, and being able to test modules on any arbitrary Nushell version would also help with that.

Yeah that's fair. In this case should we just install nushell from the Fedora repos and use that version? That way we reduce the burden of keeping track of the version ourselves and just keep pace with upstream.
Right now it looks like in both Fedora 40 and 41 the latest version is 0.99.1. https://repology.org/project/nushell/versions

In this case should we just install nushell from the Fedora repos and use that version?

In my mind the idea of using the nushell-container (which I already built and is unlikely to break any time soon) is, besides supporting non-Fedora base images and older versions of Fedora, is that we can perfecly control the Nushell version and only switch our users over once we're sure the modules are not broken on the new version.

Ok after doing some digging, using the Fedora repos might not be the smartest idea since we are also supporting stages for other distros. The best thing to do at that point would be to just use the statically compiled version of the code. So we're back to specifying the version somehow. So how about we do:

Have a default version of nushell that is installed into the final image

The version can be specified in a file in https://github.com/blue-build/modules
We install it in /usr/bin/

Allow setting a nushell-version: property

Will mount the proper version of the image
Will set PATH to have the bins in that image first

export PATH="/tmp/nushell/:$PATH"

Allow module maintainers to set a label of org.blue-build.nushell-verison

The version is used to retrieve the correct version and do the same as if the user set it in nushell-version:

The biggest caveat being that our modules define the version that is installed into the final image. Though this does bring up the worry that a user might want to try to install the version that is supplied by Fedora packaging which would end up conflicting with what we supply.
Maybe we could go the libexec route and have our shell scripts explicitly call /usr/libexec/bluebuild/nushell-<version>/nu and source the plugins as needed. That way it wouldn't interfere with the Fedora packaging or what the user wants to install.

Have a default version of nushell that is installed into the final image

This all sounds pretty good.

Allow setting a nushell-version: property

Where is that set? I assumed it'd be the recipe, but I'm confused by the clarifying sublist.
My idea was that the nushell-version: property should exist:
A) So that we can more easily test modules with different Nushell versions
B) So that we can allow users to customize the version of Nushell they install if they so please

Allow module maintainers to set a label of org.blue-build.nushell-version

I guess this proposal is an alternative to the others? This is kind of the intuitive initial plan I had, but just including a single Nushell version per image, inside the image, sounds like the preferable option right now.

Though this does bring up the worry that a user might want to try to install the version that is supplied by Fedora packaging which would end up conflicting with what we supply. Maybe we could go the libexec route...

Installing Nushell to libexec by default sounds fine, if installing Nushell from repos potentially causes an error when it is already installed. Having two copies of Nushell in an image would be a bummer, though. Maybe it would be possible that if an user specifies nushell-version: default or something we include the BlueBuild default Nushell version in the PATH?

For the default version of Nushell, I think it should be based on a tag set for a specific version of nushell-image, since the default Nushell version is not something that can change when changing module repos, or should change when changing CLI versions.

Where is that set? I assumed it'd be the recipe, but I'm confused by the clarifying sublist.

That would be on the module definition itself. That way each module could run a specific version. The run_module.sh script could read nushell-version off the JSON that is passed in and update the PATH as necessary.

I guess this proposal is an alternative to the others? This is kind of the intuitive initial plan I had, but just including a single Nushell version per image, inside the image, sounds like the preferable option right now.

I think I'm starting to prefer it being specified as a LABEL. I don't think the module should have nushell itself inside it. We'll let the CLI template the Containerfile to pull the correct image version and copy the bins to /usr/libexec/bluebuild/nushell-<version>. That way it's dynamic and the CLI doesn't need to be updated to allow new versions.

For the default version of Nushell, I think it should be based on a tag set for a specific version of nushell-image, since the default Nushell version is not something that can change when changing module repos, or should change when changing CLI versions.

So the libexec way would just require that our scripts are sure to set the shebang to point to the correct version.
#! /usr/libexec/bluebuild/nushell-0.99.1/nu

Cause otherwise if you specify:
#! /usr/bin/env nu

That will rely on what is set in PATH. The "default" version of nushell feels like it would be too hard to keep track of (if we have our modules specify the version on a LABEL) unless it's the latest version which could introduce breaking changes. I think it would be better to require setting nushell-version on the module for custom local modules. If it's a container module, then we would grab the version from the LABEL and use that. If neither of these are specified, then we'll have to either let it error out or allow the user to install nushell into their image the way they want to. Whether that's using rpm-ostree/dnf or copying the binaries themselves into /usr/bin/.

I believe there's been some mutual misunderstanding here.

That would be on the module definition itself.

I don't think this is how it should be done. Say I'm reworking all modules that use Nushell to support a later Nushell version, it would be more straightforward to just set the Nushell version for the entire build. Or, I'm a user and want a specific Nushell version in my image, this approach makes it seem like that isn't even supported?

I think I'm starting to prefer it being specified as a LABEL.

If it's per-module I would agree, but I don't think it should be per-module.

I don't think the module should have nushell itself inside it.

I don't think so either, I mean that the image that the user is building is the one that should have a single version of Nushell in it, which is put there by us, and shipped with the image and not just there at build-time.

So I guess we have some conflicting ideas.
Your idea (I presume):

Module makers specify a label for the container image the module is built to that tells CLI which Nushell version is needed
CLI transparently inspects said label and mounts that Nushell version into the run environment
Post-boot parts of modules don't get to use Nushell
All modules get to specify the Nushell version separately
Users can optionally override the Nushell version used by a specific module for testing purposes

My idea:

We as BlueBuild maintainers (at least me) set the Nushell version to be used across all of BlueBuild. This version should be kept as up-to-date as possible while testing that the modules using Nushell run properly before changing the version.
I think this should be a tag on the nushell-image, which CLI could just use add to the image with ex. COPY --from=ghcr.io/blue-build/nushell-image:bluebuild-default ...
Post-boot parts of modules get to use Nushell
All modules use the same Nushell version (no need to ship multiple Nushells) while we make sure that official modules don't break
Users can optionally override the Nushell version shipped with their image to leverage newer Nushell versions and ideally also being able to use the BlueBuild-shipped Nushell for their own shell usage as well if they so please

Maybe lets come to a better consensus before starting contributions?

Say I'm reworking all modules that use Nushell to support a later Nushell version, it would be more straightforward to just set the Nushell version for the entire build.

I don't think it should be per-module.

Ok we can work with that.

I think this should be a tag on the nushell-image, which CLI could just use add to the image with ex. COPY --from=ghcr.io/blue-build/nushell-image:bluebuild-default ...

Ok yeah this could totally work

All modules use the same Nushell version (no need to ship multiple Nushells) while we make sure that official modules don't break

Sure. I think this will be a good way forward.

Maybe lets come to a better consensus before starting contributions?

I'm a software engineer at heart. It's how I think. You can't stop me :P

I think this should be a tag on the nushell-image, which CLI could just use add to the image with ex. COPY --from=ghcr.io/blue-build/nushell-image:bluebuild-default ...

Since this is ours, could we just go with default as the tag?

I'm a software engineer at heart. It's how I think. You can't stop me :P

It's good to have a software engineer around :P 💙
For me, thinking about software architecture is sometimes even more fun than coding haha

Since this is ours, could we just go with default as the tag?

I guess yeah, sure


Swift 3.0 / App crashing

I have forked this project to my Bitbucket account, and have successfully got it compiling in Xcode 8, beta 6. The only problem is that the demo app is crashing on startup (I have the iCloud configurations set up on Apple's side).
Here is the crash: (SMStore.swift)

I am not familiar enough with the codebase to fully understand what is going on. I could submit a pull request with my Swift 3.0 code, if that would help?
Thank you in advance for any assistance. I would really like to use this library in my application.

I have submitted a pull request with my Swift 3.0 code changes: https://github.com/nofelmahmood/Seam/pull/39

It seems that the owner of this repo is MIA.  I have created a new framework based on this code here.  It is updated to Swift 3, tidies up the code a bit and addresses the missing relationships functionality.  I am also hoping to add mapping between CKAssets and binary attributes, but I haven't done that yet.
Some constants and variables have moved from being globals so you may need to address this in your code, but hopefully swapping Seam3 for Seam should be pretty straight-forward.
I am still tinkering, so the repo should be considered unstable;  I hope to get a POD released soon.

Github projects getting abandoned seems more common by the day, they really should have a feature where a project can be kept alive, e.g. a way to move a project to an organisation where new admins can be added.


Add DD_SITE env var to Helm deployment template

What was changed
Added missing DD_SITE env var to the promql-to-dd-go Helm template
Why?
Metrics are being sent to the default Datadog site but our org is on a non-default site
Checklist

Closes #95

How was this tested:
I deployed the resulting chart using ArgoCD and the metrics are properly forwarded to the configured DD site

Any docs updates needed?
None

 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.


⚠ Secret Website 2 has degraded performance

In bedbab1, Secret Website 2 ($SECRET_WEBSITE_2) experienced degraded performance:

HTTP code: 200
Response time: 5892 ms

Resolved: Secret Website 2 performance has improved in abae1a6.


Add missing android:exported in PrinterReceiver

All activity, activity-alias, service, or receiver components that have intent-filter needs android:exported defined to be able to compile in Android 12.

@suraneti Please merge this :)

Merge this


Debugger does not release COM object references

Type: Bug
I've observed a strange behavior where VSCode does not release COM object references while debugging. PyCharm works fine. To see this in action do the following:
Start Excel (the problem occurs with other apps too, I'm using Excel for this example only because most people have it).
From the command line, run the script "excel_test.py" below. It attaches to the running Excel application and tries to call a non-existent method hi(). An exception is thrown and the script will exit, as expected.
import win32com.client as w32c

# Attach to a running Excel
app = w32c.GetActiveObject("Excel.Application")

# This will throw an exception
app.hi()

print("done")

Quit Excel manually by closing it via the UI. Note in the task manager that the Excel.exe process has shut down. This is all as expected.
Repeat the same steps but run the script using VSCode debug mode. When the exception is thrown the debugger halts execution. Press the Stop button on the debugger tool bar to terminate the script. After quitting Excel, notice that the UI has shutdown, but the Excel.exe process is still running. You now have a zombie process.
Following this same pattern in PyCharm debug mode works fine, the process goes away as expected.
Somehow it appears that VSCode is not properly releasing the COM object reference when exiting debug mode. Am I missing some weird setting or something, or is it just broken?
I'm running Python 3.9.12, pywin32 302, VSCode 1.70.2.
This may be related to https://github.com/microsoft/vscode/issues/65288 and https://github.com/microsoft/vscode/issues/24779.
VS Code version: Code 1.70.2 (e4503b30fc78200f846c62cf8091b76ff5547662, 2022-08-16T05:35:13.448Z)
OS version: Windows_NT x64 10.0.22000
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz (20 x 3696)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.90GB (17.48GB free)

Process Argv
C:\Users\tj\OneDrive - Exa Research\Training\ODTK\Integrating\Exercises --crash-reporter-id 07d7cc17-f9d3-4972-9a41-087017e04f32

Screen Reader
no

VM
0%

Extensions (24)

Extension
Author (truncated)
Version

TabOut
alb
0.2.1

doxdocgen
csc
1.4.0

vbscript
Dar
1.0.4

gitlens
eam
12.1.2

better-cpp-syntax
jef
1.15.19

vsc-python-indent
Kev
1.17.0

rainbow-csv
mec
2.4.0

csharp
ms-
1.25.0

python
ms-
2022.12.1

vscode-pylance
ms-
2022.8.30

jupyter
ms-
2022.7.1102252217

jupyter-keymap
ms-
1.0.0

jupyter-renderers
ms-
1.0.9

remote-containers
ms-
0.245.1

remote-ssh
ms-
0.84.0

remote-ssh-edit
ms-
0.80.0

remote-wsl
ms-
0.66.3

cmake-tools
ms-
1.11.26

cpptools
ms-
1.11.5

cpptools-extension-pack
ms-
1.2.0

vscode-pylens
nin
0.1.4

autodocstring
njp
0.6.1

vscode-qt-for-python
sea
1.3.7

cmake
twx
0.0.17

(1 theme extensions excluded)

I've also opened a question on StackOverflow https://stackoverflow.com/questions/73401543/vscode-debugger-not-releasing-com-object-reference-when-a-python-script-throws-a to see if anyone else has run into this.

/extPython

It looks like this is caused by the Python extension. Please file the issue to the Python extension repository. Make sure to check their issue reporting template and provide them relevant information such as the extension version you're using. See also our issue reporting guidelines for more information.
Happy Coding!


Specifying directives by object in client-side use

Hi this is Oskar from JSFiddle,
I'm implementing JSHint for live code validation (using CodeMirror), but I can't seem to figure out if there's a way to set directives/options with a JS object for client-side use.
Is it at all possible? Looked everywhere for an answer but couldn't find anything.

Hi Oskar, sorry for the delay.
It sounds like you are looking for JSHint's JavaScript API. The documentation for that is available at http://jshint.com/docs/api/, but to summarize:

Load JSHint using your module loader of choice (or just via an HTML <script> tag
Retrieve a string containing the JavaScript program code that you would like to lint (e.g. var code = "void 0;";
Define the linting options you would like to enforce (e.g. var options = { expr: true };
Invoke the JSHint function with the code and options (e.g. JSHINT(code, options);)
Inspect the results using the data method (e.g. console.log(JSHINT.data()))

Does that help?


Final release for usage ?

Hello,
When do you plan to bump the final release ?
Thanks and regards,
Jean-Christophe.

Hello,
Any news for the final release ?
Thanks and regards,
Jean-Christophe.

@cppforlife: as JC said, we are missing a public blobstore in config/final.yml, and some final release too!

@JCL38-ORANGE : for your information I've ping-ed @cppforlife (Dimitri) yesterday and he said he would configure his CI soon and publish the blob.
In the meantime, we can integrate this blob manually : https://download.run.pivotal.io/openjdk-jdk/trusty/x86_64/openjdk-1.8.0_141.tar.gz

Sorry Jean-Christophe @JCL38-ORANGE, I gave you the JDK link from hybris/java-boshpackage whose SHA1 does not match.
Actually, Dimitry included the JRE in this BOSH Package, whose SHA1 is properly fef57709d2ca0b375a3879fe03df303afe24307f as stated in the config/blobs.yml file here.
So that is our blob!

@cppforlife any news on creating final release?

@neil-hickey back from vacation, will try to finish this up shortly.

@cppforlife Oh yes, please!

@cppforlife are there any news on this?

almost there (on wip branch), may be even will complete tomorrow for jdk 8 and 9.

Great news! Thank you Dmitriy!

Hi @cppforlife, the WIP branch looks very good!
Any news about creating a final release here, shipping OpenJDK 8 and 9 ?
(Sorry Dmitriy, but It's been 6 months since we started needing this and we can't wait anymore. If not possible within the following weeks, I'll fork gk-java-release in Gstack Github org and publish a final release there.)

putting it in ci finally...

and ci went through... v1 (https://github.com/bosh-packages/java-release/releases/tag/v1) is published. i've tried it out with my test kafka release and it seems to work.

checked in build.logs (eg https://github.com/bosh-packages/java-release/blob/master/packages/openjdk-9/build.log) also show build steps taken.

Great! Thank you @cppforlife!


Fix memory leaks

I have found a few memory leaks and bugs:

We did not properly release the AVIOContext, leaking memory
During string conversion, we need to free the allocated memory.
std::string will take a copy of the data, so it is safe to release it.
The fix for TexturePool had some issues

We cannot rely on Processed event to come. Especially on seek and shutdown, this caused leakes.
So we must cleanup samples on seek and on shutdown
Processed event can come anytime, so we need locking to access the tracks sample map

Seems stable.
This will also require some changes on the c++/winRT branch for the directx stuff (I think the string handling is OK there but I will need to double check)


Translations Batch: 2023-10-09

Request and update CiviForm translations using Transifex.
Follow the instructions at go/civiform-translations to

[x] Request a new batch of translations
[x] Upload translations into Transifex
[ ] Create a ticket for the next batch of translations, and assign to the next Google.org Works SWE

done


Fractional Share Support?

Hi! Ultimately I'd like to use this to set up a $5 buy of a stock every day, but didn't see anywhere in the documentation mentioning fractional shares.
Is it possible or are there plans for future support?
Thanks!

Nevermind, I see the library this is built on doesn't support fractional shares.


spec: update buildrequires

Target amt.h uses xxd.
In clean buildroot we would miss this dep.
Signed-off-by: Martin Styk<EMAIL_ADDRESS>

Thanks! Will look into (unrelated) travis issue another day...


Issue with techdocs metadata.name

Expected Behavior
Our backstage implementation should see our Azure container, and our test infra-demo-api has a catalog-info.yaml contains two items which match the required conventions (https://github.com/backstage/backstage/blob/master/docs/architecture-decisions/adr002-default-catalog-file-format.md)
metadata:
name: infra-demo-api
Actual Behavior
The below error is generated in kubectl logs for the pod, showing the above expected items but with spaces rather than hyphens.
catalog-info.yaml type=plugin
2022-05-27T13:02:42.620Z catalog warn Policy check failed; caused by Error: "metadata.name" is not valid; expected a string that is sequences of [a-zA-Z0-9] separated by any of [-_.], at most 63 characters in total but found "Infra Demo API". To learn more about catalog file format, visit: https://github.com/backstage/backstage/blob/master/docs/architecture-decisions/adr002-default-catalog-file-format.md type=plugin entity=api:default/infra demo api
Steps to Reproduce

Logs continue to read this
Context
I'm trying to populate the Backstage documentation page with test documentation.
Your Environment

AKS on Azure, single pod for POC.

To update, I realise that the names in there were from the original commit to that repo and are now the correct ones. How can I force backstage to update catalog?

@bourbonfgiles

To update, I realise that the names in there were from the original commit to that repo and are now the correct ones. How can I force backstage to update catalog?

So sounds like you got it fixed? @freben can you give some guidance on how to force update the catalog? if possible?

@bourbonfgiles It depends what the issue is. The catalog should update itself periodically (like, every couple of minutes, but depends on the catalog size). Are you seeing an old irrelevant entity lingering around still, or what's the symptoms you are seeing at this point?

Hi @freben
Essentially, I have to go into the DB and delete an entity previously registered in catalog-info.yaml. Simply removing from the catalog-info.yaml doesn't remove the item from the DB. Unsure if this is expected behaviour or not.

That it doesn't get removed is expected, yeah. This is the "orphaning" mechanism, where users are expected to get some fair warning that entities seem to no longer be connected to an authoritative input source. That way you can choose to either rectify the situation or delete the entity by hand if that was the intent. Otherwise you might suddenly see vast swathes of entities disappear instantly, unintentionally, for example if you rename a folder with catalog files in them or transfer a repo to a different team or so.
So the intent is that you should be able to go to the entity's page in Backstage, and see a big orphaning warning banner at the top of the page, and then go into the three-dots menu at the top right of the page and delete it.
But in this case, am I understanding it correctly that there was no entity page to visit since it never validated?

If you

register a file with an entity with a name that contains spaces
observe it fail to ingest properly
change the file contents such that the name no longer has spaces
wait for another ingestion round to happen

then yes, I expect the outcome to be

the old improper entity might linger around the database (this actually depends on circumstances)
the updated proper entity should appear in the database

Essentially when you change a name, to the ingestion it looks like a completely new entity with no relation to the old one. There's no "replacement"/"moves" across renaming. The reason for this is that the name is actually part of the ID. From a technical standpoint, when we see something disappear and something new+changed to appear, there's no way for us to know for sure whether the user intent was a move or a delete + add. So we take the defensive stance and treat is as "don't know" + "added", which is non-destructive so to speak.

Understood, thanks Freben!


Adding easy way to share projects with a single file

This task is automatically imported from the old Task Issue Board and it was originally created by Greg Ociepka.
Original issue is here.

As a user I want to be able to open Enso projects from a single file that I can easily share with others.
After double-click on the received file it should unpack to the Enso projects folder and open in Enso.
The suggestion is an ensa file type. This would just be a zip file containing the src, data and project.yaml.
There is no requirement on this ticket for IDE to write these (just consume), this is to allow us to post blogs and demos with sample projects.

After double-clicking on .enso file project should open in the application
Option to zip the project (whole folder) to file .enso-project
After double-clicking on .enso-project it should be unzipped to the right folder and be run in the application

Root prilileges are required to install; This is so stupid :(

@sylwiabr You can give this a try: https://github.com/enso-org/enso/actions/runs/4521196938?pr=6077
See the PR description for details.


Adds new section for Known Issues to Release Notes.

Docker-DCO-1.1-Signed-off-by: Fred Lifton<EMAIL_ADDRESS>(github: fredlf)
This is adds a new section to Release Notes for Known Issues. It is not meant to be an exhaustive list, but rather a list of significant, long-lived issues in Docker (not Hub) that commonly impact users. I need help identifying more issues. @SvenDowideit , @jpetazzo , @kencochrane, @nchazlett, anything you guys can think of would help.

I recon LGTM, and additional things should go in follow on PR's :)
@jamtur01


Documentation: TOC links in Best Practices page links to reference instead of the heading

https://docs.docker.com/articles/dockerfile_best-practices
To the right of the page is a TOC listing the major headings "On this page:". The first half of the TOC is ok. The bottom half includes the best practices for commands (FROM, RUN, CMD, ... etc) and these links to the references. eg. https://docs.docker.com/reference/builder/#from instead of the actual heading/section on the page.
This behaviour makes it difficult to navigate and jump to the specific heading/section by using the TOC.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@charleswhchan Thank you for the report. Stumbled upon this few days ago, I'll submit a fix :wink:.
/cc @thaJeztah @moxiegirl


Handle explicit GP coefficients

This PR enables creating BasisGP(..., coefficients=True) objects that treat Gaussian process coefficients explicitly. The coefficients option can be given also to the specialized FourierBasisGP, TimingModel, EcorrBasisModel.
That is, the values of the coefficients must be provided as a numpy array among the parameters (with autogenerated names like B1855+09_red_noise_coefficients), and the resulting TOA delays are returned by Signal.get_delay() instead of (implicitly) Signal.get_basis(). The vector coefficient parameters are generated as part of Signal initialization, and are included in Signal.params; they carry the correct GP prior derived from the prior furnished to BasisGP.
Explicit GP coefficients allow sampling the hierarchical PTA likelihood (as useful, e.g., in cross-validation schemes).
Comments:

Currently coefficients are not supported for common GPs (such as GWs).
Currently GP coefficients cannot be sampled consistently with parameter.sample(). However the function utils.get_coefficients(pta, params) samples all coefficient vectors from the conditional distribution induced by their GP hyperparameters.
To harmonize the naming of parameters, all GPs now carry a default name (such as red_noise); thus the parameter that may have been called B1855+09_log10_A is now B1855+09_red_noise_log10_A).

The checks are failing here because of a bug in the most recent version of numpy. https://github.com/gwastro/pycbc/issues/2402

We can patch this by restricting numpy to versions before the most recent: https://github.com/gwastro/pycbc/commit/17fa90d1e5b251a86caff29bc4bc302fe35a667a

A simple change to numpy>=1.14.1,<1.15.3 would suffice to patch this until a newer numpy version plays well with astropy. We can then merge these changes.

Thanks @stevertaylor. Applying your workaround now.


Script execution progress / Warnings and Errors

Thanks a lot for this great Software; I'm quite new to DBeaver but making very good progress, e.g. the software design and the manual are really excellent work!
Actually I'm working on the transfer of a database to PostgreSQL: The Insert-Script is about 500 MB, so I'm running it from Database > RunScript.  My problem: I can't find potential Errors or Warnings due to the huge number of "Insert 0 1" lines. Tried to copy and paste the protocol to a text editor, but could not find a method for copying (f.e. CTRL-C), only SelectAll (CTRL-A) works.
How can I check if there are any important lines in this output?
Thanks and regards, Michael
System information:

Operating system (distribution) and version kUBUNTU 18.04
DBeaver version: 6.0.0
Driver: PostgreSQL JDBC

Found, that all error-messages can be found in the LOG-file in /var/log/postgresql/. This works for me.


[FEATURE] Upgrade file_picker to version 5.x.x

Hello, now most of the plugins that depend on ffi have been upgraded to ffi v2.0, and the version used by html-editor-enhanced -> file_picker(v4.6.0) -> ffi(v1.1.2) is too low to be compatible with other plugins are compatible, causing conflicts.

Please help to upgrade the file_picker to version 5.x.x.
Thanks.

I have the same issue. Please emphasis on pushing this out.

Done


Use yamlfmt instead of prettier to format YAML

Fixes #555

📚 Documentation preview 📚: https://earthaccess--568.org.readthedocs.build/en/568/

Integration test failures look ignorable. They're happening everywhere, and this PR doesn't touch anything that could affect runtime.

Integration test failures look ignorable. They're happening everywhere, and this PR doesn't touch anything that could affect runtime.

Weird.

Integration test failures look ignorable. They're happening everywhere, and this PR doesn't touch anything that could affect runtime.

Looks like this was a transient problem. All are passing now.

There's something bigger going on here. For the last 22 minutes, I was unable to connect to any Google services from my home ISP, but my mobile ISP was fine. Just came back now.

@mfisher87, this is ready for your eyes again. I pulled in the additional changelog entry from the other PR that I just merged into main, so the indentation issue you identified is fixed.


ocamlPackages.buildDunePackage: add support for dune 3 (w/ related additions & updates)

Description of changes
Motivated by https://github.com/NixOS/nixpkgs/pull/163766#issuecomment-1066100292 & #164287
This adds a new argument duneVersion to buildDunePackages that have precedence over useDune2. It can be used to choose which version of dune to use.
This PR (as a show case) makes stog use dune 3 (it just works).
This adds a few dune-3 related libraries.
This updates dune-related libraries that were already packaged.
cc @AllanBlanchard @marsam
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

ping @sternenseemann, in case he’s interested & did not notice.

@GrahamcOfBorg build stog

Well spotted. Will do.

The manual has just been updated.


Scan Page https://sara-sabr.github.io/ITStrategy/comment-contribuer.html for accessibility issues

Scan this page using axe to see if there are any accessibility issues

no issues found


Feature set description

[ ] User Stories (DMX, manual, WiFi?)
[ ] Communication Features (485, DoDC)
[ ] Electronics Features (LEDs, Enable All, Fan, I2C(Temp Sensor), Buttons, External port switch, WS LEDs, Encoder, SD Card)
[ ] Manufacturing/Calibration features

Internal/external port pinout and selector logic

Port pinouts:

i2c address for the LM75B is 78dec


How to cancel downloading media such as videos when navigating away

Library Affected:
workbox 5.1.4 (via next-offline 5.0.5)
Browser & Platform:
Google Chrome  90.0.4430.85
Issue:
When running without the service worker, fetch requests made by the browser are automatically canceled when the DOM element that contains a video or an image is removed from the DOM.
With the service worker running, it starts streaming the entire files even when you navigate away from the element (such as a large video).
This can end up in situations where you can download a lot of things in the background.
The following screenshot illustrate the issue:

How could we mitigate that or simply filter out media from the service worker with workbox options?
My current settings are the following (but I'm feeling a bit lost):
	workboxOpts: {
		swDest: process.env.NEXT_EXPORT
		? 'service-worker.js'
		: 'static/service-worker.js',
		exclude: [/_error.*/, /admin.*/, /signin.*/, 'react-loadable-manifest.json', 'build-manifest.json', "_buildManifest.js"],
		navigateFallbackDenylist: [/_error.*/, /admin.*/, /signin.*/],
		// As of Workbox v5 Alpha there isn't a well documented way to move workbox runtime into the directory
		// required by Next. As a work around, we inline the tree-shaken runtime into the main Service Worker file
		// at the cost of less cacheability
		inlineWorkboxRuntime: true,
		runtimeCaching: [
			{
				urlPattern: /^https?.*/,
				handler: 'NetworkFirst',
				options: {
					cacheName: 'offlineCache',
					expiration: {
						maxEntries: 300
					}
				}
			},
			{
				urlPattern: /\.(?:jpeg|webp)$/,
				handler: 'cacheFirst',
				options: {
					cacheName: 'offlineCache',
					expiration: {
						maxEntries: 300
					}
				}
			}
		]
	},

Hello @PlopTheReal!
I'm not sure what the right solution to this is, and I'll try to dig around a bit more to see if there's something triggered by Workbox's logic, or if this is something that would be an issue for any site that used a service worker to intercept Range requests for video bytes.
Before I do that, could you clarify what you mean by "navigate away from the element"? Are you talking about a scenario in which playback starts, and then the browser makes a real navigation request to a new URL on the same site, loading an entirely new page from scratch? Or are you talking about a scenario in which playback starts, and then a SPA-style transition happens, or JavaScript is used to remove the <video> element from the DOM, but the same document stays loaded?

Thanks for such a feedback!
Sorry I was not clear, technically it's a SPA:  elements are removed / added to the DOM (same document). It's not a real navigation to a new URL.
So far the only solution that I was thinking about is excluding '.mp4' but it seems that my setup isn't working :
exclude: [/_error.*/, /\.map$/, 'react-loadable-manifest.json', 'build-manifest.json', "_buildManifest.js", /\.mp4$/],

Library Affected:
workbox 5.1.4 (via next-offline 5.0.5)
Browser & Platform:
Google Chrome  90.0.4430.85
Issue:
When running without the service worker, fetch requests made by the browser are automatically canceled when the DOM element that contains a video or an image is removed from the DOM.
With the service worker running, it starts streaming the entire files even when you navigate away from the element (such as a large video).
This can end up in situations where you can download a lot of things in the background.
The following screenshot illustrate the issue:

How could we mitigate that or simply filter out media from the service worker with workbox options?
My current settings are the following (but I'm feeling a bit lost):

	workboxOpts: {

		swDest: process.env.NEXT_EXPORT

		? 'service-worker.js'

		: 'static/service-worker.js',

		exclude: [/_error.*/, /admin.*/, /signin.*/, 'react-loadable-manifest.json', 'build-manifest.json', "_buildManifest.js"],

		navigateFallbackDenylist: [/_error.*/, /admin.*/, /signin.*/],

		// As of Workbox v5 Alpha there isn't a well documented way to move workbox runtime into the directory

		// required by Next. As a work around, we inline the tree-shaken runtime into the main Service Worker file

		// at the cost of less cacheability

		inlineWorkboxRuntime: true,

		runtimeCaching: [

			{

				urlPattern: /^https?.*/,

				handler: 'NetworkFirst',

				options: {

					cacheName: 'offlineCache',

					expiration: {

						maxEntries: 300

					}

				}

			},

			{

				urlPattern: /\.(?:jpeg|webp)$/,

				handler: 'cacheFirst',

				options: {

					cacheName: 'offlineCache',

					expiration: {

						maxEntries: 300

					}

				}

			}

		]

	},

Any update regarding this issue? It's tagged as "Need More Info". Do you need extra details?

Sorry about that!
Okay, so let's take a step back and discuss two possible approaches:
Easier: ensure that the service worker doesn't intercept your .mp4 requests.
Based on what I can see from your service worker config and Network panel traffic, I don't think your .mp4 files are being precached. It looks like that first runtime caching route you have configured, that match urlPattern: /^https?.*/, is picking up everything (since that pattern will match any URL), and applying a NetworkFirst strategy to it. You could confirm this by checking in the Cache Storage Viewer in the Applications DevTools tab—I think you'll see those URLs listed under offlineCache, not the cache used for precaching.
This also means that your second runtime caching route, urlPattern: /\.(?:jpeg|webp)$/, presumably isn't getting a chance to match anything, since the first matching route takes precedence.
If you take the route that's currently uses urlPattern: /^https?.*/ to match requests and narrow it down to something more focused, you should be able to avoid responding to .mp4 requests from your service worker at all. Can you let me know what your goal is for that route—what types of traffic were you hoping to apply a NetworkFirst strategy to? Once I know that, I should be able to offer some advice about narrowing down the criteria.
You should note that in addition to supporting RegExps, the urlPattern option can take in any function that follows the matchCallback interface. This means you could provide criteria like urlPattern: ({request}) => request.destination === 'script' to, e.g., only apply the route to requests for script files. There's more info in the guide to routing.
Harder: use abortable fetch to signal from the window context to the service worker to stop a fetch() request before all of the bytes have been transferred.
This is theoretically possible, but would require writing a lot of manual code, so it wouldn't work with your current config-based service worker generation. I'd recommend going with the first approach.

Hi there,
Workbox is moving to a new engineering team within Google. As part of this move, we're declaring a partial bug bankruptcy to allow the new team to start fresh. We realize this isn't optimal, but realistically, this is the only way we see it working. For transparency, here're the criteria we applied:

For PRs, we closed everything that doesn't target the current v7 branch.
For Issues, we closed everything that was created before 2024.

Thanks, and we hope for your understanding!
The Workbox team


Mauler does not increase two-handed weapon proficiency

The mauler dedication does not scale proficiency with simple and martial two-handed weapons, or weapons with the two handed trait to match the characters highest weapon proficiency.
for example a 7th level fighter:

(character in this example has Dwarven Weapon familiarity, so the advanced weapons should be treated as martial)

Remaster fixed this.


Install the driver binary as fab.bin, reuse it when possible, recompile it when needed

This PR alters the main driver logic so that the driver binary is saved in the user's project and reused when possible for a big performance boost. When the user's rules package changes, the driver binary detects it and rebuilds and reruns itself.
Closes #1

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

42 of 59 (71.19%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+20.08%) to 68.904%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

runner.go
10
12
83.33%

compile.go
31
46
67.39%

Totals

Change from base Build<PHONE_NUMBER>:
20.08%

Covered Lines:
616

Relevant Lines:
894

💛  - Coveralls


Where is the litw_annotation.py file?

Hi everyone, I'm trying to use this dataset but I can't find the litw_annotation.py file to generate the txt file, where can I find it?

Hey, you can find at src/litw_annotation.py in the repo


Bug: Break frame not working properly on stm32f4 U(S)ART

I am using an SRF01 ultrasonic rangefinder (http://www.robot-electronics.co.uk/htm/srf01tech.htm) with PIXHAWK. The rangefinder has a single-wire serial connection which can be connected to the TX pin of a U(S)ART port when the port is configured into single-wire mode. The problem is that the SRF01 requires a break frame (>=12 bits) prior each measurement. The following code is used to send the break frame and it simply does not work.
ioctl(fd_UART, TIOCSBRK,0);
usleep(2000);
ioctl(fd_UART, TIOCCBRK,0);
in which the fd_UART is the file descriptor of the UART.
Because of this, I found that the stm32 serial driver in nuttx was not implemented properly for the 'break frame' and the following is the description.
In file Nuttx/nuttx/arch/arm/src/stm32/stm32_serial.c, from line 1908 to 1927, the code is as follows.
#ifdef CONFIG_USART_BREAKS
case TIOCSBRK:  /* BSD compatibility: Turn break on, unconditionally */
{
irqstate_t flags = irqsave();
uint32_t cr2 = up_serialin(priv, STM32_USART_CR2_OFFSET);
up_serialout(priv, STM32_USART_CR2_OFFSET, cr2 | USART_CR2_LINEN);
irqrestore(flags);
}
break;
case TIOCCBRK:  /* BSD compatibility: Turn break off, unconditionally */
  {
    irqstate_t flags;
    flags = irqsave();
    uint32_t cr1 = up_serialin(priv, STM32_USART_CR2_OFFSET);
    up_serialout(priv, STM32_USART_CR2_OFFSET, cr2 & ~USART_CR2_LINEN);
    irqrestore(flags);
  }
  break;

#endif
First, there is a typo in this code on line 1922, i.e.
uint32_t cr1 = up_serialin(priv, STM32_USART_CR2_OFFSET);
cr1 should be cr2. Then, according to the Reference Manual of STM32F4XX MCUs (http://www.st.com/st-web-ui/static/active/cn/resource/technical/document/reference_manual/DM00031020.pdf, page 1004,1005), two registers CR1 and CR2 are needed in order for the UART to send the break frame. Specifically, the SBK bit in CR1 and the LINEN bit in CR2 should be used together. Apperantly, the above code only set/unset the LINEN bit in CR2.
The modified code is as follows and with it the SRF01 sensor functions properly.
#ifdef CONFIG_USART_BREAKS
case TIOCSBRK:  /* BSD compatibility: Turn break on, unconditionally */
{
irqstate_t flags = irqsave();
uint32_t cr1 = up_serialin(priv, STM32_USART_CR1_OFFSET);
up_serialout(priv, STM32_USART_CR1_OFFSET, cr1 | USART_CR1_SBK);
uint32_t cr2 = up_serialin(priv, STM32_USART_CR2_OFFSET);
up_serialout(priv, STM32_USART_CR2_OFFSET, cr2 | USART_CR2_LINEN);
irqrestore(flags);
}
break;
case TIOCCBRK:  /* BSD compatibility: Turn break off, unconditionally */
  {
    irqstate_t flags;
    flags = irqsave();
    uint32_t cr1 = up_serialin(priv, STM32_USART_CR1_OFFSET);
    up_serialout(priv, STM32_USART_CR1_OFFSET, cr1 & ~USART_CR1_SBK);
    uint32_t cr2 = up_serialin(priv, STM32_USART_CR2_OFFSET);
    up_serialout(priv, STM32_USART_CR2_OFFSET, cr2 & ~USART_CR2_LINEN);
    irqrestore(flags);
  }
  break;

#endif
Could anyone help to check whether the problem exists and whether my modification to the original code is reasonable? Thanks.
Further more, since the above code is within a macro definition CONFIG_USART_BREAKS, this definition should be added in the configuration file nuttx-configs/px4fmu-v2/nsh/defconfig, I put it after line 315 as
CONFIG_USART_BREAKS=y
This is also the reason why the typo in the original code was not found by the compiler. Due to the falsehood of the definition of CONFIG_USART_BREAKS, this section of code is eliminated by the preprocessor and not compiled.
Thanks very much.
All the best
Xiaoke Yang
<EMAIL_ADDRESS>

@teancake
Please submit a Pull request.
However I think that disabling LIN mode in the IOCTL is not a good Idea.
Also keep in mind:
The duration of the break, and the Note below

I see what you mean. Actually if I reduce the time delay in between the two IOCTLs to a certain level, the SRF01 sensor won't respond, which suggests that the break frame is not sent.
And, if the IOCTL disabling LIN mode is commented out, the sensor still works properly which is an indication that the the SBK bit has been reset. Thanks for your suggestions.
As for the duration of the break, in LIN mode the length is 13-bit, instead of 10/11 bit in the ordinary mode. See page 985 of the manual.
Cheers


added project

let's hope this works

The jshint task file paths need to be configured to include all of the js files for your project. Here's what I modified it to to get all of the relevant files: ['Gruntfile.js', '.js', '**/.js', 'public/.js', 'public/**/.js', 'src//*.js', 'test//.js', "!**/libs/.js", '!node_modules/**/*.js']
Small typo in your mongoose connection string (mongodg instead of mongodb) prevented it from running.
You only want to connect to mongodb once - by trying to connect in both app.js and in the truckRoutes.js, you'll get an error that prevents the application from running.
When you require the Truck model in in truckRoutes.js, you assign it to 'truck', but you refer to 'Truck' later when you try to use it for the '/trucks' route meaning that route just returns a 500 error.
:+1:


Add ReadMe

Add ReadMe
Related Issue: https://github.com/wso2-enterprise/open-healthcare/issues/1467

@AnjanaSenanayake we need to add .choreo folder with endpoints.yaml file in order to get the metadata ep in choreo

@AnjanaSenanayake we need to add .choreo folder with endpoints.yaml file in order to get the metadata ep in choreo

Added in https://github.com/wso2/open-healthcare-prebuilt-services/commit/46cf9a1cccda3f834fb8d4fb027e002baef29ccf


Is this package dead?

(@v1.7) pkg> add TextPlots
    Updating registry at `~/.julia/registries/General`
    Updating git-repo `https://github.com/JuliaRegistries/General.git`
ERROR: The following package names could not be resolved:
 * TextPlots (not found in project, manifest or registry)

Seems to no longer be suported. UnicodePlots.jl does work though!


camera image shows abnormally

when I run this command “roslaunch gibson-ros turtlebot_gmapping.launch” in ROS. The camera image shows like this.

but,when I just run Gibson without ros ,like "examples/demo/play_husky_camera.py" , the camera image is good.
Is it wrong when I install Gibson?
How to deal with it?

Yes, the prefilled image and depth both look correct. Double checking with @fxia22.

The problem with rgb_filled is likely to be a wrong version of pytorch is exposed to python 2.7. You can check if you are using the correct version of pytorch.

The problem with rgb_filled is likely to be a wrong version of pytorch is exposed to python 2.7. You can check if you are using the correct version of pytorch.

I install gibson from source in python2.7 for using gibson in ros.

The problem with rgb_filled is likely to be a wrong version of pytorch is exposed to python 2.7. You can check if you are using the correct version of pytorch.

My pytorch version is 0.4.1. When I change the pytorch version to 0.3.1 , it  has no effect.
I want to use gibson with ROS, I follow the  but in this line Install gibson from source _following installation guide_ in python2.7.  , I cannot open the following installation guide . So I do not know whether I install gibson successfully.
When I run the demo from GibsonEnv, I will run export PATH="/home/jaco/anaconda2/bin:$PATH" firstly and it shows good . When I run demos with ROS in gibson-ros, I wiil run export PYTHONPATH=/usr/lib/python2.7/dist-packages/:/opt/ros/kinetic/lib/python2.7/dist-packages:/home/jaco/anaconda2/envs/py27/lib/python2.7/site-packages:/home/jaco/GibsonEnv:$PYTHONPATH  firstly and  the camera image specially rgb_filled shows badly.  Does it make rgb_filled  show badly?

You installation seems to be correct.
Did you remove conda related items from PATH?
echo $PATH | grep -oP "[^:;]+" | grep conda	## Remove these paths from $PATH

For changing PYTHONPATH, don't add things before original PYTHONPATH, just added the following into an empty PYTHONPATH: /usr/lib/python2.7/dist-packages/, /opt/ros/kinetic/lib/python2.7/dist-packages(ros python libraries), <anaconda installation root>/anaconda2/envs/py27/lib/python2.7/site-packages(gibson dependencies) and <gibson root>. They need to be in PYTHONPATH in correct order.

Thanks for reply.
When I run gibson with ROS , I remove the conda PATH and run
$ echo $PATH | grep -oP "[^:;]+" | grep conda
it shows nothing in the terminal.
For the PYTHONPATH , when I open a new terminal and run echo $PYTHONPATH ,it shows nothing. Then, I add  export PYTHONPATH=/usr/lib/python2.7/dist-packages/:/opt/ros/kinetic/lib/python2.7/dist-packages:/home/jaco/anaconda2/envs/py27/lib/python2.7/site-packages:/home/jaco/GibsonEnv:$PYTHONPATH

These are the output in the terminal when I run gibson with ROS:
jaco@jaco:~$ echo $PYTHONPATH
jaco@jaco:~$ source /opt/ros/kinetic/setup.bash
jaco@jaco:~$ source catkin_ws/devel/setup.bash
jaco@jaco:~$ echo $PATH | grep -oP "[^:;]+" | grep conda
jaco@jaco:~$ export PYTHONPATH=/usr/lib/python2.7/dist-packages/:/opt/ros/kinetic/lib/python2.7/dist-packages:/home/jaco/anaconda2/envs/py27/lib/python2.7/site-packages:/home/jaco/GibsonEnv:$PYTHONPATH
jaco@jaco:~$ echo $PYTHONPATH/usr/lib/python2.7/dist-packages/:/opt/ros/kinetic/lib/python2.7/dist-packages:/home/jaco/anaconda2/envs/py27/lib/python2.7/site-packages:/home/jaco/GibsonEnv:/opt/ros/kinetic/lib/python2.7/dist-packages
jaco@jaco:~$ roslaunch gibson-ros turtlebot_gmapping.launch
... logging to /home/jaco/.ros/log/b1e0a61e-f82f-11e8-b960-4cedfb67e5ad/roslaunch-jaco-6012.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://jaco:37093/
SUMMARY
PARAMETERS

/cmd_vel_mux/yaml_cfg_file: /opt/ros/kinetic/...
/depthimage_to_laserscan/output_frame_id: /camera_depth_frame
/depthimage_to_laserscan/range_min: 0.45
/depthimage_to_laserscan/scan_height: 2
/robot/name: turtlebot
/robot/type: turtlebot
/robot_description: <?xml version="1....
/robot_state_publisher/publish_frequency: 5.0
/rosdistro: kinetic
/rosversion: 1.12.14

NODES
/
cmd_vel_mux (nodelet/nodelet)
depthimage_to_laserscan (depthimage_to_laserscan/depthimage_to_laserscan)
gibson_clock (gibson-ros/simulation_clock.py)
joint_state_publisher (joint_state_publisher/joint_state_publisher)
mobile_base_nodelet_manager (nodelet/nodelet)
robot_state_publisher (robot_state_publisher/robot_state_publisher)
rviz (rviz/rviz)
slam_gmapping (gmapping/slam_gmapping)
turtlebot_gibson_sim (gibson-ros/turtlebot_rgbd.py)
auto-starting new master
process[master]: started with pid [6023]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to b1e0a61e-f82f-11e8-b960-4cedfb67e5ad
process[rosout-1]: started with pid [6036]
started core service [/rosout]
process[joint_state_publisher-2]: started with pid [6052]
process[turtlebot_gibson_sim-3]: started with pid [6054]
process[gibson_clock-4]: started with pid [6055]
process[robot_state_publisher-5]: started with pid [6056]
process[rviz-6]: started with pid [6057]
process[mobile_base_nodelet_manager-7]: started with pid [6063]
process[cmd_vel_mux-8]: started with pid [6071]
process[depthimage_to_laserscan-9]: started with pid [6082]
process[slam_gmapping-10]: started with pid [6100]
/home/jaco/anaconda2/envs/py27/lib/python2.7/site-packages/requests/init.py:91: RequestsDependencyWarning: urllib3 (1.23) or chardet (2.3.0) doesn't match a supported version!
RequestsDependencyWarning)
/home/jaco/anaconda2/envs/py27/lib/python2.7/site-packages/requests/init.py:83: RequestsDependencyWarning: Old version of cryptography ([1, 2, 3]) may cause slowdown.
warnings.warn(warning, RequestsDependencyWarning)
pybullet build time: Nov 28 2018 20:30:15
pygame 1.9.4
Hello from the pygame community. https://www.pygame.org/contribute.html
/home/jaco/catkin_ws/src/gibson-ros/turtlebot_rgbd.yaml
startThreads creating 1 threads.
starting thread 0
started thread 0
argc=2
argv[0] = --unused
argv[1] = --start_demo_name=Physics Server
ExampleBrowserThreadFunc started
X11 functions dynamically loaded using dlopen/dlsym OK!
X11 functions dynamically loaded using dlopen/dlsym OK!
Creating context
Created GL 3.3 context
Direct GLX rendering context obtained
Making context current
GL_VENDOR=NVIDIA Corporation
GL_RENDERER=GeForce GTX 1080/PCIe/SSE2
GL_VERSION=3.3.0 NVIDIA 415.18
GL_SHADING_LANGUAGE_VERSION=3.30 NVIDIA via Cg compiler
pthread_getconcurrency()=0
Version = 3.3.0 NVIDIA 415.18
Vendor = NVIDIA Corporation
Renderer = GeForce GTX 1080/PCIe/SSE2
b3Printf: Selected demo: Physics Server
startThreads creating 1 threads.
starting thread 0
started thread 0
MotionThreadFunc thread started
ven = NVIDIA Corporation
WARN: gym.spaces.Box autodetected dtype as <type 'numpy.float32'>. Please provide explicit dtype.
WARN: gym.spaces.Box autodetected dtype as <type 'numpy.float32'>. Please provide explicit dtype.
WARN: gym.spaces.Box autodetected dtype as <type 'numpy.float32'>. Please provide explicit dtype.
Processing the data:
Total 1 scenes 0 train 1 test
Indexing
number of devices found 1
0%|                                                     | 0/1 [00:00<?, ?it/s]Loaded EGL 1.5 after reload.
GL_VENDOR=NVIDIA Corporation
GL_RENDERER=GeForce GTX 1080/PCIe/SSE2
GL_VERSION=4.6.0 NVIDIA 415.18
GL_SHADING_LANGUAGE_VERSION=4.60 NVIDIA
finish loading shaders
100%|█████████████████████████████████████████████| 1/1 [00:00<00:00,  5.24it/s]
100%|█████████████████████████████████████████| 190/190 [00:20<00:00,  9.05it/s]
{'model_id': 'space7', 'is_discrete': False, 'random': {'random_initial_pose': False, 'random_init_z_range': [-0.1, 0.1], 'random_target_pose': False, 'random_init_x_range': [-0.1, 0.1], 'random_init_y_range': [-0.1, 0.1], 'random_init_rot_range': [-0.1, 0.1]}, 'ui_num': 2, 'envname': 'TurtlebotNavigateEnv', 'target_orn': [0, 0, 1.57], 'speed': {'timestep': 0.00417, 'frameskip': 10}, 'initial_pos': [-14.3, 5, 1.2], 'verbose': False, 'fov': 1.57, 'display_ui': True, 'resolution': 256, 'use_filler': True, 'target_pos': [-14.3, 45.07, 0.5], 'mode': 'gui', 'output': ['nonviz_sensor', 'rgb_filled', 'depth'], 'ui_components': ['RGB_FILLED', 'DEPTH'], 'initial_orn': [0, 0, 4.71], 'show_diagnostics': False}
Episode: steps:0 score:0
Episode count: 0
render to ui
Laser Pose= 0.0114853 0.0928093 -1.52656
render to ui
render to ui
render to ui
render to ui
render to ui
render to ui
render to ui
render to ui
render to ui
render to ui
render to ui
render to ui

Thanks, can you also show the output of source activate py27 and then pip list | grep torch?

Thanks, can you also show the output of source activate py27 and then pip list | grep torch?

jaco@jaco:~$ export PATH="/home/jaco/anaconda2/bin:$PATH"
jaco@jaco:~$ source activate py27
(py27) jaco@jaco:~$ pip list | grep torch
torch                              0.3.1
torchvision                        0.2.1
You are using pip version 10.0.1, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
(py27) jaco@jaco:~$

I see, it might be torchvision version issue, if you downgrade to 0.2.0 it might solve the problem. Can you try it? Thanks

I see, it might be torchvision version issue, if you downgrade to 0.2.0 it might solve the problem. Can you try it? Thanks

OK, Thanks.  I will try it.
But I have a question . Why does the rgb_filled shows good in gibson without ROS but shows bad in gibson with ROS?

I am not sure about it either. The issue looks like a pytorch issue because rgb_prefilled looks fine (the gibson rendering part). With ros the environment is slightly changed and pytorch might have linked to different static libraries.

@slamjie I can reproduce your issue if I upgrade torchvision to 0.2.1, I will look into this issue further.

I am not sure about it either. The issue looks like a pytorch issue because rgb_prefilled looks fine (the gibson rendering part). With ros the environment is slightly changed and pytorch might have linked to different static libraries.

Thank you very much.
I change the torchversion version to 0.2.0 and the rgb_filled shows good finally.

that's cool !!  Thanks again.


Logging in while banned by a custom BanService causes login timeout.

I am currently running

SpongeVanilla version: 3aacba43814fbc52b9498d6128c8f6c25c7f61ce
Java version: 11.0.10
Operating System: Windows 10

Issue Description
When attempting to login while banned by a custom BanService, the screen gets stuck on "Negotiating..." as shown in https://cdn.discordapp.com/attachments/539537645152239626/863985511358398474/2021-07-11_22-27-36.mp4
Potentially involved code:
https://github.com/SpongePowered/Sponge/blob/api-8/src/mixins/java/org/spongepowered/common/mixin/core/server/network/ServerLoginPacketListenerImplMixin.java#L98
https://github.com/SpongePowered/Sponge/blob/api-8/src/mixins/java/org/spongepowered/common/mixin/core/server/players/PlayerListMixin.java#L161

I just tested this using a very basic custom ban service
https://gist.github.com/dualspiral/ebc225dacb6bf48559591b15715b9ca9
I get the following:
[18:38:00] [User Authenticator #1/INFO]: UUID of player dualspiral is dfe5c2a0-28bb-4449-ac73-a95980850077
[18:38:01] [Server thread/INFO] [testban]: Ban issues in 5 seconds
[18:38:06] [Sponge-AsyncScheduler-0/INFO] [testban]: Banning.
[18:38:06] [Server thread/INFO]: Disconnecting SpongeGameProfile[uniqueId=dfe5c2a0-28bb-4449-ac73-a95980850077, name=dualspiral] (/<IP_ADDRESS>:51929)
[18:38:06] [Server thread/INFO]: com.mojang.authlib.GameProfile@106ad34[id=dfe5c2a0-28bb-4449-ac73-a95980850077,name=dualspiral,properties={textures=[com.mojang.authlib.properties.Property@7bb4e3da]},legacy=false] (/<IP_ADDRESS>:51929) lost connection: You are banned from this server.
Reason: Banned

and it works fine.
Are you passing exceptions to the future? Otherwise I'm going to need to see a test case where you can reproduce it,

(Also, sorry, as per https://github.com/SpongePowered/Sponge/commit/867d03802e28448d331c1c2a609644b6e3193d43#r53444918 there have been slight renames - so you'll need to just adjust for that)


[Bug]: Event Hooks Do Not Get Called With Next 12 + React 18

Which variants of Embla Carousel are you using?

[ ] embla-carousel (Core)
[X] embla-carousel-react
[ ] embla-carousel-vue
[ ] embla-carousel-svelte
[ ] embla-carousel-autoplay
[ ] embla-carousel-auto-scroll
[ ] embla-carousel-solid
[ ] embla-carousel-auto-height
[ ] embla-carousel-class-names
[ ] embla-carousel-docs (Documentation)
[ ] embla-carousel-docs (Generator)

Steps to reproduce
When trying to upgrade React and Next to latest versions the bug occurs when using the latest pre-release version of the libary and Next 12/13/14 + React 18. Event callbacks are called correctly with React 17.x.x and Next 12.x.x. For testing purposes it easiest to stay on Next 12, but only pump React and the issue will appear.
React 18 behaviour

Open the sandbox
Check in package.json, verify React/Next versions to be:

    "next": "^12.x.x",
    "react": "^18.x.x",
    "react-dom": "^18.x.x",

Run pnpm install if changess were needed
Restart/start dev server
Open /components/EmblaCarousel.tsx
See emblaApi.on callbacks for events inside useEffect that should log the "init" event on first render (as it does if using React 17) and for other events
Open browser console
See only "~ in effect" log.
Refresh
See only '~ in effect" log again.

React 17 behaviour

Open the sandbox
Check in package.json, verify React/Next versions to be:

    "next": "^12.x.x",
    "react": "^17.x.x",
    "react-dom": "^17.x.x",

Run pnpm install if changess were needed
Restart/start dev server
Open /components/EmblaCarousel.tsx
See emblaApi.on callbacks for events inside useEffect that should log the "init" event on first render and for other events
Open browser console
See both "~ in effect"  and "Called event init" log.

Expected Behavior
Event callbacks/hooks are called the same way with React 18/Next 14 as with React 17/Next 12
Additional Context
Tried the same example with only pure React 18 and it worked as expected. Issues come when React is pumped together with Next (as Next 13 requires React 18, they can't be done separately). This seems more like Next's issue, but I have little hope of them fixing this and would greatly appreciate it if something could be done from this side.
What browsers are you seeing the problem on?
All browsers
Version
8.0.0-rc22
CodeSandbox
https://codesandbox.io/p/devbox/next-minimal-embla-xc65tv
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues
[X] I agree to follow this project's Contributing Guidelines for bug reports

Hi @ranno-lauri,
Thanks for the report. If you're unsure something is a bug or not, you can create a discussion instead.

Hi @ranno-lauri,
Thanks for the bug report. If you're unsure something is a bug or not, you can create a discussion instead. To answer your question, there's a gotcha with the init event and embla-carousel-react. Please read this to understand it:

https://github.com/davidjerleke/embla-carousel/discussions/379#discussioncomment-3759962

As far as I can see, all other events are working as expected in your CodeSandbox. For example, if you drag the carousel and wait for it to stop, it will fire the settle event.
Best,
David

Hey @davidjerleke,
Thank you for the reply and suggestions. Tried it out and works as expected. Problem solved! Should this be included as 'gotcha' in the documentation?

@ranno-lauri thanks for confirming.
I'm not sure which solution would be optimal. I've been considering removing the init event because it feels like it has been causing more confusion than anything else 😅. For example, when using Vanilla JS, you can just run any code after invoking the EmblaCarousel() constructor and the carousel will be ready. So the init event might be redundant:
// Vanilla JS
import EmblaCarousel from 'embla-carousel'

const emblaNode = document.querySelector('.embla')
const emblaApi = EmblaCarousel(emblaNode)

console.log('INIT - Embla is ready')

// React JS
import useEmblaCarousel from 'embla-carousel-react'

export function EmblaCarousel() {
  const [emblaRef] = useEmblaCarousel({ loop: true })

  useEffect(() => {
    if (!emblaApi) return

    console.log('INIT - Embla is ready')
  }, [emblaApi])
  // ...
}

What's your thoughts about this?
Best,
David

Indeed, caused quite a bit of confusion. That's the general emotion with useEffect and React 18 has just made it worse 😆. Using useEffect instead of 'init' would be habitual for React devs. To make migrations from React 17 -> 18 easier for others, would still be useful to have the information in the documents, but add a deprecation note to the 'init' method (both in docs and in code), so new implemenations would not use it.

Thanks for your input @ranno-lauri!


Tokenization issue with pretrained model

I am trying to pretrain BART further from the huggingface checkpoint with the below command, and it seems like there is an issue with mismatched amount of arguments for _tokenize.
The command is below:
python pretrain_nmt.py -n 1  -nr 0 -g 1 --use_official_pretrained --pretrained_model facebook/bart-large --tokenizer_name_or_path facebook/bart-large --langs en --mono_src examples/data/train.en  --batch_size 8
The error is:
Using softmax temperature of 1.0
Masking ratio: 0.3
Training for: ['en']
Shuffling corpus!
Traceback (most recent call last):
File "pretrain_nmt.py", line 628, in
run_demo()
File "pretrain_nmt.py", line 625, in run_demo
mp.spawn(model_create_load_run_save, nprocs=args.gpus, args=(args,files,train_files,))         #
File "/root/yanmtt/py36/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 199, in spawn
return start_processes(fn, args, nprocs, join, daemon, start_method='spawn')
File "/root/yanmtt/py36/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 157, in start_processes
while not context.join():
File "/root/yanmtt/py36/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 118, in join
raise Exception(msg)
Exception:
-- Process 0 terminated with the following error:
Traceback (most recent call last):
File "/root/yanmtt/py36/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 19, in _wrap
fn(i, *args)
File "/root/yanmtt/pretrain_nmt.py", line 221, in model_create_load_run_save
for input_ids, input_masks, decoder_input_ids, labels in generate_batches_monolingual_masked_or_bilingual(tok, args, rank, files, train_files, ctr): #Batches are generated from here. The argument (0.30, 0.40) is a range which indicates the percentage of the source sentence to be masked in case we want masking during training just like we did during BART pretraining. The argument 3.5 is the lambda to the poisson length sampler which indicates the average length of a word sequence that will be masked. Since this is pretraining we do not do any evaluations even if we train on parallel corpora.
File "/root/yanmtt/common_utils.py", line 482, in generate_batches_monolingual_masked
iids = tok(lang + " " + masked_sentence + " ", add_special_tokens=False, return_tensors="pt").input_ids
File "/root/yanmtt/py36/lib/python3.6/site-packages/transformers-4.3.2-py3.6.egg/transformers/tokenization_utils_base.py", line 2377, in call
**kwargs,
File "/root/yanmtt/py36/lib/python3.6/site-packages/transformers-4.3.2-py3.6.egg/transformers/tokenization_utils_base.py", line 2447, in encode_plus
**kwargs,
File "/root/yanmtt/py36/lib/python3.6/site-packages/transformers-4.3.2-py3.6.egg/transformers/tokenization_utils.py", line 441, in _encode_plus
first_ids = get_input_ids(text)
File "/root/yanmtt/py36/lib/python3.6/site-packages/transformers-4.3.2-py3.6.egg/transformers/tokenization_utils.py", line 410, in get_input_ids
tokens = self.tokenize(text, **kwargs)
File "/root/yanmtt/py36/lib/python3.6/site-packages/transformers-4.3.2-py3.6.egg/transformers/tokenization_utils.py", line 342, in tokenize
tokenized_text = split_on_tokens(no_split_token, text)
File "/root/yanmtt/py36/lib/python3.6/site-packages/transformers-4.3.2-py3.6.egg/transformers/tokenization_utils.py", line 336, in split_on_tokens
for token in tokenized_text
File "/root/yanmtt/py36/lib/python3.6/site-packages/transformers-4.3.2-py3.6.egg/transformers/tokenization_utils.py", line 336, in
for token in tokenized_text
TypeError: _tokenize() takes 2 positional arguments but 5 were given
Upon some further inspection, it seems like in a commit a few days ago, this line was changed to have 4 arguments: https://github.com/prajdabre/yanmtt/blob/main/transformers/src/transformers/tokenization_utils.py#L319
However, the _tokenize function for BART tokenizer (which inherits all the way down from GPT2 I believe), takes in less arguments:
https://github.com/prajdabre/yanmtt/blob/main/transformers/src/transformers/models/gpt2/tokenization_gpt2.py#L241

Hi,
Thats because I have not made the necessary modifications to the "generate_batches_monolingual_masked" method to handle official BART and MBART tokenizers. Can you give me a few hours? Ill code it up and make push my changes.

Hi again,
Pull the latest version of the code and try the same command again. It should work. Lemme know if it doest.

Hi,
I previously thought that it was just the masking code that was the issue but it turned out that the GPT2 tokenizer did not take additional arguments which are passed by default by the code modifications I made to the tokenizer_utils methods.
Ive addressed and tested it this time.
Try the command:
python pretrain_nmt.py -n 1 -nr 0 -g 1 --use_official_pretrained --pretrained_model facebook/bart-large --tokenizer_name_or_path facebook/bart-large --langs en --mono_src examples/data/train.en --batch_size 512 --shard_files
or
python pretrain_nmt.py -n 1 -nr 0 -g 1 --use_official_pretrained --pretrained_model facebook/bart-large --tokenizer_name_or_path facebook/bart-large --langs en --mono_src examples/data/train.en --batch_size 8 --batch_size_indicates_lines --shard_files
Note that --shard_files is needed if you are running the code for the first time on unsharded data. (I know this just creates a duplicate file with the suffix 0 but I chose not to handle this case separately to keep my code simpler.)


The App Engine Flex create new wizard fails when creating a project with app.yaml

In the create new project wizard, selecting GAE flex and then “Create app.yaml” causes an error in DefaultAppEngineProjectService#generateFromTemplate that the app.yaml already exists and fails the new project creation

Looks like this happens because of:
"Assertion failed: Access to psi files should be performed only after startup activity"


Alternative worker pool for non-resource-consuming work actions

Expected Behavior
Ability to run work actions outside the normal worker pool bounded by max workers.
Current Behavior (optional)
Today at least following the public APIs any workaction created from a gradle task consumes a worker from the worker pool bounded by max workers.
Context
There are cases where a project is doing something in parallel but it doesn't actually consume local compute or IO resources. As an example, imagine running tests or deployment tasks on a remote machine.
Ideally these sorts of tasks wouldn't be bounded by the max workers setting as they don't consume any local resources but I found no such way today.

Thank you for your interest in Gradle!
This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.

This might be something we do at some point, but it's currently out of scope.

Since there might be interest in doing this one day, keeping it open for others to up-vote or relate specific issues to it.
There is however not commitment to do this in the near future.


Release/1.5.3

Codecov Report

Merging #10 into master will increase coverage by 0.09%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
+ Coverage   97.70%   97.79%   +0.09%
==========================================
  Files           5        5
  Lines         392      409      +17
==========================================
+ Hits          383      400      +17
  Misses          9        9

Impacted Files
Coverage Δ

typish/_classes.py
97.46% <100.00%> (+0.24%)
:arrow_up:

typish/_functions.py
97.78% <100.00%> (+0.02%)
:arrow_up:

typish/_meta.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Automatic remeshing doesn't work for small objects (e.g. dishtowel) - the resulting mesh has too many (unevenly distributed) vertices

In previous versions of MeshLab (2020.x.x), adaptive remeshing alleviates this problem - there are still too many vertices, but more evenly distributed.
In the latest version of MeshLab, that flag no longer works (even in the native app, not just pymeshlab) - producing the same remeshing results no matter whether the flag is on or off.

Wensi and I recently froze the pymeshlab version at 2022.12 arbitrarily. Is this an issue at that version too?


dynamodb-janusgraph-storage-backend-*.zip file not found

I'm trying to run locally the getting started , https://github.com/awslabs/dynamodb-janusgraph-storage-backend#getting-started , but when I run this step, cp server/dynamodb-janusgraph-storage-backend-*.zip src/test/resources/dynamodb-janusgraph-docker  , it says that the zip doesn't exists at server folder. The current version of docker in my machine is 17.06.0-ce-mac19  and my operating system is macOs Sierra.

When I run the command src/test/resources/install-gremlin-server.sh , I got the following out:
--2017-08-16 18:06:27--  https://github.com/JanusGraph/janusgraph/releases/download/v0.1.1/KEYS
Resolving github.com... <IP_ADDRESS>, <IP_ADDRESS>
Connecting to github.com|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/77385607/14114040-3636-11e7-9a95-91ca5bc24e3d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20170816%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170816T210546Z&X-Amz-Expires=300&X-Amz-Signature=f7e6d7a816a3366b25ca1213e03485e77bc955635ad84481e41fa762691ec1fd&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3DKEYS&response-content-type=application%2Foctet-stream [following]
--2017-08-16 18:06:27--  https://github-production-release-asset-2e65be.s3.amazonaws.com/77385607/14114040-3636-11e7-9a95-91ca5bc24e3d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20170816%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170816T210546Z&X-Amz-Expires=300&X-Amz-Signature=f7e6d7a816a3366b25ca1213e03485e77bc955635ad84481e41fa762691ec1fd&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3DKEYS&response-content-type=application%2Foctet-stream
Resolving github-production-release-asset-2e65be.s3.amazonaws.com... <IP_ADDRESS>
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4440 (4.3K) [application/octet-stream]
Saving to: ‘KEYS.1’
KEYS.1                 100%[=========================>]   4.34K  --.-KB/s    in 0s
2017-08-16 18:06:28 (36.2 MB/s) - ‘KEYS.1’ saved [4440/4440]
gpg: key A39CC3ADAEAEF36E: "Theodore Ratte Wilmes (CODE SIGNING KEY<EMAIL_ADDRESS>not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg: Signature made Thu May 11 11:19:58 2017 -03
gpg:                using RSA key A39CC3ADAEAEF36E
gpg: BAD signature from "Theodore Ratte Wilmes (CODE SIGNING KEY<EMAIL_ADDRESS>

I used the most recent versions of MacOS X and Docker on the HEAD commit of master branch and I was not able to reproduce this issue. Specifically, when running src/test/resources/install-gremlin-server.sh, I got the following output:
gpg: key A39CC3ADAEAEF36E: public key "Theodore Ratte Wilmes (CODE SIGNING KEY<EMAIL_ADDRESS>imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Signature made Thu May 11 23:19:58 2017 JST
gpg:                using RSA key A39CC3ADAEAEF36E
gpg: Good signature from "Theodore Ratte Wilmes (CODE SIGNING KEY<EMAIL_ADDRESS>[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: D3C9 5553 EE39 B05E 350D  959C A39C C3AD AEAE F36E

The above suggests that the signature was OK. Please try again.

Closing this issue as I was not able to reproduce. If you can give me the exact steps to reproduce, please add them to this issue and reopen the issue.


Restrict the file types which can be loaded by FileContentLoader

FileContentLoadercurrently allows to load every file. It should be restricted to Text and Markdown files.
// TODO: ONLY INCLUDE MARKDOWN FILES
if let Some(resource_id) = opt_resource_id {
    resource_id_to_endpoint.insert(resource_id, endpoint);
} else {
    warn!("Can't convert Endpoint '{:?}' to ResourceId.", &endpoint);
}

[ ]  Prepare adding this issue by doing #17  first..

Wont fix


[CLI] - Create a basic template command that takes all possible arguments

Create a basic template command that takes all possible arguments, the same way we now support the docs template.
Add tests similar to docs, too.

All templates now support non-interactive, argument-defined commands.


Code quality issues in xt/examples-compilation.t

Based on commits added for  #2782.

Commented out code in the file. Remove it.
Solo is now the only option, so there's no need to call it out specifically - any instances referring to it in this text file (and in the POD and the docs) should be removed.
Some of the extra work that was being done to support the EVAL approach is not needed to run in solo mode with -c. Much of this extra code generation can be removed.
The plan for the # of tests was removed. Why? Can we add it back in?

I'm trying to remember why, probably no good reason. I'll try to add it back in.

All of these issues have been addressed with d51503be0d6b25b76a87c85fed2f68b7f9d07b09 except for the last one. I don't think it's really necessary, but I can add it if needed.

The code was trying to solve issue #2764, which was about the amount of memory. The plan needed to have all code chunks in a single array, and counting it, and then proceeding to examine all chunks in the array one by one. This obviously contributed to the memory problems, so was eliminated. I don't see a way of adding a plan back in if you don't count the chunks in advance and then work with them. If you don't want to hold them in memory, a first pass would count them, a second would actually extract and test them. That would make everything slower again. So regarding your last question, no, I don't think we can unless you think of a better way.

I have some refactoring of that test stashed away which processes every POD file in its own subtest, to have only one file's examples in memory at a time. I didn't benchmark it because #2764 was initially resolved earlier, but that would bring the test plan back in the sense that you see how many files you have left.

@taboege that's not actually a problem. The files are kept in @files so converting that into a plan could actually be done, then putting that into a subtest could be done too. But I don't see we are adding anything valuable there, other than saving the "count" we are using (to substitute it with the test number). If it does not add too much overhead, it could be done, but I see that as a different issue, and not exactly what @coke wants, which was to have a plan that includes all chunks (as it was in the beginning)

I’d rather have a plan showing files with the sub tests unknown than nothing.

Please see #2812

If everyone's OK, I think this can be closed.

Is anything else wanted?

Looks great. Thanks!

BTW, the reason I asked for a plan is because we want to catch issues when processing aborts for some reason (as we see in #2832)

Sure, I love test plans – unconditionally :-)


nextcloud-client: disable shibboleth

Motivation for this change
The expression already uses qtwebengine.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @caugner @Ma27

I made a similar PR for owncloud-client: #75206
Also notice that owncloud-client upstream has removed the feature completely: https://github.com/owncloud/client/commit/697b6b9e81031aad69e160523a2caa20d5cfeb09

nextcloud-clients upstream doesn't builds their images with this option:
https://github.com/nextcloud/desktop/blob/c7299dec78303a72192e1d4d666f91fe5798eae9/.drone.yml#L25

What does shibboleth have to do with qt at all...? :thinking:

I would guess, it servers some sort of authentication form via html+http, so you need a full browser to display it?

Interesting. I learn something new every day. :smile:

aarch64 build currently fails due to qtwebengine. Apart from this, LGTM :+1:


Enhance Post Creation API: Category, Tag Handling, and Default Fallbacks; Add Get Tags Endpoint

Description

Modified the /create-post endpoint to handle categories and tags as comma-separated strings.
Added logic to convert these strings into arrays and validate their values accordingly.
Implemented a fallback mechanism to set a default category if no categories are provided in the request.
Added a similar fallback for the author ID, allowing the system to use a default author if none is provided.
Enhanced the post creation logic to validate the provided post status, ensuring that ‘future’ posts require a date, and ‘publish’ posts cannot have a future date.
Added validation to check for duplicate post titles when creating a new post.
Updated the logic for setting default category and author. These defaults will only be applied when creating a new post ($is_update is false) and the respective fields are empty or not set.
Added the /get_tags API endpoint to retrieve a list of tags with their respective names, IDs, and post associations.
Ensured consistency in API responses for both categories and tags endpoints, maintaining a standardized format for returning data.
Addressed minor bugs related to the post creation logic and ensured better handling of edge cases (e.g., missing parameters).
Optimized category and tag string processing to avoid unnecessary transformations.

Related Jira Issue

Jira Ticket: Jira Ticket Number

Screenshots (if applicable)
(No screenshots are required for this PR)
@vplugins/vplugin @vplugins/websitepro

PostMan Collections for testing


Remove frame-size block-length restriction

While we may need to support non-stream ciphers at some point, currently our only bulk cipher is AES-GCM which has no block size restrictions.  Thus, we can (and should) remove the restriction that our frame-sizes be a multiple of 16.
https://github.com/awslabs/aws-encryption-sdk-python/blob/master/src/aws_encryption_sdk/internal/utils/__init__.py#L51
This change should be completely backwards compatible as this restriction is only enforced on the encrypt path and not the decrypt path.  As part of this change, backwards compatibility will be manually tested.
Additionally, this task will also be completed in aws-encryption-sdk-java.  See issue aws-encryption-sdk-java#42.

Base64 encoded ciphertext using a 15 byte block-size. This has been confirmed as decryptable via the aws-encryption-sdk-cli which using the python implementation internally.
AYADeM4hjbiamPp3iXnwZoz+IkQAXwABABVhd3MtY3J5cHRvLXB1YmxpYy1rZXkAREExdUJoUW0yc1hZWTk5S1NkYXJVcjRDN0x5WTlxd1o5L0JrOFhuMjdwYzdUODVMTTdtM2RaalBPZzVVV2Y5YW5WZz09AAIAB2F3cy1rbXMAS2Fybjphd3M6a21zOnVzLXdlc3QtMjo2NTg5NTY2MDA4MzM6a2V5L2IzNTM3ZWYxLWQ4ZGMtNDc4MC05ZjVhLTU1Nzc2Y2JiMmY3ZgCnAQEBAHhA84wnXjEJdBbBBylRUFcZZK2j7xwh6UyLoL28nQ+0FAAAAH4wfAYJKoZIhvcNAQcGoG8wbQIBADBoBgkqhkiG9w0BBwEwHgYJYIZIAWUDBAEuMBEEDCZX1wU5fDCyX+Am9wIBEIA7RpItoEBOjhQzvyp3zDvJTXLLX0Z+TqroeiqC2ypiSvp3qAHPcbjCUPm3otYAwf+XdaN8wmmM6Y+R25sAB2F3cy1rbXMATmFybjphd3M6a21zOmV1LWNlbnRyYWwtMTo2NTg5NTY2MDA4MzM6a2V5Lzc1NDE0YzkzLTUyODUtNGI1Ny05OWM5LTMwYzFjZjBhMjJjMgCnAQECAHhpJnHNhxTb+pGIUToV1eANxoxSoEUMxxMR4xlifYIGHQAAAH4wfAYJKoZIhvcNAQcGoG8wbQIBADBoBgkqhkiG9w0BBwEwHgYJYIZIAWUDBAEuMBEEDIbGweY+2sPfj1maeQIBEIA7Z2JiAspOWHA9TXJ9/4mpjdWzYBqQUQvC0qNGixH5CsgElkYAT94s/KBBakcuUiwqW7VNoKOyHqgyrjECAAAAAAwAAAAPAAAAAAAAAAAAAAAA24jZ+wTt58UvuUtFva6fngAAAAEAAAAAAAAAAAAAAAFfrxCiBAdIEO/fwZJvd02JIH817tj2etlH795oFlP1AAAAAgAAAAAAAAAAAAAAAnyatX/b6BJBeoqeyyo8Q+GDu8eCUo8O0xLNBuRR4Y4AAAADAAAAAAAAAAAAAAADHTAAkSsWx28tQhfv7tkPCGV33OtuV0opiXJxmHFuBgAAAAQAAAAAAAAAAAAAAARS4DUGlWVT/bCUoT9qdg9tmPOSDWhdCUvlDA/yMpabAAAABQAAAAAAAAAAAAAABaxoKhWQtMcFpX9a5GrwCFL8qabwGqH3+QERUxCUcG4AAAAGAAAAAAAAAAAAAAAGC9ALLMhdAn0dBtcWjrhAMHmeVOgfU404Dszn1Uj1qgAAAAcAAAAAAAAAAAAAAAekOpjIt2XJ0Sp01gJfrDJrmUVKps8IrliAn7SVdDSI/////wAAAAgAAAAAAAAAAAAAAAgAAAAF0R67cEXsmac8RNBnAiBILbAANmd1AGcwZQIxAMnVDGW4C9dp5NbYqz9pCqAyXfpiovB2GdsfWmivFvkGeWI2CrN8S7Sk/s+EplUS+QIwMxg7l6hVlQ+jpR/raHsYgYPPVlKUyby9DbGtzuWLLI71+iTCzC5XaLrKBPlmMpHJ


Makefile: Specify Docker build path and ignore node_modules

This PR makes make image work. I'm not sure if the produced image works but at least we get an image.
It also adds node_modules to .dockerignore since this directory is huge and there is no need to send it to the Docker daemon when building images.

fixes #31

I think Ashu had pointed it out but I am not sure what happened after that.
I use podman and it doesn't complain, maybe that;s why I never noticed it.
Anyway, good catch. I'd like only to ask for a slightly less generic title. Something along the lines of:
Makefile: Add missing dir to image target's docker command
(With generic titles things take longer to figure out later when we're scrolling through lists of similar messages)

I tried to encompass both of the commits without being too elaborate. Hope it's better now.

I think Ashu had pointed it out but I am not sure what happened after that.
I use podman and it doesn't complain, maybe that;s why I never noticed it.
Anyway, good catch. I'd like only to ask for a slightly less generic title. Something along the lines of:
Makefile: Add missing dir to image target's docker command
(With generic titles things take longer to figure out later when we're scrolling through lists of similar messages)

I tried to encompass both of the commits without being too elaborate. Hope it's better now.

I actually meant the commit's title, not the PR one. Sorry if it was not clear.

@joaquimrocha Fixed.


Components Hierarchy arrangement in architecture.yaml

Hello Tanner,
I’m working with the arch.yaml file (models/arch/1_macro/basic_analog/arch.yaml) to design a new macro for an 8-bit weight and 8-bit input MAC operation. To customize it, I added components like column_bandwidth_limiter, shift_add, and bitcell_cap from other macros.
However, I’ve noticed that changing the location of these added components within the hierarchy affects the reported Energy Efficiency and Total Energy, suggesting that component placement impacts energy results. The tutorial notes that CiMLOOP uses a container-hierarchy structure for CiM macros, but I’m unsure of the specific hierarchical guidelines needed for accurate energy calculations.
Could you provide guidance on the recommended hierarchy and placement of components to ensure precise energy estimation? Any insights into best practices for component organization in macros would also be helpful.
Thank you for your help!

Proper ordering of the container hierarchy is critical. Every component is considered to be a parent of following components and a child of previous components.
For more information on the container hierarchy representation, please see the tutorials and/or the paper. If you have something specific you'd like to model, please let me know so I can help you get the proper hierarchy for it.

Closing for inactivity. Please reopen if the issue is still active.


Git: gpg: cannot open tty `no tty': No such file or directory

When attempting to commit files with gpg signing, VSCode will show an error which is Git: gpg: cannot open tty no tty': No such file or directory` I believe that this is slightly related to issue #5065
This issue occurs on version 1.21.1, Windows 10 Version 1709. This does still occur with all extensions disabled.

Check this one: https://github.com/Microsoft/vscode/issues/46412
Might solve your issue it's all about gnu-agent setup.

#43809


How can I resolve phishing detection for facebook.

Since the css in facebook site was not working in social phish , I copied the original html of facebook and copy pasted it . I modified the code to use the login.php script provided by social phish. I hosted it in 000webhost.com then ran it . I got the login info but the page gets detected as phishing .  I read a few articles and found that there are specific strings in the page that allows the browser to detect is as phishing . Is there any way i can prevent the page from getting detected ?

how did you host it over internet i'm getting <IP_ADDRESS> ip i can't even open it on my phone !!

how did you host it over internet i'm getting <IP_ADDRESS> ip i can't even open it on my phone !!

open SocialPhish.py with you preferred text editor
search for "5000" it will bring you to:

Inicia o banco
    initDB(DATABASE)
    app.run(host="<IP_ADDRESS>", port=5000)

change host to your IP

Be aware that the displayed urls in the dashboard aren't updated so if you change IP or Port you will need to open the URL according to your changes...

Thanks
On Thu, Mar 25, 2021, 14:24 eZh3lp @.***> wrote:

how did you host it over internet i'm getting <IP_ADDRESS> ip i can't even open
it on my phone !!

open SocialPhish.py with you preferred text editor
search for "5000" it will bring you to:
 initDB(DATABASE)
 app.run(host="<IP_ADDRESS>", port=5000)

change host to your IP
Be aware that the displayed urls in the dashboard aren't updated so if you
change IP or Port you will need to open the URL according to your changes...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/UndeadSec/SocialFish/issues/272#issuecomment-806735530,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASAO6TUKE2ZRDUVWUVJH52TTFM2QJANCNFSM4YDRFPJA
.


Uncaught error multitouch gestures in iOS Safari

On multitouch gestures uncaught error is thrown.
TypeError: undefined is not an object (evaluating 'i.offset'). 30% of all uncaught errors in our app is due to coords.offset.
It seems like solution suggested by @r00ger for different problem may work as fix here https://github.com/pukhalski/tap/issues/45
Thanks

@aivarsak I can't reproduce error with multitouch on iOS 9.2.
My fix definitely helps to avoid the error but it may cause other problems. So if you will be able to reproduce issue and provide scenario it will be an argument

Issue reproduced. Multitouch triggers series of touchstart/touchend and error occurs.
Will investigate