Plasma alternative REP

This .md is our REP-002 to allow third-party object store as a Plasma alternative. We propose to provide a plasma-like object store with more functionalities target for different situations.
Related Issues: #22948 and #22795.

@zhe-thoughts Should we comment on this PR or  create a corresponding issue for comments. What's the process here? Does merging the PR means the REP is approved?

To @jjyao 's question: the designated Shepherd should work with the proposer to merge the PR. Then the reviews should happen on the corresponding GH issue.

If I understand the process correctly, we need to first finalize the design before merging this PR.

I think there are two parts not so clear to me:

We propose to define a protocol here that both vineyard and plasma should agree. For example, the protocol will define when a object adds/remove its reference, when object can be evicted/spilled. In other word The protocol defines the impact on lifecycle management in server-side when calling the above ClientImplInterface API in client-side. Since most of concerns about the integration may happens in this part, we may need further discussions about these protocols.

Can you clarify about the protocol?

Object spilling

When creating a new object with insufficient memory even with evicting possible objects, the local object manager will try to spill objects to external storage. The code path of spilling is out of Plasma (via callback) thus we can reuse it in third-party object-store.
Protocol #5: The spilling only happens in a object creation.(we trigger spilling when memory usage > threshold(triggle)) (spill)
Protocol #6: The spilling only happens when eviction can not meet the requirement. (create object will first trigger eviction)
Protocol #7: The spilling only happens in primary objects.(the spill_objects_callback will handle the spillng).
Also today plasma spilling calls back to Ray when it runs out of memory. It's not clear to me in this design doc, and also it requires some API change as well.

Can you clarify about the protocol?

The protocols here mean the side-effect on object lifecycle of the API defined in the REP, since the lifecycle management is hidden on the server-side, we need to clarify what will happen on lifecycle when we call the client APIs. For example, the reference count will increase ONLY when we call Get() or CreateAndSpillIfNeeded(), and decrease ONLY when we call Disconnect() or Release(). So we list eight protocols below, defining how the lifecycle of a plasma object changes when we call the APIs. If we do the same on the third-party object
store, the raylet and core worker can expect it performs the same as plasma does. In another word, these protocols guarantee that if an object is deletable, evictable, or spillable in plasma, then it is also deletable, evictable, or spillable in a third-party object store.

Also today plasma spilling calls back to Ray when it runs out of memory. It's not clear to me in this design doc, and also it requires some API change as well.

Today the spilling of plasma relies on the callback. A PlasmaStoreRunner is running on a thread within raylet. Triggering the callback will directly call the methods in raylet. As a separate process, a third-party object store is unable to do so. Thus we are going to put a PlasmaProxy on a thread in Raylet instead of the PlasmaStoreRunner. When triggering the callback in the third-party object store, it will send a request to the PlasmaProxy via IPC thus it can call the methods in raylet like plasma does so. Maybe we do not require API changes in the current client interface (a third-party object store will not do spilling itself, it only triggers spilling with a given threshold. In such a situation, a third-party object store will send a request to PlasmaProxy to trigger the spilling callback).

Thanks for the clarification. The reference counting part makes a lot of sense.
Should we get a bit more concrete into the spilling part as it's also important here? also cc @rkooo567 on this.

Hi, @scv119 I think we can always replace all the function call with blocking IPC request for the interaction between plasma and ray. Suppose the spilling only relies on callbacks, and the ray does not directly call plasma functions. In that case, I think it is ok to do the replacement by introducing some IPCs between PlasmaProxy and the third-party object store(trigger the spilling in PlasmProxy). In the WORST case, we can allow the third-party object store to ignore all the spilling, which means the third-party object-store never triggers spilling in object creation, I think it is still functional somehow(If we treat the spilling ability as the unique feature of plasma. Instead, the third-party will provide other features). So could you elaborate on what is your concern?

Yup; we need to decide where the spilling happens.

option 1, spilling happens above the storage implementation (as of today). If that's the case, we need define the API that the storage that triggers spilling.
option 2, spilling happens inside the storage. For this we need revisit current Ray's assumption around spilling. There are a bunch of features build around spilling happens outside of storage (such as object transfer, spill manager etc) and they may or may not break.

We do not intend to change the today spilling mechanism of ray, since it is a little heavy to do so in these PRs. Thus option 1 looks more attractive to me. So, does option 1 mean the client-side will take initiative to trigger spilling? I think the current API may be the CreateAndSpillIfNeeded() which will trigger spilling when space is not enough during object creation. A third-party object-store will check the usage of storage can decide whether to trigger the spilling. Is this API enough for spilling? As for vineyard, we will add a new handle to process the CreateAndSpill request in the vineyard codebase.

I think the proposal itself sounds reasonable. But my biggest concern is if the existing behaviors / APIs are stable enough to settle on protocol / APIs.
It seems like there are some arbitrary APIs. For example, the semantics of Delete or Abort vs Delete. The protocol itself also seems to just fit into existing implementation (which is reasonable); but my question is, do we plan to improve this sooner or later? @scv119

A summary to the concerns above:
Q1: Visbility

Wouldn't this break all invariants within Ray when you start a new raylet though (there could be lots of duplicated object ids for example)? Do you plan to not restart a new raylet? Maybe we need to at least make object id not deterministic to make this work?  (by @rkooo567)

I think third-party object stores should not break the invariants within Ray.
[with visbility] For a vineyard-like third-party object store that has a session/visibility/isolation mechanism, we can open a new session for each raylet (it is ok to have duplicated object ids that are separated in different sessions.)
[w/o visbility] For other third-party object stores which do not provide such isolation control. we can add prefixes to the duplicated object ids to distinguish them (this should be handled in xxxClinetImpl which inherits the ClientImplInterface).
Q2: Failure

Can we add a section about failure modes: what happen if raylet crashes, can worker still get objects from the third-party object store, what happens if third-party object-store crashes, etc. I'm worried that a different failure mode than what ray code is depending on now may cause problems.  (by @jjyao )

I think the third-party objects' failure mode should be consistent with plasma: which means it should behave the same as plasma when object-store/raylet crashes. We introduce XXXPlasmaProxy to handle the failure. The Third-party should provide an internal mechanism to block the connection when XXXPlasmaProxy runs into issues.
[Situation 1] When raylet crashes, workers can not get objects from the third-party object-store. Since the third-party object store will know it via the heartbeat of XXXPlasmaProxy, then it will close the connection of the related client (the same session of XXXPlasmaProxy ). This is a recoverable failure for the vineyard, when the raylet restart, it can connect to the previous session.
[Situation 2] When the third-party store crashes, the worker will not able to use the objects. The XXXPlasmaProxy will also know the fate of third-party object-store just like Situation 1. Since the XXXPlasmaProxy is running on a thread of raylet, it can complain just like plasma runner crashes. This is an unrecoverable failure for the vineyard. Since Raylet can not control the fate of the vineyard.
[Situation 3] When the XXXPlasmaProxy crashes, the third-party store will behave like the raylet crashes, it will close the connection, forbid the clients in the same session to get objects. the raylet will behave like the object store crashes, it will throw exceptions just like the original plasma runner. This is a recoverable failure for the vineyard, raylet can restart PlasmaProxy, then connect to the previous session.
Q3: Spilling

Shouldn't each object store have their own spilling implementation (e.g. where to spill, whether encryption is needed), clients only control what is spillable or not? (by @jjyao )

As for now, I think we have two options for spilling implementation:
[Option 1] Follow the current implementation. spilling is provided by raylet (in the form of callback), and the spillable query is provided by object-store. We can delegate the XXXPlasmaProxy to execute the callback in a thread of raylet. Third-party object stores send requests to XXXPlasmaProxy  when the space is not enough. We have a lot of callbacks here, which means we do have to introduce IPCs here. I think this is a straightforward way to achieve our goal.
[Option 2] Refactor the current implementation and move all the spilling code-path to the store-side. clients only control what is spillable. I think this is more clear for the object store interface, since spilling an object falls within the ambit of an object store rather than the object manager. However, I think we should not include the change of spilling mechanism in this REP, since it is orthogonal to our proposal. Maybe someone can start another proposal? we are also willing to get involved in the spilling refactoring.
Q4: PlasmaProxy

I think we need to define the PlasmaProxy IPC protocol in this doc as well. Is PlasmaProxy generic for all object stores or we will have XXXPlasmaProxy for each object store? (by @jjyao )

Also the callback will have an IPC overhead instead of current in-process function call, we may need to discuss performance as well. (by @jjyao )

Yes, we will have XXXPlasmaProxy for each object store, I think this is more maintainable and clear to implement the integration of the third-party object-store. Maybe we can have a virtual class PlasmaProxyInterface here (should be added to this REP later). As for vineyard, VineyardPlasmaProxy will take the callbacks(spilling, add, delete, ...) into the Start() method, and execute them when required.
[callback overhead], I think the cost of a callback depends on the underlying store implementation. The abstraction here can be compatible with different object-store. For plasma, the PlasmaProxy will execute the callback via in-process function calls, for standalone store services like vineyard, the VineyardPlasmaProy will execute the callback via IPC. Supporting the third-party object store will not incur a performance hit for the current code path (plasma-version).
Q5: hidden/implicit assumptions/dependencies

I think besides the explicitly defined PlasmaClientInterface, we also need to find all the hidden/implicit assumptions/dependencies Ray has on the object-store. One thing I can think of is the scheduler, currently, Ray treats object-store memory as a resource and it will try to avoid scheduling tasks on the node where the object store is almost full. Does this still work with third-party object-store especially when other systems will add objects to it that's out of the awareness of Ray. (by @jjyao)

Yes, that is why I introduce the protocols in this REP, trying to clear the assumptions Ray has on the object-store. For now, if Ray wants to interact with the underlying object store, it only has three kinds of ways:
[Client API] Raylet or core worker send requests to server-side and get what they want in reply. The third-party object-store can do the same as the interface/protocol defines in this REP, which just fits into the existing implementation (as mentioned by @rkooo567). I think the APIs/protocol in this REP is enough to be consistent with the plasma CLIENT.
[Callbacks] Raylet pass callbacks to the plasma server, thus server-side can execute the raylet methods. This can be handled by the XXXPlasmaProxy, as mentioned above
[Call method directly] Raylet directly call plasma server methods. This can also be handled by XXXPlasmaProxy we can implement all the PlasmaStoreRunner functions in XXXPlasmaProxy, and forward them to a third-party store in this case.
For the scheduler case mentioned by @jjyao, I believe that raylet must have to query (or compute) the usage of object store via the above ways. We can do the same in the third-party object store, either by adding an API in the client-side or a method in XXXPlasmaProxy. Anyway, I think we can always achieve the same functionality as plasma does for hidden/implicit assumptions/dependencies. But I really need your help to exhaust all cases that Ray has hidden dependencies on object store which are not captured by Client APIs, and We can implement these cases as unit tests for consistency check.
We will add more sections in REP later.

