Cannot reproduce the result

I strictly follow the guidance and train the model with
python train.py --data_path ~/data/fMRI-reconstruction-NSD/ --fmri_encoder "brainxs" --subj 1 --model_save_path train_logs/demo_single_subject/sub01_dim1024

and inference by
python inference.py --data_path ~/data/fMRI-reconstruction-NSD/ --fmri_encoder "brainx" --subj 1 --prompt "Describe this image <image> as simply as possible." --brainx_path train_logs/demo_single_subject/sub01_dim1024/last.pth --save_path evaluation/eval_caption/brainx

And evaluate it with BrainHub
python eval_caption.py ../UMBRAE/umbrae/evaluation/eval_caption/brainx/sub01_dim1024/fmricap.json  caption/test_images --references_json caption/fmri_cococap.json

However, I got
BLEU-1: 0.3903
BLEU-2: 0.1504
BLEU-3: 0.0486
BLEU-4: 0.0182
METEOR: 0.0798
ROUGE: 0.2735
CIDER: 0.0331
SPICE: 0.0155
CLIPScore: 0.4534
RefCLIPScore: 0.532

I can reproduce the results with the file https://github.com/weihaox/BrainHub/blob/main/caption/comparison/umbrae/sub01_decoded_caption.json and the checkpoint https://huggingface.co/datasets/weihaox/brainx/resolve/main/train_logs/brainx/last.pth you provided. That means the problem is in the training pipeline.
here are the train/val loss curves

This could be caused by various factors, such as package versions. I will train the model myself to see if I can reproduce the issue. In the meantime, could you provide the results and the pretrained model, and more details about configurations, including the GPU used and package versions?

Sure. Here are my package versions
absl-py==2.1.0
accelerate==0.19.0
addict==2.4.0
aiofiles==23.2.1
aiohappyeyeballs==2.4.0
aiohttp==3.10.5
aiosignal==1.3.1
annotated-types==0.7.0
anyio==4.4.0
async-timeout==4.0.3
attrs==24.2.0
bitsandbytes==0.43.3
braceexpand==0.1.7
certifi==2024.8.30
charset-normalizer==3.3.2
click==8.1.7
contourpy==1.3.0
cycler==0.12.1
dataclasses==0.6
datasets==2.21.0
dill==0.3.8
einops==0.8.0
einops-exts==0.0.4
exceptiongroup==1.2.2
fastapi==0.112.2
ffmpy==0.4.0
filelock==3.15.4
fonttools==4.53.1
frozenlist==1.4.1
fsspec==2024.6.1
gradio==4.42.0
gradio_client==1.3.0
grpcio==1.66.1
h11==0.14.0
httpcore==1.0.5
httpx==0.27.2
huggingface-hub==0.24.6
idna==3.8
importlib_metadata==8.4.0
importlib_resources==6.4.4
Jinja2==3.1.4
joblib==1.4.2
kiwisolver==1.4.5
kornia==0.7.3
kornia_rs==0.1.5
llvmlite==0.43.0
Markdown==3.7
markdown-it-py==3.0.0
MarkupSafe==2.1.5
matplotlib==3.9.2
mdurl==0.1.2
mmengine==0.10.4
mpmath==1.3.0
multidict==6.0.5
multiprocess==0.70.16
networkx==3.3
nltk==3.9.1
numba==0.60.0
numpy==2.0.2
nvidia-cublas-cu12==<IP_ADDRESS>
nvidia-cuda-cupti-cu12==12.1.105
nvidia-cuda-nvrtc-cu12==12.1.105
nvidia-cuda-runtime-cu12==12.1.105
nvidia-cudnn-cu12==<IP_ADDRESS>
nvidia-cufft-cu12==<IP_ADDRESS>
nvidia-curand-cu12==<IP_ADDRESS>
nvidia-cusolver-cu12==<IP_ADDRESS>
nvidia-cusparse-cu12==<IP_ADDRESS>
nvidia-nccl-cu12==2.20.5
nvidia-nvjitlink-cu12==12.6.68
nvidia-nvtx-cu12==12.1.105
opencv-python==<IP_ADDRESS>
orjson==3.10.7
packaging==24.1
pandas==2.2.2
pillow==10.4.0
platformdirs==4.2.2
protobuf==5.28.0
psutil==6.0.0
pyarrow==17.0.0
pycocoevalcap==1.2
pycocotools==2.0.8
pydantic==2.8.2
pydantic_core==2.20.1
pydub==0.25.1
Pygments==2.18.0
pynndescent==0.5.13
pyparsing==3.1.4
python-dateutil==2.9.0.post0
python-multipart==0.0.9
pytz==2024.1
PyYAML==6.0.2
regex==2024.7.24
requests==2.32.3
rich==13.8.0
ruff==0.6.3
safetensors==0.4.4
scikit-learn==1.5.1
scipy==1.14.1
semantic-version==2.10.0
sentencepiece==0.2.0
shellingham==1.5.4
six==1.16.0
sniffio==1.3.1
starlette==0.38.4
sympy==1.13.2
tensorboard==2.17.1
tensorboard-data-server==0.7.2
termcolor==2.4.0
threadpoolctl==3.5.0
tokenizers==0.19.1
tomli==2.0.1
tomlkit==0.12.0
torch==2.4.0
torchvision==0.19.0
tqdm==4.66.5
transformers==4.44.2
triton==3.0.0
typer==0.12.5
typing_extensions==4.12.2
tzdata==2024.1
umap-learn==0.5.6
urllib3==2.2.2
uvicorn==0.30.6
wcwidth==0.2.13
webdataset==0.2.100
websockets==12.0
Werkzeug==3.0.4
xxhash==3.5.0
yapf==0.40.2
yarl==1.9.7
zipp==3.20.1

My gpu
NVIDIA H100 80GB HBM3

I have uploaded the model weights and results to https://drive.google.com/drive/folders/1vwEu3o9e-kllu9YRgFv_KxP8Uw1tUuuW?usp=sharing.
Please let me know if you have any questions! I hope I can make your work more reproducible!

Thanks for sharing. I'm looking into it.

Hi @Boltzmachine,
The issue isn't with the training pipeline; it lies in inference.py, which was originally designed for the BrainX (cross-subject) model. I've added support for BrainXS (single-subject). Please see commit for details. The quantitative evaluation results using your provided checkpoints are as follows:
BLEU-1: 0.5776
BLEU-2: 0.3788
BLEU-3: 0.2491
BLEU-4: 0.1670
METEOR: 0.1787
ROUGE: 0.4187
CIDER: 0.5101
SPICE: 0.1162
CLIPScore: 0.6603
RefCLIPScore: 0.7184

Please have a check and let me know if it works for you.

I have also retrained the BrainXS model from scratch using the default settings. Here are the results:
BLEU-1: 0.5757
BLEU-2: 0.3789
BLEU-3: 0.2506
BLEU-4: 0.1672
METEOR: 0.1834
ROUGE: 0.4188
CIDER: 0.5206
SPICE: 0.1161
CLIPScore: 0.6657
RefCLIPScore: 0.7238

Still not working. My inference command is
 CUDA_VISIBLE_DEVICES=1 python inference.py --data_path ~/data/fMRI-reconstruction-NSD/ --fmri_encoder "brainx" --subj 1 --prompt "Describe this image <image> as simply as possible." --brainx_path train_logs/demo_single_subject/sub01_dim1024/last.pth --save_path evaluation/eval_caption/brainx

Is it correct?

Oh never mind just found I need to set --fmri_encoder to brainxs. And it works! Thanks so much!

Hello, I can't reproduce the result either. when using the last.pth you provided, I can get the correct result, but when I follow “python train.py --data_path 'nsd_data' --fmri_encoder 'brainxs' --subj 1--model_save_path 'train_logs/demo_single_subject/sub01_dim1024' ”，The result from this training is only :
BLEU-1: 0.4807
BLEU-2: 0.2732
BLEU-3: 0.1562
BLEU-4: 0.0977
METEOR: 0.1321
ROUGE: 0.3469
CIDER: 0.2367
SPICE: 0.0694
CLIPScore: 0.5830
RefCLIPScore: 0.6457

hi，the pretrained weight is as follows and I use the correct inference command.
 https://drive.google.com/file/d/1yovTukH-Hqk3MqSdEuSjnldjObq3iimi/view?usp=sharing
