proposal: make it possible to catch failed memory allocations

There's currently no way to safely allocate memory in Go without running the risk of the process panicing. This makes it very difficult to have an application that automatically scales to fit the machine (or container) resources. Further, for an application to determine how much memory is available for allocation from the OS is non-portable and unreliable, so it's not like an application can wrap allocations inside a function that checks to see if they will fit. The guess it can make about available memory can be under or over the real value, leading to wasted resources or OOM panics.
I realise that running defer() code when a memory allocation has failed could in turn fail, since the recovery code will also need to allocation memory. However, the common case is probably that a large allocation failed, and there is room for small allocations needed for cleanup, so just allowing applications to catch OOM panics would probably help most of the time. If there is another memory allocation failure during recovery, kill the application.
A more complete solution would be to reserve a chunk of memory that is freed/made available during OOM recovery, which is re-reserved once recovery is complete. That would also allow effective recovery if a small memory allocation failed. As long as the recovery code uses less memory than the reserved size, this approach should be robust. The memory would be allocated with the normal internal mechanisms, so it wouldn't be "special". The OOM handling code would be the only place where a reference was kept.
This reservation could be done implicitly, but it's probably cleaner to require the application to enable this feature. That would ensure that applications that don't need OOM avoidance don't have to pay the price of the reserved memory. I suggest the following API:
func runtime.ReserveOOMBuffer(size uint64)
The OOM handler would drop the reference to the reserved memory, call runtime.GC() and then generate a normal panic() rather than panic+kill. The recovery code in the application would be expected to call runtime.ReserveOOMBuffer() again (probably after calling runtime.GC()).
A less attractive option is to add trymake() and tryappend() built-in functions, which return a value,error tuple and a tryinsert() built-in which inserts into a map and returns an error value. I like this less because there are many other ways in which memory is allocated, so one cannot catch them all. It also requires changing a large number of callsites. Nevertheless, it would be better than the current situation.

Previous discussion on mailing list: https://groups.google.com/d/topic/golang-dev/wUEWhk2jtHM/

This seems going backwards to manual memory management
and it complicated the runtime a lot. I don't like this idea.
As mentioned in another issue, the GC could do a stop the world
emergency collection when memory runs out, and it should help
the usual case where there still is free memory available but GC
has yet to claim them.
If the program indeed runs out of memory, then it isn't much that
the panic handler could do to remedy the situation.

Regarding the appearance of going backwards: it's not really the same as old-school memory management.  Further, most people could just ignore the whole issue and keep playing the "I'm feeling lucky" game. Nothing changes for them.
Regarding making the runtime more complex: are you sure about that? What I'm suggesting is pretty narrow in scope. No "special memory" regions.
Regarding the emergency GC run: I haven't seen the proposal. If the suggestion is coupled with a recoverable panic(), so that the programme has the necessary feedback that memory is running out, this approach may help in many cases.
Regarding the panic handler not being able to do much to remedy an OOM situation: that is not correct. There are many classes of problems where there is a fairly high-level point at which an entire transaction can be aborted. For example, if I get a transaction request via an RPC handler then I would put the work which allocates lots of objects into a function and place a panic handler in there. The handler would drop the references to the new objects and call runtime.GC(). If the function returns a status indicating an OOM was caught, a failure status would be send back in the RPC reply, and I could even apply some back-pressure on requests.
It's essential to have an effective feedback mechanism when allocating memory. Without that, an application which dynamically scales its resource usage has no robust way to throttle.

(This may morph in to a runtime issue, but for now I think it's more of a proposal.)

I understand the desire for a memory backpressure mechanism, but I see some issues with the proposed solution.
For one, modern Linux systems (and probably other platforms) tend to make this difficult at the OS level itself. In practice, mmap operations generally let you overcommit memory (in fact, we depend on this on amd64) and things don't fail until you attempt to fault too much memory in. But at that point, the OS doesn't have much recourse but to kill your process. It is possible to configure Linux to disallow overcommit via /proc/sys/vm/overcommit_memory, though that tends to interfere with unexpected things (it may interfere with our overcommit, though that may be fixable). But maybe you have to disable overcommit for systems that depends on memory backpressure in any language.
Second, it's unclear what should happen if the failing allocation happens to be in a system goroutine. System goroutines don't allocate much, but they do allocate. Even the garbage collector has to allocate a bit for its work lists. Performing an immediate STW GC when allocation fails handles this situation much better, since it's a global solution to the global problem of an application being out of memory. A similar implementation-related problem is that if an allocation fails on a user goroutine but in the runtime, it's often on the "system stack" and making it possible to unwind a panic from the system stack would be a huge effort.
Finally, even if your defer releases reference to the memory used by a transaction, that memory won't be freed until the next GC, so allocations will continue to fail. Do you perform a full GC both before and after handling the panic? Do you require the recovery handler to perform a full GC?

1: I often run systems with overcommit off, because I would rather have the (C) application "run out" of memory a little earlier than have it killed when it starts using memory it was promised.
2: If emergency stop-the-world garbage collection were to provide feedback to the application, this might be viable. If the feedback is in the form of a function the application can call to detect that STW GC was performed, it would have to be evaluated to determine how effective it is in practice. If there is not enough memory that can be garbage collected to fulfill the memory allocations before the next check, there will still be a panic. Some obvious examples would be a large make/append of a slice or a call to one of the encoders. On the other hand, if the feedback mechanism is to generate a recoverable panic(), it gives the application the ability to stop offending allocations even inside library code.
3: If you read my opening email, I stated that the application recovery code would probably need to call runtime.GC().

How could you estimate the size for reserved memory?
Please note that OOM can happen:

on any goroutine
on multiple goroutines concurrently

1 implies that unless you control every function call in your
program, it's unlikely having reserved memory will help in
every possible OOM case. Even worse, if the OOM handler
is not last deferred function at all times, it's possible that
OOM panic occurs and a later deferred cleanup function
allocate more memory than is available, and then the
program crashes. so deferring a OOM handler won't work
in all cases.
Or perhaps the program can register a global OOM handler,
but that won't work either, because there is no way the
global handler can release the problematic memory allocation
that triggered the OOM panic.
Also note that you can't control every possible case, for
example, the runtime goroutine might allocate memory,
and what if that triggers the OOM?
2 implies that it's very hard to generally estimate the
memory required for OOM recovery. Unless you always
only run only one goroutine, but that's not what typical
Go programs are written. And I don't think we should
add a mechanism that can only be reliably used for
single goroutine programs.

I think you're making this more complicated than it needs to be. It's up to the application programmer to pick the size of the reserved memory. Well-written recovery code is going to take very little memory. All it should do is drop references to data structures, call runtime.GC() and then re-reserve memory.
Control over every single function call isn't necessary. It's a common pattern that there are a small number of goroutines doing "housekeeping", and one or more goroutines doing the heavy transactions, and those are the ones that need to throttle. The reserved memory allows the housekeeping code to continue. All we need is a way for goroutines (or functions) to register that they want to handle an OOM panic. The heavy allocation functions register this interest and no-one else does. When the initial OOM occurs, the functions that registered interest will get the notification and stop what they're doing (just like with panic()), and all the others will continue, eating a little from the reserved memory.
I think that we can do this with a "soft panic", which only affects those functions who have registered. If registered, the notification has the same behaviour as a panic(). One possible API is to have a defer-like statement (perhaps onnotification) that a function can use to register interest. Every function up the call stack that registered would get the notification. Another possible API is a failifnotified() function which would return a bool indicating whether a notification was received while running the provided function.

1: I often run systems with overcommit off, because I would rather have the (C) application "run out" of memory a little earlier than have it killed when it starts using memory it was promised.

Interesting. Does Go have any problems running with overcommit disabled? It may be that large PROT_NONE mappings don't count against committed memory (which would make sense, but they do count against ulimit -v, which does not make sense).

2: If emergency stop-the-world garbage collection were to provide feedback to the application, this might be viable. ...

I don't think a recoverable panic is a technically viable solution for the reasons I mentioned in my comment (namely, allocations on system goroutines and system stacks), unless you're only interested in catching large failed allocations. So, what about the emergency GC approach? What sort of specific feedback would be useful to an application so it could scale to fit the resources in response to triggering emergency GCs?  Alternatively, could the runtime provide feedback or mechanisms that would be useful for staying under the memory limit, rather than trying to deal with the consequences once you've already run out (and is this only useful in a strictly single tenant system)?

3: If you read my opening email, I stated that the application recovery code would probably need to call runtime.GC().

I did read your opening email (how else would I have replied?). I have now re-read it a few times and I think your penultimate paragraph is proposing "yes" to both of my questions: that GC would happen twice during the recovery (both at the beginning and at the end), and that the second time would be triggered by the application recovery code after it had unwound and dropped references. Am I interpreting your proposal correctly?

Looks like our replies crossed.

All we need is a way for goroutines (or functions) to register that they want to handle an OOM panic. The heavy allocation functions register this interest and no-one else does.

I see. I think this is how you're proposing to get around failed allocations on system goroutines as well (though it's still a problem for failed allocations on system stacks). Still, if the failed allocation happens on a goroutine that isn't registered for OOM panics, what happens? Do you pick a random registered goroutine to take the panic? Do you trigger the panic no matter where the goroutine(s) is/are, even if it's not in allocation?
I'll have to think about this a bit. I'm still interested in exploring alternative mechanisms.

I really don't think just handle OOM from allocation heavy
goroutine/function
would solve the problem.
it's quite possible that the allocation heavy goroutine allocates the last
bit
of memory and a unrelated housekeeping function/goroutine then triggers
the OOM.
What does other GC backed language do to handle OOM gracefully? Does
Java have OOM handlers?