but I believe we use this to obtain the memory usage of the plasma store, and the reason why we use the direct function call is to avoid to obtain the stale memory usage. If this returns very stale memory usage, there's a possibility it will cause some issues in the memory management.

If the IPC of third-party object-store really obstacles the performance of ray scheduler (e.g. obtain the memory usage of the plasma store, and today ray design adopts the direct function call is to avoid to obtain the stale memory usage). We can share meta between ray and third-party object store via SHM. For example, the third-party object-store writes the memory usage to SHM after each creation/deletion, and the ray read the memory usage from SHM when required.

The first section seems to suggest opening a new session for all raylet restarts whereas the second section says to connect to the previous section.

The first section here means third-party object-store should keep "when the raylet is restarted, the storage should guarantee the object id from the previous raylet should be isolated to the new one". Vineyard can meet the requirement due to the session/isolation mechanism.
The second section here means that if we restart a raylet when crashes. If we set the plasma_store_socket_name of the previous session of vineyard, we can still get the objects before the crash happens. If the raylet restarts in a new session, then it can not see the objects before failure, and vinyeard has GC to handle the dangling objects for previous session.

Overall, the new failure model is still a bit confusing to me (e.g., raylet failure is recoverable for Vineyard perspective given what you are saying whereas plasma store doesn't have these semantics).

By saying ”the failure is recoverable for vineyard“ means vineyard can recover only when raylet and XXXPlasmaProxy crashes, but it can not recover when the vineyard itself crashes, because the vineyard is running on another process and ray can not restart it. This may be different from plasma store.

@rkooo567 @jjyao any more comments?

Hi, @scv119 @rkooo567 @jjyao, thanks for your comments! Do we reach a consensus or still need more discussion about this proposal？

Hmm, we should probably not merge REPs until they are approved by public vote in the future.

I also have concerns about the increasing complexity of the system. Right now, plasma store can just be an embedding store in Raylet which is simple and clean. Although, it’s like a service, we actually can make it just a component (easier to manage). With this change, it means we need to treat the plasma store as an independent service on each node so the lifecycle of these two will change dramatically.
I could like the system define a clean abstraction before implementating so that the maintenance cost is controllable. Could you add more details about this?

I have 2 questions here.

Is this meant to be an internal refactor? Or is this meant for users to plug different stores in?

If users are supposed to plug something in, how do they do that? Do they have to statically link? Dynamically link? Do we have to maintain ABI compatibility for a c++ interface?

My concern here is that this seems very difficult to maintain.

I'm also concerned about the maintainability of code and the stability of the invariants.
Previously, the invariants are just implementation details, and they did change various times. Now there's an external component that depends on this. What if we want to change the invariants in the future? How should we corporate? I'm worried the evolvement of object store may slow down due to this external dependency.
On the other hand, one thing I can think of that would benefit Ray but not mentioned in the REP, is that we can avoid cross-node data transfer on the same host if the Ray cluster is deployed on Kubernetes. Maybe we can go deeper about this.
Also curious about the real use cases.

@iycheng @wuisawesome @kfstorm. Thanks for your comments! I can see that most of the concerns are about maintainability. Actually, I think we have to make tradeoffs among maintainability, performance, and invariance when considering this proposal. Maintainability refers to good modularization and decoupling. Performance refers to fewer IPCs and fresher information for the scheduler. Invariance refers to keeping the behavior consistent with the current situation of plasma. IMHO, I think we can not achieve maintainability, performance, and invariance at the same time. So we have to make a choice, and this is what we are doing these weeks, trying to figure out what we have to retain and what we can release.
In the previous discussion, most of concerns are about invariance, such as to keep the same behaviors in failure model and spilling. So we try to list the invariances as @rkooo567 suggests.

It'll be great if we can get more details here with more high-level generalized invariants. For example, one of the invariants we should keep is "when the raylet is restarted, the storage should guarantee the object id from the previous raylet should be isolated to the new one".  (@rkooo567)

Another concern is about performance as @rkooo567 and @jjyao said:

and the reason why we use the direct function call is to avoid obtaining the stale memory usage. If this returns very stale memory usage, there's a possibility it will cause some issues in the memory management.(@rkooo567)
Also the callback will have an IPC overhead instead of a current in-process function call, we may need to discuss performance as well. (@jjyao)

So we try to minimize IPC calls and avoid getting "stale memory usage". This is why we introduce the XXXPlasmaProxy to retain the callbacks.
And now we come to the maintainability. But before addressing the concerns above, let's forget the current REP temporarily and think about how to make trade-offs among maintainability, performance, and invariance for integrating with a third-party object store. As mentioned above, we have three options here by choosing two of these three goals:

[Maintainability + Performance] As @iycheng suggests,  we can first decouple plasma from raylet, which means that before the integration with third-party object store, we need to move the code path of callbacks, spilling, life-cycle out of plasma (maybe into ObjectManager) and just make the plasma to be a clean and pure local object-store. This is a HUGE change that obviously breaks the invariance, but it is easy to maintain and easy to optimize for higher performance. If this option is chosen, we are also willing to get involved in the refactoring.
[Maintainability + Invariance] If you can tolerate more IPCs and stale memory usage, then we do have another option that does not change the plasma client interface nor add a new  XXXPlasmaProxy. We can just process the plasma client requests in the plasma store by forwarding the request to the vineyard server (or third-party object store). This means we need two IPC calls instead of one (request path: plasma client ---> plasma store/vineyard client ---> vineyard server). In this option, the change only happens in the plasma store, thus it is easy to maintain and naturally follows the invariance of the current situation.
[Invariance + Performance] This is the current solution of this REP, we do not intend to change any logic of plasma, and just follow what plasma does in raylet like spilling, lifecycle, and failure model. Plasma store today is not like @iychen said: "can just be an embedding store in Raylet which is simple and clean".  Actually, the Plasma store is a tightly-coupled with raylet, and it is running as a thread, passing callbacks in and out (ray/#8897),  and I don't know the evolution direction of plasma store, is it going to be more tight-coupling with raylet or completely the opposite? therefore the only thing I can do is to follow the current restriction.

I think we have to Make a Choice among the three options and reach a consensus on the trade-offs since I think it is hard to come up with a perfect plan (If you have any better ideas about the integration, please let me know, that will be quite helpful).

Now, we can address the concerns for option 3:

also could we build it on top of the current implementation instead of making the plasma store pluggable? (@iycheng)

Third-party object stores may have a variety of benefits based on their design, making the plasma store pluggable may be easier to keep their code path independent. If we can loosen the restriction of invariance, a third-party may be allowed to not do anything when memory is full (just panic). However, the third-party object store is only for special scenarios(and they may do better in these scenarios), users can always choose the default plasma store. (users must be aware of what they want at what cost by switching to a third-party object-store.)

Is it possible for us to define the lifecycle in ray so that it can be decoupled with the underline storage? Like the underline storage is just a key-value store. (@iycheng)

If we choose option 1 and make the plasma store only a clean key-value store. This will be ok.

I think these invariants are too strict we should try to avoid them. I actually see some benefit there. For example, without # 5, we can’t spill objects on demand. The user might want to spill the object and persist it so it can be reused later across sessions. Or the system will spill the object in advance because the node is idle and the object is used in the other node which is very busy and that node has memory pressure. The same for # 6). (@iycheng)

Also for # 7, it’s not necessary to restrict spilling only on primary objects. Theoretically, it can happen anywhere. Maybe the node with more CPU and IO? (@iycheng)

It is ok to loosen the restriction, but your suggestions conflict with the shepherd (@scv119). Please decide whether the third-party object store has to do spilling or not.

Is this meant to be an internal refactor? Or is this meant for users to plug different stores in? (@wuisawesome)

This proposal is to provide ray with new abilities by integrating with a third-party object store, we want to make the vineyard the first one to integrate. The integration will do some internal refactor to make a third-party object store easier to integrate, and also allow users to choose different stores.

If users are supposed to plug something in, how do they do that? Do they have to statically link? Dynamically link? Do we have to maintain ABI compatibility for a c++ interface?  (@wuisawesome)

Both static link and dynamic link can be ok, maybe we can export C interfaces for better ABI compatibility. For cooperation, we will also continuously maintain the code to keep the compatibility.

What if we want to change the invariants in the future? How should we corporate? I'm worried the evolvement of object stores may slow down due to this external dependency. (@kfstorm)

I think this depends on the trade-offs that ray people should make, In this proposal, we treat the invariants as something that won't be changed easily in the future.

Hey @septicmk. Thanks for submitting the rep and contributing to the Ray community. After voting in Ray committers, we concluded that we won't accept this REP at this time. Concretely:

The ray committers are generally in favor of the direction of having a clean interface for plasma.
The main concern is the feasibility and maintainability of the proposed interface; this requires a fully working prototype to validate.
Also, there are questions about if we have fully explored the design spaces and if there exists a better alternative.

Again, thanks for putting up the efforts to come up with the REP. As we discussed offline, Vineyard and Ray team will collaborate in the following mode:

Ray will not support an alternative plasma store at the moment, and there is no guarantee that the interface won't change.
Instead of proposed REP, Vineyard team will prototype and maintain the integration code as addon/plug-in/patch in one of their repos. As they prototype, they might work with Ray team and submit PRs to clean up Ray's plasma interface that brings net benefit to Ray.
If the community accepts the API changes, and a net benefit to Ray can be demonstrated, and the introduction of Vineyard does not complicate the Ray development process, we may reconsider the plasma alternative REP.


move css over to oranda

This PR moves all the CSS we use to the oranda repo.

It creates a new folder that generates this CSS
deletes unused things  in fringe when copying over
moves most classes in the HTML to CSS for easier theming

About your comment, i assumed that was the idea, i would make it work this way, copy everything and then you would come to the PR and do your releasing magic so we could merge


Adding stitcher v2

I have introduced the version 2 of the stitcher based on overlapping tiles.
Create tiles with the mode stitch_v2
Stitch with the same mode. Just 1 array of tiles is necessary.
New parameters to consider include: overlap between tiles (default is 74 pixels and it has to be an even number) and threshold to consider that a nuclei is repeated (default 80% of the size).
Apologies for the "if, elif, else" trees to generate the tiles and masks.

I have added a new Jupyter notebook for user friendly segmentation of images (one image at a time).
I have included two folders to drop the model and the output.
Minor modifications of the Nucleus.py file to ensure correct functioning of the stitcher v2
Some paths should be modified if the notebook is moved from the root directory.


Visual effect dissolve?

I've decided to convert a famous 1992 Christmas animation from HyperCard to Decker. I think it would make a super 30th Anniversary surprise for the artist who is a friend of mine.
I'm happy to either keep everything to this one issue, or split it.
HyperCard to Decker

onmouseup = on click (like for like)
play built-in sound at with specific properties (workaround by importing recorded sounds)
visual effect dissolve (missing)

Currently the only real thing missing is visual effect dissolve.
And arguably the sound playback is simpler or less versatile depending on your point of view.

Details of the project...
Progress

I've exported the images using HyperCardPreview and an old Mojave MacBook Pro.
I can see the code by inspecting the original stack in HyperCard under emulation.

Specs

503 cards
1 image per card
1 simple script to advance
one sound for the first frame
another sound for all subsequent frames
visual effect dissolve

To Do

Import all images, one per card

initial attempt at this was quite confusing, I expect the image to remain resizable but it does not?

Record original sounds
Rewrite script

HyperTalk script
on mouseup
  global fg
  if fg is 1 then
    play flute tempo 120  d3e a3e
    visual effect dissolve slowly
    go next
    put 2 into fg
    exit mouseup
  end if

  if fg is 2 then
    play flute tempo 120  a3e d3e
    visual effect dissolve slowly
    go next
    put 1 into fg
    exit mouseup
  end if

end mouseup

Sounds like a fun project!
Decker cards themselves do not produce click events, but the pointer interface exposes live information about the mouse button and can serve as a substitute. You need to kick off the initial event, perhaps with a button on the first card, or via the view[] event on that card. If I understand the above script, an equivalent might be something like
on wait do
  while !pointer.held sleep[] end
  while  pointer.held sleep[] end
end

on view do
  while 1
    play["flute1"]
    go["Next" "BoxIn"]
    wait[]
    play["flute2"]
    go["Next" "BoxIn"]
    wait[]
  end
end

Assuming that "flute1" and "flute2" sounds exist, and temporarily substituting "BoxIn" as a transition animation. Note that choosing an invalid transition name with go[] results in no delay at all.
Dissolve is a bit complicated, but I think it could be achieved with a suitable lookup table and the canvas.merge[] operation in a custom transition. The transit.deck example is a very basic editing/preview tool for building new transition functions with a few extra examples.
If you're importing 503 images, it might be a good idea to automate the process with Lilt, which can create decks from scratch, add cards, and load images from GIF files.
I'm not exactly sure why this is an issue? The itch community forum would be a good place to showcase WIPs.

This issue is a (verbose) request for visual effect dissolve 🙃
I should have really kept it short and sweet, sorry about that.

Did a bit of tinkering with a dissolve transition, and along the way found some bugs in canvas.merge[], so it was a good exercise.
Firstly, I generated a 32x32 image with a uniform distribution of 256 grays to use as a lookup table. The idea will be to use the tween value to select a threshold in this table; lower values will show the new image, higher values will show the old image. To avoid doing the work of generating this LUT at runtime, I encoded it:
lut:image["%%IMG1ACAAIE89euIjSGos8HDHDdaH0cTJI1FA4vxarzRTKlUc0N/Az4L8n7UcRCOz68jQ5bwirLO5ymT7VnFa7t3owcHH1cqgoe6SHc4uD3FLVSFBA+RGwQf9ROaTpLZZwFhZhDyTLlt7vyk4AoXn62MWR2jQbwRzFIHNHxlBRAj11jfi9pE29hm9KMYyqAVzUvNLBQ6QWv6nsobtztFugL4AHnxgrdCst32fmiwEDEq95NMtX/gg5w/0S+kSnztUJJhDOverTrq4h+R8G727VJH1Y4SqxSJXntWPre+I+Tay8eCdZULeLyeNZ4oB+6qMGD5u9YKucjH/zh4/zjE3t07rtnf82TF4/qMqAGfSPol2+TmbYy+dm54J4OY0xt30/d6CGVfYmBNgeFdSzHSkakxejZF72l7YrMsxxUDsIdQfF20ZIZbTM8anpEMOgwcEg+Cwi5hZNRrjcCVFtEl6GMIAbzvxqadk+qmqINLbjn5P6gq9nhhyhP9GJ+GTg8heKTd716IoH4bfKNSJeruxCMXMy9qQ7SSxivNrNtcQ6EyNujoGyunVUFIWTTBS90qhd/tOw4s8llGwbIo/p668h25riz/fIFb0CZ3DLAUScmqlbn0vAjaAEdwQc6FV/2Od8ZAJsekhxzq23ZUCXBOxMpQOz5Sv+l+XTCdxFoDMeiYNs4zvLplNCxx1z3g34UZbK6AfXfIUvDP+QQPCviJiKYGW8qM/pjmjZlsi3aUjqqtrmdt2dMMBvvMy1xqvB03s2ZlsjR11JjAAnIHgm2hsVlMqmtLECew+6Vz0k5wISHk9ZmGgFVg4uOOJXefEK1SXRTVHPXnz44lwhUOM2i0r+ECfuxT2TxuBdUHw/8sKuX5RIHdkiFFthZLshFneWPrZBrSUmBOI8fJ42ciuGgN9PG9LosqPmpTNA0TNaD3jzGlCCySM644qCuV/4dM1DjUVoAbkAZB7XEAe20YPt8IMdFsmR3nuv+JtZsn+pl+b/HwHGLU5YsVOLr+yCklQUMumWjuha3Y4nF4RYSy62w1igwEmzSu5aXEbkkh+FXkXz/ALx8n4T+1W5gZ3ZRbGGm/DAoXlZkIUZ2moEIZgjxDTVSf5akWClhK8Qn/cubTyHWSj0V0esqi3qEdcZd52VJ71lzTh2KXClabvc1NMsDuKjtSZ+q0TbPvwKNEzUyR8OTNp3Fd/SSWIujSpLWiXSffnMLjSuHQbF3+OYg2tYQxDpFDWyTgR6C0SlZwwqSX2rqt93Iea7+q23wVF7fi+v+qLSl8EPPclZ/nWStew1di7s+gdtGUIMnI+5nAptZHayMAvTToLD3Wi5Y9dlRX9rKLA6mHBkhyAtX6GYKuvxKUXbUj97hEMWNQ="]

Now the transition function itself. We get a canvas (c) to draw on, images with snapshots of the current and next card (a and b), and a tween from 0-1 (t). The canvas pixels all begin clear (pattern 0), so our first merge[] operation will tile the entire canvas with pixels from the LUT, drawing a repeated texture. Then, we use those tiled pixels to index into pixels from one of the source images:
on Dissolve c a b t do
 c.merge[lut]
 c.merge[((floor 255*t) take b),(256 take a)]
end

And to register this as a transition animation usable throughout the deck, I'd just add
transition[Dissolve]

All of this could in any script, really, so long as the transition is registered sometime before you try to use it. At some point in the near future I'll package this up as a module with some more fun extra transitions, to make it even easier to use.

I've packaged the above "Dissolve" transition along with many more in a new example deck called "Public Transit": https://github.com/JohnEarnest/Decker/commit/91cae19c7a18e8a439110197ecf198ba473e9eed
Adding a dissolve transition to your own projects is as simple as importing the module from this deck and then using it just like any of the built-in transitions.
I think this comprehensively addresses the ask for an equivalent to Hypercard's "visual effect dissolve", while also providing a clear example for Decker users to follow in making their own modules of transitions.

Many thanks, John. Above and beyond!


feat(Usage Reports): add "created_by_email_id" to Offer schema

PR summary

updated offers to have the created_by_email_id field
PR Checklist
Please make sure that your PR fulfills the following requirements:

[x] The commit message follows the Angular Commit Message Guidelines.
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

Current vs new behavior

updated offers to have the created_by_email_id field
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Test results:
 PASS  test/unit/global-search.v2.test.js (5.786 s)
 PASS  test/unit/usage-metering.v4.test.js (5.803 s)
 PASS  test/unit/partner-usage-reports.v1.test.js (5.827 s)
 PASS  test/unit/ibm-cloud-shell.v1.test.js (6.077 s)
 PASS  test/unit/open-service-broker.v1.test.js (6.047 s)
 PASS  test/unit/partner-billing-units.v1.test.js (6.339 s)
 PASS  test/unit/resource-manager.v2.test.js (6.461 s)
 PASS  test/unit/global-tagging.v1.test.js (6.345 s)
 PASS  test/unit/global-catalog.v1.test.js (6.45 s)
 PASS  test/unit/enterprise-usage-reports.v1.test.js (6.541 s)
 PASS  test/unit/user-management.v1.test.js (6.776 s)
 PASS  test/unit/common.test.js
 PASS  test/unit/iam-policy-management.v1.test.js (7.083 s)
 PASS  test/unit/iam-access-groups.v2.test.js (7.226 s)
 PASS  test/unit/resource-controller.v2.test.js (7.328 s)
 PASS  test/unit/iam-identity.v1.test.js (7.68 s)
 PASS  test/unit/enterprise-billing-units.v1.test.js
 PASS  test/unit/enterprise-management.v1.test.js
 PASS  test/unit/case-management.v1.test.js
 PASS  test/unit/context-based-restrictions.v1.test.js
 PASS  test/unit/usage-reports.v4.test.js
 PASS  test/unit/catalog-management.v1.test.js
----------------------------|---------|----------|---------|---------|------------------------------------------------------------------------
File                        | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------------------------|---------|----------|---------|---------|------------------------------------------------------------------------
All files                   |   98.36 |    89.61 |     100 |   98.31 |
 case-management            |    98.8 |    88.46 |     100 |   98.78 |
  v1.ts                     |    98.8 |    88.46 |     100 |   98.78 | 129,1246,1269
 catalog-management         |   97.76 |    85.41 |     100 |   97.67 |
  v1.ts                     |   97.76 |    85.41 |     100 |   97.67 | ...9,13302,13358,13381,13437,13460,13519,13542,13601,13624,13683,13706
 context-based-restrictions |    98.3 |    92.94 |     100 |   98.29 |
  v1.ts                     |    98.3 |    92.94 |     100 |   98.29 | 142,499,642,1102
 enterprise-billing-units   |    96.4 |    79.06 |     100 |   96.15 |
  v1.ts                     |    96.4 |    79.06 |     100 |   96.15 | 185,594,617,676,699
 enterprise-management      |   96.94 |     79.1 |     100 |    96.8 |
  v1.ts                     |   96.94 |     79.1 |     100 |    96.8 | 209,552,858,1502,1525,1584,1607,1666,1689
 enterprise-usage-reports   |   95.89 |    78.57 |     100 |   95.58 |
  v1.ts                     |   95.89 |    78.57 |     100 |   95.58 | 147,388,411
 global-catalog             |     100 |    94.28 |     100 |     100 |
  v1.ts                     |     100 |    94.28 |     100 |     100 | 88,1166
 global-search              |    98.3 |    88.46 |     100 |   98.27 |
  v2.ts                     |    98.3 |    88.46 |     100 |   98.27 | 200
 global-tagging             |   98.59 |    92.98 |     100 |   98.58 |
  v1.ts                     |   98.59 |    92.98 |     100 |   98.58 | 171,331
 iam-access-groups          |   98.58 |    87.38 |     100 |   98.54 |
  v2.ts                     |   98.58 |    87.38 |     100 |   98.54 | 3779,3802,3860,3883,3941,3964,4022,4045
 iam-identity               |   99.21 |    95.84 |     100 |   99.21 |
  v1.ts                     |   99.21 |    95.84 |     100 |   99.21 | 147,296,722,2597,2912,2974,3724,4038,4112
 iam-policy-management      |   99.84 |     98.8 |     100 |   99.84 |
  v1.ts                     |   99.84 |     98.8 |     100 |   99.84 | 653
 ibm-cloud-shell            |     100 |     92.3 |     100 |     100 |
  v1.ts                     |     100 |     92.3 |     100 |     100 | 83
 lib                        |     100 |      100 |     100 |     100 |
  common.ts                 |     100 |      100 |     100 |     100 |
 open-service-broker        |     100 |    94.44 |     100 |     100 |
  v1.ts                     |     100 |    94.44 |     100 |     100 | 83
 partner-billing-units      |     100 |    95.12 |     100 |     100 |
  v1.ts                     |     100 |    95.12 |     100 |     100 | 85,229
 partner-usage-reports      |   97.36 |    83.87 |     100 |   97.18 |
  v1.ts                     |   97.36 |    83.87 |     100 |   97.18 | 413,436
 resource-controller        |   96.93 |    81.81 |     100 |   96.78 |
  v2.ts                     |   96.93 |    81.81 |     100 |   96.78 | ...04,2927,2986,3009,3068,3091,3150,3173,3232,3255,3314,3337,3396,3419
 resource-manager           |     100 |    93.33 |     100 |     100 |
  v2.ts                     |     100 |    93.33 |     100 |     100 | 85
 usage-metering             |     100 |    91.66 |     100 |     100 |
  v4.ts                     |     100 |    91.66 |     100 |     100 | 87
 usage-reports              |   97.97 |     90.9 |     100 |   97.88 |
  v4.ts                     |   97.97 |     90.9 |     100 |   97.88 | 2047,2070,2131,2154,2212,2235,2293,2316
 user-management            |    98.2 |    82.85 |     100 |   98.14 |
  v1.ts                     |    98.2 |    82.85 |     100 |   98.14 | 483,1003,1026
----------------------------|---------|----------|---------|---------|------------------------------------------------------------------------

Test Suites: 22 passed, 22 total
Tests:       1656 passed, 1656 total
Snapshots:   0 total
Time:        11.03 s

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Yes, I've signed the CLA a few of times now :)

Yes, I've signed the CLA a few of times now :)

Okay, thank you! Sometimes the CLA check get stuck, that's why I asked.

:tada: This issue has been resolved in version 0.67.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Show the fancy restaurant URL in some pleasant manner

We supply all restaurants with a URL pointing to a human readable representation of the menu elsewhere. Maybe we should show this URL in some way to the user?

This has been implemented for a very long time, I can't find when for some reason. So mat has legendary features, but this isn't always reflected in the issues. :D


Incorrect role name on page and role not shown in built in roles list

This page documents the role "Key Vault Certificates User" with id a4417e6f-fecd-4de8-b567-7b0420556985. Both of these are incorrect. The correct role name is "Key Vault Certificate User" (not plural). The id shown has been copied from the previous role (Key Vult Certificates Officer).
This is a significant error since unless you can guess the correct role name one is forced to use an administrator role. Pearticularly since the the "Key Vault Certificate User" role is not listed in the built in roles. (https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#key-vault-certificates-officer)

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

ID: 44b9a84f-6765-67dc-bb7b-04303e070c03
Version Independent ID: 32fc20a0-4321-c74a-34aa-909f43a72db0
Content: Grant permission to applications to access an Azure key vault using Azure RBAC
Content Source: articles/key-vault/general/rbac-guide.md
Service: key-vault
Sub-service: general
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

@Noel-Jones
Thanks for your feedback! We will investigate and update as appropriate.

@richardsondev @Noel-Jones
Thanks for pointing this out. Required changes have been made and visible in the document itself.
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation


[question] SSO With Camunda Tomcat

Hi,
Excellent work on this plugin, is there perhaps a way to get the SSO mechanism to work when using the tomcat distribution as explained here: https://github.com/camunda-community-hub/camunda-bpm-identity-keycloak#activating-single-sign-on without having to go the Spring framework route?

Hi @somejavadev ,
we discussed this topic already at https://github.com/camunda-community-hub/camunda-bpm-identity-keycloak/issues/83. There are no news on that. The Spring framework architecture still has the most flexibility on integrating with any SSO environment.


Bruno doesn't import as file binary data from OpenAPI definition

I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug
Here is a simple OpenAPI definition:
openapi: 3.0.0
info:
  title: Media Engine Server API
  version: 1.0.1
  description: |
    API for the Media Engine Server, enabling video transcoding into various codecs and profiles.
    This API allows users to submit video files for transcoding into specified formats and resolutions,
    catering to various media production needs.

paths:
  /transcode-video:
    post:
      summary: Transcode a video file to create a proxy
      description: Accepts a video file along with codec and resolution parameters to return a transcoded video file.
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              required:
                - originalVideoFile
              properties:
                originalVideoFile:
                  type: string
                  format: binary
                  description: |
                    The video file to be transcoded, provided as a binary file in a `multipart/form-data` request.
                videoCodec:
                  type: string
                  enum: [H.264, H.265, Apple ProRes, DNxHR]
                  default: H.264
                  description: |
                    The codec for transcoding. Choices affect file size and playback compatibility:
                      - **H.264** (default): Common codec for general playback.
                      - **H.265**: Higher compression than H.264 with similar quality.
                      - **Apple ProRes**: High-quality for post-production (requires `proresProfile`).
                      - **DNxHR**: High-resolution for editing workflows (requires `dnxhrProfile`).
                proresProfile:
                  type: string
                  enum: [Proxy, LT, Standard, HQ, Unset]
                  default: Standard
                  description: |
                    Profile for Apple ProRes (used only if `videoCodec` is `Apple ProRes`):
                      - **Proxy**: Lower quality, suitable for offline editing.
                      - **LT**: Light quality for smaller file sizes.
                      - **Standard** (default): Standard quality.
                      - **HQ**: High quality for enhanced color fidelity.
                      - **Unset**: Uses default ProRes profile.
                dnxhrProfile:
                  type: string
                  enum: [LB, SQ, HQ, HQX, 444, Unset]
                  default: SQ
                  description: |
                    Profile for DNxHR (used only if `videoCodec` is `DNxHR`):
                      - **LB**: Low bandwidth, ideal for proxies.
                      - **SQ** (default): Standard quality.
                      - **HQ**: High quality.
                      - **HQX**: Higher chroma fidelity.
                      - **444**: Full color resolution.
                      - **Unset**: Uses default DNxHR profile.
                height:
                  type: integer
                  description: |
                    Height of output resolution in pixels. Set to -1 to auto-calculate based on aspect ratio.
                    If both width and height are -1, retains the original dimensions.
                    A typicall value would be 1920 for example.
                  default: -1
                  example:
                    FullHD:
                      value: 1920
                    HD:
                      value: 1280
                width:
                  type: integer
                  description: |
                    Width of output resolution in pixels. Set to -1 to auto-calculate based on aspect ratio.
                    If both width and height are -1, retains the original dimensions.
                    A typicall value would be 1080 for example
                  default: -1
                  example:
                    FullHD:
                      value: 1080
                    HD:
                      value: 720
      responses:
        '200':
          description: Successfully returns the transcoded video file.
          content:
            application/octet-stream:
              schema:
                type: string
                format: binary
              example: "transcoded_video.mp4"
        '400':
          description: Bad Request - Invalid parameters or missing required fields.
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                    example: "Error: height value is invalid"
        '405':
          description: Method Not Allowed - Only POST is allowed.
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                    example: "Error: Method Not Allowed - Only POST is allowed."
        '500':
          description: Internal Server Error - Error occurred during transcoding.
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                    example: "Error: Server disk is full"

servers:
  - url: http://localhost:{port}
    description: Local server for testing and development.
    variables:
      port:
        default: "80"
        description: Port for server access (default is 80).

originalVideoFile is imported as a param in the body, not as a file.
but in the definition we can see that originalVideoFile is a binary data:
originalVideoFile:
                  type: string
                  format: binary

Is it my OpenAPI definition that is not correct? or that Bruno should consider binary data as a file here?
.bru file to reproduce the bug
No response
Screenshots/Live demo link

Hi @stephane-archer
Are you requesting that Bruno handle binary files in the body like this, where the file is treated as a file upload and the "Select Files" button is displayed in the value field, as shown in the screenshot?

Exactly, I don't expect people to copy paste binary data into Bruno, that data is probably already in a file

Thanks for confirming! We will get this fixed. I will update you on the progress.


Fix incorrect VehicleWheel3D Roll Influence description

Updated VehicleWheel3D Roll influence description and confirmed the tooltip has been updated in the Editor Inspection window.
I updated the es.po translation file, but additional translations need to be corrected. I updated english text for fr.po, zh_CN.po and zh_TW.po in this PR, but I need to find someone to update the alternative text for each of these files.
This PR fixes #85805.

The translations are still present, and please squash your commits into one 🙂, see here

Do I understand correctly that you want me to remove all translation changes from this pull request, such that the impacted lines in *.po remain as they are on master right now?
What is the appropriate approach to update translations?

Yes, indeed, the updates to the translation is as I said in the issue, you edit them on the webplate, see here

Thanks! And congrats for your first merged Godot contribution :tada:

Cherry-picked for 4.2.2.

Cherry-picked for 4.1.4.


Fix example in documentation

change 'm' to 'M'

I was opened this PR on the wrong branch and opened a new one on the upstream repo.  Sorry!

No problem! 😄


Tiff images not displaying on LIFT server

According to @gtarcea, the command/application that converts TIFF images needs to be installed on the LIFT server

The convert command was not installed on the lift server.

Tiff images are still not displaying for me on the Lift site.


Freetype 2 nuget packages broken?

When using the Freetype 2 package, i get this warning upon building under .net Core 3.1:
Warning NU1701 : Package 'Ultraviolet.FreeType2.Native 2<IP_ADDRESS>55' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.

Using an Android project, this results in a crash regarding the missing freetype natives.
I have my game project defined as netstandard2.0 library using Ultraviolet and Ultraviolet.FreeType2. Upon that i have the actual projects as netcoreapp3.1 for desktop and xamarin for android using the Shim Packages, plus a reference to the game project. This works perfectly under desktop with and without freetype (just the above warning) and under android as long as i do not use freetype2.

This will be fixed in the next release.


Add documentation on the disease_model.py

I updated the code with more explanation of the code and detail comments on the code. Please review this later.

For the docstring, I would suggest using the Numpy format. We can set it in the Python docstring extension in VSCode. Just to keep consistent with Pyomo.


mobilenetv2 on somethingsomethingv2 performance?

Dear author:
you make a gesture demo using mobv2, which is really helpful!
I wonder have you tried trainining on other large actions space datasets, such as full sthsthv2 , using mobilenetv2？ could you give some intuitive performance descrption of mobv2 on these datasets? thank you.

Hi, thanks for your interests. But I did not train MobileNetV2 on the Something-Something dataset.


Add support for kube_apiserver SLI metrics

What does this PR do?

This PR introduces two new kube_apiserver metrics: kube_apiserver.slis.kubernetes_healthcheck and kube_apiserver.slis.kubernetes_healthchecks_total.
Motivation

Kubernetes v1.26 exposed a new /metrics/slis endpoint (reference here); this endpoint is enabled by default starting in v1.27. This PR adds support for capturing the new metrics exposed for the apiserver: kubernetes_healthcheck and kubernetes_healthcheck.
The reason we're adding this to the legacy OpenMetrics version of the integration is that we are using that version internally and would like the metrics.
Additional Notes

To QA:

Run the agent with kubernetes version 1.27+
Check that the metrics are sent via the UI

Review checklist (to be filled by reviewers)

[x] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[x] Changelog entries must be created for modifications to shipped code
[x] Add the qa/skip-qa label if the PR doesn't need to be tested during QA.

/merge

/merge


React router should export PropTypes

A lot of us work in lint enforced environments, on of these lints is usually good propTypes.
All linters aside prop types are great documentation and also help you figure out problems.
Right now the only option to have prop types for match or history is to use PropTypes.object.  Also PropTypes.object, PropTypes.any and others are usually frown upon in big code bases.
MobX solved this by exporting a set of prop types.
Something similar would be very nice for react router.
import { PropTypes as RouterPropTypes } from 'react-router';

class RandomComponent extends React.Component {
  static propTypes = {
    history: RouterPropTypes.history,
    match: RouterPropTypes.match,
    location: RouterPropTypes.location,
  }

  .
  .
  .

I'm actually undecided on this approach with a tendency to not like it.
For example if there is a major version upgrade that changes the API of any of those parameters, you won't catch that, because the propType validators silently update as well. Otherwise you know that you need to update your code and where because of the warnings.
And when you import the propTypes you and up always requiring all parameters, not only those you really need for your component to work.

@bitcloud I understand your perspective.
In a perfect world everyone put the exact tue things they need in prop types.
But in reality a lot of people just use PropTypes.object to describe these objects which is not very useful for someone looking at prop types trying to figure out what a component needs.

Do you think those people who use PropTypes.object would then start using the exported propType? ;-)
I think if the really start worrying about using better PropTypes then PropTypes.object they should go the whole 9 yards and put the exact things they need in prop types.
Putting that in place would more or less support or even encourage not doing it right :)

We don't maintain strong PropTypes internally, so there's not really anything to export. We don't pass anything around, and we rely on PropTypes.object a lot. We also tend to not put a lot of value in PTs. A strongly typed system like TypeScript or Flow is probably going to serve you better.


Node default color cannot be set

Bug report
Modification of the node default color in the settings has no effect
Sigma.js version: 2.1.2
Graphology version: 0.21.1
Operating System: Windows 10
Web browser: Chrome Version 96.0.4664.45
Steps to reproduce
Check the live example https://codesandbox.io/s/clever-mcclintock-z1u0w
Expected behavior
Nodes and label should be displayed in green
Actual behavior
Nodes and labels are displayed in grey

In the example you provided,  you are not configuring the Sigma settings, but you are setting node's attributes.
The good way is the following :
import Graph from "graphology";
import Sigma from "sigma";

const container = document.getElementById("sigma-container") as HTMLElement;

const graph = new Graph();

graph.addNode("John", {
  x: 0,
  y: 10,
  size: 5,
  label: "John"
});
graph.addNode("Mary", {
  x: 10,
  y: 0,
  size: 3,
  label: "Mary"
});

graph.addEdge("John", "Mary");
// eslint-disable-next-line @typescript-eslint/no-unused-vars
const renderer = new Sigma(graph, container, {
  labelWeight: "normal",
  defaultNodeColor: "#39ff14",
  labelColor: { color: "#39ff14" }
});

Thank you very much. This worked like a charm!


Ubuntu 22 node doesn't sync

Compiling with the standard Ubuntu 22 libraries makes the lyra2 powhash incorrect and thus gives the high-hash error on blocks after 166767.
I am trying to compile with the depends dir. Will let you know how that works.

yes we are aware, thanks for filing the issue, not sure where the issue lies, perhaps with gcc version

yeah gcc was my suspect

there is almost no difference when compiling between gcc 9 and gcc 11, except this:
gcc9:
crypto/pow/scrypt.cpp:119:38: warning: ‘void* memset(void*, int, size_t)’ clearing an object of non-trivial type ‘class CHMAC_SHA256’; use assignment instead [-Wclass-memaccess]
119 |  memset(&PSh, 0, sizeof(CHMAC_SHA256));
gcc11:
crypto/pow/scrypt.cpp:119:15: warning: ‘void* memset(void*, int, size_t)’ clearing an object of non-trivial type ‘class CHMAC_SHA256’; use assignment instead [-Wclass-memaccess]
119 |         memset(&PSh, 0, sizeof(CHMAC_SHA256));

Now I remember I fixed this with a "hack" in another branch I work on. In bmw.c:
#include <stdio.h>
In the bmw32_close method, add
fflush(stdout);
right after the #endif of SPH_64 (right before compress_small(buf,h,h2);)
I did this because it started working when I put printf statements in there...
Also I am trying another BMW implementation: https://github.com/floodyberry/supercop/tree/master/crypto_hash/bmw256/ref
and it seems to work, but not sure yet. Also I don't know how reputable this code is.

im on a virtual machine with a high-hash build right now, ill implement this n see what happens and report back, and if it works ill label the commit so others dont have this issue in the future

@akrmn2021 that worked 100%, we appreciate the insight!


CLI support for rerunning tests

It would be great to have an Rspec tag for running one test multiple times from the command line. Right now I'm using the "for i in 'seq 50'; do rspec spec" command UNIX provides in the CLI. Thank you

Duplicate of #795, this is better off as an extension or simply using the UNIX script you provided.


RFC: Adding Forward Trait

RFC: Adding Forward Trait
To make all modules of the Burn crate implement a Forward trait.
Feature motivation
This would allow a more functional and thus rusty implementation of the forward pass of user defined modules, akin to the following:

let seq: [&dyn Forward<B, D>; 4] = [
      &self.fc1,
      &self.dropout
      &self.activation
      &self.fc2
];

let res = seq.into_iter().fold(input.clone(), |res, x| x.forward(res));
res + input

A downside would be that it imposes a more sequential framework and hence more restrictive, however, I believe this would induce more modular code since the parts which e.g. uses a residual connection between several layers or require reshaping could be refactored into its own module, since such actions can easily be done at / between the beginning and end of the forward pass without being hindered by the suggested framework.
In the end, I think the sequential nature and the increased modularisation would make the forward passes of the burn ecosystem more concise and quicker to understand for others.
(Optional) Suggest a Solution
To prevent breaking changes the Forward trait could just call the existing forward method until next major release.

Just a side note. We need to check if a module can work with dyn, which requires the module to be object safe.
Question. How is this different than Module Trait defined here: https://github.com/burn-rs/burn/blob/6b5ba770847ae0b4a2dda6bc584415c6c8008270/burn-core/src/module/base.rs#L92

Regarding the Question: The Module trait has several methods that return Self, so as of my understanding, it wouldn't be possible to make it object safe, and creating a separate Trait for just the forward method would prevent forcing all Modules to have a forward trait; I'm not sure if that is already the case, though.
Regarding the side note: I think a trait can be made object safe even though it returns objects that has generic types, like Tensor<_>, if generic types are set on the Trait signature rather than the signature of the method; A downside to this is a that the iterator chain can only handle Tensors of a fixed number of dimensions.
Additional thoughts: There could possibly be a performance drop by adopting dynamic dispatch, since it prevents compiler optimisation - though, I have no knowledge on how applicable that is to Burn code, and the impact of GPU architecture on said issue? - but, I don't see the downsides of letting some users opt in to it, if they so wish, so as to enable subjectively more succinct code.

Also, some forward methods take multiple inputs, and even if the input is single, the types are different (e.g., Tensor<B, 3>, Tensor<B, 2>). So to make it work universally, there should be two additional traits (ForwardArgs and ForwardOutputs), and the users need to implement the conversion.

I think you could make a separation between those Modules which are base building blocks , like Linear, GELU, LayerNorm, and versions of different NN frameworks, like Transformer or LTSM, when it comes to forward methods that have more than 1 input argument; A Forward Trait would mainly be adopted for the base building block and the thus make the frameworks easier to understand and create on your own.
Regarding Tensors with different number of dimensions, my initial thought was that there would be one iterator chain for say Convolution layer and one for the a possible FC so that this wouldn't be a problem - or at least not as frequent so as to allow the user to chose one main dimension count for the majority of layers, and if one layer would require something different the changing of dimensions could be confined in that layers forward pass only, ie convert input immediately and return back to original dimension before returning.
Another possible solution would be to have Tensors of high dimension count with several ones of them being at count 1 if low dimensional Tensors are required; there might be an overhead to this though, and could prevent Type system to catch bugs and mistakes.

I don't think we should add a Forward trait to Burn. I have thought deeply about it, and this will not be flexible enough to enable all network architectures. Modules can have multiple forward passes with any arguments and do anything, really. That's the point of dynamic graphs.
I acknowledge that we may want to provide a way of implementing sequential modules similar to Keras: https://keras.io/guides/sequential_model/. I don't think we should force the implementation of a trait on all neural network building blocks to provide this API. This is mostly about removing verbosity, so we could use codegen (macros, attributes) to perform such tasks.
#[burn::sequential(input = "Tensor<B, 4>", output = "Tensor<B, 4>")]
pub struct MySequentialModule<B: Backend> {
    fc1: nn::Linear<B>,
    dropout: nn::Dropout<B>,
    fc2: nn::Linear<B>,
    relu: nn::ReLU,
}

This is just a rough idea of an API that would generate the correct forward method. However, I'm still unsure if this is a desirable API since it would create different ways of creating modules in the library, potentially making it harder to understand and harder to debug.
You are free to add any trait/codegen system on top of Burn modules in your crates. By testing abstractions, we could potentially adopt one that helps without losing flexibility.

I wasn't thinking about procedural macros, but that seems indeed to have potential for higher level of abstractions.
As a side note, I've come up with a work for those who read this and want a sequentialish forward pass:
let x = self.linear.into_iter().fold(input, |res, x| {
    let res = e.forward(x);
    let res = self.dropout.forward(res);
    self.activation.forward(res)
});


Publish a new version on Pub

Could you please publish an update on Pub?
The current version has some critical problem.
In my case, my app crashes because there isn't this guard in BarcodeScanPlugin.kt:
if (registrar.activity() != null) {
...
}

flutter release version 1.12.13 with some great changes.  Maybe a lot of work should to do to fit it.

A new version is available https://pub.dev/packages/barcode_scan


Autocomplete emptyState HTML markup not working

Current Behavior
When using the autocoplete component emptyState prop, i expect it to render the html in the empty state:
<Autocomplete ... emptyState="TEST" >
However it outputs it as a string: "TEST"  and not the bold text as it is should, am I doing something wrong?
Expected Behavior
The emptyState to render the html

@SK4P3 the emptyState value doesn't accept HTML, only text:
https://github.com/skeletonlabs/skeleton/blob/master/packages/skeleton/src/lib/components/Autocomplete/Autocomplete.svelte#L172
However, we do provide a regionEmpty class prop which will format the text using utility classes. For example:
<Autocomplete ... regionEmpty="font-bold"  />

If you require HTML for this slot please let me know and I can happily modify this to a feature request. If this satisfies your requirements feel free to close. And of course, PRs are always welcome! Thanks!

Hi thanks for the answer I was just a bit confused by the way it is worded in the doc! For me its not important right now, I initially wanted to put a button in there, that if its empty a user can click the create new button, but I just put it next to the input filed now.
But I think it wold be a good addition in the future!


1.1.1f  If call SSL_key_update while writes are pending（no-block socket），next SSL_write or SSL_read will return fail

In TLS servers where asynchronous reads and writes may be flowing concurrently(non-block socket) , OpenSSL's TLS 1.3 can't support call SSL_key_update between SSL_ERROR_WANT_WRITE return by SSL_write and next SSL_write or SSL_read.
it will fail with the following error:
SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_SSL3_WRITE_BYTES,SSL_R_BAD_LENGTH);
I have seen similar cases：https://github.com/openssl/openssl/issues/8677
it have a solution：
https://github.com/mattcaswell/openssl/commit/807f7cddbe3336687eaf3dd6631cbc7ec58b7ddb
maybe the solution just solve the problem which receive key_update_requested while writes are pending。
but it can't solve the  problem which call  SSL_key_update while writes are pending。
ssl = SSL_new(Context);
new_sd = create_socket();
if (ioctl(iSd, FIONBIO, &nonBlock) == SOCKET_ERROR)
{
	printf("ioctl() failed with error %d\n", ipsi_get_last_socket_error());
	return;
}
ret =SSL_setSockId(ssl, (SEC_SOCK)iSd);
while(1){
		err = SSL_accept(ssl);  	//connect to the server
		if (err == 1)
		{
                    break;
		}
}
// step1 :Write a large message on the server，until SSL_write return -1 with SSL_ERROR_WANT_WRITE
	while(1)
	{
		ret = SSL_write(ssl, buf_write, sizeof(buf_write));
		if(ret == -1 && SSL_get_error(ssl, ret) == SSL_ERROR_WANT_WRITE)
		{
			printf("SSL_ERROR_WANT_WRITE exit\n");
			break;
		}
	}
//step2: server call SSL_key_update
	ret = SSL_key_update(ssl, SSL_KEY_UPDATE_NOT_REQUESTED);  //SSL_KEY_UPDATE_REQUESTED
	TEST_ASSERT(ret == TEST_SSL_SUCCESS,"SSL_key_update");

//step3: do SSL_write again,it will fail and return error :SSL_R_BAD_LENGTH
	ret = SSL_write(ssl， buf_write, sizeof(buf_write));
	TEST_ASSERT(ret != -1,"SSL_write fail");
        err = SSL_get_error(ssl, ret);
       printf("last write err=%d\n",err);
       printf("\nret: %d, SSL_getLastError: %d\n",ret, ERR_GET_REASON(ERR_peek_error()));  //**SSL_R_BAD_LENGTH**

step3 failed caused by this logic

@mattcaswell
I have seen similar cases #8677, but our case is  that call SSL_key_update while writes are pending（no-blocking socket).
may be our using  logic is wrong?
Is there any documentation that supports this issue?

closing for inactivity.  Please feel free to reopen if anyone wants to follow up on this


JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal start byte 0x90

Hi everyone, thanks for the Vision API here in Android.
We at my team are having some issues reading some 2d codes in the ID Documents for Colombia, some codes are reading well but some others are throwing native crashes when parsing the codes to strings.
Attached is the stack trace of the crash we are facing, it seems to be a crash at the very beginning of the string parsing...
We are using 'com.google.android.gms:play-services-vision:10.2.1'
Any help here would be greatly apprecited
Thanks

This bug seems to be similiar to previously known bugs above Lolipop http://stackoverflow.com/questions/34066498/csipsimple-throwing-exception-jni-detected-error-in-application-input-is-not-val http://stackoverflow.com/questions/12127817/android-ics-4-0-ndk-newstringutf-is-crashing-down-the-app Furthermore it isn't limited to scanning 2D Codes, the Vision Api will crash as soon as some unexpected characters, like the Registered Sign ®, are within the parsed String.
To reconstruct this error, simply scan this code containing the Registred Sign:

Hi,
Same problem, it crashes on my Samsung GS5 as soon as the CameraSource call start(). Is there any update ?
Thanks for your help.

Hi all,
Like @VynceCook the crash is on call start method, not while scanning a qrcode containing special chars.
Same on Galaxy S5 klte.
And no crash on Sony Xperia D2203 but the scanner found no qrcode / barcode.


New package: GraphUtils v0.1.0

Registering package: GraphUtils
Repository: https://github.com/sisl/GraphUtils.jl
Created by: @felixmg312
Version: v0.1.0
Commit: 2b50bfb1786521721f945f12812383cd4e9471fa
Git reference: HEAD
Description: Welcome to the GraphUtils.jl documentation. The purpose of this project is to provide an example package structure which can be easily copied and modified.

stop auto merge


Example on using COM interface

Please add an example of using COM interface to the readme.
Thanks in advance.
My goal is to create a safe wrapper for IDesktopWallpaper from #745, and I don't understand how to use the code from that PR, nor where to look it up.
I'm relatively new to Rust, and not an expert in COM nor Windows. I'd like to have a usage example for all the functionality that winapi-rs provides. Not necessarily for all the functions (i.e. everything in the crate) - but just a single good example for each of the significantly different case would definitely be a game changer for me.
So far, I can the following things that worth having an example:

~using C API (for example stuff from user32.dll);~ is already in the README
using COM API (shlobj_core, creation, use and deletion of an interface);
implementing a COM interface;
extending winapi-rs (aka contribution guide).

Maybe there's something else I don't yet know of.

I intend to eventually create a repository full of examples and links to crates that are good examples, and link to it from the readme. I'm not about to add COM examples directly to the readme as it is already long enough as is.

Ok, could please hook me us with a link or something here for a quick solution? All I could find in the internet is for v0.2 of winapi-rs. Really looking forward to it.
I know I should somehow create a IDesktopWallpaper implementor, probably using CoInitializeEx - but I wasn't able to go from than that basic understanding to something concrete.

If you know a create that uses COM API - that'd be enough for me, cause I scrolled over creates.io but couldn't find the one that'd do it.

Just fiogured I could use github search: https://github.com/search?p=1&q=CoInitializeEx+language%3Arust&type=Code


iOS builds don't work

It seems the built dylib is not being included in the build. Tested in Unity 2022.3.16

Fixed by #15


BO - ajout des 4 pages du footer

:tada: This PR is included in version 0.10.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add grid 0 to grid size list as it is in official ant Grid System

What problem does this feature solve?
Grid 0 is so important  (e.g [nzXs]="0") as it allow us to hide content according to breakpoints (xs, sm, md, lg, xl), and it is provided on official ANT documentation for React
What does the proposed API look like?
<div nz-col [nzXs]="24" [nzSm]="24" [nzMd]="8" [nzLg]="5" [nzXl]="5">
    DIV 01
</div>
<div nz-col [nzXs]="0" [nzSm]="0" [nzMd]="16" [nzLg]="19" [nzXl]="19">
    DIV 02 not shown on small screens
</div>

will be supported in next version.


Fixing the docs

As the Installation suggests entering the Pkg mode by typing ] in the Julia REPL, but the code block displays adding in the julia mode. Fixed that by the command for adding the package in the Pkg mode.

