"boolean" is a keyword

"boolean", which is used for a method name in the module, is a future reserved keyword (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Reserved_Words). Error messages are emitted by various checkers.
Please provide the same method under a different name.

I suggest either toggle or switch.


Card links: border style

Description
The current colour contrast of the page background and card links surrounding border is 1.24:1. As it does not meet the non-text contrast ratio of 3:1 it makes the border somewhat redundant.

Blog post on non-text contrast of UI elements
https://iknowdavehouse.medium.com/why-debate-non-text-contrast-of-ui-elements-1be4313c9e12

Every time you design or build something, take 10 minutes to review it with all the parts of the interactive UI elements that do not meet 3:1 contrast ratio removed.
So if your button background does not meet 3:1 remove it, if your interactive card borders do not meet 3:1 remove them…
Then ask yourself:

Is the interface still understandable?
Is the interface still as usable?
Could I do more?

https://github.com/nhsuk/nhsapp-frontend/issues/11#issuecomment-2063462496

Button v Card link comparison

Something to consider is the visual alignment between buttons and card links (spacing, text size, border width etc).
Current sizes:

Secondary button border 2px v Card link border 1px
Button text size (mobile) 16px v Card link text size (mobile) 19px

Note: We're currently in the explorative stage of the secondary button and secondary card links.
Also the example above has the divider line connected to the right of the card link, but that still needs to be decided (see this issue).

@davidhunter08 re: the above note "Something to consider is the visual alignment between buttons and card links (spacing, text size, border width etc).", i made a little doodle...

Some exploration of border styles, font sizes, spacing on card links:

Screenshots on Mural
cc @michaelgallagher

Account Identity management card
Context: In the IA/Nav team we've been exploring creating a new 'identity management card' for the new Account Hub. The aim of this card is to give users information about themselves and given them the option to go and manage health services for others.

We've been chatting around making this card visually different to other elements of the page to reinforce this information and set the context of who's account you are on. We've previously heard from users around the importance of this information and that they associate the 'proxy' jump-off to their own personal account information.

Few exploration screenshots of the visual treatment of the card:

@michaelgallagher & @davidhunter08 any feedback would be appreciated!

Thanks for sharing @mariapinillapease 🙌
IMO tonal colours is the way to go for the 'identity management card' but I'm just not sure on the border styles, it feels quite sharp.
I was actually looking card link styles yesterday afternoon, considering the 'identity management card' alongside the existing card link styles and buttons. I was also thinking about how to make it all feel a bit more 'appy', as we look to go more native 👀
Here's where I got to:

In summary:

added a 8px border radius (also bumped button radius to 8px from 4px)
removed the outer borders, reducing the visual noise
tweaked the chevron and inner border colours to make more versatile for the different colour backgrounds (also reducing visual noise)
reduced the link font size to 16px, it's currently 18px but the new typographic scale would bump it to 19px, which would be quite large

Next steps:

review proposed changes with the service manual team to understand how best to progress with visual design changes such as these and how it impacts others components in the design system
initial accessibility assessment of proposed design (eg: does it work without borders etc)

Thanks @davidhunter08
I like the suggestion of having the tonal colour for the card but without the border. I agree that removing the outer borders reduces the visual noise.


Passing the object-type to the plugin

Currently, the object-type which is supported by the plugin is derived from the classname.
For some objecttypes might contain also contain forward slashes (namespaced).
Also, it might be possible to have one plugin support multiple objecttytpes (e. g. a generic sobj-based plugin).
Proposal similar like in saplink:
  SELECT * FROM vseoextend INTO TABLE classlist
    WHERE refclsname like 'ZABAPGIT_OBJECT_%'
    AND version = '1'.

  LOOP AT classlist INTO classline.
    clsname = classline-clsname.
    TRY.
        CREATE OBJECT classobject
          TYPE
            (clsname)
          EXPORTING
            name      = 'foo'.
        objtype = classobject->get_supported_objecttypes( ).

yep, seems like a good idea, assuming this is extended to the built-in object types
could get rid of the following evil hack
https://github.com/larshp/abapGit/blob/master/zabapgit.prog.abap#L11178
and the not so evil hack
https://github.com/larshp/abapGit/blob/master/zabapgit.prog.abap#L11134
could be done in a nicer way

though need to consider the constructor input, it seems off to instantiate a class with a dummy abap object to get the supported types :o/

