text:
[Bug]: Starter Tutorial (Local Models) - model response incorrect

Bug Description
I followed the installation and setup steps described in the documentation page. Everything seems to be correctly setup but when I run the starter tutorial code the model doesn't seem process correctly the document ("paul_graham_essay.txt") or the request because instead of responding "The author wrote short stories and tried to program on an IBM 1401." it responds: "Based on the context provided in the essay, the author did not directly mention what they did growing up. However, we can infer some information about their background from the text. [...]". From the logging it seems that the top 2 nodes retrieved are actually not the most relevant parts of the text to answer the question. What could the issue be?
Version
0.10.37
Steps to Reproduce
Installing and setting up as described here: https://docs.llamaindex.ai/en/stable/getting_started/installation/ and running the following code as "starter.py": "
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
import logging
import sys
logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)
logging.getLogger().addHandler(logging.StreamHandler(stream=sys.stdout))
documents = SimpleDirectoryReader("data").load_data()
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text")
Settings.llm = Ollama(model="llama2", request_timeout=360.0)
index = VectorStoreIndex.from_documents(
documents,
)
query_engine = index.as_query_engine()
response = query_engine.query("What did the author do growing up?")
print(response)
"
Relevant Logs/Tracbacks
PS C:\Users\matteucc\Desktop\Playground\LlamaIndex> & C:/Users/matteucc/AppData/Local/anaconda3/envs/llamaindex/python.exe c:/Users/matteucc/Desktop/Playground/LlamaIndex/starter.py
DEBUG:llama_index.core.readers.file.base:> [SimpleDirectoryReader] Total files added: 1
> [SimpleDirectoryReader] Total files added: 1
DEBUG:fsspec.local:open file: C:/Users/matteucc/Desktop/Playground/LlamaIndex/data/paul_graham_essay.txt
open file: C:/Users/matteucc/Desktop/Playground/LlamaIndex/data/paul_graham_essay.txt
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: What I Worked On

February 2021

Before college...
> Adding chunk: What I Worked On

February 2021

Before college...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: All that seemed left for philosophy were edge c...
> Adding chunk: All that seemed left for philosophy were edge c...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: Its brokenness did, as so often happens, genera...
> Adding chunk: Its brokenness did, as so often happens, genera...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: If he even knew about the strange classes I was...
> Adding chunk: If he even knew about the strange classes I was...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: The students and faculty in the painting depart...
> Adding chunk: The students and faculty in the painting depart...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: I wanted to go back to RISD, but I was now brok...
> Adding chunk: I wanted to go back to RISD, but I was now brok...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: But alas it was more like the Accademia than no...
> Adding chunk: But alas it was more like the Accademia than no...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: After I moved to New York I became her de facto...
> Adding chunk: After I moved to New York I became her de facto...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: Now we felt like we were really onto something....
> Adding chunk: Now we felt like we were really onto something....
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: In its time, the editor was one of the best gen...
> Adding chunk: In its time, the editor was one of the best gen...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: A company with just a handful of employees woul...
> Adding chunk: A company with just a handful of employees woul...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: I stuck it out for a few more months, then in d...
> Adding chunk: I stuck it out for a few more months, then in d...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: But about halfway through the summer I realized...
> Adding chunk: But about halfway through the summer I realized...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: One of the most conspicuous patterns I've notic...
> Adding chunk: One of the most conspicuous patterns I've notic...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: Horrified at the prospect of having my inbox fl...
> Adding chunk: Horrified at the prospect of having my inbox fl...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: We'd use the building I owned in Cambridge as o...
> Adding chunk: We'd use the building I owned in Cambridge as o...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: It was originally meant to be a news aggregator...
> Adding chunk: It was originally meant to be a news aggregator...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: It had already eaten Arc, and was in the proces...
> Adding chunk: It had already eaten Arc, and was in the proces...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: Then in March 2015 I started working on Lisp ag...
> Adding chunk: Then in March 2015 I started working on Lisp ag...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: I remember taking the boys to the coast on a su...
> Adding chunk: I remember taking the boys to the coast on a su...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: But when the software is an online store builde...
> Adding chunk: But when the software is an online store builde...
DEBUG:llama_index.core.node_parser.node_utils:> Adding chunk: [17] Another problem with HN was a bizarre edge...
> Adding chunk: [17] Another problem with HN was a bizarre edge...
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:11434
Starting new HTTP connection (1): localhost:11434
DEBUG:urllib3.connectionpool:http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
http://localhost:11434 "POST /api/embeddings HTTP/1.1" 200 None
DEBUG:llama_index.core.indices.utils:> Top 2 nodes:
> [Node 396b67ba-f079-4d38-8b1a-6b71f4d57b90] [Similarity score:             0.269713] Now we felt like we were really onto something. I had visions of a whole new generation of softwa...
> [Node 7df44d30-6d9b-4d53-a070-b9acc411adcd] [Similarity score:             0.26883] It was originally meant to be a news aggregator for startup founders and was called Startup News,...
> Top 2 nodes:
> [Node 396b67ba-f079-4d38-8b1a-6b71f4d57b90] [Similarity score:             0.269713] Now we felt like we were really onto something. I had visions of a whole new generation of softwa...
> [Node 7df44d30-6d9b-4d53-a070-b9acc411adcd] [Similarity score:             0.26883] It was originally meant to be a news aggregator for startup founders and was called Startup News,...
DEBUG:httpx:load_ssl_context verify=True cert=None trust_env=True http2=False
load_ssl_context verify=True cert=None trust_env=True http2=False
DEBUG:httpx:load_verify_locations cafile='C:\\Users\\matteucc\\AppData\\Local\\anaconda3\\envs\\llamaindex\\Library\\ssl\\cacert.pem'
load_verify_locations cafile='C:\\Users\\matteucc\\AppData\\Local\\anaconda3\\envs\\llamaindex\\Library\\ssl\\cacert.pem'
DEBUG:httpcore.connection:connect_tcp.started host='localhost' port=11434 local_address=None timeout=360.0 socket_options=None
connect_tcp.started host='localhost' port=11434 local_address=None timeout=360.0 socket_options=None
DEBUG:httpcore.connection:connect_tcp.complete return_value=<httpcore._backends.sync.SyncStream object at 0x0000021E27884680>
connect_tcp.complete return_value=<httpcore._backends.sync.SyncStream object at 0x0000021E27884680>
DEBUG:httpcore.http11:send_request_headers.started request=<Request [b'POST']>
send_request_headers.started request=<Request [b'POST']>
DEBUG:httpcore.http11:send_request_headers.complete
send_request_headers.complete
DEBUG:httpcore.http11:send_request_body.started request=<Request [b'POST']>
send_request_body.started request=<Request [b'POST']>
DEBUG:httpcore.http11:send_request_body.complete
send_request_body.complete
DEBUG:httpcore.http11:receive_response_headers.started request=<Request [b'POST']>
receive_response_headers.started request=<Request [b'POST']>
DEBUG:httpcore.http11:receive_response_headers.complete return_value=(b'HTTP/1.1', 200, b'OK', [(b'Content-Type', b'application/json; charset=utf-8'), (b'Date', b'Thu, 16 May 2024 20:17:14 GMT'), (b'Content-Length', b'986')])
receive_response_headers.complete return_value=(b'HTTP/1.1', 200, b'OK', [(b'Content-Type', b'application/json; charset=utf-8'), (b'Date', b'Thu, 16 May 2024 20:17:14 GMT'), (b'Content-Length', b'986')])
INFO:httpx:HTTP Request: POST http://localhost:11434/api/chat "HTTP/1.1 200 OK"
HTTP Request: POST http://localhost:11434/api/chat "HTTP/1.1 200 OK"
DEBUG:httpcore.http11:receive_response_body.started request=<Request [b'POST']>
receive_response_body.started request=<Request [b'POST']>
DEBUG:httpcore.http11:receive_response_body.complete
receive_response_body.complete
DEBUG:httpcore.http11:response_closed.started
response_closed.started
DEBUG:httpcore.http11:response_closed.complete
response_closed.complete
DEBUG:httpcore.connection:close.started
close.started
DEBUG:httpcore.connection:close.complete
close.complete
Based on the context provided in the essay, the author did not directly mention what they did growing up. However, we can infer some information about their background from the text.

The author mentions that they studied art, which suggests that they may have had an interest in the arts from a young age. Additionally, the author's reference to Interleaf and their experience working as a consultant for the company implies that they may have had some exposure to programming or computer science during their formative years.

However, without any direct statements from the author about their childhood experiences or interests, we cannot provide a definitive answer to the query.

@gmatteuc it works fine for me, ran this a few times and the results were consistent
Code:
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama

documents = SimpleDirectoryReader("data").load_data()

# nomic embedding model
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text")

# ollama
Settings.llm = Ollama(model="llama3", request_timeout=360.0)

index = VectorStoreIndex.from_documents(
    documents,
)