This is an old PR. The issue is being solved explicitly.


Database connection problems

Description
For some reason I get some strange error when trying to connect to my database and every other plugin works just fine
Reproduction Steps
start the server
Expected Behaviour
server connects to database
Server Details
Velocity 3.3.0-SNAPSHOT (git-75d6dcc1-b371)
LuckPerms Version
v5.4.121
Logs and Configs
https://gist.github.com/Danieljunek17/72234d167d0228599cd32831c6aa6f82
Extra Details
This happend after I enabled cloudflare proxy and switched from the FQDN (panel.**.net) to the direct ipv4 ip (65...*21)

caused by a corrupt library, which didnt fully download since the server was killed during a previous startup


create install script

[x] Check if firefox and git are installed
[x] Clone repo
[x] Move chrome folder to profile folder root and change about:config prefs
[x] Detect profile folder automatically (deducted from files in mozilla/firefox)
[x] Add option to uninstall
[ ] Add support for windows
[ ] Options for recommended settings (may do in separate PR)

Designed to make the installation a lot simpler, by just using curl to execute the script

Might require testing on MacOS, will probably do a Windows .ps1 script later

@bmFtZQ This is probably all I'll do for now, let me know what you think

I added a better way to uninstall, which preserves the user's user.js in case they want to keep it but removes only the custom settings added by the script if the user wishes.
I've also done everything you suggested above, let me know if there's anything you'd change.
I've also updated the README.md accordingly.