Perhaps we're thinking about this the wrong way.  What if instead of thinking about "what do we do at OOM", how about "how do we let the application figure out that it is getting close to OOM"?
I could see runtime functions something along the lines of currentMemoryInUse and maxMemoryAvailable.  Heavy-allocating goroutines could check these two functions and backoff/fail the work instead of allocating.
Another possible API would be a "reserveMem(bytes int64) bool" call that tells the runtime "expect me to allocate this much".  If the runtime thinks it will be too much, it can return false, meaning "probably not going to be able to allocate that much, please back off".
I'm less sure how one might implement those calls, especially the "when is the OS going to refuse my next allocation" question.  It seems difficult in general, but we may be able to come up with something.  Maybe when reserveMem(...) is called, we ensure that we can successfully map & commit the heap space required for that much memory?

CC @rlh @aclements

Oh, wow. So many points to reply to. Well, a healthy discussion :-)
I'll put all my replies into this one message.
1: I have not observed problems running Go code with overcommit disabled.
2: I'm interested in catching failures in large allocations as well as many small allocations buried in a library I don't control.
3: Emergency GC would probably work if I still got a notification that stopped processing in the goroutines I've registered and called my recovery code.
4: Latency of emergency GC is unfortunate but is better than the alternative (dying).
5: I don't think providing feedback when we're "close" to running out of memory is viable. It won't work on a multi-tenant system, and even on a single tenant system knowing how much is available is difficult and non-portable (even on Linux: think nested containers versus no containers). It's also a problem when allocations are done deep inside a library that one does not control. I think it's unrealistic to expect that lots of library code will be refactored to perform periodic checks.
6: Yes, my proposal is to GC at the beginning and the end of recovery.
7: Failed allocations in system goroutines are just like application goroutines that have not registered interest in recovering from OOM. The heavy allocators are the ones where there is a benefit to doing recovery (lots of allocations, OOM, recover, drop references and abort transaction). Everyone else should be able to get by with the memory that the emergency GC frees up. We rely on their cleanup to bring the system back from the brink of disaster.
8: A TryAndReserveMem(bytes int64) bool function has similar issues to (5): between when you ask and when you try to do a real allocation, the situation can change. There is the same problem with refactoring libraries. Further, it's difficult to know how much memory I'm about to use. Go allocates a lot of memory under the covers for housekeeping. That's really significant with large numbers of small allocations.

The GC will do whatever it can to avoid an OOM and as GC matures it will
get better and better. As this happens the application's chances of
recovery will become less and less likely.
Even today attempts to recover seem doomed to failure. For example, the
immediate cause of an OOM may be in a Goroutine that has little to do with
the root cause of the OOM. This means that the innocent Goroutine that
allocated the final object that caused the OOM would have to do global
reasoning about the cause of the OOM and then have to correct the problem
locally. Cascading OOMs across Goroutines only make reasoning about global
properties  and maintaining coherency less likely. Algorithms with the
ability to reason globally and react locally are complex and hard. The most
obvious example of such an algorithm is the GC itself which has to reason
about the global property of reachability. Getting into an arms race with
the GC about how to manage memory will waste a lot of energy that could be
spent articulating and understanding real world use cases that can be then
used to improve the GC for everyone.
On Sat, Jan 30, 2016 at 6:53 PM, rgooch<EMAIL_ADDRESS>wrote:

Regarding the appearance of going backwards: it's not really the same as
old-school memory management.  Further, most people
could just ignore the whole issue and keep playing the "I'm feeling lucky"
game. Nothing changes for them.
Regarding making the runtime more complex: are you sure about that? What
I'm suggesting is pretty narrow in scope. No "special memory" regions.
Regarding the emergency GC run: I haven't seen the proposal. If the
suggestion is coupled with a recoverable panic(), so that the programme has
the necessary feedback that memory is running out, this approach may help
in many cases.
Regarding the panic handler not being able to do much to remedy an OOM
situation: that is not correct. There are many classes of problems where
there is a fairly high-level point at which an entire transaction can be
aborted. For example, if I get a transaction request via an RPC handler
then I would put the work which allocates lots of objects into a function
and place a panic handler in there. The handler would drop the references
to the new objects and call runtime.GC(). If the function returns a status
indicating an OOM was caught, a failure status would be send back in the
RPC reply, and I could even apply some back-pressure on requests.
It's essential to have an effective feedback mechanism when allocating
memory. Without that, an application which dynamically scales its resource
usage has no robust way to throttle.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/14162#issuecomment-177339824.

Let's posit that the GC is perfect: every time an object is no longer referenced, it is freed immediately and thus available for reuse. In this case, my original proposal to reserve a buffer for use during OOM recovery makes recovery viable. Functions which expect to do large allocations register an interest in being notified that we had to eat into the emergency buffer. If any allocation fails and the reserved buffer is sitting there, the buffer is dereferenced and freed, notifications of "we are running on reserve power" are sent, and normal processing continues. The application can decide how big the reserve buffer is.
My proposal deals with the scenarios you describe.
Note that my proposal is not an arms race with the GC. The underlying issue is not with the behaviour of the GC. The underlying issue is the lack of a backpressure mechanism. The core problem is that the application has no way to find out that memory is running low and no way to effectively react (stop all allocations which are likely to be large).

Fundamentally, the whole point of a garbage collector is that the programmer doesn't have to worry about allocating nor freeing memory. The problem is that a garbage collector can't do anything sensible when it runs out of memory except trying a sweep. If that fails, there's no way to decide what to do since the allocation that failed could have come from anywere.
The only way to avoid this is to allocate and free the memory manually. I could imagine the unsafe package gaining a few extra functions to do this, such as unsafe.Allocate(), unsafe.Free().

Fundamentally, the role of a garbage collector is to present to the programmer the illusion of an infinite free store.
If that illusion is broken, is seems reasonable to abort the program.

On 1 Jul 2016, at 08:42, Beoran<EMAIL_ADDRESS>wrote:
Fundamentally, the whole point of a garbage collector is that the programmer doesn't have to worry about allocating nor freeing memory. The problem is that a garbage collector can't do anything sensible when it runs out of memory except trying a sweep. If that fails, there's no way to decide what to do since the allocation that failed could have come from anywere.
The only way to avoid this is to allocate and free the memory manually. I could imagine the unsafe package gaining a few extra functions to do this, such as unsafe.Allocate(), unsafe.Free().
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Agreed there. That is exactly why I would  propose non-gc memory management
as a workaround for situations where this illusion is undesirable or even
dangerous.
On 1 Jul 2016 12:57 am, "Dave Cheney"<EMAIL_ADDRESS>wrote:

Fundamentally, the role of a garbage collector is to present to the
programmer the illusion of an infinite free store.
If that illusion is broken, is seems reasonable to abort the program.

On 1 Jul 2016, at 08:42, Beoran<EMAIL_ADDRESS>wrote:
Fundamentally, the whole point of a garbage collector is that the
programmer doesn't have to worry about allocating nor freeing memory. The
problem is that a garbage collector can't do anything sensible when it runs
out of memory except trying a sweep. If that fails, there's no way to
decide what to do since the allocation that failed could have come from
anywere.
The only way to avoid this is to allocate and free the memory manually.
I could imagine the unsafe package gaining a few extra functions to do
this, such as unsafe.Allocate(), unsafe.Free().
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/14162#issuecomment-229811645, or mute
the thread
https://github.com/notifications/unsubscribe/AAEWeRNkmh5bPXlQ1QwVKtaMjeaD0dPWks5qREmsgaJpZM4HP1lM
.

I don't see how one can write robust applications which scale to fit their resource constraints if one insists on maintaining the illusion of an infinite free store. Aborting the programme when an unknowable memory limit is reached is a terrible experience. Is no-one else here writing code which tries to make the most out of available resources (particularly memory)?
Right now one strategy we have for avoiding an OOM panic is to over-provision the VM/container. If we have a workload that has a steady-state requirement of 30 GiB, we need to provision at least 50 GiB so that we can handle demand spikes. We need significant headroom since we call other libraries we don't control which could allocate a lot of memory. We periodically check our memory consumption and call runtime.GC() to help out and if that doesn't work out we start shedding load ("we're full, come back later"). Determining the required headroom is basically measurement-based guesswork. We pick a number for the headroom, run the load for a few hours or a day or so and if there are no OOM panics, declare "victory", otherwise we try again with a higher number.
This approach is not one we're happy with. We're spending a lot of extra money on this "safety headroom". For many of our workloads we need to be prepared to shed load anyway, and that's just fine. And since we need to be able to shed load anyway, we'd be much better off being able to catch OOM panics so that we can abort a request rather than abort the whole programme.
If someone has a better idea for dynamic workload management which doesn't require massive over-provisioning of resources, I'd be quite interested.
The suggestion for unsafe.Allocate() and unsafe.Free() doesn't look like it would help, since we simply don't know with certainty how much memory a particular request will require. It depends on the request data and is not easily computable.

/cc @matloob, who is investigating handling memory-constrained situations and load spikes by giving the application more visibility into and control over GC pacing (not by catching OOMs, which I still think is not a technically viable option). The rough idea is that if we can give the application tight-loop control over the GC's heap size target, it can observe its own memory usage (and anything else that might affect this, like other processes in the same container), shed load if it gets too tight, and dynamically trade off more CPU for lower memory overhead by making GC more aggressive.

If I could get a recoverable panic when memory use hits a pre-defined limit, that would help. This would work OK for applications which are intended to consume most of the memory of a VM/container. This would best be coupled with a way to safely allocate (and dirty) memory until full, then free that memory and report back. That would allow an application to know how much memory is available in the VM/container and then it could set the limit based on that (i.e. 95%). Suggested API:
runtime.GetAllocateableMemory() uint64
runtime.SetSoftMemoryLimit(maxBytes uint64)
GetAllocateableMemory() should come with a warning that it will keep allocating memory until failure, can cause massive swapping (then again, only the foolish run with swap:-) and will throw out your page cache.

Note that I keep harping on about recovering from a panic because I can't just sprinkle all code with TellMeWhenImRunningOut() calls, because I don't control all the code that I call. I need an out-of-band way to abort the current callchain and give up the transaction at a high level.

