Add support for Python 3.12

Hello!
When running this plugin with Python 3.12, it won't start, raising the following error:
LSP-ruff: Traceback (most recent call last):
LSP-ruff:   File "<frozen runpy>", line 198, in _run_module_as_main
LSP-ruff:   File "<frozen runpy>", line 88, in _run_code
LSP-ruff:   File "C:\Users\senpos\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Scripts\ruff-lsp.exe\__main__.py", line 7, in <module>
LSP-ruff:   File "C:\Users\senpos\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\ruff_lsp\__main__.py", line 5, in main
LSP-ruff:     from ruff_lsp import __version__, server
LSP-ruff:   File "C:\Users\senpos\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\ruff_lsp\server.py", line 55, in <module>
LSP-ruff:     from pygls import server, uris, workspace
LSP-ruff:   File "C:\Users\senpos\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\pygls\server.py", line 27, in <module>
LSP-ruff:     from pygls.lsp import ConfigCallbackType, ShowDocumentCallbackType
LSP-ruff:   File "C:\Users\senpos\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\pygls\lsp\__init__.py", line 36, in <module>
LSP-ruff:     from typeguard import check_type
LSP-ruff:   File "C:\Users\senpos\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\typeguard\__init__.py", line 27, in <module>
LSP-ruff:     from typing_extensions import Literal
LSP-ruff:   File "C:\Users\senpos\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\typing_extensions.py", line 1174, in <module>
LSP-ruff:     class TypeVar(typing.TypeVar, _DefaultMixin, _root=True):
LSP-ruff: TypeError: type 'typing.TypeVar' is not an acceptable base type

This problem is specific to 3.12 and was also mentioned here: https://github.com/astral-sh/ruff-vscode/issues/200
The solution was to update typing-extensions package to its latest version. As I can see, that's what authors do in ruff-vscode repository, they don't pin this package.

I suppose the dependabot that we use to bump dependencies in requirements.txt doesn't work quite as we would expect. It should ideally bump all the requirements to the ones that would match ruff-lsp but it doesn't do that...


fix : colossalai.zero.shard_utils could not be resolved

📌 Checklist before creating the PR

[ ] I have created an issue for this PR for traceability
[x] The title follows the standard format: [doc/gemini/tensor/...]: A concise description
[x] I have added relevant tags if possible for us to better distinguish different PRs

🚨 Issue number
Not involved
📝 What does this PR do?
fix : colossalai.zero.shard_utils could not be resolved
detail info
modified:   examples/language/gpt/titans/configs/gpt2_small_zero3_pp1d.py
modified:   examples/language/gpt/titans/configs/gpt3_zero3_pp1d.py
modified:   examples/tutorial/opt/opt/colossalai_zero.py
Before adjustment

💥 Checklist before requesting a review

[ ] I have linked my PR to an issue (instruction)
[x] My issue clearly describes the problem/feature/proposal, with diagrams/charts/table/code if possible
[x] I have performed a self-review of my code
[x] I have added thorough tests.
[x] I have added docstrings for all the functions/methods I implemented

⭐ Do you enjoy contributing to Colossal-AI?

[x] 🌝 Yes, I do.
[ ] 🌚 No, I don't.

Tell us more if you don't enjoy contributing to Colossal-AI.

thanks for raising the issue! could you update the import statements to follow this example so that different versions of colossalAI are supported?

hi, there's no 'legacy' under the colossalai.zero module anymore. We will rewrite these examples to demonstrate how to use the booster API. If you're interested, feel free to join the development of colossalai.


Current state of development?

Is this still under active development? What are the current items that are being implemented? Would love to work on some of the implementation (would need a LOT of help, of course).

Checkout Issue #49
Also, I had started implementing bitswap py-ipfs-bitswap, but I have paused it due to personal commitments and lack of response. I plan to restart it in a few days (hopefully I will get proper feedback this time 😅).
You can work on some other aspect of py-ipfs if you want ✌
@alexander255 is currently heading the development of py-ipfs

@alexander255 Please guide us and tell us what is to be done next. And what is the roadmap of the project

@AliabbasMerchant: What feedback were you missing? Maybe I didn't notice it, but I can't recall you asking me anything recently. 🙂
As for the roadmap: There hasn't changed much since I updated it last I fear: It's still all contained in #49. I could extend it to have more items if there is interest through.
@utkarsh5k: Are you more interested in networking stuff (block exchange, security, DHT, …) or local stuff (fetching blocks from go-IPFS's local repository)? That's roughly the division I made in the roadmap since those two things can be implemented pretty much independently from each other.

@alexander255 https://github.com/ipfs/py-ipfs/issues/49#issuecomment-468931595 😅

@alexander255 : I'd love to work with the networking side of things. I am assuming that this work would mostly involve libp2p. I'd love to talk to you more about the current work done, some design specs and what I can take on for the same.

@AliabbasMerchant: Indeed! How didn't I see that!?
Left a bunch of comments around the repo and in that issue. Sorry about this!

@utkarsh5k: You are correct about libp2p of course 🙂
There really isn't all that much work done atm and py-libp2p isn't really usable or compatible with any real-work application yet. As such I've added some py-libp2p related things to #49. The MSS one should be fairly easy, adding encryption on the other hand does require some background I fear.
Based on your message, would you be more comfortable using some other communication channel or is GitHub OK for you?
Regarding the tasks at hand (there is obviously always more than I list at any given time): Is there any thing you'd like to work on in particular? What's your background in programming/networking/security? I can help you out getting starting and reviewing stuff, but you'd have to show some initiative of course. 😉

@alexander255 : We can use any other channel of your choice for communicating further, talking on this thread isn't ver efficient.
In the past, I have written a lot of code in python, however off late I have been slightly out of touch, but I don't think it will take too long for me to ramp up again. I have a fair background in networking because my day job (@ Microsoft) requires me to work in the domain of distributed systems, and I  also have a fair theoretical foundation in networking.
There is a lot I am interested in, inside the peer to peer domain, but from your first comment, I'd like to explore DHT first. It would be great to discuss what implementations (if any)  we have, and if no, what options can we consider (like Chord/Kelips system).
On the side, I think it will be great for me to parallelly pick up some small documentation tasks, as it'll help me understand the system better.

@alexander255 any thoughts on the above?

@alexander255 pinging again. :)