query_engine = index.as_query_engine()
response = query_engine.query("What did the author do growing up?")
print(response)
print(response.source_nodes[0].score)
print(response.source_nodes[1].score)
print(response.source_nodes[0].text[:100])
print(response.source_nodes[1].text[:100])

Output:
(llama-index-py3.11) python ./starter.py
Growing up, the author worked on writing short stories and programming outside of school. He wrote awful short stories with hardly any plot, just characters with strong feelings. In 9th grade, he tried to write programs on an IBM 1401 using early Fortran, but couldn't figure out what to do with it due to limited input options. Later, with the arrival of microcomputers, everything changed, and he started programming seriously, writing simple games, a program to predict rocket flight heights, and a word processor that his father used.
0.3468624729835544
0.26796958338700294
In the art world, money and coolness are tightly coupled. Anything expensive comes to be seen as coo
What I Worked On

February 2021

Before college the two main things I worked on, outside of school,

Maybe make sure you have the latest version of Ollama's server installed, and the latest version of the models pulled?

Yes, pulled llama3 and nomic-embed-text in Ollama (that I just reinstalled) as described.
Running your code snippet I get this:
"c:/Users/matteucc/Desktop/Playground/LlamaIndex/data/newtest.py
Based on the provided context information, there is no mention of the author's childhood
or upbringing. The text only discusses the author's experiences and decisions in his adult life, specifically related to his career and entrepreneurial ventures. Therefore, it is not possible to answer this query based on the given context.
0.26971341318867764
0.268829948067337
Now we felt like we were really onto something. I had visions of a whole new generation of software
It was originally meant to be a news aggregator for startup founders and was called Startup News, bu"

That's pretty weird. I see you are on windows, i wonder if it's an Ollama + windows thing

Weird ideed. I will retry on another computer and/or using gpt-3.5-turbo to see if I get the same issue...

@logan-markewich Hi! Small update on the issue. I tried with gpt-3.5-turbo and it works. I also tried with LangChain + Ollama and got the same issue.  I think the problem is not with the language model itself but with the similarity search in the vector store.  In both case the retrieved documents don't always fit the query not all parts of the documents seems to be accessible for retrival... Indeed, with LangChain, if I swap the embedding generator from the Ollama one to the OpenAI one while keeping Ollama as LLM the probem is fully solved (I didn't try the same in LlamaIndex yet).

authors: gmatteuc logan-markewich


text:
[Question]: BM25 Hybrid Retriever

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
@jerry
How to use the BM25 hybrid retriever using the already indexed milvus collection.

Short answer: you can't (easily)
Long answer: you need all the nodes/documents from Milvus. Then, put those in a docstore. Then, put that in a bm25 retriever

source: gharchive/issue

authors: logan-markewich yashdeepyds

license: MIT

license_type: permissive

license_source: github-api


text:
[Bug]: Delete document in Elasticsearch vector store does not work

Bug Description
I was using index.update_ref_doc(doc) to update an existing document but it was inserting a duplicate instead. When I enabled logs and checked for issues, I found this:
WARNING:  2023-10-21 19:50:07 Could not find text <document-id-here> to delete

Version
0.8.46
Steps to Reproduce

Set up an elasticsearch index
Add a document using index.insert(doc)
Try updating the same document using index.update_ref_doc(doc) (ensure this doc is the same or has the same doc_id as the one in the previous step)
Check documents in the elasticsearch index, there will be 2 documents with the same doc_id

Relevant Logs/Tracbacks
No response

Oops. This wasn't a bug in llama_index, I was creating the elasticsearch index without the correct types. Works fine after letting llama_index create the elasticsearch index instead of me manually creating it.


text:
unable to create dir "/atlantis-data/bin": mkdir /atlantis-data/bin: permission denied

Using atlantis helm chart version 4.0.1.
Getting this when scaling up the statefulset replicas from 1 to 2, and also when doing a fresh install on a new namespace.

Not sure what's changed in the new helm chart exactly, but if you have a PVC configured for that zone, it'll use the root path.
From there, you'll need to set the proper security context (example below). I was able to get past the error, but now I am getting Error: initializing server: initializing terraform: writing generated .terraformrc file with TFE token to /.terraformrc: open /.terraformrc: permission denied, even though folders were created on pod creation and my user (99) has full permissions to write to the designated directory.
securityContext:
  fsGroup: 100
  runAsUser: 99
  fsGroupChangePolicy: "OnRootMismatch"
  priorityClassName: ""

That's bizarre. The volume claim template looks exactly the same.
https://github.com/runatlantis/helm-charts/blob/bc9db325f8f023a282fabe03de6a5fb9b969ac7a/charts/atlantis/templates/statefulset.yaml#L520-L548
Values
https://github.com/runatlantis/helm-charts/blob/bc9db325f8f023a282fabe03de6a5fb9b969ac7a/charts/atlantis/values.yaml#L271-L283
Is this still an issue with the latest helm chart?
Could you show the helm template command diff between supplying the deprecated input and omitting it? Perhaps that will bubble up the issue here.

Is this still happening?

I'm getting the same issue while deploying with the helm chart version 5.5.0. @GMartinez-Sisti .

I'm getting the same issue while deploying with the helm chart version 5.5.0. @GMartinez-Sisti .

Hi @creeram, please share your values file (redacted) so we can test it please.

atlantisUrl: "**********"
orgAllowlist: github.com/*****/*
gitconfigReadOnly: true
extraArgs:
   - --disable-autoplan

image:
  repository: ghcr.io/runatlantis/atlantis
  tag: "v0.29.0"
  pullPolicy: Always
repoConfig: |
  ---
  repos:
  - id: /.*/
    apply_requirements: [approved, mergeable]
    allowed_overrides: [workflow,plan_requirements]
    allow_custom_workflows: true
  workflows:
    terragrunt:
      plan:
        steps: [plan]
      apply:
        steps: [apply]
  metrics:
    prometheus:
      endpoint: /metrics

githubApp:
  id: *****
  key: |
    -----BEGIN RSA PRIVATE KEY-----

    *********************************
    -----END RSA PRIVATE KEY-----

  secret: **********

volumeClaim:
  enabled: true
  dataStorage: 20Gi
  storageClassName: ""
  accessModes: ["ReadWriteMany"]

replicaCount: 3

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - "**********"

service:
  type: ClusterIP
  port: 80
  portName: atlantis
  targetPort: 4141

ingress:
  enabled: true
  ingressClassName: "nginx"
  annotations:
    kubernetes.io/ingress.class: nginx
  path: /
  pathType: ImplementationSpecific
  host: "*********"

environment:
  TERRAGRUNT_TFPATH: /plugins/terraform

initConfig:
  enabled: true
  image: alpine:latest
  imagePullPolicy: IfNotPresent
  sharedDir: /plugins
  sharedDirReadOnly: true
  workDir: /tmp
  sizeLimit: 200Mi
  script: |
    #!/bin/sh
    set -eoux pipefail

    # example for terragrunt
    TG_VERSION="v0.63.4"
    TG_SHA256_SUM="b3ab5ef5176bee485052de29afe5fbeb9f2fff8a8d6f1c83e7db49776a47a850"
    TG_FILE="${INIT_SHARED_DIR}/terragrunt"
    wget https://github.com/gruntwork-io/terragrunt/releases/download/${TG_VERSION}/terragrunt_linux_amd64 -O "${TG_FILE}"
    echo "${TG_SHA256_SUM}  ${TG_FILE}" | sha256sum -c
    chmod 755 "${TG_FILE}"
    terragrunt -v

    # Terraform
    TF_VERSION="1.5.7"
    TF_FILE="${INIT_SHARED_DIR}/terraform"
    wget https://releases.hashicorp.com/terraform/${TF_VERSION}/terraform_${TF_VERSION}_linux_amd64.zip
    unzip terraform_${TF_VERSION}_linux_amd64.zip
    mv terraform ${INIT_SHARED_DIR}
    chmod 755 "${TF_FILE}"
    terraform -v

lockingDbType: "redis"
redis:
  host: ********
  port: 6379

redisSecretName: "****"

This is the values file and I'm trying to use ReadWriteMany PVC so that 3 replicas can use the same volume. @GMartinez-Sisti

I see, the problem is the ReadWriteMany PVC, to scale Atlantis you need shared storage. What is the definition for the default storageClass in that cluster?

Yes, the default storageClass type is block/device, which doesn’t allow access from multiple Kubernetes nodes. That’s why I’m using nodeAffinity to schedule all pods on a single Kubernetes node. Could you please suggest a solution to the 'permission denied' issue while sticking with the current approach? @GMartinez-Sisti

Could you please suggest a solution to the 'permission denied' issue while sticking with the current approach? @GMartinez-Sisti

Sorry but this is not an Atlantis, issue but a kubernetes limitation instead, please refer to the docs for more information -> https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes.
My suggestion is to use an NFS solution for the share, e.g. on AWS you can use EFS as a storageClass.