---Original---
From: "Weihao @.>
Date: Mon, Nov 18, 2024 17:32 PM
To: @.>;
Cc<EMAIL_ADDRESS>Subject: Re: [weihaox/UMBRAE] Cannot reproduce the result (Issue #5)
@xqoby Could you share the pretrained weight?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Please share the doc with proper access permissions. Open a new issue if possible.

Please share the document with proper access permissions. Open a new issue if possible.


Updated pom.xml file to fix build.

I was getting the following error while trying to build. Upgrading the shade plugin fixes the error.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.0:shade (default) on project elasticrawl-examples: Execution default of goal org.apache.maven.plugins:maven-shade-plugin:2.0:shade failed: A required class was missing while executing org.apache.maven.plugins:maven-shade-plugin:2.0:shade: org/sonatype/aether/graph/Dependency

I ran into this as well.


Can Apple reject the App Store upload for using rc version of Alamofire?

I am using Alamofire & AlamofireObjectMapper in a project with Swift version 5.0 & Deployment Target iOS 11.0. After 'pod install' AlamofireObjectMapper v6.2.0 got downloaded along with Alamofire v5.0.0-rc.2 and ObjectMapper v3.5.1. My question is can Apple reject the App Store upload for using rc version of Alamofire?
**Alamofire version: 5.0.0-rc.2
**AlamofireObjectMapper version: 6.2.0
**Xcode version: 11.3.1
**Swift version: 5.0
**Platform(s) running Alamofire: iOS 11 onwards (iPhone/iPad)
**macOS version running Xcode: 10.15.4

No.


Add config cache mechanism

@threepointone , can you confirm if this is the sort of thing you had in your mind?
Might be a bit overzealous to log those messages on every read/write, but this introduces a node_modules/.cache/wrangler/config-cache.json that we can all just write to with whatever we want to, to persist things that we either:

don't want to add to config, or
don't yet know how to add to config

For an example, if a user is running wrangler dev index.ts without a wrangler.toml, and they have multiple accounts for your user, we could store the account_id that they select in the prompt here, saving them from having to select it again the next time they want to run it.
If the user blows away their node_modules or switches machines, they'll need to select it again, but this is about convenience for people running commands again and again, rather than acting as an actual source-of-truth.
We (Pages) will use this to store the account_id and Pages project name in order to simplify the CF_ACCOUNT_ID=xyz wrangler pages publish <directory> --project-name=foo command everyone would ordinarily have to run every time: wrangler pages publish <directory>.

This is a great start, yup this is along the lines of what I was thinking about. We'll use the same module for plain wrangler commands too. We'll want to log read/write this only once per session (you could use a module local variable like hasMessageBeenLogged or something to track it)


Feature/add typeid

PR Overview
This PR will address the following Issue/Feature:
https://github.com/fivetran/dbt_hubspot_source/issues/106
This PR will result in the following new package version:

0.10.0 - Columns being added in the source and this package. Source was made a breaking change.
Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:

Columns added to several tables in the source, but the only tables used in this package are DEAL_PIPELINE and DEAL_PIPELINE_STAGE. Added the corresponding new ...created_at and ...updated_at columns to these tables.
Also updated the docs with these definitions.

PR Checklist
Basic Validation
Please acknowledge that you have successfully performed the following commands locally:

[x] dbt compile
[x] dbt run –full-refresh
[x] dbt run
[x] dbt test
[x] dbt run –vars (see ticket for vars used)

Before marking this PR as "ready for review" the following have been applied:

[x] The appropriate issue has been linked and tagged
[x] You are assigned to the corresponding issue and this PR
[x] BuildKite integration tests are passing

Detailed Validation
Please acknowledge that the following validation checks have been performed prior to marking this PR as "ready for review":

[x] You have validated these changes and assure this PR will address the respective Issue/Feature.
[x] You are reasonably confident these changes will not impact any other components of this package or any dependent packages.
[x] You have provided details below around the validation steps performed to gain confidence in these changes.

Validated using data provided in ticket. Ran the published package on our dataset, ran the updated package, and confirm the columns were added with no change in row count/grain.

Standard Updates
Please acknowledge that your PR contains the following standard updates:

Package versioning has been appropriately indexed in the following locations:

[x] indexed within dbt_project.yml
[x] indexed within integration_tests/dbt_project.yml

[x] CHANGELOG has individual entries for each respective change in this PR

[x] README updates have been applied (if applicable)

[ ] ~DECISIONLOG updates have been updated (if applicable)~
[x] Appropriate yml documentation has been added (if applicable)

dbt Docs
Please acknowledge that after the above were all completed the below were applied to your branch:

[x] docs were regenerated (unless this PR does not include any code or yml updates)

If you had to summarize this PR in an emoji, which would it be?

🐑

FYI i changed the base branch! i made releases/v.10.latest yesterday and merged the customer's PR into that one (it was originally v0.9.latest as i didn't see that your changes were breaking). so if you could resolve the merge conflicts around the versioning that would be great! i'm also happy to do it if it's confusing at all, i just didn't wanna go rogue and edit your branch 😄

Thanks @fivetran-jamie! Sorry I missed that you already had the release branch. I got the conflicts resolved!


Test Version 3 of the API

We're looking for Habitica developers to try out the upcoming version 3 of the API. We are hoping that we will be ready to start testing within the next two weeks, but we're collecting testers now so that we can hit the ground running. Thanks very much for considering it, and feel free to let me know if you have any questions!

Sign Up!

Just letting you know that the testing phase is now over. Version 2 of the API will be officially deactivated on July 15th.
Here is a migration guide for upgrading to version 3. If you have any questions, feel free to reach out on Github or the Aspiring Comrades Guild.

Up on this... Is this program updated ?


Freeze frame when using multiple video streams

When we start multiple video streams we're experiencing freezes. The freezes seem random, sometimes the first frame, sometimes after a few seconds.

Yes. I know. Playback and "multiple video streams" features are experimental.
I can't resolve soon.


Shutdown tweaks

See also #747

Cool. Ship it!
On Sun, Apr 8, 2018 at 11:23 AM, Tom Swirly<EMAIL_ADDRESS>wrote:

Got rid of the signal-related commit
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/748#issuecomment-379558513,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6umTG4qcV5zjJKTg0RW0lUidqYFKks5tmitrgaJpZM4TLg-O
.


xarray 0.19.0 breaks cmip6_preprocessing

Our CI is currently broken. I supect the new xarray release.
Will investigate now.

should add an "upstream" test environment to avoid this kind of thing

I do have one...but I must have been to aggressive with turning off notifications?

Is there a way to get an email notification ONLY if the scheduled CI fails?


PyLint plugin

My first PyLint plugin, it was easier than I expected (but also quite fiddly, I used pylint-django as a reference, as the Astroid docs was sorely lacking)
The tortoise.pylint module now contains two AST transforms for:

Models → _meta, id and related_name of relationships on remote model.
Fields on Models → Transforms the type to ALSO be the instantiated python typ.

This fixes nearly every case of PyLint not finding an attribute, or the attribute not following through.
+
Made Aggregate.aggregate_function point to pypika.terms.AggregateFunction instead of None, as the astract class will never be called, and this resolves issues on Aggregates.
A few other small/safe changes. (not error related)
I re-enabled pylint -E as part of make check as all "errors" are now fixed.
I also added the PyLint plugin and usage of it to the docs.

👍


E1019 Throwing False Error When GetAtt DBClusterResourceId

CloudFormation Lint Version
cfn-lint 0.66.1
What operating system are you using?
Mac
Describe the bug
When running cfn-lint, we get the following error
E1019 Parameter TestMySQLDbCluster.DBClusterResourceId for Fn::Sub not found at Resources/TestMySQLReadOnlyPolicy/Properties/PolicyDocument/Statement/0/Resource/Fn::Sub
templatepath/test.yaml:30:13

However, based on the aws docs and after ignoring the cfn-lint error, this seems like it should be valid.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-rds-dbcluster.html#aws-resource-rds-dbcluster-return-values
Expected behavior
Expecting the error not to be thrown
Reproduction template
Parameters:
  Username:
    Type: String

  Password:
    Type: String
    NoEcho: true

Resources:
  TestMySQLDbCluster:
    Type: AWS::RDS::DBCluster
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      Engine: "5.7.mysql_aurora.2.07.7"
      MasterUsername: !Ref Username
      MasterUserPassword: !Ref Password

  TestMySQLReadOnlyPolicy:
    Type: AWS::IAM::ManagedPolicy
    DependsOn: TestMySQLDbCluster
    Properties:
      Path: /
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - rds-db:connect
            Resource: !Sub "arn:aws:rds-db:${AWS::Region}:${AWS::AccountId}:dbuser:${TestMySQLDbCluster.DBClusterResourceId}/iam-readonly"

similar recent RDS attribute issue: https://github.com/aws-cloudformation/cfn-lint/issues/2343

From the registry.
readOnlyProperties": [
    "/properties/DBClusterResourceId",
    "/properties/Endpoint",
    "/properties/Endpoint/Address",
    "/properties/Endpoint/Port",
    "/properties/ReadEndpoint/Port",
    "/properties/ReadEndpoint/Address"
  ],

Going to have to patch this in.  Was hoping it made it in to the last spec but its still not there.


docs: Unable to locate package libcudnn7

URL(s) with the issue:
https://www.tensorflow.org/install/gpu#install_cuda_with_apt
Description of issue (what needs changing):
I'm following the Ubuntu 18.04 (CUDA 10.1) instructions. I've installed the NVIDIA package repositories & NVIDIA driver and rebooted. I now try to install cuda & libcudnn7:
$ sudo apt-get install --no-install-recommends \
    cuda-10-1 \
    libcudnn7=<IP_ADDRESS>-1+cuda10.1  \
    libcudnn7-dev=<IP_ADDRESS>-1+cuda10.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libcudnn7
E: Unable to locate package libcudnn7-dev

I'm running Ubuntu 18.04.5 LTS (Bionic Beaver)

I've run sudo apt-get update again (since rebooting as recommended) and now it works!

I've run sudo apt-get update (again?) and now it works!

It looks like I missed running the second sudo apt-get update in the instructions. I've run it again, and it works!


(MinIO) S3 storage problems for SVG and JSON

As already reported in other issues #4274, #2952 and #2068 there seems to be some problems with SVG and JSON files
I'm using a MinIO setup that is currently having problems with PocketBase.
credentials.go (same credentials used in two tests and a small error check utility to keep rest of the code cleaner)
package main

var (
	bucketName       = "c…t"
	region           = "e…o"
	endpoint         = "s…z"
	accessKey        = "X…Q"
	secretKey        = "O…k"
	s3ForcePathStyle = true
	objectKey        = "q…x/o…r/l…p.svg"
)

func ErrCheck(err error) {
	if err != nil {
		log.Fatalln(err)
	}
}

This examples uses aws-sdk-go directly, to check if the library can handle MinIO API correctly:
package main

import (
	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/credentials"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/s3"
	"io"
	"log"
)

