[Feature] Support for Or-package

Goal
Support requirements that depend not not on only a range of different versions, but also a range of different packages.
Motivation
It's rare for this to have been an issue, I've only encountered it once so far for a very specific case. Qt.py requires either PySide, PySide2, PyQt4 or PyQt5, and yet there is no way to make this request; it can't depend on all, and it can't depend on none.
However, it dawned on me that this can also solve #21 which would be great, and could potentially squat two flies with one stone.
Implementation
Syntax is still not clear, but spontaneously I found the | symbol quite intuitive.
From your package.py
requires = [
  "pyyaml-2.4",
  "six-1.1",
  "PySide-1.2|PyQt4-4.7|PyQt5-5.7.1|PySide2-5.11"
]

And from the command-line.
$ rez env mayapy|python

Where the first package found is picked.
As an added bonus, we'll also (finally) be able to account for #21 by adding a "null" package that does nothing.
requires = [
  "packageA-1.2|null"
]

Now both packageA-1.2 and null are equally acceptable. If packageA-1.2 isn't found, it would behave as though it was optional and not break the solve.

There are already two ways to largely achieve the goal here.
The first is variants. The downside to variants in this case is that you
would be installing 4 different copies of the package payload, even though
there's no difference between them. Had this been a compiled package
though, variants would probably have been the best way to achieve this (by
way of example).
The second approach, is imo is arguably better, is to use a late-bound
requires:
@late()
def requires():
    variants = []
    if "PySide" in request:
        variants.append(["PySide-1.2"])
    ...
    return request

The problem with the Or'd syntax in your example is that there's no way to
control which dependency you're actually going to get. For example, the
PyQt5 dependency isn't invalid just because PySide might be in the request

there's nothing special about these packages as far as rez is concerned,
and they don't conflict with one another. Using a late-bound requires fixes
this problem - the behaviour of the package is clear that, if PySide is in
the request, then the PySide dependency becomes activated.

Technically it may be possible to get or'd requires to work, but I'm fairly
sure it's going to be pretty difficult to do, and I'm concerned that this
feature, in combination with variants, will cause some quite complicated
problems. Or'd package requirements would require significant updates to
the solver. Right now I would categorize this feature request as possibly
nice to have, but at the cost of potentially significant complexity, and
significant development cost. Imo there are other features we could work on
that would bring greater benefit to the project, at lower dev cost.
A
ps - The example syntax given doesn't work, because even though it doesn't
look like it, what you have there is a valid standard version range.
PySide-1.2|PyQt4-4.7
== (PySide-1.2 OR PySide-PyQt4-4.7).
On Thu, Jun 6, 2019 at 9:30 PM Marcus Ottosson<EMAIL_ADDRESS>wrote:

Goal
Support requirements that depend not not on only a range of different
versions, but also a range of different packages.
Motivation
It's rare for this to have been an issue, I've only encountered it once so
far for a very specific case. Qt.py requires either PySide, PySide2, PyQt4
or PyQt5, and yet there is no way to make this request; it can't depend on
all, and it can't depend on none.
However, it dawned on me that this can also solve #21
https://github.com/nerdvegas/rez/issues/21 which would be great, and
could potentially squat two flies with one stone.
Implementation
Syntax is still not clear, but spontaneously I found the | symbol quite
intuitive.
From your package.py
requires = [
"pyyaml-2.4",
"six-1.1",
"PySide-1.2|PyQt4-4.7|PyQt5-5.7.1|PySide2-5.11"
]
And from the command-line.
$ rez env mayapy|python
Where the first package found is picked.
As an added bonus, we'll also (finally) be able to account for #21
https://github.com/nerdvegas/rez/issues/21 by adding a "null" package
that does nothing.
requires = [
"packageA-1.2|null"
]
Now both packageA-1.2 and null are equally acceptable. If packageA-1.2
isn't found, it would behave as though it was optional and not break the
solve.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nerdvegas/rez/issues/643?email_source=notifications&email_token=AAMOUSSNJ352J3XWJ64LPHLPZDYPBA5CNFSM4HVBAARKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GX75EHA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMOUSRDXMCCDQE3T4XPNUTPZDYPBANCNFSM4HVBAARA
.

*Example code should have read 'return variants'
On Fri, Jun 7, 2019 at 10:32 AM Allan Johns<EMAIL_ADDRESS>wrote:

There are already two ways to largely achieve the goal here.
The first is variants. The downside to variants in this case is that you
would be installing 4 different copies of the package payload, even though
there's no difference between them. Had this been a compiled package
though, variants would probably have been the best way to achieve this (by
way of example).
The second approach, is imo is arguably better, is to use a late-bound
requires:
@late()
def requires():
    variants = []
    if "PySide" in request:
        variants.append(["PySide-1.2"])
    ...
    return request

The problem with the Or'd syntax in your example is that there's no way to
control which dependency you're actually going to get. For example, the
PyQt5 dependency isn't invalid just because PySide might be in the request

there's nothing special about these packages as far as rez is concerned,
and they don't conflict with one another. Using a late-bound requires fixes
this problem - the behaviour of the package is clear that, if PySide is in
the request, then the PySide dependency becomes activated.

Technically it may be possible to get or'd requires to work, but I'm
fairly sure it's going to be pretty difficult to do, and I'm concerned that
this feature, in combination with variants, will cause some quite
complicated problems. Or'd package requirements would require significant
updates to the solver. Right now I would categorize this feature request as
possibly nice to have, but at the cost of potentially significant
complexity, and significant development cost. Imo there are other features
we could work on that would bring greater benefit to the project, at lower
dev cost.
A
ps - The example syntax given doesn't work, because even though it doesn't
look like it, what you have there is a valid standard version range. PySide-1.2|PyQt4-4.7
== (PySide-1.2 OR PySide-PyQt4-4.7).
On Thu, Jun 6, 2019 at 9:30 PM Marcus Ottosson<EMAIL_ADDRESS>wrote:

Goal
Support requirements that depend not not on only a range of different
versions, but also a range of different packages.
Motivation
It's rare for this to have been an issue, I've only encountered it once
so far for a very specific case. Qt.py requires either PySide, PySide2,
PyQt4 or PyQt5, and yet there is no way to make this request; it can't
depend on all, and it can't depend on none.
However, it dawned on me that this can also solve #21
https://github.com/nerdvegas/rez/issues/21 which would be great, and
could potentially squat two flies with one stone.
Implementation
Syntax is still not clear, but spontaneously I found the | symbol quite
intuitive.
From your package.py
requires = [
"pyyaml-2.4",
"six-1.1",
"PySide-1.2|PyQt4-4.7|PyQt5-5.7.1|PySide2-5.11"
]
And from the command-line.
$ rez env mayapy|python
Where the first package found is picked.
As an added bonus, we'll also (finally) be able to account for #21
https://github.com/nerdvegas/rez/issues/21 by adding a "null" package
that does nothing.
requires = [
"packageA-1.2|null"
]
Now both packageA-1.2 and null are equally acceptable. If packageA-1.2
isn't found, it would behave as though it was optional and not break the
solve.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nerdvegas/rez/issues/643?email_source=notifications&email_token=AAMOUSSNJ352J3XWJ64LPHLPZDYPBA5CNFSM4HVBAARKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GX75EHA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMOUSRDXMCCDQE3T4XPNUTPZDYPBANCNFSM4HVBAARA
.


Update permissions-reference.md

Removed Knowledge Manager from "All roles" section

@rolyon
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#please-close


Expose virEventAddHandle

It's very important to get events when things happen in libvirt. I've been digging into this code and the libvirt code (in particular virevent.c), and have some observations:
Calling EventRunDefaultImpl in a loop, is useless without virEventAddTimeout because there is no way to trigger it to return so you can shutdown and break that polling loop if the EventRunDefaultImpl call is blocked. However, for some reason it seems to return in bursts every 5 seconds... Anyone know why?
Secondly, is there a way in libvirt to switch to a select style wait, instead of a polling style loop?
Thanks!

The default implementation is already "evented". You should use it like this:
		go func() {
			for {
				if res := libvirt.EventRunDefaultImpl(); res < 0 {
					// Report the error somehow or break the loop.
				}
			}
		}()

EventRunDefaultImpl() will wait for one event and handle it, then return. If you want to interrupt it, you can either wait for some event to happen (if you use keepalives, there are events even nothing happens) or you will need to use a pipe and register one end in the event loop to trigger an event. Unfortunately, those parts are not currently exposed in libvirt-go. I don't bother stopping it, I start it using sync.Once. You can also start it in init().

On Tue, Oct 18, 2016 at 3:06 PM, Vincent Bernat
<EMAIL_ADDRESS>wrote:

EventRunDefaultImpl() will wait for one event and handle it, then return. If you want to interrupt it, you can either wait for some event to happen (if you use keepalives, there are events even nothing happens) or you will need to use a pipe and register one end in the event loop to trigger an event. Unfortunately, those parts are not currently exposed in libvirt-go. I don't bother stopping it, I start it using sync.Once. You can also start it in init().

Any idea why it triggers in bursts every five seconds?

Do you use keepalives?

Do you use keepalives?

Haven't added any yet. Unless they are added automatically when you use something else...

They are not used automatically. But you don't have any events? Or maybe you are just concerned by the fact that you have bursts? In this case, I wouldn't care much. Maybe an event is translated or trigger several events and EventRunDefaultImpl() only handles them one at a time.

@vincentbernat Okay, is there any way to cause EventRunDefaultImpl to return ?

Not from Go. We need to expose virEventAddHandle(). Then, you can interrupt EventRunDefaultImpl() by using Pipe() and registering the reader part with virEventAddHandle(). Then, when you want to stop EventRunDefaultImpl(), you set some "stop" flag and write to the pipe. Break the for loop when the stop flag is set.
I don't think that's useful as you can run the for loop in a separate go routine and never really need to stop it. The loop handles libvirt internal events and as libvirt is thread safe, there is no downside to running it in a separate goroutine/thread.

@vincentbernat Fully agree with everything you said, except that I think it would be more correct to "clean it up" by guaranteeing an exit (besides when golang just exits).
Thanks for confirmation. I'm going to aim to go for the easier patches first, but maybe I'll loop back around to this one. Cheers!

Without exposing virEventAddXXX(), we could have EventRunDefaultImplWithContext() that would take a context and make the whole stuff cancellable. We would still need to do all the pipe dance but not exposing virEventAddHandle() is easier since we don't have to handle callbacks.

@purpleidea in case you want to use the libvirt events for you mgmt project, I collected some of the shortcomings of the libvirt events today and started a discussion on the libvirt mailinglis on how to improve them [1].
[1] https://www.redhat.com/archives/libvir-list/2016-November/msg01318.html

@rmohr Awesome, thank you for starting the discussion... Couple of questions:

missed events