OOM is a global property. The application could have a goroutine that wakes up periodically, checks some status, and if all is well go back to sleep for an application appropriate time. If there is memory pressure then back pressure, such as not accepting any new requests, could be applied.

How would you feel about, say, registering a channel to receive
notifications about memory use at some well-defined time with respect to
garbage collection?  (This is my own bright idea, not necessarily endorsed
by Richard or Austin).  The intent is to give you some relatively accurate
record of memory use over time, rather than letting you know too-late that
you're in a bad way, and you would use this interface to control how much
work you allowed into your server, and/or would modify the amount of memory
overhead (indirectly, the GC rate).
On Jul 9, 2016 2:37 PM, "rgooch"<EMAIL_ADDRESS>wrote:
If I could get a recoverable panic when memory use hits a pre-defined
limit, that would help. This would work OK for applications which are
intended to consume most of the memory of a VM/container. This would best
be coupled with a way to safely allocate (and dirty) memory until full,
then free that memory and report back. That would allow an application to
know how much memory is available in the VM/container and then it could set
the limit based on that (i.e. 95%). Suggested API:
runtime.GetAllocateableMemory() uint64
runtime.SetSoftMemoryLimit(maxBytes uint64)
GetAllocateableMemory() should come with a warning that it will keep
allocating memory until failure, can cause massive swapping (then again,
only the foolish run with swap:-) and will throw out your page cache.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/14162#issuecomment-231551900, or mute
the thread
https://github.com/notifications/unsubscribe/AB1vJ7EiT0fXBtdl79g68b6h63d4CWj_ks5qT_h1gaJpZM4HP1lM
.

Having a goroutine which periodically checks memory use, or which listens on a channel for memory warnings doesn't do me a lot of good because I need to kill off the code that's doing the problematic memory allocations.
While it's true that OOM is a global property, it's usually the case that transaction processing code is where the bulk of allocations are being done, so it's that code that needs to be aborted/limited. This is why the panic on soft memory limit exceeded approach can help, while other notification mechanisms would not help. It's not a real OOM, it's just an early warning that soon you will be in trouble. runtime.SetSoftMemoryLimit() would affect only the calling goroutine. If you architect your application so that transaction processing is limited to specific goroutines, and those goroutines have asked for the early warning panic, they can recover from those panics by aborting the transaction and hence freeing up memory. Everyone else runs as normal, since there is still memory available.
In a way, this is similar to my original suggestion of a memory buffer that's set aside and only used when there is an OOM panic, but it's probably simpler and cleaner to implement in the runtime.

I think we're going to close this specific proposal of a solution in favor of #16843 which is tracking the more general problem.


Option to redirect/surpress stderr

makemkvcon spits out a lot of error messages, I am guessing this is because Popen send them to stdout,
could it be possible to have some way of redirecting this so they either can be handled with a callback, or just surpress them?
A lot of it is just status that can't be done a lot with.

python-makemkv uses python's logging module. You can use logging.basicConfig() to change logging settings like log format, log level (debug, info, warning, error, critical) or log handlers.
To suppress warnings from makemkv, you can also set the log level of makemkv's Logger to "error"
import logging

logging.getLogger("makemkv").setLevel(logging.ERROR)

or suppress all messages
logging.getLogger("makemkv").setLevel(logging.CRITICAL)

If you think that the log level of a specific message isn't appropriate (there are ~300 different messages, I have not yet met most of them in a real life situation), feel free to point me to its id (the number in parentheses) and I can take a look at it.

Thank you!
Works just like I wanted. Closing the issue, and will report if any specific message causes a problem.


Feature: Managed Assets

This changeset introduces a managed asset layer to Elide, which is integrated into the framework build tools. At build time, embedded SSR and CSR assets are packaged into the application, and are now additionally embedded with an asset descriptor providing metadata and dependency info.
These descriptors are then used at runtime to more efficiently serve static assets directly out of memory, and to reference static assets easily from dynamic contexts.
Later, we can use this as groundwork to enable dependency-aware asset serving, on-the-fly compilation, and so on.
Changelog

[x] Add AssetManager, AssetReader, AssetResolver interfaces
[x] Add initial abstract logic for resolving and serving assets
[x] Add server configuration properties for the asset system
[x] Add concept of general bundled asset to bundle.proto
[x] Add built-in implementations for each asset component interface
[x] Add initial implementation of controller for asset serving
[ ] Logic to translate assets into HTTP responses
[ ] Logic to load and read assets
[ ] Tests for asset components
[ ] Tests for asset controller
[ ] Gradle plugin support

[x] JS bundling: elide-dev/buildtools#5
[ ] Asset spec generator

Codecov Report

Merging #22 (199dd46) into v3 (d8f3b58) will decrease coverage by 41.73%.
The diff coverage is 0.26%.

@@             Coverage Diff              @@
##                 v3     #22       +/-   ##
============================================
- Coverage     44.21%   2.48%   -41.74%
- Complexity      166     167        +1
============================================
  Files            41     132       +91
  Lines          1825   32937    +31112
  Branches        171    5386     +5215
============================================
+ Hits            807     819       +12
- Misses          997   32097    +31100
  Partials         21      21

Impacted Files
Coverage Δ

...main/kotlin/elide/server/assets/AssetController.kt
0.00% <0.00%> (ø)

...rc/main/kotlin/elide/server/assets/AssetManager.kt
0.00% <0.00%> (ø)

...c/main/kotlin/elide/server/assets/AssetResolver.kt
0.00% <0.00%> (ø)

...c/main/kotlin/elide/server/assets/RenderedAsset.kt
0.00% <0.00%> (ø)

...src/main/kotlin/elide/server/assets/ServerAsset.kt
0.00% <0.00%> (ø)

...er/src/main/kotlin/elide/server/cfg/AssetConfig.kt
0.00% <ø> (ø)

.../google/common/html/types/CustomSafeUrlScheme.java
0.00% <0.00%> (ø)

...c/main/java/com/google/common/html/types/Html.java
0.00% <0.00%> (ø)

...va/com/google/common/html/types/SafeHtmlProto.java
0.00% <0.00%> (ø)

.../com/google/common/html/types/SafeScriptProto.java
0.00% <0.00%> (ø)

... and 82 more

Continue to review full report at Codecov.

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


Is not working

it will not actually ping the server ip and create anything it keeps saying
Timeout on error on {server ip}

Can you please post your config, hide your token

I cannot provide it right now but at 5 UTC I can sorry for this
inconvenience
On Mon, 28 Jun 2021, 00:58 Feli, @.***> wrote:

Can you please post your config, hide your token
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/01-Feli/ServerStatusBot/issues/6#issuecomment-869244326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOIB4EUBV4JGQGYHP7CUGCDTU63J3ANCNFSM47MJCDLQ
.

Which node bash or node.js or any

Um I cant even remember what this is it has been nearly a year
On Wed, 18 May 2022, 08:45 adarsh-sk6, @.***> wrote:

Which node bash or node.js or any
—
Reply to this email directly, view it on GitHub
https://github.com/negrifelipe/ServerStatusBot/issues/6#issuecomment-1129682251,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOIB4ERY5SW6WKNC7C3FS2DVKSN2JANCNFSM47MJCDLQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


[1.12] Crystal Growth Chamber crashes the game

When I placed the Crystal Growth Chamber the game crashed. (Crashes also occur when using other ae2stuff blocks)
It seems that the version of ae2stuff is incompatible with my ae2 version.
appliedenergistics2-rv5-alpha-7
ae2stuff-<IP_ADDRESS>-mc1.12.2
If so, what version do I have to use and why is no error occurring when ae2stuff loads?
java.lang.NoSuchMethodError: appeng.api.IAppEngApi.grid()Lappeng/api/networking/IGridHelper;
	at net.bdew.ae2stuff.grid.GridTile$class.getNode(GridTile.scala:79)
	at net.bdew.ae2stuff.machines.grower.TileGrower.getNode(TileGrower.scala:30)
	at net.bdew.ae2stuff.grid.GridTile$$anonfun$1.apply$mcV$sp(GridTile.scala:37)
	at net.bdew.lib.Event0$$anonfun$trigger$1.apply(Event.scala:19)
	at net.bdew.lib.Event0$$anonfun$trigger$1.apply(Event.scala:19)
	at scala.collection.immutable.List.foreach(List.scala:383)
	at net.bdew.lib.Event0.trigger(Event.scala:19)
	at net.bdew.lib.tile.TileTicking$class.update(TileTicking.scala:24)
	at net.bdew.ae2stuff.machines.grower.TileGrower.func_73660_a(TileGrower.scala:30)
	at net.minecraft.world.World.func_72939_s(World.java:1807)

Full crash report: https://gist.github.com/0blu/1a317f0ad4a45e6b31db06eeedd6ff38

That version is for alpha 8, it's not compatible with earlier versions of AE2.
For alpha 7 and lower use AE2Stuff <IP_ADDRESS>


how do i use it

I'm really new to kali and I don't know how to activate the program, i got it downloaded and everything but what's the command to activate it

very easy, please read README.md


The library isn't updated to Swift 3.0

Hi,
Can you please update this library to use latest Swift 3.0 standards?

+1

+1, please update asap ;)

+1

Sorry guys, the lib was updated for swift 3.0 but didn't have a proper tag until tonight.
To install it with Carthage:
github "delba/JASON" "~> 3.0"

I'm having some connectivity problems but the CocoaPod is coming soon :)
Thanks for your patience!


High system load

Normally my laptop sits around 0.00-0.10 at idle. When I use clevo-indicator ìt sits above 1.00. Any idea what my causing this?

Thank you!


API tests for GDPR export

the GDPR export should be tested by API tests

generate personal data for a user e.g. upload files, create spaces, share items, etc.
send request to generate the export
download the report file using WebDAV
check content of the downloaded file using JSON schema

This might require multiple scenarios to test
CC @ScharfViktor

TODO scenarios:

[ ] check events when user is created
[ ] check events when file is uploaded

and others as well.


Fixed typo in error message

Summary
Fixed a spelling mistake in an exception message.
Solves
#577