As the instantiation is anyway managed, I'd think of having a
constructor which is free of any parameters and a protected abstract
method to define the scope of the instance.
------ Originalnachricht ------
Von: "Lars Hvam"<EMAIL_ADDRESS>An: "larshp/abapGit-Plugins"<EMAIL_ADDRESS>Cc: "Oliver Jägle"<EMAIL_ADDRESS>Gesendet: 16.02.2016 19:29:27
Betreff: Re: [abapGit-Plugins] Passing the object-type to the plugin
(#3)

though need to consider the constructor input, it seems off to
instantiate a class with a dummy abap object to get the supported types
:o/
—
Reply to this email directly or view it on GitHub.

yea, it would work

guess this can be closed, implemented in https://github.com/larshp/abapGit/pull/177


Fix a broken link to contributions guidelines

Fixes a broken link to contributions guidelines.

Another issue with readmes. The quarterly project reports link under https://github.com/finos/morphir-scala/blob/main/CONTRIBUTING.md#governance looks to be expired. If anyone knows the correct/up-to-date location, feel free to drop it here. I can include the fix/update in this PR.


Could NOT find cpuid (missing:  CPUID_INCLUDE_DIR CPUID_LIBRARY)

Building on Ubuntu 16.04 LTS, having searched for a good while.  Haven't been able to figure out the required dev library package.
Thoughts anyone?

Digging further into the error report showed that BOOST library dev dependencies were needed, this allowed me to complete the 'build'.


As a user, I want to generate a report that shows the total payroll amount received by a specific employee

, so that I could track the employee's overall compensation.

Payslip generator partially implemented. Still need to add report or payslip command.

next step: implement batch export


RFC: Native pointer vectors

Native pointer vectors
This bug is a request for comment.  I am but a novice Rust developer, but I suspect that this would be a strong addition to the language.
Motivation
While working on bindings for FFTW (the Fastest Fourier Transform in the West), I ran into the hairy issue that it doesn't seem possible to have Rust hold vector pointers to the outside world.  What do I mean by this -- and why do we care?  Well, I'll provide (a distilled version of) the FFTW APIs in question, by way of example:
double *fftw_malloc(size_t sz);
fftw_plan_t *fftw_plan_fft(size_t n, double *in, double *out, int flags); /* morally */
void fftw_execute(fftw_plan_t *plan);

The general course of action when using FFTW is to use fftw_malloc to get a chunk of space to store your inputs and outputs, then create a "plan" with fftw_plan (a potentially expensive operation, but if you intend to run many FFTs, ultimately time-saving), and then finally execute the plan with fftw_execute when you've populated your buffers.  You can fftw_execute the same plan many times (and, in fact, if you can, you should!) after refilling the buffers and taking data out.
In FFTW-land, fftw_malloc is not strictly necessary as the only way to get memory, but it's a Damn Good Idea -- and as I'll discuss in a moment, not using it doesn't save us.  fftw_malloc goes out of its way to obtain memory that has "nice" properties; for instance, it tries hard to align things not just to double boundaries, but also to cache lines, depending on how much memory you ask for.  If it knows anything else interesting about your system, it takes that into account.  So, it's not fatal to not use it, if that's the only thing you can do ... but it sure does hurt.
Currently, in Rust, there is no way to import a pointer from the outside world and use it mutably, nor is there a way to tell Rust that this pointer may be written to by an outside API.  The closest thing that Rust has is vec::unsafe::from_buf, which in turn calls rustrt::vec_from_buf_shared, but the first thing that vec_from_buf_shared does is allocate a new space and copy the memory away!  This makes it unsuitable for referencing both the in and the out pointers; changing a pointer that has been imported through this mechanism will cause changes not to get written back to the outside world, and executing a transform to (and overwriting the contents of) a pointer that has been imported through this mechanism will cause Rust to not see the changes that happen after the copy.
In this case, we have another option, though.  We could create a vector inside Rust, and use vec::unsafe::to_ptr to create a pointer to it.  This will work, but it is dangerously broken (violates safety) in three ways.  In the first, Rust is not in control of the lifecycle of the external reference; Rust cannot know when the external reference no longer exists, and may prematurely garbage collect the vector.  This can happen, for instance, in the case in which a reference to the out pointer is still live, and a reference to the plan is still live, but the reference to the in pointer is dead; calling fftw_execute on this plan will result in doing accesses to the dead in vector, which may have been garbage collected.
In the second, Rust may reallocate memory out from under the external application.  The vector can be appended to, which may cause a reallocation to occur.  The external application's pointer will not be updated, and when it goes to access that pointer, that memory will be dead.  In the case of a "correct" usage, this will not occur (i.e., the programmer can be instructed not to do that), but this violates safety; at the very least, += now becomes an unsafe operation.
In the third, perhaps most compellingly, this locks Rust into a world in which it is not permissible to have a copying garbage collector.  Right now, Rust does ref-counting and garbage collection with free()... but this need not always be the case!  Another implementation of Rust could very conceivably experiment with garbage collection schemes for better performance.  If the behavior of pointers were already specified, it would be one story, but currently that behavior is not -- and I argue, for the better.
In short, the language's existing capabilities for this are not sufficient to operate with at least one API.
Use cases
The FFTW API is not the only system in which the current capabilities for referring to native memory are insufficient.  Consider also:

A framebuffer interface, in which an external resource has mmap()ed some memory.  Accesses must go to exactly those addresses; none else will do.
A command queue interface, in which a set of commands are provided for an external device (say, a graphics card) to DMA to and from chunks of memory.  (This is how modern graphics cards operate.)  Accesses must go to some prescribed address, usually managed through a remote resource manager (DRI, et al); no other address will do.

These are both examples of requiring a specific address... recall, however, that there are surely many applications that require some mutable chunk of memory, any mutable chunk at all!  Consider, for instance, the ioctl() interface on Linux, which has a similar "combination input/output buffer".
The FFTW API is one of many cases that require mutable memory accessible to the native system.
Proposed solution
I propose the addition of a vector qualifier, [native T].  The type [native T] does not unify with [T]; it is mainly distinct from the normal vector, but that dereferencing indexes in it and iterating over it both work.
The type [native T] has one introduction form:
unsafe fn std::vec::unsafe::native<T>(ptr: *T, elts: uint) -> [native T];

The following elimination forms of vectors function for native vectors:

v[a] as an expression (with size checking)
v[a] as an lvalue (with size checking)
for t: T in v as a loop construct

Notably, the following form does not function:

v += vp as an append

When a native vector goes out of scope, the native memory pointed to is not modified or otherwise operated upon.
These are the basic rules for a native vector.
Implementation
A native vector has the following internal representation:
type native_repr<T> = { len: uint, data: *T };
It is distinct in the type system because it does not share a representation with a Rust vector.  This choice was made to avoid the performance cost of having to check at run time whether any given vector is a Rust vector or a native vector before accessing it.
Translation is presumably very similar to Rust vectors.
It could be the case that no rustrt support is needed for this, since the native_repr type can be constructed purely in Rust, and then can be reinterpret_casted into a native vector.
Extensions
The above describes a basic semantics for a native vector.  It provides a semantics sufficient to behave safely, but missing are two potentially useful extensions.  These are optional, and certainly not required for a first pass implementation, but would make the native vector substantially more usable.
[native? T] unification
There is currently a substantial vector library built up to operate on Rust vectors.  Just because some operations do not apply, it does not make sense to have to duplicate the ones that do.  For that, I propose the [native? T] qualifier, similar to [mutable? T].  Presumably a separate code path would have to be emitted at translate time.  I do not know enough about the inner workings of mutable? to comment on how similar this might be, and how possible this might be given the existing Rust codebase.
Built in destructors
It can be potentially useful to have Rust take over lifecycle management of memory, if the FFI binding builder is careful.  Classically, the mechanism by which one might do this is as such:
type mem = {
  vec : [native f64],
  dtor : @mem_res
};

fn malloc(n : uint) -> mem {
  let mem = fftw_native::fftw_malloc(n * 8u);
  ret { vec: unsafe { vec::unsafe::native(mem as *f64, n) }, dtor: @mem_res(mem) };
}

resource mem_res(mem: fftw_native::mem) {
  fftw_native::fftw_free(mem);
}

This has the unfortunate downside that a user of the API can extract the vec from the type mem, and let the type mem itself go out of scope (or otherwise become dead).  When the type mem itself becomes dead, the resource can immediately be freed, even though the native vector may still be live; this can violate safety.
A native vector, then, may wish to have an introduction form that includes a resource pointer associated with it, for built-in cleanup.
Conclusion
In this document, I describe a new form of vector called the native vector.  The native vector allows Rust to safely interact with external memory.  The introduction form is unsafe, so although it would permit inter-task shared memory communication, it does not do so in a particularly novel fashion.  This proposed solution addresses all of the mentioned use cases in what seems (to the untrained eye!) like an elegant, Rust-like fashion.
Thoughts?

First off, thanks for the well-reasoned and written up proposal.  Here is another possible solution that seems a bit less invasive.  First, we add the ability to dereference unsafe pointers using [] syntax.  Therefore, for a value x of type *T, x[5] would do the same thing as in C, just as *x is currently permitted.  Both of course are only legal in unsafe code.
Based on this, one can implement the proposed unsafe vectors as a library.  Something like:
mod c_vec {
    type t<T> = { base: *T, size: uint };
    fn create<T>(base: *T, size: uint) -> @t<T> { ret @{ base:base, size:size}; }
    fn get<T>(v: t<T>, idx: uint) -> T { assert idx < v.size; ret v.base[idx]; }
}

The one issue is the re-use of higher-order functions from the vec module and so forth. I think that this could be addressed with traits or other similar solutions.

This is an important problem to solve, but I'm reluctant to solve it at the language level because vectors are likely going to change yet again and, as niko hinted, the language will probably become expressive enough solve it in std.
Eventually we should be able to implement c_vec and vec as implementations of a common interface and treat them more or less interchangeably.
Still, we need some solution now since people are going to be writing more and more interop code. Can we implement a stopgap c_vec module now that would make writing this kind of code more convenient?

so everything I described can be written today if the [] operation were added, which doesn't seem very difficult.  You would end up with some code duplication, I guess.  Also we need to think about when these arrays get freed---probably you want a resource?

Right.  Well, yeah, I could add the [] operation if that seems like the Right Way to do it.
Resources seem like a solution, but the question is where the resource goes ... take a look at the "built in destructors" extension proposal in my original post?

I think it could be done even without []. We have pointer math.

Client code could be prevented from pulling out the vec by keeping mem abstract, I think?
(Where by abstract I mean "wrapping it in a tag and not exporting the constructor", unless we have added more real abstract types while I was gone)

Yes, except that #818 is still not fixed. Could also put it in an obj if you don't mind the vtable.

@msullivan: That would work.
@brson: OK -- I can try hacking that up tomorrow or tomorrow evening.
I'm still not convinced, though, that not unifying with the existing vector bits isn't the right way.  I thought about it some more today.  Having to call out to a function to safely do a set and a get on a native vector -- an operation that we probably want to be fast!  Adding typeclass dispatch for all vectors creates quite a bit of overhead... is that really the right thing to do?
I agree that where possible, "more general" solutions are better than "more specific".  But I'm not totally convinced that in this specific case, typeclassing vectors will lead to acceptable performance...

There is no dynamic overhead to the categories that I proposed.  All calls would be dispatched statically.  I don't know the details of how Haskell typeclasses are implemented but I think categories are not 100% analogous.  Without inlining, it's true that there is some function call overhead to do the get() operations.  You will have overhead if you want to have some function that accepts either a native or a non-native vector and performs operations on it, because that will require an interface, which involves dynamic dispatch.
However, there is one limitation that I was thinking about with the categories.  The implementations of higher-order functions like map() will be difficult to share because their type signatures are hard to express without knowledge the direct types involved.  This is the precise issue that the Scala people addressed in their 2.8 collection rewrite.
For example, consider a trait vec_like:
trait vec_like<T> {
    req T get(idx: uint);
    req void set(idx: uint, T value);
    req uint len();

    // foreach works great
    fn foreach(b: block(T) => ()) {
        let i = 0u, n = len();
        while i < n { b(get(i)); }
    }

    // map... not so great. what is the return type?
    fn map<S>(b: block(T) => S) -> ??? {
    }
}

The earlier versions of Scala addressed this problem through inheritance. The return type of map(), for example, would be vec_like<T>, and there would be a req fn clone -> vec_like<T> function that duplicated the existing vector-like thing.  This is ok but not great and doesn't apply to us very well since vec_like<T> is not a type.  The newer versions use implicits to get much more precision but with much more complexity. You also need parameterization by type constructors, not just types.  Again, another level of complexity.
I still think native vectors don't need to be built into the language more than they already are, and much of the code can be shared, but without some significant design work there will be more redundancy than I originally envisioned.

Right, indeed, "map" just returned Rust vectors in the original implementation.
So here's what I'm hearing: either way, there should be a c_vec module with manual "get" and "set" that wrap the unsafeness inside of them.  There is substantial pain involved in not being able to use [], but that pain might be resolved in the future by what you call traits (and what I call typeclasses).  The c_vec needs no language extensions -- just basis extensions, and would be sufficient to unblock a user of fftw.
@brson commented that [] is not necessary on native pointers, but I'm not entirely convinced yet.  Strictly, there are a lot of things that are not "needed" in a language, but not having sugar makes a lot of operations pretty disgusting...
I'll write a mod c_vec tonight, and see if using it makes me want to puke or not.

So here's one thing that we don't have exposed from the language that we certainly do need in order to have mod c_vec.  In order to add pointers together, the best that we can get is something like:
fn p<T>(t: t<T>, ofs: uint) -> *mutable T {
    // I'd like to do the following, but FIXME #1173
    // (*t).base + (ofs as *T)
    ((*t).base as uint + ofs) as *mutable T
}

Specifically, I cannot write (*t).base + ofs directly, since if I do:
./c_vec.rs:36:17: 36:20 error: mismatched types: expected *ps0 but found uint (types differ)
./c_vec.rs:36     ((*t).base + ofs) as *mutable T

This would be by itself just an annoyance, but the fatality here is that we can't know the size of a T at compile time -- I believe there is no sizeof-like operator.
Thoughts for a workaround?

What you want to do, I believe, is this:
mod c_vec {
import ptr;
    type t<T> = {
        base: *T;
        len: uint;
    };

    fn get<T>(v: t<T>, idx: uint) -> T unsafe {
        assert idx < v.len;
        let ptr = ptr::offset(v.base, idx)
        ret *ptr;
    }

    fn set<T>(v: t<T>, idx: uint, value: T) unsafe {
        assert idx < v.len;
        let ptr = ptr::offset(v.base, idx)
        *ptr = value;
    }
}

With respect to the annoyance of typing c_vec::get() and c_vec::set(), I hear you.  I think the only solution to that is user-defined operators.  I personally like the idea but others may disagree

Right, ptr::offset() did the right thing -- sort of.  There are a few other niggling details in there, but I have a pull request ready in pull request #1217. (Not ready to be pulled yet; an RFC at this stage.)
Of note, there are a few things that I'm not sure about in there.  I'm not sure about whether <copy T> is the right thing -- this seems to be new as of this week?  Similarly, I'm not convinced (or unconvinced) that the mutable T cast is the right thing.
I haven't written tests for it yet, but I could easily do so as needed.

I've renamed the pull request away from "do not merge"; I would say it is approaching ready.

Closed, pending rework in #1227 for get and set (and perhaps [] overloading).


Render and resize for web display?

Type of issue
[ ] Bug
[x ] Question (e.g. about handling/usage)
[ ] Request for new feature/improvement
Expected Behavior
Current Behavior
Possible Solution (optional)
Steps to Reproduce (for bugs)
Your Environment
ASP.NET MVC
Currently I am using QRCode class and resize the Bitmap of GetGraphic method. Then I place the BMP as Base64 image on webpage.
Problem is: The QRCode gets blurry when resizing to 96x96px.
How can it be done with high quality render?

Maybe you could use the SvgQRCode-Renderer


Kubernetes service discovery continues to scrape metrics from the IP of pods in an Error state

What did you do?
We have configured Prometheus with Kubernetes service discovery. We have a job named kubernetes-pods which uses the pod role for service discovery.
We had a pod named ibv-instructions-svc-111-4gvk8 running with pod IP <IP_ADDRESS> exposing metrics on port 8009 under the path /metrics. This pod failed (due to excess memory usage), and went into the Error state:
$ k get po -o wide
NAME                                  READY   STATUS    RESTARTS         AGE     IP                NODE   NOMINATED NODE   READINESS GATES
[…]
ibv-instructions-svc-111-4gvk8        0/1     Error     0                42h     <IP_ADDRESS>      kn5    <none>           <none>
ibv-instructions-svc-111-58gs5        1/1     Running   3 (22h ago)      42h     <IP_ADDRESS>     kn3    <none>           <none>
ibv-instructions-svc-111-7d28m        1/1     Running   0                42h     <IP_ADDRESS>      kn4    <none>           <none>
ibv-instructions-svc-111-ctwvv        1/1     Running   0                22h     <IP_ADDRESS>      kn2    <none>           <none>

After some time, this pod IP was re-used by another pod admin-checks-3-p45lk (actually in a different namespace, though that is not relevant for the ticket):
$ k get po -o wide --namespace admin
NAME                              READY   STATUS    RESTARTS   AGE   IP               NODE   NOMINATED NODE   READINESS GATES
[…]
admin-checks-3-m2mnr              1/1     Running   0          64m   <IP_ADDRESS>     kn7    <none>           <none>
admin-checks-3-p45lk              1/1     Running   0          64m   <IP_ADDRESS>     kn5    <none>           <none>
admin-checks-3-qpmg4              1/1     Running   0          65m   <IP_ADDRESS>     kn3    <none>           <none>

This new pod also exposes metrics on port 8009, under the same path /metrics.
What did you expect to see?
We expected to no longer see any metrics from the pod ibv-instructions-svc-111-4gvk8, once it had entered an Error state. We did not expect to see it in the Targets view of the prometheus agent that is scraping it.
What did you see instead? Under which circumstances?
Metrics emitted by the new pod admin-checks-3-p45lk are visible, but a copy of those metrics labelled as though they come from the old pod ibv-instructions-svc-111-4gvk8 are also visible.
With our relabelling config (attached below) we see otherwise-duplicate metrics with the following labels:

{cluster_loc="stg1", instance="<IP_ADDRESS>:8009", job="kubernetes-pods", kubernetes_cluster="app-clusterx1.stg-ld5.gbr", kubernetes_namespace="docs", kubernetes_pod_name="ibv-instructions-svc-111-4gvk8", monitor="kubernetes", serviceName="ibv-instructions-svc"}
{cluster_loc="stg1", instance="<IP_ADDRESS>:8009", job="kubernetes-pods", kubernetes_cluster="app-clusterx1.stg-ld5.gbr", kubernetes_namespace="admin", kubernetes_pod_name="admin-checks-3-p45lk", monitor="kubernetes", serviceName="admin-checks"}

System information
Kubernetes 1.22.5
Prometheus version
prometheus, version 2.35.0 (branch: HEAD, revision: 6656cd29fe6ac92bab91ecec0fe162ef0f187654)
  build user:       root@cf6852b14d68
  build date:       20220421-09:53:42
  go version:       go1.18.1
  platform:         linux/amd64

Prometheus configuration file
global:
  scrape_interval: 15s
  external_labels:
    monitor: 'kubernetes'
    cluster_loc: "{{cluster_loc}}"
    kubernetes_cluster: "{{cluster_name}}"

remote_write: [] # elided for brevity

scrape_configs:
# several elided for brevity

#
# Scrape from Kubernetes pods
#
- job_name: 'kubernetes-pods'
  label_limit: 100
  label_name_length_limit: 100
  label_value_length_limit: 2000

  # ask k8s for a list of pods
  kubernetes_sd_configs:
  - role: pod

  relabel_configs:
  # Pod scraping config comes from annotations on the pod.
  #  • `prometheus.io/scrape`: Only scrape pods that have a value of `true`
  #  • `prometheus.io/path`: If the metrics path is not `/metrics` override this.
  #  • `prometheus.io/port`: If the metrics are exposed on a different port to the
  #    pod then set this appropriately.
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
    action: keep
    regex: true
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
    action: replace
    target_label: __metrics_path__
    regex: (.+)
  - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
    action: replace
    target_label: __address__
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2

  # Add pod name and namespaces labels to the time series.
  - source_labels: [__meta_kubernetes_namespace]
    action: replace
    target_label: kubernetes_namespace
  - source_labels: [__meta_kubernetes_pod_name]
    action: replace
    target_label: kubernetes_pod_name

  # Connect team used the "serviceName" label in some dashboards; keep it in case
  # it's useful elsewhere.
  - source_labels: [__meta_kubernetes_pod_label_serviceName]
    action: replace
    target_label: serviceName

Alertmanager version
No response
Alertmanager configuration file
No response
Logs
No response

Please note: I don't believe this is necessarily a duplicate of #10257, because that is using the endpoints role and not the pods role.
As far as I can see, #10257 is being caused by the Endpoints object retaining a reference to the old pod IP, whereas this issue is because Prometheus is not considering the fact that the pod has exited (state Error) before it decides to scrape, and it just so happens to pick up some other unrelated pod that has since come along on the same virtual IP.

I've captured the YAML for the pod, in case it's useful to see how to extract the status: pod.yaml.gz

The underlying reason here is actually very similar to #10257, pods are kept around after termination; this is dependent on kube-controller-manager GC flags and the amount of pod churn in the environment.
As mentioned in https://github.com/prometheus/prometheus/issues/10257#issuecomment-1046784527 for endpoints the desired behaviour can depend on the environment. Pods are similar to endpoints in this respect and there is a meta label available to relabel on  __meta_kubernetes_pod_phase.
A relabel like:
- source_labels: [__meta_kubernetes_pod_phase]
  action: drop
  regexp: Failed|Succeeded

Would fix this (the pod yaml you provided -- thanks! -- shows phase: Failed for this case). It probably would make sense to suggest this in the Kubernetes example config.

Thank you for the response.
I agree that it would be sensible to provide this in the example config, as we did use that as the starting basis for our own config. But it is rather surprising that we need to explicitly filter out pods in this status (I believe that it is only in Kubernetes v1.22 onwards that pods that have exited retain their original IP field value in the Status section — in earlier releases, the pod objects still existed but they had no IP value).
I have added the following relabel_configs entry to the job:
  # Only scrape pods that are in the Running phase.
  #  https://github.com/prometheus/prometheus/issues/10755#issuecomment-1139248161
  #  https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core
  #    Pending — not all containers running yet. Pod may not even be scheduled yet.
  #    Running — all containers created and at least one still running.
  #    Succeeded — all containers exited with status=0, pod will not restart.
  #    Failed — one or more containers exited with status≠0, pod will not restart.
  #    Unknown — we lost contact with the host's kubelet. We have seen this persist for
  #              days after a node machine dies.
  - source_labels: [__meta_kubernetes_pod_phase]
    action: keep
    regex: Running

I chose to only keep pods in the Running phase — each of the other phases I have observed to overlap with cases where I know metrics scraping would fail and I'd rather not have the error messages / metrics from Prometheus in this case. However, perhaps others may evaluate the trade-offs differently.
I've verified this on the cluster where we still have the same status as in the bug report and it does indeed just drop the one target that was being scraped erroneously.

It seems that the original "issue" has been solved. Feel free to reopen if it's not the case.
FWIW recent versions of the Prometheus Operator drop pods in Failed or Succeeded state by default.


A (hopefully) better Hamburger Button

I have created what I think to be a more understandable and cleaner hamburger menu . It doesn't have the jitter on hover that's present in the current snippet.
Just want to see what everyone thinks and if what I've done is better understood and cleaner, I'd be happy to send a PR to update the current snippet.
Current version: https://css.30secondsofcode.org/snippet/hamburger-button
My version: https://codepen.io/duoketchup/pen/NWWVPWO?editors=1100

Great work! Feel free to make a PR

Opened PR #173


Disable issue staling

As discussed with the team, staling issues has no value anymore.
Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.


Inconsistent header capitalisation

https://github.com/dwyl/learn-json-web-tokens/blob/e31141dfa8e34b29af759be1d1a01fe8fbb49ca9/example/lib/helpers.js#L68
Content-Type vs authorization vs user-agent
Headers are case-insensitive, but it still makes me feel wibbly.

Yeah... this repo/readme is a mess! I've been meaning to aksk someone to be our copy editor...


Use HTTPs for getsubstrate.io

When using the instructions in the README, I execute arbitrary code from the internet. This code should at least be protected by TLS.

... is now served via HTTPS only.
https://getsubstrate.io/  (HTTP/1.1 200 OK)


Remove beforeUpdate hack once vue 2.6.0 is released

Currently vue-relay uses a computed property as a workaround for vuejs/vue#7481.
Need to remove the hack once the fix is released.

@ntkme Vue v2.6.2 released ;)