Have you been able to cause this to happen? If so, it should be reported as a serious bug. Is it being tracked somewhere, and can you reproduce it?

responsiveness of my VM state watchers

Out of curiosity, what is your application for all this? AFAICT, you're not working on mgmt at the moment...

Want to help out with mgmt? Come hang with us in #mgmtconfig on Freenode.

Thanks again!


Add secret export option to aws cli

Add option to export aws cli command as secret

Would you mind adding a Signed-off-by line (a.k.a. DCO) to your commit message @Butterneck?
We can get this merged from my POV after we have that & all checks pass.

@Butterneck you can git commit --amend -s to do the sign-off then force push.


Upgrade to frame 1.0.1

Removed unneeded overlay file for app-config.
Added in seed for configuring GA

:+1:


Including SlowFast in LocPointTransformer

Hi, I have a question: assuming no GPU memory related problems, I was wondering how to modify the model, and its parameters, if a SlowFast network were to be inserted as a backbone (just before the ConvTransformer, for example) and thus avoid using 'pre-generated' features but train it throughout the model.
For example, shall we need to use temporal grids as already done? Maybe change the learning rate, or truncate the features during training or something else?
Thanks a lot!

I think you still need temporal grids, i.e., making the input clips has some overlaps cause directly feeding the whole video will result in non-overlapping features. Also, you should make the learning rate small for backbone (SlowFast part), and larger for ActionFormer part.

Hi, thanks for the fast reply.
So I should use the usual formula to compute the grids
feature_grid = (timestamp * FPS - 0.5 * window_size) / feature_stride
But with window_size and feature_stride adapted from the configuration I'm using for extracting embeddings from SlowFast.
During training should I still need to truncate the features extracted from SlowFast before passing them to the ConvTransformer?https://github.com/happyharrycn/actionformer_release/blob/e559d1c4ba85ba24650067c6f6a9db605ae3ecb8/libs/datasets/epic_kitchens.py#L189

"truncated feats" is used to form a training batch, for short actions, we pad them to the fixed length, for long actions, we truncate them into the fix length, I think you still need it.

One thing to notice is that some of the current operations such as feature truncation, or input preprocessing do not support back propagation and thus will block the gradients to the video backbone. This can be easily modified by considering differentiable operators from PyTorch. Internally, we have experimented with joint training of the video backbone and a variant of ActionFormer, and it works pretty well.

Thank for the replies!
@happyharrycn when you say "input preprocessing" do you mean this? https://github.com/happyharrycn/actionformer_release/blob/e559d1c4ba85ba24650067c6f6a9db605ae3ecb8/libs/modeling/meta_archs.py#L390
In this case, how can it be solved?

Yes, you will need to replace the logic in these lines with differential functions. A good option is torch.nn.functional.pad.

Mark as closed. Feel free to re-open if this is not resolved.


prompt

Did you use the clothing-related prompt, such as IDM-VTON?
'caption': 'model is wearing Long Sleeve V Neck Cardigan ', 'caption_cloth': 'a photo of Long Sleeve V Neck Cardigan '.

We use fixed prompts,
{ "model_prompt":"a human wearing a " + cloth_type + " clothing",
"cloth_prompt": "a photo of " + cloth_type + " clothing" }
cloth_type = upper / lower / dresses.


Querying Solr

Hello,
First off:
DBeaver Version:  4.3.0 CE
Desktop OS: Windows 7
Solr device driver:  Driver included with DBeaver
I finally established a connection with my Solr environment. I tried using port number 9983 and received zookeeper timeout messages. I changed the port number to 2181 (default clientPort number--got from the zoo.cfg file).
I'm trying to query my solr collection. I have tried (plus a few other combinations):
select?indent=on&q=:&wt=json
qt=select&indent=on&q=:&wt=json
I receive this message:
Query Execution failed
                Reason
                SQL Error: java.io.IOException: java.io.IOException: Slices not found for [collection]

What is the syntax for querying Solr? Are the query features/functions available on the Solr's Web UI available with DBearver?
Thank you for your help and time,
Richard