Thanks!


Feat: Wallet connect & Mobile Metadata

the goal of this PR is to add the mobile metadata of a wallet and also its definitions for wallet connect, such as the patterns with which a user can invoke the service on mobile

If the schema is ok, I'll update mobile wallet configs


Change openai model version

The current version is not available in Azure and the deployment fails.

Without this change we get
Deployment Error Details:
InvalidTemplateDeployment: The template deployment 'openai' is not valid according to the validation procedure. The tracking id is 'b5df8d0e-ef4a-415d-960a-388482f9b9df'. See inner errors for details.
DeploymentModelNotSupported: The model 'Format: OpenAI, Name: text-embedding-3-small, Version: 2' of account deployment is not supported.

Deployment was successful after this change.
5/3/2024 4:57:16 PM: Info   (✓) Done: Resource group: rg-sebros3
5/3/2024 4:57:38 PM: Info   (✓) Done: Container Registry: acr7vleary5vwctw
5/3/2024 4:57:38 PM: Info   (✓) Done: Log Analytics workspace: law-7vleary5vwctw
5/3/2024 4:59:27 PM: Info   (✓) Done: Container Apps Environment: cae-7vleary5vwctw
5/3/2024 4:59:49 PM: Info   (✓) Done: Container App: eventbus
5/3/2024 4:59:49 PM: Info   (✓) Done: Container App: postgres
5/3/2024 5:00:00 PM: Info   (✓) Done: Container App: redis
5/3/2024 5:00:47 PM: Info   (✓) Done: Azure OpenAI: openai7vleary5vwctw

Also, I used <AspireVersion>8.0.0-preview.7.24251.11</AspireVersion> with the nightly feed:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
    <add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
    <add key="dotnet-public" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <!-- key value for <packageSource> should match key values from <packageSources> element -->
    <clear />
    <packageSource key="dotnet-public">
      <package pattern="*" />
    </packageSource>
    <packageSource key="dotnet-tools">
      <package pattern="*" />
    </packageSource>
    <packageSource key="dotnet-eng">
      <package pattern="*" />
    </packageSource>
    <packageSource key="nuget">
      <package pattern="*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

Is this only a policy deployment issue or the model is not available for everyone?


[Feature Request] Limit max number of items dropped

I've tried significantly lowering the probabilities of all items an enemy drops to prevent multiple items spawning, but even then, sometimes multiple items will spawn.
Ideally I'd like to specify for each enemy the chance that any item drops, and then if an item does drop, it chooses which item from the probabilities given.

If you want a random item to drop you can leave the config line empty. Otherwise making it so people have to configure each item for each monster is a bit much. I mean you can already do that though. The config allows you to put as many items as you want and alter the chance of dropping for them all. I will make it so you can limit the max amount of items per level though.

@GoldenKittenPlays ohh okay, so I'm trying to make a specific loot table for each monster with a limited subset of items. Is that possible? I'm giving it:
Hoarding bug = Big bolt, 0, 1, 20, 35, 6, Bottles, 0, 1, 40, 60, 4, Brush, 0, 1, 20, 35, 6, Candy, 0, 1, 20, 35, 6, Chemical jug, 0, 1, 50, 80, 4, Comedy, 0, 1, 30, 50, 4, Cookie mold pan, 0, 1, 18, 30, 6, Dust pan, 0, 1, 15, 30, 6, Egg beater, 0, 1, 20, 30, 6, Flask, 0, 1, 25, 35, 6, Gift, 0, 1, 15, 25, 6, Large axle, 0, 1, 25, 50, 6, Laser pointer, 0, 1, 30, 40, 5, Magnifying glass, 0, 1, 20, 35, 6, Metal sheet, 0, 1, 15, 25, 6, Mug, 0, 1, 30, 40, 5, Plastic fish, 0, 1, 20, 30, 6, Remote, 0, 1, 20, 30, 5, Rubber Ducky, 0, 1, 20, 30, 6, Stop sign, 0, 1, 15, 25, 6, V-type engine, 0, 1, 25, 50, 6, Whoopie cushion, 0, 1, 15, 25, 6, Yield sign, 0, 1, 15, 25, 6

Which I feel like should ensure the hoarding bug rarely ever drops loot at all, but it seems to always drop something on every kill.

@GoldenKittenPlays ohh okay, so I'm trying to make a specific loot table for each monster with a limited subset of items. Is that possible? I'm giving it:
Hoarding bug = Big bolt, 0, 1, 20, 35, 6, Bottles, 0, 1, 40, 60, 4, Brush, 0, 1, 20, 35, 6, Candy, 0, 1, 20, 35, 6, Chemical jug, 0, 1, 50, 80, 4, Comedy, 0, 1, 30, 50, 4, Cookie mold pan, 0, 1, 18, 30, 6, Dust pan, 0, 1, 15, 30, 6, Egg beater, 0, 1, 20, 30, 6, Flask, 0, 1, 25, 35, 6, Gift, 0, 1, 15, 25, 6, Large axle, 0, 1, 25, 50, 6, Laser pointer, 0, 1, 30, 40, 5, Magnifying glass, 0, 1, 20, 35, 6, Metal sheet, 0, 1, 15, 25, 6, Mug, 0, 1, 30, 40, 5, Plastic fish, 0, 1, 20, 30, 6, Remote, 0, 1, 20, 30, 5, Rubber Ducky, 0, 1, 20, 30, 6, Stop sign, 0, 1, 15, 25, 6, V-type engine, 0, 1, 25, 50, 6, Whoopie cushion, 0, 1, 15, 25, 6, Yield sign, 0, 1, 15, 25, 6

Which I feel like should ensure the hoarding bug rarely ever drops loot at all, but it seems to always drop something on every kill.

So my code works by each item. So with so many items the chance of one of them dropping is pretty high. I will add it as a feature where if you type in something like this: random, 1, 1, 30, 50, 5
It will make it a random item with very little chance of dropping. Does that sound like what you wanted?

@GoldenKittenPlays I've done some more testing and the hoarding bugs are dropping items that I haven't specified in the list. I'm assuming it's defaulting to the normal item drop table. Any idea why? Is my string malformed? Or does the mod spawn items that aren't on the list as well?

@GoldenKittenPlays I've done some more testing and the hoarding bugs are dropping items that I haven't specified in the list (e.g. wedding ring and jar of pickles). I'm assuming it's defaulting to the normal item drop table. Any idea why? Is my string malformed? Or does the mod spawn items that aren't on the list as well?

If you mistype a config item at all I make my mod double back and choose a random item. I do this so I do not get errors. Guess I could make it so if it has a certain amount of drops to do something else

@GoldenKittenPlays okay so I dug into the code a bit and I think I know what's happening. Because all the items have such low chance to spawn, itemsToGive is an empty list. But the line here:
https://github.com/GoldenKittenPlays/GetLootForKills/blob/de18c381f8d69d1dcc95e8afbc3a9663281f0d19/GetLootForKills/Patches/KillPatch.cs#L30
Doesn't care why the itemsToGive is empty, it always picks a random item to drop.

Would you accept a PR to change how the loot spawns work? It would change the config for each enemy to be:

Chance of spawning any item at all

Items

Name
Probability
Min value
Max value

I might just add that as a function later. I will make it configurable if they want to use that way or not. I forgot that part about the code. I tend to work on it even when tired af lol. I will work on it again to remedy it


Add an example of using len8.Checker class in a file

Is your feature request related to a problem? Please describe.
A description of what the problem is. Ex. What are you trying to solve?
There are currently no examples of how to utilize len8 inside a python script.
Describe the solution you'd like
A detailed description of an ideal implementation.
An example or 2 in the readme would suffice.

Resolved in #10


PointFeature properties inaccurate type

I don't know if it is possible to solve this but I think it could be helpful if it was. Perhaps I am missing something and there is a better solution.
In the readme it states: "Currently supported Point properties are null, boolean, number, string. The rest will be discarded when the supercluster is created. If you need to store other properties you can always turn them into a JSON."
This makes sense but it would be useful if there was some way of reflecting this in the types to avoid errors where properties other than these types were passed to the class Supercluster.
Currently, the follow code could lead to problems if the an attempt was made to access PointFeature["properties"]["price"]["weekday"] since the type would suggest this property existed when, in fact, this will have been stripped out.
type InternalPointType = {
    name: string,
    price: {
        weekday: number;
        weekend: number;
    }
}
const superClusterIndex = new Supercluster<InternalPointType >();

In my own code I have used the following type "PickByType" (credits: https://stackoverflow.com/a/69756175) to create a new version of the original type which reflects the runtime object more accurately.
type PickByType<T, Value> = {
    [P in keyof T as T[P] extends Value | undefined ? P : never]: T[P];
};

type ClusteredInternalPointType = PickByType<
    InternalPointType,
    null | boolean | number | string
>
const superClusterIndex = new Supercluster<ClusteredInternalPointType >();

I wonder if a similar technique could be used internally to modify the type passed to Supercluster. I don't think I have a deep enough understanding of this project at the moment to create a pull request but I think this could be helpful if someone else thought this would be useful to implement.

No need for picking types, this limitation is removed with v2.0.0 🙂


add/update flowlog documentation

Addressing the last part of issue #64
Signed-off-by: eriknordmark<EMAIL_ADDRESS>

@deitch I thought I had specified that, but I see it has the copy and pasted intro line:
Send Device and Application logs to Controller
which is incorrect. These are TCP/IP/DNS flow logs showing which connections an app instances has had or tried to have. I'll fix that.


use kubebuilder go/v4 template

resolve: #213

@peng225

When I ran go mod tidy on my environment, go.mod and go.sum was changed. Could you check it?

It was an incomplete work, so I updated it.

Because you deleted config/default/kustomization.yaml, the release procedure should be changed. Now step 2 to 6 can be deleted.

It will be your help to compare it with the TopoLVM's release procedure.

The change was added in the following commit.
https://github.com/topolvm/pvc-autoresizer/pull/236/commits/37b5c6539f89652b083a21b2d79520b5adf583ad

I'd like to see separate commits for change set to migrate from kubebuilder go/v3 to go/v4 and those that are not. ...

I reworked the split of the commits.

It seems that the change in the project layout might affect in our code not only main.go, but also codes for the controller and the webhook. Shouldn't this be addressed?

Since the official layout was defined differently from the Standard Go Project Layout, I wondered whether I should include it or not. However, the internal/ directory was the same for both, so I changed it. Since there was no specification for constants, I moved it to the top directory in the same as TopoLVM.


[SPARK-2909] [MLlib] [PySpark] SparseVector in pyspark now supports indexing

Slightly different than the scala code which converts the sparsevector into a densevector and then checks the index.
I also hope I've added tests in the right place.

ping @jkbradley @mengxr Would be great if you could have a look :)

