text:
Integrating ruby/debug with Rails to replace byebug through a single "debugger" call

Love the progress with this! We'd very much like to make ruby/debug the default debugger in Rails 7. This would replace byebug, which has been the default for 7 years. But to do that, and retain the same developer experience, we're looking for a way to retain a similar interface.
That means being able to require ruby/debug either all the time or at least all the time in development, and then jumping into the debugger merely by adding a call to "debugger" anywhere in the code base (alternatively using "binding.break", but I find the "debugger" call more intuitive).
Is this approach compatible with the aspirations of ruby/debug? If so, is there anything we can do to help it along, such that we can make the switch for Rails 7?
✌❤

That means being able to require ruby/debug either all the time or at least all the time in development, and then jumping into the debugger merely by adding a call to "debugger" anywhere in the code base

Just to share my experience here: my project (Rails 6.1) has installed the debugger for 2 weeks and requires it by default in both development and test environment (even when running on CI). It doesn't break any test case, Rails/Rake task. It also doesn't slow the application in any obvious way. And whenever we need to debug, we just use binding.b to enter a debugging session. So I think this is possible already 🙂

However, the current implementation assumes that loading the gem means you want to start a session:
% ruby -rdebug -e1
DEBUGGER: Session start (pid: 73510)

In a Rails application, ideally you'd require the gem via Bundler as usual, and have binding.break (or whatever) start the session if not already started. I believe this alternative pattern fits better web applications in development. Could be behind a configuration point for backwards compat (provided that is possible).

I see. This is the discussion that led to the current design: https://github.com/ruby/debug/issues/65
From my understanding, debugger session records every iseq sequence that's loaded once it's started.
https://github.com/ruby/debug/blob/c5917c529b99dee8a7e27ec6abdc2c8e70d4e6f6/lib/debug/session.rb#L86-L89
(which eventually leads to here)
https://github.com/ruby/debug/blob/c5917c529b99dee8a7e27ec6abdc2c8e70d4e6f6/lib/debug/session.rb#L1304-L1317
So if the debugger session only starts after binding.b is called, all the code loaded before it would not be stored into the debugger's SourceRepository.
And later affect the source the debugger can retrieve
https://github.com/ruby/debug/blob/c5917c529b99dee8a7e27ec6abdc2c8e70d4e6f6/lib/debug/session.rb#L265-L271
https://github.com/ruby/debug/blob/c5917c529b99dee8a7e27ec6abdc2c8e70d4e6f6/lib/debug/frame_info.rb#L62-L64

Ah, I just tested this now. It's actually doing the right thing. It doesn't halt execution on require, which is what I thought. So we can just remove require: false from the Gemfile.
It does, however, output a noisy "DEBUGGER: Session start (pid: 48334)". Is it possible to turn that off?

Also, still wish it was possible to just called "debugger" instead of "binding.b". But that's a minor point.

I've turned it on by default for Rails 7 dev/test. So this isn't really a problem. Would be nice if there was a way not to get the output statement, and I'd still love "debugger" as an alias for "binding.b", but this is great in any case.

I just investigated this a little bit more. If we require debug by default in the Rails framework, and you use the vscode extension (which will call rdbg) or use rdbg directly you get two debug sessions. The reason for that is that lib.debug.rb starts a session and rdbg will start another one requiring debug/open or debug/start.
Would it possible to not start the session using ruby -r debug and always use ruby -r debug/start? and only use debug to providing the biding methods and setup tracepoint?

@rafaelfranca sorry I couldn't catch the points.
lib/debug.rb should not be used if
(1) rdbg is used
(2) require 'debug' with Gemfile and bundle exec.
But lib/debug.rb can be required if
(3) require 'debug' in Ruby 2.7 or before without Gemfile and bundle exec.
Could you check the situation and make another issue with your reproduce process?
Thanks.

Ah, I can repro and make new issue.

repo: ruby/debug


text:
Restart threads on DAP evaluation

This makes sure DAP evaluation request also doesn't hang.
See #947 for the original console implementation.

@ono-max I tried implementing the same change for CDP as well but it still hangs. So I will leave that to you.

[master]$ git diff
diff --git a/lib/debug/server_dap.rb b/lib/debug/server_dap.rb
index 8298428..bae1e4d 100644
--- a/lib/debug/server_dap.rb
+++ b/lib/debug/server_dap.rb
@@ -625,6 +625,7 @@ module DEBUGGER__
           expr = req.dig('arguments', 'expression')

           if find_waiting_tc(tid)
+            restart_all_threads
             request_tc [:dap, :evaluate, req, fid, expr, context]
           else
             fail_response req
@@ -701,6 +702,7 @@ module DEBUGGER__
         register_vars result[:variables], tid
         @ui.respond req, result
       when :evaluate
+        stop_all_threads
         message = result.delete :message
         if message
           @ui.respond req, success: false, message: message

could you add stop_all_threads?

Ah I thought it's handled in Session#process_event too. I've updated code but will try to put up a test case for thread-stopping too.

I think I found another issue: when I run the test, the result was not deterministic even without sleep and fails around 10% of the time on my machine.
I initially thought it's because of my test, but then I found that it's because this early return isn't always correct. Sometimes it doesn't reflect the actual running thread count and thus the debugger doesn't stop the threads. If I comment it out, the test doesn't fail intermittently anymore. Should I address that in this PR too?

Now current behavior is already non-deterministic (by design).
Essentially this is hard to write a test for such cases.

As the test could make CI unstable, I've dropped it.

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
Rename RescueNode#exception to RescueNode#reference

Fixes #1160

Okay, let me know when it's ready.

I'm closing out for the weekend so going to merge this. I really want to figure this out going forward, otherwise it's impossible to make breaking changes without waiting for y'all to make changes. Maybe we could mark the check as optional.

@kddnewton The usual strategy for this is to wait that TruffleRuby adopts the change, and then when that's merged we can merge here and no CI breaks. So if this is not urgent I would wait for that.