func main() {
	creds := credentials.NewStaticCredentials(accessKey, secretKey, "")
	sess, err := session.NewSession(&aws.Config{
		Region:           aws.String(region),
		Endpoint:         aws.String("https://" + endpoint),
		Credentials:      creds,
		S3ForcePathStyle: aws.Bool(s3ForcePathStyle),
	})
	ErrCheck(err)
	s3Client := s3.New(sess)

	input := &s3.GetObjectInput{
		Bucket: aws.String(bucketName),
		Key:    aws.String(objectKey),
	}

	result, err := s3Client.GetObject(input)
	ErrCheck(err)
	defer result.Body.Close()

	body, err := io.ReadAll(result.Body)
	ErrCheck(err)

	log.Println("Body:", len(body), "bytes")
}

Running the code gives the following output:
I've ofc saved the file to check it's integrity. It works correctly.
❯ go run .
2024/02/02 17:15:04 Body: 118469 bytes

This example uses PocketBase Filesystem library:
package main

import (
	"github.com/pocketbase/pocketbase/tools/filesystem"
	"log"
)

func main() {
	s3, err := filesystem.NewS3(bucketName, region, endpoint, accessKey, secretKey, s3ForcePathStyle)
	ErrCheck(err)
	defer s3.Close()

	r, err := s3.GetFile(objectKey)
	ErrCheck(err)

	log.Println(r.ContentType(), r.Size())
}

Unfortunately as reported in the issues, the file appears to be empty:
❯ go run .
2024/02/02 17:09:36 image/svg+xml 0

Please provide the svg file you are testing with and a little more details about your MinIO setup (eg.the version you are testing with).
Again, I'm not able to reproduce the issue with other S3 providers. You can try it on your own for example with the Wasabi free trial https://wasabi.com/.

This is an example file I used today that's not working. Following is also the corresponding json attrs.

{
  "user.cache_control": "",
  "user.content_disposition": "",
  "user.content_encoding": "",
  "user.content_language": "",
  "user.content_type": "image/svg+xml",
  "user.metadata": {
    "original-filename": "logo.svg"
  },
  "md5": "QLT2lgPy3BqUJQcNOj7PAA=="
}

Thank you for the file sample but I still don't think this is PocketBase related.
Keep in mind that your 2 code samples are not equivavlent because as mentioned the file size is read from the attributes/head call.
In other words, to confirm that you get a valid file size with the raw aws-sdk-go implementation, please replace GetObjectInput with HeadObjectInput and check its response length:
in := &s3.HeadObjectInput{
    Bucket: aws.String(bucketName),
    Key:    aws.String(objectKey),
}
resp, err := s3Client.HeadObjectWithContext(ctx, in)
if err != nil {
    return nil, err
}

log.Println(resp.ContentLength) // this should return the same as r.Size() in PocketBase

I don't have MinIO setup at the moment to test, but will investigate it further this weekend.
And again, you can try other S3 providers (for example the wasabi free trial) and try to reproduce it with it. If you can't then most likely is a MinIO issue or some peculiarity that will need special handling.

In other words, to confirm that you get a valid file size with the raw aws-sdk-go implementation, please replace GetObjectInput with HeadObjectInput and check its response length:

Added your code right after the one I used in the example:

Output:
❯ go run .
2024/02/02 18:26:39 Body: 118469 bytes
2024/02/02 18:26:39 Len: 118469 bytes

I don't have MinIO setup at the moment to test but will try to investigate it further this weekend.
I can provide you an access key to a dedicated test bucked on my instance.

I'm not able to reproduce it using the MinIO playground (I'm not sure if that matters but I'm testing with the latest PocketBase linux binary).
Here is the S3 configuration that you could try (assuming that no one will change/delete it):
- Endpoint:  https://play.min.io
- Bucket:    pbtest123456
- Region:    us-east-1
- AccessKey: Q3AM3UQ867SPQQA43P2F
- Secret:    zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG

The provided svg file is returned for me with the correct content length (the reported Content-Length in the browser console for me is 13240).

Regarding MinIO - I've tried to investigate it further but I'm not able to reproduce it in the MinIO playground, testing with different files and configurations. Please double check that you are using the latest MinIO version as it is possible to be related for example to https://github.com/minio/minio/pull/4483 (based on https://play.min.io:9443/support/diagnostics, the reported playground version seems to be "2024-01-18T22:51:28Z").
Regarding Cloudflare R2 - I was able to reproduce the zero SVG size issue with Cloudflare R2. The issue is also reproduced with the plain aws-sdk-go library using the following minimal code sample:
package main

import (
    "log"

    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/credentials"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/s3"
)

const (
    accessKey  = "..."
    secretKey  = "..."
    region     = "..."
    endpoint   = "..."
    bucketName = "..."
    objectKey  = "..."
)

func main() {
    creds := credentials.NewStaticCredentials(accessKey, secretKey, "")
    sess, err := session.NewSession(&aws.Config{
        Region:      aws.String(region),
        Endpoint:    aws.String(endpoint),
        Credentials: creds,
    })
    if err != nil {
        log.Fatal(err)
    }
    s3Client := s3.New(sess)

    in := &s3.GetObjectInput{
        Bucket: aws.String(bucketName),
        Key:    aws.String(objectKey),
    }

    resp, err := s3Client.GetObject(in)
    if err != nil {
        log.Fatal(err)
    }

    // for some reason there is no ContentLength with the response for SVGs uploaded to R2
    log.Println(resp.ContentLength)
    log.Println(aws.Int64Value(resp.ContentLength)) // 0
}