Test build #25480 has started for   PR 4025 at commit 3528e47.

This patch merges cleanly.

Test build #25480 has finished for   PR 4025 at commit 3528e47.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/25480/
Test FAILed.

Test build #25481 has started for   PR 4025 at commit f02148b.

This patch merges cleanly.

Test build #25481 has finished for   PR 4025 at commit f02148b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/25481/
Test PASSed.

@mengxr I've fixed up your comments. Btw, should we use a similar logic for the scala code? Right now it seems to convert it into a dense vector, which I'm not sure is advisable.

Test build #25503 has started for   PR 4025 at commit 07d0f26.

This patch merges cleanly.

Test build #25503 has finished for   PR 4025 at commit 07d0f26.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/25503/
Test PASSed.

Also I'm thinking out aloud if it's worthy enough to implement __setitem__

This looks good to me, thanks!

Thanks, has this been pushed to master, so that I can close it?

It's not merged yet, github will close it once it get merged.

LGTM. @MechCoder The Scala code uses Breeze's index lookup, which uses bisection as well. You can try implementing bisection in MLlib and then doing a micro-benchmark. If there is a big difference, we will have the implementation in MLlib.

Merged into master. Thanks!


MinGW packages failing when built with Nuitka

See note at https://github.com/Nuitka/Nuitka/issues/43#issuecomment-536833426 for how these are being built.
This issue details failures beyond those encountered at https://github.com/Nuitka/Nuitka/issues/522
Build:

[ ] pefile - doesnt emit pefile
[ ] PyYAML fatal error: stdio.h: No such file or directory also pycryptodome
[ ] redis & maxminddb AttributeError: Can't pickle local object 'BaseTestReader._check_concurrency.<locals>.lookup'
[ ] cmarkgfm - strange C++ in .c files
[ ] Pillow - no error given?

Test (quite likely these may be due to different dependencies on Windows, missing from .spec files written for Linux only):

[ ] waitress Test failed: <unittest.runner.TextTestResult run=565 errors=63 failures=0>

Import fails (lots of these; no idea what is going on, yet):

[ ] pexpect
[ ] bcrypt
[ ] CacheControl
[ ] MarkupSafe
[ ] msgpack
[ ] Werkzeug
[ ] OpenSSL & requests-toolbelt
[ ] itsdangerous

Out of memory:
(mingw32 cc1.exe appears limited to 2Gb of memory)
(possibly also due to extra tracing, and running under wine - it is easy to increase the memory on the workers for each of these)

[ ] Pygments
[ ] pyasn1-modules
[ ] peewee

Missing mingw deps (i.e. not in openSUSE): git, argon2, brotli, cmark, libyaml
Missing Python stdlib deps: mpdecimal, gdbm (not working in cpython cross-compile)
Failing because of Windows:

[ ] pytest-asyncio - test_subprocess test_subprocess_forbid raise NotImplementedError in stdlib asyncio

I honestly don't know how to use this, but I suspect it's outdated.


Fix issue #578 #577 and #574

FastJsonHttpMessageConverter is apply to using Spring MVC below 4.2
FastJson4HttpMessageConverter is apply to using Spring MVC 4.2+
The addSerializeFilter method‘s bug has fixed

'FastJson4HttpMessageConverter' the className is confused, it looks like fastjson 4.0 version.

@wenshao 。。。那应该叫什么名字呀

@wenshao FastJsonHttpMessageConverterNew ?

FastJsonHttpMessageConverter4 ?


Fix typo in case studies

Fix typo in case studies
Signed-off-by: Youssef Azrak<EMAIL_ADDRESS>

Re-checl


Support Project

I watch socketry libraries. It is really good. I want to support if you open a page on crowdfunding page. Example: https://opencollective.com/opensource
Thank you.

We have GitHub sponsorship, is that sufficient?

I didn't see it. Are you getting enough support?

The more support this project gets the more we can achieve, since I can focus more time on it. So the short answer is, we can always use more sponsorship.

@fastengineer Here is the latest progress report FYI.
https://www.codeotaku.com/journal/2020-04/open-source-progress-report/index
If you have budget for sponsorship, I am happy to discuss including your logo/link on those reports.
You can also provide sponsorship/support using the tiers on this page: https://github.com/sponsors/ioquatix
Let me know if there is anything else I can help with.


Fixes bug #113: Run keepalive setInterval outside NgZone