It works similarly to other Solr JDBC clients (e.g. https://lucene.apache.org/solr/guide/6_6/solr-jdbc-squirrel-sql.html#querying )


Question : what's the purpose of slicePeriodSeconds in struct VestingSchedule.

It is used to configure the size of the atomic period of the vesting. For example to be able to create a daily, monthly, ... schedule. If you set it to 1 the vesting will be linear second by second.


Scoped measurement keys from subcircuits

Is your feature request related to a use case or problem? Please describe.
As we scale our subcircuits solution to more levels, and as we add features like feed forward and flow control, we will need a structured way to manage the measurements coming from subcircuits.
Describe the solution you'd like
Would it be possible instead to allow CircuitOperation itself to have a key?
q1, q2 = cirq.LineQubit.range(2)
fc = FrozenCircuit(cirq.H(q1), cirq.measure(q1, key='m'))

c = cirq.Circuit(
  cirq.CircuitOperation(fc).on(q1).key('x'),
  cirq.CircuitOperation(fc).on(q2).key('y'),
)

assert str(c) == """\
q1 --CircuitOperation(fc).key('x')--

q2 --CircuitOperation(fc).key('y')--
"""

assert cirq.decompose(c) == [
  cirq.H(q1), cirq.measure(q1, key='x.m'),
  cirq.H(q2), cirq.measure(q2, key='y.m'),
]

Similarly, perhaps a repetitions circuit could key measurements so that they could be accessed by keys m[0] etc.
[optional] Describe alternatives/workarounds you've considered

We already do have key remapping. Key remapping may be sufficient.
We could use more of a language compiler syntax cirq.let("x", subcircuit), where there is a "Let" operation type. But keys feel more natural with our existing stuff.

[optional] Additional context (e.g. screenshots)
What is the urgency from your perspective for this issue? Is it blocking important work?

P2 - we should do it in the next couple of quarters (if accepted)

This sounds like a duplicate of #3663. Please find the related RFC at https://tinyurl.com/measurement-repeated-circuitop.

This sounds like a duplicate of #3663. Please find the related RFC at https://tinyurl.com/measurement-repeated-circuitop.

@smitsanghavi I don't have access to the RFC. Would love to what is in it. This seems like an important next step for cirq.

@smitsanghavi I don't have access to the RFC. Would love to what is in it. This seems like an important next step for cirq.

@smitsanghavi Got it. I think the above is more focused on hierarchies of subcircuits than repetitions, though I do mention repetitions at the end. Ultimately where I think we should go is if we have a
circuit with
  subcircuit key=a with
    subcircuit key=b repetitions=4 with
      subcircuit key=c with
        measurement key=a

it would be great if the four measurements were each referenceable by a.b[n].c.a for n=0..3. (Or from within the first subcircuit it's just b[n].c.a, and from within the second subcircuit it's just c.a etc.). Such that it's like a nested record in ordinary programming languages. There's no remapping and it reduces the burden on the users. Do you think that's doable?

@smitsanghavi Got it. I think the above is more focused on hierarchies of subcircuits than repetitions, though I do mention repetitions at the end. Ultimately where I think we should go is if we have a
circuit with
  subcircuit key=a with
    subcircuit key=b repetitions=4 with
      subcircuit key=c with
        measurement key=a

it would be great if the four measurements were each referenceable by a.b[n].c.a for n=0..3. (Or from within the first subcircuit it's just b[n].c.a, and from within the second subcircuit it's just c.a etc.). Such that it's like a nested record in ordinary programming languages. There's no remapping and it reduces the burden on the users. Do you think that's doable?

@smitsanghavi I wonder if we could implement the above in terms of your design. @95-martin-orion noted that this is already possible in the non-repeat case https://github.com/quantumlib/Cirq/pull/3495#issuecomment-770954210. I think the way you have the mapping being defined as a function, it could work in the repeat case too. It would map lambda(key, index: f'{key}[{index}].{base_key})' if repetitions > 1 else lambda(key: f'{key}.{base_key})'. I couldn't tell if support for something like that would be fully fleshed out in your design, but do you think that would that work?
The main thing is if we have a standard representation of things coming from subcircuits and repetitions, that gives us a nice way to be able to add things like slices and aggregators later when working with flow controls. e.g. with the above you could do something like conditionally apply a gate if all measurements are 1's: cirq.H(q1).c_if(cirq.classical.all('a.b[:].c.a'))

@daxfohl Have you joined the cirq-dev googlegroup? I'm able to view the RFC on both my work and personal accounts, so I believe it's visible to anyone in cirq-dev.
To my understanding, the key function defined in the linked comment is already compatible with Smit's repeated measurement behavior, although the final key will not have the format you specify. In the RFC, manual key renaming and loop-indexing of keys are applied separately, so no function is necessary.
(As an aside: I intentionally avoided using functions for measurement key mapping in creating CircuitOperation, as serialization is one of the key use cases of the class.)

Yes, I read the document, though the middle part that discusses Callable[[str], str] escaped me a bit. So it looks like the format of the above would end up as {n}-a.b.c.a, or for a more complicated circuit where b, d, and f have repeats, as `{b_index}-{d_index}-{f_index}-a.b.c.d.e.f.g'? From the examples, that's what it seems, but I'm not 100%.
Where I'm going with this is it would be nice if the indexes were adjacent to the subcircuit key they indexed, like a.b[i].c.d[j].e.f[k].g. That way if you had a subsequent mixed classical-quantum subcircuit, that worked with a shape of c.d[j].e.f[k].g measurements in all its c_if's (say it had a c_if_all('c.d[:].e.f[:].g')), you could create it with CircuitOperation(...).on(cirq.ClassicalGateTree('a.b[0]')) or something like that eventually. It would work just like passing structured data to a function in an ordinary language.

I agree that the Callable part of the RFC is a little confusing and not compatible with serialization. In the ongoing implementation, I am actually not doing that. The _decompose_ method will create a Dict for each measurement operation. For any nested CircuitOperation it will output a copy of the child CircuitOperation with prefixed repetition_ids.
That said, the design covers both repetitions and nested CircuitOperation hierarchy. I guess I haven't emphasized the latter part in the introduction section as much.
@daxfohl I'm using different separator than your suggestion (totally onboard with changing that if needed) but I think the actual output would be very similar to what you want above.
instead of a.b[i].c.d[j].e.f[k].g it will be a-{b[i]}-c-{d[j]}-e-{f[k]}-g where b[i] is the ith repetition_id for the CircuitOperation you have labelled b.
I think the key difference is that instead of assigning a single label to the subcircuit and aliasing all its repetitions to f{CircuitOperation.label}[{index}], we will provide the ability to give a unique name to each individual repetition of the CircuitOperation.

But I don't want to dismiss the above difference. Assigning a label the CircuitOperation instead of the individual repetitions would work and may be cleaner to read.
@95-martin-orion on whether having custom labels for each repetition is a feature users would appreciate.
Also, adding the discuss label in case anyone else wants to chime in.

I think the custom repetition id's are fine. And it's fine if we use a - instead of a dot to separate. We could still slice them the same way in what I'm imagining our classical gate logic will shape into: the above example would look like c_if_all('c-*-e-*-g').
The one thing I'd want to clarify is that given your above example, the following
circuit with
  subcircuit key=a with
    subcircuit key=b repetitions=['one', 'two'] with
      measurement key=m

it looks like you're saying we'd get keys a-one-m and a-two-m, and the b key gets ignored? I think the b should stay there, so it can be easily distinguished in
circuit with
  subcircuit key=a with
    subcircuit key=b1 repetitions=['one', 'two'] with
      measurement key=m
    subcircuit key=b2 repetitions=['one', 'two'] with
      measurement key=m

which would allow us to slice by a-b1-*-m or a-b2-*-m distinctly.

I don't see the benefit of having a key for CircuitOperation when each repetition of the CircuitOperation has an id (even when repetitions = 1). The above example can be represented in the current design as:
circuit with
  subcircuit repetition=['a'] with
    subcircuit repetitions=['b1-one', 'b1-two'] with
      measurement key=m
    subcircuit repetitions=['b2-one', 'b2-two'] with
      measurement key=m

I think if we want to add the concept of a key for CircuitOperation as a whole, it needs to replace repetition_ids in the above RFC. Else, we get stuck with redundant ways to identify an unfolded instance of the CircuitOperation. For e.g. when CircuitOperation.repetition == 1.
I think your proposal of having a key for every CircuitOperation and always auto-indexing the repetitions reads cleaner and I'd be okay with replacing repetition_ids with that*. But having two slightly different concepts of keys in CircuitOperation seems messier than either of the options.
*given custom repetition ids are not an important requirement.

So, where I'm picturing flow control going is creating almost a DSL for logic gates. So I'm imagining things through the perspective of what kind of DSL would be easiest to work with. The approach that I'm proposing here is, where subcircuits are equivalent to functions and keys are equivalent to the name you assign to their return values. So in the example above it would be equivalent to a DSL like
let circuit =
  let a =
    let b1 = { m : measure(q) }.repeat(2)
    let b2 = { m : measure(q) }.repeat(2)
    return { b1 : b1, b2 : b2 }
  return { a : a }

So at the end of the day, circuit contains an object of shape a.{b1,b2}[0..1].m. Here would be the equivalent when it's decomposed into subcircuits:
let subcircuit_measure(q) =
  { m : measure(q) }

let subcircuit_a(q) =
  { b1s : subcircuit_measure(q).repeat(2),
    b2s : subcircuit_measure(q).repeat(2) }

let circuit =
  let a = subcircuit_a(q)

This gives you a nice data structure that you can pass into other circuits that depend on it. It's like a regular programming language. So, equivalently in cirq you'd do like
def createMeasure(q) =
  return FrozenCircuit(measure(key=m))

def createSubcircuitA(q) =
  return FrozenCircuit(
    CircuitOperation(createMeasure(q), key=b1, repetitions=2),
    CircuitOperation(createMeasure(q), key=b2, repetitions=2),

def createCircuit(q) =
  a = createSubcircuitA(q)
  return Circuit(CircuitOperation(a), key=a)

So it gets closer to a DSL with structured return values that we'd be able to do things with in the future like aggregation, slicing, everything else you can do in a regular programming language.
With raw remapping, I see that more as a design where every measurement in the circuit is part of a flat list of a global variables. There's nothing you can't do with it but it will get messy to work with as the number of classic gates grows. Classic gates aren't a scarce resource, and for flow control, the number of classic gates will grow substantially because we'll need to do boolean operations on them, maybe eventually mathematical, and it will be hard to manage from a flat global namespace.
Maybe I'm thinking about it too hard. I'd also like to include @Strilanc since it looks like he's dabbled in the Q# repo a bit, which is a full-blown DSL.

@daxfohl, it's clear you have a mental model for what control flow ought to look like. It's less clear that this model expressly requires the keyed CircuitOperation behavior that you're suggesting, although I can see how consistent formatting would be useful. In order to keep things moving forward, here's what I recommend:

@smitsanghavi: Continue with your current design for repeated measurements as specified in your RFC. In my eyes, that work will not significantly complicate the change Dax is suggesting here, and we'll need it in either case.
@daxfohl: Take a look at the Cirq RFC process and document your plan for this issue as an RFC. RFCs are our primary method for capturing design feedback from the Cirq maintainers group; by documenting how this issue fits into the larger flow-control story, we (the maintainers) can better decide whether to go forward with the change.

Lastly: I'll set up a meeting for the three of us and @balopat to discuss partitioning of future classical data work. I think it's possible for us to work from both ends on this, but we need to be on the same page or we'll keep stepping on each other's toes.

Starting the RFC here: tinyurl.com/z8hmmx9o

Tuples will handle this.


Add support for HTTP proxy

This pull request adds support for tunneling librespot data through an HTTP proxy. It relies on the fact that most http proxies support CONNECT to hosts on port 443.
A CONNECT results in the proxy tunneling all incoming data as is and is commonly used for TLS connections.

I believe there is something wrong with the Travis builds. The console output seem to indicate PKG_CONFIG_ALLOW_CROSS=1 is not set when cross compiling. It has to be set or pkg-config will not work.

Indeed. I'm hesitant to merge this functionality though, as librespot doesn't use HTTPS anywhere (it only uses http to check apresolve.spotify.com), and hence openssl is not only a big dependency to include, but also entirely redundant in this case. I believe that librespot uses system proxy settings anyway?

This request would also need to update the travis.yml file accordingly to enable cross compilation, and require OpenSSL be installed on any system wishing to use it, which can be a PITA.

I didn't realize I had added openssl as a dependency! It must be the proxy library, I'll see if I can get rid of it.

Looking at the commit, I think you just added hyper-proxy, but that it includes support for TLS, which in turn depends on OpenSSL :/

I decided to skip trying to resolve an ap when using proxy and use the fallback directly. If and when there's a good library for making proxy requests that does not require SSL I'll revisit it.
I also think I've finally wrapped my head around futures and realized how I could move the proxy setup to it's own future. It's much nicer this way.
@sashahilton00 It seems something has happened with rustfmt so those tests fail pretty badly currently. Other than that it is green!

yeah something in rustfmt changed, you'll need to run cargo fmt --all with a nightly to fix it. Can we close this pull request for now given that there is no immediate solution?

What do you mean by close? I was hoping it could be merged since it solves the general case of running librespot behind a HTTP proxy. Using the fallback AP always for now should be fine I think.

Sorry, didn't realise you had rewritten the code to avoid using TLS, assumed that when you mentioned revisiting that you hadn't found a workaround. Before this can be merged, you'll need to run cargo fmt --all with rust nightly and push a commit to fix the formatting. Will test this once that's done.

Right, I wasn't very clear on that. It is passing now!

Since https://github.com/tafia/hyper-proxy/pull/3 was merged I was able to fix the resolving of APs as well. Also made sure the proxy is allowed to resolve the remote url instead of resolving it directly.
I had to update the lowest rust librespot requirement to 1.21.0 though as there were version conflicts and removing Cargo.lock resulted in dependencies that are not buildable on 1.20.0

The reason for it not working is that the proxy address needs to be in the form of a URL. Specifically only http://host:port is supported. I've updated the pull request with better validation of the input as well as changed from String to url::Url for proxies as it is a better representation.
There are other proxy types (https, socks4, socks5) so i think it is better to be strict about it from the start.
If you provide a proxy URL to somewhere that doesn't exist you are still going to end up with a "connection refused" but hopefully it is now more difficult to accidentally end up with invalid proxy URLs.
I'll update the wiki with info about proxies but the format is http://host:proxy and it uses --proxy or the http_proxy environment variable

Sorry it's taken a while, just tested and works fine with the format you mentioned. Not too worried about the port error, as proxy is a fairly edge user case. Merging.

Looks as if this change reverted many of the formatting changes applied a few weeks ago? IMHO that's not good, as it kills the history in git. It makes it really hard to find the actual code changes :-(.

@michaelherger Running cargo fmt --all on latest nigthly is a requirement for integration and they keep changing the behaviour. It is cargo fmt --all that caused this and I put it in a separate commit to make it easier to find the actual changes to the code.
I agree the formatting changes are messing up the history (difficult to run git blame for example) and I personally dislike automatic code formatters for this reason. However I also think rust is a difficult language to format nicely manually. I think the best thing we can do is to make sure the result of cargo fmt --all is put in separate commits for now and hope rustfmt stabilizes.
On the other hand it encourages people to mainline their changes to avoid difficult merge conflicts, so perhaps it isn't so bad after all!

Fair enough. I'd be happy to mainline my changes. But they're very specific - and often ugly and hackish, lack of better Rust/librespot understanding :-). I doubt any of it would be desirable in mainline :-).
The formatting discussion is something I've been fighting in various projects before... But if cargo fmt still is changing all the time, should we really apply it? Once it's stable, why not. But if that causes large chunks of the code base to change all the time, then it's really not any helpful at all.

Do you think it would be better to make this optional?  By adding the following to Cargo.toml you should be able to decrease the size substanially:
[profile.release]
panic = "abort"
lto = true
codegen-units = 1
incremental = false

Don't forget to strip the resulting binary with strip -s
If you still need to get the size down try out cargo bloat to find big offenders. Also since both hyper-proxy and librespot uses things like tokio-core, tokio-io, hyper and futures you should be able to decrease the size further by aligning the crate versions.

@Fulkerson  Yep, have already done the usual suspects to reduce size (-Zstrip-debuginfo-if-disabled=yes)
and after reading https://clap.rs/2018/01/09/new-years-weight-loss/ found cargo bloat and have been working towards aligning crates.  But in the end, it would be nice to break all these features into - features! ;-)


Add dev dependency badge

https://david-dm.org/

I can work on this.

@hiteshpr Great stuff! All yours! Thanks for offering to help 👍

@joshghent What exactly is needed here?

@hiteshpr Basically you need to follow the instructions on that website and add the dev dependencies badge to the Readme near the top


[BUG] Registration of newly uploaded AASes within registry not working for nginx setup

Describe the bug
I setup an basyx system, very similar to the BaSyxNGINX example https://github.com/eclipse-basyx/basyx-java-server-sdk/tree/main/examples/BaSyxNGINX, just without discovery service. When trying to upload a new AAS, the server respons with the error message 400. However, the AAS is uploaded into the AAS repository, visible only when browsing directly to it. Within the registry, there is no entry, and thus also nothing is visible in the UI. The same shell worked for an older setup of basyx just without the nginx component. Same behaviour occurs for standard shells like maximal.json.
To Reproduce
Steps to reproduce the behavior:

Go to UI
Try to upload an AAS

Expected behavior
The AAS should be registered within the registry and sb-registry components.
BaSyx (please complete the following information):

BaSyx Version  v2.0
BaSyx SDK Java
AAS Version  DotAAS V3

Screenshots

Used Asset Administration files (.aasx/.json/.xml)
Please drop your AAS files here that were used when the bug was encountered.
BaSyx configuration
Provide details about the configuration you used. If possible, attach the configuration as a .zip file.
System (please complete the following information):

OS: Linux on aws
CPU architecture:  x86
Browser firefox

Additional context
Add any other context about the problem here.

Hi @barthchristian,
I would assume that the problem lies in how the registry integration is configured.
Can you please share your .properties file for the AAS environment so that I can point you in the right direction?

Hi Aaron,
thanks for looking into this! Here is the aas-env.properties:
aas-env_properties.txt

Hi Aaron,
anything suspicious with the aas-env file?
I tried several modifications, without success so far. The error still holds.
Cheers,
Christian

I tried with
server.servlet.context-path = /aas-env/
and now it seems to work.

Hi Christian, sorry for the late response. Great to hear that you were able to solve the problem. Depending on the nginx config the trailing "/" is needed.


Using the bitboard representation for other AI

Hi Robert, I am writing my undergraduate math thesis on AI for 2048. So far, I have been using my own implementation of the board, but I want to try out more computationally intensive algorithms and would like to use your efficient bit representation of the board, along with the look-up table. I tried to implement it on my own in Python, but could get nowhere near your efficiency. I am unfamiliar with C and new to Github. I'm sorry if this is a trivial issue but I have spent dozens of hours on this already and found no easy answers.
How can I use your board implementation with different AI? What parts of the repository would I have to fork and what parts would I have to change? I have been trying to understand (only) 2048.py and use parts of that but could not get it to work. Am I ignoring some dependencies? If you could either explain your code a little bit more or tell me how to use your implementation with my own AI it would really save me a huge amount of time and effort. Thank you anyway!

2048.py depends on the C++ component (2048.cpp) to be built - please build it first according to the instructions (under Building). 2048.py itself is only a driver, and contains no significant game logic or AI logic. Pretty much all the interesting stuff in this repository is in 2048.cpp.

So if I have 2048.ccp and want to use it to test AI written in Python, what would I have to do?

I don’t understand what you’re asking. If you already have an AI in Python, what do you need the C++ AI for?


One-Click Import walk through example does not work

[Enter feedback here]
The quick start import example on this page does not work.
These values are not valid - no where on the page did I see that this was not a "working" quick start - all other quick starts I have executed provide working datasets and instructions to try something out.
https://docs.microsoft.com/en-us/azure/synapse-analytics/data-explorer/ingest-data/data-explorer-ingest-data-one-click#one-click-ingestion-wizard
Wanted to try this out using the quick start sample, guess not

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6b978fe4-faf9-4086-99b8-5073d5951615
Version Independent ID: 406eec68-93c5-8489-e5a8-a611e22cb7a8
Content: Quickstart: Get started ingesting data with One-click (Preview) - Azure Synapse Analytics
Content Source: articles/synapse-analytics/data-explorer/ingest-data/data-explorer-ingest-data-one-click.md
Service: synapse-analytics
Sub-service: data-explorer
GitHub Login: @shsagir
Microsoft Alias: shsagir

Thanks for the ask  . At this time we are reviewing the ask and we will reply back as soon as we can .

We have assigned the issue to the content author. They will further evaluate and update the document as appropriate.

@SQLAdventurer Thanks for your feedback. We've submitted a documentation change based on your suggestion, and the updated article should be live by tomorrow. Please let us know if there's anything more we can do for you. To follow up on this issue, leave us a comment with an @mention.
Apologies for the delay in responding.
#please-close


add config item smv_rebuild_tags

This new option enables faster builds for those that have a large number of tags and large documentation.
To enable add this to conf.py
smv_rebuild_tags = False
If this flag is False (defaults to True) then we skip any pre-existing target folders for tags. All branches are always rebuilt since they are subject to change.
Note that this means that historical documentation will have no forward links to future documentation. It is recommended that master is added to the branch whitelist so that this is always linked from all versions and will include links back to historical versions.

@Holzhaus It'd be great if you could review and merge or give feedback so it can get merged on this and the other outstanding PR's. I understand if you've got time limitations but maybe just let everyone know if you're ever going to merge anything or if we should start looking into other options.
Thanks!

For information, we have now moved away from this approach (and sphinx-multiversion in general) in favour of doing the version switching in javascript at runtime in a custom layout.html. An example of this is here: https://github.com/dls-controls/versiongit/blob/master/docs/_templates/layout.html

@Holzhaus: We are using this in two of our libraries, and it's indeed perfect for our needs. However, this project is now lacking maintenance. I understand that you might not have time to deal with this, so is it possible that you give other devs push access or pass the torch so this can be done?
I am now facing an issue with pip, as now dependencies on sphinx-multiversion need to be fixed to specific branches/repos rather than just pip install sphinx-multiversion.
I'll be more than happy to take care.

Came here to close this PR and realized there is recent interest. Unfortunately it does not look like this is going anywhere. For our own projects we have moved on as per Tom's comments above. For the latest on how we do multiple versions of python docs see https://github.com/DiamondLightSource/python-copier-template


Update project description in .cabal

The repository description and README are referring to Jupyter instead of IPython. Let's make them consistent.

Thanks!


Consume new code

The rest-example is now working.
There is still some bugs:

When you hit a bad password json.parse is failing.
When you login you will see the user info. If you refresh the page it looks like the tokens are deleted and you are not logged in anymore.

@TimMikeladze example is ready!

Thanks @pradel. The example looks good. Running into an issue in our work app: I updated the packages to the latest versions and modified the code to manually resume the session like in the example but am getting a Uncaught (in promise) Error: no tokens provided error. This could easily (and most likely) be something with the app and not the accounts package but I haven't investigated yet. Just a heads up.

@TimMikeladze Got the same in my app but didn't have the time to find why yet. I will try to find in the next days.

Here is the example for the redesign of the client.
It use react-router v4.


[InkBar] Remove style-propable mixin

:+1:

Fixed error where prepareStyles was still being called from mixin instead of context (comment)

Thanks a lot :+1: :+1:


DB Connector UI Updates

@chriddyp Please review.. It addresses most of the concerns from QA .. Will need another PR after this to cover 💯 ..

💃  - these look good to me, thanks!


Update README.md

Fix small grammar/spelling issues.

While we welcome even minor single line fixes made in good faith, this appears to be part of an airdrop farming campaign (see https://github.com/risc0/risc0/pull/1091 and https://github.com/risc0/risc0/pull/1092). Also, these changes are not an improvement. Closing.


Allow custom mappings

This makes it possible to disable the default mappings, for example:
let g:smoothie_use_default_mappings = v:false

nmap <C-j> <Plug>(SmoothieDownwards)
nmap <C-k> <Plug>(SmoothieUpwards)

Also, the commit adds so that existing mappings will not be overwritten by the plugin.

I've adjusted it slightly to use g:smoothie_no_default_mappings flag instead, which seems a bit more idiomatic to me. Thanks a lot, @segeljakt!


function members of primitives/builtins are not read-only

🔎 Search Terms
builtin number string member readonly
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about "Common Bugs that arent Bugs"

⏯ Playground Link
https://www.typescriptlang.org/play/?ts=5.5.4&ssl=6&ssc=1&pln=1&pc=1#code/DYUwLgBAHhC8ECYDcAoKA6AbgQ2AVxAHkAzOCACgQEotcCTUVRIBPMgIgAsRhgB7dqhboAxp2wAnAIKR4wsZJmogA
💻 Code
let x = 2;
x.valueOf = (2).valueOf;

let y = "hello";
y.charAt = y.charAt;

🙁 Actual behavior
Code compiles just fine, even with --strict enabled.
Executing JavaScript fails:
can't assign to property "valueOf" on 2: not an object

🙂 Expected behavior
Should be rejected by tsc as read-only assignment.
Additional information about the issue
Seems similar in nature to https://github.com/microsoft/TypeScript/issues/49113
Notably, array.length is allowed (because its legal in JS) but string.length is not (because it is illegal in JS). Since assigning to builtin functions is also illegal, this should be flagged by tsc.

What runtime are you using? This is valid in default DOM contexts. If you're using a custom environment that freezes these prototypes, you'd need to customize your lib appropriately

This happens both with node v20.16 and in the linked playground.

I am not aware of having changed any lib or using any custom environments...

Setting a property on a primitive is legal (but silently ignored) in sloppy contexts, and throws an error with "use strict"; or any implied strict context such as a module.

Ah, right. The type system doesn't have any notion of "valid in strict mode" vs not (we can only differentiate when this would be the case syntactically). Given that it's pretty hard to make this mistake unless you're intentionally trying to, I don't think we'd undertake the fairly invasive effort to change it unless there was a more compelling demonstration of how this comes up in practice.

Sounds fine to me. Do you happen to know if this behavior is documented anywhere? "frozen builtins" did not yield any results upon search


Remove preview decorator related methods

Use setPreview and getPreview instead

I revert the my whole original code.
With the way you suggested, we need to call setPreview multiple times.
With my code, we can't do that.

But we can check whether a custom preview is set before trying to set the default one. [example].


localStorage and changes to editor UI

LocalStorage:  Located in GameEditor/Controllers. Purpose is to save the state of the edited game across different pages. We want one object all throughout

@tomking Only changes to Objects were in slimming down the imports which is fine with me.


Update npm to 2.3.3

Hello!
Will you please update npm to the latest version? See #659 for instructions provided by @gabel.
Thanks so much.

Done.
Thanks for reminding me.


findTransactionSignature() not finding the transaction by the provided reference

Hey guys. I am testing solana pay to build a payment module based on it but I haven't been able to successfully finalize a payment based on the payment-flow-merchant example!
Steps that I follow:

Successful connection to devnet

Connection to cluster established: https://api.devnet.solana.com { 'feature-set':<PHONE_NUMBER>, 'solana-core': '1.9.9' }

Simulate Checkout using my test merchant wallet and generate the payment URL:

solana:GrH51Zbp6czGypTUe2gcU6B6eB9BjTERx7K6XYoXE9au?amount=0.01&reference=4ZQAj72fPDzy99UNWZdupTd5rKMeoXn7r1nguzT5hxKA&label=MORTIE-PAY&message=MORTIE-PAY%20-%20your%20order%20-%20%23001234&memo=JC%234098

I then convert the URL to QR code and scan it with my second test wallet made on Slope Wallet (Android) while the network is set to devnet. Transaction succeeds and gets fully confirmed. I can see the reference and the message added to the URL shown while approving the transaction on my wallet.
https://solscan.io/tx/5TukQF9AEYjf7oDdPxpP7Bc6nNezzcANt8ooa5ztT8t36S4yfX8opmsLJYwwwxS8aQhwSYXSjFFBzgHL4dEiYgiy?cluster=devnet
Now at this stage, findTransactionSignature() never finds the transaction using the randomly generated reference key. I can't actually see this transaction using the reference on Solscan as well.

Can you help me with this, please?
Should I find that reference key somewhere in the transaction description in Solescan?
Thank you!

Ah, this is an issue with Slope. Their wallet is not including the reference field in the transaction. I've reported this to them!

same problme here , using phantom wallet

Having the same issue with Phantom. Copy pasting the code from the "Merchant Integration", the txn goes thru just fine, but the await fintTransactionSignature just hangs indefinitely


Fine-tuning weights from retinanet_rn18fpn.pth...
Traceback (most recent call last):
  File "/opt/conda/bin/odtk", line 33, in <module>
    sys.exit(load_entry_point('odtk', 'console_scripts', 'odtk')())
  File "/workspace/odtk/odtk/main.py", line 244, in main
    model, state = load_model(args, verbose=True)
  File "/workspace/odtk/odtk/main.py", line 133, in load_model
    model.initialize(args.fine_tune)
  File "/workspace/odtk/odtk/model.py", line 94, in initialize
    self.load_state_dict(state_dict)
  File "/opt/conda/lib/python3.6/site-packages/torch/nn/modules/module.py", line 1054, in load_state_dict
    self.__class__.__name__, "\n\t".join(error_msgs)))
RuntimeError: Error(s) in loading state_dict for Model:
        size mismatch for box_head.8.weight: copying a param with shape torch.Size([36, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([48, 256, 3, 3]).
        size mismatch for box_head.8.bias: copying a param with shape torch.Size([36]) from checkpoint, the shape in current model is torch.Size([48]).

If I omit the fine-tuning and try training from scratch, there's no mismatch.
Is this caused by the outdated checkpoint? If so, any chance you could provide updated models?

I had changed the number of anchor ratios, so the resulting number of anchors, which affects the box_head, conflicted with the checkpoint. I added box_head.8.bias, box_head.8.weight to the ignored weights in initialize, so it's fine now.


robots is not properly applied

https://github.com/getgrav/grav-plugin-error/blame/develop/pages/error.md#L3
robots: noindex,nofollow

Does not work, and should be instead:
metadata:
    robots: noindex,nofollow

I found no reason why the first one should work, and it does not for me.
PR: https://github.com/getgrav/grav-plugin-error/pull/43

I also noticed this and came here to report it. However, I subsequently realised that no sane crawler is going to index a page returning a 404 status, so the whole property is unnecessary.

True, but I guess the fix won't hurt, will it?

That is also true and at least it will be correct, but as a "less code" guy I'd rather lose it :/

I'd keep it. Otherwise someone will want to add it again in 3 years. It is clear and it is correct (in the PR). However it is a nice to know information, maybe we could add a comment?

Otherwise someone will want to add it again in 3 years

Ha! Fair enough, let's merge this. Easily overridden anyway.


feat: improve resolver implementation and docs

I further improved the implementation by using our new getDotPath util. I've also changed the Valibot code in the README to use wildcard imports, as this is now the official recommended way to use Valibot because of the better DX (three shaking still works).

Thank you so much. Does tree shaking work because of the TypeScript compiler? Didn't know this.

In my investigations, yes, but feel free to take a look for yourself and give me feedback.

v0.31.0 is available: https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/


Import Aperio annotations (squares and circles)

We did the freehand annotation import wizard, but still need to add the square and circle import tool.

yep
its really important~


Updated Config.js as my requirement

What kind of pull requests is this?

I did it by mistake,sorry about that
On Sat, Jun 24, 2023, 4:16 AM Ghellab Abderrahmane @.***>
wrote:

What kind of pull requests is this?
—
Reply to this email directly, view it on GitHub
https://github.com/saiteja-madha/discord-js-bot/pull/357#issuecomment-1605079692,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AR4YRKGDKWHMYEGLEL5IUHLXMYMGDANCNFSM6AAAAAAYFALJXI
.
You are receiving this because you authored the thread.Message ID:
@.***>

I did it by mistake,sorry about that
…
On Sat, Jun 24, 2023, 4:16 AM Ghellab Abderrahmane @.> wrote: What kind of pull requests is this? — Reply to this email directly, view it on GitHub <#357 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4YRKGDKWHMYEGLEL5IUHLXMYMGDANCNFSM6AAAAAAYFALJXI . You are receiving this because you authored the thread.Message ID: @.>

No worries. Anyways I am closing this pull request


Automated cherry pick of #9076: Notify via contact skip receiver

Cherry pick of #9076 on release/3.6.
#9076: Notify via contact skip receiver

Codecov Report

Merging #9077 (245762a) into release/3.6 (b9d30c0) will increase coverage by 1.89%.
The diff coverage is 1.63%.

@@              Coverage Diff               @@
##           release/3.6   #9077      +/-   ##
==============================================
+ Coverage         5.86%   7.76%   +1.89%
==============================================
  Files              828     258     -570
  Lines           129133   33958   -95175
==============================================
- Hits              7577    2636    -4941
+ Misses          120876   31052   -89824
+ Partials           680     270     -410

Flag
Coverage Δ

aFlag
7.76% <1.63%> (+1.89%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/cloudcommon/db/apply_manager_method.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/db_dispatcher.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/modelbase.go
4.49% <0.00%> (-0.03%)
:arrow_down:

pkg/cloudcommon/db/models.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/virtualjointbase.go
0.00% <0.00%> (ø)

pkg/cloudprovider/objectstore.go
2.57% <ø> (ø)

pkg/cloudprovider/resources.go
0.00% <0.00%> (ø)

pkg/compute/regiondrivers/managedvirtual.go
0.00% <0.00%> (ø)

pkg/monitor/alerting/conditions/nodataquery.go
0.98% <0.00%> (-0.01%)
:arrow_down:

pkg/multicloud/esxi/vnic.go
0.00% <0.00%> (ø)

... and 553 more

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 c8d4a33...245762a. Read the comment docs.


[Feature Request] Reverse UniForm

Feature request
Which Delta project/connector is this regarding?

[x] Spark
[ ] Standalone
[ ] Flink
[ ] Kernel
[ ] Other (fill in here)

Overview
This issue asks for reverse UniForm for enhanced Interoperability.
Motivation
The existing Delta UniForm is one-direction as it enables read Delta as Iceberg; Thus this asks for the other direction to read Iceberg as Delta.
Willingness to contribute
The Delta Lake Community encourages new feature contributions. Would you or another member of your organization be willing to contribute an implementation of this feature?

[x] Yes. I can contribute this feature independently.
[x] Yes. I would be willing to contribute this feature with guidance from the Delta Lake community.
[ ] No. I cannot contribute this feature at this time.

@lzlfred how this would work? It would generate Delta Log on the fly?


Create osx-arm64 package

Comment:
mpire is not available for osx-arm64
Is there any technical reason?

Sorry for missing this issue. I don't think there would be a technical reason not to. I'll open the appropriate PR

Actually this is a noarch: python package so there's no need to have a specific osx-arm64 build.


docs: add note about how publicPath interacts with asset modules

This updates the documentation to better define how publicPath interacts with asset module types. Specifically, it is poorly documented on how to dynamically set the publicPath on the fly for these module types. This is important and useful in an enterprise environment where there may be different upstream CDNs or other locations that the app hosts assets on that aren't the server or a static site.

@Aghassi Lint is failing on CI, can you fix?

Yup let me do that

Is there a good way to understand the Typeerror from CI that Cypress is throwing? The stack trace is pretty sparse.

Weird, we need to check it
@snitin315 Can you look why our tests are failed?

Fixed, it was because of the incorrect heading levels.


BasicShields-1.2.0-1.18 Fabric, Gold shield recipe not working

I think the recipe might be looking for "gold_ingots" instead of "gold_ingot"?
"Failed to parse recipe 'basicshields:golden_shield[minecraft:crafting_shaped]'! Falling back to vanilla: com.google.gson.JsonSyntaxException: Unknown item tag 'c:gold_ingots'"

It's because I was trying to make it accept the c:gold_ingots tag instead of hardcoding the item it uses. I guess I forgot to actually initialize the tag.

I'll have a bugfix update out soon

Update 1.2.1 will contain this fix

For now you can download the file from the releases tab in this github or at https://modrinth.com/mod/basic-shields-fabric. Because I'm having some issues with curseforge for some reason.


The compressed onnx model can't run inference.

When checking the compressed model accuracy in tutorial 01, the error is as follow:

InvalidArgument                           Traceback (most recent call last)
Cell In[5], line 7
      2 testloader = torch.utils.data.DataLoader(testset, batch_size=1, shuffle=False, num_workers=4)
      4 # acc1_full, acc5_full = check_accuracy(model, testloader)
      5 # print("Full model: Acc 1: {acc1}, Acc 5: {acc5}".format(acc1=acc1_full, acc5=acc5_full))
----> 7 acc1_compressed, acc5_compressed = check_accuracy_onnx("ResNet_compressed.onnx", testloader)
      8 print("Compressed model: Acc 1: {acc1}, Acc 5: {acc5}".format(acc1=acc1_compressed, acc5=acc5_compressed))

File [e:\github\only_train_once\tutorials\utils\utils.py:57](file:///E:/github/only_train_once/tutorials/utils/utils.py:57), in check_accuracy_onnx(model_path, testloader, two_input)
     54 total = 0
     56 for X, y in testloader:
---> 57     outputs = ort_sess.run(None, {'input.1': X.numpy()})[0]
     58     prec1, prec5 = accuracy_topk(torch.tensor(outputs), y.data, topk=(1, 5))
     59     correct1 += prec1.item()

File [~\AppData\Roaming\Python\Python38\site-packages\onnxruntime\capi\onnxruntime_inference_collection.py:200](https://file+.vscode-resource.vscode-cdn.net/e%3A/github/only_train_once/tutorials/~/AppData/Roaming/Python/Python38/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py:200), in Session.run(self, output_names, input_feed, run_options)
    198     output_names = [output.name for output in self._outputs_meta]
    199 try:
--> 200     return self._sess.run(output_names, input_feed, run_options)
    201 except C.EPFail as err:
    202     if self._enable_fallback:

InvalidArgument: [ONNXRuntimeError] : 2 : INVALID_ARGUMENT : Non-zero status code returned while running Gemm node. Name:'Gemm_47' Status Message: GEMM: Dimension mismatch, W: {10,15} K: 512 N:10

ResNet_full_group_sparse model is OK!

Thanks for the question @rotorliu
Could you please share your torch, onnx and torch version?
Since I do not reproduce such issue on my environments, here are the normal full and compressed models should look like. You could find the checkpoints.

Python 3.8.13
torch 1.10.2
onnx 1.14.0

Yes，My compressed onnx is only different from the full model at the end of model (Gemm node). So I think the result is wrong.

Thanks for sharing your configs @rotorliu . Will test it out next week, if such configs does not work on my end either, I will update the requirements file and proceed a fix.
Here are my package list.
torch 1.13.1
onnx 1.12.0
I tested is out from torch 1.9-2.0 thereby 1.10 should be fine.  My gut feeling is that the latest onnx 1.14 may be the root cause since the names of Gemm layer are different. Yours is Gemm_47, mine is /fc/Gemm, which might cause trouble during assigning tensors. If so, I will need to proceed a fix.


 iter_copied error

I got following compile error:
[170/1118]   Compiling toml v0.5.4
error[E0658]: use of unstable library feature 'iter_copied' (see issue #57127)
   --> /home/dvogt/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-0.5.4/src/de.rs:435:30
    |
435 |                             .copied()
    |                              ^^^^^^

error[E0658]: use of unstable library feature 'iter_copied' (see issue #57127)
   --> /home/dvogt/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-0.5.4/src/de.rs:575:22
    |
575 |                     .copied()
    |                      ^^^^^^

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0658`.
error: Could not compile `toml`.

Actually i switch to the 0.4 version.
My version:
stable-x86_64-unknown-linux-gnu (default)
rustc 1.35.0 (3c235d560 2019-05-20)

rustc 1.35.0 (3c235d560 2019-05-20)

I think the oldest version of rustc that works is 1.36.  Can you update to a newer version?

With a newer version of rustc it works. Thanks. Also to @dunnock


Should opt for immutability where we can

Currently all objects in the SDK are mutable. If a new event or object is needed, it should be recreated, instead of using setters to set things.
https://github.com/cdevents/sdk-java/blob/5d17b750fda57fd4a9d7ad2c5baec2bb4b9e2143/sdk/src/main/java/dev/cdevents/models/build/started/Subject.java#L113-L115
Instead we should utilize the builder pattern, imo. Look at lombok, https://projectlombok.org/features/Builder. This will make it a lot easier to generate these and make them properly immutable

Duplicate of #66


[AIRFLOW-2429] Fix api, bin, config_templates folders flake8 error

Make sure you have checked all steps below.
JIRA

[x] My PR addresses the following Airflow JIRA issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-2429
In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a JIRA issue.

Description

[x] Here are some details about my PR, including screenshots of any UI changes:
Fix api/, bin/, config_templates/ folders flake8 errors

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[x] In case of new functionality, my PR adds documentation that describes how to use it.

When adding new operators/hooks/sensors, the autoclass documentation generation needs to be added.

Code Quality

[x] Passes git diff upstream/master -u -- "*.py" | flake8 --diff

Codecov Report

Merging #3391 into master will decrease coverage by <.01%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master    #3391      +/-   ##
==========================================
- Coverage   76.49%   76.49%   -0.01%
==========================================
  Files         203      203
  Lines       15019    15015       -4
==========================================
- Hits        11489    11485       -4
  Misses       3530     3530

Impacted Files
Coverage Δ

airflow/api/__init__.py
72.22% <ø> (ø)
:arrow_up:

airflow/api/common/experimental/get_task.py
100% <ø> (ø)
:arrow_up:

airflow/api/client/local_client.py
100% <ø> (ø)
:arrow_up:

airflow/api/common/experimental/delete_dag.py
85.18% <ø> (ø)
:arrow_up:

...rflow/api/common/experimental/get_task_instance.py
90% <ø> (ø)
:arrow_up:

airflow/api/auth/backend/deny_all.py
0% <ø> (ø)
:arrow_up:

airflow/api/client/json_client.py
0% <ø> (ø)
:arrow_up:

airflow/api/auth/backend/default.py
100% <ø> (ø)
:arrow_up:

airflow/config_templates/airflow_local_settings.py
83.33% <ø> (ø)
:arrow_up:

airflow/api/common/experimental/pool.py
100% <ø> (ø)
:arrow_up:

... and 6 more

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 dc78b91...5da71fc. Read the comment docs.

LGTM

@feng-tao I have resolved flake8 issues for contrib folder in https://github.com/apache/incubator-airflow/pull/3394. Can you please start with the other folders when you get time?

hey @kaxil , thanks a lot:) I will look into other folders and fix the issues.