@utkarsh5k: I'm very sorry for the long delay on my end.
I must confess that I have very little knowledge about the DHT that IPFS currently uses and documentation has only recently started to be written (link). A couple of months ago some form of kad support was added to py-libp2p(I have updated #49 accordingly). The main tracking issue is at: https://github.com/libp2p/py-libp2p/issues/150

It would be great to discuss what implementations (if any) we have, and if no, what options can we consider (like Chord/Kelips).

Having other implementations definitely sounds interesting! Main problem is that many of the other required functions for using these in the context of IPFS or even libp2p do not exist yet (that's what the other tasks are about), so their utility would be quite limited at this point.
Sorry to let you waiting so long for this kinda lame response, my next reply will likely be a lot quicker. :flushed:


[BTAT-10347] - Added connector and it tests

Staging - https://github.com/hmrc/app-config-staging/pull/10248

QA - https://github.com/hmrc/app-config-qa/pull/14722


Fix driver load order for external ICM20948/Here GNSS for Pixhawk Cube

With the driver load in rc.sensors, the external ICM20948 magnetometer on Here GNSS gets activated as last (and 4th) magnetometer on Pixhawk Cube.  It gets set as primary mag after calibration, but QGroundControl does not show the "External Compass Orientation" Dropdown in Parameters -> Sensors -> Set Orientations:

I moved the driver load to the start of rc.board of px4fmu-v3, after the load of external ist8310. This resolves the issue for Pixhawk Cube.

No longer an issue (we don't use the mpu9250 mags by default).


Finite Difference Pricer with nalgebra

Important Notes
This Pull Request is regarding issue https://github.com/avhz/RustQuant/issues/98 for the creation of a finite difference pricer.
I have made 2 PRs for this particular issue. Only one of them needs to be merged if the decision has been made to merge.
nalgebra vs heap allocated vectors
This PR utilises the nalgebra package to represent vectors and matrices, and handle their calculations. The other PR uses heap allocated vectors instead.
The way in which the objects and methods should be used are exactly the same for both PRs.
There are differences in speed performance between the two implementations.
An example with the following parameters:
initial_price: 3.22,
strike_price: 12.87,
risk_free_rate: 0.02,
volatility: 0.2,
evaluation_date: None,
expiration_date: today() + Duration::days(365),
time_steps: 1000,
price_steps: 100,
type_flag: TypeFlag::Put,
exercise_flag: ExerciseFlag::American

We get the following runtimes when we run one instance of both implementations:

Method
vec branch
nalgebra (latest commit)

Explicit
18.032395ms
447.828518ms

Implicit
475.63228ms
548.617466ms

Crank-Nicolson
496.54801ms
1.034193406s

We can immediately see that the explicit method is about ~17 22~ 24 times faster using heap allocated vectors than using the nalgebra package (this PR) and runtime for the Crank-Nicolson method is roughly halved  (This is at least the case for the machine I am running the code on).
Contents of this PR
This PR implements the following features:

A struct, FiniteDifferencePricer in the module instruments::options::finite_difference_pricer, where the attributes are the parameters of an option, namely:

initial_price: f64
strike_price: f64
risk_free_rate: f64
volatility: f64
evaluation_date: Option<Date>,
expiration_date: Date,
time_steps: u32,
price_steps: u32,
type_flag: TypeFlag,
exercise_flag: ExerciseFlag

where TypeFlag and ExerciseFlag are imported from instruments::options::option

A constructor for the above struct with the new() method which takes in the above defined attributes as arguments

Three public methods implemented in the FiniteDifferencePricer for the three widely known finite difference methods, namely explicit(), implicit() and crank_nicolson() which returns the option price rounded to 2 decimal places

Demonstration by example
We can start off by defining the finite difference object by calling the new() constructor
use RustQuant::instruments::options::{
    option::{TypeFlag, ExerciseFlag},
    finite_difference_pricer::FiniteDifferencePricer,
};

let finite_difference_obj = FiniteDifferencePricer::new(
    15.55,                            // initial_price
    10.2,                             // strike_price
    0.1,                              // risk_free_rate
    0.025,                            // volatility
    None,                             // evaluation_date
    today() + Duration::days(1),      // expiration_date
    1000,                             // time_steps
    100,                              // price_steps
    TypeFlag::Call,                   // type_flag
    ExerciseFlag::American            // exercise_flag
);

Now that the object has been defined, we can run any of the 3 methods to provide a numerical approximation of the option price:
println!("Explicit method: {}", finite_difference_obj.explicit());
println!("Implicit method: {}", finite_difference_obj.implicit());
println!("Crank-Nicolson: {}", finite_difference_obj.crank_nicolson());

Running the above code yields the following results:
Explicit method: 5.35
Implicit method: 5.35
Crank-Nicolson: 5.35

Notes

I have opted to solve this problem using a struct to define the option parameters and from there we can run each finite difference method from the object. Alternatively, I could amend the PR so that it can be purely functional.

The code utilises the Dirichlet condition for the boundaries of the stock price extremities:

If we define the following:
$$V^{m}_{n} - \text{The option price at time step } n \text{ and price step } m \text{ (with maximum } M\text{)}$$
$$T - \text{Maturity time}$$
$$K - \text{Strike price}$$
$$S_{M} - \text{Maximum price of the underlying asset}$$
$$\Delta t - \text{Time step size}$$
Then Dirichlet boundary conditions for the call options are:
$$V^{0}_{n} = 0$$
$$V^{M}_{n} = S_M - Ke^{-r(T-n\Delta t)}$$
and for the put options:
$$V^{0}_{n} =Ke^{-r(T-n\Delta t)}$$
$$V^{M}_{n} = 0$$

We can also implement the option use the Neumann conditions, perhaps in another pull request in the future.

I will close this for now, however I would be interest to see if this can be optimised further.
If I get the time, I will try myself.


Direct parent-child refs in Accordion and Panel break reusability

Let's say I have component A that has many of component B.
If can define an accordion within A's template with simple panels containing instances of B:
<-- A's template -->
<accordion v-if="b_children" type="info">
  <panel v-for="b in b_children" :header="b.name">

  </panel>
</accordion>

And that works fine.
Let's say I want to specify a more complex header though, and programmatically determine whether the panel's type and open status:
 <-- A's template -->
<accordion v-if="b_children" type="info">
  <panel v-for="b in b_children" :isOpen="panelOpen(b.status)" :type="panelType(b.status)">
      <template slot="header">

          {{b.name}}
          <C :status="b.status"></C>

      </template>

  </panel>
</accordion>

This gets messy pretty fast. It's clear to me that we're relying too heavily on the state of B to render its surrounding markup in A's template. If B is always going to be rendered in a panel, I'd prefer to render the accordion within A and the panel within B, especially if B can contain more of itself! For example:
 <-- RegressiveComponent's template -->
<panel :isOpen="panelOpen" :type="panelType">
  <template slot="header">

      {{name}}
      <C :status="status"></C>

  </template>

  <accordion v-if="children" type="info">
    <RegressiveComponent v-for="child in children" :sync="child"/>
  </accordion>
</panel>

However, when a panel is declared in this way, it becomes untoggleable.
A quick scan through the accordion and panel code shows us that panel is only toggleable if its parent Vue component (so not DOM-wise, but Vue-logic wise) has _isAccordion set to true. This is to ensure the parent contains the openChild method, which the child will then call upon opening itself to allow the oneAtATime functionality.
If I add these to the definition of RegressiveComponent, then click toggling works again:
# RegressiveComponent.coffee
  ...
  created: () -> this._isAccordion = true
  methods:
    openChild: (child) -> return   # Or the full implementation, if you need it

However, this seems like an unnecessary workaround. The events system is built into Vue Components to avoid exactly this sort of tight coupling - children should only broadcast to their parents, never directly manage them.
It looks like the Vue 1.x versions of these component actually do rely on the event system:
https://github.com/yuche/vue-strap/blob/master/src/Accordion.vue
this.$on('isOpenEvent', (child) => {
      if (this.oneAtAtime) {
        ...

Some things to take in mind first:

You're working with vue 1 or 2 ?
My master is based on vue 2: https://wffranco.github.io/vue-strap/
if you're working with vue 1, use yuche version: http://yuche.github.io/vue-strap/

To put a slot in a template tag maybe can cause problems... vue try to replace the slot in the component with this, and the template is not a DOM object like div or span, so maybe that can be part of your problem.

If this don't help you to solve the problem, try to replicate in a jsfiddle.
Some examples (just to help you to import vue & vue-strap files):

example with vue1: https://jsfiddle.net/wffranco/goLmr7ty/
example with vue2: https://jsfiddle.net/wffranco/yeqwj0gt/

You're working with vue 1 or 2 ?

I'm working with vue 2. I opened this issue on your fork because your fork represents the current vue 2 code. This issue doesn't exist with the vue 1 code.

To put a slot in a template tag maybe can cause problems... so maybe that can be part of your problem.

My problem is that the template logic in https://github.com/wffranco/vue-strap/blob/master/src/Panel.vue requires _isAccordion set to true in order to create the toggle attribute, and that it calls openChild on its $parent. I am not receiving any errors from vue itself.

If this don't help you to solve the problem, try to replicate in a jsfiddle.

As requested: https://jsfiddle.net/b13wu1bm/1/. Note that the accordions start open and are not toggleable.
As mentioned, I can fix this by adding:
  created: function() {
    return this._isAccordion = true;
  },
  methods: {
    openChild: function(child) {}
  },

to the metadata for RecursiveComponent: https://jsfiddle.net/qtrmto7y/, which demonstrates the issue is related to these functions.
Ideally, Accordion would listen for opens that occur in its Panels like they do in the Vue 1 code, instead of Panels directly toggling actions on their parent Accordions.

The accordion only work if the panel is directly inside a accordion... is that way to avoid the panel component have a weird behavior when you nest components.
The best solution is to put your master data inside an array (the master element) and put accordion and panel inside your recursive component. Here is your example working:
https://jsfiddle.net/wffranco/b13wu1bm/2/

Hey @wffranco, thanks for getting back to me. Sorry for the delay.
You said:

The accordion only work if the panel is directly inside a accordion... is that way to avoid the panel component have a weird behavior when you nest components.

I agree that the panel currently has weird behavior when you nest it under custom components, for precisely the reasons I laid out in the initial description - panel directly calls methods on its $parent. I've found that other components within this repo actually do this as well. Per the Vue 2 docs, this is an anti-pattern:

Use $parent and $children sparingly - they mostly serve as an escape-hatch. Prefer using props and events for parent-child communication.

Regarding my particular issue, you said:

The best solution is to put accordion and panel inside your recursive component, in that order.
Have 2 ways to solve your problem.

Thank you for the examples! But they don't actually solve my issue, because the panel needs to be the root element of my custom component.  See the second example in my initial comment, especially the paragraph underneath:

It's clear to me that we're relying too heavily on the state of B to render its surrounding markup in A's template.

This specific issue is just one of several potentially caused by referring to $parent directly. All child-to-parent communication in Vue components should occur as events.
I'm happy to help refactor the areas that need to be changed, but I won't be able to start on it until late February.

Well, when I said The best solution I mean that is the fast way to solve it...
I said I avoid any weird behavior, but I don't really test nesting accordion & panel with other components, so I think I can make it work nested (using $children & $parent).
But I think is hard to handle nested parent-child communication with events & props when you don't know how deep inside is your child component. If you have some idea how to do it, I invite you to fix it :smiley:

@wffranco Sorry for the delay. I do have some ideas how to fix it and will submit a PR as soon as I get some time to work on it.


Replica is synced with incorrect (Global)logStartOffset

Scenario
Leader has a TopicPartition which is partially offloaded to RemoteStorage. This would result in leader having different values for LocalLogStartOffset and (Global)LogStartOffset). When a new replica is created, it tries to sync from the leader at the ReplicaFetcherThread.buildRemoteLogAuxState() function. This function calls truncateFullyAndStartAt which should set the correct offsets for the topicPartitions in the replica.
Expectation
LocalLogStartOffset for the replica topic partition should be equal to the LocalLogStartOffset and (Global)LogStartOffset) should be equal to (Global)LogStartOffset).
Reality (bug)
(Global)LogStartOffset) for the replica topic partition is equal to LocalLogStartOffset of the leader. This occurs because the logOffset passed to Log.truncateFullyAndStartAt from ReplicaFetcherThread.buildRemoteLogAuxState is incorrect passed as Leader's leaderLocalLogStartOffset instead of leaderLogStartOffset
Result
In case the leader goes down, the replica becomes the new leader with an incorrect (Global)LogStartOffset) and hence, consumer will not be able to read valid data stored in RemoteStorage.

I have fixed this bug at https://github.com/Hangleton/kafka/commit/a3c1ec2dd4186ce9a03453c705c6eaced9c6e45b. I will open a PR here soon. I am currently working on creating an integration test to assert this scenario.


runtime: gc: fatal issue: stopTheWorldWithSema cost 158 seconds

What version of Go are you using (go version)?

$ go version
go version go1.12.8 linux/amd64

Does this issue reproduce with the latest release?
uncertain
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN="/home/zhoudazhuang/gobin/"
GOCACHE="/home/zhoudazhuang/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/zhoudazhuang/db11/jm/pro"
GOPROXY=""
GORACE=""
GOROOT="/home/zhoudazhuang/usr/local/go1.12.8/go"
GOTMPDIR=""
GOTOOLDIR="/home/zhoudazhuang/usr/local/go1.12.8/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build045404538=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Occasional gc issues with my online service
I added the code in mgo.go
        now1 := nanotime()
	systemstack(stopTheWorldWithSema)
	now2 := nanotime()
	println("stopTheWorldWithSema, cost: ", now2 - now1)

So it can print the time it cost. I got the log:
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=154445 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0]
stopTheWorldWithSema, cost:<PHONE_NUMBER>87

What did you expect to see?
this func cost too long to my service during gc.
What did you see instead?
gc log:
gc 51606 @1829883.099s 2%: 4.8+856+1.3 ms clock, 233+0/39785/0+65 ms cpu, 2593->2608->1325 MB, 2659 MB goal, 48 P
gc bg mark start workers :  0
gc 51607 @1829891.917s 2%: 158596+2074+0.45 ms clock, 7612622+0/16431/0+21 ms cpu, 5765->6516->6133 MB, 5766 MB goal, 48 P