This is a fix for issue #113 to allow Protractor to continue without waiting for synchronization with Angular.
issue #113
Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines: https://github.com/HackedByChinese/ng2-idle/blob/master/CONTRIBUTING.md#pr
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x")
[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior? (You can also link to an open issue here)
https://github.com/HackedByChinese/ng2-idle/issues/113
What is the new behavior?
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Coverage increased (+0.003%) to 99.372% when pulling 04e3d4c941cffbae8190c6833c73718507cbd70a on michaelmills:bugfix/issue-113 into 11f2796a580f416943aec9f18f9607c403c7ce2e on HackedByChinese:master.


output error when starting a rescheduled container fails

output error when starting a rescheduled container fails
fix part of #2026
Signed-off-by: Sun Hongliang<EMAIL_ADDRESS>

LGTM

ping @vieux

LGTM


Sample: Ending a conversation

Hello!
I'm using the new version of BotFramework-WebChat, it's in any time call the end conversation automatically?
Because some customers can't keep a conversation with the same conversationId after some time.
It's happen to me also, and I need to generate another conversationId.
Error 404

Thank you.

@gabog
"With the previous webchat it was possible to dispose the webchat and recreate it on the page and that would generate a new conversationId, is this not possible with the new webchat? We need to be able to start a new conversation every time the webchat control is instantiated without having to refresh the page."
Do you happen to have any pointer or sample code that address the webchat disposal and recreation on Botframework V3?
Thx!

Closing as we have no plans to implement this sample. For the DirectLineJS issue, please see https://github.com/microsoft/BotFramework-DirectLineJS/issues/124


Making Interop SDK Hash Extensible

Feature addition:

Added interface to Fabric interop SDK for Hash. Implemented default SHA256.
Updated Fabric-cli as per the above hash interface.
Update fabric-cli exchange-step command, and replaced with different lock, claim, and unlock commands.
Docs updated as per above changes.
Updated SDK unit tests as per above change.

RFC:

Added API specs for relay.
Added message specs used for data sharing.

Others:

Version bump v1.3.0 for all fabric modules, relay and protos.
Access control logs added to corda interop app.
Fixed makefiles for interopcc, interop sdk, and fabric-cli.
Made semi-local tests in workflows use locally built docker images.

Fix: Typescript and ts-node version mismatch fixed, and updated in interop node sdk and fabric-cli.


Debian package of trepl

package lua-torch-trepl is currently pending for review,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827590
Packaging is here:
http://anonscm.debian.org/cgit/debian-science/packages/lua-torch-trepl.git

the package is already in the archive. Closing this issue.


Replace circle.yml skeleton file

Nice, I'm glad you were able to modify the npm shell bit, that's great, :shipit:


ARROW-18016: [CI] Add sccache to more jobs

@github-actions crossbow submit -g nightly

By the way, what is the current disk footprint of our sccache?

@github-actions crossbow submit -g nightly

@github-actions crossbow submit -g nightly

@raulcd @kou could you review this? There are still a few jobs we can add sccache but I will do those in a follow up to keep this reviewable.

@github-action crossbow submit verify-rc-source-cpp-linux-conda-latest-amd64 test-alpine-linux-cpp homebrew-r-autobrew test-r-install-local test-r-linux-as-cran test-r-versions

@kou the only way is to manually check in the logs :see_no_evil:  but I did that and noted the jobs that are still not using sccache. The builds above had errors (missing curl)/I fixed/were still missing envvars so I am now only testing those. all other failures are unrelated.

The R failures are unrelated test failure, I had to change the install script to work with alpine's busybox

@github-actions crossbow submit test-alpine-linux-cpp test-ubuntu-20.04-cpp

rebased to fix go CI issue

@github-actions crossbow submit -g nightly

python-sdist

was still missing curl, now fixed

test-r-versions

fails due to ARROW-18174

verify-rc-source-integration-linux-ubuntu-18.04-amd64
verify-rc-source-js-linux-ubuntu-18.04-amd64

fail due to wrong nodejs version (18 is not supported)

Will update this when more results are available.

@github-actions crossbow submit r-binary-packages python-sdist

The r binary failure is also caused by ARROW-18174, the problem caused by busybox being installed was solved.

@github-actions crossbow submit test-alpine-linux-cpp ubuntu-cpp

* python-sdist

  * was still missing curl, now fixed

Why do we need sscache for this? It seems that we don't compile C/C++ code for this.
BTW, could you list jobs that should be sscache enabled? I'll confirm results of them.

This PR is to widespread to review properly. I am going to open a new PR with reduced scope.


To adding a day and date part when the task are written

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

when we enter the task and submit it then to show the day and date so that anyone can know this task is given on this date .
please assign me under SSOC2.0

pls specify the name of project and give reference with screenshots so that i can work on this issue.

Create a fresh issue with proper description


Remove uppercasing of groups

Unlike most fields in forms in Mailchimp, which use uppercase key names (eg: "NAME"), groups do not (eg: "group[2][4]"), so uppercasing them causes them to not be recognized as a group by Mailchimp.
Example:

To fix this, a simple check if the key name includes the substring "group[", and if it does, the key is not uppercased.

wow thanks!  this looks good but i'll need about a week to test it locally first.  hope that's okay?  thanks so much for the PR! 👍

wow thanks! this looks good but i'll need about a week to test it locally first. hope that's okay? thanks so much for the PR! 👍

Sure, happy in any way to help.

@tomrbowden working on this today.  looks like you are using prettier to format the code?  i may need to simply make this change myself and commit it normally (instead of merging your PR).
if you prefer, you can make a new diff that adds prettier to this lib so that this diff is much smaller.
either way, hoping to get this solved / fix today.  be in touch.

solved!  https://github.com/benjaminhoffman/gatsby-plugin-mailchimp/commit/7f73fd827b3da383bfabe815ac3dea73de9daf4d
closing this.


pixel streaming is stuck

Component your question relates to

[x] Signalling server
[x] Frontend library
[x] Frontend UI library
[ ] Matchmaker
[ ] SFU
[ ] This repo
[ ] Other

Background
When my game screen is at 4k resolution, pixel streaming is available, but when I set the game screen to 5k resolution, pixel streaming is stuck, and the frontend information shows "webrtc connected, waiting for video"
Question
Is there any way I can set the game screen to be 5k, but the pixel streaming screen to be 1k?
Additional context

Hi there!
Unfortunately, there isn't anything out of the box to separate the game/application resolution and the stream resolution. They are tied together by default.
However, if you're comfortable changing C++, the FinalScale parameter could be set to some multiplier in Engine\Plugins\Media\PixelStreaming\Source\PixelStreaming\Private\PixelStreamingVideoInputRHI.cpp

Extra bit of info:
Pixel Streaming has a maximum for 4096x4096 encoding resolution. 5k encoding is not supported on enough GPUs yet, so that is why the stream cannot connect - the frame cannot be encoded.


Update head for StereoGram Pull Request to TensorFlow repository

Update Local copy to latest TensorFlow prior to StereoGram pull request.

Can one of the admins verify this patch?

Wanted to pull current Tensorflow to my repo.  Error, closing.


Xcode crashes on welcome screen

If there is no project opened, Xcode crashes right as you highlighting "Gitflow" item in main menu.

It crashes because there is no projectDirectoryPath.


Receiving error when the project starts

After pressing play on the project, I'm receiving this error. I did not change anything, everything is default.
Invalid get index '_height_view' (on base: 'null instance').. Line 494 of Grass.gd

I originally downloaded this from the GitHub page. It seems to work now after downloading it from AssetLib.


Why does luajit's LUA_PATH not include ?;?.lua?

Describe the bug
The LUA_PATH set by luajit's setup hook does not include the default value ?;?.lua (documented here), so relative imports from the current directory do not work.
To Reproduce
Create two files:
==> a.lua <==
print(require('b'))

==> b.lua <==
return "hi!"

~ $ nix-shell -p luajit
[nix-shell:~]$ which luajit
/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/bin/luajit
[nix-shell:~]$ echo $LUA_PATH
/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/lib/lua/5.1/?.lua;/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/share/lua/5.1/?.lua;/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/share/lua/5.1/?/init.lua;/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/lib/lua/5.1/?/init.lua
[nix-shell:~]$ luajit a.lua
luajit: a.lua:1: module 'b' not found:
	no field package.preload['b']
	no file '/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/lib/lua/5.1/b.lua'
	no file '/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/share/lua/5.1/b.lua'
	no file '/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/share/lua/5.1/b/init.lua'
	no file '/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/lib/lua/5.1/b/init.lua'
	no file '/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/lib/lua/5.1/b.so'
	no file '/nix/store/bafy33kb1drwgcdr031vhjl84ls0sni5-luajit-2.1.0-2020-12-28/share/lua/5.1/b.so'
stack traceback:
	[C]: in function 'require'
	a.lua:1: in main chunk
	[C]: at 0x004062c0

Expected behavior
From a non-nixos system (Arch):
~ $ which luajit
/usr/bin/luajit
~ $ echo $LUA_PATH
# unset
~ $ luajit a.lua
hi

Additional context
For some reason, nix-shell -p luajit sets a LUA_PATH but nix-shell -p lua does not. I don't really understand that.
Notify maintainers
@thoughtpolice @grwlf @vcunat @andir @lblasc
Metadata

system: "x86_64-linux"
host os: Linux 5.10.15-arch1-1, Arch Linux, noversion
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.4pre20200721_ff314f1
channels(root): "nixpkgs-21.03pre246046.41c0f496810"
channels(jamie): ""
nixpkgs: /home/jamie/Projects/nixpkgs (master)

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

its a bug I think. Tue LUA_PATH setup could be cleanupd/improved if you feel like it: https://github.com/teto/nixpkgs/blob/e87f466cc589698023c984446c0e26aa20fdc02b/pkgs/development/interpreters/lua-5/interpreter.nix#L24

I kinda want to give this a shot, but I'm not sure how it would work given that I already have a PR that is adding me to the maintainers list.

also, we should try to match the default path of lua, which includes ;./?.lua;./?/init.lua, otherwise we might end up introducing other confusing bugs.

Cross-link: PR https://github.com/NixOS/nixpkgs/pull/286822

fixed on master


fix checkout the pr, not the base

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Automated Package Upgrade

:tada: This PR is included in version 25.4.88 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Failed installation in Mac Envrionement

Hello,
I got the following error messages launching Kelner server. The message says libmagic is need and therefore I installed libmagic to my Mac envrionment  with brew install libmagic but still have the same problem. Would be helpful
kelnerd -m tensorflow_inception_graph.pb --engine tensorflow --input-node ExpandDims --output-node softmax
Traceback (most recent call last):
  File "/Users/takahi-i/.pyenv/versions/3.6.0/bin/kelnerd", line 7, in <module>
    from kelner.cli import kelnerd
  File "/Users/takahi-i/.pyenv/versions/3.6.0/lib/python3.6/site-packages/kelner/cli.py", line 4, in <module>
    from . import client
  File "/Users/takahi-i/.pyenv/versions/3.6.0/lib/python3.6/site-packages/kelner/client.py", line 4, in <module>
    import magic
  File "/Users/takahi-i/.pyenv/versions/3.6.0/lib/python3.6/site-packages/magic.py", line 181, in <module>
    raise ImportError('failed to find libmagic.  Check your installation')
ImportError: failed to find libmagic.  Check your installation

Could you send the output of this command: brew info libmagic?
I get this:
libmagic: stable 5.33
Implementation of the file(1) command
https://www.darwinsys.com/file/
/opt/brew/Cellar/libmagic/5.32 (299 files, 6.0MB)
  Built from source on 2017-11-08 at 16:14:01
/opt/brew/Cellar/libmagic/5.33 (305 files, 6.2MB) *
  Built from source on 2018-04-27 at 11:38:31
From: /opt/brew/Library/Taps/homebrew/homebrew-core/Formula/libmagic.rb
==> Dependencies
Optional: python@2 ✔
==> Options
--with-python@2
        Build with python@2 support

I think I can remove the libmagic dependency, which should solve your issue.

Sorry for the late response. The following is the results  of brew info libmagic.
brew info libmagic
libmagic: stable 5.33
Implementation of the file(1) command
https://www.darwinsys.com/file/
/opt/brew/Cellar/libmagic/5.33 (305 files, 6.2MB) *
  Built from source on 2018-07-11 at 15:44:58
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/libmagic.rb
==> Dependencies
Optional: python@2 ✘
==> Options
--with-python@2
        Build with python@2 support

Until I remove the dependency, I can see two possible causes:
I'm not sure what the ✘ in your libmagic installation means:
Mine:Optional: python@2 ✔
Yours: Optional: python@2 ✘
But it seems other people had this problem too: http://www.brambraakman.com/blog/comments/installing_libmagic_in_mac_os_x_for_python-magic/
Anyway, I'm removing the dependency: https://github.com/lunardog/kelner/pull/5

I confirmed that the latest Kelner works in my environment. Thanks!


Add Ceph RBD to list of storage providers

Current coverage is 7.45% (diff: 100%)

Merging #705 into master will not change coverage

@@            master      #705   diff @@
========================================
  Files           21        21
  Lines         2577      2577
  Methods          0         0
  Messages         0         0
  Branches         0         0
========================================
  Hits           192       192
  Misses        2368      2368
  Partials        17        17

Powered by Codecov. Last update a20a838...e42c057

Hi @codenrhoden,
Can you rebase this onto master so I can merge this? I missed it earlier, I apologize.

@akutz - done!


Let's Encrypt certificates

We currently rely on CloudFlare Full SSL for the TLS certificates for shields.io and img.shields.io.
It means that the individual servers use self-signed certificates, which CloudFlare connects to, and CloudFlare produces its own certificates that apply to shields.io and *.shields.io for inbound traffic from the rest of the Internet.
Using authentic Let's Encrypt certificates instead of the self-signed ones may finally make the monitoring endpoint work. It currently fails because the websocket connection expects a valid certificate.
apt install certbot python-pip
pip install certbot certbot-dns-cloudflare
# TODO insert export env variables
certbot certonly --email XXXX -d shields.io -d img.shields.io --dns-cloudflare --test-cert

Note: Let's Encrypt does not yet support wildcard DNS; see https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html.
Current issue:
$ certbot plugins
An unexpected error occurred:
VersionConflict: (certbot 0.19.0 (/usr/lib/python2.7/dist-packages), Requirement.parse('certbot==0.21.0'))
Please see the logfile '/tmp/tmpSay7_c' for more details.
$ lsb_release -a | grep Release
Release:	16.04

Related: https://github.com/badges/shields/issues/608

Note: Let's Encrypt does not yet support wildcard DNS;

They do now! I've tested wildcard DNS with Let's Encrypt and they work great :)

I'm using acme-dns and certbot 0.22.2