Awesome!


Invalid syntax in Ditto.swift

When doing a pull, for localized strings using multiple custom parameters, the generated syntax is invalid.
In the following example you can see that too many commas are being added in the signature and body of the function, creating invalid syntax. The last two parameters in the localizedStringWithFormat(:_, ...) seems to be concatenated, which also is wrong.
Expected result:
public static func infoDescription(_ localeOverride: String? = nil, userFullName: String, userAddress: String, deliveryDatePostalCode: String, deliveryDatePostalPlace: String, recipientName: String = "Mottaker") -> String {
			  String.localizedStringWithFormat(NSLocalizedString("infoDescription", tableName: "app", bundle: getBundle(localeOverride), comment: ""), userFullName, userAddress, deliveryDatePostalCode, deliveryDatePostalPlace, recipientName)
		}

Actual result:
public static func infoDescription(_ localeOverride: String? = nil, userFullName: String, , userAddress: String, , deliveryDatePostalCode: String, , deliveryDatePostalPlace: String, , recipientName: String = "Mottaker") -> String {
			  String.localizedStringWithFormat(NSLocalizedString("infoDescription", tableName: "app", bundle: getBundle(localeOverride), comment: ""), userFullName, userAddress, deliveryDatePostalCode, deliveryDatePostalPlacerecipientName, )
		}