@eregon @kddnewton I can see the benefits of wanting people to see breaking changes on TR for bug fixes, but for development work this creates a backwards dependency.
If I submit a PR here (X) to change something then if we followed your process and I was willing to submit a PR (Y) to your repo first (and let's just pretend that is no work but just something which just happens); then I think this assumes YARP development is some single linear process.
So Y is landed, then someone in yarp fixes a different bug with a PR (Z), then we land X.  In this case Z is red and has nothing to do with the PR you fixed with Y.  That will be confusing to the author of Z. Other scenarios (WIP PRs, language level changes needing githubaction changes depending on language level TR has) but right now this one feels like it would be common.
If we adopted the same process for JRuby,  then we have to have two consuming repositories do PRs before the PR can land on YARP.  That ignores some of YARPs CI will catch things which would be hard to test locally (so it would be nice to see that before two PRs land in other projects).
I wonder if there is some other way of achieving the goals here.  Correct me if I am wrong @eregon but you want to make sure if someone breaks TR from a fix there is a chance for them to notice that and reject the PR (or at least consult about what happened).

I think the main issue is once it's red nobody will notice if there is another incompatible change or a bug slipping in.
And so it might be hard to get back to green if that happens (e.g. if Java deserialization is broken and has multiple bugs it quickly becomes challenging to fix it, that already happened before the check was there).
I think the existing process of merging in TruffleRuby first and in YARP right after works well for most cases.
The main alternative I see is to avoid breaking that check, for instance in this case by keeping the old field or so. It often feels hacky or overhead though or it might not be reasonably possible.
I also thought at some point to only do the "can it deserialize cleanly" check (maybe running it on JRuby if it doesn't depend on specific YARP node names and field names). But that's weaker in terms of testing than actually checking it works for a real usage of YARP, i.e., as TruffleRuby uses it. I think so far this usage is the only one that really checks the AST makes sense and has the relevant information. Nothing else in CI really uses YARP nodes for execution yet, e.g., if there was an incorrect node as the receiver of a CallNode, I think nothing would notice it except that check.
If we do a bunch of field/node renames then it probably makes sense to group them, and similarly for other related breaking changes, so there is less often the need to merge things in a particular order.

authors: enebo eregon kddnewton

repo: ruby/yarp

license: MIT


text:
DistributionsController#create should be cleaned up

There are currently 3 different branches in that action that result in render :new.
My gut says there is probably some redundancy here that could be reduced.

working on this

source: gharchive/issue

repo: rubyforgood/diaper

license: mit

license_source: bigquery


text:
Developer login

Hello, I've enabled development login as needed in issue #73. Now when you signin, you should see this screen:

And you can choose which authentication to use in development by using the environment variable FORCE_AMAZON_LOGIN. (true/false)
It disables csrf protection only in development mode and to the developer auth provider.

Thanks for the PR! :tada: I'll take a look at it tomorrow.

Hey @leesharma, did it! :D

Awesome, thanks! 👍

authors: gabteles leesharma

repo: rubyforgood/playtime


text:
REST server 프로젝트 구성

Django REST를 이용하여 API server를 구성한다.

django rest가 아닌 express.js + ORM을 이용해 구성하도록 한다


text:
Cannot auth with password only

Redis can be configured with requirepass which makes AUTH command accept a password without username. Currently, there is no option for this. AUTH command can only initiated with username and password.
Source: https://redis.io/commands/auth/
https://github.com/rueian/rueidis/blob/a525ad43300a4ea316a8ca1355a46752ee8be8ea/pipe.go#L73-L79

Hi @nerg4l,
Thank you for pointing it out.
In the new v0.0.45, it will use the default username if no username but password provided according to https://redis.io/commands/hello/

Thanks

repo: rueian/rueidis


text:
question for image selected in every individual

Dear author,
Can you explain specifically which cross-section  image each individual selected comes from, or was it selected manually? Your article is great, but I would like to know how to select CT cross-sections for specific individual images.  Can you provide an image example?

Hello, thank you for your question. For each individual, 2D axial slices with the largest tumor area along the z-axis from 3D CT images were selected as the input of diagnostic model.

thanks for your response! .could you send me  sample clinical data and i am  trying to reproduce your paper. Here is my email-address(3346720994@qq.com)

repo: ruitian-olivia/STIC-model


text:
Archive site under 2014.rulu.eu

Ship this with rulu-eu/rulu2017/pull/1

👌

authors: dmathieu mehlah


text:
[Question]: How to proper load a Redis Vector Store

Question Validation

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

Question
Suppose i create a vector store like:
# Define the IndexSchema
embed_model = OpenAIEmbedding(
    embed_batch_size=10,
    model="text-embe,
    api_key=API_KEY,
)
vector_store = RedisVectorStore(redis_client=redis_client, schema=index_schema, overwrite=True)

documents = [Document(text=item, metadata={"merchant_id": "test"}) for item in items]
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents, storage_context=storage_context, embed_model=embed_model)

If a query it like:
retriever = index.as_retriever(
    similarity_top_k=3,
    filters=MetadataFilters(filters=[ExactMatchFilter(key="merchant_id", value="test")])
)
query_bundle = QueryBundle("pizza")

retrieved_nodes = retriever.retrieve(query_bundle)
print(retrieved_nodes)

I got results. nice.
But when i try to load it like:
vector_store = RedisVectorStore(
    index_schema=index_schema,
    redis_client=redis_client,
    overwrite=False,
)

index = VectorStoreIndex.from_vector_store(vector_store, embed_model=embed_model)
retriever = index.as_retriever(
    similarity_top_k=3,
    filters=MetadataFilters(filters=[ExactMatchFilter(key="merchant_id", value="test")])
)
query_bundle = QueryBundle("Pizza")

retrieved_nodes = retriever.retrieve(query_bundle)
print(retrieved_nodes)

I get :
merchant_id field was not included as part of the index schema, and thus cannot be used as a filter condition.
[]
What is wrong with the way I am loading it?

@luccazifood initially you have
RedisVectorStore(redis_client=redis_client, schema=index_schema, overwrite=True)
But then when loading,
vector_store = RedisVectorStore(index_schema=index_schema, redis_client=redis_client, overwrite=False)
Notice the switch from schema= to index_schema= ?

The correct kwarg is schema=

ohhh thanks @logan-markewich ! think I need to take a break lol

authors: logan-markewich luccazifood


text:
[Bug] Wrong Runtime if task failed

Hello, faced interesting issue:
state: RUNNING
createdAt: 2023-10-20T01:19:56.420301Z
scheduledAt: 2023-10-20T01:19:56.424951Z
startedAt: 2023-10-20T07:12:15.879177Z
failedAt: 2023-10-20T01:19:56.252516Z

So, if task was failed we can see incorrect Runtime in tork-web
Will be nice to see some Fail counter near the task State

When it completed time is correct:

@ppcololo this should be fixed. could you confirm?

I don't know what did you fix, but I still see this issue:

coordinator:

Can you try again using the latest release?

I will try, thanks.
But can't reproduce it right now.
If I have an issue then write here

createdAt: 2023-11-11T04:32:06.689706Z
scheduledAt: 2023-11-11T04:32:06.700287Z
startedAt: 2023-11-11T05:37:18.931082Z
failedAt: 2023-11-11T04:32:06.675842Z```

New data: no time at all

for running task
state: RUNNING
createdAt: 2023-11-15T11:46:35.067896Z
scheduledAt: 2023-11-15T11:46:35.091199Z
startedAt: 2023-11-15T11:46:35.214332Z
failedAt: 2023-11-15T11:46:35.0151Z

for completed
state: COMPLETED
createdAt: 2023-11-13T20:33:12.05211Z
scheduledAt: 2023-11-13T20:36:03.056434Z
startedAt: 2023-11-15T03:16:02.248571Z
completedAt: 2023-11-15T03:16:03.156508Z

Can you try again using the latest release?

I didn't see any issues
closing

authors: ppcololo runabol

repo: runabol/tork-web


text:
Hi, could we PLEASE get a larger health bar?  The current one is too short

The problem is that I like to PvP and knowing what your health is, as exactly as possible, is important.
This is why I would LOVE to have a longer health bar, so it's easier to see how much hp I have
Numbers over the current health bar would also be amazing

Thank you!

You're welcome

The healthbar above the player is limited, since the values used for it aren't representative of the actual health values; this is a Jagex limitation. A wider health bar would not make it more granular. Status Bars or the hp orb are much better ways of showing this.

authors: Hydrox6 MyopicHuman Whowhos

repo: runelite/runelite


text:
Add combined option "Europe" to quick-hop region

If you are based in Europe, the UK and Germany worlds usually have very similar ping, being able to utilize a larger pool of worlds for quick hopping while maintaining a decent ping would be handy.

added in f6a3d222b4986ab7beab54b650797f2821f5852c

authors: Adam- Jin-Jiyunsun


text:
Hot/Cold Clue Solver

https://twitter.com/bitterkoekjers/status/840219782372839424
I feel this would be hard to implement, but if done would be amazing. If you knew the exact ranges of what each temperature meant for how close you are to the clue (not sure if that is documented anywhere) then you could effectively have a plugin that narrows down the locations for you over time.

I've got a working solution for this. I need to clean up my code and work on the UI a bit, but I should be able to do a PR soon.
Here's some teasers:
https://streamable.com/370tj
https://streamable.com/hrgrq
https://streamable.com/gb8bn

Done in #2412

authors: Adam- Eadgars-Ruse Jalopyy


text:
"Reset others" in loot tab

Is your feature request related to a problem? Please describe.
Currently have to reset all manually when I want to track a single monsters loot after I have looted a few e.g. slayer tasks.
Describe the solution you'd like
A "Reset others" option like in the exp tracker.

Its not that hard to simply click reset multiple times

authors: deathbeam michaelcubel


text:
player indicators: Add clan caller

adds a clan caller option to the player indicators which will show clan caller name as well as show clan callers target name

Any news on this?

My comments still apply, the options should be renamed to just highlight etc to be more universal

authors: deathbeam mrpker9 sethtroll


text:
events: Fix ItemContainerChanged NPEs

`ItemContainerChanged.getItemContainer()' is nullable, therefore should
be null-checked in subscribers. This commit marks the field as nullable
and changes its usages to properly null-check it.

Is this necessary? Because its doing reference checks everywhere, so null checking it is irrelevant, unless both sides will be null, what I dont think can happen? Or at least, I never saw NPE from those methods before. Do you have stacktrace or something?

Does it make sense to send item container changed events for a null container?

I'll get some stacktraces later today, but I noticed NPEs from most plugins using ItemContainerChanged on startup with empty inventory/equipment.

FWIW I can't repro on release. This is from master, which is currently ad2cce60b.

stacktraces
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.cluescrolls.ClueScrollPlugin.onItemContainerChanged(ClueScrollPlugin.java:246)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.runecraft.RunecraftPlugin.onItemContainerChanged(RunecraftPlugin.java:186)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.timers.TimersPlugin.onItemContainerChanged(TimersPlugin.java:811)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.roguesden.RoguesDenPlugin.onItemContainerChanged(RoguesDenPlugin.java:99)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.cannon.CannonPlugin.onItemContainerChanged(CannonPlugin.java:164)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.cluescrolls.ClueScrollPlugin.onItemContainerChanged(ClueScrollPlugin.java:246)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.runecraft.RunecraftPlugin.onItemContainerChanged(RunecraftPlugin.java:186)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.timers.TimersPlugin.onItemContainerChanged(TimersPlugin.java:811)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.roguesden.RoguesDenPlugin.onItemContainerChanged(RoguesDenPlugin.java:99)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)
2019-07-11 16:02:02 [Client] WARN  n.runelite.client.eventbus.EventBus - Uncaught exception in event subscriber
java.lang.NullPointerException: null
	at net.runelite.client.plugins.cannon.CannonPlugin.onItemContainerChanged(CannonPlugin.java:164)
	at net.runelite.client.eventbus.EventBus$Subscriber.invoke(EventBus.java:72)
	at net.runelite.client.eventbus.EventBus.post(EventBus.java:218)
	at net.runelite.client.util.DeferredEventBus.replay(DeferredEventBus.java:69)
	at net.runelite.client.callback.Hooks.updateNpcs(Hooks.java:469)
	at client.lc(client.java:63774)
	at w.hq(w.java)
	at client.hg(client.java:6630)
	at client.ew(client.java:3324)
	at client.au(client.java:1621)
	at ba.p(ba.java:393)
	at ba.run(ba.java:372)
	at java.lang.Thread.run(Thread.java:748)