@bmFtZQ

Also with the user.js file, if running the script again after installing it, duplicate values will be added to the user.js file as Firefox will never edit user.js. When Firefox is opened, it sets the preferences found in user.js. Removing them from the user.js file later does not remove the preferences from Firefox as they have already been set previously.

The preferences that firefox sets are found in prefs.js, which means they can easily be removed (which sets them to default) provided firefox is closed. Of course, this would mean we also remove the prefs in user.js, because we don't want to set them again.
TL;DR change nothing about how it's currently being installed, but on uninstall, remove prefs in user.js and prefs.js.
The option is there, let me know if you prefer that instead.

The preferences that firefox sets are found in prefs.js, which means they can easily be removed (which sets them to default) provided firefox is closed. Of course, this would mean we also remove the prefs in user.js, because we don't want to set them again.
TL;DR change nothing about how it's currently being installed, but on uninstall, remove prefs in user.js and prefs.js.
The option is there, let me know if you prefer that instead.

When uninstalling I think removing the preferences should be optional and the script could prompt the user with something like this:
Reset preferences to default values in 'prefs.js' and 'user.js'? [y/N]

Then also create a backup of the existing files before starting (create a copy with .bak added to the end of the filename).
When installing, maybe the script can look in the user.js file for existing preferences and only set the preferences that are needed.
If someone's existing user.js file looked like this:
user_pref("toolkit.legacyUserProfileCustomizations.stylesheets", true);
user_pref("layout.css.color-mix.enabled", true);
user_pref("layout.css.light-dark.enabled", true);