Resolved via #4929. 😌


Dot notation data input

The multiselect shall accept Data in the Dot Notation Comma separated format.

Not a real input. Removing


[PORT] logPersonalInformation flag missing in QnAMakerDialog

Describe the bug
The class QnAMakerDialog  is missing the logPersonalInformation flag which is present in C#. This causes, among other things, issues with telemetry reporting in Power BI.
The flag, in turn, is not being passed by constructor to QnAMaker in the method getQnAClient, unlike the behavior in C#.

Expected behavior
The class QnAMaker should have parity with C#, and telemetry should be being reported.
Additional context

This problem was reported in a comment of issue microsoft/botframework-solutions#3612.
This is the PR where the logPersonalInformation property and other telemetry changes were added in C#

@stevengum , @EricDahlvang, could one of you take a look?

@matiasroldan6 , can confirm that you are correct, we are missing logPersonalInformation in QnAMakerDialog.getQnAClient().
Looks like the JS SDK also fails to pass along options as well.
Working on a fix now.


Drop chance added to external pages

DO NOT MERGE until we can deploy the following:
-- Prepare drops table
alter table mhhunthelper.drops add column drop_count int, add column min_amt int, add column max_amt int;
DROP PROCEDURE IF EXISTS mhhunthelper.update_drops;

DELIMITER $$
$$
CREATE<EMAIL_ADDRESS>PROCEDURE `mhhunthelper`.`update_drops`(
	IN `table_name` VARCHAR(255),
	IN `from_time` VARCHAR(255),
	IN `until_time` VARCHAR(255)

)
BEGIN

CALL exec_query(CONCAT('DROP TABLE IF EXISTS mhhunthelper.drops', table_name, '_temp;'));
CALL exec_query(CONCAT('CREATE TABLE mhhunthelper.drops', table_name, '_temp LIKE mhhunthelper.drops;'));
CALL exec_query(CONCAT('ALTER TABLE mhhunthelper.drops', table_name, '_temp AUTO_INCREMENT=1;'));