So for R2 it is either some obscure bug with the AWS SDK or there is some peculiarity related to the R2 APIs. But in both cases I don't want and don't have time to invest in this (also keep in mind that there are plans to remove the aws-sdk-go as several users complained about the bloated binary size - https://github.com/pocketbase/pocketbase/discussions/3665).
But again, this is only for R2 and I'm not able to reproduce the issue with the MinIO playground, so make sure that your local MinIO is up to date. If you still think that it is something related to PocketBase, feel free to open a PR and will try to review it.

Just tested with aws-sdk-go-v2 and at least for Cloudflare R2 the zero ContentLength issue is fixed there:
package main

import (
    "context"
    "log"

    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/credentials"
    "github.com/aws/aws-sdk-go-v2/service/s3"
)

const (
    accessKey  = "..."
    secretKey  = "..."
    region     = "..."
    endpoint   = "..."
    bucketName = "..."
    objectKey  = "..."
)

func main() {
    ctx := context.Background()

    cred := credentials.NewStaticCredentialsProvider(accessKey, secretKey, "")

    cfg, err := config.LoadDefaultConfig(ctx,
        config.WithCredentialsProvider(cred),
        config.WithRegion(region),
        config.WithEndpointResolverWithOptions(aws.EndpointResolverWithOptionsFunc(func(service, region string, options ...interface{}) (aws.Endpoint, error) {
            return aws.Endpoint{URL: endpoint, SigningRegion: region}, nil
        })),
    )
    if err != nil {
        log.Fatal(err)
    }

    s3Client := s3.NewFromConfig(cfg)

    in := &s3.GetObjectInput{
        Bucket: aws.String(bucketName),
        Key:    aws.String(objectKey),
    }

    resp, err := s3Client.GetObject(ctx, in)
    if err != nil {
        log.Fatal(err)
    }

    log.Println(*resp.ContentLength)
}

Note that we use aws-sdk-go because aws-sdk-go-v2 is not compatible with GCS out of the box (see the revert from https://github.com/pocketbase/pocketbase/issues/2231).
I'll consider with the next release to upgrade again and will define a custom headers signing function to cover the GCS issue, but once again this is not related to MinIO (or at least not reproducable with play.min.io).


How to android deployment on device

hi,
to transfer to your Android device there are video tutorials?

http://facebook.github.io/react-native/docs/running-on-device-android.html

@facebook-github-bot stack-overflow


Artwork Image Recognition

Deep Learning Simplified Repository (Proposing new issue)
:red_circle: Project Title : Artwork Image Recognition
:red_circle: Aim : to classify 7500 artwork images belonging to 30 classes
:red_circle: Dataset : https://www.kaggle.com/datasets/cyanex1702/surreal-symphonies-a-dataset-of-diverse-art
:red_circle: Approach : Try to use 3-4 algorithms to implement the models and compare all the algorithms to find out the best fitted algorithm for the model by checking the accuracy scores. Also do not forget to do a exploratory data analysis before creating any model.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Follow Contributing Guidelines & Code of Conduct before start Contributing.

:white_check_mark: To be Mentioned while taking the issue :

Full name :
GitHub Profile Link :
Email ID :
Participant ID (if applicable):
Approach for this Project :
What is your participant role? (Mention the Open Source program)

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

Full name : Aditya Narayan Jha
GitHub Profile Link : https://github.com/aditya0929
Email ID<EMAIL_ADDRESS>Participant ID (if applicable):
Approach for this Project : using pre trained multi instance image classification models such as inceptionv3, restnet152v2 etc .
What is your participant role? (Mention the Open Source program) - ssoc-2023


Fix Explicit HTTP Internal URL issues

See https://msazure.visualstudio.com/DefaultCollection/One/_workitems/edit/2755344 for details.

@zhiliangxu : Thanks for your contribution! The author, @mikeblome, has been notified to review your proposed change.


WIP: Physics subdirectory

I did think that the current src directory should be renamed to parallel the physicsand dynamics directories, but could not come up with a good name last week. I think core is just right, though.

Any outstanding comments can go on PR #5 .


Converting main views to flask blueprints

This PR is a lot smaller in scope compared to the previous ones. More time was spent on researching conventions than actual coding.
Authorization, character creation and map view converted to Flask Blueprints. No new features added.
Closes #10

Nice looking stuff! The blueprint conversion seems nice, although I have no prior knowledge of it.

Yeah, I'm learning as I go. For some reason a part of me wants to convert the project back the way it was but I understand why Flask works well with blueprints. I still have to go through the services and move the ones that cater to a single blueprint into their respective folders.

Haven't seen the code base this mature yet, so added comments to also code prior to the changes made in this pr.

Really nice comments overall, thanks!

Commits are logical, although some of the messages might be a tad too long. Were there any reasons to not split the seemingly larger commits down? Or could the messages just have been made more brief?

Both could have been done. I myself am not bothered by large commits or long messages but will be trying to skim them down gradually as I get deeper into DX (and maybe start to write some actually good code, haha)...

@viettrung2103

Overall, Nice commit messages. About the commit messages, I think some just describe briefly what it does but not why you want to do it. However, As I understand that you are doing the refactoring, so all the commits is to serve that purpose.

Being consistent with the commit messages is an ongoing struggle. They tend to get long as some DX principles state they should be descriptive. Anyway, I suppose they could be shorter and work with the PR description and user story to make the whole more readable.

In your Issues, you mention about time consuming. How is the actual time it took compare to your estimation?

It wasn't the amount of hours we were supposed to allocate for the coding part. Overall the estimate was quite spot-on but I missed a few "bugs", mainly the one where a blueprint uses the main static folder instead of the one inside the blueprint's own folder. Solving this was one of those "don't think too complicated" kind of problem. It also didn't help that I updated my mac but forgot to restart it during this troubleshoot, which in turn messed up my proxy settings and made testing the code changes impossible.

Since I also do not know about blueprint, so may I ask why you decided to use it?

It makes the components independent and easier to use around the app. In general, everything that serves a single view in your app should be inside the respective blueprint.

Also, I notice that in all your app, you declare error = None many times. I think you can have separate function for that? like getError() return None.

Mmyeah, the solutions could be more elegant. Mostly the error gets it's value from the functions that validate form inputs. I will look into this as it's pretty much the last element left from the way the DX practice app was structured at the beginning of the course.

The blueprint looks a a nice stuff to learn, I will try to implement it in my own project.

Just make sure that you don't trust my repo to provide the only example on how to do it. I'm also still just learning.


GNSS override is ignored for waveshare_sx1302_lorawan_gateway_hat

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

What happened?
Setting  model_flags=[    "GNSS"  ] is ignored when model="waveshare_sx1302_lorawan_gateway_hat"
What did you expect?
I expected the GPS to be used.
If I set model="rak_2287", with the waveshare radio still connected, then the GPS is used, even though the GPS on the module isn't UBLOX
Steps to reproduce this issue
Steps:
Add GNSS for model_flags, set model to waveshare_sx1302_lorawan_gateway_hat and set  log_level="DEBUG"
Could you share your log output?

With model="waveshare_sx1302_lorawan_gateway_hat"
Opening SPI communication interface
Note: chip version is 0x12 (v1.2)
INFO: Configuring SX1250_0 in single input mode
INFO: using legacy timestamp
INFO: LoRa Service modem: configuring preamble size to 8 symbols
ARB: dual demodulation disabled for all SF
2024-10-13T10:46:40.964Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Getting gateway EUI
2024-10-13T10:46:40.965Z INFO  [chirpstack_concentratord_sx1302::cmd::root] Gateway ID retrieved, gateway_id: "0016c001f15d6607"
2024-10-13T10:46:40.965Z INFO  [libconcentratord::jitqueue] Initializing JIT queue, capacity: 32
2024-10-13T10:46:40.965Z INFO  [libconcentratord::events] Creating socket for publishing events, bind: ipc:///tmp/concentratord_event
2024-10-13T10:46:40.966Z INFO  [libconcentratord::commands] Creating socket for receiving commands, bind: ipc:///tmp/concentratord_command
2024-10-13T10:46:40.966Z DEBUG [chirpstack_concentratord_sx1302::handler::uplink] Starting uplink handle loop
2024-10-13T10:46:40.967Z DEBUG [chirpstack_concentratord_sx1302::handler::jit] Starting JIT queue loop
2024-10-13T10:46:40.967Z DEBUG [chirpstack_concentratord_sx1302::handler::command] Starting command handler loop
2024-10-13T10:46:40.967Z DEBUG [chirpstack_concentratord_sx1302::handler::stats] Starting stats loop, stats_interval: 30s

With model="rak_2287"
Opening SPI communication interface
Note: chip version is 0x12 (v1.2)
INFO: Configuring SX1250_0 in single input mode
INFO: using legacy timestamp
INFO: LoRa Service modem: configuring preamble size to 8 symbols
ARB: dual demodulation disabled for all SF
2024-10-13T10:37:25.920Z DEBUG [chirpstack_concentratord_sx1302::concentrator] Getting gateway EUI
2024-10-13T10:37:25.922Z INFO  [chirpstack_concentratord_sx1302::cmd::root] Gateway ID retrieved, gateway_id: "0016c001f15d6607"
2024-10-13T10:37:25.923Z INFO  [libconcentratord::jitqueue] Initializing JIT queue, capacity: 32
2024-10-13T10:37:25.923Z INFO  [libconcentratord::events] Creating socket for publishing events, bind: ipc:///tmp/concentratord_event
2024-10-13T10:37:25.924Z INFO  [libconcentratord::commands] Creating socket for receiving commands, bind: ipc:///tmp/concentratord_command
2024-10-13T10:37:25.925Z DEBUG [chirpstack_concentratord_sx1302::handler::uplink] Starting uplink handle loop
2024-10-13T10:37:25.925Z DEBUG [chirpstack_concentratord_sx1302::handler::jit] Starting JIT queue loop
2024-10-13T10:37:25.926Z DEBUG [chirpstack_concentratord_sx1302::handler::command] Starting command handler loop
2024-10-13T10:37:25.926Z DEBUG [chirpstack_concentratord_sx1302::handler::stats] Starting stats loop, stats_interval: 30s
2024-10-13T10:37:25.927Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Starting GPS loop
2024-10-13T10:37:25.927Z INFO  [chirpstack_concentratord_sx1302::handler::gps] Enabling GPS device, tty_path: /dev/ttyS2
2024-10-13T10:37:25.929Z INFO  [chirpstack_concentratord_sx1302::handler::gps] Starting GPS validation loop
2024-10-13T10:37:26.867Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-13T10:37:26.929Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.929692814s
2024-10-13T10:37:27.000Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
2024-10-13T10:37:27.002Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] GPS sync error, error: lgw_gps_sync failed
2024-10-13T10:37:27.867Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-13T10:37:27.930Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.930099601s
2024-10-13T10:37:28.000Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
2024-10-13T10:37:28.001Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] GPS sync error, error: lgw_gps_sync failed
2024-10-13T10:37:28.861Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-13T10:37:28.930Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.930370765s
2024-10-13T10:37:28.994Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
2024-10-13T10:37:29.866Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-13T10:37:29.999Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
2024-10-13T10:37:30.863Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-13T10:37:30.996Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
2024-10-13T10:37:31.859Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-13T10:37:31.991Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
2024-10-13T10:37:32.861Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-13T10:37:32.990Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS

Your Environment

Component
Version

Application Server
v?.?.?

Network Server

Gateway Bridge

Chirpstack API

Geolocation

Concentratord
v4.4.3

Side note. This is running on a Radxa Rock 5B board. Hence the strange GPS port, i2c port and GPIO allocations.
If this is an issue proving that the GPS on the waveshare hat works fine, even though it isn't Ublox, then I'll be happy to set up a PI4 to do the same tests.

The Waveshare shield does not have an U-blox GNSS module. Please note that the Semtech HAL only supports the  U-blox GNSS modules because it relies on a proprietary binary message for accurate time syncing.

@brocaar Did you read my complete report? The GPS module on the waveshare hat WORKS if I tell concentratord that I have a rak_2287. Does changing the model in the config magically change the GPS module to a UBLOX module?
As I noted in another issue a few years ago, the waveshare GNSS module has been modified to emit UBLOX time messages.
So in the end I just have to run my concentrator misconfigured, set up as a rak_2287, with incorrect power calibration or whatever that causes, just to get GPS to work?

I have tested with my Waveshare module to reproduce what you are saying, but it does not work for me. The Waveshare module only reports NMEA RMC messages. If it supports the NAV-TIMEGPS (which is a proprietary u-blox msg), it should have printed this in the logs every second and it does not:
https://github.com/chirpstack/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1302/src/handler/gps.rs#L98
This is what the Concentratord outputs:
2024-10-28T12:27:04.512Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Starting GPS loop
2024-10-28T12:27:04.512Z INFO  [chirpstack_concentratord_sx1302::handler::gps] Enabling GPS device, tty_path: /dev/ttyAMA0
2024-10-28T12:27:04.512Z INFO  [chirpstack_concentratord_sx1302::handler::gps] Starting GPS validation loop
2024-10-28T12:27:05.206Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:05.206Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] get gps coordinates failed, error: lgw_gps_get failed
2024-10-28T12:27:05.512Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.512831649s
2024-10-28T12:27:06.205Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:06.513Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.513058794s
2024-10-28T12:27:07.196Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:07.513Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.513292139s
2024-10-28T12:27:08.200Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:08.513Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.513531554s
2024-10-28T12:27:09.198Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:09.512Z DEBUG [chirpstack_concentratord_sx1302::handler::beacon] Get GPS epoch error, error: gps time reference not available
2024-10-28T12:27:09.513Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.513681444s
2024-10-28T12:27:10.197Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:10.513Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.513882843s
2024-10-28T12:27:11.205Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:11.514Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.514056621s
2024-10-28T12:27:12.205Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:12.514Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.514207036s
2024-10-28T12:27:13.197Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:13.514Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.514356456s
2024-10-28T12:27:14.196Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:14.514Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.514591285s
2024-10-28T12:27:15.200Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:15.512Z DEBUG [chirpstack_concentratord_sx1302::handler::beacon] Get GPS epoch error, error: gps time reference not available
2024-10-28T12:27:15.514Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.51482584s
2024-10-28T12:27:16.196Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:16.515Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.515028858s
2024-10-28T12:27:17.196Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
2024-10-28T12:27:17.515Z WARN  [chirpstack_concentratord_sx1302::handler::gps] GPS time reference is not valid, age:<PHONE_NUMBER>.515224301s