I want to know how this happened, could anyone have any suggestions ?

during this gc, no normal business log except schedule log:
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=56977 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=57101 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=57241 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=57361 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]

the numbers of runqueue increase .

and a scvg log:
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=23752 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0]
scvg12198: 39 MB released
scvg12198: inuse: 6643, idle: 7187, sys: 13830, released: 6600, consumed: 7230 (MB)
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=23883 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0]

I suspect that a certain gouroutine is constantly creating new goroutines and is unable to reach the safe point. STW cannot be completed.

 0 0 0 0 0 0]
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=154425 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0]
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=154435 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0]
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=137 runqueue=154445 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0]
stopTheWorldWithSema, cost:<PHONE_NUMBER>87
finishsweep_m, cost:  26941
SCHED<PHONE_NUMBER>ms: gomaxprocs=48 idleprocs=0 threads=144 spinningthreads=0 idlethreads=138 runqueue=154458 [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0clearp
ools, cost:  7324163

at last , the idle thread from  'idlethreads=137' to 'idlethreads=138'

I'm no expert or stakeholder, but I noticed you're using go1.12...
In go1.14 goroutines are now asynchronously pre-emptible: https://golang.org/doc/go1.14#runtime so maybe it's worth upgrading.
IIUC, go1.12 is also no longer supported anyway.

Can't find the relevant problem point, any suggestions?

I'm no expert or stakeholder, but I noticed you're using go1.12...
In go1.14 goroutines are now asynchronously pre-emptible: https://golang.org/doc/go1.14#runtime so maybe it's worth upgrading.
IIUC, go1.12 is also no longer supported anyway.

Thanks, I will try it.


Update and fix the API Swagger configuration

Updating Swagger required updates to several other dependencies (it was incompatible with our outdated other dependencies). I have updated them too, and all seems ok.
I have applied IntelliJ suggested refactoring to the Facade classes I touched, since I was carefully reviewing them all anyway. I have also updated JavaDoc and comments to be more accurate.
This review may be easier commit by commit, since they are all nicely standalone but may look confusing together (especially optimising the Java imports! It's a separate commit before the rest for a reason).
There are one or two permissions adjustments where some methods in a Facade allowed all staff and others only admins/event managers etc.
I also added some deprecation warnings to endpoints that did not seem to work, or were unused and/or unmaintained. We should review these after Swagger is deployed and remove them if possible.

You should be able to naviagte to http://localhost:8080/isaac-api/api-docs/#/ to test this!


fix: Properly handle url passed into embed image.

What type of pull request is this?

[x] Non-breaking code change
[ ] Breaking code change
[ ] Documentation change/addition

Description

fixes #298
Changes

Defaults to URL property if a string is passed.
Checklist

[x] I've formatted my code with Black
[x] I've ensured my code works on Python 3.10.x
[ ] I've tested my code

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev@69d06dd). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             dev     #299   +/-   ##
======================================
  Coverage       ?   48.93%
======================================
  Files          ?      106
  Lines          ?     8929
  Branches       ?        0
======================================
  Hits           ?     4369
  Misses         ?     4560
  Partials       ?        0

Continue to review full report at Codecov.

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


lksctp-tools: 1.0.17 -> 1.0.19

Changes: https://github.com/sctp/lksctp-tools/blob/master/ChangeLog
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4305

Please rebase

Rebased. Fixed single conflict around licenses change.


bosh for linuxbrew

changes on bosh-cli to work with linuxbrew

it seems to be a duplicate for #53, I have just realised this so I am closing the PR

Closing this PR. The bosh-cli formula is managed via Concourse and our publishing flow, and gets overwritten by the tooling there. This should be fixed via https://github.com/cloudfoundry/bosh-cli/commit/3d10b621ff97ae8b16d1862a27b5de06d240e09e, and future formulas should have a linux compatible binary.
-- Aakash && @krutten


explicit description added to the README.md file

I added a line of description that tells much about the composition of the project

This issue has been solved. Please merge my pull request to effect the change. Thank you


[screengrab] release #19020

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
The code in #19020 has not been released to Maven Central. This means that fastlane screengrab cannot be used without jcenter dependencies.

Pinging @joshdholtz as they merged #19020 - there's no rush for me on this issue but it has been 6 months since the code changes were made

This is still an issue.

        at Build_gradle$1$1.invoke(build.gradle.kts:33)

@joshdholtz

Still an issue @joshdholtz

@joshdholtz

@joshdholtz


CoqStart fails because of invalid identifier

Running :CoqStart gives the error "Error: Invalid character ':' at beginning of identifier ":".". Afterwards, running any coquille command just prints a full screen of "Coq is already running.". No new panels are opened.

Could you confirm that there aren't any other plugins (like Coquille) that might be interfering?

Coquille is not running to the best of my knowledge. I had installed it in the past, but double checked just now to make sure it's not in .vimrc and re-ran :PluginClean.

 A line number or error code?

The only other thing is when scrolling to the bottom of the "Coq is already running." lines that are shown above is says
Error detected while processing function coqtail#Start:
line    1:
E169: Command too recursive
Press ENTER or type command to continue

Ok, I figured out how to reproduce what you're seeing. The initial error message is from Coq if you have something like '-Q . :a' in _CoqProject. Then the infinite loop of error messages is due to an issue with how I'm registering commands that I'll work on.

The same error persists even after updating the plugin to include that commit.

The same error meaning the "Error: invalid character" part or the infinite "Coq is always running"?

My bad, that was ambiguous. The invalid character error is the only one that seems to happen now.

Do you have a _CoqProject file?

Yes, the contents are -Q . LF.

Could you try adding print(coq_path, *args) in python/coqtail.py on line 133 and show me the output when you do :CoqStart?

And have you checked whether you get this error when using CoqIDE?

The output for that is -Q /Users/jacob/Sync/school/pl : thesis/books/software foundations/v1 logical foundations/english/ LF.
I have. There's no problems when using the IDE.

Oh ok, so I think the problem is when . is expanded the spaces aren't getting escaped so Coq thinks you're mapping /Users/... to : and complains that : isn't a valid identifier. CoqIDE seems to handle this correctly when it expands paths, but from some quick checks it seems to fail with an error if you write a path with spaces directly in the _CoqProject file. I'd be curious if you replaced . with the full path in your _CoqProject if you also get an error in CoqIDE.

I pushed a potential fix to coq-proj-escape.

That worked! Yes, CoqIDE did give an error when the full path was substituted for the .. Surrounding it with quotes still worked though. Thank you for the fix.

Great, glad we figured it out. I'll add a little more to better handle spaces in paths and merge it probably later this week.


graph/encoding/dot: NewEdge method of Builder is troubling

@mewmew I'm troubled by the presence of the NewEdge method in the Builder interface. I can see why it's there, but it is almost the same as SetEdge, and that's a problem. Possibly it could go away in the changes associated with the fix to #31?

I'm definitely open to getting rid of NewEdge and agree that it is too similar to SetEdge. The main difference is that NewEdge doesn't update edges if there already exists an edge between from and to, but simply returns it instead.
In general I think there is quite a bit of cleanup we can do in the encoding/dot package, both API and internals, and I'm very glad to see that you've started to take a stab at it : )

I wrote another user-defined graph today which implemented the method sets required for encoding/decoding. Doing so made me recall additional rationale why NewEdge was added in the first place. For the very same reason that NewNode was added (to be used instead of NewNodeID and AddNode).
The graph decoding library cannot know about user-defined node and edge types, but somehow has to be able to create them. Thus NewNodeID in combination with AddNode is not enough, so NewNode was added. The same logic applies to NewEdge.

Yeah, that's fair enough. That argument says that we should move it to graph.Builder.

The issue that I am concerned with still here is the difference in semantics between the NewNode/AddNode pair and NewEdge/SetEdge pair. NewNode does not add the node to the graphs, explicitly. However, the implementation of NewEdge that exists in dot/decode_test.go does add newly created edges to the graph. This needs to be reconciled.

I'm fine with that. Then perhaps graph.EdgeSetter would be renamed to graph.EdgeAdder in accordance with graph.NodeAdder.
To further improve consistency, perhaps NewEdge should behave like NewNode in that it does not add the edge to the graph, only creates it, for later addition with SetEdge? It would make the EdgeAdder interface more consistent with NodeAdder, but most likely make it more annoying to use.
What are your thoughts?
// EdgeAdder is an interface for adding edges to a graph.
type EdgeAdder interface {
	// NewEdge adds a new edge from the source to the destination node to the
	// graph, or returns the existing edge if already present.
	NewEdge(from, to graph.Node) graph.Edge

	// SetEdge adds an edge from one node to another.
	// If the graph supports node addition the nodes
	// will be added if they do not exist, otherwise
	// SetEdge will panic.
	// The behavior of an EdgeAdder when the IDs
	// returned by e.From and e.To are equal is
	// implementation-dependent.
	SetEdge(e Edge)
}

// NodeAdder is an interface for adding arbitrary nodes to a graph.
type NodeAdder interface {
	// NewNode returns a new Node with a unique
	// arbitrary ID.
	NewNode() Node

	// Adds a node to the graph. AddNode panics if
	// the added node ID matches an existing node ID.
	AddNode(Node)
}

The issue that I am concerned with still here is the difference in semantics between the NewNode/AddNode pair and NewEdge/SetEdge pair. NewNode does not add the node to the graphs, explicitly. However, the implementation of NewEdge that exists in dot/decode_test.go does add newly created edges to the graph. This needs to be reconciled.

My previous comment was written before I had a chance to ready you latest reply. I agree, we should figure out how to make them more consistent. Lets make the change so that NewEdge returns an edge that is not yet added to the graph, and see how it affects the current code in the graph decoders. Perhaps they may need a local helper function to make it more pleasant to use, and then we should discuss if all users would write such a helper function, and if that's the case whether convenience or consistency is valued highest.

That SGTM (I figured we were two ships in the night there).
Do you want to do that? Alteration of the decode_test.go and your most recent graph code mentioned about would be good test cases.