@GMartinez-Sisti  No problem i decided to move forward with ReadWriteOnce AccessMode for the pvc.

@GMartinez-Sisti  No worries! I encountered this issue before when I tried to use the old deprecated storage option on values.yaml file, which creates a separate PVC for each replica, and the new storage config for your helm chart by default creates a shared PVC, that's why I'm scheduling all pods on a single Kubernetes node with nodeAffinity so that I don't need an NFS solution for the StorageClass.
This is only for our Dev/Staging environment, We will use a cloud-based NFS solution when configuring the production environment.

authors: GMartinez-Sisti akhan23wgu creeram nitrocode nokernel

repo: runatlantis/helm-charts


text:
AnimationID for Forester Campfire

Type
Other
Operating System
Windows
OS Version
Windows 11
Bug description
I'm getting 10573 as the animation ID when tending to the campfire versus the 10572 defined here https://github.com/runelite/runelite/blob/master/runelite-api/src/main/java/net/runelite/api/AnimationID.java#L63.
Not sure if it's just a missing animation or a typo.
Screenshots or videos
No response
RuneLite version
RuneLite Version: 1.10.14.5
Launcher Version: 2.6.7
Logs
No response

fixed in 5b12f573dc7b4827da1dcb3535d7f877036f52d7

authors: Adam- mikeweyandt

repo: runelite/runelite


text:
Switch Options on Con/Craft Cape

Instead of Wear 1st option make it "teleport to poh" and the same for crafting

Already done , mb forgot to turn on


text:
Menu entry swapper - Swap Talk-to with pickpocket

There is currently no way to swap pickpocket with talk to for some NPC-s in menu entry swapper. Good example is Master Gardener.

Would be nice to have option for swapping pickpocket with talk-to or just prioritizing pickpocket over every other option (currently only specific option for swapping it for H.A.M NPC-s). This option should be off by default of course.

This is Rejected for being absurdly powerful for blackjacking.
Side Note: Martin is an outlier for master farmers since he sells the Farming cape; any other Master Farmer can be left-click pickpocketed without modification.


text:
fix: model to cpu for cuda cleanup

https://app.shortcut.com/galileo/story/8227/dq-move-model-to-cpu-before-cleanup
For @dcaustin33

Urm, credentials in notebook.

Eeek! my bad ... squashed in an interactive rebase so it's not in commit history

source: gharchive/pull-request

repo: rungalileo/dataquality


text:
grab current rss feeds without running into CORS issues

  //todo: grab current rss feeds without running into CORS issues

https://github.com/runguszone/rungnews/blob/6ef03660f139bae52dc936f4ba9c9352f3c42a0b/internal/parse-rss-and-print.js#L2

an update, it seems that rss-parser.min.js does not play nice with CORS. trying to set it to mode: no-cors doesn't seem to fix the issue.
i really do not want to write my own rss parser, but signs are pointing that way.

repo: runguszone/rungnews


text:
Update 'ros_genmsg' to 0.5.12-p0

I've followed this guide
step by step carefully. [Yes]

I've tested this package remotely and have excluded all broken builds.
Here is the links to the Travis/AppVeyor with status "All passed":

https://ci.appveyor.com/project/kgeorgiev93/hunter/builds/24938094
https://travis-ci.com/kgeorgiev93/hunter/builds/113819876

Testing:

https://ci.appveyor.com/project/ingenue/hunter/builds/24945545
https://travis-ci.org/ingenue/hunter/builds/539607958?utm_source=github_status&utm_medium=notification

Released: https://github.com/ruslo/hunter/releases/tag/v0.23.184

repo: ruslo/hunter

license_source: bigquery


text:
Catch v1.8.2-p0

You're right. It was easier to do it again.

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2076
https://travis-ci.org/ingenue/hunter/builds/259152747?utm_source=github_status&utm_medium=notification

Uploading:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2079
https://travis-ci.org/ingenue/hunter/builds/259157600?utm_source=github_status&utm_medium=notification

Released: https://github.com/ruslo/hunter/releases/tag/v0.19.52


text:
S3 Addressing Style

S3 supports two different ways to address a bucket, Virtual Host Style and Path Style. Boto3 supports controlling this manually, link: https://boto3.amazonaws.com/v1/documentation/api/1.9.42/guide/s3.html#changing-the-addressing-style
Is it supported by rusoto?
The original problem I am trying to solve is access of S3 from Lambda within a VPC, which doesn't work.

Just making a note for the record the path style is deprecated https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/

Looks like a duplicate of https://github.com/rusoto/rusoto/issues/1482

authors: riquito softprops vim-zz

repo: rusoto/rusoto

license: mit


text:
Travis/Appveyor: disable incremental compilation

Starting with Rustc 1.24 incremental compilation has been enabled by default for non-release builds. I ran some tests and disabling it on Travis appears quite a bit faster.
For comparison:
• Build with default settings (incr. build for >=1.24)
• Incr. build explicitly disabled
I guess this explains the speed difference between 1.23 and beta/nightly.

Thanks for the PR!
The usual stable channel on Linux timed out. Making docs for so many crates takes a long time. 😢 Restarted it.

Let's give this a try for a week or two and see if our build times improve overall. 👍

authors: matthewkmayer pgerber


text:
DateTime ToSql format is not compatible with sqlite date format

Sqlite supports following DateTime formats:
TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

rusqlite uses RFC3339 timestamp ("YYYY-MM-DDTHH:MM:SS.SSS+00:00") which is not compatible with the sqlite format.
Here is an example where the incompatible formating causes problem.
use rusqlite;
use chrono::prelude::*;

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn check_datetime_select() {
        let db_conn = rusqlite::Connection::open_in_memory().unwrap();
        let start_date = Utc::now();
        let test_date = start_date + chrono::Duration::seconds(15);
        db_conn.execute(" CREATE TABLE test_table (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP);",  rusqlite::NO_PARAMS).unwrap();
        for _ in 0..30 {
            //db_conn.execute("INSERT INTO test_table (ts) VALUES (?1);",  rusqlite::params![start_date + chrono::Duration::hours(i)]).unwrap();
            db_conn.execute("INSERT into test_table default values;",  rusqlite::params![]).unwrap();
            std::thread::sleep(std::time::Duration::from_secs(1));
        }

        let mut statenent = db_conn.prepare("SELECT ts FROM test_table").unwrap();
        let res_iter = statenent.query_map (rusqlite::params![], |row| {
            let date_db : DateTime<Utc> = row.get(0).unwrap();
            //println!("{}", date_db);
            Ok( date_db )
        }).unwrap();
        let all: Vec<DateTime<Utc>> = res_iter.map(|itm| {itm.unwrap()}).collect();

        //let mut statenent = db_conn.prepare("SELECT ts FROM test_table").unwrap();
        let mut statenent = db_conn.prepare("SELECT ts FROM test_table where ts > ?1;").unwrap();
        let res_iter = statenent.query_map (rusqlite::params![test_date], |row| {
            let date_db : DateTime<Utc> = row.get(0).unwrap();
            //println!("{}", date_db);
            Ok( date_db )
        }).unwrap();
        let res: Vec<DateTime<Utc>> = res_iter.map(|itm| {itm.unwrap()}).collect();
        if res.len() < 10 || res.len() > 20 {
            println!("All {:?}", all);
            println!("ts > {}: {:?}", test_date, res);
            panic!("Selection using DateTime<Utc> doens't work")
        }
    }
}

Expanded SQL is:
SELECT ts FROM test_table WHERE ts > '2021-01-28T17:47:23.556940+00:00';

Should be without 'T':
SELECT ts FROM test_table WHERE ts > '2021-01-28 17:47:23.556940+00:00';

Expanded SQL is:
SELECT ts FROM test_table WHERE ts > '2021-01-28T17:47:23.556940+00:00';

Should be without 'T':
SELECT ts FROM test_table WHERE ts > '2021-01-28 17:47:23.556940+00:00';

Ok, CURRENT_TIMESTAMP format is '%Y-%m-%d %H:%M:%S' UTC.
But DateTime<Utc> format is 'YYYY-MM-DDTHH:MM:SS.SSS+00:00'.
A quick fix is:
SELECT ts FROM test_table where datetime(ts) > datetime(?1);

Ok, CURRENT_TIMESTAMP format is '%Y-%m-%d %H:%M:%S' UTC.
But DateTime<Utc> format is 'YYYY-MM-DDTHH:MM:SS.SSS+00:00'.
A quick fix is:
SELECT ts FROM test_table where datetime(ts) > datetime(?1);