Config:
[concentratord]
log_level="DEBUG"
log_to_syslog=false
stats_interval="30s"
disable_crc_filter=false

[concentratord.api]
[gateway]
lorawan_public=true
model="waveshare_sx1302_lorawan_gateway_hat"
region="EU868"
model_flags=["GNSS",]
antenna_gain=2

Tested with a custom Concentratord that enables GPS for the Waveshare module.
I can not find a single source that confirms that the GNSS module should support this:
https://www.google.com/search?q=quelctel+l76+"NAV-TIMEGPS"

Strange. As that is exactly what I see:
Oct 28 15:01:30 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:30.772Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:30 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:30.907Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:31 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:31.762Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:31 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:31.900Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:32 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:32.772Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:32 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:32.907Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:33 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:33.766Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:33 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:33.902Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:34 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:34.766Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:34 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:34.901Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:35 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:35.776Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:35 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:35.911Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:36 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:36.776Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:36 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:36.912Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:37 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:37.776Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:37 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:37.912Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:38 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:38.779Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:38 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:38.914Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:39 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:39.767Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:39 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:39.903Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:40 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:40.769Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:40 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:40.905Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:41 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:41.774Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:41 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:41.909Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:42 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:42.775Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:42 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:42.910Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:43 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:43.769Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:43 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:43.905Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:44 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:44.770Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:44 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:44.906Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:45 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:45.773Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:45 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:45.908Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:46 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:46.770Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:46 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:46.905Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:47 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:47.770Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:47 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:47.905Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:48 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:48.774Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:48 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:48.909Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:49 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:49.777Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:49 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:49.913Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:50 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:50.777Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:50 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:50.912Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:50 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:50.969Z INFO  [libconcentratord::jitqueue] Duty-cyle stats: [label: M, freq_min: 868000000, freq_max: 868600000, dc_max:>
Oct 28 15:01:50 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:50.969Z INFO  [libconcentratord::jitqueue] Duty-cyle stats: [label: L, freq_min: 865000000, freq_max: 868000000, dc_max:>
Oct 28 15:01:50 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:50.969Z INFO  [libconcentratord::events] Publishing stats event, rx_received: 0, rx_received_ok: 0, tx_received: 0, tx_e>
Oct 28 15:01:51 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:51.799Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:51 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:51.934Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:52 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:52.791Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:52 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:52.926Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS
Oct 28 15:01:53 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:53.779Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing NMEA RMC
Oct 28 15:01:53 rock-5b chirpstack-concentratord-sx1302[949]: 2024-10-28T13:01:53.915Z DEBUG [chirpstack_concentratord_sx1302::handler::gps] Processing u-blox NAV-TIMEGPS

Sample output for my gps:
gps_sample.txt

Note that I got that output with:
 model="rak_2287"
 gnss_dev_path="/dev/ttyAMA0"
 com_dev_path="/dev/spidev0.0"
 sx1302_reset_pin=23
 sx1302_power_en_pin=18`

And my config:
# Concentratord configuration.
[concentratord]
  # Log level.
  #
  # Valid options are:
  #   * TRACE
  #   * DEBUG
  #   * INFO
  #   * WARN
  #   * ERROR
  #   * OFF
  log_level="DEBUG"

  # Log to syslog.
  #
  # When set to true, log messages are being written to syslog instead of stdout.
  log_to_syslog=false

  # Statistics interval.
  stats_interval="30s"

  # Disable CRC status filter.
  #
  # By default, the Concentratord will ignore received frames which do not have
  # a valid CRC. This option makes it possible to disable this filter such that
  # received frames without (valid) CRC can be analyzed.
  disable_crc_filter=false

  # Configuration for the (ZeroMQ based) API.
  [concentratord.api]
    # Event PUB socket bind.
    event_bind="ipc:///tmp/concentratord_event"

    # Command REP socket bind.
    command_bind="ipc:///tmp/concentratord_command"

# LoRa gateway configuration.
[gateway]

  # Antenna gain (dBi).
  antenna_gain=0

  # Public LoRaWAN network.
  lorawan_public=true

  # Region.
  #
  # The region of the gateway. Options:
  #  EU868, US915, CN779, EU433, AU915, CN470, AS923, AS923_2, AS923_3, AS923_4,
  #  KR923, IN865, RU864
  #
  # Not not all the gateway models implement all regions.
  region="EU868"

  # Gateway vendor / model.
  #
  # This configures various vendor and model specific settings.
  #model="rak_2287"
  #model="waveshare_sx1302_lorawan_gateway_hat"
  model="rak_2287"

  # Gateway vendor / model flags.
  #
  # Flag can be used to configure additional vendor / model features. The
  # following flags can be used:
  #
  #   Global flags:
  #     GNSS - Enable GNSS / GPS support
  #     USB  - Use USB for concentrator communication (default is SPI)
  model_flags=[
    "GNSS"
  ]

  # Time fallback.
  #
  # In case the gateway does not have a GNSS module or is unable to aquire a
  # GNSS fix, use the system-time for setting the 'time' field on RX.
  time_fallback_enabled=true

  # Device and pin configuration.
  #
  # Only set this configuration if you need to override the default
  # configuration provided by the model configuration and you know
  # the device and pin mapping. In any other case, leave this commented
  # out.
  gnss_dev_path="/dev/ttyAMA0"
  # gnss_dev_path="gpsd://localhost:2947"
  com_dev_path="/dev/spidev0.0"
  #i2c_dev_path="/dev/i2c-7"
  #sx1302_reset_chip="/dev/gpiochip3"
  sx1302_reset_pin=23
  #sx1302_power_en_chip="/dev/gpiochip3"
  sx1302_power_en_pin=18

  # LoRa concentrator configuration.
  [gateway.concentrator]

    # Multi spreading-factor channels (LoRa).
    multi_sf_channels=[
      868100000,
      868300000,
      868500000,
      867100000,
      867300000,
      867500000,
      867700000,
      867900000,
    ]

    # LoRa std channel (single spreading-factor).
    [gateway.concentrator.lora_std]
      frequency=868300000
      bandwidth=250000
      spreading_factor=7

    # FSK channel.
    [gateway.concentrator.fsk]
      frequency=868800000
      bandwidth=125000
      datarate=50000

  # Static gateway location.
  [gateway.location]

    # When set to non-zero values, the static gateway location will be reported
    # when the gateway does not have a GNSS module or when no GNSS location fix
    # is available.
    latitude=0.0
    longitude=0.0
    altitude=0

Just to be sure, I tried with your config but I can not reproduce the same output with NAV-TIMEGPS using your config.
Maybe your shield is from a different batch, that I don't know. However to support GPS I would like to see a confirmation from Waveshare that this is expected to work. Mine has a Quectel L76 module and I can find zero references that this module is supposed to support the NAV-TIMEGPS binary messages.
See below the picture of my shield + GNSS module:

I have not looked at my older hat, but the new hat on my desk has a Q76K, which might have the ublox addition?


showing old device list, unable to add new devices

Build/Submit details page URL
No response
Summary
I have some new devices that I want to add to my build. I also have an old device that I want to remove. I did all this on apple's dev site and then I've been trying to do a build with EAS. No matter what I do (revoke all certs, create new certs, etc.) I still get the device list from before I made the changes.
I've even tried to update the profiles after EAS creates them on apple's site, but it just reverts the device list to the incorrect devices when I go to do a build.
Managed or bare?
Managed
Environment
expo-env-info 1.0.5 environment info:
System:
OS: macOS 12.5.1
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.13.0 - /usr/local/bin/node
Yarn: 3.2.0 - /usr/local/bin/yarn
npm: 8.1.0 - /usr/local/bin/npm
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 16.0, macOS 12.3, tvOS 16.0, watchOS 9.0
IDEs:
Xcode: 14.0.1/14A400 - /usr/bin/xcodebuild
Expo Workflow: managed
Error output
No response
Reproducible demo or steps to reproduce from a blank project
¯_(ツ)_/¯

@dsokal I have multiple devices listed on the Apple Developer portal, but when I run eas device:create and select the import from Developer Portal option, it says All your devices registered on Apple Developer Portal are already imported to EAS.. Any other ideas for how to refresh the list?


Create docker image or something more easily deployable

Never done this before, will investigate later unless someone else would like to do the honors.

After speaking to a number of end users I don't think a conda package is the way to go. Instead I will use something more easily isolated and deployable.


Nice SDK! 🔥

Hey!
I like to occasionally look and find SDKs built with Saloon and see how people build them - I was looking through this one and thought it looked really good! Would you like me to add it Saloon's showcase section in the documentation?
Awesome work ☺

Absolutely! Thanks.

Done! https://docs.saloon.dev/conclusion/showcase


ACPI work.

I'm not saying this is right, only that it appears to do no harm.

Ok then.
LGTM

OK, just FYI, this code should not affect anyone unless they boot with -a.
And, even if you boot with -a, it should not affect you anyway, because the acpi setup now always returns 0. . I've tested both cases.


Problem I am facing while launching the bot sometimes and the sample questions

When I am trying to test the bot using the sampq command, I get the following error message:
Googling and searching WikipediaError accessing: http://www.google.com/search?nl=en&q=minky+mantel+wiki&start=0&num=10
<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:833)>
Traceback (most recent call last):
File "answer_bot.py", line 290, in
get_points_sample()
File "answer_bot.py", line 255, in get_points_sample
points, maxo = google_wiki(simq, options,neg)
File "answer_bot.py", line 223, in google_wiki
link = search_wiki[0].link
IndexError: list index out of range
Could someone please explain how to fix this issue?

I am facing the same problem. Please help!


Throttle stop after front transition

Bug Report
Hello,  here's the log link.
https://logs.px4.io/plot_app?log=f10ed9d8-4eab-4b31-962f-bd5c69178878
After transition to fw is done, the pusher throttle drops to 0 and goes back to normal, then altitude drops as throttle is zero. Check this:

I reproduced this EVERYTIME I make a front transition. Tried to modify trasition parameters but seems no use.
And I found in source code this, which might be related to the bug:

I can't fully understand what this set_idle_fw() for, could you add a few more lines of comments here?

I believe this is largely how TECS is initialized after a VTOL transition.

Later I'd like to look at having TECS in control of the throttle during transition to avoid the issue.

I would add an else to the TECS::_initialize_states function that to handle the case where of an in-air start that is not climbout mode. This would set the throttle integrator to cruise throttle.

Thanks Paul. ECL PR https://github.com/PX4/ecl/pull/372

I made a test for changes from @priseborough  https://github.com/PX4/ecl/pull/372.
The height drop problem is not that bad, however, it still exist. Here is the log:
https://logs.px4.io/plot_app?log=79bd4404-ea40-45f1-be64-99cc9de12835
So I would like to make tecs start in advance, like below, but I'm not sure if this would cause other problems, maybe you could give me some advice. @dagar

That will cause problems with integrator windup unless there is a method to clamp integrator states to initial values when TECS is not in control.
TECS demands a nose down pitch transient when it starts. What specific energy and energy rate errors are driving that demand? Are they caused by internal derivative filter switch-on transients or by a mismatch between TECS demands and initial flight condition?
For fixed wing operation TECS has a climbout mode that gives the internal filter time to settle. It is likely an equivalent mode for VTOL launches is required.

Thanks for your advice @priseborough, but I don't understand why TECS needs a nose down pitch transient?
When we start TECS just at the moment the front transition is done, all states are changed from 0 to real value, things are discontinue, if we start TECS when vehicle reaches blend speed, I suppose this would allow a few seconds for TECS to follow changes, thus less discontinue.
And I checked my log above, after front transition is done, the heigt drops due to discontinue, then pitch integrator raises rapidly to compensate that height drop.

I think it's discontinue that will accelerate integrator windup, start TECS in advance will ease that point.
Please correct me if I'm wrong, your advice will help me understand better.

TECS can be started before being in control to allow internal rate of change filters to settle, but integrator states should be held at initial values when this is being done.

This PR might help. https://github.com/PX4/Firmware/pull/8835


npm ERR! cb() never called!

OS?
Ubuntu 16.10
Versions.
Node: v5.9.1 (via nvm)
ng-cli: undefined (but it should be 1.0.0-beta.24, EDIT: so it doesn't work with earlier betas neither)
Repro steps.
Trying to install angular-cli via npm install -g angular-cli.
The log given by the failure.
npm ERR! cb() never called!

Mention any other details that might be useful.
I tried npm cache clean beforehand and also manually uninstalling and reinstalling the module with no effect. All other global and local npm installations are running just fine.

NPM version?  3 or higher is required

It's 3.7.1 I think. Definitely higher than 3. But I'll check tomorrow.

I also installed ng-cli successfully about a month earlier on the very same setup.

npm is 3.7.3.

Wait, running ng version does not work? Does it show the above version?  Does it show that log and that's it? This seems like a bug in node itself, so unless ng version actually works or you have additional log, I'll close this in favor of your issue npm/npm#15344.

No, it doesn't really install properly.


Disconnect connection and close database

First of all, many thanks for this great library.
I was wondering if duckdb_disconnect and duckdb_close are on the roadmap.
My use case would be to start a db and connection (in memory), load data, query it and shut it down again to free up the allocated memory.
(My C knowledge is non-existent otherwise I would have opened a PR)

Thanks!
Please, see similar issues, next

👋 @AlexR2D2
Just a question: since the NIF resource destructors run on the main scheduler, doesn't it have a slight issue with (unlikely) scheduler blocking?

👋 @ruslandoga  yes, you are right, this can happen. In addition, you may need to close DB explicitly, for example to send db file somebody or archive it and open new db file, thus, explicit closing can be required by business logic, so I will add this close functions to the lib. Thanks!

There was a recent discussion about this problem on Erlang forums: https://erlangforums.com/t/how-to-deal-with-destructors-that-can-take-a-while-to-run-and-possibly-block-the-scheduler/4290
Might be interesting :)


[WIP] Introduce proper deployment flow

Proposed changes
This PR introduces the deployment flow proposed in the deployment flow doc
Types of changes
What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

[ ] Non-breaking fix (non-breaking change which fixes an issue)
[ ] Breaking fix (breaking change which fixes an issue)
[ ] Non-breaking feature (non-breaking change which adds functionality)
[ ] Breaking feature (breaking change which adds functionality)
[ ] Refactor (non-breaking change which changes implementation)
[ ] Messy (mixture of the above - requires explanation!)

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[ ] I am making a pull request against the main branch (left side). Also you should start your branch off our main.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have locally run services that could be impacted and they do not present failures derived from my changes

As mentioned in the doc, the deployments flow will look like this
$ autonomy fetch some_service
$ cd some_service
$ autonomy build-images
$ autonomy deploy build
$ cd abci_build
$ docker-compose up --force-recreate

@DavidMinarsch It seems docker compose provides a python SDK on installation, we can write a wrapper around this to implement autonomy build run command (Just an idea)
For one click deployments
$autonomy deploy run TOKEN_ID PATH_TO_KEYS
This will resolve the token id from on-chain contracts, fetch the relevant service package, build the images and build the deployment.

Update
I've implemented autonomy deploy from-token command so It would be less confusing. Using this command we can build deployments for on-chain services using their token ids.
$ autonomy deploy from-token 2

neat!

Now only issue with the flow is images, right now we build images on the runtime which is not a good thing. Both of the dependency images does not require building every time we build a deployment we can just build and push them with every autonomy package release.

Yes, but let's treat this in a separate PR.

The agent runtime image has some issues as well, for example it needs to fetch the required agent twice. First when building the image and second on runtime. When building the image we fetch the agent to install the required dependencies and then on the runtime we fetch the agent for actual use. We also install base dependencies like open-aea and open-autonomy when building an image for an agent. I propose we separate it into 2 images, one is simple base autonomy image which comes with pre-installed base dependencies and derive an agent image from it. The agent image will fetch the agent, install agent dependencies, configure agent and run the agent.
The problem is that the agent dependencies are specific to an agent. So you cannot get all dependencies in the base by design.


Added missing closing tag

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Fixed issues
-

👍


Update README for RC4

maintainers, could you please merge this to make the README show correct info?


Unable to disable/delete rexray/s3fs Docker plugin

Summary
After stopping and deleting all containers that were using rexray/s3fs as volume driver, I am unable to disable/uninstall the rexray/s3fs plugin. It says "in use".
docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

docker volume ls
DRIVER               VOLUME NAME
rexray/s3fs:latest   myprefix-vol

docker plugin disable rexray/s3fs
Error response from daemon: plugin rexray/s3fs:latest is in use

Version
Rexray plugin rexray/s3fs:latest
"Description": "REX-Ray FUSE Driver for Amazon Simple Storage Service (S3FS)",
"DockerVersion": "17.11.0-ce",

docker version
Client:
 Version:      17.09.1-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:24:23 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.1-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   19e2cf6
 Built:        Thu Dec  7 22:23:00 2017
 OS/Arch:      linux/amd64
 Experimental: false

Expected Behavior
Be able to delete the plugin
Actual Behavior
It says the plugin is in use
Steps To Reproduce

Install the rexray/s3fs plugin
Create a service that uses the plugin to create a volume
Stop and delete the service
Try to disable/uninstall the plugin

Simple fix, altough not the intended use, thus this stays a bug: restart the docker service and then remove the plugin. That worked for me multiple times.

@christiaangoossens Your trick worked on one node, unfortunately not on the other:
root@frontend1:/var/lib/docker# docker plugin disable rexray/s3fs
Error response from daemon: plugin rexray/s3fs:latest is in use
root@frontend1:/var/lib/docker# docker plugin disable rexray/s3fs
Error response from daemon: plugin rexray/s3fs:latest is in use
root@frontend1:/var/lib/docker# systemctl restart docker
root@frontend1:/var/lib/docker# docker plugin disable rexray/s3fs
Error response from daemon: plugin rexray/s3fs:latest is in use
root@frontend1:/var/lib/docker# systemctl restart docker
root@frontend1:/var/lib/docker# docker plugin disable rexray/s3fs
Error response from daemon: plugin rexray/s3fs:latest is in use
root@frontend1:/var/lib/docker# systemctl restart docker
root@frontend1:/var/lib/docker# docker plugin disable rexray/s3fs
Error response from daemon: plugin rexray/s3fs:latest is in use

I'm stuck with the current installed plugin. I just need to delete and reinstall with a S3FS option that I forgot. Quite disturbing...

Just noticed there is a --force option.
That worked.

Thanks @ptemmer, can you close this if you are good?

@clintkitson If you think this is not a bug, I'll close it.

@ptemmer I believe REX-Ray is functioning as it should here. It is the docker interface that is deciding how/when to close the managed plugin. Am I missing something?


Why handleSubmit triggers asyncValidate

Are you submitting a bug report or a feature request?

What is the current behavior?

What is the expected behavior?
Sandbox Link

What's your environment?

Other information

Why handleSubmit triggers asyncValidate

...because if something in the server changed since you filled an async validated field, that could cause a conflict (like a signup form), so you can handle it before submitting.
If you would like to propose some enhancement, please open a new issue, providing more evidence to support you.
Otherwise, it's better to ask somewhere else, since here is not the best place for this.


Uninstaller does not remove 'Open Terminus Here'

Context menu still exist even when i uninstalled this app,
So i had to open my registry editor and deleted registry manually.
please consider uninstaller feature in next release.
Sorry for my bad english, and thank you for your work.

Duplicate of #682.


Pin django-tagging version

Pin version to hopefully fix "ImportError: No module named fields" error

:+1:


Microservices for video

Even Amazon can't make sense of serverless or microservices

from DHH

Rebuilding the death star of complexity

from DHH
I think it is too much to draw many conclusions from few samples. The real conclusion should be: For some tasks it does not make sense to split it into smaller services. In the Basecamp case the conclusion is that for some millions of lines projects there is at least one person that understands the codebase.
See :

https://martinfowler.com/bliki/MicroservicePremium.html
https://polylith.gitbook.io/polylith/
https://www.kamilgrzybek.com/blog/posts/modular-monolith-primer

The Only Unbreakable Law
This is taken from 48:03:
“...now things are only getting worse unfortunately. Libraries, engines, package managers, containers, virtual machines, Microservices, all of these things are ways of introducing more org charts, more boundaries between things, that cannot be optimised across, because the people cannot communicate with each other rapidly or at all.
And again, when people say that any of this is good, it’s very important to recognise that it’s not good. Objectively speaking for the end product, these are all bad, because every single one of these implies that we are under optimising our eventual product, because we have a priority decided what we will not consider to work together and to optimise together and to merge".
tengstrand

I think this is an important observation, that it has a price when dividing things in a way that you can't easily put them back together again. When he uses the word optimise, he means optimising the user experience of the end product.

http://highscalability.com/blog/2020/4/8/one-team-at-uber-is-moving-from-microservices-to-macroservic.html


prevent the creation of the "Downloads" folder

in the ee_initialize function, the out_dir folder is initialized as well.
https://github.com/giswqs/geemap/blob/0af4b82e19e6355bac6c0e068f890f707b5bbea5/geemap/common.py#L22
For macOS and windows plateform I guess it doesn't do much as the Downloads (with a capital D) folder already exists. On the other hand, in linux based plateform the downloads are stored in a downloads folder.
Every time I start a geemap I'm actually creating a Downloads folder that I never fill and that is disturbing some of my users.
Is this folder used in an automatic way by the geemap lib afterward ?
Can we think of something that allows people using linux based computer to not have a duplicate downloads folder ?

The reason for creating the Downloads folder was that many functions and tutorial examples download data to the default Downloads folder when users do not set the output folder. Anyway, I just committed code to disable the creation of the Downloads folder.


Database schema fix

Changed the models.py file to reflect the schema currently in the specs sheet.

2048 chars for original message (Not Nullable)
2048 chars for each jp message (Nullable)
2 chars for country code (Nullable)
64 chars for username (Nullalbe)

Backend branch is now gone?


[SPARK-43914][SQL] Assign names to the error class LEGACY_ERROR_TEMP[2433-2437]

What changes were proposed in this pull request?
The pr aims to assign names to the error class LEGACY_ERROR_TEMP[2433-2437].
Why are the changes needed?
Improve the error framework.
Does this PR introduce any user-facing change?
'No'.
How was this patch tested?
Exists test cases updated.

ping @MaxGekk The GA failure is unrelate to this PR.

ping @MaxGekk Rebased.

+1, LGTM. Merging to master.
Thank you, @beliefer and @cloud-fan for review.

@MaxGekk @cloud-fan Thank you for all.


feat: update contribution.md

I updated the  commit format part of the contribution.md.  I did that for someone who is new to this format and wants to read mor aboout.

oh sorry i guess I have to close and open and a new PR


Generic/UpperCaseConstantName: improve code coverage

Description
This PR improves code coverage for the Generic.NamingConventions.UpperCaseConstantName sniff. It also fixes several bugs found while working on adding tests.
This is a big PR and I wasn't sure if I should split it into multiple PRs. I decided to first open a single PR to share in a single place all the issues that I found. But I can split this into multiple PRs if you prefer.
While working on this PR, I noticed that the sniff does not support named parameters and created an issue to document it: #661.
Suggested changelog entry
Generic.NamingConventions.UpperCaseConstantName: fix false negatives when handling unconventional spacing and comments after define(
Generic.NamingConventions.UpperCaseConstantName: fix false positives when handling unconventional spacing and comments before a call to define()
Generic.NamingConventions.UpperCaseConstantName: fix false positives when a constant named DEFINE is encountered
Generic.NamingConventions.UpperCaseConstantName: fix false positives when handling attributes called define
Generic.NamingConventions.UpperCaseConstantName: use the line of the constant name instead of the line of the call to define() when displaying errors and recording metrics
Generic.NamingConventions.UpperCaseConstantName: remove special treatment for constant names that contain a double-colon
Related issues/external references
Part of https://github.com/PHPCSStandards/PHP_CodeSniffer/issues/146
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

[ ] This change is only breaking for integrators, not for external standards or end-users.

[ ] Documentation improvement

PR checklist

[x] I have checked there is no other PR open for the same change.
[x] I have read the Contribution Guidelines.
[x] I grant the project the right to include and distribute the code under the BSD-3-Clause license (and I have the right to grant these rights).
[x] I have added tests to cover my changes.
[x] I have verified that the code complies with the projects coding standards.
[ ] [Required for new sniffs] I have added XML documentation for the sniff.

FYI: I've opened issue #733 with another improvement which should be made to the sniff, but which is out of scope for this PR (and an improvement which will not be easy to make comprehensively anyhow).


ShowInTaskBar with Owned window: make consistent with WPF

Repro
var window = CreateSampleWindow();

window.ShowInTaskbar = false;

window.Show(GetWindow());

window.Loaded += (sender, args) => { window.ShowInTaskbar = true; };

Current behavior (windows only)
When the loaded event happens, it will just remove the owner window. Meaning that the dialog will go behind the main window.
I checked WPFs behavior and it definately ignores ShowInTaskBar changes in this scenario.

ShowInTaskBar = false, causes SetParent to be called and parent set to HiddenWindow.Handle, and  _hiddenWindowIsParent = true;

Show gets called, SetParent sets the new owner. all good.

ShowInTaskbar gets set to true, but because _hiddenWindowIsParent was left true, it overwrites the owner window.
casuing the issue.

Fixed behavior:
ensure _hiddenWindowIsParent is always in sync.
ShowInTaskbar is ignored and relationship maintained.

You can test this PR using the following package version. 11.0.999-cibuild0038580-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]


[Doc] Add Node.js Client Docs

Motivation
Currently, There is no official document for Node.js client.
We want to find information about Node.js client from Official docs.
Modifications
Add Node.js client docs.
Result
We can find information about Node.js client.

@Jennifer88huang
As follow above, I fix some issues. I appreciate for your suggest.
If you notice more issue, please comment to me.

@nkurihar
In 9161fc1, delete some description.
So, please review again.

@equanz Thank you very much for your efforts.

run integration tests

run integration tests


[REQUEST] Document the Python validator feature set

Additional context
This issue consist in figuring out the feature set of the Google provided python GTFS validator
code: https://github.com/google/transitfeed/tree/master/transitfeed
"documentation": https://github.com/google/transitfeed/wiki/FeedValidator
and report them in our own rules spreadsheet : https://docs.google.com/spreadsheets/d/1Qu9hoZWVPcsMf0ZwtmG6upcgjY97Sj5BXljnUrH9UlU/edit#gid=0
we need this to be able to prioritize our own implementation effort towards reaching feature parity before adding extra checks.

 Every stop time is added to StopTimes table in db. Validation performances are bad using the gtfsfactory, so Stop class is used instead.

util.py : utils for the validation

The document [Members] Error support prioritization is fully updated with Google Python Validator rules https://docs.google.com/spreadsheets/d/1vqe6wq7ctqk1EhYkgtZ0_TbcQ91vccfs2daSjn20BLE/edit#gid=0


Ablation test results do not match with those presented in the paper

Hi,
I am trying to verify the experiment results presented in the original paper. I made some changes to the code in order to perform the ablation test. My code is on https://github.com/duanqn/PRPN/tree/LMparse
diff: https://github.com/yikangshen/PRPN/compare/master...duanqn:LMparse
I'm doing the first ablation test, which is to remove parsing network and replace structured attention with normal ones.
I have run the original code on Penn Treebank dataset, getting 61.53 perplexity (which is similar to 61.98 in the paper). After removing the parsing network, I got 62.18 test PPL which is different from 64.42 in the paper.
Right now I'm not sure if I modified the network correctly. Could you please show me the right way to change the structure of the network?
Thanks,
Qingnan

I wonder if the ablation results would be less finicky on a larger corpus which isn’t so regularization dependent


button2d doesn't show up if another inspector plugin is active

I have a piece_maker (hehe) Node that allows me to create new pieces using a recording feature in the viewport.
To trigger  the recording, I'm using @button2d:

So far so good, but the piece_maker stores a list of Shape objects (custom Resource) with a custom InspectorPlugin:

Now, whenever that list is collapsed in the editor, the button2ds show up, but if I open the list, they don't.

Until I can figure out why, a messy hack might be to extend the class with the shapes, and try the @button2d in the child class.
I was having problems with _get_property_list() and that solved it.
There is also the _get_editor_buttons(): method which can return 2d viewport buttons with { call=method, type="2d" }, but I doubt it will solve the problem.


feat(rds): Add an optional database URL to RDS secret

Goal
Have the package generate the value for database URL in RDS secrets. Since I'm not sure what the connection URL is for aurora and aurora-postgresql engines, I'm only setting it if the engine is aurora-mysql so as not to affect anything else downstream. Would love to be able to implement it for all engine types though.
Implementation Decisions

Add a database URL for MySQL-compatible Aurora instances.

Fix typos in comments.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Build Error for NSAttributedStringKey

I am in the middle of submitting to the App Store, and I updated cocoa pods prior to archiving. On build I get the following error: Use of unresolved identifier 'NSAttributedStringKey' - there are three instances of the error below.
My deployment target is iOS 10.3
The code triggering the errors is in ScrollingNavigationController line 432:
    if let titleColor = navigationBar.titleTextAttributes?[NSAttributedStringKey.foregroundColor] as? UIColor {
      navigationBar.titleTextAttributes?[NSAttributedStringKey.foregroundColor] = titleColor.withAlphaComponent(alpha)
    } else {
      navigationBar.titleTextAttributes?[NSAttributedStringKey.foregroundColor] = UIColor.black.withAlphaComponent(alpha)
    }

I understand that NSAttributedStringKey is an iOS 11 API.
Any suggestions as to how I should proceed in handling the updateNavbarAlpha() function?
Thank you so much.

https://github.com/andreamazz/AMScrollingNavbar/blob/master/README.md#versioning-notes
Use version 3.x

@andreamazz you are the bomb!! 8 minute response that worked - wow!! Thank you for all of your work and all the best!!

Hey. I have the same issues. I do not want to downgrade to 3.x as I need a iPhone X compatibility as it is in 4.0.1. My code is in Swift 4.0 and it seems like this particular Pod is compiled in Swift3.
What am I missing?

Version 4.x is compiled with Swift 4. Make sure that your pod project is using the correct version of swift.
you might need something like this in your post installs critps:

swift4pods = ['AMScrollingNavbar']

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if swift4pods.include? target.name
      target.build_configurations.each do |config|
        config.build_settings['SWIFT_VERSION'] = '4.0'
      end
    end
  end
end

But this is odd, if you run pod install your project should default to 4.

Hi @andreamazz ! I am using the version 4.2.1 in a private pod like this:
s.pod_target_xcconfig   = { 'SWIFT_VERSION' => '4.0' }
...
s.dependency 'AMScrollingNavbar', '4.2.1'

But when I try to pod lib lint the project I am still getting the errors:
AMScrollingNavbar/Source/ScrollingNavigationController.swift:462:60: error: type 'NSAttributedStringKey' (aka 'NSString') has no member 'foregroundColor'
AMScrollingNavbar/Source/ScrollingNavigationController.swift:465:42: error: type 'NSAttributedStringKey' (aka 'NSString') has no member 'foregroundColor'

Do you have any ideas on this ? Thanks

Looks like it's compiling it against Swift 3. Can you check the Swift version in target AMScrollingNAvbar inside your Pods project?

It's Swift 4.0

That's really weird, that error message is typical when you compile it with Swift 3 🤔
Also, those lines are wrong in the current version of the file:
https://github.com/andreamazz/AMScrollingNavbar/blob/master/Source/ScrollingNavigationController.swift#L462
462 points to an empty line


Update CacheExtensions.xml

Clarify what happens if GetOrCreateAsync is called multiple times concurrently.

 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.:x: Grauenwolf sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Docs Build status updates of commit b05a908:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

.openpublishing.publish.config.json
:x:Error

Details

Line 117: [Error] Restore nuget package W:\s2lq-s\.optemp\dependentPackages\Microsoft.DocAsCode.ECMA2Yaml\packages.config in folder:W:\s2lq-s\.optemp\packages failed, possibly due to transient errors from nuget servers. Please retry building your content. If the issue still happens, open a ticket in http://SiteHelp and include the build report and the following error message for our team to troubleshoot:  Errors in packages.config projects     Unable to find version '1.0.483' of package 'Microsoft.DocAsCode.ECMA2Yaml'.       D:\Windows\system32\config\systemprofile\.nuget\packages\: Package 'Microsoft.DocAsCode.ECMA2Yaml.1.0.483' is not found on source 'D:\Windows\system32\config\systemprofile\.nuget\packages\'.       https://www.myget.org/F/op/api/v2: Package 'Microsoft.DocAsCode.ECMA2Yaml.1.0.483' is not found on source 'https://www.myget.org/F/op/api/v2'.
Line 117: [Error] Restore nuget package W:\s2lq-s\.optemp\dependentPackages\Microsoft.OpenPublishing.CommonPlugins\packages.config in folder:W:\s2lq-s\.optemp\packages failed, possibly due to transient errors from nuget servers. Please retry building your content. If the issue still happens, open a ticket in http://SiteHelp and include the build report and the following error message for our team to troubleshoot:  Errors in packages.config projects     Unable to find version '1.0.225-alpha' of package 'Microsoft.OpenPublishing.CommonPlugins'.       D:\Windows\system32\config\systemprofile\.nuget\packages\: Package 'Microsoft.OpenPublishing.CommonPlugins.1.0.225-alpha' is not found on source 'D:\Windows\system32\config\systemprofile\.nuget\packages\'.       https://www.myget.org/F/op-dev/api/v2: Package 'Microsoft.OpenPublishing.CommonPlugins.1.0.225-alpha' is not found on source 'https://www.myget.org/F/op-dev/api/v2'.

.openpublishing.publish.config.json

Line 290: [Error] Restore of dependent packages failed. Please check your .openpublishing.publish.config.json?on the configuration of the dependent packages or ask for help?in Docs Support teams channel. Please also include the following error code for our team to troubleshoot: 1

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

It appears the link with the instructions, https://review.docs.microsoft.com/en-us/help/onboard/faq?branch=master, is not public.

per the readme:
API PR's ( api/autoapi/... ) should not be made here. Changes to API documentation should be made in the source repository against the triple slash /// comments.


don't show table name when no search results are shown

Currently we show a gray both with the text
"

Use the sidebar to the right to select search attributes.
"
Let's remove  because at best it isn't useful. And at worse it is confusing. Like in RBK case, when you see "image" it leads you to wonder if this is a broken link for an image.

Done through the commit 0c0f2279e108d78061117734bca0ba596593a4ea.

Github's markdown ruined the issue I entered above. What I intended this issue to say was to remove only the TABLE NAME but not the whole box itself. Can you please bring back the box but not display the table name in it?

Done now through commit 08b1abc949d9de7ad1fcf7189477962034b4ce89.


is this project actively maitained?

Hello, Curios if this project is actively maintained.

i was wondering the same

Hi @asm582, @namenmalkav ,
I was wondering the same opening the PRs half a year ago that are still hanging without response.
At the end we forked this project and continue development for our use-case.
Our fork (named MortalGPU) can be found here: https://gitlab.com/MaxIV/kubernetes/mortalgpu
It is used in production and we aim to continue maintaining it.
/Andrii

Hi @asm582, @namenmalkav ,
I was wondering the same opening the PRs half a year ago that are still hanging without response.
At the end we forked this project and continue development for our use-case.
Our fork (named MortalGPU) can be found here: https://gitlab.com/MaxIV/kubernetes/mortalgpu
It is used in production and we aim to continue maintaining it.
/Andrii

Any chance you can mirror the codebase to Github? Would be good to have an up-to-date mirror here as well, even if read-only.


Tests for #880, PR review suggestions

My suggested tests for the Kahan summation PR @johnynek wrote up in #848.
@johnynek, I also backed off the toDouble, toFloat. I would have expected, based on this, that the tests would fail by turning all of the intermediates into doubles!
scala> val input = Stream.continually(0.01f).take(1000).map(implicitly[Numeric[Float]].toDouble(_))
input: scala.collection.immutable.Stream[Double] = Stream(0.009999999776482582, ?)

scala> input.map(implicitly[Numeric[Float]].toDouble(_)).take(5).toList
res3: List[Double] = List(0.009999999776482582, 0.009999999776482582, 0.009999999776482582, 0.009999999776482582, 0.009999999776482582)

But it turns out that the toFloat at the end "fixes" these errors. I added a third test to make this more clear.

 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.

Codecov Report

Merging #881 into oscar/kahan_summation will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@                  Coverage Diff                   @@
##           oscar/kahan_summation     #881   +/-   ##
======================================================
  Coverage                  89.23%   89.24%
======================================================
  Files                        117      117
  Lines                       9354     9353    -1
  Branches                     354      369   +15
======================================================
  Hits                        8347     8347
+ Misses                      1007     1006    -1

Impacted Files
Coverage Δ

...ore/src/main/scala/com/twitter/algebird/Ring.scala
73.22% <100.00%> (+7.60%)
:arrow_up:

...n/scala/com/twitter/algebird/SuccessibleLaws.scala
76.92% <0.00%> (-15.39%)
:arrow_down:

...main/scala/com/twitter/algebird/monad/Reader.scala
52.94% <0.00%> (-5.89%)
:arrow_down:

...in/scala/com/twitter/algebird/scalacheck/Gen.scala
95.34% <0.00%> (-4.66%)
:arrow_down:

...src/main/scala/com/twitter/algebird/Interval.scala
81.73% <0.00%> (-2.61%)
:arrow_down:

.../main/scala/com/twitter/algebird/JavaMonoids.scala
78.68% <0.00%> (-1.64%)
:arrow_down:

.../main/scala/com/twitter/algebird/BloomFilter.scala
94.69% <0.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 91d5200...4c06cf0. Read the comment docs.

@johnynek okay, reverted! This is ready to go.

Thanks a ton!


IdReg: Correctly use a mask when creating an Id with to_id()

Fixes a problem where the Extended bit was added to the ExtendedId.

Thanks for these PRs, they all look good to me. This change makes the #[allow(dead_code)] lint on line 155 redundant, so ideally I would remove that lint too.
Please add yourself to the authors section in Cargo.toml , since you are the primary author of this code! You should also have rights to edit everything in this repo, approve PRs and so on, which you're very welcome to do.

bors r+