Evaluation loss is being reported, but class-based AP scores are 0?

Hi, I have the following log
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] 301/301, 3.2 task/s, elapsed: 93s, ETA:     0sLoading and preparing results...
DONE (t=0.00s)
creating index...
index created!
Running per image evaluation...
Evaluate annotation type *bbox*
DONE (t=0.10s).
Accumulating evaluation results...
2021-10-10 19:27:39,658 - mmdet - INFO - Evaluating bbox...
2021-10-10 19:27:40,055 - mmdet - INFO -
+-----------------+-------+-----------------+-------+---------------+-------+
| category        | AP    | category        | AP    | category      | AP    |
+-----------------+-------+-----------------+-------+---------------+-------+
| person | 0.000 | car | 0.000 | cow | 0.000 |
+-----------------+-------+-----------------+-------+---------------+-------+
2021-10-10 19:27:40,061 - mmdet - INFO - Exp name: cascade_mask_rcnn_swin_small_patch4_window7_mstrain_480-800_giou_4conv1f_adamw_3x_coco.py
2021-10-10 19:27:40,062 - mmdet - INFO - Epoch(val) [3][675] bbox_mAP: 0.0000, bbox_mAP_50: 0.0000, bbox_mAP_75: 0.0000, bbox_mAP_s: -1.0000, bbox_mAP_m: -1.0000, bbox_mAP_l: 0.0000, bbox_mAP_copypaste: 0.000 0.000 0.000 -1.000 -1.000 0.000
DONE (t=0.29s).
Average Precision  (AP) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.000
Average Precision  (AP) @[ IoU=0.50      | area=   all | maxDets=1000 ] = 0.000
Average Precision  (AP) @[ IoU=0.75      | area=   all | maxDets=1000 ] = 0.000
Average Precision  (AP) @[ IoU=0.50:0.95 | area= small | maxDets=1000 ] = -1.000
Average Precision  (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=1000 ] = -1.000
Average Precision  (AP) @[ IoU=0.50:0.95 | area= large | maxDets=1000 ] = 0.000
Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=100 ] = 0.000
Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=300 ] = 0.000
Average Recall     (AR) @[ IoU=0.50:0.95 | area=   all | maxDets=1000 ] = 0.000
Average Recall     (AR) @[ IoU=0.50:0.95 | area= small | maxDets=1000 ] = -1.000
Average Recall     (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=1000 ] = -1.000

Any ideas why?

You may have a problem with the config file such as data train/test/val path, classes, etc.

Thanks a lot for replying so quickly guys! I can confirm my model is overfitting to the training data - and also mysteriously performing too well on the validation set just because of the observed losses (validation was synthesized from train)
My dataset is pretty small, and I am using a 110M+ params model so it overfits quite quickly
2021-10-11 00:51:52,905 - mmdet - INFO - Epoch(val) [2][38] loss_rpn_cls: 0.0002, loss_rpn_bbox: 0.0000, s0.loss_cls: 0.0011, s0.acc: 99.9775, s0.loss_bbox: 0.0001, s1.loss_cls: 0.0010, s1.acc: 99.9634, s1.loss_bbox: 0.0001, s2.loss_cls: 0.0006, s2.acc: 99.9582, s2.loss_bbox: 0.0000, loss: 0.0032

wandb: WARNING Step must only increase in log calls.  Step 1351 < 1352; dropping

{'val/loss_rpn_cls': 0.00016263271544702499, 'val/loss_rpn_bbox': 1.6639697366228672e-05, 'val/s0.loss_cls': 0.0011009046492721321, 'val/s0.acc': 99.97751336348684, 'val/s0.loss_bbox': 0.00014984695927092902, 'val/s1.loss_cls': 0.0010168649431235327, 'val/s1.acc': 99.96337890625, 'val/s1.loss_bbox': 7.71293784246633e-05, 'val/s2.loss_cls': 0.0006183671116320367, 'val/s2.acc': 99.95823910361842, 'val/s2.loss_bbox': 2.7828343215668083e-05, 'val/loss': 0.003170213940106087, 'learning_rate': 1.0281822390660857e-05, 'momentum': 0.9}.

From a tentative run, smaller models seem to be more robust (I will surely train them out tmrw and verify properly)
So its pretty clear that it can indeed validate @jshilong which means that the data is indeed correct (I had manually verified that the bounding boxes of images are aligned) but perhaps the annotations' format might be off... thinking
I was pretty confused with the conflicting results hence the issue.
Again, many thanks for replying so quickly!
EDIT:-
I am also specifying load_from to be a checkpoint for warm restarting - so it takes only about 50 steps to attain maximum scores. @jshilong
Also a better chart
wandb: Run summary:
wandb:    train/loss_rpn_cls 0.0001
wandb:   train/loss_rpn_bbox 1e-05
wandb:     train/s0.loss_cls 0.00046
wandb:          train/s0.acc 99.99414
wandb:    train/s0.loss_bbox 7e-05
wandb:     train/s1.loss_cls 0.00039
wandb:          train/s1.acc 99.99023
wandb:    train/s1.loss_bbox 4e-05
wandb:     train/s2.loss_cls 0.00023
wandb:          train/s2.acc 99.98926
wandb:    train/s2.loss_bbox 2e-05
wandb:            train/loss 0.00129
wandb:         learning_rate 1e-05
wandb:              momentum 0.9
wandb:              _runtime 13883
wandb:            _timestamp<PHONE_NUMBER>
wandb:                 _step 1351
wandb: Run history:
wandb:    train/loss_rpn_cls █▅▆▃▁▂▄▁▄▂▁▃▃▃▃▁▁▂▃▂▂▁▃▂▂▂▂▂▂▃▁▂▁▁▁▁▂▁▁▁
wandb:   train/loss_rpn_bbox ▇██▃▂▄▄▁▂▂▁▄▂▅▂▁▁▂▃▁▃▁▆▆▆▄▁▂▁▂▃▂▁▁▂▁▃▂▁▁
wandb:     train/s0.loss_cls █▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
wandb:          train/s0.acc ▁███████████████████████████████████████
wandb:    train/s0.loss_bbox ▄▅█▃▃▄▆▂▅▂▂▄▂▅▄▂▁▅▃▂▂▂▂▂▃▃▃▂▂▁▂▂▂▁▂▁▂▁▁▁
wandb:     train/s1.loss_cls █▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
wandb:          train/s1.acc ▁███████████████████████████████████████
wandb:    train/s1.loss_bbox ▄▆▇▃▄▅▇▂▆▂▄▇▄██▃▁█▄▃▂▃▃▄▅▆▄▄▄▂▄▄▃▂▃▂▃▂▁▂
wandb:     train/s2.loss_cls █▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
wandb:          train/s2.acc ▁███████████████████████████████████████
wandb:    train/s2.loss_bbox ▂▂▄▃▃▃▄▂▃▂▃▅▄▆█▃▁▇▄▂▃▃▄▅▆█▆▆▄▂▆▄▂▂▃▂▄▂▂▂
wandb:            train/loss █▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
wandb:         learning_rate ████▇▇▇▇▇▇▆▆▆▆▆▆▆▅▅▅▅▅▅▄▄▄▄▄▄▃▃▃▃▃▂▂▂▁▁▁
wandb:              _runtime ▁▁▁▂▂▂▂▂▂▃▃▃▃▃▃▄▄▄▄▄▅▅▅▅▅▅▆▆▆▆▆▇▇▇▇▇▇███
wandb:                 _step ▁▁▁▂▂▂▂▂▂▃▃▃▃▃▄▄▄▄▄▄▅▅▅▅▅▅▆▆▆▆▆▇▇▇▇▇▇███

Sorry for the late response, I guess there are some things wrong in your test Phares, If you make sure the model's visualization is correct, the only reason is the code related to the metric or the way to load annotaions is wrong. Is there any modification of the code? you can debug by visualized your annotations and your predictions of the same image before calculating mAP, then you can localize the bug is in your annotation or in your metric calculation. Good luck!

Many thanks @jshilong, will try both! 🤗
Would you happen to know if mmdetection has any script that easily visualizes bbox predictions @ image, otherwise I wouldn't waste time manually writing one!
I will surely update my findings here - it may be help for someone else! 🚀

Would it help If I send over my dataset for reproducibility? Because I just can't figure out this weird bug disappointed

Sorry I do not have enough time to provide such help


[Router] optional trailing slash not working as intended

At the moment, the process works only if, the route is defined without a trailing slash, i.e.: my/route, then this route matches requests on both my/route and my/route/. This is because the Dispatcher actually removes the trailing slash from the request URI.
If the user defines a route as my/route/ then neither of the above URIs match anymore. This is not the intended operation and must be fixed ASAP.
Both the URI definitions in the route:

my/route
my/route/

must match the following request URIs:

domain.com/my/route
domain.com/my/route/

Furthermore, the documentation states that the user might disable this functionality. This is not reflected in the code, and must be implemented as well.

On second thought, scratch the configurability. If the user wants to require a trailing slash it can be done so by adding a + quantifier at the end.

Resolved. Update documentation.


DMN Decision table column generated from type with constraint

needs to reflect the data type constraint. In other words. If the Decision table is generated for a InputData node, that is referring to a custom DataType (myType: is range [1..100]), then also Decision Table Input Data column needs to reflect this configuration like shown bellow.

Furthermore, we should support this just for the first time decision table generation. Any following updates to data type definition or the Input Data Nodes requirements will be not automatically reflected in the decision table columns.

Fix prepared as https://github.com/kiegroup/kie-tools/pull/1383

ref https://issues.redhat.com/browse/DROOLS-4640
thanks @jomarko


Fixing URL & Directory path in ReadMe

The readme had wrong Git Repo URL and directory path. Fixing the same.

@divbash I have integrated the first proposed fix.
Will close current PR,
feel free to to open a new one if I missed something.
Thanks for contributing !


Buttons for MD formatting

Having a typical toolbar for the comment composer can be helpful. Something like the one we see on github or gitlab

Could we use a more user-friendly editor. Of course, it’s a good idea to limit the formatting options for the end user. It seems to me, it will a good solution, if the mark will use something looks like https://prosemirror.net/examples/markdown/