then only user_pref("svg.context-properties.content.enabled", true); would need to be added to the file.

Happy New Year!

Happy new year!

Happy new year!

@bmFtZQ PR is ready to merge unless you want anything else changed.


More tests failing as result of isolated change

More failures related to isolated change.

Codecov Report

Merging #13803 into main will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #13803      +/-   ##
==========================================
- Coverage   59.93%   59.91%   -0.03%
==========================================
  Files         684      684
  Lines       37962    37962
  Branches     5466     5466
==========================================
- Hits        22753    22744       -9
- Misses      14036    14040       +4
- Partials     1173     1178       +5

Impacted Files
Coverage Δ

src/client/datascience/crossProcessLock.ts
79.41% <0.00%> (-11.77%)
:arrow_down:

src/client/common/utils/platform.ts
56.00% <0.00%> (-8.00%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0.00%> (-2.23%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0.00%> (-1.57%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0.00%> (-0.73%)
:arrow_down:

src/client/common/errors/errorUtils.ts
50.00% <0.00%> (ø)

src/client/common/process/pythonProcess.ts
97.22% <0.00%> (ø)

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 1e0f596...9e3681c. Read the comment docs.

Going to just submit so we get a CI over the weekend.


Attempt to fix issue #10366 encoding and categoricals hdf serialization.

closes #10366 .
Probably not quite the right approach but want to run travis. Tests are a bit weak at this point (just testing for non-exceptions). Encoding issues might be relevant to other types besides categoricals (but categoricals raise exceptions when strings to mangled to non-uniqueness).

Also, let's make a store in 0.16.2. and try it on the current to see if back-compat can be rescued.

I haven't resolved the python2 issue (TypeError: [unicode] is not implemented as a table column) so have put a skip in the test for PY2.
In Python 3.4.3, have successfully created a store in 0.16.2 and read it using the current branch.

@jreback I've squashed. Let me know if there are other comments/concerns.

can you rebase / update?

Rebased and squashed.

@cottrell can you rebase and update according to my last

@jreback I have rebased and commented above that I did not get very far with the _convert_string_array suggestion you made.

ok will take a look thxs

replaced by #10889


Import fixes for basscss with npm 2

The different module structure with npm means basscss submodules need to be installed as peers.

@winkerVSbecks

@SethDavenport this isn't actually required with npm 3. However, if we are supporting below that then this makes sense.
:shipit:

Yeah I initially did it the other way and was like "ok that works" on my npm 3 box. However for the starters we made a decision to support the latest node LTS (currently 4.3.1), which ships with npm 2.


Are bond length same for all the structures between Na and Cl ions?

@s4il3sh Depends on the configuration you chosen. For the distorted rectangle, the bond length is different.

ok so how do we find this information? It's not given in the paper.

We need to make the best guess using trial and error. If you have a better strategy please share.


Rotation helper element doesn't match the correct key size

While implementing the rotation helper I finally started dealing with the issues in the key layout calculations due to the "margin" added to keys. This isn't a big deal except for the fact that it indicates I'm still not applying it consistently.

Turns out I neglected to set the correct box-sizing CSS property for the "ghost" key.


WIP: Do not timeout if salt-api does not respond in a reasonable timeframe.

Also, detect those cases and just assume no changes on the backend.
Fixes: bsc#1047953

I'll take a look at this again soon.


Define an interface for experimenters to provide final inputs data with a label

This story is part of epic Generalize OrbitAI.

give raw OBSW data to experimenters
allow experimenters to perform any checks and transformation they want on raw OBSW data
allow experimenters to give back transformed OBSW data + associated label
make it easy in case we want to allow non-binary classification

@TanguySoto some note regarding the refactored ML Server:

You no longer need to send it a "train" or "infer" string as part of the command string. It will figure this out on its won based on what mode is set the in properties file.
When sending data input for training or inference, the first four characters is the command string with the length of the command message, e.g.:

0041 +1 1:1.232 2:2.412 3:2.123 4:5.23223
0031 -1 1:1.232 2:2.412 3:2.123

This is described here but eventually should be documented in the README.

@TanguySoto what do we need to do to get this issue closed?


Cleanup.

Result of running .specmesh/clean_up.sh
Reviewer checklist

[ ] Read the contributing guide
[ ] PR should be motivated, i.e. what does it fix, why, and if relevant, how
[ ] Ensure relevant issues are linked (description should include text like "Fixes #")
[ ] Ensure any appropriate documentation has been added or amended

Build failing as there is no Java code yet... it's coming!


[discussion] engine rearchitecting

@defkev brought up some interesting points recently about potential changes to the engine.js. I'd like to start a larger discussion about some bigger goals for the engine in hopes that if a comprehensive overhaul is to happen, it can encompass some extra ideas.
Goal 1: I want it to be possible to run multiple coins. Right now I can set --buy_max_amt and run 2 separate bots, and with a strategy configured to switch modes based on whether or not I have a positive asset balance, they do indeed play nicely together without overspending beyond that buy_max_amt. However, because they, on Binance at least, are running 2 separate polls to Binance, I get my IP throttled when I try. You can implement websockets for multiple coins at 1 time, but how do you get 2 instances of Zenbot to share that stream of trades? Definitely need a major change for that.
Goal 2: Fix the madness of this setTimeout chain. It's entirely possible (and happens to me on occasion) for an error to trigger a retry of the callback chain of an order, and then in the next period, an entirely separate chain of callbacks to trigger on the same order. There's no way for the engine to recognize that it's already looping through a bunch of setTimeouts and so they start stepping on each others' toes. The best case scenario is they both try to place an order, and the exchange sends an "insufficient funds" error causing 1 chain to die. Timing should somehow be more explicit. Either decisions should be made as callbacks from web socket streams, or after time passes, it should be saying "with the current state of things, what should I be doing with my current order?" instead of hoping that the setTimeout dance in the ether will figure itself out. There's multiple related bugs that this could solve.

After #1359 came up i was thinking about using nodes cluster feature.
https://nodejs.org/api/cluster.html
Having one master process running the "core" stuff like talking with the exchange(s) and N workers doing the actual strategy/trades.
That way all workers would've access to the same set of data, taking out a lot of overhead multiple running instances create, including hammering the exchange.
This would also allow us to expose multiple instances under a single IP/port for the API, along with something like a "Master" dashboard listing all running instances (with some brief info like exchange/selector/profit) will clicking on one brings you to the instance dashboard, as we have it right now.
This should at least partially solve Goal 1
Definitely would be a bigger change non the less, as we most likely need to touch everything under the hood.
Maybe with v5 :grin:

Hey guys, cross post, Bot18 is my new bot in development and has already solved these issues! Will probably drop soon! Stay tuned!
https://github.com/DeviaVir/zenbot/issues/1589

~Carlos


Build error occurred

working fine on localhost but not working on vercel deploy, any idea?

This is a problem caused by not creating the .env variables within Vercel.


Can't download XLA archive. Certificate expired

Hi,
when trying to install exla with Mix.install I am getting:
21:45:21.094 [info] Found a matching archive (xla_extension-x86_64-linux-gnu-cpu.tar.gz), going to download it
==> exla
could not compile dependency :exla, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile exla", update it with "mix deps.update exla" or clean it with "mix deps.clean exla"
** (RuntimeError) failed to download the XLA archive from https://github.com/elixir-nx/xla/releases/download/v0.4.4/xla_extension-x86_64-linux-gnu-cpu.tar.gz
    (xla 0.4.4) lib/xla.ex:203: XLA.download_archive!/2
    (xla 0.4.4) lib/xla.ex:33: XLA.archive_path!/0
    /home/michal/.cache/mix/installs/elixir-1.14.2-erts-13.1/e70174c9a0507b6eb7c9a038b5edd35d/deps/exla/mix.exs:112: EXLA.MixProject.extract_xla/1
    (mix 1.14.2) lib/mix/task.ex:492: Mix.Task.run_alias/6
    (mix 1.14.2) lib/mix/tasks/compile.all.ex:92: Mix.Tasks.Compile.All.run_compiler/2
    (mix 1.14.2) lib/mix/tasks/compile.all.ex:72: Mix.Tasks.Compile.All.compile/4
    (mix 1.14.2) lib/mix/tasks/compile.all.ex:59: Mix.Tasks.Compile.All.with_logger_app/2
    (mix 1.14.2) lib/mix/tasks/compile.all.ex:33: Mix.Tasks.Compile.All.run/1

and from curl
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Looks like some certificate has expired on Tue, 21 Mar 2023 23:59:59 GMT
When trying to download tar with the source code manually (from the release section on github), it works correctly.

We are just downloading it from GitHub though. Perhaps a temporary issue on GitHub side?

Discussion here: https://news.ycombinator.com/item?id=35295216

And it seems to be back up!

Thanks! Works for me too


Fix Swift 4 migration.

Changeset 81f506ab only migrated the iOS target to Swift 4.0;
the watchOS, tvOS, and OSX targets were still declared as Swift 3,
so they no longer compiled.
Fix this by moving the language declaration to the project level and
removing it from all the targets.  This sets everything to be Swift 4.

Hey @ewanmellor thanks for this, I've totally missed that. Hotfix version coming up soon.


Reduced Defend (Universal Ability) magic resist

Reduced magic damage reduction of Defend (Universal Ability) from 20% to 15%.

@vampirika could you please re-save the map with the proper terrain.slk setup (I think Pig showed you this), export again, and commit? I'm seeing a lot of pathing changes!

Closes #2143

Please re-open once the Pathing fixes are in.


Issue with metadata: cpu_time

Hi!
I have some confusion about cpu_time. Why is there zero value for cpu_time?

You have to realize that the metadata provided comes directly from the online judging sites. If AIZU records 0 for cpu_time then it show up as such in our metadata CSV file. Mind also that the resolution of the measurement is milliseconds; a lot of programs run very fast, maybe even in less than 1 millisecond. That measurement might then be rounded down to 0 (since the column lists integer numbers). We did NOT run all Accepted submissions ourselves and recorded their cpu_time. That might be a good exercise to obtain more precise numbers. Note that some of the rejected submissions have negative cpu_time. We have no explanation for that.


Container Publish: OCI base image without optional root mediaType fails

Describe the bug
We are using custom aspnet-runtime-images with OCI manifest. When using dotnet publish -p:PublishProfile=DefaultContainer with csproj's ContainerBaseImage pointing to our custom image, publish fails (exception below).
Our OCI manifest does not have a mediaType property in root which is valid according to the spec but seems to cause dotnet to fail:
{
        "schemaVersion": 2,
        "config": {
                "mediaType": "application/vnd.oci.image.config.v1+json",
                "size": ...,
                "digest": "..."
        },
        "layers": [
                {
                        "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
                        ...

To Reproduce

create custom base image with OCI manifest
create minimal dotnet web project with ContainerBaseImage
run dotnet publish -p:PublishProfile=DefaultContainer

Exceptions (if any)
The "CreateNewImage" task failed unexpectedly. [...]
/usr/lib/dotnet/sdk/8.0.104/Containers/build/Microsoft.NET.Build.Containers.targets(202,5): error MSB4018: System.Text.Json.JsonException: JSON deserialization for type 'Microsoft.NET.Build.Containers.ManifestV2' was missing required properties, including the following: mediaType

Thanks for the report.
@Tobias-08 without a media type, how should we interpret the various properties of the manifest? When an image like this is pushed to Docker hub or other container registries, what defaults do they have?

Yeah, your last point is what I was getting at. At this point I agree with you that per spec the manifest is valid, and I think that we need to see what other tools do in the absence of this (seemingly critical) information. Do they assume a certain media type? Do they probe for properties that only exist in one media type or another? Etc.

@Tobias-08 is there any chance you could provide a sample base image or link to one for testing purposes?

I think that Docker at least defaults a manifests' mediaType to "application/vnd.docker.distribution.manifest.v2+json", based on this default which is mapped to a mediaType in this check


delete kwargs.req after parsing

See #339

Can this please get accepted?  It's been a bug for a long time and your customers are losing important data.

Pinging @benvinegar and @MaxBittker - please merge and release a new version asap

your customers are losing important data.

I don't believe this is causing people to lose data, it just causes this processing error warning on the event page for people using the middleware:

If this is in fact causing people to lose data, can you give an example of how?


Requests signed with certificates(PEM/Key)

Is your feature request related to a problem? Please describe.
i would like to send some request signed with certificates(PEM/KEY). but i cant passed a the certificate.
Describe the solution you'd like
i would like to passe a certificate via file or string, and it send my request.

This is an interesting use case. I haven't came across into such scenario.
To further understand the requirement, do you have an example to perform such request with any other popular libraries like http, request or phin.
If you an example code with phin, that would really help us to tackle this requirement.

i found this example using Request
const fs = require('fs')
    , path = require('path')
    , certFile = path.resolve(__dirname, 'ssl/client.crt')
    , keyFile = path.resolve(__dirname, 'ssl/client.key')
    , caFile = path.resolve(__dirname, 'ssl/ca.cert.pem')
    , request = require('request');

const options = {
    url: 'https://api.some-server.com/',
    cert: fs.readFileSync(certFile),
    key: fs.readFileSync(keyFile),
    passphrase: 'password',
    ca: fs.readFileSync(caFile)
};

request.get(options);

i didnt find example with Phin
Thanks!

You need to create a new agent with all the certification information and them pass the information to withCore method.
const http = require('http');
const agent = new http.Agent({
  cert: '',
  key: ''
});

const pactum = require('pactum');

await pactum.spec()
  .get('<url>')
  .withCore({ agent });

I hope this would work.

``I made a small change and its working

const https = require('https');
let pem = path.resolve(__dirname, 'your-path-pem')
let key = path.resolve(__dirname, 'your-path-key')

const agent = new https.Agent({
            cert: fs.readFileSync(pem),
            key: fs.readFileSync(key),
            passphrase: ""
 });

await pactum.spec()
     .post('your-uri')
     .withBody(body)
     .withCore({ agent })

As I wrote in https://github.com/pactumjs/pactum/discussions/252#discussioncomment-4501041,
also with the suggestion above, Pactum complains that it is UNABLE_TO_VERIFY_LEAF_SIGNATURE. Instead accessing my server over http2 succeeded.


Create a "Windows Desktop application" for Visual Studio 2019

I trying to follow "Walkthrough: Create a traditional Windows Desktop application (C++)" but is for Visual Studio 2017 and I using Visual Studio 2019, ist hard to follow the tutorial, I cant find "Windows application (.exe)" in "Windows Desktop Project" of the "Windows Desktop Wizard" I find only "Console application (.exe)" and "Desktop application (.exe)", so what should I choose?

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

ID: eda99bc7-483b-e53c-1035-886f4d0955f4
Version Independent ID: a6fdba4d-53e4-9f1a-2352-bc68ef491069
Content: Walkthrough: Create a traditional Windows Desktop application (C++)
Content Source: docs/windows/walkthrough-creating-windows-desktop-applications-cpp.md
Product: visual-cpp
Technology: cpp-windows
GitHub Login: @mikeblome
Microsoft Alias: mblome

@SuperDragonM apologies! You should choose Desktop Application (.exe). We are working as fast as we can to create new topics for Visual Studio 2019.  This planned work is on our backlog so I am closing this particular issue. Feel free to file a new issue if you encounter other problems.


Shareable Config

Related to #2 are there any plans to include an extends type property to support shareable configs?

@adam-moss, I'm not exactly sure what you mean by shareable configs. licensee currently loads any .licensee.json for configuration. You can produce that JSON file however you like.

So what I mean here is the
{
    extends: [ "moduleA", "moduleB" ]
}

Type of pattern.  i.e. the project .licensee.json essentially imports its config from one or more other modules, so that a common baseline of whitelisted packages can be shared.
Does that make sense?

@adam-moss, thanks for clarifying.
I'm open to input from others, but I don't expect I'll putt any time on that kind of configuration.
Figuring out how to do that kind of system correctly may be a bigger and harder problem than licensee otherwise tries to solve. And I know from experience that programs with support for that kind of configuration---eslint comes to mind---cause all manner of headaches, in terms of making sure modularized configs are properly installed, reading from disk, etc. It's often a real pain to get them configured, and even when you do, and come back to a project later, it's pretty common for something to have shifted, creating a break.
I would much rather keep licensee as small and focused as possible, and let folks do whatever they want to do to compose the JSON or command line flag arguments for the configuration they want.
{
  "scripts": {
    "prelicense": "node compose-config.js > .licensee.json",
    "license": "licensee"
  }
}

I might change my tune if someone managed to package up the functionality you're describing in a lean and focused package that we could rely on. But even then, I'm loathe to bring anything more in scope than I have to.


What does it mean that it does not support the autoregressive case?

It's not possible to enforce that the past does not see the future when you project along the sequence dimension, as is done in this variant of efficient attention


Unit tests for Command.java

More unit tests are needed for Command.java

@charlesmike hello

@charlesmike hello

Hi, @amihaiemil! I can help you index your Github-hosted website, provided that the repository name respects the format owner.github.io (or has a gh-pages branch) and the command is given by the repo's owner.

@charlesmike index

@charlesmike index

@amihaiemil thank you for the command, the indexing process started just now. I will let you know of the outcome shortly.

@charlesmike online?

@charlesmike online?

@amihaiemil sorry I do not understand you. See this link for more details.

@charlesmike hi

@charlesmike hi

Hi, @amihaiemil! I can help you index your Github-hosted website, provided that the repository name respects the format owner.github.io (or has a gh-pages branch) and the command is given by the repo's owner.

Done


Error undefined variable dict object

So I have been trying to setup internet-pi on my Pi 3b and after running ansible-playbook main.yml  I get the error
"
An exception occurred during task execution. To see the full traceback, use -vvv.
What changes did you perform?

Ok, this might be your problem.
There are two options:

You run it from another machine and remotely install on the Pi, then you change the second line in inventory.ini.

Thanks! And sorry for the late reply I cought covid lol


Add blogs - @emmyft moving on and @seun joining

https://hackmd.io/Wiy6CCL3Qge6FZhtdxUlvg?view both here

[ ] emmy
[ ] Seun

whoops I made a duplicate. Closing, this is a duplicate of #809


About aggregate evaluation

Thanks for your great paper.
One question about aggregate evaluation, why metrics like MMLU are not included in aggregate evaluation?

We do MMLU evaluation for our Zamba model.
For the dataset ablations we performed the same evaluations as Dolma and Refinedweb for comparison purposes.