this has been addressed internally.

authors: Adam- Nightfirecat deathbeam


text:
Add travis' validation of "Signed-off-by:" line

This adds validation of "Signed-off-by:" line.
Signed-off-by: Fabio Utzig utzig@apache.org

Regarding the comment suggesting to add commiter checking as well as author:
[utzig@inspiron mcuboot]$ git show -s --format="%cn <%ce>" cb1bb48
David Brown <davidb@davidb.org>
[utzig@inspiron mcuboot]$ git show -s --format="%an <%ae>" cb1bb48
David Brown <david.brown@linaro.org>

I'm not sure it would be a great idea at the moment. I would prefer to work on it later in a new patch (if at all).

You should only ever see the davidb.org commit after github rebases it. It is using my primary account for the rebase, as far as it is concerned.
You should always be ok adding the committer check, and when added, it will usually be after the author Sob.

Added check for commiter as well, let's see how it goes.

repo: runtimeco/mcuboot


text:
fastsdcpu offline?

I want to know if there's a way to use fastsdcpu offline.
How can i use the models I have on A1111/models/StableDiffusion folder on my PC
I will convert the models into OpenVINO models follown de scrits.
Should I modify stable-diffusion-models.txt or settings.yaml?
The models are located in D:/A1111/models/StableDiffusion
I'm new on Stable Diffusion, need help and step by step instruction

@bjivanovich  Thanks for using FastSD CPU, enable this setting
Checkout this https://github.com/rupeshs/fastsdcpu?tab=readme-ov-file#models

@bjivanovich LCM-LoRA offline tutorial  https://www.youtube.com/watch?v=T8kZL5l3K8c

authors: bjivanovich rupeshs

repo: rupeshs/fastsdcpu


text:
Setting public headers for Xcode framework target

I have built the 02-library example for Xcode with the following command:
build.py --clear --toolchain xcode  --framework
This built a Framework, but it does not have any public headers in the framework Headers folder.
I added a public.h file to the example and added the following entry in the CMakeLists.txt
set_target_properties(
        foo PROPERTIES
        PUBLIC_HEADER public.h)

When building the public.h file is copied to '_install/xcode/lib/'
But the build fails with the error:
Expected only one lib in directory: .../_install/xcode/lib
But found: ['.../_install/xcode/lib/libfood.a', '.../_install/xcode/lib/public.h']

What is the correct way to configure the public headers for a framework build.

Try to install headers to include directory. Explanation: this is workaround script which expect only one file in lib folder (which should be the *.a library) so when there are some other files script can't decide what file is a library.
Just for your information there are few fixes in latest CMake version that allow creating frameworks without hacks/workarounds (just using CMake). I haven't tried it yet, but if it works okay --framework option will be removed.

Still using make 3.3
cmake_minimum_required(VERSION 3.3)
I added the FRAMEWORK property
set_target_properties(
        foo PROPERTIES
        FRAMEWORK TRUE
        PUBLIC_HEADER public.h)

Then I built using the following command
./buildtools/polly/bin/build.py --clear --toolchain xcode

This created a Framework with 'public.h' in the Headers folder located at:
_builds/xcode/Debug/foo.framework

But this only appears to be a MAC OS X framework not a fat Framework, I ran the file command:
file _builds/xcode/Debug/foo.framework/foo

result was:
Mach-O 64-bit dynamically linked shared library x86_64

I also tried --toolchain ios-9-2 but the framework still appears to be created only for x86_64

But this only appears to be a MAC OS X framework not a fat Framework

This is by design. Fat library created only for iOS.

I also tried --toolchain ios-9-2 but the framework still appears to be created only for x86_64

I will test latest CMake version with few improvements, may be will create an example.

What is the correct way to configure the public headers for a framework build

Okay, I think I know what is the problem here. --framework option expect headers be located in directory <install-prefix>/include/<frameworkname>. I.e. if you have library libfoo.dylib installed, then headers should be located in <install-prefix>/include/foo and will be moved to foo.framework/Headers. The reason of this is that project which uses foo should do #include <foo/*.hpp> in both variants. I've added warning to build.py script, so you should see next message:
Warning: no headers found for framework (dir: /.../_install/ios-9-1-armv7/include/boo)

Which can be fixed by next CMake code:
install(FILES boo.hpp DESTINATION include/boo)

I also tried --toolchain ios-9-2 but the framework still appears to be created only for x86_64