Config.yml
status: FINAL
sources:
  components: true
  projects:
    - id: [REDACTED]
      name: app
variants: true
format:
    - ios-strings
    - ios-stringsdict
iosLocales:
    - base: nb
    - danish: da
    - english: en
    - svenska: sv

Thanks for surfacing @OlafAndreas! I'll take a look into fixing this today.

Hi @OlafAndreas! Just released a few fixes to the generator of the Ditto.swift file, can you try regenerating the file and see if it fixes your issue? Thanks!

It's looking better, almost there!
Following is the result of the latest pull, notice the last comma in the call to String.localizedStringWithFormat(...) is added after recipientName when it should be added in between deliveryDatePostalPlace and recipientName.
public static func infoDescription(_ localeOverride: String? = nil, userFullName: String, userAddress: String, deliveryDatePostalCode: String, deliveryDatePostalPlace: String, recipientName: String = "Mottaker") -> String {
    String.localizedStringWithFormat(NSLocalizedString("infoDescription", tableName: "app", bundle: getBundle(localeOverride), comment: ""), userFullName, userAddress, deliveryDatePostalCode, deliveryDatePostalPlacerecipientName, )
}

Not sure if it's helpful but here's the generated localized string format: "%1$@\n%2$@\n%3$@, %4$@"
And here's a snapshot of the variables in our project:

Thank you so much for the additional context! I'll make sure to take another look tomorrow morning, looks like it's an ordering issue on our end with variables.

@OlafAndreas I just pushed a fix for this issue! Can you try generating the Ditto.swift file once more?

Great success, works like a charm now! 🙏
Here's a digital trophy from me to you 🏆


Move Context into Noir interfaces initialiser

Today, the autogenerated Noir interfaces take a private or public context on every call as their first parameter. We can take a page out of the refactor that @benesjan did for storage in #1926, and do the same for interfaces.
So instead of doing:
let token = Token::at(address);
token.transfer(&mut context, to, amount);

We'd be doing:
let token = Token::at(address, Context::private(&mut context));
token.transfer(to, amount);

Note that we should wait until https://github.com/AztecProtocol/aztec-packages/issues/2074 is implemented before moving forward though.
Also, note that Context::private(&mut context) can probably be autogenerated by a macro.

Great suggestion!

let token = Token::at(address, Context::private(&mut context));

Can we instead do:
let token = Token::at(address, &mut context);?

Definitely. I forgot I had split the interfaces into public and private, and each of them takes a public context or private context respectively, so there's no need to use the Context union from #2074.


Bug: Fetch traces only capture the hostname of the request URL

Expected Behavior
The request URL captured by the trace of a Fetch request should be the URL of the request.
Current Behavior
The request URL captured by the trace of a Fetch request is only the requested hostname.
Code snippet
await fetch("https://aws.amazon.com/free?test=1");

Steps to Reproduce

Set AWS_XRAY_DEBUG_MODE environment variable to true of an instrumented Lambda function.
Perform requests using fetch and node:https

await fetch("https://aws.amazon.com/free?test=1");
await axios.get("https://aws.amazon.com/free?test=1");

Compare output of subsegments.

fetch emits incorrect request URL:
        {
          "id": "45b22f447784c44f",
          "name": "aws.amazon.com",
          "start_time":<PHONE_NUMBER>.18,
          "namespace": "remote",
          "http": {
            "request": {
              "url": "aws.amazon.com",
              "method": "GET"
            },
            "response": {
              "status": 301,
              "content_length": 0
            }
          },
          "end_time":<PHONE_NUMBER>.849
        }

node:https emits correct request URL:
        {
          "id": "e861c05fa31a14ab",
          "name": "aws.amazon.com",
          "start_time":<PHONE_NUMBER>.856,
          "namespace": "remote",
          "http": {
            "request": {
              "url": "https://aws.amazon.com/free",
              "method": "GET"
            },
            "response": {
              "status": 301,
              "content_length": 0
            }
          },
          "end_time":<PHONE_NUMBER>.218
        }

Possible Solution
Modify the onRequestStart function of the Tracer's ProviderService to generate a URL rather than use the hostname.
For example, modify to the following:
  const origin = getOriginURL(request.origin + request.path);
...
  (subsegment as HttpSubsegment).http = {
    request: {
      url: `${origin.protocol}//${origin.hostname}${origin.pathname}`,
      method,
    },
  };
...

Powertools for AWS Lambda (TypeScript) version
2.7.0
AWS Lambda function runtime
20.x
Packaging format used
npm
Execution logs
No response

Hi @gruntster, thank you for taking the time to report the issue.
I looked into it and I am able to reproduce the behavior you described. When making requests with fetch, the trace data is indeed missing the path/pathname.
I'll be working on a fix before this week's release.


Move state_machine into separate package

It doesn't have any dependencies on WLib and can live separately.

I will do this today


Force over multiple contact points at rest.

In the real world if you have a table with 4 legs, the foot of each leg transfers 1/4 of the weight of the table to the ground. If the table had 8 legs of the same size, each would transfer 1/8th etc.
Is it possible to see this kind of force distribution in cannon? If I model a table and inspect the contact points at each leg, is it possible to tell how much force is applied at those contacts when the table is not moving?
Sorry if this is a dumb / obvious question.