And you are listing only 3 formats among the 12 formats supported (which don't include formats with timezone):
https://sqlite.org/lang_datefunc.html#time_values

And you are listing only 3 formats among the 12 formats supported (which don't include formats with timezone):
https://sqlite.org/lang_datefunc.html#time_values

For reference,
https://github.com/launchbadge/sqlx/blob/v0.4.2/sqlx-core/src/sqlite/types/chrono.rs#L61

For reference,
https://github.com/launchbadge/sqlx/blob/v0.4.2/sqlx-core/src/sqlite/types/chrono.rs#L61

I am not expert in sqlite. So excuse me if I am wrong. In the original post I was reffering to chapter 2.2 of https://www.sqlite.org/datatype3.html. The 12 formats from https://sqlite.org/lang_datefunc.html#time_values can be used as input for sqlite's datetime functions. But the output is always in "YYYY-MM-DD HH:MM:SS.SSS" format. Also the datetime values have to be stored using the same format - to work properly with sqlite's datetime functions and also to assure compatibility with other sqlite clients. For example pysqlite in my case.

I am not expert in sqlite. So excuse me if I am wrong. In the original post I was reffering to chapter 2.2 of https://www.sqlite.org/datatype3.html. The 12 formats from https://sqlite.org/lang_datefunc.html#time_values can be used as input for sqlite's datetime functions. But the output is always in "YYYY-MM-DD HH:MM:SS.SSS" format. Also the datetime values have to be stored using the same format - to work properly with sqlite's datetime functions and also to assure compatibility with other sqlite clients. For example pysqlite in my case.

See #886.

See #886.

authors: gwenn nosense-cz

repo: rusqlite/rusqlite


text:
eager evaluation of full syntax tree information

I'd like to propose that it would be useful to have an API which makes all information of a rust file easily available in one go.
My use case is to generate a json file from each rust file which has type/ usage information about each struct/ function definition and definition and docs information about each usage (motivation: https://drewdevault.com/2019/07/08/Announcing-annotations-for-sourcehut.html).
I looked at how cbindgen does that because that seemed similar enough and they indeed have a similar problem (see the warning) and already also looked into ra https://github.com/eqrion/cbindgen/issues/214#issuecomment-470176868 .
As a comparison for other languages I would highlight c ("clang -Xclang -ast-dump=json sokol_gfx.h" https://twitter.com/FlohOfWoe/status/1290299480881782795) and go (https://github.com/golang/example/tree/master/gotypes and https://pkg.go.dev/golang.org/x/tools/go/packages).
I asked about this on zulip and was pointed to the syntax_highlighting.rs code so maybe the pattern used there could be turned into an API that is useful for consumers.

The rust-analyzer analysis-stats implementation might be useful here, but you could also look into the new rustdoc JSON backend, which might be easier to get started with.

The rustdoc JSON backend looks interesting although it does not cover the doc use case as it only contains information for declarations and not bodies as far as I can see, but it might be interesting for cbindgen actually as it seems roughly equivalent to clang -Xclang -ast-dump=json.
Regarding the unactionable label I'm not sure what specific details are required to make this actionable other than the example of the go package and the example use case.
Another one would be generating a call-graph which would be pretty trivial with that information and helpful for docs as well.

Another one would be generating a call-graph which would be pretty trivial with that information and helpful for docs as well.

See https://github.com/robinmoussu/cargo-callgraph/

My use case is to generate a json file from each rust file which has type/ usage information about each struct/ function definition and definition and docs information about each usage (motivation: https://drewdevault.com/2019/07/08/Announcing-annotations-for-sourcehut.html).

I think it would make sense to build a tool using the rust-analyzer api that directly outputs the exact format that sourcehut expects and possibly even directly uploads it rather than have it consume a rust-analyzer specific json format that likely won't be stable either and may be slower due to needing to be more generic and thus requiring more info to be generated. In addition a json format is likely to miss information as new features are added to rust-analyzer.

See https://github.com/robinmoussu/cargo-callgraph/

Thanks I looked at some a while ago and concluded they were not really usable yet e.g.

Currently, I highly advice against testing cargo-callgraph on any crate that has more than 500 SLOC since the output will be very hard to visualize, and dot is extremely slow with bigger graph.

but on the other hand thats easy enough to fix eventually and not related to the issue I opened.

I think it would make sense to build a tool using the rust-analyzer api

I totally agree, I just tried 3 times I think and it seemed not very easy to use for me (compared to what it looked like in go, maybe because the scope of the project is slightly different)

Sounds like the SCIP/LSIF output is what is desired here which already exists

authors: Veykril benmkw bjorn3 lnicola

repo: rust-analyzer/rust-analyzer


text:
proc macro server crashed

When loading atsamd-rs BSPs, rust-analyzer crashes.
I don't have the VSCode Rust extension installed.
Steps to reproduce:

VSCode Version 1.15.1
Rust-Analyzer Version 0.2.408
git clone https://github.com/atsamd-rs/atsamd.git
code atsamd/boards/itsybitsy_m4

settings.json:
{
    "rust-analyzer.procMacro.enable": true,
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "window.zoomLevel": 0,
    "explorer.confirmDragAndDrop": false,
    "workbench.tree.indent": 24,
    "workbench.tree.renderIndentGuides": "always",
    "rust-analyzer.checkOnSave.command": "clippy",
    "files.eol": "\r\n",
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "matklad.rust-analyzer",
    "rust-analyzer.updates.channel": "nightly",
    "rust-analyzer.checkOnSave.allTargets": false,
}

Stack trace:
thread '<unnamed>' panicked at 'no value set for FileTextQuery(FileId(0))', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\salsa-0.16.0\src\input.rs:104:32
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'internal error: entered unreachable code', crates\proc_macro_srv\src\proc_macro\bridge\mod.rs:256:5
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'use-after-free in `proc_macro` handle', crates\proc_macro_srv\src\proc_macro\bridge\handle.rs:38:30
stack backtrace:
   0:     0x7ff7015754f9 - <unknown>
   1:     0x7ff70158fcbb - <unknown>
   2:     0x7ff70156e458 - <unknown>
   3:     0x7ff701578544 - <unknown>
   4:     0x7ff701578128 - <unknown>
   5:     0x7ff701578dff - <unknown>
   6:     0x7ff701578965 - <unknown>
   7:     0x7ff701575ddf - <unknown>
   8:     0x7ff701578919 - <unknown>
   9:     0x7ff70158d720 - <unknown>
  10:     0x7ff70158d4c2 - <unknown>
  11:     0x7ff701a6bb5a - <unknown>
  12:     0x7ff7015a4064 - <unknown>
  13:     0x7ff9be21abb7 - proc_macro::bridge::closure::Closure::call
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\closure.rs:27
  14:     0x7ff9be21abb7 - proc_macro::bridge::client::{{impl}}::drop::{{closure}}
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:243
  15:     0x7ff9be219853 - proc_macro::bridge::scoped_cell::ScopedCell::replace
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\scoped_cell.rs:74
  16:     0x7ff9be219853 - proc_macro::bridge::client::{{impl}}::with::{{closure}}
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:290
  17:     0x7ff9be219853 - std::thread::local::LocalKey::try_with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libstd\thread\local.rs:263
  18:     0x7ff9be219853 - std::thread::local::LocalKey::with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libstd\thread\local.rs:239
  19:     0x7ff9be219853 - proc_macro::bridge::client::BridgeState::with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:289
  20:     0x7ff9be219853 - proc_macro::bridge::Bridge::with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:327
  21:     0x7ff9be219853 - proc_macro::bridge::client::TokenStream::drop
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:236
  22:     0x7ff9be219853 - proc_macro::bridge::client::{{impl}}::drop
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:55
  23:     0x7ff9be1e87de - core::ptr::drop_in_place<proc_macro::bridge::client::TokenStream>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libcore\ptr\mod.rs:184
  24:     0x7ff9be1e800e - core::ptr::drop_in_place<proc_macro::TokenStream>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libcore\ptr\mod.rs:184
  25:     0x7ff9be20489a - paste::expand
                               at C:\Users\Sympatron\.cargo\registry\src\github.com-1ecc6299db9ec823\paste-1.0.3\src\lib.rs:256
  26:     0x7ff9ead61030 - <unknown>
  27:     0x7ff9ead64a52 - is_exception_typeof
  28:     0x7ff9ead6e7a4 - _C_specific_handler
  29:     0x7ff9ead63cc8 - is_exception_typeof
  30:     0x7ff9ead6f0d1 - _CxxFrameHandler3
  31:     0x7ffa0b98124f - _chkstk
  32:     0x7ffa0b8fd9b2 - RtlUnwindEx
  33:     0x7ff9ead6ec62 - _C_specific_handler
  34:     0x7ff9ead62955 - is_exception_typeof
  35:     0x7ff9ead62d81 - is_exception_typeof
  36:     0x7ff9ead63dc4 - is_exception_typeof
  37:     0x7ff9ead6f0d1 - _CxxFrameHandler3
  38:     0x7ffa0b9811cf - _chkstk
  39:     0x7ffa0b94a209 - RtlRaiseException
  40:     0x7ffa0b949fc3 - RtlRaiseException
  41:     0x7ffa092aa799 - RaiseException
  42:     0x7ff9ead66220 - CxxThrowException
  43:     0x7ff701a5e151 - <unknown>
  44:     0x7ff701a5e0d9 - <unknown>
  45:     0x7ff701579008 - <unknown>
  46:     0x7ff701578eb6 - <unknown>
  47:     0x7ff70147d8f4 - <unknown>
  48:     0x7ff70147d88f - <unknown>
  49:     0x7ff7015added - <unknown>
  50:     0x7ff7015a4b21 - <unknown>
  51:     0x7ff701a64770 - <unknown>
  52:     0x7ff7015a4064 - <unknown>
  53:     0x7ff9be209647 - proc_macro::bridge::scoped_cell::ScopedCell::replace
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\scoped_cell.rs:74
  54:     0x7ff9be209647 - proc_macro::bridge::client::{{impl}}::with::{{closure}}
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:290
  55:     0x7ff9be209647 - std::thread::local::LocalKey::try_with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libstd\thread\local.rs:263
  56:     0x7ff9be209647 - std::thread::local::LocalKey::with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\src\libstd\thread\local.rs:239
  57:     0x7ff9be209647 - proc_macro::bridge::client::BridgeState::with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:289
  58:     0x7ff9be209647 - proc_macro::bridge::Bridge::with
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:327
  59:     0x7ff9be209647 - proc_macro::bridge::client::TokenStream::new
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\bridge\client.rs:236
  60:     0x7ff9be209647 - proc_macro::TokenStream::new
                               at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9\/src\libproc_macro\lib.rs:108
  61:     0x7ff9be203483 - paste::expand
                               at C:\Users\Sympatron\.cargo\registry\src\github.com-1ecc6299db9ec823\paste-1.0.3\src\lib.rs:176
  62:     0x7ff9be2032bb - paste::paste
                               at C:\Users\Sympatron\.cargo\registry\src\github.com-1ecc6299db9ec823\paste-1.0.3\src\lib.rs:157
  63:     0x7ff9be203391 - paste::item
                               at C:\Users\Sympatron\.cargo\registry\src\github.com-1ecc6299db9ec823\paste-1.0.3\src\lib.rs:166
  64:     0x7ff9be1e7998 - core::ops::function::FnOnce::call_once<fn(proc_macro::TokenStream) -> proc_macro::TokenStream,tuple<proc_macro::TokenStream>>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libcore\ops\function.rs:233
  65:     0x7ff9be1e3a76 - proc_macro::bridge::client::{{impl}}::expand1::run::{{closure}}<fn(proc_macro::TokenStream) -> proc_macro::TokenStream>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\client.rs:407
  66:     0x7ff9be1e2fe0 - proc_macro::bridge::client::run_client::{{closure}}::{{closure}}<proc_macro::bridge::client::TokenStream,proc_macro::bridge::client::TokenStream,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\client.rs:375
  67:     0x7ff9be1e2218 - proc_macro::bridge::scoped_cell::{{impl}}::set::{{closure}}<proc_macro::bridge::client::BridgeStateL,tuple<>,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\scoped_cell.rs:79
  68:     0x7ff9be1e28e2 - proc_macro::bridge::scoped_cell::ScopedCell<proc_macro::bridge::client::BridgeStateL>::replace<proc_macro::bridge::client::BridgeStateL,tuple<>,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\scoped_cell.rs:74
  69:     0x7ff9be1e21f5 - proc_macro::bridge::scoped_cell::ScopedCell<proc_macro::bridge::client::BridgeStateL>::set<proc_macro::bridge::client::BridgeStateL,tuple<>,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\scoped_cell.rs:79
  70:     0x7ff9be1e391c - proc_macro::bridge::client::{{impl}}::enter::{{closure}}<tuple<>,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\client.rs:323
  71:     0x7ff9be1e55dc - std::thread::local::LocalKey<proc_macro::bridge::scoped_cell::ScopedCell<proc_macro::bridge::client::BridgeStateL>>::try_with<proc_macro::bridge::scoped_cell::ScopedCell<proc_macro::bridge::client::BridgeStateL>,closure-1,tuple<>>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\thread\local.rs:263
  72:     0x7ff9be1e50ee - std::thread::local::LocalKey<proc_macro::bridge::scoped_cell::ScopedCell<proc_macro::bridge::client::BridgeStateL>>::with<proc_macro::bridge::scoped_cell::ScopedCell<proc_macro::bridge::client::BridgeStateL>,closure-1,tuple<>>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\thread\local.rs:239
  73:     0x7ff9be1e3798 - proc_macro::bridge::Bridge::enter<tuple<>,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\client.rs:323
  74:     0x7ff9be1e2f05 - proc_macro::bridge::client::run_client::{{closure}}<proc_macro::bridge::client::TokenStream,proc_macro::bridge::client::TokenStream,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\client.rs:368
  75:     0x7ff9be1e1266 - std::panic::{{impl}}::call_once<tuple<>,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\panic.rs:318
  76:     0x7ff9be1e5b30 - std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure-0>,tuple<>>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\panicking.rs:348
  77:     0x7ff9be2062e7 - paste::is_flat_group::{{impl}}::eq
  78:     0x7ff9be1e599a - std::panicking::try<tuple<>,std::panic::AssertUnwindSafe<closure-0>>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\panicking.rs:325
  79:     0x7ff9be1e5056 - std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure-0>,tuple<>>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\panic.rs:394
  80:     0x7ff9be1e2d40 - proc_macro::bridge::client::run_client<proc_macro::bridge::client::TokenStream,proc_macro::bridge::client::TokenStream,closure-0>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\client.rs:367
  81:     0x7ff9be1e3a2d - proc_macro::bridge::client::{{impl}}::expand1::run<fn(proc_macro::TokenStream) -> proc_macro::TokenStream>
                               at C:\Users\Sympatron\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libproc_macro\bridge\client.rs:407
  82:     0x7ff701a64562 - <unknown>
  83:     0x7ff701a62ec7 - <unknown>
  84:     0x7ff7015a4109 - <unknown>
  85:     0x7ff701481aca - <unknown>
  86:     0x7ff70144b562 - <unknown>
  87:     0x7ff7014622e6 - <unknown>
  88:     0x7ff70146261c - <unknown>
  89:     0x7ff701579133 - <unknown>
  90:     0x7ff70144e8a7 - <unknown>
  91:     0x7ff702171460 - <unknown>
  92:     0x7ffa099a7bd4 - BaseThreadInitThunk
  93:     0x7ffa0b94ce51 - RtlUserThreadStart
thread panicked while panicking. aborting.
[ERROR proc_macro_api::process] proc macro server crashed, server process state: Ok(Some(ExitStatus(ExitStatus(3221225501))))

[rust-analyzer macro-error] [E] proc macro server crashed  +1

rust-analyzer macro-error] [E] Empty result

Otherwise, excessive highlight warning
[rust-analyzer unresolved-proc-macro] [H] proc macro not expanded

@Piping Could you reproduce the error? I don't understand your comments.

@Sympatron can you try with the nightly version?

@lnicola Seems to be fixed on nightly (version 0.3.413).

@Sympatron I am using vim and Coc.vim together with rust-analyzer. I can reproduce crash in my workspace with a different project. ( I used maud crate which heavily depends on proc-macro).
My Coc Setup
{
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,
    "rust-analyzer.procMacro.enable": true,
    // comment  "rust-analyzer.diagnostics.disabled": [ "macro-error", "unresolved-proc-macro" ],
    "rust-analyzer.updates.channel": "nightly"
}

I use nvim + Coc.vim and after update to rust-analyzer-mac with version: dbd0cfb have proc macro server crashed. Before update all was fine. I don't remember previous version, but it is ~1month old.

The original crash in this issue is fixed. We can track further ones with no error messages under https://github.com/rust-analyzer/rust-analyzer/issues/6880.

@comicfans that's related to #8925, #8928, #8929 and https://github.com/rust-analyzer/rust-analyzer/pull/9047#issuecomment-852134592 (not sure we need three issues for it, though).
You can either:

use an older nightly
disable proc macros
use a stable toolchain

We won't be able to merge any fix soon, unfortunately.

authors: Piping Sympatron invis87 lnicola


text:
We should have a weekly "update Cargo-recent.lock" cronjob

We should have a script here which runs cargo update followed by all known manual pins that we need, and updates Cargo-recent.lock accordingly.
This script would serve as documentation of all the currently-known pins that are needed for the library to work with MSRV, and would make us aware when we need new ones reasonably quickly. Without breaking our build.
It may be that @tcharding is tired of "reviewing" all these bot PRs whose only purpose is to tweak CI config and see if it breaks, but if they're all clustered on Sunday evenings maye it's okay?

I just ack if CI is green :) I open to this. It would be nice to do it using rust-bitcoin-maintainer-tools somehow so all the repos can benefit.

Maybe we can even auto-detect breakages and update the pin list somehow: if the CI fails have the bot try updating one crate at a time and record whatever failed as broken (so the previous version is considered pinned).

I'd like that. In theory it shouldn't be too hard. My algorithm is roughly:

If an updated crate no longer compiles...
...try downgrading that specific crate by linear-searching from the broken version down to the lowest version that manifests allow until something works...
...and if that fails, go to whatever crate in the tree depends on it and was also updated (one must exist otherwise the previous step would've succeeded) and try downgrading that

In practice I use some heuristics, like with 1.56.1 we couldn't use syn 2 and whenever it appeared I knew I needed to downgrade serde, and I even had the specific version memorized, etc.

authors: Kixunil apoelstra tcharding

repo: rust-bitcoin/rust-bitcoin


text:
[0.2.x]: Fix warning, remove #[deny(warnings)] but keep check on CI

This fixes #213. Additionally I removed #[deny(warnings)] but added a check for it on CI.
I think we should cherry pick #138 to the 0.2.x branch as well and release a 0.2.4 version, since 1.0 will still take a while.
I can do that in a separate PR.

r? @ryankurte
(rust_highfive has picked a reviewer for you, use r? to override)

:warning: Warning :warning:

Pull requests are usually filed against the master branch for this repo, but this one is against v0.2.x. Please double check that you specified the right target!

bors r+

CI tests failed on rust nightly due to untagged-option. I have updated the stm32f30x package now.

bors retry

bors retry

authors: adamgreig eldruin rust-highfive ryankurte

repo: rust-embedded/embedded-hal


text:
Use Future::lazy instead of future::lazy (etc)

It should eventually be possible to provide the current free functions in the futures library as inherent functions on the corresponding traits. Currently blocked on https://github.com/rust-lang/rust/issues/37591

I'm going to close this, since it's unactionable until compiler changes land.

repo: rust-lang-nursery/futures-rs


text:
env: Allow zero-allocation LogBuilder::format?

The the "format function" passed to LogBuilder::format must implement Fn(&LogBuilder) -> String.  That is, it must allocate a new string on the heap for every message logged. The string is discarded immediately after env_logger::Logger writes to stderr.
Would you consider, instead, making the signature Fn(&LogBuilder, &mut std::io::Write) -> io::Result?  That way, customized env loggers could write directly to stderr without creating a String.

Thanks for the suggestion @tomjakubowski! We did end up doing this in https://github.com/sebasmagri/env_logger/pull/19

authors: KodrAus tomjakubowski

repo: rust-lang-nursery/log


text:
Misconfiguration no longer detected

With https://github.com/rust-lang-nursery/multirust-rs/commit/c3679a5922e68c5b08d7ff544f4d76031887523d the proxy test was removed. While I understand the rationale for it's removal, I do think it was useful:

On windows, the system-wide PATH has a higher precedence than the user-specific PATH, so by default, any existing rust install will silently override the rustup install, and the invocations of rustc will not be correctly proxied. Given how likely this is to occur, we should at least warn when this is happening.

Previously, multirust would intercept commands of the form <proxy> --multirust and print a message indicating that said proxy is working correctly. This was a useful feature in itself, and does not cause erroneous warnings.

There are a couple of ways this could be solved:

Only check the proxies on first install.
Provide a command to check that the proxies are correctly configured, and recommend using it in the post-install message.

Interesting points. I did not know the first. There are other system problems we might want to detect too, like old .multirust directories laying around.
The main reason I removed the old test was because it expected rustc to be on the PATH, which is I didn't consider a requirement for rustup to work. I also removed setting of PATH during proxy execution, instead relying on MULTIRUST_TOOLCHAIN.
I have doubts though that this was the right decision because of the way rustup is installed to ~/.cargo/bin: if ~/.cargo/bin is not in PATH then when cargo runs rustc it's going to fail because the rustc proxy isn't on the path. In other words, to make rustup work without setting PATH beforehand, rustup needs to set PATH to ~/.cargo/bin (not the toolchain dir) when executing proxies.
So what I think we might should do is:

Before running a proxied command prepend the directory containing the running proxy to PATH.
At installation, prepend the proxy directory to PATH and run rustc --multirust (or some other flag)
to see if Windows is overriding PATH.

authors: Diggsey brson

repo: rust-lang-nursery/multirust-rs


text:
no such subcommand: +

Hey all,
Just trying out cargo-bisect-rustc today. When I try to run:
cargo bisect-rustc --test-dir . --start=801821d15 --end=40336865f --regress error --preserve -vv -- version

(I was trying an actual build command but simplifying the failure to running version)
It seems to have trouble running cargo with the newly added toolchain:
bisecting ci builds
starting at 801821d15, ending at 40336865f
opening existing repository at "rust.git"
Found origin remote under name `origin`
refreshing repository at "rust.git"
fetching (via local git) commits from 801821d15 to 40336865fe7d4a01139a3336639c6971647e885c
opening existing repository at "rust.git"
Found origin remote under name `origin`
refreshing repository at "rust.git"
looking up first commit
looking up second commit
checking that commits are by bors and thus have ci artifacts...
finding bors merge commits
found 8 bors merge commits in the specified range
  commit[0] 2022-08-14UTC: Auto merge of #100429 - GuillaumeGomez:merge-html-elements-together, r=notriddle
  commit[1] 2022-08-14UTC: Auto merge of #100540 - matthiaskrgr:rollup-734hkpt, r=matthiaskrgr
  commit[2] 2022-08-15UTC: Auto merge of #100510 - compiler-errors:as-a-treat, r=jackh726
  commit[3] 2022-08-15UTC: Auto merge of #96350 - austinabell:skip_optimization, r=Mark-Simulacrum
  commit[4] 2022-08-15UTC: Auto merge of #96745 - ehuss:even-more-attribute-validation, r=cjgillot
  commit[5] 2022-08-15UTC: Auto merge of #98393 - michaelwoerister:new-cpp-like-enum-debuginfo, r=wesleywiser
  commit[6] 2022-08-15UTC: Auto merge of #100569 - matthiaskrgr:rollup-9450lzs, r=matthiaskrgr
  commit[7] 2022-08-15UTC: Auto merge of #100595 - matthiaskrgr:rollup-f1zur58, r=matthiaskrgr
validated commits found, specifying toolchains

checking the start range to verify it passes
installing 801821d1560f84e4716fcbd9244ec959320a13d5
testing...
error: no such subcommand: `+bisector-ci-801821d1560f84e4716fcbd9244ec959320a13d5-x86_64-pc-windows-msvc`

        Cargo does not handle `+toolchain` directives.
        Did you mean to invoke `cargo` through `rustup` instead?
RESULT: 801821d1560f84e4716fcbd9244ec959320a13d5, ===> Yes

The toolchain is installed, though, and I'm able to run it directly via cargo +bisector-ci-801821d1560f84e4716fcbd9244ec959320a13d5-x86_64-pc-windows-msvc version.

My guess would be that there is an issue with the PATH environment variable. cargo-bisect-rustc just executes the command "cargo" from your PATH (although the lookup rules on windows is complicated), it doesn't use the one from the downloaded toolchains.
I'd verify that ~/.cargo/bin is first in your PATH. It might also help to report which version of cargo-bisect-rustc you are using, and which version of Rust you used to build it.

I just tested on my machine and have no problem running cargo bisect-rustc -- version
but when I specified --start and --end or only -vv things broke down.
Working:
cargo bisect-rustc -- version
checking the start range to find a passing nightly
installing nightly-2023-01-22
rust-std-nightly-x86_64-pc-windows-msvc: 27.22 MB / 27.22 MB testing...
RESULT: nightly-2023-01-22, ===> Yes
uninstalling nightly-2023-01-22

checking the start range to find a passing nightly
installing nightly-2023-01-20
rust-std-nightly-x86_64-pc-windows-msvc: 27.18 MB / 27.18 MB esting...
RESULT: nightly-2023-01-20, ===> Yes
uninstalling nightly-2023-01-20

checking the start range to find a passing nightly
installing nightly-2023-01-18
rust-std-nightly-x86_64-pc-windows-msvc: 27.14 MB / 27.14 MB testing...
RESULT: nightly-2023-01-18, ===> Yes
uninstalling nightly-2023-01-18

Not working:
cargo bisect-rustc --start 2023-01-20 -- version
checking the start range to find a passing nightly
installing nightly-2023-01-20
rust-std-nightly-x86_64-pc-windows-msvc: 27.18 MB / 27.18 MB testing...
RESULT: nightly-2023-01-20, ===> Yes
uninstalling nightly-2023-01-20

ERROR: the start of the range (nightly-2023-01-20) must not reproduce the regression

cargo bisect-rustc -vv -- version
checking the start range to find a passing nightly
installing nightly-2023-01-22
rust-std-nightly-x86_64-pc-windows-msvc: 27.22 MB / 27.22 MB
testing...
error: no such command: `+bisector-nightly-2023-01-22-x86_64-pc-windows-msvc`

        Cargo does not handle `+toolchain` directives.
        Did you mean to invoke `cargo` through `rustup` instead?
RESULT: nightly-2023-01-22, ===> Yes
uninstalling nightly-2023-01-22

checking the start range to find a passing nightly
installing nightly-2023-01-20
rust-std-nightly-x86_64-pc-windows-msvc: 27.18 MB / 27.18 MB testing...
error: no such command: `+bisector-nightly-2023-01-20-x86_64-pc-windows-msvc`

        Cargo does not handle `+toolchain` directives.
        Did you mean to invoke `cargo` through `rustup` instead?
RESULT: nightly-2023-01-20, ===> Yes
uninstalling nightly-2023-01-20

where cargo executed cmd returns C:\Users\user\.cargo\bin\cargo.exe but Command::new() returns
C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe
C:\Users\user\.cargo\bin\cargo.exe

Running cargo-bisect-rustc -vv -- verison instead of cargo bisect-rustc -vv -- verison fixes the issue. Apparently if command is run through cargo some additional paths are prepended to path: C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib;C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin;

Can you show which version of rustup you have and what your PATH looks like?  I suspect it is https://github.com/rust-lang/rustup/issues/3036, and it may be an issue with PATH.

rustup --version
rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.66.0 (69f9c33d7 2022-12-12)`

My path is:
C:\Program Files\Common Files\Oracle\Java\javapath;C:\Program Files\Eclipse Adoptium\jre-8.0.332.9-hotspot\bin;C:\Program Files\Eclipse Adoptium\jre-17.0.3.7-hotspot\bin;C:\Program Files\Eclipse Adoptium\jre-11.0.15.10-hotspot\bin;C:\Program Files (x86)\Eclipse Adoptium\jre-8.0.332.9-hotspot\bin;C:\Program Files\Python310\Scripts\;C:\Program Files\Python310\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files (x86)\dotnet\;C:\Program Files\dotnet\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\FirefoxPWA\;c:\page;C:\Users\user\AppData\Roaming\nvm;C:\Program Files\nodejs;C:\Program Files\Streamlink\bin;C:\Program Files (x86)\Calibre2\;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;C:\Users\user\.cargo\bin;C:\Users\user\AppData\Local\Microsoft\WindowsApps;C:\Users\user\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\user\ffmpeg\bin;C:\Users\user\AppData\Roaming\Python\Python310\Scripts;C:\Users\user\AppData\Roaming\nvm;C:\Program Files\nodejs

and when running cargo run on my test program:
fn main() {
    println!("{}", std::env::var("PATH").unwrap());
    let mut cmd = std::process::Command::new("cmd");
    cmd.arg("/C");
    cmd.arg("where");
    cmd.arg("cargo");
    cmd.status().unwrap();
}

those paths gets prepended: C:\Users\user\tester\target\debug\deps;C:\Users\user\tester\target\debug;C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib;C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin;

Yea, the issue is https://github.com/rust-lang/rustup/issues/3036.  I have posted a fix there for it.

The fix for here would be to use rustup run {toolchain} cargo {subcommand}. I have done it on each of my windows machines, and it works correctly.

Update on this: This can be fixed by setting the environment variable RUSTUP_WINDOWS_PATH_ADD_BIN=0. We hope to change the default option for that in rustup in the future.

Yup worked, thanks!

This should now be fixed by default with rustup 1.27.1 released today.

authors: MingweiSamuel albertlarsan68 ehuss jszwedko sagudev

repo: rust-lang/cargo-bisect-rustc


text:
[git] ~ in init.templatedir

Hi
In my git config file, init.templatedir is set to ~/.config/git/template. When I launch cargo new -v test, it fails saying that ~/.config/git/template doesn't exist. When I replace ~ by /home/<user>, the command successes.
It seems that cargo doesn't expand ~.

Looks like this is a bug in libgit2 right now, I've opened a bug with them: https://github.com/libgit2/libgit2/issues/2814

Cool, thanks !

I believe this was fixed in a recent libgit2 update, but please reopen if it still happens!

No, the problem is still there with 2015-03-24...

Ah well.

Oh right this was a time when cargo nightlies weren't getting built, I just checked again and confirmed that this is fixed, yay!

authors: Yamakaky alexcrichton

repo: rust-lang/cargo


text:
New arm target missing from cargo manifests

The new armv7 target hasn't been introduced in the crates ecosystem yet, [predictably]  (https://github.com/rust-lang/rust/pull/30948#issuecomment-176646360 ) resulting in errors like this:
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/libssh2-sys-0.1.34/lib.rs:10:1: 10:26 error: can't find crate for `openssl_sys` [E0463]
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/libssh2-sys-0.1.34/lib.rs:10 extern crate openssl_sys;
                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~~

BTW, @alexcrichton well spotted fixing the .mk file - I was going to open a PR myself.
I was also wondering if on the last line:
CFG_GNU_TRIPLE_armv7-unknown-linux-gnueabihf := armv7-unknown-linux-gnueabihf
it was really necessary to differentiate from arm-?

I don't think this is a particularly actionable bug in Cargo itself, it'll just take time for the target to be found on the stable/beta compilers. If you use a nightly compiler to build the target then everything should work just fine. Cargo itself has no knowledge of targets or target triples, so it's just the underlying compiler that needs to be updated here (or perhaps a stale build directory?)

I was using a bootstrapped compiler - otherwise I wouldn't even have the necessary rlibs to try this.
I'm well aware cargo itself doesn't know about targets, etc; when I jokingly wrote about "telling cargo" I meant stuff like this:
https://github.com/sfackler/rust-openssl/blob/master/openssl-sys/Cargo.toml#L39
or this:
https://github.com/tomaka/glutin/blob/master/Cargo.toml#L96
So I meant you probably had the tools to automatically fix the affected crates.

Oh yeah for those you can just send PRs to update them (or wait for the cfg-in-dependencies to get implemented)

authors: alexcrichton petevine


text:
updated yank error message

Fixing issue #8695

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Eh2406 (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

I think there will probably need to be tests updated. If not then we will need to figure out how to add a test.
@ehuss What do you think of the new text?

Perhaps .required(true) can just be added to the --vers flag and let clap handle it. That would make the help text better (it explicitly shows --vers is required), and the error would look like this:
error: The following required arguments were not provided:
    --vers <VERSION>

USAGE:
    cargo yank [OPTIONS] --vers <VERSION> [--] [crate]

For more information try --help

This works better and is a good idea, but now the test alt_registry::bad_registry_name fails because it expects the --vers argument. Should I remove yank cmd from this test?

It works using .required_unless("registry"). Would this be a good option?

You can just put in a bogus version to fix that test, like this:
diff --git a/tests/testsuite/alt_registry.rs b/tests/testsuite/alt_registry.rs
index f9129e284..c3ed37633 100644
--- a/tests/testsuite/alt_registry.rs
+++ b/tests/testsuite/alt_registry.rs
@@ -637,7 +637,7 @@ Caused by:
         "owner",
         "publish",
         "search",
-        "yank",
+        "yank --vers 1.2.3",
     ] {
         p.cargo(cmd)
             .arg("--registry")

Alright I did it.

Thanks!
@bors r+

:pushpin: Commit 51fa3a4d28c9cf9ebea6d7adef3a949025827ef9 has been approved by ehuss

:hourglass: Testing commit 51fa3a4d28c9cf9ebea6d7adef3a949025827ef9 with merge 8777a6b1e8834899f51b7e09cc9b8d85b2417110...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 8777a6b1e8834899f51b7e09cc9b8d85b2417110 to master...

authors: Eh2406 Mikastiv bors ehuss rust-highfive


text:
Add documentation about third-party registries.

This adds a link to the wiki where a list of third-party registries can be maintained.

r? @Eh2406
(rust-highfive has picked a reviewer for you, use r? to override)

@bors: r+

:pushpin: Commit a5e069722a0d1b36194c30f4023d89100e726f7b has been approved by alexcrichton

:hourglass: Testing commit a5e069722a0d1b36194c30f4023d89100e726f7b with merge 835d5576e1f0b917a42ba18a9556242204377cd1...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 835d5576e1f0b917a42ba18a9556242204377cd1 to master...

authors: alexcrichton bors ehuss rust-highfive


text:
Skip interactive prompts if CI environment variable is set

This is a consistent variable that various CI environments define for the purpose of tooling to change its defaults to make more sense in a noninteractive context.

https://docs.travis-ci.com/user/environment-variables/#default-environment-variables
https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables
https://www.appveyor.com/docs/environment-variables/

The readme calls out that cargo miri setup avoids the prompts but it shouldn't be necessary; CI should be able to go directly to cargo miri test.

So you are basically saying that if env::var_os("CI").is_some(), we should skip prompts? That makes sense. I didn't know such a general env var existed. Thanks for bringing this up!

authors: RalfJung dtolnay

repo: rust-lang/miri


text:
Rust support across macOS and Windows versions

Currently we support the following targets for Windows & macOS. An issue that has crept more over time is that the specific OS versions that were initially put for support, are no longer tested and built by Rust. This is for a variety of reasons, the main one being that we are bound by the OS versions provided by our CI providers.

platform
OS

i686-apple-darwin
32-bit OSX (10.7+, Lion+)

i686-pc-windows-gnu
32-bit MinGW (Windows 7+)

i686-pc-windows-msvc
32-bit MSVC (Windows 7+)

x86_64-apple-darwin
64-bit OSX (10.7+, Lion+)

x86_64-pc-windows-gnu
64-bit MinGW (Windows 7+)

x86_64-pc-windows-msvc
64-bit MSVC (Windows 7+)

Potential Solutions

Update Rust's target guarentees to the latest releases.
Update our platform targets to be OS aware.

Not sure how effective this would be as currently Apple and Microsoft have two completely different release schemes. Apple annually releases OS's with breaking changes, and Microsoft will likely not publish a new numbered version of Windows any time in the near future.

Okay, how do we communicate this change? Is this something that needs to be part of the Target Tier Policy RFC, its own RFC, or just an update to the forge documentation?

To be clear, I believe that the change we are considering is changing the minimum OS X version to 10.13 (from 10.7), which falls in line with Apple support (per https://github.com/rust-lang/rust/issues/50776#issuecomment-574252166).
I believe that we should prepare an RFC, similar to @pietroalbini's 32-bit Apple demotion to tier 3 RFC, and aim to land that. The RFC would be slightly different in that it would set a minimum bar that on Apple, we support no earlier than latest publicly security-release targeted versions by the vendor (only Apple, in this case). As of today, that's 10.13.

@Mark-Simulacrum What about Windows? We have the same problem with Windows 7/8, where we don't have machines to test with.

Ah, looks like Windows 7 is also EOL (https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information) so we can include stripping it per the same reasoning. I don't think we should do the same for Windows 8.1, as it looks like extended support extends into 2023 for that.
We may not have machines, but this policy is also not about that. As we've discussed on this thread, these support tiers are mostly about "we will do our best to support this target" vs. "we will close/ignore bugs found" -- or so is my interpretation. Obviously, if we don't have available machines, it's highly likely bugs will get fixed very slowly, if at all, but they at least won't get closed out of hand.

@Mark-Simulacrum Windows 7 has Extended Security Updates till 2023 for companies: https://support.microsoft.com/en-us/help/4527878/faq-about-extended-security-updates-for-windows-7

Good to know! I do still think that Rust probably needs to say that we don't really support Windows 7 because I don't think it's really feasible for anyone on the Rust teams to support it -- we just don't have the ability to install it I imagine.

Are you aware that Windows 7 alone is more than 10 times more popular than Linux? It is too early to abandon Windows 7.

I can provide remote access to a PowerMac G5 running OS X 10.5.
Send your SSH authorizes_keys file to ''noloader, gmail account''. In return's I'll make you an admin on the box and send you the IP to connect.

@Mark-Simulacrum,

Ah, looks like Windows 7 is also EOL (https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information) so we can include stripping it per the same reasoning.

Negative. Windows 7 still has a 28% of market share. The market determines when an OS is no longer needed, not a company suffering seller's regret.

@vrubleg @noloader Platform support is not solely a popularity contest and Rust runs on a lot of different kinds of architectures and machines not just desktops so there are more considerations and constraints at play than simply "which has the most people?". There's also a meaningful difference here between being able to build rustc and tooling to run on Windows 7 and being able to build your application with Rust that runs on Windows 7. This is mostly a discussion about the former AFAIU.

I wrote this topic in the forum while ignorant of this issue.
As far as I understand it, in practice Rust only has full tier 1 support (as currently defined) for Windows 10 1607 and 1809. That is, those are the two that can be tested on Azure. Downgrading Windows 7 to a separate tier would better reflect reality. Or perhaps, as has been suggested, it may be better to change how support is explained.
Of course this shouldn't mean the platform will be abandoned or that bugs wouldn't be fixed. It's just a statement of how things are. rustc developers can still endeavour to avoid making changes that they know will break Windows 7. And if there are enough developers using Windows 7 (and 8.1, etc) there will hopefully be enough to run tests, raise issues and submit PRs in the event that anything does break. This is how things are right now, whatever the policy says.

To be clear, the current tier 1 policy is:

Tier 1 platforms can be thought of as "guaranteed to work". Specifically they will each satisfy the following requirements:

Official binary releases are provided for the platform.
Automated testing is set up to run tests for the platform.
Landing changes to the rust-lang/rust repository's master branch is gated on tests passing.
Documentation for how to use and how to build the platform is available.

As it stands today, Windows 7 only fulfils the first and last of those bullet points.

Maybe there's also a role here for platform vendors to support the Rust project in maintaining support for older releases? @rylev does MS have thoughts about they might want to handle this going forward?

I think @danielframpton might have a more clear opinion on this. I'll let him answer before I add any of my own (personal) opinions.

Microsoft will likely not publish a new numbered version of Windows any time in the near future.

Sorry to be nitpicky here but this is only really true in the same sense that MacOS was stuck on version 10 for two decades. New versions of Windows will always be under the "Windows 10" umbrella from now on but that's not relevant in terms of their release scheme.
Microsoft releases a new version of Windows twice a year which are marketed using a year/month scheme. For example, the latest is "2004" aka "April 2020". These releases each have their own support lifetime. Individually each release is much smaller than, for example, the transition from 8.1 to 10 was. However the releases are cumulative so going from 1507 to 2004 could potentially be a very big change (albeit somewhat mitigated by Windows' commitment to backwards compatibility).
All this is to say that when we talk about which platforms are tested it makes more sense to talk specifically about 1607, 1809, etc. In this context saying merely "Windows 10" is not very helpful unless we actually test all 10 versions of Windows 10.

As an additional bit of data point, we might want to take into account platform data gathered also from the Rust Survey 2019. Perhaps the 2020 survey could break down a bit the Windows platform into 7, 8, 10/1507, 10/2004, ...) to gain insights on what developers are really using/interested in.

The new target tier policy in RFC 2803 has something to say about all of this. (Thanks @inquisitivecrystal for pointing this out.)

Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.

For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

We still have open questions about CI though, because we simply don't have the means to test all versions from that oldest baseline -- often we only have access to the most current.

Windows 8.1 support and Windows 7 Extended Security Updates have ended on January 10, 2023, and no ESU for Windows 8.1 is provided (reference).

Right, the plan for Windows target bumps was discussed in MCP 651.

authors: ChrisDenton Mark-Simulacrum XAMPPRocky apiraino cuviper djc noloader rylev tesaguri vrubleg

repo: rust-lang/release-team


text:
[Proposal] Compiler should prevent compile code that can panic if it is may be used from C

#[no_mangle]
pub extern fn oh_no() -> i32 {
        panic!("Oops!");
}
fn main() {}

This should not be compiled because it may be called from C code
https://doc.rust-lang.org/nightly/book/ffi.html

You want to be able to use regular rust functions inside extern functions; forbidding panicking also means forbidding use of these functions, because they may panic as well.

Could compiler know about does function may panic? It must know. Function metadata may be extended with this information. It will prevent many errors. It will make compiler more complex, but it will prevent many errors that can occur.

Sure it could, but this information is pretty useless to the compiler. Like I said, there’s almost no panic-less rust code: addition (x+y) panics if it overflows, indexing slices panics if it is out of bounds and so on.
Basically, what you are suggesting is to forbid use of 99.99% (and probably even more nines) of rust code inside extern blocks; something we can’t and most likely don’t want to do. What you might want to do instead is to use catch_panic in any function that you expect to go across FFI. Checking for lack of catch_panic sounds like scope of lint project such as rust-clippy.

@nagisa You are right.

authors: KalitaAlexey nagisa

repo: rust-lang/rfcs


text:
RFC: 'task lifetime

 Issue by huonw
Saturday Aug 24, 2013 at 00:06 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/8726
This issue was labelled with: A-lifetimes, B-RFC in the Rust repository

Add a 'task lifetime that represents things that live as long as the task, e.g. borrowing a @T would give a &'task T.
I haven't met any instance where I really needed this; but @bblum said he'd be interested, and I have met a few lifetime issues with borrowing things out of @ in a chain (but this is probably just #3511).

cc https://github.com/rust-lang/rfcs/pull/1705

Seeing as how we closed the 'thread RFC and we no longer even have tasks, this issue seems irrelevant nowadays. Closing.

authors: nrc rust-highfive withoutboats