Oh, I see, you use server render for preview. And client render is not appreciated solution for that case.

Currently, we do the server-side rendering for preview. With such editor, it could be a non-trivial task to keep preview and  WYSIWYM in full sync
It is unclear to me how much this thing extendable for things like image drag-drop, counts and limits
I'm not even sure if rich formatting for comments is a thing. I think 90% of users expecting a place to write a plain text, and maybe another 10% may want to drop a picture.

I suggest using WYSIWYG as your default editor.
I see problem only with  your first point.
The second point possible solve by plugin https://prosemirror.net/examples/upload/ (drag-drop can be add)
Prosemirror generate pure plain text (try switch radio button between markdown and  WYSIWYM  in exapmle). If we are going add formatting button,  why we should show intermediate view for user.

Whatever, it is not simple add synced server and client render. And it is good idea add simple button for textarea.


[Feat]: Add ChatPDF

What feature?
I would like to add ChatPDF - Chat with Pdf.
ChatPDF is an innovative platform that allows users to interact and chat with PDF documents. By integrating natural language processing and AI technologies, ChatPDF enables users to ask questions, extract information, and perform actions within the PDF through conversational interactions. It simplifies document navigation and enhances the user experience by bringing interactivity to static PDF files.
Add screenshots

Code of Conduct

[X] I agree to follow this project's Code of Conduct

will you like to work on this ?

Hello @JasonDsouza212 @VenomFate-619 , I have added my work still my issue has been closed. Please look into the matter


add support for adhoc and universal distribution within enterprise teams

Checklist

[ ] I've added an entry to CHANGELOG.md if necessary.

Why
This is the first part of adding support for internal distribution within enterprise teams.
This PR introduces a new property to eas.json (enterpriseProvisioning: 'adhoc' | 'universe') as well as the support for generating adhoc/universal distribution provisioning profiles.
How

https://github.com/expo/eas-cli/pull/335/commits/4b42fd861ca5c3be8c91a07f51d1f775aa048af1 adds the new optional prop to eas.json (enterpriseProvisioning).
https://github.com/expo/eas-cli/pull/335/commits/6e7513892f00c71413fe69b5c642c22e9662ab20

It makes the SetupProvisioningProfile action generic, which means it's now capable of setting up both app store and enterprise provisioning profiles (it's passed as an argument to the constructor).
I changed the SetupBuildCredentials so it accounts for the enterpriseProvisioning property now.
It adds the new SetupInternalProvisioningProfile action. Right now, it should be considered as a placeholder as it only runs the SetupAdhocProvisioningProfile (this is what currently happens when "distribution": "internal"). I'll implement this in the follow-up PR. This action is going to work only in the interactive mode and will allow choosing between ad-hoc and universal distribution credentials.

Test Plan

I have inited a new project.
I set "distribution": "internal" and "enterpriseProvisioning": "adhoc" in eas.json. I ran a build and noticed that proper ad-hoc credentials were generated.
Later, I set "distribution": "internal" and "enterpriseProvisioning": "universal" in eas.json. I ran a build and noticed that proper universal distribution credentials were generated.

Not part of this PR, but one thing we need to consider is behavior for appstore app, I would see two options here:

make distribution field required in eas.json (without default)
errors in SetupProvisioning Profile (for store) when logged in as enterprise team must be very descriptive(exact info what to change in eas.json)

@quinlanj

lgtm. Just to clarify, we are letting people on Apple Enterprise Accounts create either an Adhoc or Enterprise profile, and people on Apple Developer Accounts only create an Appstore profile? Cuz technically people on Apple Developer Accounts can create adhoc profiles too, but there might not be a usecase for this in ios:build 🤷♀

People on Apple Developer Accounts are also able to create adhoc profiles. They only need to set distribution: "internal" and leave the enterpriseProvisioning prop empty. This is how the "regular" internal distribution works now (and this is why I left the SetupInternalProvisioningProfile "empty" now). I don't know if this is clear now but we can talk about it on Slack :)


Timing does not support times <1ms

The Statter API has:
Timing(stat string, delta int64, rate float32) error
And it expects delta to be in milliseconds. However, the protocol supports floating point numbers, and in a Python library I'm using sub-ms timings and it works perfectly fine with Graphite.
I'm dealing with sub millisecond timings in Go now, and I can't get accurate reading because of this.
Ideally, the Statter's API should look like this IMO:
Timing(stat string, delta time.Duration, rate float32) error
And internally should convert to float for low numbers, and to int for larger ones.
However, in order not to break the API, I'd add a separate method for it, e.g:
TimingDuration(stat string, delta time.Duration, rate float32) error
Anyway, if you're interested I'd be happy to implement and add a PR. let me know.
Thanks :)

I like the TimingDuration proposal. Sounds like a great addition.
If you have time a pull request would be super.

Enjoy #11 :)

fixed by #11


fix &'static lifetime warning

When building a project with 1.74.0-nightly rustc compiler, I receive a warning further described by this thread.
https://github.com/rust-lang/rust/issues/115010

Thanks!


PatternIterators and Java arrays

The typechecker allows this:
ObjectArray<Integer->Float> entries = nothing;
for ([Integer i, Float f] in entries) {
}

but would reject it if entries was a Iterable<Integer->Float>. Likewise using key value iteration over ObjectArray<[Integer, Float]>.

Fixed, it seems.

Yeah, thanks!

Hmm, seems I can't now spread invoke a java iterable into a ceylon iterable:
void f(Iterable<String> s) {
}
JIterable<String> it = nothing;
f(*it);

spread argument not assignable to parameter types: 'String[]' is not assignable to '[{String*}]'

@tombentley wait, that example doesn't make sense. I think you meant to write f{*it}.
Re-closing.


No default for normalization word clouds

Since there is no default for normalizing word clouds, generating of a normalized word cloud yields no output. Perhaps use the middle setting as default?

Strange, it works for me on Chrome. Safari issue maybe?

I am unable to reproduce this issue in Safari. Could you describe the steps that you have taken?

I wasn't unable to reproduce this at first either, but now it does happen with me on Chrome as well (sometimes). Might be a Heisenbug... I assume that there's some rogue asynchronous JavaScript when the application is loaded.

Found the problem; this only happens if you have not yet opened the config window when you ask for a word cloud. After initial opening of the config window everything works as desired. I'll move the opening of the config window to startup of the application.


Sample setup files

Describe the proposal
It would be great of these additional components included sample yaml files and any other valuable instructions that show how to set them up.

@cecilphillip This is coovered in our docs repo https://github.com/dapr/docs/tree/master/howto


cli: Add Hubble section to cilium status output

This adds a new line to the output of cilium status which prints the
state of the embedded Hubble server. If enabled, the output will look
similar to hubble status:
$ cilium status
[...]
Hubble:   Ok   Current/Max Flows: 2542/4096 (62.06%), Flows/s: 164.21   Metrics: Disabled

test-me-please

@gandro Can we also include a flows/s metric?

@gandro Can we also include a flows/s metric?

Sure! It will require some changes to cilium/hubble though. So it will have to wait for #10860

Coverage decreased (-0.05%) to 45.847% when pulling f1aa554671fe82d6b806e06e99d82d3ec16b891d on pr/gandro/add-hubble-server-status into 5d356866c72c471b041b8df5ee1534c52ed5d770 on master.

I have pushed a new version which I believe addresses all of your feedback, thanks!
The most notable change is that the observer now keeps track of its uptime and the total amount of flows observed to compute the overall Flows/s. Note that I do not rely on the Hubble Prometheus metrics for this: First of all it is not enabled by default, and secondly does not allow us to easily compute the flows per second, as it only stores a counter, and requires us to keep track of the overall time (e.g. the uptime) separately anyways.

test-me-please

test-me-please

test-me-please

restart-ginkgo

test-me-please


IOS app crashing while launching

Hi i added fbsdk swift package by following this doc https://developers.facebook.com/docs/ios/getting-started, after adding this package app crashing while launching, but its working if run the project through xcode but not working through command line
also not getting any error logs
Environment
System:
OS: macOS 12.4
CPU: (8) x64 Apple M1
Memory: 28.39 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 14.19.0 - ~/.nvm/versions/node/v14.19.0/bin/node
Yarn: 1.22.18 - ~/.nvm/versions/node/v14.19.0/bin/yarn
npm: 8.7.0 - ~/.nvm/versions/node/v14.19.0/bin/npm
Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
Android SDK:
API Levels: 29, 30, 31, 32
Build Tools: 28.0.3, 29.0.2, 30.0.2, 30.0.3, 31.0.0, 32.0.0, 32.1.0
System Images: android-31 | Google APIs ARM 64 v8a, android-32 | Google APIs ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: 2021.1 AI-211.7628.21.2111.8193401
Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
Languages:
Java: 11.0.11 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.68.1 => 0.68.1
react-native-macos: Not Found
react-native-fbsdk-next: "^9.0.0",

Exact same problem here with the same hardware, no missing Client Token.

ios crash reports should always be accompanied by the crash trace - if you can reproduce this please launch app from Xcode, reproduce, then paste a crash trace, otherwise all I can say is I don't have any crashes so this has no reproduction or root cause analysis I'm aware of


Update for releasing version 1.0.0

What
Changes to bump version to 1.0.0
This code has been in use for a while, and merely repackaged in a gem
here. It therefore makes sense to release this as 1.0.0 and immediately
start following all of semver.
How to review
Code review. Verify that the intended version makes sense.
Once merged, I will tag the merge commit which will cause Travis to release this to rubygems.org
Who can review
Not me.

LGTM


ImageJ plugin saves blank black label images

I'm running the ImageJ plugin using the "Versatile (H&E nuclei)" model. It successfully detects nuclei and shows them in the ROI manager, as well as in the label image window that appears. However when I try to save the label image it saves a blank black tif.
This occurs whether I run it manually or using this script: https://gist.github.com/maweigert/8dd6ef139e1cd37b2307b35fb50dee4a
Below you can see that it is detecting ROIs, even though it isn't saving them correctly.