get template methodology species id for occurrence_submission

Overview
Links to jira tickets

https://quartech.atlassian.net/browse/BHBC-1347

This PR contains the following changes

{List all the relevant changes. If there are many changes across many Jira tickets, organize the changes by Jira ticket}

This PR contains the following types of changes

[x] New feature (change which adds functionality)
[ ] Enhancement (improvements to existing functionality)
[ ] Bug fix (change which fixes an issue)
[x] Misc cleanup / Refactoring / Documentation
[ ] Version change

Checklist
A list of items that are good to consider when making any changes.
Note: this list is not exhaustive, and not all items are always applicable.
General

[ ] I have performed a self-review of my own code

Code

[ ] New files/classes/functions have appropriately descriptive names and comment blocks to describe their use/behaviour
[ ] I have avoided duplicating code when possible, moving re-usable pieces into functions
[ ] I have avoided hard-coding values where possible and moved any re-usable constants to a constants file
[ ] My code is as flat as possible (avoids deeply nested if/else blocks, promise chains, etc)
[ ] My code changes account for null/undefined values and handle errors appropriately
[ ] My code uses types/interfaces to help describe values/parameters/etc, help ensure type safety, and improve readability

Style

[ ] My code follows the established style conventions
[ ] My code uses native material-ui components/icons/conventions when possible

Documentation

[ ] I have commented my code sufficiently, such that an unfamiliar developer could understand my code
[ ] I have added/updated README's and related documentation, as needed

Tests

[ ] I have added/updated unit tests for any code I've added/updated
[ ] I have added/updated the Postman requests/tests to account for any API endpoints I've added/updated

Linting/Formatting

[ ] I have run the linter and fixed any issues, as needed
See the lint commands in package.json
[ ] I have run the formatter and fixed any issues, as needed
See the format commands in package.json

SonarCloud

[ ] I have addressed all SonarCloud Bugs, Vulnerabilities, Security Hotspots, and Code Smells

How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Screenshots
Please add any relevant UI screenshots, if applicable.

nice unit test cases @anissa-agahchen


Results Processing for 30+ minutes

My team is attempting to submit our final results for the 2D detection model, but it has been on the processing phase for the past 30 minutes. Is there potentially something wrong with our submission or should we continue to wait?

There is a high load of submission now. You can wait a bit. As long as it is submitted before the deadline, it is counted in the challenge.

If you are worried, send me a link to your submission to<EMAIL_ADDRESS>

Great! Just sent the email


createApolloClient, SSR, and providing HttpLink to Apollo Client