CALL exec_query(CONCAT('INSERT INTO mhhunthelper.drops', table_name, '_temp (location_id, loot_id, cheese_id, stage_id, total_drops, drop_count, min_amt, max_amt)
SELECT h.location_id, hl.loot_id, h.cheese_id, hs.stage_id, SUM(hl.amount), count(hl.amount), min(hl.amount), max(hl.amount)
FROM (
	SELECT h2.id, h2.location_id, h2.cheese_id, h2.extension_version, h2.timestamp
	FROM mhhunthelper.hunts h2
	WHERE h2.timestamp > (unix_timestamp(now()) - 25920000)
	ORDER BY h2.id DESC) AS h
INNER JOIN mhhunthelper.hunt_loot hl ON h.id = hl.hunt_id
LEFT JOIN mhhunthelper.hunt_stage hs ON h.id = hs.hunt_id
WHERE h.extension_version >=11107 ', from_time, until_time, '
GROUP BY h.location_id, hl.loot_id, h.cheese_id, hs.stage_id
HAVING COUNT(DISTINCT h.id) >= 2;'));

CALL exec_query(CONCAT('UPDATE mhhunthelper.drops', table_name, '_temp s
INNER JOIN (
	SELECT COUNT(DISTINCT h.id) AS total_hunts, h.cheese_id, h.location_id, hs.stage_id, SUM(h.caught) as total_catches
	FROM mhhunthelper.hunts h
	LEFT JOIN mhhunthelper.hunt_stage hs ON h.id = hs.hunt_id
	WHERE h.extension_version >=11107 AND h.timestamp > (unix_timestamp(now()) - 25920000) ', from_time, until_time, '
	GROUP BY h.location_id, hs.stage_id, h.cheese_id
	) a ON s.location_id = a.location_id AND s.cheese_id = a.cheese_id AND s.stage_id <=> a.stage_id
SET s.rate = ROUND(s.total_drops/a.total_hunts*1000), s.total_hunts = a.total_hunts, s.total_catches = a.total_catches, s.rate_per_catch = ROUND(s.total_drops/a.total_catches*1000);'));

START TRANSACTION;
CALL exec_query(CONCAT('RENAME TABLE mhhunthelper.drops', table_name, ' TO mhhunthelper.drops', table_name, '_old;'));
CALL exec_query(CONCAT('RENAME TABLE mhhunthelper.drops', table_name, '_temp TO mhhunthelper.drops', table_name, ';'));
COMMIT;

CALL exec_query(CONCAT('DROP TABLE IF EXISTS mhhunthelper.drops', table_name, '_old;'));

END$$
DELIMITER ;

Then we will have to update all the drop tables (script below). But because update_drops stored proc has a minimum extension version level in it the old event tables would be empty. So they're either empty or broken or we populate those tables without the version restriction.
CALL update_drops('', '', '');
CALL update_drops('_3_days', ' AND h.timestamp >= (unix_timestamp(now()) - 259200) ', '');
CALL update_drops('_1_month', ' AND h.timestamp >= (unix_timestamp(now()) - 2592000) ', '');
CALL update_drops('_3_months', ' AND h.timestamp >= (unix_timestamp(now()) - 7776000) ', '');

CALL update_drops('_bday_18' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_bday_19' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_bday_20' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_gwh_18' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_gwh_19' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_hlwn_18' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_hlwn_19' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_lny_19' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_ronza_19' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_seh_18' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_seh_19' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_seh_20' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_stpatty_18' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );
CALL update_drops('_val_19' , ' AND h.timestamp >=<PHONE_NUMBER>', ' AND h.timestamp <=<PHONE_NUMBER>' );

We could create an "update_drops_old_events" or something without the extension version requirement - figuring "we get what we get".

Stored procs deployed. All aggregate drop tables have been updated and have the new columns (well, the ones I spot-checked) and data.
Added a new update_drops_novers SP that only looks at the timestamps passed in - to be used to retrofit really old events should an update like this happen in the future. It also ignores the extension version and doesn't have the "last X months" default filter on it.
I'd still like to rewrite that proc so it only puts that filter on if it doesn't have a minimum time to evaluate but that's for another time.


Google Home cover not opening for 1 of 2 users

Home Assistant release with the issue:
0.92.2
Last working Home Assistant release (if known):
None
Operating environment (Hass.io/Docker/Windows/etc.):
RPi hass.io
Component/platform:
nabu casa
Description of problem:
Google Home successfully opens and closes the garage doors using a PIN for me, but always fails when my wife asks.  It asks her for the PIN, then responds with "It looks like hass.io is unavailable right now" every time.  We do have our voices trained for GH and are sharing the GH home account access as admin users so she sees what I see on any device sync.  Prior to requiring PINs open and close of the doors worked for both of us.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
cover:
  - platform: garadget
    covers:
      3a0057000651353530333533:
        username: !secret garadget_username
        password: !secret garadget_password
        name: Single Garage
      29005b000351353432383931:
        username: !secret garadget_username
        password: !secret garadget_password
        name: Double Garage

cloud:
  google_actions:
    filter:
      include_entities:
        - group.all_lights
        - group.garage_doors
      include_domains:
        - cover
        - light
      exclude_domains:
        - camera
        - climate
        - fan
        - group
        - input_boolean
        - media_player
        - scene
        - script
        - switch

Traceback (if applicable):
Nabu casa debug logging from HA snippet for the failed requests.
2019-05-05 10:12:32 DEBUG (MainThread) [hass_nabucasa.iot] Received message:
{'handler': 'google_actions',
 'msgid': '63655a65-89d3-4c9b-820b-ab74dfa62a50',
 'payload': {'inputs': [{'context': {'locale_language': 'en'},
                         'intent': 'action.devices.EXECUTE',
                         'payload': {'commands': [{'devices': [{'id': 'cover.double_garage'}],
                                                   'execution': [{'command': 'action.devices.commands.OpenClose',
                                                                  'params': {'openPercent': 100}}]}]}}],
             'requestId': '3477064171931396590'}}

2019-05-05 10:12:32 DEBUG (MainThread) [hass_nabucasa.iot] Publishing message:
{'msgid': '63655a65-89d3-4c9b-820b-ab74dfa62a50',
 'payload': {'payload': {'commands': [{'challengeNeeded': {'type': 'pinNeeded'},
                                       'errorCode': 'challengeNeeded',
                                       'ids': ['cover.double_garage'],
                                       'status': 'ERROR'}]},
             'requestId': '3477064171931396590'}}

Additional information:

Can you give me some information on language used?

Me: Hey Google, open the single garage. --> Good, asks for PIN then opens.
Wife: Hey Google, open the single garage. --> Error, asks for PIN then gives error.
Me / Wife: Hey Google, close the single garage -->, Good, closes.

I actually meant the language you speak to it 😅, are you speaking English? And may I ask in what country you are using Google Assistant?
I've also escalated this bug to Google to confirm.

We are speaking English to it, in the US, both the Google email ids were originally registered in Canada many years ago.


IGC Repo Proxy - SemanticAsignment triggers multiple events

A semantic assignment triggers multiple OMRS events: UPDATED_ENTITY(3), NEW_RELATIONSHIP(1), UPDATED_RELATIONSHIP(2).
Are all events necessary? This could add some overhead on omrs/omas's level.

Browsing through the latest set of sample payloads (after the type simplification from TypeEmbeddedAttribute and NestedSchemaAttribute) this duplication appears to be resolved -- at least for these SemanticAssignment examples.
Will close for now, but suggest we open a new issue if we identify any duplication elsewhere.


Custom wallet (ts) for Magic.link

Integrating ThirdwebSDK with Quartz:
import { ThirdwebSDK } from "@3rdweb/sdk";
import { ethers } from "ethers";
import { Magic } from "magic-sdk";

const magic = new Magic()

// Magic.link wallet -> will be making the sdk contract calls
const provider = new ethers.providers.Web3Provider(magic.rpcProvider);
const signer = provider.getSigner();

// Initialise the SDK instance with magic.link signer
const sdk = new ThirdwebSDK(signer);

// Access any modules using the SDK
sdk.getNFTModule("0x...");

https://github.com/Signal-K/ls-cli/issues/15
https://github.com/Signal-K/starsailors-boilerplate/issues/3
https://github.com/Signal-K/Unity-WebGL-Demo/issues/1
https://github.com/Signal-K/marketplace/issues
New commit incoming referencing these!!


promql: fix "cannot reduce resolution to custom buckets schema" panic in rate over native histograms with mix of custom and exponential buckets

If rate is used over a range of native histograms with both custom and exponential buckets, a panic can occur.
I've also modified the behaviour of the test scripting language to check for query errors before warnings: if the query failed to evaluate, it's more useful to see the failure rather than the fact that warnings were or weren't present.

Thank you. Related to #13494

Also somewhat related: #14168


Add support for backing up mssql transactional log files

name: Backing up mssql transactional log files
about:

Description of the feature
Right now it only takes a full backup of the database. With this feature it will backup transactional logs.
Benftits of feature

This will allow minimal data loss in the event of database failure/corruption.
And this will also ensure that transaction logs are automatically truncated by mssql, which can grow 10s of gbs.

Taking full backups every 15 minutes is not practical for fairly large databases. This way a full back up is taken every hour or every night. And every 15 minutes only new transactions are backed up.
Additional context
This feature is already available in this repo here. The bash script is already there, just need to adopt it for this awesome image.
I can test it out if someone can implement it.

Coming in upcoming version 4.x relase.


Running code actions on save is very slow and breaks imports

VS Code version
1.89.0
Extension version
2.2.2
Biome version
1.7.3
Operating system

[ ] Windows
[X] macOS
[ ] Linux

Description
When noUnusedImports is enabled, running code actions on save (source.organizeImports.biome + quickfix.biome) is slow and breaks the imports.
Steps to reproduce
Full reduced test case: https://github.com/OliverJAsh/biome-vscode-quickfix-import-issue/compare/1.7.3. Contents inlined below.
Given:
biome.json:
{
    "$schema"<EMAIL_ADDRESS>    "linter": {
      "enabled": true,
      "rules": {
        "correctness": {
          "noUnusedImports": "warn"
        }
      }
    }
  }

.vscode/settings.json:
{
  "editor.codeActionsOnSave": {
    "source.organizeImports.biome": "explicit",
    "quickfix.biome": "explicit"
  }
}

index.ts:
// @ts-nocheck

import * as APIClientError from 'app/services/api/APIClientError';
import { TPhotoSlug, Codec } from 'app/services/api/Photo/types/PhotoSlug';

APIClientError;
export type F = TPhotoSlug;

// edit this comment and save the file

When I save index.ts and "code actions on save" runs, I notice two things. Firstly, it feels much slower than I would expect it to be. It adds about 500ms-1s to the save operation (see screen recording below). Secondly, I end up with broken imports—this is similar to https://github.com/biomejs/biome-vscode/issues/179 although note here I'm using the latest version of Biome which—I understand from https://github.com/biomejs/biome/issues/688—is supposed to include the fix.
// @ts-nocheck

import * as APIClientError from 'app/services/api/APIClientError';
import { TPhotoStype lug } from 'app/services/api/Photo/types/PhotoSlug';

APIClientError;
export type F = TPhotoSlug;

// edit this comment and save the file

https://github.com/biomejs/biome-vscode/assets/921609/7b68b97b-47ef-465c-b387-78e1736a4dab
Expected behavior
Save is fast + imports are not broken.
Does this issue occur when using the CLI directly?
Not sure / Not applicable
Logs
No response

Closing as duplicate of https://github.com/biomejs/biome-vscode/issues/229

@nhedger https://github.com/biomejs/biome-vscode/issues/229 seems to focus on performance, however my issue above also describes an issue with imports breaking. Can we re-open this and update the title?
I can still reproduce this issue on the last version (1.9.4): https://github.com/OliverJAsh/biome-vscode-quickfix-import-issue/compare/1.9.4

Sure, but in that case it belongs in the main repo. I'll move it


Removing Lint Issues

dev:
lint-issues: 50
test-coverage: 85%
lintissues:
lint-issues: 0
test-coverage: 85%

Thanks, pls deploy


using conversations endpoint instead of channels; treat all channels …

…the same

@ambulatorymerperson Cool, looks simple enough.
Just confirming. The conversations api method will work on both public and private channels. You tested this locally?

@jolexa testing now

@jolexa it works! :) https://pagerduty.slack.com/messages/CEN3LCCS2/


Document how to use OpenTelemetry with Nest

We have received multiple bug reports from NestJS users that OpenTelemetry is not working for them and it frequently turns out that it is a misconfiguration. Clearly document that OTel needs to be loaded before nest in order for it to work.

We have received multiple bug reports from NestJS users that OpenTelemetry is not working for them and it frequently turns out that it is a misconfiguration. Clearly document that OTel needs to be loaded before nest in order for it to work.

Could you give an example  or documentation to implement it in NestJs?

I implement a mini project here


Added new styles with tailwind

Removed the default styles.css and implemented something else with Tailwind for the main page.

LGTM


Bad credentials when downloading using @prisma/fetch-engines

Bug description
I am using Prisma as part of AWS Lambda deployed with serverless. When packaging the project, we have a custom step (as a javascript file) which downloads prisma engines. Starting today, this step doesn't work anymore because of bad credentials from the CDN hosting the engines.
How to reproduce
const { download } = require('@prisma/fetch-engine');

await download({
  binaries: {
    'migration-engine': resolve('./node_modules/@prisma/engines/'),
  },
  binaryTargets: ['rhel-openssl-1.0.x'],
  ignoreCache: !0,
  printVersion: !0,
  failSilent: !1,
  showProgress: !0,
  progressCb: (e, n) => {...},
})

The errors that I get:
{
  message: 'Bad credentials',
  documentation_url: 'https://docs.github.com/rest'
}

from:
.../node_modules/@prisma/fetch-engine/dist/getLatestTag.js:54
    throw new Error(`Could not fetch commits from github: ${JSON.stringify(commits, null, 2)}`);

URL which cannot be reached:
https://github-cache.prisma.workers.dev/repos/prisma/prisma-engines/commits?sha=${branch}
Expected behavior
No response
Prisma information
my package.json:
"@prisma/client": "^4.7.1"
"prisma": "^4.7.1"
"@prisma/fetch-engine": "^4.7.1"

Environment & setup

OS: Ubuntu
Database: Postgres
Node.js version: 16.15.1

Prisma Version
prisma                  : 4.7.1
@prisma/client          : 4.7.1
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 272861e07ab64f234d3ffc4094e32bd61775599c (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 272861e07ab64f234d3ffc4094e32bd61775599c (at<EMAIL_ADDRESS>Introspection Engine    : introspection-core 272861e07ab64f234d3ffc4094e32bd61775599c (at<EMAIL_ADDRESS>Format Binary           : prisma-fmt 272861e07ab64f234d3ffc4094e32bd61775599c (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.7.1-1.272861e07ab64f234d3ffc4094e32bd61775599c
Default Engines Hash    : 272861e07ab64f234d3ffc4094e32bd61775599c
Studio                  : 0.477.0
Preview Features        : interactiveTransactions

Indeed, it should be fixed, It was due to an expired GitHub token on that worker.

You should be able to prevent on this supposedly internal web service by providing an explicit version to the function. Only when non is provided it assumes latest and then talks to this API to get the latest version. That is most probably a thing you do not want your build pipeline to rely on anyway - it might not match the Prisma version of your app you are building and hence could introduce subtle bugs.
Can you share what exactly you are doing in that serverless build pipeline? That sounds interesting to understand for us. This code was definitely not written for that use case :D

@janpio @Jolg42 Thank you for responding, I will be able to test again in several hours.
First of all, I would like to ask you if there's any recommendation on how to stick to downloading fixed version.
The way we use it is basically like this:

serverless packager calls custom script
custom script downloads these engines so they can be packaged
the code gets deployed to AWS Lambda which is then invoked to run/apply migrations on the DB

Is there any better/recommended way to package these engines into an AWS Lambda which has only one purpose which is running the migrations?

latest, or not providing a version, is actually not fixed. You should provide an explicit version there if possible.
The "normal" way to deal with your problem (that you want to have rhel-openssl-1.0.x engine files when developing somewhere else) is probably to use binaryTargets in the generator block of your Prisma schema, and then run a command locally that downloads the appropriate engine - like prisma generate.
As you mention that you need the migration engine, a command to trigger that download would be for example prisma -v as that will make sure all of them are present. There the binaryTargets of the schema are not used though. You can probably use this environment variable: https://www.prisma.io/docs/reference/api-reference/environment-variables-reference#cli-binary-targets The example shows this already influencing npm install, so maybe you do not even have to call any command.
Does this help?

@janpio Thank you, this is helpful 👍


Clear draw buffer after creation and resize.

I've been working on fixing the scissor test for https://github.com/servo/servo/pull/14075 and found that the GLContexts are not cleared after creation. That's why that test is failing now (after fixing what the spec says about scissor).
I'm adding the clear changes here because I think that clearing the created framebuffer is a good default for any project.  I had a lot of problems in the past with buggy Adreno GPUs on Android because of this. A initial clear is a safeguard to avoid problems. Some Adrenos were such bad that even required clearing the Depth/Stencil even if the buffer is neither created and used.

I don't think we can call ClearColor here, or at least we should restore the clear color on the WebGL implementation, right?
Otherwise we're changing the underlying state of the GL context under the hood, and I while I think Viewport and Scissor are probably fine to do on resize, ClearColor is more dubious to me.
What do you think?

Yeah, that can be a problem in the resize method. It's not a problem in the init because a transparent color is the default one.
We can restore the ClearColor from WebGL (we are restoring scissor value too now to mach the Spec).

Ok, r=me with that in Servo then.

Ok, please bump version ;)

Done :P.
Next time feel free to PR the version bump too.