Interesting question. Not sure if it's possible, but hopefully yes.
If you loop over all ContactEquations in the world, you can use their multiplier property to get the applied force. Maybe you have to multiply the value with the time step, dont remember. Read more here: https://github.com/schteppe/cannon.js/issues/229
Then you just need to filter away the ones you aren't interested in.
Can be good to know that a shape may have more contact points than you expect. A cube on a plane will have 4 contact points as it is implemented now.


Google Books API Tool

Discussed in https://github.com/langchain-ai/langchain/discussions/26977

Originally posted by S-Makrod September 29, 2024
Checked

[X] I searched existing ideas and did not find a similar one
[X] I added a very descriptive title
[X] I've clearly described the feature request and motivation for it

Feature request
We would like to add a tool that integrates with the Google Books API that can be found at https://developers.google.com/books/docs/overview. This would allow agents to interact with information contained in the Google Books API.
The tool would take a query from an agent, gather the relevant information from Google Books, format the information into a readable output, and return the result to the agent.
Here is some sample usage and output to get a better idea of what we would like to add:
Sample Usage
from langchain_community.tools import GoogleBooksQueryRun
from langchain_community.utilities import GoogleBooksAPIWrapper

api_wrapper = GoogleBooksAPIWrapper()
tool = GoogleBooksQueryRun(api_wrapper=api_wrapper)

tool.run({'query': 'artificial intelligence'})

Sample Output
Here are a few books related to artificial intelligence:

1. "Introduction to Artificial Intelligence" by Simplilearn: This AI beginner's guide aims to take the readers through the current AI landscape, provides the key fundamentals and terminologies of AI, and offers practical guidelines on why and how you can be a part of the AI revolution, and also the ways in which you can scale up your AI career.

2. "Artificial Intelligence in Society" by OECD: Artificial Intelligence in SocietyThe artificial intelligence (AI) landscape has evolved significantly from 1950 when Alan Turing first posed the question of whether machines can think. Today, AI is transforming societies and economies. It promises to generate productivity gains, improve well-being and help address global challenges, such as climate change, resource scarcity and health crises.

3. "What Was Artificial Intelligence?" by Sue Curry Jansen: What Was Artificial Intelligence?When it was originally published in 2002, Sue Curry Jansen's "What Was Artificial Intelligence?" attracted little notice. The long essay was published as a chapter in Jansen's Critical Communication Theory, a book whose wisdom and erudition failed to register across the many fields it addressed. One explanation for the neglect, ironic and telling, is that Jansen's sheer scope as an intellectual had few competent readers in the communication studies discipline into which she published the book. "What Was Artificial Intelligence?" was buried treasure. In this mediastudies.press edition, Jansen's prescient autopsy of AI self-selling—the rhetoric of the masculinist sublime—is reprinted with a new introduction. Now an open access book, "What Was Artificial Intelligence?" is a message in a bottle, addressed to Musk, Bezos, and the latest generation of AI myth-makers.

Motivation
Looking at current integrations, we have noticed that there are many GSuite integrations, so this would expand on the current collection. Moreover, currently there are reading material integrations like PubMed and Google Scholar; however, these sources are purely for academic papers. It looks like there is room to add a tool that can return reading material of all types based on agent queries.
Overall, Google Books is the largest API in the world that keeps track of books in a curated manner. It has over 40 million entries, so this will give agents a significant amount of data to work with when generating resources for a user.
Proposal (If applicable)
We (a group of 4) are planning to make an addition to the tools contained in libs/community/langchain_community/tools and follow a similar structure to the existing tools. If this idea is approved, we hope to submit a PR by early November.
Here is an outline of the changes we are anticipating to make:
Modifications to existing files
We plan to modify the following files:

libs/community/langchain_community/agent_toolkits/load_tools.py to register our tool
libs/community/langchain_community/tools/__init__.py to register the tool
libs/langchain/langchain/tools/__init__.py to register the tool

New files
We plan to create the following files:

libs/community/langchain_community/tools/google_books where we will define the class GoogleBooksQueryRun which inherits from BaseTool
libs/community/langchain_community/utilities/google_books which we will define the class GoogleBooksAPIWrapper that inherits from BaseModel
libs/community/tests/integration_tests/utilities/test_google_books.py where we will define test cases to test our tool

Some Sample Code
class GoogleBooksQueryRun(BaseTool):
    """Tool that searches the Google Books API."""

    name: str = "GoogleBooks"
    description: str = (
        "A wrapper around Google Books. "
    )
    api_wrapper: GoogleBooksApiWrapper

    def _run(
        self,
        query: str,
        run_manager: Optional[CallbackManagerForToolRun] = None,
    ) -> str:
        """Use the Google Books tool."""
        return self.api_wrapper.run(query)

class GoogleBooksAPIWrapper(BaseModel):
    google_books_api_key: Optional[str] = None

    model_config = ConfigDict(
        extra="forbid",
    )

    @root_validator()
    def validate_environment(cls, values: Dict) -> Dict:
        """Validate that api key exists in environment."""
        google_books_api_key = get_from_dict_or_env(
          values, "google_books_api_key", "GOOGLE_BOOKS_API_KEY"
        )
        values["google_books_api_key"] = google_books_api_key

        return values

    def run(self, query: str) -> str:
        # build Url based on API key and query
        request_url = ...

        # send request
        response = requests.get(request_url)

        # some error handeling
        if response.status_code != 200:
            return response.text

        # send back data (format style tbd)
        return self.format(query, response)