Here is the saved label image (github won't allow inline tiffs):
Label Image.tar.gz

Here is the saved label image (github won't allow inline tiffs):
Label Image.tar.gz

I opened your label image in Fiji and it looks just fine! Why do you think it's black? Did you maybe open it in a different software that assumes a value range from 0 to 255, hence all objects will appear very dark (since pixel values denote objects ids from 1..70 in this image).


Update index.html

use https when possible
use rel=noopener for external links

/CC @LeaVerou

Hey, thanks for contributing!
Slashes in self-closing tags are perfectly valid HTML5 (though optional). I like using them because they aid readability by signifying that a tag is self-closing without expecting the reader to memorize the list of self-closing tags.
Regarding https, I just merged #29 which fixed some of these. For the rest, if you could open a new PR without removing my slashes, I'd be delighted to merge it :)
Same applies for the new GA snippet: I don't have the time to do it right now, but would gladly merge a PR for it :)

@LeaVerou: I could just rebase this instead of you closing it ;)

Wasn't sure if you'd prefer to do that. Reopened!

Also just noticed the username. Γειά σου συμπατριώτη! 👋

Haha, Καλησπέρα :)
OK, I made the changes, bu the GA snippet isn't the latest one you will get if you visit your GA account. I can revert that too, or you can paste the snippet from your GA page :)

Did you refresh the page? This is the raw patch I have pushed in this branch https://github.com/LeaVerou/contrast-ratio/commit/b7ce0cc4c0c053185ee62db9ae37cd022d963374.patch

Maybe I hadn't, I do see it now! (sorry, τρέχω και δε φτάνω σήμερα)
Merged, thanks!


checkov: 3.1.20 -> 3.1.21

Diff: https://github.com/bridgecrewio/checkov/compare/refs/tags/3.1.20...3.1.21
Changelog: https://github.com/bridgecrewio/checkov/releases/tag/3.1.21
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 272069 run on x86_64-linux 1

2 packages built:

checkov
checkov.dist


when use "gomobile bind" compile a aar,it fail

use 1.8.3
gomobile build and install was success but fail with bind
the console log:
gomobile: loadExportData failed go install -pkgdir=/Users/landsnail/go/pkg/gomobile/pkg_android_arm -gcflags=-shared -ldflags=-shared test failed: exit status 2
go: GOPATH entry is relative; must be absolute path: "".
For more details see: 'go help gopath'
oh, i am using mac with OSX system.
if someone can repply?

Looks like gomobile may need to be updated to handle the new meaning of a missing GOPATH.
For now, you can make it work with: export GOPATH=$HOME/go.


@alloy - Add middleware to block ip addresses

cc @craigspaeth

For posterity: general site slowness was traced to super-aggressive crawling of /sitemap-... paths from a single AWS IP address. Logs included hundreds of lines per minute like the following, with the same IP address and useragent string:
2016-11-22T21:05:36.605689+00:00 app[web.2]: ::ffff:<IP_ADDRESS> - - [22/Nov/2016:21:05:36 +0000] "GET /sitemap-artworks-4-2016-03-01.xml HTTP/1.1" - - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246"
2016-11-22T21:05:36.560720+00:00 heroku[router]: at=info method=GET path="/sitemap-images-1-2016-08-01.xml" host=www.artsy.net request_id=9ce09c98-f1fd-4191-9a8c-585317052662 fwd="<IP_ADDRESS>" dyno=web.2 connect=0ms service=10245ms status=200 bytes=1982995
2016-11-22T21:05:36.561248+00:00 heroku[router]: at=error code=H12 desc="Request timeout" method=GET path="/sitemap-artworks-4-2016-03-01.xml" host=www.artsy.net request_id=f3e2d9e2-186f-491c-9e10-b873f6d9044a fwd="<IP_ADDRESS>" dyno=web.2 connect=3ms service=30001ms status=503 bytes=0

@broskoski @alloy we already had middleware to do this found here https://github.com/artsy/force/blob/master/lib/setup.coffee#L56 😛

@craigspaeth :face_with_head_bandage:

Will revert this then, already added the IP to the blacklist.


General clean up

Changes proposed in this pull request:

Remove license from every file
Rename variable named type overriding builtin
Fixes inconsistent function docstring
Remove ugly print statement

Coverage remained the same at 100.0% when pulling de93b7e37947c88cd960c4fadb7b51d16886b5e6 on rafaelcaricio:clean-up into 5892feb471a9f4757151fabfac25dbabf7073174 on zalando:master.

Coverage remained the same at 100.0% when pulling de93b7e37947c88cd960c4fadb7b51d16886b5e6 on rafaelcaricio:clean-up into 5892feb471a9f4757151fabfac25dbabf7073174 on zalando:master.

Coverage remained the same at 100.0% when pulling 5fa038d2d89c0f4b35161f7becb3a3eb5a1581f5 on rafaelcaricio:clean-up into 5892feb471a9f4757151fabfac25dbabf7073174 on zalando:master.

:+1:


Restricted API Key and gRPC

I want to use an restricted api key over grpc that works only with specific referers to access the text-to-speech api. An unrestricted key works fine with x-goog-api-key but x-origin or x-referer or referer doesnt work for the restricted key. It always returns empty referer. Not supported? Thanks for your help!

Hi there. Thanks for filing an issue. But, this repo is for Go samples embedded on cloud.google.com. If you have a general question, StackOverflow or Cloud Support would be a better fit for these types of questions. StackOverflow also has the benefit of being discover-able by other users. Unfortunately, I'm not sure what the answer is to your question.


How do you trigger the pages-build-deployment action?

Hi @xuhcc ,
Thanks for your continued update of the ReST docs.
I just crawled and pushed, but I wonder how your trigger the pages-build-deployment action.

Hello
I run python build.py gh-deploy

Thank you!


Issue with multiple connections

I have multiple connections as such:
PROD
QA
LOCAL
The local and qa one use localhost:9291 for host  and a user/pass combo.
What QA does different is that it has ssh connection with key pair. (To an external server)
HOWEVER: The QA connection seems to actually be a similar LOCAL connection
NOTE:
PROD server is similar to QA (different key/pair and SSH Host though) BUT it has a different host: app-etc.ninja:9291

Hi @tudorpie , so what's the problem you meet?  Could not connect prod and qa host?

I could connect to prod; qa connection actually connected to localhost instead of going to remote server.

@tudorpie got it I will try to reproduce it with ssh key pair

Hi @tudorpie  please try the latest version: v1.9.31, and also you can download from Jetbrains market v1.9.31.
This issue is caused by refactor in v1.9.28: jsch tunnel connect not correctly handle by connection.
Thanks your feedback, If you meet any issue please let me know.


Add UnoCSS logo

Add UnoCSS logo
Name with link
unocss: https://github.com/unocss/unocss/
Description
The instant on-demand Atomic CSS engine.
Link to the vector file, preferably from an official source
https://github.com/unocss/unocss/blob/main/playground/public/icon.svg

Added in de8fdaf0ce10dc9f0c41e7f0612da5d2d36f4e74
Thanks


Use RECURSION variable in for-loop

To ensure the CantorGasket works with higher and lower recursions, use the variable and deduct one in the for-loop.

RECURSION is the global variable we defined holding the number of recursions. Following the suggestion this was 5.
The commented out for-loop, which offers a tighter code, uses 4 (i.e. recursion - 1). I would thus suggest to actually do that calculation there instead of hard coding the result in. Like this, if for any reason the recursion is changed to a higher or lower number this will automatically adapt maintaining the effect we want.


VEGA-1818 donor parent child bug in create document

added logic to override the base level donor with the parent if it exists. Created new pact and cypress test to cover scenario. VEGA-1818 #patch
Checklist

[ ] I have updated the end-to-end tests to work with my changes

N/A

[ ] I have added styling for Dark Mode

N/A

[ ] I have checked that my UI changes meet accessibility standards

N/A

Codecov Report
Patch coverage: 50.00% and project coverage change: +0.13 :tada:

Comparison is base (0f975c3) 72.71% compared to head (4bb81c5) 72.85%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #315      +/-   ##
==========================================
+ Coverage   72.71%   72.85%   +0.13%
==========================================
  Files          88       90       +2
  Lines        3496     3514      +18
==========================================
+ Hits         2542     2560      +18
  Misses        685      685
  Partials      269      269

Impacted Files
Coverage Δ

internal/sirius/case_type.go
0.00% <0.00%> (ø)

internal/sirius/person.go
29.41% <ø> (ø)

internal/sirius/case.go
100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


cmd/compile: function's interface (send on channel vs normal return) should not affect quality of compilation of function's logic

What version of Go are you using (go version)?

$ go version
go version go1.21.1 darwin/arm64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/amanvm/Library/Caches/go-build'
GOENV='/Users/amanvm/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/amanvm/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/amanvm/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.21.1/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.21.1/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/4v/hg2cqzyx3rd9hv7kx2_7b8w40000gn/T/go-build72951666=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?
Background: This quest started with an observed anomaly that a simple "add 1.0 billion times" program performed slower when work was distributed among 2 parallel goroutines (each doing half the work) compared to a single one doing billion additions. There isn't any interaction between the independent goroutines while they do the computations, so this isn't about synchronization penalties. Nor are new memory pages being touched in the loop, so it isn't about memory either.
Loop in sumpar1 is 4 times slower than sumseq, even though there isn't any difference in loop's logic. The only way they vary is that sumpar1 returns value computed in the function on a channel instead of a normal function return. This observation isn't about delay added by writing to channel itself, it's about the quality of loop compiled in both the functions.
 For a function like sumpar1 that sends result of a tight loop on a channel, break it into two parts: a function that does the tight loop and returns the value normally like sumseq, and create a wrapper function sumpar2 that just instantiates sumseq and returns it's value on channel. You can see the performance results in the listing below entire code (sumpar2 is 4 times faster than sumpar1). Update: using an anonymous function or a useless variable like mentioned in comments: https://github.com/golang/go/issues/63332#issuecomment-1745565902, https://github.com/golang/go/issues/63332#issuecomment-1748585137 also achieves 4x speedup, and would be more maintainable till compiler addresses the issue.
Why is fixing this might be worthwhile? a) the hack of wrapping mentioned in previous para is quite ugly, b) it makes it difficult to reason about go if such optimizations are to be manually done, c) this might be a low-hanging fruit that could help existing codebases. Seems like this could be an easy fix in go's compiler if the optimization is first run on "business logic" and then the interface (channel vs normal function return) is glued to it later. Though I am not a compiler expert.
func sumseq(numiter int) float64 {
	sum := 0.0
	for i := 0; i < numiter; i++ {
		sum += 1.0
	}
	return sum
}