I am using Vue 3.0 and SSR (via Quasar and Vite), and I am running into a problem where because SSR must be rendered on both the client and server, there is no global fetch instance defined, and I'm getting the following error:
Invariant Violation:
"fetch" has not been found globally and no fetcher has been configured. To fix this, install a fetch package (like https://www.npmjs.com/package/cross-fetch), instantiate the fetcher, and pass it into your HttpLink constructor. For example:

import fetch from 'cross-fetch';
import { ApolloClient, HttpLink } from '@apollo/client';
const client = new ApolloClient({
  link: new HttpLink({ uri: '/graphql', fetch })
});

I am using the nhost methods to create these clients and I've tried using generateNhostApolloClient:
    const apolloClient = generateNhostApolloClient({ gqlEndpoint: "https://hasura-your_hasura_endpoint.nhost.app/v1/graphql%22%7D).client;
as well as createApolloClient:
   const apolloClient = createApolloClient({ nhost });
When creating an ApolloClient directly the solution suggested by the error is possible, but it doesn't appear that there's a way to provide a custom HttpLink instance when using nhost.
This seems like a showstopper for using SSR, and it seems like the solution would be to pass a custom HttpLink into either generateNhostApolloClient or createApolloClient. Is there another option that I'm missing?
As an aside, I see example of using both generateNhostApolloClient and createApolloClient. Is one of these preferred over the other?
Thanks in advance for the help!!

Notice that the Apollo package is but a wrapper of Apollo and the headers from the user of your application, so you can achieve the same by importing base apollo and including the headers (token.) Does that help? I'm not sure that you currently can send a special fetch to the provider itself 🤔


chore(main): release 1.25.4

:robot: I have created a release beep boop
1.25.4 (2024-10-31)
Performance Improvements

♻ Enhance recording stability (3dd7525)
♻ Optimize camera recording stability (952b2a7)
💄 Normalize control window titles and generated file names (ccc7f0e)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.25.4
:sunflower:


Announcements framework

Ticket:  Closes #1454 Framework for features updates / announcements
How it works

Display announcement through a modal at startup:

It will only be shown once per entry.
Users can manually re-open it to review from Settings > Help > What's New.

Content definition is through markdown.

It's currently hardcoded in the component file, but I envision it to be part of homepage { categories, meme, announcement }.  But it can be from wherever we want.
I'm thinking it should per-homepage rather than per-language, since translating to all languages in time would not be feasible.
Content length can be infinite (content area will be scrollable).

Style Todo (but not needed for MVP)

[ ] Animate the modal's appearance.
[ ] Mobile modals will take over the full screen.  I think for the case of announcement, it should just take parts of the screen, so that returning or first-time users know it's a modal.

Dev/Testing notes

Delete viewed-announcement-hash in local storage to make the same text appear at startup.

This is awesome! Agree on it being in homepages, but can start here. I haven't had a chance to check it out, sorry.
Other thoughts:

probably don't want it for new users?
Is it only on homepage (probably what we want)

d030e51 to 40f808e

Exclude incognito and only show if loaded from the homepage.

After putting it up on a dev instance, I realized it won't work when re-opening the browser because the local cached version is used (same issue as "users stuck with old version").
Will need #1329 so that an explicit F5 is not required.

Fastest solution to the issue above is to continue with built-in homepage + fetch v2 but only use the announcements data.

I'm ok with V2 for announcement data

Worth syncing to wallet also? So let's say i sign in on another device or log out / back in, i don't see it again?

Moved storage to wallet
It opened up more timing corner-cases, but I think I covered it all.  Asking Miko to try out would be nice.
Note that moving to the wallet means we need to wait until the first sync before announcements can appear -- can be up to 5 seconds.
Testing notes:

Moved to inf test instance.
Use window.clearLastViewedAnnouncement() to reset.  Wait until "populating..." appears.
Ideas for permutation:  Refreshing and logging in are 2 different redux paths (wallet vs rehydrate).

523c037 to 14a11aa

Don't show "What's New" button in Help Page if no announcements.
Need to trim the value as an empty file is \n and would still invoke the modal.
Test several rounds of actual updates and builds cycles.


Update default video thumbnail to better fit dimensions

Changes

Adjust default no-js video thumbnail image dimensions to show the CFPB logo at all screensizes.

How to test this PR

Pull branch and run gulp clean && gulp build
Visit a video page, such as http://localhost:8000/consumer-tools/everyone-has-a-story/leah-repaying-student-loans/, http://localhost:8000/consumer-tools/reverse-mortgages/, http://localhost:8000/coronavirus/avoiding-scams/
Open the dev console settings and disable JavaScript.
Reload the page to show the default video image.
Resize the window and note that the image is cropped at certain sizes.

Screenshots
Before:

After:

Before:

After:

Also realizing that it seems kinda problematic that the preview image on a standalone video player is so much taller now. We want to ensure that stays at a 16:9 aspect ratio.

Can we crop the image down to just the logo and center it on the white background?

The way it's set up currently is that the bounding box adjusts to the image:

So if we wanted to do what you're describing, we'd need to convert the img to a div and set the image as a background.

So if we wanted to do what you're describing, we'd need to convert the img to a div and set the image as a background.

Well, it's already in a div, but this gives me two ideas:

Reduce the img down to just the logo with no padding, as suggested in my previous comment, then change the background color of div.o-video-player_image-container to white and center the image vertically (it's already being centered horizontally when it's cropped on the left and right). I don't think the current black background is ever seen, except for perhaps milliseconds during loading?
Just make it the background image of div.o-video-player_image-container and have the preview image from YouTube load in on top of it.

Which do you think would be preferable?

A couple minor suggestions, but something else happened when I tried to test this locally: I couldn't run gulp build successfully because some JS in PFC was looking for jQuery, which is presumably because it was removed in #6314. I'm not sure why builds aren't failing everywhere. Ah, the mysteries of Node module caching!

Yikes! Sorry for the inconvenience. This is fixed in main now though, thanks to https://github.com/cfpb/consumerfinance.gov/pull/6285. Updating to bring that change in here.


setData not setting properly

I have a cropped image's dimensions stored in my database, and sometimes it does not set the cropping properly on the built() function when either the width or height are set exactly to the rendered dimensions of the  cropper-canvas class.
I had to
$(this).cropper("setData", {x: x, y: y, height: height - 1, width: width - 1 });
to give the illusion that the cropper rendered correctly.
Any ideas why?

Please check if the stored data was still the same as the data get by getData method.

And I suggest you to apply the stored data with the data option:
$().cropper({
  data: storedData
});

the stored data is 1 higher than getData because it is stored as a integer in the database after rounding off. Could we have an option to set the crop to max instead of failing if the values inputted are larger than the getData size?

I tried using

$().cropper({
data: storedData
});

like you suggested and it didnt work, but the old method does.

For integer values, you can get the data like this: var storedData = $().cropper('getData', true).

$().cropper({
  data: storedData
});

is a shortcut of
$().cropper({
  built: function() {
    $(this).cropper('setData', storedData)
  }
});

when storedData.width is larger than $().cropper('getData', true).width, the cropper resets. Is this intended?

Sorry, I don't really understand that...

I had an image with a height of something like<PHONE_NUMBER>px after cropping to a ratio (The user uploaded a portrait image while we needed a landscape one). I stored it in the database as an integer after rounding, which resulted in a height of 228px.
So when I attempted to set the cropper with
$().cropper({
  data: { x: x, y: y, height: 228px, width: width }
});

It does not work. I had to set with  height:<PHONE_NUMBER>px  obtained from getData!
Hope this helps

Sorry, I can't reproduce this case, can you provide a demo?

I'm still having this issue. I'm using 2.3.0 of Cropper. Anyone got a solution?

Hello @fengyuanchen !
Had same bug, but can't reproduce at jsfiddle :/
Here is code https://jsfiddle.net/39tqomwp/ - it seems fine, but read my comments.
And here is how it seems at my local demo http://imgur.com/7kPgtYM
Crop area get's centered because cropper thinks height and width are 1199.9999999999998px, not 1200. IDK why that happens only at my local demo.


feat(workflow): remove pre-installed android sdk to free up disk space

What this PR does / why we need it:
github action always fails because the disk is not enough
this pr removed Android SDKs and free up 14GB of space
There is actually more useless pre-installed software, such as .NET SDKs. But at present, the space is very enough after removing the android SDKs.

References：
Ubuntu 22.04 github runner image
Maximize available disk space for build tasks

ci results, see https://github.com/setcy/cubefs/actions/runs/6376641994/job/17303961442


Retire ProcessUserdefinitions

Step 2 of allowing user defined types effort .
Retires UserDefinitions.ProcessUserdefinitions as it creates a tight coupling between Parse and processing of all different kinds of Userdefinitions.
We and our tests assume that client uses this method for processing, hence fixing all the tests as we will not use this moving forward.
Moving AllowAttributes transformation to Parse as it is a transformation of ParseResult and returns a ParseResult . Ideally this could be a transformation on NamedFormula ParseResult .
This will be followed with

Introduce NamedTypes, LookupType in INameResolver but support only Primitives. Remove PrimitiveTypeSymbolTable usage , Require INameResolver to create UDFs.
Introduce parsing and adding user defined NamedTypes.
Optimize type graph to update incremental.

✅ No public API change.

    internal void TestFormulasParseRoundtrip(string script)

Not part of your changes, but this is only called inside this class, consider changing to private

Refers to: src/tests/Microsoft.PowerFx.Core.Tests/ParseTests.cs:822 in 88915d3. [](commit_id = 88915d3663498f4a7e801f89442ef006943f402b, deletion_comment = False)

✅ No public API change.

✅ No public API change.

✅ No public API change.


ssr false with +layout.server file cause loop page refresh on 404 (#6854 recurred)

Describe the bug
Same issue as #6854 is happening with @sveltejs/kit 1.27.6 or later.
It does not happen in @sveltejs/kit 1.27.5 or earlier.
Create a +layout.server.js file when SSR is false cause loop refresh of the page.
Reproduction
pnpm create svelte@latest my-app
cd my-app
pnpm install
pnpm upgrade

Create the following files:
/src/routes/+layout.js

export const ssr = false;

/src/routes/+layout.server.js (empty)

pnpm run dev

Now when navigating on a non-existent URL the page keeps refreshing indefinitely.
Logs
No response
System Info
System:
    OS: Linux 5.15 Ubuntu 22.04.3 LTS 22.04.3 LTS (Jammy Jellyfish)
    CPU: (12) x64 11th Gen Intel(R) Core(TM) i5-11400 @ 2.60GHz
    Memory: 9.40 GB / 15.42 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 20.8.0 - /usr/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 10.1.0 - /usr/bin/npm
    pnpm: 8.6.10 - /usr/bin/pnpm
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.0.0
    @sveltejs/kit: 1.27.5 => 1.27.5
    svelte: ^4.2.7 => 4.2.7
    vite: ^4.4.2 => 4.4.2

Severity
annoyance
Additional Information
No response

+1, exactly same issue. Happening in @sveltejs/kit 1.27.4 and 1.27.6, but not 1.27.5.

+1

Also happens in today's SvelteKit 2, can't upgrade :(


Image references in Markdown behave inconsistently

Hi! As per discussion in #252, this is a quick description of an issue I just ran into.
Scenario:
I am using middleman-blog with the following config:
activate :blog do |blog|
  blog.prefix = 'blog'
  blog.sources = 'articles/{year}/{year}-{month}-{day}-{title}.html'
  blog.taglink = 'tags/{tag}.html'
  blog.layout = :article
  blog.summary_separator = /\-\-\-\s*READMORE/
  blog.default_extension = '.md'
  blog.tag_template = 'blog/tag.html'
  blog.calendar_template = 'blog/calendar.html'
  blog.paginate = true
end

I am referring to images stored alongside blog posts as outlined here, so, for instance:
![my nifty image](2015-08-13-my-nifty-article/image.png)

This works on the article page, assuming I view the article page first in the preview server. It does not work on the main blog index at source/blog/index.html.erb, however. If I access the index first, in fact, the cache will result in a non-working image reference when visiting the article page afterwards.
Changing the reference to:
![my nifty image](articles/2015/2015-08-13-my-nifty-article/image.png)

will, as expected, cause the reverse: a working image at source/blog/index.html.erb and a broken one on the article page.
As of right now, the only workaround I have found is to refer to the absolute source path:
![my nifty image](/blog/articles/2015/2015-08-13-my-nifty-article/image.png)

Per @tdreyno, the suspected cause is that "blog 'moves' the image assets along to the new article path, but images references in markdown don't point to that new location."
Thanks so much for looking into this!

I am experiencing something like this. I am using middleman (4.1.10) and middleman-blog (4.0.1). Was there any fix for this?

@ernie Are you able to Create a PR for some Features that will test this issue. We can then start to look at a fix as it seems an issue still in the latest release. I personally have not used the relative images.

@iwarner I'm sorry, I've long since left the company where I was using Middleman, so this issue no longer affects me.


several supporting companies are missing from the map on the SCS website

This a follow-up of #756.

identify all missing supporting companies

AOV IT.services
arctodix
Daiteap
JH-Computers
Proventa
caleUp Technologies
StackXperts

fetch the logos and add information by using data of the websites
create PRs for these comapnies

[x] AOV IT.services
[x] arctodix
[x] Daiteap
[x] JH-Computers
[x] Proventa
[x] ScaleUp Technologies
[x] StackXperts

https://github.com/SovereignCloudStack/website/pull/770

Created PRs with a small script and merged the changes to be previewed at
https://staging.scs.community/de/


Tighten the version of Node that is valid

Our Heroku deployments were complaining about our potentially dangerous version specification for the acceptable Node.js engines as it is allowing for experimental versions rather than only stable/LTS versions.

This is causing deployment failures so I'm going to merge it now. 😅


First H2 Iteration

Hi Flavio,
please take a look. It seems to run the tests fine but hasn't been further tested. Please note that I put the schema in quill-jdbc/src/test/resources so that I only have to rebuild this package in case of changes and also because I think it's jdbc-test related. Also, I can easily load it via the classpath for an in-memory instance of H2.
Jan

Current coverage is 99.63%

Merging #48 into master will increase coverage by +0.01% as of c432cae

Powered by Codecov. Updated on successful CI builds.

It's looking great! Could you also review the SqlIdiom to check if there are other things that could be different in h2? We don't have integration tests for all sql features.

Thanks for the feedback. I'll get to it asap.

@janheise Any news on this? I'm planning to cut a release soon and this PR seems almost ready, it'd be nice to include it.

Hi Flavio,
would love to do it, but currently I'm swamped by work. (You catch me
doing work on Sunday morning...)
I'll see what I can do next week.
Jan
On 17.01.2016 10:42, Flavio W. Brasil wrote:

@janheise https://github.com/janheise Any news on this? I'm planning
to cut a release soon and this PR seems almost ready, it'd be nice to
include it.
—
Reply to this email directly or view it on GitHub
https://github.com/getquill/quill/pull/48#issuecomment-172306298.

@janheise no worries at all! Thanks for the feedback and good luck! :)

Would someone be interested in continuing the work on this branch? It's open for too long, it'd be sad to have to close this.
cc/ @jilen @lvicentesanchez @gustavoamigo @godenji

I will do it, I always miss proper H2 support in other libraries and this seems almost ready.

I have created a local branch from this PR, as it's not possible to push my changes to this PR I will create one as soon as it's ready.

Ok, I'm closing this one for now.


Add --bundle flag to sign-blob and verify-blob

Add in --bundle flag to cosign sign-blob and cosign verify-blob. The bundle stores everything required to verify a blob in a file, so now you can do something like this:
cosign sign-blob --bundle bundle.sig <blob>

cosign verify-blob --bundle bundle.sig <blob>

The bundle is basically just JSON with the Signature, Cert, and RekorBundle included.
Some thoughts I had, which might be future work:

For now I put everything behind the --bundle flag, but later we might want sign-blob to print out the entire bundle instead of just the signature by default
Right now other flags don't effect the output of --bundle, but later we might want certain flags to work together (e.g. --b64)
Since we already have the concept of a "rekor bundle" maybe we should call this something else?

fixes #1193
Add --bundle flag to sign-blob and verify-blob

For https://github.com/sigstore/cosign/pull/1294/, we're going to include a TUF timestamp in the OCI signature. Will this automatically pick this up, or will we need to append the timestamp to the bundle?

For now I put everything behind the --bundle flag, but later we might want sign-blob to print out the entire bundle instead of just the signature by default

I'd be fine adding it by default now - this is only relevant for the COSIGN_EXPERIMENTAL sign-blob workflow right?

@haydentherapper I think it'll need to be added in, I can update that!
@dlorenc it should work for all workflows right now (for the regular workflow it'll just store the signature in the file and nothing else). Should we only do it for experimental right now?


Initial view history implementation

Created a basic viewed posting history feature, added on the right side below the job counter.
I'm not very well versed in ruby or rails but I saw this project on hacktoberfest and thought it looked neat, so if there are problems in my implementation please let me know.

Wow @tripph this is a great idea. Thanks for contributing and happy hacktoberfest!


Ability to set a maximum usage per day/month per user

Is your feature request related to a problem? Please describe.
No, just a feature request.
Describe the solution you'd like
Since I share open-webui with family & friends, it would be nice if we could set a maximum token (or message) limit per day and/or month, per user, and model, so they won't use up all my credits if they're not careful, especially because I'm using the LLMs over an API and don't use them locally.
Describe alternatives you've considered
Right now, there's no alternative approach to limit this, not even globally.
Additional context
-

Closing in favour of #1067


Suggestion: Map enhancements - boat location and travel speed

Two suggestions for the map...
First: It would be amazing if you could change the map via settings to a zone with oceans (BB, TD, Erud's, etc) and then see the location of the boat.   Or show the boat ETAs in applicable zones.
Second: A simple velocity calculation (units/second) of travel speed.  It could be shown in one of the empty corners of the map.  It would be fun to be able to compare travel speeds between jboots, sow, bard, etc.
Edit: subject from enchantments to enhancements

I don't know that I can do the first one, unfortunately, as that would require knowing server-side information.
The second one could be done though. I'll look into it!


can not find db schema.

Hi Emma,
I wanted to express my gratitude for the incredible Tech-School repository. As someone who is new to Tailwind, I find it immensely helpful. However, I encountered an issue while trying to utilize this repository for reference. It seems that the database schema or the exported database files are missing. If it's possible for you to add them, it would be greatly appreciated. Thank you once again for your contribution.
Best regards, JC

Hi JC,
Go through the README under installation no. 5 Set up your database - Schema you will find the schema.

thanks a lot


most AD verification experiments still use CPP-flag ECCO_CTRL_DEPRECATED

I suggest to change this for

[ ] global_ocean.cs32x15
[ ] isomip
[ ] obcs_ctrl
[ ] offline_exf_seaice
[ ] tutorial_global_oce_optim

to test the generic control variable mechanism (ALLOW_GEN*_CONTROL). Any additional suggestions?

Would be good to try these 5 ones. I noticed hs94.1x64x5 is already not using this CPP option, which is good, but it's also a very very
simple set-up.

@jm-c I have started with offline_exf_seaice, but I am not getting anywhere with this. First I replaced ECCO_CPPOPTIONS.h, which required many additional 'include AUTODIFF_OPTIONS.h' in thsice code. With those changes, I can reproduce results, but then switching to genarr3d/gentim2d is really problematic and the gradient checks behave differently (they are good, where they are non-zero, but I get 2 zero gradients out of 4.
In order to make some progress, I could create a draft PR with this, so that we can work on this together. What to do you think?

Removing ECCO_CCPOPTIONS.h from this experiment is already a good thing.
Otherwise, a draft PR would be good. You could attach a label "Work-in-progress" to it.

I am no longer sure if tutorial_global_oce_optim is a good experiment for the switch, because the only control variable is ALLOW_HFLUX_CONTROL, which is totally unknown to the main code and many, but not all relevant declarations, code changes, etc are done in local files (FFIELDS.h, ini_ffields.F, external_forcing_surf.F, ...). To me this is more like an example of how to "hack" the code for your favourite control variable. On the other hand, many additional code pieces are in the main code (ctrl_init.F, ctrl_map_forcing.F ctrl_pack/unpack.F, grdchk_getadxx/setxx.F, ini_ffields.F, ctrl.h, ctrl_weights.h, checkpoint_*.h). Either we clean this up entirely (move all specific code to the main code) and then switch to GENARR2D for HFLUXM, or we leave it as it is. What do you think?

My thought it that we could wait for me to finish the new coarse global tutorial, and redo this adjoint tutorial using latest/best simple approach from here. If working on the existing seems "spending good hours on bad" I'd rather have people think about how a new tutorial should function to introduce basic capabilities and functionality. (when I converted this old tutorial into rst, I recall thinking if I needed this tutorial to learn how to setup/run this, I'm screwed... :) )

OK, I'll leave tutorial_global_oce_optim alone for now. The remaining 4 experiments are enough of a challenge.


use Threads to spilt frames simultaneously from 3 videos

currently 3 videos are split one after another , takes too long , if we can use threading and concurrently do the three tasks ,we can save alot of time

Solved


Patterns seem to be ignored on number field

I want the user to only be able to type in integers into a number field. If I set pattern=[0-9]* and preventInvalidInput=true, I can still type 46...1, which of course is not a valid integer and doesn't match the regex.

The number field is based on the native <input type="number">. Because it also allows you to input 46...1, Vaadin's number field has the same limitation

I see. Thanks for taking the time to explain.


IDA or Angr?

I want to run deepbindiff and have read some of your codes.
It seems deepbindiff leverages Angr to extract basic block information and generate CFG instead of IDA?

Hi, we have both the IDA pro version and the angr version. IDA pro is used in order to directly compare with BinDiff, which uses IDA pro as well. The one I uploaded uses Angr indeed. Thanks.


Update python-tests README

Note: only updating readme, no need for CI builds

commit was cherry-picked


Added support for configurable Filepond table name

I wanted a table called 'uploads' instead of 'fileponds'. With this you can configure the table name used in Filepond model in config/filepond.php.

@dmalta can you update the FilepondServiceProvider to migrate with the table name from the config. Also please open another pull request as this got messed up on my end when I tried to revert.

Hi @rahulhaque , I see you merged and then decided to revert it. Found any issues?
I did think about using the table name from config in the migration, but then I considered it would make the migration flow too vulnerable to accidental changes in the configuration. Even different developers with different.env would get incompatible results. I realized the user would need to run a migration anyway, so would be just natural to change it there and their decision would be kept in the app repository.

Hello @dmalta, welcome to my little package and thanks for the pull request. Yes, I merged it and thought of releasing another version for it. You wanted to change the table name for upload tracking. But, I was concerned about the use cases and consistency. For new installs, if someone changes the table name before migration, it won't be reflected in the database making it inconsistent. It will be more confusing for a model name Filepond to have table name something else rather than fileponds breaking the convention. For the use cases, please explain any where you would like to (or you're forced to) change the table name after migration.

Hi @rahulhaque , thanks for considering. This feature is actually very important to me. In my current project a large team cooperates and we have conventions for table naming. In a broader sense, I personally think "fileponds" is very implementation specific. There is nothing wrong with that, but I don't like to mention client side component names in the database. I don't think the Laravel model having a different table name is a big deal. Specially because the it's a component model, not under App/Models.

By the way, if you allow me a feedback, I love your overall solution design, but I think having two different classes named Filepond is confusing. In my code I had to name variables differently because it was never clear what is a Filepond model and a Filepond service.

Hello @dmalta, feedback are always welcome. There's always opportunity to see things from another perspective. However, if I allow you to change table name after migration, it will raise some new test cases for me and make future development complex. I agree with you about the service and model name being same. But that's why php namespacing is there and laravel has a tendency to use same name for different classes if require. Even I had to name variable my own model at an early stage of developing this package. You can use DB::table('fileponds') to avoid that. If it feels too odd to have fileponds table with client  side naming, please bear with it. I am really sorry that I cannot merge this at the moment. I hope you'll understand. :) If you allow me I will close the conversation right after I hear from you. Happy coding.

That's alright, no problem. I will keep using my own forked version for now. That's one of the beauties of FOSS. ;-) I really appreciate your work here. Thank you.

@dmalta I assure you I will keep your use case in mind. Maybe one day I will face the same scenario as you. It was nice having the discussion btw. Thank you.

Hello @dmalta, hope you're doing well. I've just added support for Filepond model extending through config file. This will allow you to set a table name of your choice from custom model with protected $table = 'table_name'. The discussion is available here #45. Hope this come in handy for you. Thanks.


Show Extension Properties based on a result of a function

I need a way to only show properties for paid users. I thought about adding a key called "visible" that receives a function name that will be called by vscode. If the result is true, then the prop is available.
In my case I will determine if the prop is available after issuing a request to my server to check if the user's license is still activate.
"configuration": {
      "title": "Extension",
      "properties": {
        "myProp": {
          "type": "boolean",
          "default": true,
          "description": "If checked, the form is displayed.",
          "visible": "functionNameToBeCalledToResolveTrueOrFalse"
        },
}

Workaround: I can allow anybody to toogle the properties on, and then verify or not if they are allowed to use or not that prop. But this creates more complexity to me, as I will need to keep checking in the server if that user is allowed to use that configuration.

Even if you were able to do that, what would stop the unlicensed user from simply adding the setting to settings.json directly? It seems to me you still need to do the check in your extension.

@gjsjohnmurray good point haha
I just don't want users to configure things they would not be allowed to use. Just to now keep asking "Why this is not working If I toogled in on"

@AllanOricil maybe add "(requires license)" to the end of the description of each setting it applies to?

@gjsjohnmurray it is a solution. But do you think it is the best way of implementing it?

Forgetting the proposed use-case, I think adding an optional when clause using the existing context infrastructure could be very interesting for extensions to control setting visibility (in the UI).

Related to #70589

Please, don't use the word "when". It is so weird. If this feature gets enough votes, ask the community about the their preference. My opinion is that is much more clear to use "visible"


how to use tmpfs in docker

Hi !
I found that Fuzz is slow when running many dockers at the same time to Fuzz, but the fuzzing speed is normal when only run one docker , so I wonder if it is disk performance causing such a difference?(Here fuzzer is afl ,not aflnet)
I tried to execute  mount -t tmpfs -o size=4096M tmpfs <dir> inside docker, but the speed is still slow, I wonder if it is the tmpfs obtained by mount inside docker container, not the real server memory.
So, how to solve this problem?

As an example, when starting only one docker, the speed of afl is 1500/sec, but when starting 10 dockers, the speed of afl drops to 100/sec.
Also, I made the docker by referring to the configuration of profuzzbench


0.5.0rc3 upgrade doesn't use most logical/recent b2d ISO

I had docker toolbox 1.9 rc1 installed on my machine, and I used the included docker-machine to create some hosts.  This went as expected and the hosts were created using the b2d 1.9 rc1 ISO.
I then upgraded toolbox to 1.9 rc2 (which upgraded b2d to 1.9 rc2 and machine to 0.5.0 rc3).  When I try upgrading the same host, docker-machine doesn't use the 1.9 rc2 ISO that ships with toolbox, and instead goes and downloads 1.8.3 ISO and "upgrades" my machine to that.
pvn@dewgong /Users/pvn> file .docker/machine/cache/boot2docker.iso
.docker/machine/cache/boot2docker.iso: ISO 9660 CD-ROM filesystem data 'Boot2Docker-v1.9.0-rc2         ' (bootable)
pvn@dewgong /Users/pvn> eval "$(docker-machine env test3)"
pvn@dewgong /Users/pvn> docker version
Client:
Version:      1.9.0-rc2
API version:  1.21
Go version:   go1.4.3
Git commit:   60d36f7
Built:        Fri Oct 23 00:20:59 UTC 2015
OS/Arch:      darwin/amd64
Server:
Version:      1.9.0-rc1
API version:  1.21
Go version:   go1.4.3
Git commit:   9291a0e
Built:        Wed Oct 14 03:29:07 UTC 2015
OS/Arch:      linux/amd64
pvn@dewgong /Users/pvn> docker-machine upgrade test3
Stopping machine to do the upgrade...
Upgrading machine test3...
Downloading https://github.com/boot2docker/boot2docker/releases/download/v1.8.3/boot2docker.iso to /Users/pvn/.docker/machine/cache/boot2docker.iso...
Starting machine back up...
pvn@dewgong /Users/pvn> docker version
Client:
Version:      1.9.0-rc2
API version:  1.21
Go version:   go1.4.3
Git commit:   60d36f7
Built:        Fri Oct 23 00:20:59 UTC 2015
OS/Arch:      darwin/amd64
Error response from daemon: client is newer than server (client API version: 1.21, server API version: 1.20)
pvn@dewgong /Users/pvn> docker-machine -v
docker-machine version 0.5.0-rc3 (a1e610b)
pvn@dewgong /Users/pvn> file .docker/machine/cache/boot2docker.iso
.docker/machine/cache/boot2docker.iso: ISO 9660 CD-ROM filesystem data 'Boot2Docker-v1.8.3             ' (bootable)

This is particularly weird because "docker-machine create" doesn't have any problem using the 1.9.0-rc2 ISO.  It seems that at the very least both operations should have consistent behavior here.

@tianon Do you think it would make sense to start doing the boot2docker RCs at boot2docker/boot2docker and adding some kind of --release-candidate flag to docker-machine upgrade to allow upgrading to a release candidate?

How about making sure that boot2docker rc is available, documented and compatible with *-boot2docker-url? That way we can create a machine with the rc directly.

They've been announced in the same places Docker is; they're currently at
https://github.com/tianon/boot2docker-legacy/releases and are usable with
"boot2docker-url" CLI flag.
I'm not opposed to uploading them to boot2docker/boot2docker, assuming that
we've had sufficient releases of docker-machine that filter out pre-release
uploads so that we can be reasonably assured that folks with older releases
aren't getting the RCs by mistake.  That filtering code's only been in one
major release (0.4) so far, right?

I'm not sure such filtering code exists at all for us today, so I'm not wanting to rush into anything.  Just considering the options at hand.  Personally I'm pretty OK with being able to create brand new VMs with the RC ISOs, but the expectations around upgrade seem to confuse some users.

Ah, that filtering code was introduced with the b2d-ng code, and then subsequently reverted also.  So currently, if I upload any RCs to boot2docker/boot2docker, regardless of that "pre-release" flag, they'll be upgraded to on docker-machine upgrade, which IMO is surprising behavior and is why I haven't done so.  I'm definitely 100% +1 to getting that filtering code in place and letting it bake for one or two major Machine releases before we switch to uploading RCs to the main repo.

Yeah, cool, I think that's what I'd like to do as well.

I'm not sure what other users expect, but my personal expectation is that at a given point in time, if I "docker-machine create" a new machine or if I "docker-machine upgrade" an existing one, both of those operations conclude by leaving me with a machine with the same version of engine installed.
Also, even if you guys decide that the default upgrade behavior is to never use release candidate ISOs without some explicit --use-release-candidate flag (or similar), that's fine, but "upgrading" 1.9rc2 to 1.8.3 shouldn't happen without some sort of "are you sure you want to do this?" step.

@nathanleclaire @tianon I have a similar issue: docker-machine upgrade uses whatever --boot2docker-url was given at create time, and I can't override it. So for the RC, I used file:///... and when I want to upgrade to 1.9.0 it still looks for my file:///... one when I'd like it to fetch the latest.
Do you want me to open a new issue?


[🐞] usePopover with Cloudflare adapter fails to respond/causes qwik error 20

Which package is affected?
Headless Kit
Describe the bug
I tried deploying a small Qwik website with a manual usePopover() in it, and it worked locally; but when deploying to Cloudflare Pages, I got this error on the production logs:
  `Calling a 'use*()' method outside 'component$(() => { HERE })' is not allowed. 'use*()' methods provide hooks to the 'component$' state and lifecycle, ie 'use' hooks can only be called synchronously within the 'component$' function or another 'use' method.\nSee https://qwik.dev/docs/components/tasks/#use-method-rules`

From the stack trace looks like it's something inside of the usePopover() hook. That said I am pretty new to Qwik so maybe I'm holding it wrong.
EDIT
I tried to make a minimal reproduction, but then instead now I'm seeing that the example nearly straight copy-pasted from the usePopover() example on the Qwik UI website just doesn't seem to call the handler at all (but something outside of the Popover.Root works fine):
Repro: https://github.com/osdiab/repro-qwik-ui-popover-cloudflare-fail
Result on Cloudflare Pages: https://5bc62893.repro-qwik-ui-popover-cloudflare-fail.pages.dev

first button should toggle a popover and log to console, it doesn't
second button logs to console outside of Popover root, it's fine

Reproduction
https://github.com/osdiab/personal-website/blob/93179b5ae60e1c23fc821f75541b5b4a7778e332/apps/web-app/src/components/tooltip.tsx#L48
Steps to reproduce
Locally no error, but when I deployed this on Cloudflare Pages then try to access the page, it returns a 500 and I get the error.

make a qwik app
add cloudflare adapter
make a component that uses usePopover() in it
see it works locally
deploy to Cloudflare
set NODE_VERSION env var
set node_compat compat flag
see that it doesn't respond/in the case of my personal website, it errors

I tried to remove all the other use*, event handlers, etc from my personal website Tooltip example, but it crashes until I comment out the usePopover() altogether.
System Info
System:
    OS: macOS 14.5
    CPU: (10) arm64 Apple M1 Max
    Memory: 292.73 MB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.7.3 - ~/.asdf/installs/nodejs/21.7.3/bin/node
    npm: 10.5.0 - ~/.asdf/plugins/nodejs/shims/npm
    pnpm: 9.0.4 - ~/.asdf/shims/pnpm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 125.0.6422.142
    Edge: 125.0.2535.92
    Safari: 17.5
  npmPackages:
    @builder.io/qwik: ^1.5.5 => 1.5.5
    @builder.io/qwik-city: ^1.5.5 => 1.5.5
    @builder.io/vite-plugin-macro: ~0.0.7 => 0.0.7
    @qwik-ui/headless: ^0.4.4 => 0.4.4
    typescript: 5.4.5 => 5.4.5
    undici: * => 6.13.0
    vite: ^5.2.13 => 5.2.13

Additional Information
Error: Code(20) https://github.com/QwikDev/qwik/blob/main/packages/qwik/src/core/error/error.ts#L28
    at createAndLogError (functionsWorker-0.5285299984186582.js:4936:52)
    at logErrorAndStop (functionsWorker-0.5285299984186582.js:4927:55)
    at qError (functionsWorker-0.5285299984186582.js:4968:10)
    at useInvokeContext (functionsWorker-0.5285299984186582.js:6327:11)
    at useSequentialScope (functionsWorker-0.5285299984186582.js:5260:16)
    at useConstant (functionsWorker-0.5285299984186582.js:6038:24)
    at useSignal (functionsWorker-0.5285299984186582.js:6041:35)
    at usePopover (functionsWorker-0.5285299984186582.js:11174:32)
    at AsyncFunction.S1 [as resolved] (functionsWorker-0.5285299984186582.js:12808:50)
    at AsyncFunction.ui (functionsWorker-0.5285299984186582.js:2333:19)

same thing seems to happen on vercel edge

Working on this @osdiab 🫡

Working on this @osdiab 🫡

The Jack Sheltons are on it @osdiab 🫡

@osdiab try @builder.io/qwik dev and see if this fixes your problem. Seems to work for me

@thejackshelton sorry I don’t think I understand what you mean - do you mean the latest dev build of qwik/qwik-city? Thanks!

@thejackshelton sorry I don’t think I understand what you mean - do you mean the latest dev build of qwik/qwik-city? Thanks!

Try Qwik 1.6, as I think this should fix the issue.

Confirmed that it did make the repro repo work, but my personal one is still not OK; debugging further to see if I can figure something out. Thanks,

Qwik 1.7 made this go away.


update bench.py path in documentation

The old URL: https://github.com/giampaolo/pyftpdlib/blob/master/test/bench.py gives 404.

Merged, thanks.


[sil-opaque-values] More SILGen support.

The standard library now builds with -enable-sil-opaque-values.

@swift-ci smoke test and merge.

@gottesmm oops, I mean that standard library can be build with -enable-sil-opaque-values. That's not what we're actually doing.


Export as new table DDL issue with SELECT NULL, MySQL

System information:

Win 10
<IP_ADDRESS>103211229
Additional extensions

Connection specification:

MySQL 8
Driver name
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:
Select NULL as "abc" generates DDL of CREATE.. "abc VARCHAR NULL," which won't parse. Need VARCHAR(n).
Whilst that's understandable, it is not clear to the user where the issue is. Suggest default to VARCHAR(10).
Include any warning/errors/backtraces from the logs

Please write steps to reproduce and full query you use.

select 10 'id', null 'abc';
Executue > Export From Query > Database
Mapping = Create, generates DDL of:

CREATE TABLE gos.fred (
id BIGINT NOT NULL,
abc NULL NULL
)
ENGINE=InnoDB
DEFAULT CHARSET=utf8mb4
COLLATE=utf8mb4_0900_ai_ci;

The DDL handling NULL value is not valid MySQL, generating:

Error occurred during Apply schema changes
Reason:
SQL Error [1064] [42000]: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NULL NULL

)
I was using <IP_ADDRESS>104042040 for this query.

Thank you for the report.

Now we inference VARCHAR type in the situation when we transfer from MySQL to MySQL. The length still needs to be added by hand.

verified


Fix formatting (NBitcoin.Altcoins)

ReYahihebSharper

this one is tricky for me to review. (can't just check it is only whitespaces) and tests does not pass.

@nopara73 lol but I really like to see the code very clean :p.
@NicolasDorier I agree.
Should I break it into smaller PRs (6 or 7 files per PR) but they might still be big?
Or to avoid the review you can do it yourself. If you are using Visual Studio 2019, use Alt + Enter (Quick Actions)  on a line containing for ex if( and choose Fix formatting and then Fix all occurrences in: Solution.

Closing this one for inactivity. I don't think we have to format, we can do as we go. However, if we do, you can break in smaller pieces.


GoogleMap plugin: Moving HTML before JavaScript so that  container for google map is loaded before being manipulated

This fixes an existing issue

If you're using sekizai correctly and put your {% render_block "js" %} at the bottom of the page, this already happens. Not using sekizai here is not an option.


⚠ Bofrost.at has degraded performance

In a63ff84, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2089 ms

Resolved: Bofrost.at performance has improved in 3127228.


[BUG] Unable to Connect to Postgres Database

Hi Perseus Team,
I am seemingly unable to scan a postgresql database instance from within Perseus and I am not sure why this is failing.
Attached is a video of me attempting a connection but it fails:
https://user-images.githubusercontent.com/29561456/197873059-7cb46384-e2c2-4b1f-ba2a-a5925f7eb647.mp4
I followed the wiki and am unsure as to what happened -- this feels like a bug.
Thanks!

@TheCedarPrince Try to add application IP ranges in pg_hba.conf file and restarted the Postgres instance.

@TheCedarPrince
You tried connect from one container (White-Rabbit) to another (Shared-db).
So in this case localhost would be host inside of container, and there are no any databases.
To connect to shareddb container you should change localhost to shareddb.

Hey @bradanton and @chMatvey , the solution of changing localhost to shareddb worked! However, this doesn't feel like a great solution. What would be a better solution to test or interact with Perseus?

Hey @bradanton and @chMatvey , the solution of changing localhost to shareddb worked! However, this doesn't feel like a great solution. What would be a better solution to test or interact with Perseus?

as @chMatvey said, when using 'localhost', a container with White-Rabbit  try to access 'inside itself', but there is no PostgreSQL running in this container at <IP_ADDRESS>:5432. thus, in order to get into the PostgreSQL container from the White-Rabbit container, you need to call container by name (shareddb), or use the IP-address of your CRI (for example, Docker). it is not difficult to find out the address for Docker (on Linux, run "ifconfig |grep -A 7 docker0 |grep inet |tr -s ' ' |cut -d ' ' -f 3" or "ip a |grep docker0 |grep inet |tr -s ' ' |cut -d ' ' -f 3" in your terminal and you will see something like <IP_ADDRESS>) or find docker-compose network address (docker network inspect perseus_default |grep -i gateway).
in addition, you can use the IP-address of your Ethernet or WiFi connection (if it has not dynamic addressing, otherwise it will be less convenient), since PostgreSQL occupies a port at the address <IP_ADDRESS> on your host system.

@TheCedarPrince I hope that the issue is fixed. If you have concerns related to this item or encounter any issues, you can raise another item or reopen it.


Recommended/preferred vs. default clean-targets

Preview
What are you changing in this pull request and why?
Often, we make the preferred / recommended option be the default option. Most likely for backwards-compatibity, the default differs from the recommended.
It would be nice to call this out a little more explicitly.
This PR represents my quick attempt at this -- very, very open to totally different wording here.
Checklist

[x] Review the Content style guide and About versioning so my content adheres to these guidelines.
[x] If appropriate, open an issue to hyperlink to https://docs.getdbt.com/reference/project-configs/clean-targets within https://docs.getdbt.com/reference/commands/clean.

https://github.com/dbt-labs/docs.getdbt.com/pull/3598

hey @dbeatty10 do you want me to merge this pr for you? or are you wanting to double check this?

Thanks for the nudge @mirnawong1 ! I just enabled auto-merge right now.


Simplify resolving type parameters

Using Guava's TypeToken simplifies things and supports full
resolution.

Follow up to #8620.


Add images to about page

Just added some of the images to the 'public' subdirectory. Add them to the about page.

Hello @nlebovits is there a Figma design I can look at, and what images do you want added to the page?

https://www.figma.com/file/NAFkgq34abW6uJ0R7PW24T/Prototype---Vacant-Properties?type=design&node-id=38%3A9193&mode=design&t=Zk6Z0xT7hBV6ak9q-1
Images are in the public directory. It's the three .png files.


Return error if invalid input detected in transport layer (Send/Recv)

Return error if invalid input detected in transport layer
Description
Check the input at *FreeRTOS_send/recv function and return negative value if input is invalid.
Test Steps

Open Windows simulator to test different transport layers.
Send/Receive with valid/invalid inputs
Assert happened when testing invalid inputs.
using_mbedtls_pcks11: corePKCS11_MQTT_Mutual_Auth_Windows_Simulator
using_mbedtls: FreeRTOS_Cellular_Interface_Windows_Simulator
using_plaintext: coreMQTT_Windows_Simulator/MQTT_Plain_Text
using_wolfSSL: coreMQTT_Windows_Simulator/MQTT_Mutual_Auth_wolfSSL

Related Issue
Refer to API reference
Openssl_Recv should return negative value when byteToRecv is 0.
Openssl_Send should return negative value when byteToSend is 0.
TransportRecv_t:
If no data is available on the network to read and no error has occurred, zero MUST be the return value. A zero return value SHOULD represent that the read operation can be retried by calling the API function. Zero MUST NOT be returned if a network disconnection has occurred.
TransportSend_t:
If no data is transmitted over the network due to a full TX buffer and no network error has occurred, this MUST return zero as the return value. A zero return value SHOULD represent that the send operation can be retried by calling the API function. Zero MUST NOT be returned if a network disconnection has occurred.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run checks


Using 'builder()' factory method instead of constructor

Currently, we instantiate a builder by calling a constructor or a static method in a builder class:
Server server = new ServerBuilder()
        .foo()
        .bar()
        .build();

I wonder if it was a good idea or we need to reconsider this decision in favor of having builder() method:
Server server = Server.builder()
                      .foo()
                      .bar()
                      .build();

The pros of builder() are:

We can easily align at '.', which is better in terms of aesthetics.
We do not need to import ServerBuilder if we chain all.

I like the Server.builder() way

Let me make the proposed change.

builder() or newBuilder()? Protobuf uses newBuilder() and Guava uses builder(). Which one is better?

+1.001 for builder vs +1 for newBuilder :)

Just came back from Spain and it reads like 1001 vs 1 :rofl:

I'm working on this

The remaining builder classes that need migration:

ClientBuilder
DefaultClientBuilderParams
ServerListenerBuilder
HttpAuthServiceBuilder
SimpleCompositeServiceBuilder
SimpleCompositeRpcServiceBuilder
CorsPolicyBuilder
CorsServiceBuilder
DocServiceBuilder
HttpFileBuilder
HttpFileServiceBuilder
LoggingServiceBuilder
JettyServiceBuilder
ArmeriaRetrofitBuilder
KeyStoreCredentialResolverBuilder
SamlServiceProviderBuilder
TomcatServiceBuilder
ZooKeeperUpdatingListenerBuilder

It has been on progress since this monday. Apologize for for slow progress (__)

@4whomtbts It's good to be back! I think you need to know some changes in #2335.

Please make sure your current branch is up to date from the master branch. Lots of class which have HTTP keyword have been deprecated.
HttpAuthServiceBuilder and HttpFileServiceBuilder have been done, you may want to skip them.
This issue is scheduled to apply before release 1.0.0. Maybe in the middle of January. 😉

I'm looking forward to your next PR. Cheer up!

ClientBuilder
DefaultClientBuilderParams
ServerListenerBuilder
~HttpAuthServiceBuilder~
SimpleCompositeServiceBuilder
SimpleCompositeRpcServiceBuilder
CorsPolicyBuilder
CorsServiceBuilder
DocServiceBuilder
HttpFileBuilder
~HttpFileServiceBuilder~
LoggingServiceBuilder
JettyServiceBuilder
ArmeriaRetrofitBuilder
KeyStoreCredentialResolverBuilder
SamlServiceProviderBuilder
TomcatServiceBuilder
ZooKeeperUpdatingListenerBuilder

@4whomtbts It's good to be back! I think you need to know some changes in #2323.

Please make sure your current branch is up-to-date from the master branch. Lots of class which have HTTP keyword have been deprecated.
HttpAuthServiceBuilder and HttpFileServiceBuilder have been done, you may want to skip them.
This issue is scheduled to apply before release 1.0.0. Maybe in the middle of January. 😉

I'm looking forward to your next PR. Cheer up!

ClientBuilder
DefaultClientBuilderParams
ServerListenerBuilder
~HttpAuthServiceBuilder~
SimpleCompositeServiceBuilder
SimpleCompositeRpcServiceBuilder
CorsPolicyBuilder
CorsServiceBuilder
DocServiceBuilder
HttpFileBuilder
~HttpFileServiceBuilder~
LoggingServiceBuilder
JettyServiceBuilder
ArmeriaRetrofitBuilder
KeyStoreCredentialResolverBuilder
SamlServiceProviderBuilder
TomcatServiceBuilder
ZooKeeperUpdatingListenerBuilder

Yes. My local branch is currently up-to-date.
Thank you for fill me in!

Once #2352 is merged, these are probably the last:

ClientBuilder
DefaultClientBuilderParams
new SimpleCompositeService(...)
new SimpleCompositeRpcService(...)
new DocService()
new ArmeriaRetrofitBuilder(...)
KeyStoreCredentialResolverBuilder

They are somewhat trickier than others, so let me handle them by myself.

Need to replace contants with factory methods as well:

EventCount.ZERO
ClientCacheControl.*
ServerCacheControl.*
PrometheusMeterRegistries.defaultRegistry
AuthTokenExtractors.*
CorsConfig.DISABLED

Once #2352 is merged, these are probably the last:

ClientBuilder
DefaultClientBuilderParams
new SimpleCompositeService(...)
new SimpleCompositeRpcService(...)
new DocService()
new ArmeriaRetrofitBuilder(...)
KeyStoreCredentialResolverBuilder

They are somewhat trickier than others, so let me handle them by myself.

Ok.  I got it.


Release v0.1

:rocket: Hola! Welcome To The Release Preparation. Just sit back and relax while we prepare the release for you. We will Notify you here once the Release Process is complete.

Triggering Release Process with Type: minor

:rocket: Hola! Welcome To The Release Preparation. Just sit back and relax while we prepare the release for you. We will Notify you here once the Release Process is complete.

:rocket: Hola! Welcome To The Release Preparation. Just sit back and relax while we prepare the release for you. We will Notify you here once the Release Process is complete.

Triggering Release Process with Type: minor

Triggering Release Process with Type: minor

:rocket: Hola! Welcome To The Release Preparation. Just sit back and relax while we prepare the release for you. We will Notify you here once the Release Process is complete.

Triggering Release Process with Type: minor

Triggering Release Process with Type: minor

:rocket: The release process is successfully completed. No Action Required from user end. This ticket will be auto-closed. Please Re-Open the ticket In Case any Further Release is required.


Ember-Core: reimplement "combineArrays"

Within the parser of ember-core, rewrites the combineArrays to
something that avoids some work.

Not allocate, fill, and grow, an intermediaryArrayBuffer.
Not allocate an array, immediately discarded, that is a copy of the Chunk.
Maybe? avoid boxing brought by the use of a type-parametric API of ArrayBuffer, and deal directly with arrays of Byte.

Have we done anything to confirm this will improve performance?

We can run some of the benchmarks we have for that cross-language, and cross-stack, benchmarks. However, we have an intuition why it cannot be slower, and the code is not longer now (with the use of special methods).


Update contribute docs and script

closes #121
Fixes a couple issues in the build contribute script:

moved script file to fit directory organization of other scripts
cleans out previous generated docs when run
handles markdown to MDX comment conversion reliably

This PR also pulls in the latest updates from the p5 repo's contribute docs

build will be fixed by #124


Update level detecting

Update level detection from the Unity's deprecated OnLevelWasLoaded.
Use SceneManager.sceneLoaded delegate instead.

OnLevelWasLoaded is still supported on Unity 5.6, while SceneManager.sceneLoaded is not supported on 5.4.
Thus won't fix until really needed.


KDPM_2A and KEULER_A are not reproducible

GPU: MPS
VRAM: ~12gb (MBP M1 Pro 16gb)
CPU arch: ARM
OS: MacOs 13
Python: miniconda, 3.10.6
Branch: On branch main

Describe the bug
I run different samplers with the same seed. KDPM_2A and KEULER_A always have different results. KDPM_2A outputs is somewhat similar to each other (great stylization btw), EULER_A's is not. Is that ok? The rest are reproducible 1:1.
Examples:
KDPM_2A

KEULER_A

Others (klms, plms, etc)

@tildebyte, is this expected behavior?

This is expected, not every sampler looks the same

using the same seed will result in the same image

Yes, exactly. There are subtle differences between all of the samplers; the differences with the "ancestral" samplers are not-as-subtle (note that the last two rows are the "_a" samplers); indeed, one can see that the "_a" samplers are closer to each other than to all of the others:
*Note that this was taken from somewhere on reddit - not my work

And the results are reproducible. Using the same seed will result in the same image.

This is the issue as it's not the case when on a M1 Mac. When using KEULER_A or KDPM_2A there is no way to reproduce an image even when using the same configuration.
For example running dream> landscape --seed 1234 --sampler k_euler_a --steps 20 --cfg_scale 8 --iterations 1 --width 512 --height 512 three times in a row produces three different images:

Where as the other samplers reproduce the same image as expected, dream> landscape --seed 1234 --sampler k_lms --steps 20 --cfg_scale 8 --iterations 1 --width 512 --height 512:

I think this is the underlying issue - https://github.com/pytorch/pytorch/issues/84288

This is not fixed yet in Release candidate 1.14.3. Maybe we should create a pull request.

Recommended. If it's high enough priority, and isolated enough to not break anything else, you might be able to convince @lstein to make a hotfix release on top of 1.14.x

I think it's not high priority (the sampler still works) but if something to remember, as this it needs a fix to reproduce images.
Maybe after things settle down with the release we can do a PR.

Now that the release is out, it might be a good time to pick thing up from here.
There is also this https://github.com/lstein/stable-diffusion/discussions/507 for which a good starting point may be adding k_euler to img2img.


Fix 32 bit interger overflow handling

The current way that handleBigInt() works does not match how true 32bit integer overflow in CS code works when casting a large number to a 32bit integer.
This patch corrects this and removes the need for the BigInteger library.
You can see a "frustrating" example of this on XianjiTV's vod at https://www.twitch.tv/videos/921493868 around1 hour 5mins into the vod.
For reference, his Game ID was: 273414764 and the predictor said his Mine Chests were:

10 - Wind Spire
20 - Magnet Ring
50 - Combat Boots
60 - Wood Mallet
80 - Dark Boots
90 - Wicked Kris
110 - The Slammer

What he actually got in game, and what this patch corrects the predictor to show is:

10 - Wind Spire
20 - Elf Blade
50 - Pirate's Sword
60 - Burglar's Shank
80 - Dark Boots
90 - Obsidian Edge
110 - Steel Falchion

I think anyone with a seed that overflows a 32 bit signed integer, or in the case of mine chests, is larger than 4194303, they will "buffer overflow" and the predictor I believe will show the incorrect results for one or more mine chests.

I believe I've been hit by this bug because none of my geode predictions are correct, and they were on my last game save. My new game save ID is 301947353, which is higher than 4194303.

BigInteger.min.js is not required. This is my handleBigInt (num) version " return (num%<PHONE_NUMBER>)<<0; ".
There is another hard to find error. In cs-random.js, the number returned by InternalSample() will be greater than INT_ MAX or less than INT_ MIN。
Translated from Chinese:
BigInteger.min.js并不是必须的，我的handleBigInt(num)版本return (num %<PHONE_NUMBER>) << 0 ;
还有一个难以发现的错误在cs-random.js里，InternalSample()返回的数字会大于INT_MAX或小于INT_MIN。


Azure Functions logs / FunctionAppLogs table does not appear under LogManagement tables in Log Analytics Workspace.

The test example to reproduce this issue was generated from this Quickstart: Create a C# function in Azure from the command line documentation.
Additional diagnostic setting was added as described in Monitoring Azure Functions with Azure Monitor Logs documentation.
Azure Functions logs / FunctionAppLogs table does not appear under LogManagement tables in Log Analytics Workspace.
Log stream displays the data, but logs were not consolidated into Log Analytics Workspace.
2023-02-06T11:30:35Z   [Information]   C# HTTP trigger function processed a request.

How can I further troubleshooting it?

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

ID: 8962c9c8-f550-db2f-6573-0dea51802a6e
Version Independent ID: 6340d0ac-0f03-3484-1a6b-d4bb5b64d645
Content: Create a C# function from the command line - Azure Functions
Content Source: articles/azure-functions/create-first-function-cli-csharp.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

@sheeeng
Thanks for your feedback! We will investigate and update as appropriate.

@sheeeng
MicrosoftDocs Github issue is mainly related to the document issue. For troubleshooting related queries and issue discussions, I would recommend you to create a thread on the forums - Microsoft Q&A or Stack Overflow
Once you post your issue on forums, it will have visibility across the community which is a better suited audience for such types of issues.
I will go ahead and close this issue as this is troubleshooting issue. In case if you have any queries feel free to tag me in.