```</div>

@efriis Just created a PR, please have a look for this tool.

@efriis, as discussed earlier we have opened up a PR for this tool. Please let us know what you think when you get a chance and thanks again for elevating our discussion to an issue!
@keenborder786 my group and I were actually working on this earlier since we proposed the initial discussion and sample implementation. The issue is tagged utoronto as we are students from the University of Toronto and we had the intention of us submitting a PR for it as soon as possible


[iOS] on('notification') event does not trigger when app is foreground with screen locked

Expected Behaviour
.on('notification') should trigger when opening notification
Actual Behaviour
it does not trigger when opening notification from lockscreen and app is foreground
Reproduce Scenario (including but not limited to)
Steps to Reproduce

Open app
Lock screen
receive and open a push notification from lockscreen

Platform and Version (eg. Android 5.0 or iOS 9.2.1)
iOS 13.3.1
Cordova CLI version and cordova platform version
cordova 9.0.0
cordova ios 5.0.1
Plugin version
2.3.0
Sample Push Data Payload
any

To add to this, I am only seeing this behaviour when I have a passcode or fingerprint set on the device, and once that step is completed the app will be open but the .on('notification') handler is not called. Interestingly if I don't have passcode or fingerprint set then the app opens as expected and handler is called.
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
iOS 13.3.1
Cordova CLI version and cordova platform version
cordova 9.0.0
cordova ios 5.1.1
Plugin version
2.3.0

I should also add that the handler is called correctly with or without security if the app is in a forced closed state when the notification is tapped.

My bug happens when app is foreground behind the lock screen. Can't be closed at the same time.
Does yours happen when app is not force closed but not foreground ?

@roxteddy Yes that's when I was experiencing the issue.
I've actually moved over to https://github.com/dpa99c/cordova-plugin-firebasex which does not have the issue, is updated regularly and in my opinion has a more intuitive API and much clearer documentation, so I'd recommend making the switch to that if you can.

@alexstanbury yeah but that plugin is GIGANTIC! When I migrated it takes like 10 minutes to build on iOS. I had to dump it from all the dependencies and size and warnings during build.
I actually really like interfacing with this plugin (phongap-plugin-push) but I can't get it to work at all on iOS - a different topic/issue.


More up-to-date PyTorch?

Thanks for publishing this competition. It looks great.
Any chance we could get a requirements file with a more up-to-date version of PyTorch? We're currently on 1.13, and unfortunately version 1.8 doesn't play well with the CUDA/GPU configurations for the majority of the machines I have available to me.
I've spent a few hours fighting with things and if I figure out a configuration that works I'll close send a PR but if you happen to have one available it'd be much appreciated.

Thanks for your interest, Nicholas!
The reason why we require PyTorch 1.8 is that it is the latest version officially compatible with torchcsprng. There are open issues in https://github.com/pytorch/opacus/issues/504 and https://github.com/pytorch/csprng/issues/130 that address this.
That said, torchcsprng builds fine from source with PyTorch 1.13.0 (e.g., with pip install git+https://github.com/pytorch/csprng.git@7820f5ddf258cd06c2487caa53a6695daa0ee644'). When running some limited tests, I didn't run into any issues and the behaviour seems consistent with what I get with PyTorch 1.8.1. However, this isn't the environment we used to create or test the competition, so I can't say whether it will work fine in all cases.
We need torchcsprng to train models with Opacus in secure mode, which uses a cryptographically secure PRNG for noise addition and batch sampling. This incidentally patches Gaussian noise sampling against some floating-point representation attacks (https://arxiv.org/abs/2107.10138). Presumably, you could train additional models with Opacus without setting secure mode which for most practical matters won't differ from the models that we provide. This won't require torchcsprng and will allow you to use a more recent version of PyTorch that plays well with your configuration.
Unfortunately, we also took a dependency on torchcsprng.create_mt19937_generator to recreate data splits from seeds. To overcome this, you could use torchcsprng just to recreate the data splits, store them, and then load them in a different environment without torchcsprng. (I just made importing torchcsprng conditional to allow one to do this).
For loading and running the models in forward mode you won't need torchcsprng and I believe that there won't be any difference using a more up-to-date version of PyTorch, such as the latest stable 1.13.

To be more concise, according to [1], [2] and [3], the following combination of versions are the most up-to-date versions of pytorch, csprng, opacus for GPU that work flawlessly are:

opacus==1.1.3
torchcsprng==0.2.0+cu111
torch==1.8.0+cu111

It took me some time to find the correct configuration: Could you had this to the repo, so that other people do not need to waste their time?
[1] csprng repo
[2] opacus releases
[3] pytorch

Thanks for digging into this @xehartnort!
For the record, these are the requirements we recommend:

opacus==1.1.3
torchcsprng==0.2.1
torch==1.8.1

This is the configuration we used. We tested that it works well in a clean environment. What problem did you encounter when trying it?
Despite what the torchcsprng repository says, the latest version of torchcsprng available from PyPI (0.2.1) works fine with torch 1.8.1. Note that this is also the version Opacus maintainers recommended in the issue where you cross-posted your message.
We wouldn't want to prescribe a specific version of the CUDA toolkit or even the use of CUDA at all since GPU acceleration is not required. There are several versions that would work with torch 1.8.1 and many pre-compiled binaries available (https://anaconda.org/pytorch/pytorch/files?version=1.8.1).


This is a bug

I really love your work!!! :D congrats!
if using nested header and after you delete one column, it let twice columns.

The nested headers has been implemented. This works better now... ;)


Prohibit starting of postmaster with EXECUTE role.

Prohibit starting of postmaster with EXECUTE role.
Normally segment node is started in utility role and execute role is used only
when backend process is started. However if one tries to start segment directly
in the execute mode using pg_ctl, this leads to SIGSEGV in the postgres process.
It happens because pointer to shared memory flag shmCleanupBackends is left
uninitialized. This pointer initialized in the function tmShmemInit() only for
GP_ROLE_DISPATCH and GP_ROLE_UTILITY and the flag itself is meaningful only for
GP_ROLE_DISPATCH.
This patch prohibits start of the postmaster in execute mode and raises error in
this case. To ensure that flag shmCleanupBackends is initialized correctly an
assert was added.
Also this patch adds one more condition where shmCleanupBackends set taken from
the 7.x.
This scenario assumes unexpected startup procedure and quite specific use case
not falling into regular regression tests. Automated testing of this case would
require quite complicated TAP test and does not bring any value to normal use
cases. Considering this, it seems not feasible to make a specific automated test
for this scenario.

Allure report https://allure.adsw.io/launch/81914

What does it mean to run postmaster (if I understood correctly) with the execute role? Is there any point in supporting this?

What does it mean to run postmaster (if I understood correctly) with the execute role? Is there any point in supporting this?

If we try to start it with pg_ctl  with f.e. -o "gp_role=execute", this will try to set gp_role to execute at postmaster startup. This is normal for adb 7.x, but makes no sense for 6.x.
Execute role (QE) is normal operation mode for the backend on the segments and set only when user session starts. What do you mean by supporting this?

What do you mean by supporting this?

I mean, what kind of user case is there for this? Might it be worth adding a check and fail with an meaningful error if postmaster is started with this role?

It seems to me that it is worth prohibiting the start of postmaster with the execute role, since this does not make practical sense and if for some reason it is started with this role, then this is clearly an error.

Allure report https://allure.adsw.io/launch/82221

It seems to me that it is worth prohibiting the start of postmaster with the execute role, since this does not make practical sense and if for some reason it is started with this role, then this is clearly an error.

Although it seems good idea for me as well, it's not very practical to do it. Here we don't start the it in the specific mode. Instead it just started normally and pass a set of options to it, one of it (okay, may be the one we pass), by coincidence is gp_role mode.
When postgres process starts it applies a set of options from defaults, from configuration file, command line, and some of that option combinations might be invalid, incorrect or differ from the user's expectations. AFAIK the is no and it's extremely difficult to check all options combinations for correctness, this is left for the user - most likely developer or DBA in this case.
Also, the user don't start pg_ctl directly in case of GP/ADB, instead he using scripts which already contain correct options set. And, I am not completely sure that starting with gp_role=execute has no practical usage.
So, I believe checking for gp_role=execute at start is not feasible.

However if we know that one of the options is incorrect, then it is worth informing the user about it as early as possible. Moreover, in this state, we cannot even take a lock on the table.

Allure report https://allure.adsw.io/launch/82607

However if we know that one of the options is incorrect, then it is worth informing the user about it as early as possible. Moreover, in this state, we cannot even take a lock on the table.

Okay

Allure report https://allure.adsw.io/launch/82618

Allure report https://allure.adsw.io/launch/82874

Allure report https://allure.adsw.io/launch/82880

Allure report https://allure.adsw.io/launch/83097

Allure report https://allure.adsw.io/launch/83120

Allure report https://allure.adsw.io/launch/83509


rewrite installation page

In reference to this issue https://github.com/packwiz/packwiz-website/issues/32
I completely rewrote the installation page to include more detailed instructions and clarified how to navigate the Github Actions page, including screenshots to better assist with these steps. I have also included information for adding files to the PATH for those that are unaware of how to do so.

Images weren't rendering in the preview, so I removed them and simplified it to just be a step-by-step for the Github Actions section.


How to use my own dataset for trainer?

I referred to this document:
[PyABSA]/[examples-v2]/[aspect_polarity_classification]/aspect_polarity_classification)/Aspect_Sentiment_Cassification.ipynb
and tried to pass my own dataset to PyABSA trainers, but I can't use this code:
my_dataset = DatasetItem("my_dataset", ["my_dataset1", "my_dataset2"])
I wrote this for my data:
my_dataset = DatasetItem("131.Electronics", ["131.Electronics"])
and the error shows that it cannot find dataset: 131.Electronics
What should I do to use my own dataset to train the model? Thanks!

Your datasets should be located in the integrated_datasets/{apc|atepc}_datasets/131.Electronics. If it fails again, you can paste your code here, I will help you.

I've solve this issue. Thank you so much!

I've solve this issue. Thank you so much!


Add "Name" in FontConfig

I suggest adding each font its name.
This is done so that in one folder "fontconfigs" (example) you could store the settings for several fonts at once. When loading and saving, you will need to specify the font name in FontConfig

Thanks!

@Dumkin I don't know how you are editing your code, but I assume that there is probably a way to set up a gofmt call when you are saving your file.  That is what I do in neovim.

@4ydx I'm sorry, habit. On account of gofmt many thanks, I'm new to golang, did not know this feature, I'll definitely install


Allow to use additional mirrors for Zenodo.

During an Hackathon, I observed for the first time continued 500 response codes from Zenodo, this is resolved in the meantime, but the goal of this ticket is to allow for mirrors in case of such short-term outages.

The problem is resolved via the commits above


setup test.pypi.org for testing

Install required packages - https://packaging.python.org/tutorials/installing-packages/
version naming for dev release to test.pypi.org
https://github.com/apache/airflow/blob/429584525fd7037215c5b6019aa7d643f2d7cb1a/setup.py#L130-L163
https://packaging.python.org/specifications/core-metadata/

Now the development environment is setup. And could push the artifacts to test.pypi.org
Add scripts to do these steps automatically!


Unable to parse Juniper firewall logs ingested via SC4S server

IHAC facing an issue while parsing Juniper firewall logs ingested via the SC4S server
Splunk TA juniper: 1.5.5-rfb1b492
Splunk Cloud Version: 9.0.2208.1
Customer Description:
“We have integrated Juniper Firewall logs by using syslog port 514 TCP with Structured Syslog format. We used Splunk connect for syslog to get the logs and configured the metadata files as it was suggested in Splunk SC4S docs. - https://splunk.github.io/splunk-connect-for-syslog/1821/sources/vendor/Juniper/junos/
But we are not able to parse the logs properly in Splunk cloud. Line break is not working properly which causes the multiple events becomes the part of single event in splunk.”
sourcetype=juniper:junos:firewall

we need pcap/raw data on the wire to reproduce the scenario, we haven't noticed this issue in any of our tests.

@gshah123,
We did not hear anything from you about this issue.
Closing this issue for now.
Feel free to reach out in case of any further queries.
Thank you.


Extension Page stories, restructuring Storybook code

This PR thanks to @riccardo-forina and live code share this morning.
Changes:

Write stories for Extension Page.
Group Extension Page stories together in Storybook.
Remove this.state reference no longer in use.

Some screenshots:

PR Storybook available here


not working reliably after upgrade to Lollipop 5.0.2 on Sony Xperia Z2 tablet

i upgraded my Sony Xperia Z2 tablet (Verizon model SGP561) from Kitkat 4.4.x to Lollipop 5.0.2 and now the app rarely works without first manually issuing a command in the debug terminal. there are no errors or crashes, and no errors were noticed in logcat either. the app appears to connect OK, but never begins receiving bus data from the ELM adapter without the manual command.
some part of the service looks like it may be "hanging" during launch. sending any command form the debug terminal causes the startup commands to be issued again and everything begins to work. note that just using the menu option "re-send startup commands" in the terminal does not work though.
i've tried manually launching the app as well as using the "automatic launch" setting, neither makes a difference.
i am using version 1.0 of the app (car_bus_interface_v1.0-debug.apk)

now fixed in Version 1.1 (1/7/2015)
within CBIServiceMain.java > btWriteBreak(), sending a null character alone was no longer working to stop a long running receive. however, sending a null + carriage-return/line-feed would have caused problems in older Android versions because the null char would break the receive and then the return/feed would be interpreted separately and result in most ELM adapters repeating the last command starting the receive again... therefore i needed to send something plus a return/feed, so i went with a tab ("\t") - hopefully this isn't seen as a special command to any ELM adapters out there.


Labels for dockerTools

Docker has a feature called labels. I'd like to see this exposed too.
See https://docs.docker.com/engine/userguide/labels-custom-metadata/ for more information.

@fubarbaz @NeQuissimus Docker image labels are supported in config argument buildImage:
    config = {
         Labels = {
             "com.acme.label" = "value";
         }
    }

our problem is probably that while our docs say

config is used to specify the configuration of the  containers that will be started off the built image in Docker. The available options are listed in the Docker Image Specification v1.2.0

Docker Image Specification does not seem to be updated to include labels.

fixed?

@tomberek labels are working and I was able to leverage this successfully with pkgs.dockerTools.buildImage as @datakurre mentioned. See this nix expression for context.
Resulted in:
$ skopeo inspect docker://docker.io/nebulaworks/awsutils:dz783iaashdby6phqf9pcydxsw1bbjq0
{
    "Name": "docker.io/nebulaworks/awsutils",
    "Digest": "sha256:4df34c1e6ab561b3aa6f0c250122ce121ff18e6803d72733f041978b87979df4",
    "RepoTags": [
        "dz783iaashdby6phqf9pcydxsw1bbjq0"
    ],
    "Created": "1970-01-01T00:00:01Z",
    "DockerVersion": "",
    "Labels": {
        "com.nebulaworks.packages": "awscli:1.17.13,bash:4.4,coreutils:8.31,curl:7.68.0,jq:1.6",
        "org.opencontainers.image.authors": "Nebulaworks Inc.",
        "org.opencontainers.image.source": "https://github.com/Nebulaworks/nix-garage"
    },
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:6f29a11d541b258cbfb4956ccc442ac0ecf8a6c052f10d1ed0d6d6078ae30f2a"
    ]
}

Seems like this can be closed.


Rule #150 incorrectly references discussion of 207 for rate limiting

The rule 150, in particular, when discussing the 429 response code, contains the following:

Too many requests - the client does not consider rate limiting and sent too many requests. See Must: Use 207 for Batch or Bulk Requests.

This incorrectly links to http://zalando.github.io/restful-api-guidelines/#152 where it should actually link to http://zalando.github.io/restful-api-guidelines/#153, which is "Must: Use 429 with Headers for Rate Limits [153]"

Thanks for noting. We found already quite some of those off-by-one wrong links, which were likely caused by the migration to AsciiDoc (in #282), maybe we should systematically check all of them.