func sumpar1(numiter int, c chan<- float64) {
	sum := 0.0
	for i := 0; i < numiter; i++ {
		sum += 1.0
	}
	c <- sum
}

func sumpar2(numiter int, c chan<- float64) {
	c <- sumseq(numiter)
}

Complete code (count.go):
package main

import (
	"fmt"
	"time"
)

const (
	numiterations = 1_000_000_000
	numworkers    = 2
)

func sumseq(numiter int) float64 {
	sum := 0.0
	for i := 0; i < numiter; i++ {
		sum += 1.0
	}
	return sum
}

func sumpar1(numiter int, c chan<- float64) {
	sum := 0.0
	for i := 0; i < numiter; i++ {
		sum += 1.0
	}
	c <- sum
}

func sumpar2(numiter int, c chan<- float64) {
	c <- sumseq(numiter)
}

func main() {
	c := make(chan float64, numworkers)

	// distribute counting among #numworkers parallel routines
	// using sumpar1
	start := time.Now()
	result := 0.0
	for i := 0; i < numworkers; i++ {
		go sumpar1(numiterations/numworkers, c)
	}
	for i := 0; i < numworkers; i++ {
		result += <-c
	}
	delta := time.Since(start)
	fmt.Printf("sumpar1 result: %f took: %v\n", result, delta)

	// distribute counting among #numworkers parallel routines
	// using sumpar2
	start = time.Now()
	result = 0.0
	for i := 0; i < numworkers; i++ {
		go sumpar2(numiterations/numworkers, c)
	}
	for i := 0; i < numworkers; i++ {
		result += <-c
	}
	delta = time.Since(start)
	fmt.Printf("sumpar2 result: %f took: %v\n", result, delta)

	// do all counting in single routine
	// using sumseq
	start = time.Now()
	result = sumseq(numiterations)
	delta = time.Since(start)
	fmt.Printf(" sumseq result: %f took: %v\n", result, delta)
}

Output:
sumpar1 result:<PHONE_NUMBER>.000000 took: 1.780064625s
sumpar2 result:<PHONE_NUMBER>.000000 took: 484.627042ms
 sumseq result:<PHONE_NUMBER>.000000 took: 940.366166ms

What did you expect to see?
The compilation quality of a function's "business logic" should not be affected if output is returned on channel vs returned normally.
What did you see instead?
Returning on channel affects compilation quality of logic in function.
Check the assembly of the loop for sumseq and sumpar1 on an ARM64 machine below. Similar degradation in assembly is seen on other architectures (though I don't have a way to benchmark them):
sumseq:
	0x000c 00012 (count.go:15)	ADD	$1, R1, R1
	0x0010 00016 (count.go:16)	FMOVD	$(1.0), F1
	0x0014 00020 (count.go:16)	FADDD	F1, F0, F0
	0x0018 00024 (count.go:15)	CMP	R1, R0
	0x001c 00028 (count.go:15)	BGT	12

sumpar1:
	0x0028 00040 (count.go:24)	FMOVD	main.sum-8(SP), F0
	0x002c 00044 (count.go:24)	FMOVD	$(1.0), F1
	0x0030 00048 (count.go:24)	FADDD	F1, F0, F0
	0x0034 00052 (count.go:24)	FMOVD	F0, main.sum-8(SP)
	0x0038 00056 (count.go:23)	ADD	$1, R2, R2
	0x003c 00060 (count.go:23)	CMP	R2, R0
	0x0040 00064 (count.go:23)	BGT	40

I think this is a consequence of variables being sent to a channel effectively having their address taken, disabling register allocation for them.
We should fix this. Probably a vestige of old bits of the compiler.

cc @golang/compiler

I think this is a consequence of variables being sent to a channel effectively having their address taken, disabling register allocation for them.

I've been thinking for a little bit that maybe we shouldn't mark variables addrtaken due to runtime calls at all, at least for SSA-able types. Instead, if we need to pass a value by address to the runtime and it's not already addrtaken, we allocate a temporary variable to spill into it just for the runtime call.

@amanvm No, the change I suggested would only help the first case.
The second and third cases require pointer alias analysis, which we don't currently do much of. E.g., in case two, it's possible through the use of package unsafe for sp.sum and in[start:end] to alias.
Case 3 seems like it should be possible to optimize if we had a pass that looked for memory-resident variables that could be lifted to SSA form.

@0-issue Correct, only the first issue is fixed.
Filing issues for the other two is fine. I'd suggest filing them as two separate issues, because they're going to need different fixes. Please link back to this issue if you do.
Thanks.

This change wsn't backported, it'll only be available in the next minor release (1.22.0)


Model#find_by_hashid method is falling back on the standard find method

Hi!
Currently using version 1.0.0 and just noticed that the Model#find_by_hashid method returns my models even if I pass the original integer id values...
If I open the rails console and type Company.find_by_hashid(1) I get my company with id=1... same thing with other ids... Normally, passing 1 as the argument here should not return the company...

As a workaround, I added this validation for now to make sure in a specific sensitive page no visitor can guess the ids with incremental integer values...
# if I enter "1" as the id in the url, the find_by_hashid still works...
@company = Company.find_by_hashid!(params[:id])
throw 'Used incorrect ID to access offer' if @company.hashid != params[:id]

Thanks @frederickdubois for opening this issue. I have a PR in progress to correct the behavior: https://github.com/jcypret/hashid-rails/pull/41. Should be ready to go soon.

Issues resolved and release in version 1.2.0.


Enhancement request - readable name for credentials

When creating credentials, it will be useful to have a human-readable explanation of what it each credential set is used for.

I fully support this.  I believe you can resolve all issues with the current situation.  But the price is hugely increased management and ops burden on our users.
This is one way of resolving it.  It is part of many similar user experiences.
Cons

Not part of the AWS access key ID experience.
Workaround available: use another user.

Pros

Part of every token experience.  For instance, GitHub tokens force me to attach a name to every token.  One of mine is named "Emacs Forge", so I know precisely what it does :-)* Make access key IDs manageable by humans.  For example: I leave my laptop somewhere.  Which access key ID do I need to delete?

Automated systems need to attach metadata to a credentials pair.  Consider a script that creates a dev env on a lakeFS.  It might need to create credentials to put on a Spark profile.  Without metadata, that dumps an impossible key management problem onto users.
We actually had this very problem during the new lakeFS wizard.  We dropped that wizard for other (good) reasons, but this was a thorn during use and even during development.

Workaround (create new accounts) adds considerable administrator management burden.


ci: Require Signed-off-by

Modify the .ci/run.sh script to require the Signed-off-by line in the commit

We could add a little python script to help with this if need be. We can't enable the DOC bot unfortunately so we have to write a script.

There's really no reason to do this


No trained weights/generated audios?

We just merged in a pytorch wrapper -- in the pytorch/README.md file, you'll find a pointer to weights and generated audios.


Doesn't seem to handle multi-disc games correctly.

When it comes to multi-disc games, the second disc is supposed to be put in the same folder as the first disc but labeled "Disc2.iso"
It just puts it in it's own folder like a different game which will impact Nintendont's ability to handle the disc swap I believe.

When it comes to multi-disc games, the second disc is supposed to be put in the same folder as the first disc but labeled "Disc2.iso"
It just puts it in it's own folder like a different game which will impact Nintendont's ability to handle the disc swap I believe.

Checking this in code now.

So basically.. Ugh
Take poorly named iso file 'Baten kaitos Origins seconddisc.iso'
Scanned - > Internal name is Baten Kaitos Origins, ID is GK4E01, and Disc ID is 0x01
We have the choice of using xml name if downloaded, though I believe this one is a bad example, as its the same.
When running through GCIT, (scrubbing) I believe it defaults gcit's behavior to the game's internal name. Would you want the file then moved from .. Lets go with Eternal wings. The XML title is Baten Kaitos Eternal Wings and the Lost Ocean, but when scrubbed the title is simply Baten Kaitos. If using the xml title (for display at least, if gcit overrides that anyway?) we should then move the file to 'x:\games\Baten Kaitos and the Lost Ocean [GKBEAF]\game.iso' from 'x:\games\Baten Kaitos [GKBEAF]\game.iso' ...
Right?

Did it with a scrubbed install. But just need the disc2.iso put in the same folder as the game.iso
Easy enough to fix manually but many won't know to do that or how to.

Did it with a scrubbed install. But just need the disc2.iso put in the same folder as the game.iso
Easy enough to fix manually but many won't know to do that or how to.

Alright, so you don't also need the sys folder from disc 2? I'm assuming since it's a bootloader it would be donated in the first?

Still learning how Nintendont works myself so can't give too much definititely but that sounds about right.
Sorry, I wish I could give you better information myself but learning this as I go setting up an old WiiU to replace my nephews old Wii & Gamecube entirely. So don't know too much about it myself yet.
Just know that for Nintendont to work it requires the 2 discs to be in the same folder and like I mentioned.

New release is out


[config] suggest inclusion of mod_geoip... before mod_ssi.

In modules.conf, mod_geoip needs to be loaded before mod_ssi, otherwise GeoIP vars won't be available to SSI pages.
In geoip.conf suggest GeoLiteCity.dat instead of GeoCityLite.dat.

Thanks.  PR will be picked up soon.

Cool!
BTW, sorry for not having sent yet my improved version of mod_geoip.
(I did not find the time to clean/improve some parts of my code...)

i'd love to see if the engine can decide itself which order modules need to be loaded. i.e geoip says i need to be before ssi. there are lots of systems (php, apache, ... etc) where this needs to be ordered and distributions have to resort to using conf.d style file fragments with 01-, 10-, ... prefixes.
@gstrauss something doable?

@glensc , is this an issue that people trip over frequently with lighttpd modules?  I am not aware of such.  Yes, there is a suggested order for loading lighttpd modules for expected functionality, mostly due which hooks run when, and which modules run during which hooks.
However, unlike some other web servers, lighttpd modules tend to be standalone and not interact much with other modules.  This may provide slightly more limited functionality compared to some other web servers, but it also tends to reduce complexity.
Is there evidence that module ordering is a hard problem for people to solve in lighttpd when they load lots of lighttpd modules?  I am interested in more info if this affects more than a quorum of people, but otherwise there are more important priorities on my list of requested lighttpd enhancements.