Are you sure you're using patched CMake version?

https://github.com/ruslo/polly/wiki/Toolchain-list#ios
https://github.com/ruslo/hunter#notes-about-version-of-cmake

Example with framework and native Xcode project updated:

https://github.com/forexample/ios-dynamic-framework#headers

Great! I have successfully built and linked the ios-dynamic-framework project.
I did have to use patched CMake version, I tried with the latest 3.5.0-rc2 CMake but that failed to build the Fat framework bundle.
I'm going to try and replicate the project setup to my own library repo.

but that failed to build the Fat framework bundle

With CMake 3.5+ you have to use CMAKE_IOS_INSTALL_COMBINED=YES and CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO and run install (no need to use --framework, now it's --install). However dynamic framework will not be signed properly so the last time I've tried it I failed to run bundle on real device.

I have replicated the demo project setup on my own repo, I did not copy over the custom jenkins.py as I am just trying to build a dynamic library component, I am calling build.py directly with:
./buildtools/polly/bin/build.py --clear --toolchain ios-9-2 --framework --config Release

The build is successful and the lib binary now reports as a Fat lib and the public header is copied over to the framework/Headers folder.
I have noticed that if I build with --config Debug, that 'd' gets appended to the project name for all folders and files and it also causes the public header not to get copied to framework/Headers (unless I install it to an include/'d' folder.
Is there a way to prevent the 'd' suffix getting added and maybe create the framework under a debug or release folder depending on the --config value.

Is there a way to prevent the 'd' suffix getting added

Set it in command line -DCMAKE_DEBUG_POSTFIX="", in terms of build.py script it will be --fwd CMAKE_DEBUG_POSTFIX=""

Both iOS and OSX framework builds are working, thanks.

authors: novocodev ruslo

repo: ruslo/polly


text:
Adding ec2 test autogen

Builds on https://github.com/rusoto/rusoto/pull/373 and will need a rebase after that is merged.
Found a few bugs!
test result: FAILED. 75 passed; 15 failed; 0 ignored; 0 measured

Trying to figure out how we should handle cases where the call output is a shape wrapped in a shape where the top shape is only used for the top level xml tag.  Example test_parse_ec_2_request_spot_instances:
<RequestSpotInstancesResponse xmlns="http://ec2.amazonaws.com/doc/2014-06-15/">
   <spotInstanceRequestSet>
      ...
   </spotInstanceRequestSet>
</RequestSpotInstancesResponse>

The output shape looks like this:
"RequestSpotInstancesResult":{
      "type":"structure",
      "members":{
        "SpotInstanceRequests":{
          "shape":"SpotInstanceRequestList",
          "documentation":"
One or more Spot instance requests.
",
          "locationName":"spotInstanceRequestSet"
        }
      },

We want to generate code that ensures the top level is there then immediately calls the child shape deserializer.

After working on this more I see while the tests pass nothing is correctly populated in the output object.  Needs a bit deeper of a dive than expected.

This is off in the weeds.  I'm extracting a better solution of trimming code we generate by not populating serializers and deserializers if we know we don't need them.  Then back to extracting the good bits from this into smaller scoped PRs.

Closing this, got the work extracted from this mess.

repo: rusoto/rusoto


text:
add metadata to S3 put/copy/create_multipart

The metadata field was already available on the S3 request objects, but it was not being serialized into the request headers. This fixes that. This automatically prepends the x-amz-meta- to all keys in the metadata hashmap. I haven't done anything on the get object side, which appears to properly have the z-amz-meta- stripped from the keys in the GetObjectOutput metadata field.
I believe it is correct, and I've tested with my own setup.

The failure appears to be transient:
Too many open files (os error 24)

Thanks for the PR!  I've restarted the one Travis job that failed - hopefully it'll work this time. 😄

@bluejekyll - Have you run the s3 integration tests that we don't run on CI? If not I'd be happy to run them for you, but the code itself looks fine so running them is really just to make sure.

I didn’t realize there were tests not run by CI, if you point me to the doc, or give me the command I’ll happily post the results.

I can't find the docs on running integration tests, so I'll make sure that gets documented in the repo.
To get going, going into the integration_tests folder and running cargo test --features all runs all integration tests.  To run just S3, run cargo test --features s3.
The OSX build has failed for two different reasons so far that appear to be transient so I'm restarting the failing one again.

This looks good to me, thanks!
Could you add an integration test to the S3 tests demonstrating this new behavior? The test goes in this file: https://github.com/rusoto/rusoto/blob/master/integration_tests/tests/s3.rs .

The OSX build issues should be reduced or eliminated from https://github.com/rusoto/rusoto/pull/875 which is now in master. 😄

I'll work on the integration test today. Thanks!

Some things I noticed while testing:

unicode in the keys is not supported, if anyone wants that it will need some form of encoding
unicode is also a problem in the values, in so far as unicode characters are encoded, but not decoded on the Output objects.

Those seem like more general issues with the way headers are treated in the Rusoto library, and I'm not explicitly handling those cases in this PR, but it's something we may want to enhance in the future.
Anyway, I've added GetObject and HeadObject tests for S3 to validate the metadata section. Let me know if there's anything else you'd like to see.

@matthewkmayer let me know if anything else is needed for this change, Thanks!

Planning on getting to it tonight. 👍

All good, thanks!

Thank you!


text:
Change in float behavior in 0.30.0

Hi there! Thanks for the project, it's awesome.
We saw a change in float behavior from 0.29 to 0.30: https://github.com/PRQL/prql/actions/runs/6864485300/job/18666598362?pr=3797#step:13:101, from https://github.com/PRQL/prql/pull/3797
We test PRQL across a number of databases, and rusqlite==0.29.0 matched other databases on that query, while 0.30.0 doesn't. Over at PRQL we don't have particularly strong preferences about exact float behavior, though avoiding special-casing specific databases is good, and I thought it might be helpful for you to know about the change.
Thanks!

I am not sure but it may be related to this same regression in an Java / JDBC SQLite driver here:
https://github.com/xerial/sqlite-jdbc/commit/8880c338290e6505bc85eec96917552f027a99bd

Since version 3.43.0 the sqlite source doesn't round the value anymore, but returned the value including the 8-byte IEEE floating point number inaccuracies. Somehow different operating systems behave differently.

On SQLite forum, only 32-bit platform should be impacted ?
https://sqlite.org/forum/forumpost/b9511aa180bd1f4875ff20cf7f9953a216f5fe8092e95237321c39a0884ed930

authors: gwenn max-sixty

repo: rusqlite/rusqlite


text:
Hover details show unexpected crate name/path

Hey! I hope that this hasn't been posted before. I searched and could not find anything.
I expect the first line of the hover details to show std::collections::HashMap. Instead, it shows std::collections::hash::map.

std::collections::hash::map::HashMap is the full path of HashMap. std::collections::HashMap is just a re-export.
https://github.com/rust-lang/rust/blob/de32266a1780aa4ef748ce7f6200a1554fad0aca/library/std/src/collections/hash/map.rs#L200
https://github.com/rust-lang/rust/blob/de32266a1780aa4ef748ce7f6200a1554fad0aca/library/std/src/collections/mod.rs#L425

I see - I figured that something like this would be the case. Is there a way to get the re-exported path instead?

Rustc has the same problem with error messages: https://github.com/rust-lang/rust/issues/21934

I see. I understand that this isn't a priority for my people. I'll keep an eye on it though. Thank you :100:

repo: rust-analyzer/rust-analyzer


text:
feat: Add assist for replacing turbofish with explicit type.

Converts ::<_> to an explicit type assignment.
let args = args.collect::<Vec<String>>();

->
let args: Vec<String> = args.collect();

Closes #10285

authors: lnicola terrynsun


text:
Remove Ty::substs{_mut}

Almost all uses actually only care about ADT substs, so it's better to be explicit. The methods were a bad abstraction anyway since they already didn't include the inner types of e.g. TyKind::Ref anymore.

bors r+
changelog skip

bors r+


text:
feat: Make inline_function work on methods

Now called inline_call.

There is a lot of improvement potential for the assist here still.

For one better handling of the self param, which currently always emits ref (mut) for &(mut )self params even if not necessary.
A problem we currently have is that function parameters can have coercions happen, which this assist will lose as it doesnt emit type ascriptions for the let statements.
And there is the general potential for just not even generating some of the let statements and inline the expressions instead depending on the expression(I'll work on this next).

bors r+

We should start recording adjustments (for coercions and self parameter autoref / deref) in type inference sooner rather than later so we can handle these cases more correctly!

Definitely, I think this is the third issue/feature which wants coercions tracked. I'll open a new issue for this one to track them together.

authors: Veykril flodiebold


text:
Refactor use map_err

issue: https://github.com/rust-bitcoin/rust-bitcoin/issues/793
change to using map_err

i have refactor another place too

I approved run but unless I'm too confused something it'll fail on missing commas.

authors: Kixunil wim-web

repo: rust-bitcoin/rust-bitcoin


text:
Quickfix: Exclude the template file

This PR excludes the template file to fix this:

Follow up to #21

rustwasm wg seems to do exactly the same thing: https://github.com/rustwasm/rustwasm.github.io/blob/src/_config.yml


text:
Ash 0.30 release

I'm not the library author but the latest release seems worthy to be included in the newsletter!

Part of #89 ("Newsletter 8: Coordination/Tracking")

Nice, thanks!

authors: msiglreith ozkriff


text:
Fix version issues

This should fix both #270 and #274 as well as an issue I noted with particular versions of backtrace-rs and Rust 1.31.0

I'm not convinced that 0.13 will ever actually be released, but I think its fair to bump the minimum version to 1.13 and move from try! to ? as in #279
Wish I had found this before I addressed the failures today :)

Ok, I'm closing this out now then now #279 is merged. Will open a new PR fixing the backtrace version issue.

authors: AndyGauge palfrey

repo: rust-lang-nursery/error-chain


text:
Check only_v6 mode setting before trying to set it

Not all platforms allow changing a socket's IPV6_V6ONLY mode. OpenBSD for example treats this property as read-only, it is always enabled. It returns an error for any attempt to set it, even when you're setting it to what it already was. You are allowed to read out the value, though.
This PR changes the only_v6/set_only_v6 functions so that they first check if the value is already what is desired, before attempting to set it. This allows the user to explicitly enable (or disable) IPV6_V6ONLY mode without having to worry about getting an error on some systems, as long as the default value for the system is the same as what is being requested. You only get an error when the system default is different, and unable to be changed.

Thanks for the PR! This crate, however, is intended to be pretty low-level and correspond 1:1 with setsockopt operations. In that sense I think this may not necessarily be the best place to put this abstraction for OpenBSD perhaps?

That's understandable, but at the moment there's no way to query the socket options before setting them. In my use case, I want to have separate sockets for IPv4 and IPv6 (with the same port), but to do that I have to ensure that IPV6_V6ONLY is set. How would I go about doing this in a portable way, so that I don't receive an error when trying to set it on some platforms?

Perhaps a method could be added to query the settings? (the socket2 crate may also be useful here)

authors: Rua alexcrichton


text:
Bump version to 0.30.0

Version bump, primarily to get #832 and #892 in now that 1.19 is out and untagged unions are usable in stable!
r? @emilio

Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @emilio (or someone else) soon.

From the test output, the stable rust side is still emitting BindgenUnion(https://github.com/rust-lang-nursery/rust-bindgen/blob/master/tests/expectations/tests/anon_struct_in_union_1_0.rs)

Those are testing Rust 1.0 output.
Anyway, doing a new release sounds fine to me, @fitzgen, any reason we shouldn't?

Did stylo folks end up making their own bug-fix-only branch yet?
I see no reason not to release a 0.30.0 crate.

@bors-servo r+

Didn't, but no reason we can't in the future if we need to. shrug

:pushpin: Commit 3cbdb98 has been approved by emilio

:hourglass: Testing commit 3cbdb9894c5e90631d7fced86f8adf9868672706 with merge 05caa820010d44b601b340228d4f95d81958a270...

@emilio I'll write release notes and publish to crates.io if you haven't already

I planned to do so when it merges, but feel free to :)

Both release notes and publishing, or just the latter?

Mostly publishing. If you could do relnotes that'd be awesome, because it's taking a bit and I'm about to head out.

Sure thing

:sunny: Test successful - status-travis
Approved by: emilio
Pushing 05caa820010d44b601b340228d4f95d81958a270 to master...

0.30.0 is published

And release notes published on r/rust and u.r-l.o

authors: bors-servo bradfier emilio fitzgen highfive photoszzt

repo: rust-lang-nursery/rust-bindgen


text:
Fix tyvar_behind_raw_pointer warning

See https://github.com/rust-lang/rust/issues/46906

r? @alexcrichton

Thanks!

authors: nrc thibaultdelor


text:
"cargo +X clean" cleans not only for X

Looks like cargo can cache result of cargo build for different toolchains,
if I run cargo +stable build && cargo +nightly build && cargo +stable build with empty target
it build only two times, the second run of cargo +stable build does nothing.
This is great.
But if I run cargo +nightly clean the next run of cargo +stable build also run full rebuild.
It would be great if cargo +nightly build clean cache related only to nightly toolchain,
cargo +stable clean clean cache related only to stable toolchain and so on.

Related to #5026 ("cargo target fills will outdated artifacts as toolchains are updated/changed").
How would one go about changing clean so it only cleans artefacts relevant to the selected channel?

cargo sweep is adding this functionality.

I don't think it'd make sense for cargo clean to only clean up for the toolchain being invoked but I could see the possibility of a flag.  We'd need better tracking of what files are associated with what toolchain.  #12633 is the most likely route for that.

authors: Eh2406 davemilter dwijnand epage

repo: rust-lang/cargo


text:
cargo publish and cargo package incorrectly complain about .gitignored Cargo.lock in library

Recently (at some point since mid-July; but I don't know the exact version when it started) in my two library repos Cargo has started failing when attempting to cargo publish, with the error:
$ cargo publish
    Updating crates.io index
error: 1 files in the working directory contain changes that were not yet committed into git:

Cargo.lock

to proceed despite this, pass the `--allow-dirty` flag

However, this is incorrect because:

This is a library, so Cargo.lock should not be committed or published.
Cargo.lock is in .gitignore.
Cargo.lock has never been checked in to Git.

For confirmation:
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

$ git log Cargo.lock
[no output]

$ git rm --cached Cargo.lock
fatal: pathspec 'Cargo.lock' did not match any files

$ cat .gitignore
Cargo.lock
target/

cargo publish fails in the same way/with the same error.
As a workaround, deleting Cargo.lock entirely allows publishing (and of course since it's a library it can just be safely recreated afterwards).
The two repositories where I have observed this happening are https://github.com/felixc/rexiv2 and https://github.com/felixc/gexiv2-sys. I tried to reproduce it by creating a minimal empty repo but was not immediately able to, so I'm not sure what part of the repo configuration is leading to this. Some discussion on Discord suggested it might have to do with the runnable examples/ targets leading to some mis-detection as a binary crate rather than a library one?
Notes
$ cargo version
cargo 1.37.0 (9edd08916 2019-08-02)

$ rustup --version
rustup 1.18.3 (435397f48 2019-05-22)

$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
beta-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
1.20.0-x86_64-unknown-linux-gnu

$ uname -a
Linux mir 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux

CC @Eh2406 since you suggested on Discord that I should file this as you had some ideas about which parts of the relevant code might have changed recently.

Thanks, yes I would guess that it is something to do with #7026. CC @ehuss  as this may have to do with your lockfile on publish work.

I have this same issue with my repo: boxcars. This was a bug introduced in Cargo 1.37.0. I've downgraded to Cargo 1.36.0 successfully. Deleting a .gitignored Cargo.lock before pushing a library seems too inconvenient of a workaround.

This bug still exist in cargo 1.39.0 (1c6ec66d5 2019-09-30)
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
$ bat .gitignore
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: .gitignore
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ /target
   2   │ **/*.rs.bk
   3   │ Cargo.lock
   4   │ .idea
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
$ cargo publish
    Updating crates.io index
error: 1 files in the working directory contain changes that were not yet committed into git:

Cargo.lock

to proceed despite this and include the uncommited changes, pass the `--allow-dirty` flag
$ bat Cargo.toml
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: Cargo.toml
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ [package]
   2   │ name = "log-derive"
   3   │ version = "0.3.2"
   4   │ license = "MIT/Apache-2.0"
   5   │ authors = ["Elichai <elichai.turkel@gmail.com>"]
   6   │ repository = "https://github.com/elichai/log-derive"
   7   │ readme = "README.md"
   8   │ edition = "2018"
   9   │ description = "Procedural Macros for logging the result and inputs of a function"
  10   │ categories = ["development-tools::debugging"]
  11   │ keywords = ["log", "macro", "derive", "logging", "function"]
  12   │ include = [
  13   │     "src/*.rs",
  14   │     "Cargo.toml",
  15   │ ]
  16   │
  17   │ [dependencies]
  18   │ darling = "0.10.0"
  19   │ proc-macro2 = "1.0.3"
  20   │ #syn = { version = "0.15", features = ["full", "extra-traits"] } # -> For development
  21   │ syn = { version = "1.0.5", features = ["full"] }
  22   │ quote = "1.0.2"
  23   │ log = "0.4"
  24   │
  25   │ [dev-dependencies]
  26   │ simplelog = "0.7"
  27   │
  28   │ [badges]
  29   │ travis-ci = { repository = "elichai/log-derive" }
  30   │
  31   │ [lib]
  32   │ proc-macro = true

@elichai the fix is in 1.40, can you try that?

@elichai the fix is in 1.40, can you try that?

Yep, fixed. sorry :)

authors: Eh2406 ehuss elichai felixc nickbabcock


text:
Please publish new version of cargo-platform to include the license files

The published version of cargo-platform does not include the LICENSE-APACHE or LICENSE-MIT files, which can be seen on https://docs.rs/crate/cargo-platform/0.1.1/source/. Could a new version be published that includes these files? This makes it much easier to audit that the code to make sure it is correctly licensed.
There were also a handful of small clippy fixes since cargo-platform was last published, but as best as I can tell, they don't appear to be significant changes.
Possible Solution(s)
It appears that all we need to do to address this is to:

Bump the cargo-platform to 0.1.2
Verify that cargo publish --list includes LICENSE-APACHE and LICENSE-MIT
Publish cargo-platform 0.1.2

Thanks so much!

Feel free to post a PR to bump the version, and I can publish it.

authors: ehuss erickt


text:
Suggest cargo install --git when missing registry package looks like a git* URL

What does this PR try to resolve?
Fix #10485
Create a local Error type that that wraps existing error handling code
Giving the three error variants names improves readability and
makes it easier to share duplicate code
Move all string operations to create errors from 3 separate bail!
calls into anyhow::anyhow! calls that are encapsulated in the
From impl
How should we test and review this PR?
I left 2 comments asking for REVIEW
Please suggest other failure scenarios that SelectPackageError may have missed or too eagerly
bundled in the CouldntFindInRegistry variant.
I thought that adding error handling code is something we might be happy to pay a potential perf
penalty for if we can improve error messages, but please correct me if I am wrong
Additional information
I worked on this by adding a failing test case and implementing until it passed. Then I ran all install tests
cargo test --package cargo --test testsuite -- install --nocapture

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.
Please see the contribution instructions for more information.

Thanks for your review. I have now restructured the PR to consist of 2 commits:
https://github.com/rust-lang/cargo/pull/10522/commits/b87ae285ce86cc5212e200e6862a2d15dccda39b
with the regression test and the implementation that makes it pass without refactoring into new errors types.
The original REVIEW comment is still there for anyone to suggest improvement on.
https://github.com/rust-lang/cargo/pull/10522/commits/174c80ec6fceeed732bd4d3f95190e18bb63efc8
Is the refactor commit that adds the local error type and refactors all error handling there.
I hope this makes it easier to review.
I am happy to revert the PR back to the first commit that implements the actionable fixit with minimal refactoring.
Let me know.
Last but not least, congrats on soon becoming the new maintainer of cargo - it's a great tool and I am happy to see such diligent stewardship.

:umbrella: The latest upstream changes (presumably #11243) made this pull request unmergeable. Please resolve the merge conflicts.

Unfortunately I think this PR has fallen through the cracks (over a year ago 😞), and I'm not sure what the status of it is. Does anyone have an update on where it stands?

Unfortunately I think this PR has fallen through the cracks (over a year ago 😞), and I'm not sure what the status of it is. Does anyone have an update on where it stands?

Let me see if I can resolve the merge conflicts and I would appreciate a review

I settled the merge conflicts - please review
Since this PR was originally opened, gitoxide started getting integrated into cargo https://github.com/rust-lang/cargo/issues/11813, but I am not sure if you want new PRs to use gitoxide already.
Using gix_url, I can minimise the risk of adding a completely new dependency for a Quality-of-Life improvement like an actionable error message.
https://docs.rs/gix-url/0.21.1/gix_url/
Please clarify if this is something you would like me to do in this PR or you prefer to keep the current implementation and port it to gix_url when that is more stable

Using gix_url, I can minimise the risk of adding a completely new dependency for a Quality-of-Life improvement like an actionable error message.

Sounds like a good idea! Not sure if their feature parity is at the same level. For reviewer we have to do the amount same work for either — auditing the dependency as much as possible. If it is something from @Byron I am more confident to rubber-stamp it (just kidding, we still need to audit it).
Thanks for bringing this up and welcome back!

Thanks for chiming me in. I recommend using gix-url for the reason that it's already part of the dependency tree, and it does't use regex and tracing. It's not 100% spec compatible yet but that is in the making. I hope that helps.

Thanks for chiming me in. I recommend using gix-url for the reason that it's already part of the dependency tree, and it does't use regex and tracing. It's not 100% spec compatible yet but that is in the making. I hope that helps.

I moved to use gix::url instead of git-url-parse and the diff is now smaller!
The previously passing test passes. The test that was failing is still failing.
I will leave a comment with the root cause of the failing test to share context and would appreciate your input

Just wanted to note that since this PR only cares about http/s URLs, you could also use url::Url::parse directly. The additional logic present in gitoxide does not provide any benefit for this particular case.
gix-url (especially after the rewrite) would be helpful if you want to additionally detect scp like target urls and local file paths.

@niklaswimmer is mostly right. Thanks for calling out that.
It's my fault not looking at this pull request closer. Yes Cargo doesn't support SCP-like URL for Git dependencies, so url crates seems pretty sufficient for this enhancement at this moment.Sorry for giving a wrong pointer.
We may also want to include ssh:// protocol for this check, as Cargo supports that.

Thank you @petr-tik for your work on making this error message better. I merged another PR (#12575) which implements a similar hint for suggesting --git when a URL is passed.
Apologies for the confusion of having two different PRs fixing the same issue. I'm glad to see this error improved.

authors: Byron arlosi bors ehuss niklaswimmer petr-tik rust-highfive weihanglo


text:
fix(cli): Forward non-UTF8 arguments to external subcommands

Whether we allow non-UTF-8 arguments or not, we shouldn't preclude external subcommands from deciding to do so.
I noticed this because clap v4 changed the default for external subcommands from String to OsString with the assumption that this would help people to "do the right thing" more often.

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

:umbrella: The latest upstream changes (presumably #11119) made this pull request unmergeable. Please resolve the merge conflicts.

Should we add a test to prevent any regression?

I'm trying to weigh this out with updating the infrastructure so it can be tested.
As is, this is something the type system is verifying for us.
To test this, we  need a platform-specific test that can generate a project capable of verifying the argument was passed through.  The existing echo_subcommand would require platform-specific changes to allow it to sometimes not panic when echoing back out (windows could still panic) or a custom program that fails if expected values aren't received which requires updating the project builder to work with bytes instead of strings.
All of this can be done but weighing out, I'm unsure how worth it it is to do.

@bors r+

:pushpin: Commit 87fdf7660c21a4129a0bfa2385fe45da33065ff9 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit 87fdf7660c21a4129a0bfa2385fe45da33065ff9 with merge 7c8a5a67d34ff4ae46f2b6b689653509af8b75b6...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing 7c8a5a67d34ff4ae46f2b6b689653509af8b75b6 to master...

authors: bors epage rust-highfive weihanglo


text:
fix(cli): Error trailing args rather than ignore

This warning has been in for a sufficient time, requires a hack from clap to avoid all argument ID validation, and allows users to run the wrong command (imagine cargo -- publish --dry-run).
See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Cargo.20ignoring.20arguments.20with.20.60cargo.20--.20check.20--ignored.60

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

Thanks!
@bors r+

:pushpin: Commit 8f8a79a5a44a439351e487d532d1c98ac4d225e2 has been approved by ehuss
It is now in the queue for this repository.

:hourglass: Testing commit 8f8a79a5a44a439351e487d532d1c98ac4d225e2 with merge e320c3e545741210bd7d9a30c186e6426cb13546...

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

authors: bors ehuss epage rust-highfive


text:
Flip 'foo' and 'bar' to be consistent

The "Renaming dependencies" section initially uses 'foo' as the crate name and 'bar' as a rename, but then swaps them and uses 'bar' as the example crate name in the context of optional dependencies. Now both examples in this section treat 'foo' as the original crate name.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (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.

@bors: r+
Thanks!

:pushpin: Commit 2663d7d3af1674cd669c6f19ae43673b75e85b4b has been approved by alexcrichton

:hourglass: Testing commit 2663d7d3af1674cd669c6f19ae43673b75e85b4b with merge 4e4490f337522e31d9c4bfe3fb8ce0dfa193b5ff...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 4e4490f337522e31d9c4bfe3fb8ce0dfa193b5ff to master...

authors: alexcrichton bors dimo414 rust-highfive


text:
No-op shared_flag() and static_flag() methods.

The compiler flags enabled by the methods in question are link flags and are never actually used in the cc-rs context. The shared_flag() is documented as reserved for future support for linking shared libraries, and static_flag() is effectively deprecated.
This is with reference to https://github.com/rust-lang/cc-rs/issues/772#issuecomment-1651365558 and forward.

@dot-asm A lot of your PRs were closed in batch, is it an accident?

No, it's a conscious choice. Just in case, it's not a random "lot," but all open ones. I've also removed myself from the watchers' list.

@dot-asm Is it because members of cc-rs is too slow to review and respond to your PR and some of them has been open for a long time?

authors: NobodyXu dot-asm

repo: rust-lang/cc-rs


text:
Simplify builds.json to return what the clients actually want

AFAIK our primary consumers are:

shields.io
crates.io

They both only care:

will going to https://docs.rs/<crate>/<version> show docs

They emulate this by checking whether the latest build is successful, but this relies on docs.rs also using this as the signal (it currently mostly is for other reasons, but we should show docs in cases where a previous build was successful but a newer rebuild failed, and there were previously bugs around proc-macros).
So, remove all the extraneous data they don't depend on and just return a simple boolean showing whether the docs are good or not, the same one we use to determine whether to redirect to show a build failure warning or not:
https://github.com/rust-lang/docs.rs/blob/f1a7e46a620d763db485a25efb5e510fd3fe0594/src/web/rustdoc.rs#L476
(This helps simplify some changes I'm working on around what and how we store build details).

We're retuning the same structure they expect. I was considering adding a new route with a different structure, but at least at the moment I don't think it's worth the migration pain.

We're retuning the same structure they expect. I was considering adding a new route with a different structure, but at least at the moment I don't think it's worth the migration pain.

You're right, I missed the [] in the JSON response. So yes, assuming this is the only attribute used, this would be backwards compatible.

I was considering adding a new route with a different structure, but at least at the moment I don't think it's worth the migration pain.

if it's worth the migration pain probably also depends on your initial question, if anyone except crates.io / shields.io uses this endpoint / the result.
I see two ways here:

as you already proposed, try to get data from cloudfront about the user agents for this endpoint. I assume this has to be configured by infra.
or, use a new endpoint, switch over crates.io / shields.io, and see if any requests remain.

From my limited experience I couldn't say if we can just do the breaking change, without the data above.

A thing I just remembered : since the endpoint is uncached, you could also check the access logs on the server itself, if they contain what we seek

I did that, we just get Amazon CloudFront as the user-agent on all requests.

I've been persuaded to go the new endpoint route, I'll open a separate PR adding that and prepare PRs for crates.io/shields.io (and lib.rs assuming my gitlab login still works) using it for once it's been deployed. Then we can re-evaluate whether there's still any traffic to this endpoint.


text:
= 0.17.0 issues running cargo semver-checks

Hi! I'm currently running into issues with cargo-semver-checks 0.21.0 (on Arch Linux, but can reproduce building straight from crates.io) and was asked to open a ticket here and link to this one.
Using git2 >= 0.17.0 cargo-semver-checks runs into TLS errors:
cargo semver-checks check-release
    Updating index
Error: the server did not provide a certificate; class=Ssl (16)

Caused by:
    the server did not provide a certificate; class=Ssl (16)

Current cargo-semver-checks 0.21.0 pulls in git2 0.17.0 and libgit2-sys 0.15.2+1.6.4, but only when downgrading git2 to 0.16.1 and libgit2-sys to 0.14.2+1.5.1, the issue described in the above ticket goes away.

To give further background info:
I am packaging libgit2 for Arch Linux. It is currently at 1.6.4 and we do not apply any patches (see PKGBUILD).
Our openssl in the stable repositories is at 3.0.9, soon 3.1.1 (see PKGBUILD).

Can you provide a reproduction that uses this crate directly? Like perhaps running the clone example? It's also important to know how which SSL backend it is using, which version, etc.

authors: dvzrv ehuss


text:
struct linger is missing

Hey,
the linger {int l_onoff, int l_linger} struct is missing in this binding. I checked it's implementation in glibc and musl, but it's missing in this binding.
I guess the struct should look like in the crate winapi.

Ah yeah should be good to add at any time!

Ok, it's a bad idea to take the struct from winapi, because on windows you need to set u_short's, on *nix systems you need to set int's, so we need to set it so c_int, not u16.

Now fixed!

authors: alexcrichton sateffen

repo: rust-lang/libc


text:
Passing argument without -- to cargo miri run bypasses miri

Check this out:
% cat src/main.rs
use std::ffi::c_char;

extern "C" {
    fn printf(fmt: *const c_char, ...);
}

fn main() {
    dbg!(std::env::args().skip(1).take(1).collect::<String>());
    let fmt = b"Hello, world!\n\0".as_ptr() as *const c_char;
    unsafe {
        printf(fmt);
    }
}

You'd expect miri run ... to error on the above code.
But:
% cargo +nightly miri run whoa
Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... done
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/hello whoa --target-dir /local/home/pnkfelix/Dev/Rust/hello/target/miri --target x86_64-unknown-linux-gnu --config 'target.'\''cfg(all())'\''.runner=["/local/home/pnkfelix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri", '\''runner'\'']' --`
[src/main.rs:8] std::env::args().skip(1).take(1).collect::<String>() = "whoa"
Hello, world!

Now, if someone is reading the above output properly, they might get a hint as to what's actually happening here: it's building and running a debug binary, rather than running cargo-miri itself.
(I.e., you need to pass inputs with an intervening --, like so: cargo +nightly miri run -- whoa, which does what you expect and issues a error at the point where printf is called.)
But what is the scenario where you want the current behavior when -- is omitted? Should miri run provide an error or warning when -- is omitted and the extra arguments are not recognized by miri's argument processor?

I am confused, probably because I am tired... what is happening here? All these arguments should just be forwarded to cargo run, while a whole bunch of env vars are being set to make binaries be executed by Miri.

The issue is that the actual binary gets executed:

Running `target/debug/hello

And not miri
I don't know how a binary even gets created (maybe left over from a previous non-miri run?).

This is caused by very strange cargo behavior: in cargo run foo --config blah, cargo ignores the --config and probably passes it to the program instead. I would expect all --flags before the -- to be interpreted by cargo.
With this cargo behavior, I don't know if the bug is fixable. It is not possible for Miri to know whether an argument is present before the --; that would require knowing whether some --flag takes a parameter or not.
Cc @ehuss

When we passed the arguments in a different order, that broke cargo nextest :joy: .
But anyway this still doesn't help:

Scan the args for anything that is cargo-specific, but that cargo-miri wants to know about (like --target-dir). If you find these special flags, strip them from the args, and add them to cmd.arg(…). You'll need to collect the args into a temporary Vec to do this.

Here we have to stop at the first argument that is passed to the program. So e.g. cargo miri run -- foo --target-dir=blah, we need to stop at the --. That already works. But with cargo miri run foo --target-dir=blah we need to stop at the foo. Worse, with  cargo miri run --flag foo --target-dir=blah we need to stop at the foo if and only if --flag does not take a 'value'. In other words, we need to copy-paste the entire cargo argument passing logic (at least which flags exist and whether they they an argument or not). That's quite bad. :(

I personally wouldn't worry too much about having cargo miri run perfectly match the behavior of cargo run. If the concern is about these flags colliding with the user's program, I also wouldn't worry too much about that since they can use -- to avoid those collisions (and they seem like they would be unlikely).
An alternative is to use clap in cargo-miri, and just parse the cargo run flags. There aren't very many of them, and they don't change very often. That's what cargo expand does.  I realize that isn't ideal, but otherwise there aren't a lot of options.

An alternative is to use clap in cargo-miri, and just parse the cargo run flags. There aren't very many of them, and they don't change very often. That's what cargo expand does. I realize that isn't ideal, but otherwise there aren't a lot of options.

I was living under the illusion that argument parsing worked out in a way that was just modular enough to make this work, but as this issue shows that was just wrong. :(

If we are willing to ignore the issues around cargo miri run foo --target-dir=blah, things are still not entirely trivial: if we add our --config immediately after the 'verb', we end up with cargo nextest --config ... run, which errors. That's why we moved to passing the --config at the end in the first place.

authors: RalfJung ehuss oli-obk pnkfelix

repo: rust-lang/miri


text:
Missing cmath function: ldexp

The libcore test suites calls ldexp via FFI. Unfortunately, libstd does not expose this function in any way. What would be the best way for us to implement this shim?
I found this crate. Alternatively we could try to just define the extern symbol ourselves and see if that works on all our host platforms?^^

I am taking care of this one

Awesome!
Do you need mentoring? The file to edit is this one.

Thank you Ralf. It seems my gut feeling was right this time :D that's the file I modified. I just  added a new match under // math functions based on the [description] (http://www.cplusplus.com/reference/cmath/ldexp/) for ldexp:
        "ldexp" => {
            let x = f32::from_bits(this.read_scalar(args[0])?.to_u32()?);
            let exp = f32::from_bits(this.read_scalar(args[1])?.to_u32()?);
            this.write_scalar(Scalar::from_u32((x * 2.0f32.powf(exp)).to_bits()), dest)?;
        }

Should that be enough? Or should I use the crate you mentioned?
I also suppose we should remove https://github.com/rust-lang/rust/blob/0f11354a9c1bf0c5ac250c7fa2bafc289a662f42/src/libcore/tests/num/flt2dec/mod.rs#L1, is that right?

I just added a new match under // math functions based on the description for ldexp

Hm. I guess it is a reasonable start. Maybe add a FIXME saying that if we see imprecise results, we should try to use the C math lib ldexp instead.
Your code should also, like the other math functions, have a FIXME because it uses host floats.
And finally, find an appropriate test case to extend and call the function there.

I also suppose we should remove

Once this lands in Miri and Miri has been updated in rustc, that can be removed, yes. One step after the other. :)

I just added a new match under // math functions based on the description for ldexp

Hm. I guess it is a reasonable start. Maybe add a FIXME saying that if we see imprecise results, we should try to use the C math lib ldexp instead.

I can use the C math library directly if you think that's a more definitive solution.

I also suppose we should remove

Once this lands in Miri and Miri has been updated in rustc, that can be removed, yes. One step after the other. :)
Ok then I will do the miri PR first and wait :)

I can use the C math library directly if you think that's a more definitive solution.

That is more in line with what we do with the other functions. I just don't know if it will work on all platforms.

Seems like ldexp is part of the normal C math lib so we can rely on it being present in Miri. So @christianpoveda if you want to switch it to import the function via extern instead, be my guest. :)

I am seeing test failures when turning on the libcore tests that use ldexp, so maybe we actually need the higher precision.

I'll fix this ASAP :)

authors: RalfJung christianpoveda


text:
add lockfile

Fixes https://github.com/rust-lang/miri/issues/427

@bors r+

:pushpin: Commit 5a025ab273007e3219e888592595bac199b507b4 has been approved by RalfJung

:hourglass: Testing commit 5a025ab273007e3219e888592595bac199b507b4 with merge 420bba081b4b9d0e2d402ce59ef5ff04480da528...

:broken_heart: Test failed - checks-travis

@bors r+

:pushpin: Commit 917effada1e970e964520f56431119b7f6b332c9 has been approved by RalfJung

:hourglass: Testing commit 917effada1e970e964520f56431119b7f6b332c9 with merge 394a9d5d295078f7b846d6833c73b2661704e97e...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing 394a9d5d295078f7b846d6833c73b2661704e97e to master...

authors: RalfJung bors


text:
RegexSet replace

Is there a reason for not having replace-like methods on RegexSet? If not, I would be willing to contribute an implementation based on Regex's.

Yes, there is a reason. Replace APIs require finding the offset of matches, and the implementation doesn't support that, as stated in the docs.

authors: BurntSushi gahag

repo: rust-lang/regex