I don't know if there would be situations were two different load sequences would produce slightly different functionality (and yet still make sense), but having an automated dependency resolver would make the configuration less flexible, unless, of course, extra parameters were added to allow an unusual ordering.

@gstrauss well, i'm not saying it's highest! urgent! priority! task that should be implemented or that it's most common problem with lighttpd setups.
i've done some initial ordering fixes in ~2006 and it has not needed much changes in that area afterwards. but i might not need the changes because i got lucky (geo < ssi in alphabet) and i do not use all modules in my setups.
$ ls /etc/lighttpd/conf.d/??_*.conf

10_mod_rewrite.conf
11_mod_redirect.conf
50_mod_access.conf
50_mod_alias.conf
50_mod_auth.conf
50_mod_cgi.conf
50_mod_cgi_php.conf
50_mod_cml.conf
50_mod_deflate.conf
50_mod_dirlisting.conf
50_mod_evasive.conf
50_mod_evhost.conf
50_mod_fastcgi.conf
50_mod_flv_streaming.conf
50_mod_geoip.conf
50_mod_indexfile.conf
50_mod_mysql_vhost.conf
50_mod_proxy.conf
50_mod_rrdtool.conf
50_mod_scgi.conf
50_mod_secdownload.conf
50_mod_setenv.conf
50_mod_simple_vhost.conf
50_mod_ssi.conf
50_mod_staticfile.conf
50_mod_status.conf
50_mod_uploadprogress.conf
50_mod_userdir.conf
50_mod_usertrack.conf
50_mod_webdav.conf
55_mod_expire.conf
55_mod_magnet.conf
60_mod_compress.conf
90_mod_accesslog.conf
91_mod_extforward.conf

but i dislike that part that such manual module load order must be done at all.
of possible solutions, perhaps add some internal priority for each hook that module has, some number in range -100 ... 100., so that such problems as:

In modules.conf, mod_geoip needs to be loaded before mod_ssi, otherwise GeoIP vars won't be available to SSI pages.

can be solved with (default priority is 0):

mod_geoip: { .export_http_vars: { .priority: -50, handler: handler } }
mod_ssi: { .export_http_vars: NULL }

in my distribution each lighttpd module has it's own conf.d config that does server.modules += ( "mod_<modname>" ) and defines rest of module specific variables with few defaults resulting highly modular setup when each module can be enabled/disabled.

As already mentioned, most modules do not interact.  mod_rewrite, mod_cml, and mod_magnet are the most likely to interact since they might restart requests.  Any dynamic handlers all run in the subrequest hook and there can be only one handler, so those reset state if they restart the request (mod_fastcgi and mod_cgi might).  The only reason mod_geoip and mod_ssi ordering matter is because mod_ssi currently is in the subrequest_start hook, but ought to move its handling into the subrequest hook, at which point there would be no potential ordering issue with mod_geoip and mod_ssi.  There are some open feature requests for mod_ssi, and mod_ssi is likely to move its handling to the subrequest handler in the future.
The reason I mentioned priorities when talking about this suggestion of yours is that there are multiple ways to do this, and multiple workarounds if issues occur, and your specific use of a directory of *.conf is one way to do it (among a number of options), and your prefixing of the files with numbers is a valid way to control module ordering when you have a directory of *.conf files which I presume are globbed to be loaded.  Another option is to list the modules in a specific order in the lighttpd.conf file, instead of globbing.
In summary, while this would be a "nice to have" for some people, there are so many valid and existing ways to do this that I hardly see why it worth discussing further, unless -- as I mentioned in my first post -- this is causing problems for people, and I was not previously aware.

I feel a little bit of electricity, although there is imho no reason for it. I'm sure @glensc also knows an automated dependency solver would be a "nice to have" ; he was just showing that, like most distros, the one he uses has everything that is needed to ensure the modules are loaded in a correct order.
I apologize for this whole message. You are both so much more experienced developers than me, that I hardly explain how did I dare to write this message!!! ;-)

@fbrosson, I give more currency to the opinions of those who produce code behind their ideas, and less to those dictating work to others with little justification for the work besides "nice to have".  If someone spends some of their own time attempting to implement something, it lends some credence to the proposition that it is a problem worth solving.  Otherwise, I have an existing list of problems that are worth solving, and the "nice to have" without justification or priority is not on that list, primarily because of the missing justification and priority.  Sure, it would be nice to have.

I totally agree with you that this is just a "nice to have" and that, given the number of more important things, this "nice to have" will remain a "nice to have" forever, and I believe this is not a problem for anyone ;-)


Fails when the browser is set to a zoom level different than 100%

The new version 0.15 implements a workaround for a floating point-related bug that may solve this issue, but I haven't tested it yet.

Tested and working! The recent 0.15 version that addressed a bug with floating point widths has also solved this bug. Meow!

Sadly, I've re-checked this and it seems it's not really solved yet :(

Seems I finally solved this bug, it is related to a docummented jQuery bug that causes jQuery to report wrong div sizes in certain situations when the browser is zoomed in or out: https://github.com/jquery/jquery/issues/3808
Using a jQuery version >= 3.3.0 makes the bug disappear in the browsers I tested (latest versions of Chrome, Safari and Firefox in Mac Os as of august 2018).
I'm adding this information to the README file and updating the minimum required jQuery version accordingly.
Meow!


refactor(container): mark container exceptions with ContainerException

This pull request introduces a marker interface, ContainerException. It's useful for catching only exceptions related to the container:
try {
    $this->container->get(SomeDependency::class);
} catch (ContainerException) {
    // Do something
}

I am using this in https://github.com/tempestphp/tempest-framework/pull/829. Not merging immediately, as I know @brendt is not a fan of marker interfaces 👀

Feel free to merge! It makes sense in case of exceptions 👍

Oh, I already pressed merge. Well; good.

It makes sense in case of exceptions 👍

@brendt are you says that's the... one exception? 🥁


compiler crash: Functions in generic context must have an interface type

reproduced on DEVELOPMENT-SNAPSHOT-2022-09-27-a:
struct S
{
    static
    func x(_ s:some StringProtocol) -> String
    {
        .init(s)
    }
    static
    subscript(s:some StringProtocol) -> String
    {
        Self.x(s)
    }
}

$ swiftc test8.swift
error: compile command failed due to signal 6 (use -v to see invocation)
Functions in generic context must have an interface type
(accessor_decl range=[test8.swift:10:5 - line:12:5] 'anonname=0xbef4aa0' interface type=' (S.Type) -> (some StringProtocol) -> String' access=internal captures=(<generic> ) type get_for=subscript(_:)
  (parameter "self")
  (parameter_list range=[test8.swift:9:14 - line:9:36]
    (parameter "s" type='some StringProtocol' interface type='some StringProtocol'))
  (call_expr type='String' location=test8.swift:11:14 range=[test8.swift:11:9 - line:11:17] nothrow
    (dot_syntax_call_expr type='(some StringProtocol) -> String' location=test8.swift:11:14 range=[test8.swift:11:9 - line:11:14] nothrow
      (declref_expr type='(S.Type) -> (some StringProtocol) -> String' location=test8.swift:11:14 range=[test8.swift:11:14 - line:11:14] decl=test8.(file).S.x@test8.swift:4:10 [with (substitution_map generic_signature= (substitution some StringProtocol -> some StringProtocol))] function_ref=single)
      (argument_list implicit
        (argument
          (type_expr type='S.Type' location=test8.swift:11:9 range=[test8.swift:11:9 - line:11:9] typerepr='S'))))
    (argument_list
      (argument
        (declref_expr type='some StringProtocol' location=test8.swift:11:16 range=[test8.swift:11:16 - line:11:16] decl=test8.(file).S.<anonymous>.s@test8.swift:9:15 function_ref=unapplied)))))
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.
Stack dump:
0.      Program arguments: /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-27-a/usr/bin/swift-frontend -frontend -c -primary-file test8.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -color-diagnostics -new-driver-path /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-27-a/usr/bin/swift-driver -empty-abi-descriptor -resource-dir /home/ec2-user/.swiftenv/versions/DEVELOPMENT-SNAPSHOT-2022-09-27-a/usr/lib/swift -module-name test8 -o /tmp/TemporaryDirectory.nrsWjH/test8-1.o
1.      Swift version 5.8-dev (LLVM ed4d811c2897d77, Swift 8491f52d478aca6)
2.      Compiling with the current language version
3.      While walking into decl 'S' (at test8.swift:1:1)
4.      While walking into 'S' (at test8.swift:1:1)
5.      While verifying AccessorDecl getter for subscript(_:) (at test8.swift:9:5)
6.      While verifying FuncDecl getter for subscript(_:) (at test8.swift:9:5)
7.      While verifying AbstractFunctionDecl getter for subscript(_:) (at test8.swift:9:5)

does not crash if the subscript is desugared to the where-based syntax.

Oops. At least with a read-only subscript, I think this should work.

It looks like this came with [SE-0341](https://github.com/apple/swift-evolution/blob/main/proposals/0341-opaque-parameters.md) and the crash is due to AbstractFunctionDecl::isGenericContext being based on getGenericParams() which is nullptr in this case for AccessorDecl because createOpaqueParameterGenericParams seems to not be able to create the implicit generic param list correctly because it should look through subscript(storage) signature instead of itself. This commit fixes the crash and I think it makes sense to me, but maybe there is more to it? @slavapestov

Your fix looks good! Two minor suggestions:

You don't have to cast the result of getStorage() to ValueDecl since ValueDecl is a superclass of AbstractValueDecl.
It would be better to add the test case to test/type/opaque_parameters.swift

@LucianoPAlmeida For the future, please let me know before you start working on an issue that I have assigned myself to, so that we can avoid potential "effort races".

@LucianoPAlmeida For the future, please let me know before you start working on an issue that I have assigned myself to, in order to avoid potential "effort races".

For sure, sorry for that Anthony!

Reported via radar too: rdar://100783783