Updated Login button#1398

Improved login button
Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state "None”]
Description
[Please include a brief description of the changes or features added]
Type of PR

[ ] Bug fix
[ ] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes]
Checklist:

[ ] I have performed a self-review of my code
[ ] I have read and followed the Contribution Guidelines.
[ ] I have tested the changes thoroughly before submitting this pull request.
[ ] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[ ] I have commented my code, particularly in hard-to-understand areas.

Additional context:
[Include any additional information or context that might be helpful for reviewers.]

hey i have updated login button please check @arghadipmanna101

plz work on present web site. link - https://flipkart-clone-seven-azure.vercel.app/

OK so will you merge this pr and github link for the new website @arghadipmanna101

OK so will you please merge this pr and github link for the new website repo @arghadipmanna101

No i can't merge.


No menu bar at all with global menus on Linux

Using Arch Linux, KDE 4 with DBusMenu and Atom 1.0.0.  I can’t see a menu bar, I also can’t enable it in any way, and it does not appear on my panel either.  It worked in 0.211.0.
local/libdbusmenu 12.10.2-2
    A library for passing menus over DBus
local/libdbusmenu-glib 12.10.2-4
    A library for passing menus over DBus
local/libdbusmenu-gtk2 12.10.2-3
    A library for passing menus over DBus
local/libdbusmenu-gtk3 12.10.2-4
    A library for passing menus over DBus
local/libdbusmenu-qt4 0.9.3+15.10.20150604-1
    A library that provides a Qt4 implementation of the DBusMenu spec
local/libdbusmenu-qt5 0.9.3+15.10.20150604-1
    A library that provides a Qt implementation of the DBusMenu spec
local/atom-editor-bin 1.0.0-1
    Chrome-based text editor from Github - Precompiled binary from official repository

Fixed by restarting KDE.
And you would think that works for Windows only…


puppet node_manager pin does not pin or error

puppet node_manager pin does not pin or error, given ...
Define a group:
[root@pe-201817-master ~]# cat pin.pp
node_group { 'Pin Test':
  ensure => present,
  parent => 'PE Infrastructure',
}

Create the group:
[root@pe-201817-master ~]# puppet apply pin.pp
Notice: Compiled catalog for pe-201817-master.puppetdebug.vlan in environment production in 0.05 seconds
Notice: New node_group 'Pin Test' with ID 'ed116200-488e-45ac-99ff-4608c4f48816'
Notice: /Stage[main]/Main/Node_group[Pin Test]/ensure: created
Notice: Applied catalog in 2.39 seconds

Inspect the group (Confirmed in the Console):
[root@pe-201817-master ~]# puppet resource node_group 'Pin Test'
node_group { 'Pin Test':
  ensure               => 'present',
  environment          => 'production',
  id                   => 'ed116200-488e-45ac-99ff-4608c4f48816',
  override_environment => 'false',
  parent               => 'PE Infrastructure',
  rule                 => [''],
}

Pin an existing node:
[root@pe-201817-master ~]# puppet node_manager pin --node_group 'Pin Test' pe-201817-agent.puppetdebug.vlan

Inspect the group (Confirmed in the Console):
[root@pe-201817-master ~]# puppet resource node_group 'Pin Test'
node_group { 'Pin Test':
  ensure               => 'present',
  environment          => 'production',
  id                   => 'ed116200-488e-45ac-99ff-4608c4f48816',
  override_environment => 'false',
  parent               => 'PE Infrastructure',
  rule                 => [''],
}

Also, why is there no unpin from a specific group?
puppet node_manager unpin --node_group GROUP nodename

:)

@tkishel If it's not pinning, that's a bug I should look into.
As for unpinning, when I created the module, this didn't exist:
https://puppet.com/docs/pe/2017.1/nc_groups.html#post-v1groupsidunpin
But now it does, so I'll work on adding it.

Thanks!!!

Ok, was able to pin a node successfully.  One thing, using the face, which is a little more basic, you have to supply the group ID, not the group name.  I did this so each ad-hoc command line action wouldn't run the instances() method and query all groups first.  That said, there was still a bug in there anyway.  Here's the code so far.
https://github.com/WhatsARanjit/puppet-node_manager/tree/issue44
# puppet resource node_group 'Pin Test' ensure=present
Notice: New node_group 'Pin Test' with ID 'c3094616-479b-4eef-980f-92c1805b2070'
Notice: /Node_group[Pin Test]/ensure: created
node_group { 'Pin Test':
  ensure => 'present',
}
# puppet resource node_group 'Pin Test'
node_group { 'Pin Test':
  ensure               => 'present',
  environment          => 'production',
  id                   => 'c3094616-479b-4eef-980f-92c1805b2070',
  override_environment => 'false',
  parent               => 'All Nodes',
  rule                 => [''],
}
# puppet node_manager pin --node_group 'c3094616-479b-4eef-980f-92c1805b2070' 'test.node'
# puppet resource node_group 'Pin Test'
node_group { 'Pin Test':
  ensure               => 'present',
  environment          => 'production',
  id                   => 'c3094616-479b-4eef-980f-92c1805b2070',
  override_environment => 'false',
  parent               => 'All Nodes',
  rule                 => ['or', ['=', 'name', 'test.node']],
}

Alright, added a --all option to the unpin action.
# puppet node_manager unpin --help

USAGE: puppet node_manager unpin [--all] [--node_group GROUP] nodename

Unpin a node from a group

OPTIONS:
  --render-as FORMAT             - The rendering format to use.
  --verbose                      - Whether to log verbosely.
  --debug                        - Whether to log debug information.
  --all                          - Unpin a node from all groups
  --node_group GROUP             - Node group to unpin from

See 'puppet man node_manager' or 'man puppet-node_manager' for full help.

This is a breaking change because previously, unpin would unpin the node from all groups.  Now it will only do all groups if --all is supplied.

So --node_group is an ID not a Name?

Merged.


Basic Cargo based build

Builds the uutils multicall binary containing all utils (except stdbuf)
by default. To only build a subset
cargo --no-default-features --features "<utils>"
can be used.
Whats missing is building the standalone binaries and a mechanism to
automatically disable the build of unix only utils on windows.
Maybe a step towards fixing #655.

should we merge it?

There was some resistance last time I tried to get a cargo build merged.
cc @Arcterus @jbcrail

ping

What were the objections? The Makefile approach to dependencies is not really that great.

See #395

Hm I kind of like having more granular configuration even if there are a few lines that are superfluous. Having said that, it's not like I actually contribute much.
The make build seems to take a lot longer than your cargo build, even under --release.  Are you building everything make is? it's like ~1m (30s without --release) versus ~4m for make.  If you are, this would be a reason enough to upgrade.

It'd certainly be helpful to have a cargo build to run things like clippy and would generally be more welcoming to newbies (such as myself) who haven't got much of a background in C/C++ and thus are not well-versed in make.
I could imagine it'd end up benefiting the project despite the extra effort of having to maintain both cargo and make builds.

I suppose we could merge this and see which system we prefer (I assume we would remove one of them at some point).

Then I'm merging this. If there will be serious problems please revert


Bump SBT from v0.13.6-M1-31-g0b2f2ae5a to 0.13

Hopefully will work after the fixes in sbt/sbt#1523.
Fixes scala/community-builds#480

Let's merge first and ask questions later :-)

https://scala-ci.typesafe.com/job/scala-2.11.x-integrate-community-build/524

still working on this -- committed directly to 2.11.x

The bintray plugin fails with None.get...
https://scala-ci.typesafe.com/job/scala-2.11.x-integrate-community-build/526/console

https://github.com/typesafehub/dbuild/issues/158

Reverting this version bump until we can fix the bintray issue.

previous discussion on building sbt as part of the community build: https://github.com/scala/community-builds/pull/290


EOF error when loading 1GB onnx model

Describe the bug
I'm trying to load a 1GB lilt.onnx model with modelmesh. The model has been tested directly in Triton, so should be loadable. But I get back an EOF error. The triton container does not have any logs beside the startup logs. The triton-adapter and mm container do contain errors.
To Reproduce

Setup ModelMesh-serving with the Getting started.
Upload a 1GB onnx model into the Minio onnx directory.
Create a onnx InferenceService.

kubectl apply -f - <<EOF
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: onnx-example-lilt
  annotations:
    serving.kserve.io/deploymentMode: ModelMesh
spec:
  predictor:
    model:
      modelFormat:
        name: onnx
      storage:
        key: localMinIO
        path: onnx/lilt.onnx
        parameters:
          bucket: modelmesh-example-models
EOF

Expected behavior
I would expect the model to load, or would expect a clear error message.
Environment (please complete the following information):

OS: Ubuntu 22.04 (KIND for Kubernetes)

Additional context
isvc status
Status:
  Conditions:
    Last Transition Time:  2023-09-13T07:46:55Z
    Status:                False
    Type:                  PredictorReady
    Last Transition Time:  2023-09-13T07:46:55Z
    Status:                False
    Type:                  Ready
  Model Status:
    Copies:
      Failed Copies:  2
      Total Copies:   2
    Last Failure Info:
      Location:             4b45d5-xmm2v
      Message:              UNAVAILABLE: Failed to load Model due to Triton runtime error: rpc error: code = Unavailable desc = error reading from server: EOF
      Model Revision Name:  onnx-example-lilt__isvc-5c217e7471
      Reason:               ModelLoadFailed
      Time:                 2023-09-13T07:46:54Z
    States:
      Active Model State:  FailedToLoad
      Target Model State:
    Transition Status:     UpToDate
Events:                    <none>

triton-adapter logs
1.6945902122509565e+09	INFO	Triton Adapter.Triton Adapter Server.Load Model	Using model type	{"model_id": "onnx-example-lilt__isvc-5c217e7471", "model_type": "onnx"}
1.6945902122510161e+09	DEBUG	Triton Adapter.Triton Adapter Server	Reading storage credentials
1.6945902122510774e+09	DEBUG	Triton Adapter.Triton Adapter Server	found existing client in cache	{"type": "s3", "cacheKey": "s3|0x33b60418eef4115e"}
1.6945902122564182e+09	DEBUG	Triton Adapter.Triton Adapter Server	found objects to download	{"type": "s3", "cacheKey": "s3|0x33b60418eef4115e", "path": "onnx/lilt.onnx", "count": 1}
1.694590212256669e+09	DEBUG	Triton Adapter.Triton Adapter Server	downloading object	{"type": "s3", "cacheKey": "s3|0x33b60418eef4115e", "path": "onnx/lilt.onnx", "filename": "/models/onnx-example-lilt__isvc-5c217e7471/lilt.onnx"}
1.694590214431798e+09	ERROR	Triton Adapter.Triton Adapter Server.Load Model	Triton failed to load model	{"model_id": "onnx-example-lilt__isvc-5c217e7471", "error": "rpc error: code = Unavailable desc = error reading from server: EOF"}
github.com/kserve/modelmesh-runtime-adapter/internal/proto/mmesh._ModelRuntime_LoadModel_Handler
	/opt/app/internal/proto/mmesh/model-runtime_grpc.pb.go:181
google.golang.org/grpc.(*Server).processUnaryRPC
	/root/go/pkg/mod/google.golang.org/grpc@v1.49.0/server.go:1301
google.golang.org/grpc.(*Server).handleStream
	/root/go/pkg/mod/google.golang.org/grpc@v1.49.0/server.go:1642
google.golang.org/grpc.(*Server).serveStreams.func1.2
	/root/go/pkg/mod/google.golang.org/grpc@v1.49.0/server.go:938

mm logs
{"instant":{"epochSecond":1694591214,"nanoOfSecond":743250378},"thread":"model-load-onnx-example-lilt__isvc-5c217e7471","level":"ERROR","loggerName":"com.ibm.watson.modelmesh.ModelMesh","message":"Model load failed for onnx-example-lilt__isvc-5c217e7471 type=mt:onnx","thrown":{"commonElementCount":0,"localizedMessage":"UNAVAILABLE: Failed to load Model due to Triton runtime error: rpc error: code = Unavailable desc = error reading from server: EOF","message":"UNAVAILABLE: Failed to load Model due to Triton runtime error: rpc error: code = Unavailable desc = error reading from server: EOF","name":"io.grpc.StatusRuntimeException","extendedStackTrace":[{"class":"io.grpc.Status","method":"asRuntimeException","file":"Status.java","line":537,"exact":false,"location":"grpc-api-1.57.2.jar","version":"1.57.2"},{"class":"io.grpc.stub.ClientCalls$UnaryStreamToFuture","method":"onClose","file":"ClientCalls.java","line":548,"exact":false,"location":"grpc-stub-1.57.2.jar","version":"1.57.2"},{"class":"io.grpc.internal.ClientCallImpl","method":"closeObserver","file":"ClientCallImpl.java","line":567,"exact":false,"location":"grpc-core-1.57.2.jar","version":"1.57.2"},{"class":"io.grpc.internal.ClientCallImpl","method":"access$300","file":"ClientCallImpl.java","line":71,"exact":false,"location":"grpc-core-1.57.2.jar","version":"1.57.2"},{"class":"io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed","method":"runInternal","file":"ClientCallImpl.java","line":735,"exact":false,"location":"grpc-core-1.57.2.jar","version":"1.57.2"},{"class":"io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed","method":"runInContext","file":"ClientCallImpl.java","line":716,"exact":false,"location":"grpc-core-1.57.2.jar","version":"1.57.2"},{"class":"io.grpc.internal.ContextRunnable","method":"run","file":"ContextRunnable.java","line":37,"exact":false,"location":"grpc-core-1.57.2.jar","version":"1.57.2"},{"class":"io.grpc.internal.SerializingExecutor","method":"run","file":"SerializingExecutor.java","line":133,"exact":false,"location":"grpc-core-1.57.2.jar","version":"1.57.2"},{"class":"java.util.concurrent.ThreadPoolExecutor","method":"runWorker","file":"ThreadPoolExecutor.java","line":1136,"exact":false,"location":"?","version":"?"},{"class":"java.util.concurrent.ThreadPoolExecutor$Worker","method":"run","file":"ThreadPoolExecutor.java","line":635,"exact":false,"location":"?","version":"?"},{"class":"java.lang.Thread","method":"run","file":"Thread.java","line":833,"exact":false,"location":"?","version":"?"}]},"endOfBatch":false,"loggerFqcn":"org.apache.logging.log4j.spi.AbstractLogger","contextMap":{},"threadId":69,"threadPriority":5}

The triton container has contains no logs beside the startup.

Giving triton all my memory seemed to fix it 😅


✅ [B-862] Add e2e tests for requested payments

This item belongs to payment request #F78085 on OnlyDust:

from oscarwroche to oscarwroche
35 items included
$1,000 for 2 days of work

This item belongs to payment request #D812A4 on OnlyDust:

from oscarwroche to oscarwroche
35 items included
$1,000 for 2 days of work


[Update Request]: Update SiarheiKuchuk.BUtil to version 2024.09.29

What type of update are you requesting?
A new version of an existing package
Current Package Identifier
SiarheiKuchuk.BUtil
Package Version
2024.09.29
Please describe the changes you would like to see
New Features

Bengali, Urdu, Indonesian, Japanese, Nigerian Pidgin, Marathi, Telugu languages.
It is possible to copy text from message.
On task deletion log files are deleted as well.

Changes

7-zip update to 24.08
7-zip is not used anymore to compress/encrypt files because of 7% average space profit (each file is compressed individually) with drawbacks of not supporting Android devices
Update libraries
Unit-tests are part of build.ps1 script execution
Storage format upgrade. Previous versions of applications won't be able to open it. Backward compatibility for restoration etc will be preserved for some time.
Checking for updates was switched back to github since upload was fixed, personal site at NAS will be shutdown after some time.
Messages for questions was improved.

Bug Fixes

Message buttons locations was invalid
Message text locations was invalid
! Incremental backup creates version when duplicate files exists
Task status was missing on rename
Import multimedia with skip already imported flag was not working correctly during rename of task

Should be closed as completed manually.

See #175726

Should be closed as completed manually.

See [Update Request]: Update SiarheiKuchuk.BUtil to version 2024.09.29 #175726

Thanks!


This change will help keep the image small

This change will help keep the image small

Hi @lvnilesh, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

Note that this won't actually reduce the image size, unless the image in question is squashed. Docker build uses a layered filesystem, so removing the file in another layer still retains the file (and the size) in the previous layer. You can see another approach here: https://github.com/PowerShell/PowerShell/pull/1992

Restarted travis CI due to time out.

@garethr is correct, the binary still exists in the layer where it was added. Closing, but thanks for contributing!


Pointcloud is very bad and wavely even using filters

I am using some filters built in, but result are really wavely:

With the quality of point cloud, I don't think it can be used to do any applications. model is D435

This type of errors can be usually significantly reduced by recalibrating the camera using provided tools

@dorian3d Thanks for you reply. I am now using the right calibration now, it seems better:

As you can see, the plane can be flat now (though it is very close, but I am good with it)
another serious thing is: how to remove the points in the middle air?
you can tell it is full with points that doesn't  has any objects. How to remove those middle air points out?

Hi @jinfagang,
Please refer to the following white-paper for tuning the depth performance. Choosing a higher accuracy preset and/or applying some filters would be something to quickly try and see the outcome using the RealSense Viewer app.
https://www.intel.com/content/dam/support/us/en/documents/emerging-technologies/intel-realsense-technology/BKMs_Tuning_RealSense_D4xx_Cam.pdf


Guards for Array Axioms

Suggested improvements to the array axioms from @utting:
axiom (forall a:[int]Any,i:int,v:Any ::
  ((0 <= i) && ((i < Array#Length(a)) && (v != Void))) ==> (Array#Length(a) == Array#Length(a[i:=v])));

axiom (forall a:[int]Any,l:int ::
  ((0 <= l) && (Array#Empty(l) == a)) ==> (Array#Length(a) == l));

axiom (forall a:[int]Any,v:Any,l:int ::
  ((0 <= l) && ((v != Void) && (Array#Generator(v,l) == a))) ==> (Array#Length(a) == l));

[ ] Add Array#in
[ ] Update Array#is
[ ] Update Array#Length axioms.

This is the proof that Mark provided:
let a0 : [int]Any = Array#Generator(42,0)
  let a1 : [int]Any = Array#Generator(42,1)
  Then we can prove:
  1.    a0 == lambda i. Void
  2.    a1 == (lambda i. if i == 0 then == 42 else Void)
  3.    length(a0) == 0       // from axiom 6
  4.    length(a1) == 1       // from axiom 6

   Now let b = a1[0 := Void]
   then we have:
   5.   length(b) == length(a1) == 1     // by axiom 7
   6.   b == (lambda i. Void)               // by standard properties of Boogie maps
   7.   b == a0                                  // since a0 == (lambda i. Void)
   8.   length(b) == length(a0) == 0     // from 7 and 3
   9.   1 == 0                                    // from 5 and 8

Ok, disjointness problem is also not an issue.  Currently, have this in the prelude:
function Int#is(v : Any) returns (bool) {
   (exists i:int :: Int#box(i) == v)
}
axiom (forall i:int :: Int#box(i) != Void);

...

axiom (forall v:Any :: Int#is(v) ==> ((!Null#is(v)) && (!Byte#is(v)) && (!Bool#is(v)) && (!Array#is(v)) && (!Record#is(v)) && (!Ref#is(v)) && (!Lambda#is(v))));

This allows us to conclude that v != Void if Int#is(v).  We could remove the axiom axiom (forall i:int :: Int#box(i) != Void), and fold it into the other giving axiom (forall v:Any :: Int#is(v) ==> (v != Void && ...  But, I have a feeling that is not equivalent since we cannot conclude that Int#box(i) != Void given Int#is(v).  I would guess Whiley like this would cause a problem:
int[] xs = [0]

This generates the following:
xs := Array#Empty(1)[0:=Int#box(0)];
assert (forall i#0:int :: Array#in(xs,i#0) ==> Int#is(xs[i#0]));

Hmmm, the above logic seems funny since it could equally be applied to Null which is not protected like Void.  Maybe what we should write is this:
axiom (forall i:int :: Int#is(Int#box(i)));
...
axiom (forall v:Any :: Int#is(v) ==> (!Void#is(v) && (!Null#is(v)) && (!Byte#is(v)) && (!Bool#is(v)) && ... ));

There is an outside chance that this latter change might explain some problems with recursive types, but I wouldn't hold my breath.  It would need to be tested.


✨[Feature Request]: Community Health Events Calendar

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
A feature designed to keep patients informed about upcoming health-related events in their local area. This feature will provide a centralized calendar on the RAPIDOC-HEALTHCARE-WEBSITE where users can view and receive notifications about seminars, workshops, health camps, and other community health activities.
Use Case
The Community Health Events Calendar provides a valuable resource for users, promoting engagement with local health initiatives and supporting their journey to better health.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

where will you add this ?

I'll create a section on the homepage that highlights a selection of upcoming events, such as health camps or seminars. This section will provide a preview of these events to users visiting the homepage, allowing them to quickly see what's coming up.

where will you add this ?

I'll create a section on the homepage that highlights a selection of upcoming events, such as health camps or seminars. This section will provide a preview of these events to users visiting the homepage, allowing them to quickly see what's coming up.

Provide layout


Issue moving mujoco gameobject with transform.position in unity

Hi,
I'm a student and I'm trying to use the MuJoCo Unity plug-in and HAPTIX to study human performance of referred robotic arm control. I am running MuJoCo 3.1.1 on Unity 2022.3.5f1
Currently I have an environment with a mujoco element in it (a cylinder with an mjbody, mj free joint, and mjgeom attached to it) and I want to be able to programmatically move it to different locations on command. Right now I have a C# script that I am trying to use to make it move using transform.position but when I do that the object flashes to the new desired location and then goes right back to where it was the frame before. I am guessing this comes from MuJoCo taking over the physics side of things and having an issue with Unity trying to do something physically impossible with the transform.position command? I was wondering if there is any way I could get around this issue or if I'll just have to destroy the old object and instantiate a new one where I want it to be to get what I want to happen?
Thanks!
Michael

MjBody position is fully determined by the mujoco simulation, and changes in the Unity scene won't be persistent for the next frame (barring a MjScene reconstruction, which is one of your options but may have certain side effects).
If you just want to teleport the object to a new position you can do it the same way it can be done in regular MuJoCo, by editing the qpos array. Here's an example on how to do that:
https://github.com/Balint-H/modular-agents/blob/927a4ead43c8b8e4db902657f37550db3b7d45e9/mj-unity-extensions/Runtime/MjState.cs#L143
If you want full continuous control of an MjBody so the state is only determined by you in Unity, you can use an MjMocapBody, or connecting the MjBody to an MjMocapBody through a weld constraint if you want to allow some deviation from your prescribed position.

Hi Balint,
Thanks for the response, being able to teleport the object would be great. However, I am confused as to how to implement the example you linked. The TeleportMjRoot function looks straightforward enough to use, but I'm not sure how to get to that point within the scripts I currently have -- would I put the MjState.cs in my local .../unity/Runtime level and then call it from my project's scripts or is there some other way?
Thanks,
Michael

Hello, apologies for missing your message for so long... the approach you describe is indeed how its meant to be used. Of course if you want you can copy the relevant parts of MjState to your script as well. Let me know if you since moved on from this problem.


Use tokio executor

Hi, this PR makes it possible to run futures on a tokio runtime in riker:
#[derive(Default)]
struct AsyncActor;

impl Actor for AsyncActor {
    type Msg = MessageType;
    fn recv(&mut self, ctx: &Context<Self::Msg>, msg: Self::Msg, sender: Sender) {
        let handle: tokio::task::JoinHandle<String> = ctx.run(async move {
            // runs in tokio runtime!
            tokio::time::delay_for(tokio::time::Duration::from_millis(10));
            String::from("Done!")
        }).unwrap();
    }
}

#[tokio::main]
async fn main() {
    let mut sys = ActorSystem::new().unwrap();
    let actor = sys.actor_of::<AsyncActor>("async-actor").unwrap()
    loop {
        update(actor);
    }
}

This PR adds a cargo feature tokio_executor which basically replaces the futures::executor::ThreadPool in ActorSystem with tokio::runtime::Handle and changes all dependent code accordingly.
This makes the code a bit messy and I would like to refactor this to encapsulate it more. The only real problem is the different APIs of tokio::JoinHandle and futures::RemoteHandle, which are returned by the respective runtime handles when starting a future execution:

JoinHandle can be dropped and the future will keep running. RemoteHandle needs to call forget()
tokio::Handle.spawn will just return a JoinHandle, futures::executor::ThreadPool.spawn_with_handle returns a Result<RemoteHandle>
Blocking on a JoinHandle returns a Result<T> where blocking on a RemoteHandle just returns T

I would introduce an internal type for representing either of the task handles, with an API respecting both. Depending on the feature, this type would be a RemoteHandle or a JoinHandle under the hood. Maybe the same can be done for the executor.

#150

@mankinskin thanks for taking this on. It's been a much requested feature and is a significant step in bringing Riker to the rest of the async/futures environment. I'll start to review this!

@mankinskin thanks for taking this on. It's been a much requested feature and is a significant step in bringing Riker to the rest of the async/futures environment. I'll start to review this!

Some general notes:

tokio 1.0.0 was just released, it would be nice if we could integrate that directly
One thing thats bugging me is that the tests aren't passing with the feature enabled yet. They don't fail, they just block.

Then tokio works a bit differently than the futures ThreadPool. Since tokio is itself a runtime, it is usually started before anything else. This is different than the ThreadPool field that was hosted by the ActorSystem, with tokio the ActorSystem would probably be hosted by tokio.
I am not that familiar with the riker code right now, but i would very much like to help making it async. A lot in riker already seems to work asynchronously, so we might be able to integrate that with tokio fairly easily and eventually provide async Actor trait implementations, that run directly as tasks on a tokio runtime.

Some general notes:

tokio 1.0.0 was just released, it would be nice if we could integrate that directly
One thing thats bugging me is that the tests aren't passing with the feature enabled yet. They don't fail, they just block.

Then tokio works a bit differently than the futures ThreadPool. Since tokio is itself a runtime, it is usually started before anything else. This is different than the ThreadPool field that was hosted by the ActorSystem, with tokio the ActorSystem would probably be hosted by tokio.
I am not that familiar with the riker code right now, but i would very much like to help making it async. A lot in riker already seems to work asynchronously, so we might be able to integrate that with tokio fairly easily and eventually provide async Actor trait implementations, that run directly as tasks on a tokio runtime.

A question still to be answered is if we want to drop the futures::ThreadPool entirely and only support tokio, or if we want to keep the futures::ThreadPool dependency. I don't think there would be anything wrong with transitioning to tokio completely.

A question still to be answered is if we want to drop the futures::ThreadPool entirely and only support tokio, or if we want to keep the futures::ThreadPool dependency. I don't think there would be anything wrong with transitioning to tokio completely.

Doesn't tokio bring in another rather heavy dependency? And is this then a massive breaking change that would require everyone to retool?

Doesn't tokio bring in another rather heavy dependency? And is this then a massive breaking change that would require everyone to retool?

Doesn't tokio bring in another rather heavy dependency?

Yes, tokio is another dependency, but since it is the fastest and most active async runtime I know of, I think it would be benefitial.

And is this then a massive breaking change that would require everyone to retool?

Yes it does take transitioning from the futures based API to the tokio API, to talk to the runtime.
Originally I wanted to put the different executors behind features, but I am not sure if this is worth it. Maintaining multiple executors has a maintenance cost.
What we could do is introduce something like a runtime module, that encapsulates any runtime that is selected with a feature. But this would require some more work and I am not sure if I know what this project really needs/wants.
I could however revert the removal of the tokio_executor feature, so we can at least opt-into the tokio runtime, instead of defaulting.

Doesn't tokio bring in another rather heavy dependency?

Yes, tokio is another dependency, but since it is the fastest and most active async runtime I know of, I think it would be benefitial.

And is this then a massive breaking change that would require everyone to retool?

Yes it does take transitioning from the futures based API to the tokio API, to talk to the runtime.
Originally I wanted to put the different executors behind features, but I am not sure if this is worth it. Maintaining multiple executors has a maintenance cost.
What we could do is introduce something like a runtime module, that encapsulates any runtime that is selected with a feature. But this would require some more work and I am not sure if I know what this project really needs/wants.
I could however revert the removal of the tokio_executor feature, so we can at least opt-into the tokio runtime, instead of defaulting.

What could be a solution is to transition to async-std, which has the tokio-async-std crate, which instead of running on the futures executor, runs on tokio. But that would still not be backwards compatible obviously.

What could be a solution is to transition to async-std, which has the tokio-async-std crate, which instead of running on the futures executor, runs on tokio. But that would still not be backwards compatible obviously.

I agree that tokio is the most prominent executor and probably even the fastest, but there a other things that people might take into consideration. For example: if you want to use riker on embedded platforms, you might want an executor that is more lightweight.
I think it would be beneficial to support multiple executors or to be completely executor agnostic (e.g.: async_executors or agnostik).

I agree that tokio is the most prominent executor and probably even the fastest, but there a other things that people might take into consideration. For example: if you want to use riker on embedded platforms, you might want an executor that is more lightweight.
I think it would be beneficial to support multiple executors or to be completely executor agnostic (e.g.: async_executors or agnostik).

@hardliner66 valid points. And thank you for these suggestions. I will try to integrate on of them in this PR when I have time 👍

@hardliner66 valid points. And thank you for these suggestions. I will try to integrate on of them in this PR when I have time 👍

I've tried to integrate an agnostic executor into riker and both options doesn't play well with the current riker architecture.
Agnostik executor trait is not object-safe, therefore, to include it in the ActorSystem is not as simple as boxing it inside an Arc, you need to add a type parameter. And this type parameter leaks and ends up affecting many many structs end impl, you need to introduce it all over riker.
This option might work (if no other problems are found). I was in the middle of adding the type parameter where needed to test it. But I decided is better to ask first if this is the way you want to go before fixing the new type parameter everywhere.
async_executors executor trait is object-safe, but if you want to receive a JoinHandle after spawning you need to provide a type parameter for the output type of the spawned futures. This, AFAIK, wouldn't work well with riker architecture.
I think it's important to discuss if we really need riak to be executor agnostic, if we want it to use tokio executor, as it's the most used executor today, or even implement a custom solution for a fixed set of executors based on enums instead of traits.
If I have some time, I might try to finish the test with Agnostik to see if it's even an option and think more about a possible enum based solution.

I've tried to integrate an agnostic executor into riker and both options doesn't play well with the current riker architecture.
Agnostik executor trait is not object-safe, therefore, to include it in the ActorSystem is not as simple as boxing it inside an Arc, you need to add a type parameter. And this type parameter leaks and ends up affecting many many structs end impl, you need to introduce it all over riker.
This option might work (if no other problems are found). I was in the middle of adding the type parameter where needed to test it. But I decided is better to ask first if this is the way you want to go before fixing the new type parameter everywhere.
async_executors executor trait is object-safe, but if you want to receive a JoinHandle after spawning you need to provide a type parameter for the output type of the spawned futures. This, AFAIK, wouldn't work well with riker architecture.
I think it's important to discuss if we really need riak to be executor agnostic, if we want it to use tokio executor, as it's the most used executor today, or even implement a custom solution for a fixed set of executors based on enums instead of traits.
If I have some time, I might try to finish the test with Agnostik to see if it's even an option and think more about a possible enum based solution.

Another option to cover the different use cases would be to keep the current executor under a feature flag (when something lightweight is needed) and the tokio executor under another feature flag for general use case and compatibility.
This is probably easier to implement than using Agnostik and better than the Enum idea. And it could be extended in the future with other flags if needed.

Another option to cover the different use cases would be to keep the current executor under a feature flag (when something lightweight is needed) and the tokio executor under another feature flag for general use case and compatibility.
This is probably easier to implement than using Agnostik and better than the Enum idea. And it could be extended in the future with other flags if needed.

I implemented the different executors behind feature flags, but it was a very simple implementation, basically just adding cfg annotations everywhere where compiler errors occurred. It worked, but was very ugly because the cfg annotations were spread all over different modules.
It would be great to have something like agnostik work, especially if they support more executors in the future. If that does not work, I think the best solution would be to encapsulate all of the Executor and SpawnHandle logic into internal types/traits so that all of the riker code can target a single API, and then select the specific implementation using the cfg feature annotation only in that module.
This should be fairly simple to do, but I really don't have any time until after next week.

I implemented the different executors behind feature flags, but it was a very simple implementation, basically just adding cfg annotations everywhere where compiler errors occurred. It worked, but was very ugly because the cfg annotations were spread all over different modules.
It would be great to have something like agnostik work, especially if they support more executors in the future. If that does not work, I think the best solution would be to encapsulate all of the Executor and SpawnHandle logic into internal types/traits so that all of the riker code can target a single API, and then select the specific implementation using the cfg feature annotation only in that module.
This should be fairly simple to do, but I really don't have any time until after next week.

One other important thing is that the riker-testkit has to be adapted to this too. So the same steps should be taken there. This is the related pull request https://github.com/riker-rs/riker-testkit/pull/1

One other important thing is that the riker-testkit has to be adapted to this too. So the same steps should be taken there. This is the related pull request https://github.com/riker-rs/riker-testkit/pull/1

Just to let you know that the past weekend I've been investigating the solutions for agnostic async executors, and I'm trying to write a new crate without the limitations of the others that made it so difficult to integrate into riker.
I have something working already that would be enough for riker, but ideally this should be a generally useful crate beyond that, and I'm still trying to figure out how much can be done in a completely agnostic way.

Just to let you know that the past weekend I've been investigating the solutions for agnostic async executors, and I'm trying to write a new crate without the limitations of the others that made it so difficult to integrate into riker.
I have something working already that would be enough for riker, but ideally this should be a generally useful crate beyond that, and I'm still trying to figure out how much can be done in a completely agnostic way.

Cool! I can try to integrate it into this patch soon and give you feedback. Don't hesitate to submit your own pull request when you're ready before though. I just have some assignments to finish first.

Cool! I can try to integrate it into this patch soon and give you feedback. Don't hesitate to submit your own pull request when you're ready before though. I just have some assignments to finish first.

@siriux can you explain what the limitations of agnostik or async_executors were?

@mankinskin I've continued with this the last few days and the rabbit hole of agnostic async executors is really deep, but I'm starting to see the light.
The main architectural problem with agnostik (apart from bugs, missing features, ... that could be fixed) is that is not object-safe.
This is on purpose, to be able to give you a nice API on the trait. You can see it here, the output type of the join handle is a type parameter of the spawn* function. But this makes the trait not object-safe. This means we cannot store it as a trait object and we have to put a type parameter for it wherever we want to store it, and in the case of riker this parameter spreads everywhere which is not good.
The alternative using traits is what async_executors is doing, have a spawn handle trait with an output type parameter on the trait itself. This is object-safe, but it requires that you know in advance the return type. This might work for  some libraries but not for something as generic as riker, and is a pretty big limitation in general. Also, the way of working with this is completely different to working with the underlying executors. You can see it here inside the declaration.
Both of this ways of trying to be agnostic using traits don't have a big performance impact, but impose big limitations. An alternative, that is used in the futures crate (currently used by riker) is to have an executor trait that doesn't return anything, and therefore you don't have to worry about the output type.  And when you need an output you can create a oneshot channel and receive the result trough it (see RemoteHandle implementation). This removes all the limitations imposed before but it has some overhead (that riker is already paying).
When I wrote my last comment I had an implementation based on this idea (based on this library) that I improved and extended, but at the same time I continued learning and thinking and I found a better solution.
The main thing those libraries are doing is hiding the executor behind a trait and then implementing it. In theory, you could implement this trait yourself outside of the library, but in practice this is really hard and many times even impossible, so this libraries are not really agnostic, but agnostic over a set of predefined executors and if you need more you have to add them to the library itself.
If that's the case, why do we need the trait at all? We can use an enum with different variants that are under different config features for each executor/option. This doesn't have any of the problems of the traits or the performance overhead (and has some extra benefits). Of course, it's important to cover many uses cases and all the main libraries (and to be open to include new ones if they get traction) but in practice this is as flexible as the other "agnostic" libraries.
But in addition to this, if we want a library that can be used in many projects, we need to do it right and support a shared subset of all the libraries that really works.
What I've been working on is tokio, async_std, smol, futures, and wasm_bindgen_futures  (and I've been loking to async_global_executor), and there are many many differences and details between them but they are the most used and cover all the main use cases. Big systems and compatibility with tokio and async_std, minimal with smol and futures, and wasm with wasm_bindgen_futures. Maybe embedded systems and no-std are the only things missing.
Also I've tested many variations of the architecture of the library until I've been able to find something that works well. The main problem has been having a spawn_local that is useful and works with tokio and futures. After trying many things that didn't work I have a solution that should work half implemented.
Another important thing is to be able to support timers that work everywhere and that reuse the internal timers when possible because they have a really good implementation in some of the executors. This is already working, and can be used as the base for even more agnostic things like IO, but that's another story.
You can see what I have right now here (except some things I'm still working on I didn't commit yet). I think I'm on the right track and I can have something complete soon, but the problem is much deeper than I thought when I started.

Thanks for this write-up! If I understand correctly, I think you wouldn't even need the enum, right? unless you want to support multiple executors at the same time, you can just implement the JoinHandle and ExecutorHandle types directly for each feature.
Another thing I thought about was to let users pass an executor handle to the ActorSystem when creating it. That would be great, because users could pick any executor and riker wouldn't have to maintain compatibility crates. The problems here are of course

we want to spawn arbitiary futures (e.g. generic return type)
we don't want ActorSystem to be generic, because a lot of other code would then need to be generic
we can't spawn arbitiary futures from a non-generic trait object, because generic trait methods are not object safe

But if riker already relies on oneshot channels to return the output, we could easily define an Executor trait (similar to async_executors::SpawnHandle), that can only spawn futures returning (). That would be object safe, so we can store it in a trait object in non-generic ActorSystem, and code using the executor to spawn futures can wrap the JoinHandle<()> in a generic handle along with a channel receiver for the return value.
Something like
struct FutureHandle<T: Send> {
    handle: JoinHandle<()>,
    recv: Receiver<T>,
}

impl<T: Send> Future for FutureHandle<T> {
    type Output = T;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
         // poll handle
         // then receiver
         // return value
    }
}

And ActorSystem's run function could wrap the already generic future with the channel and spawn it on the executor as a Future<Output=()>, then return a FutureHandle<T>.
What do you think about this?

you can just implement the JoinHandle and ExecutorHandle types directly for each feature.

In theory you don't need the enum, but I think it's more convenient. As you said, you can enable multiple executors at the same time and that's pretty convenient for testing against all backends, but I'm sure some apps might need this too.
Also, if you don't use an enum you need to ensure all the implementations have the same signatures, that all are clone, send, sync, ... and like with tests, you cannot just enable all features and check once, you need to do it one by one. And not only for the main executor type, for JoinHandle, ...

Another thing I thought about was to let users pass an executor handle to the ActorSystem when creating it.

The idea is that libraries that want to be executor agnostic, like riker, depend on agnostic_async_executor without any executor dependent features. They still have access to an AgnosticExecutor type (a struct that wraps an enum) and build anything around it.
Then, final apps that use those libraries depend on one or more executor features that let them create an instance AgnosticExecutor to provide to the library.
Of course, a library that uses agnostic_async_executor will need to depend on some executor features in it's dev dependencies, otherwise it cannot be tested.

... also riker can still provide defaults.

And if you want to provide a default executor, as you said, you need to depend on it. But this should be a feature (maybe default?) on riker, otherwise if you use other executor you are still depending on the default one.

The problems here are of course

I'm not sure what you mean about the problems you present. Those are a good summary of the problems of the previous agnostic libraries, but my new library has been designed to solve all of them.
In riker you don't need an executor trait, you use the AgnosticExecutor struct provided by agnostic_async_executor.
This struct wraps the enum we talked about before, so you don't have to match on it or even have access to it. And it's clone, send, sync, ... doesn't require mut to spawn, ... So in practice you can do whatever you want with it like any other simple struct. That's a big difference with respect to the trait based approaches.
(As a note, if you try to introduce spawn_local in a direct way, as I tried before, you lose the Send property of AgnosticExecutor, among many other compatibility problems and blocks. That's mainly due to the design of tokio and the futures crate, that is very limiting with respect to spawn_local. I'm working on a new design for spawn_local that solves this, a description of the idea is in the TODO file.)

But if riker already relies on oneshot channels to return the output, we could easily define an Executor trait

Riker currently relies on oneshot, but it would be better to avoid this cost when you don't use the futures executor, as other executors handle this case natively.
The spawn method of my library already returns a JoinHandle that provides a value, so no need to do anything else on the riker side. And it achieves this without any extra overhead. For example, it just wraps the handles that tokio, async_std and smol provide, so it should be as fast as them.
For futures and wasm we still use the RemoteHandle from the futures crate (using oneshot internally), but that overhead is imposed by the executors themselves not by my library, you would still pay the cost even if you use the executor directly. To avoid this when you don't need the result we could add an extra async spawn method that returns ().
Also, in some cases you pay a minimal wrapping cost to have a consistent api, for example with the timer errors, but in most cases the optimizer will remove it, even more so when you only use a single executor.
In summary, the purpose of this library is to handle all the details and give you a nice abstraction. So that you don't need to create or implement any traits, or create your own handle types, ... Just use AgnosticExecutor inside riker as if it where the real executor, with it's real JoinHandle, but instead of creating it yourself just receive it from the outside.
I plan to add example crates to the library that show a library crate and a binary crate that uses the library one. So maybe this way it's easier to grasp the idea.

My concern was that agnostic_async_executors would be another dependency that would need to maintain an API to multiple executors. That could lead to a lot of maintenance requirement, that is why I proposed the trait based solution so that users can set the executor themselves. This would however incur the performance cost of the oneshot channels, which we actually want to avoid, obviously.
And apparently it is not really possible to spawn generic futures on generic executors from a non-generic host struct, so we need the compile time feature set anyways.

I looked into integrating your crate with riker, and it seems like you are still working on it. There are some tests that don't compile because method sleep doesn't exist for AgnosticExecutor.
I don't think it makes much sense to support multiple executors at the same time. At least I can't think of a use case where you would need multiple executors and I think that would be out of scope anyways. It would be better if the crate would just wrap those executors behind features, so you can change the executor just by compiling with a different feature. Currently, riker would have to use features to call the different versions of new_<>_executor, to get the selected executor. Basically it should only need to call AgnosticExecutor::new() and get the executor it selected through the feature.

@mankinskin I don't think the right way to make riker agnostic is to call something like AgnosticExecutor::new() inside riker (except for the default/compatibility case, if we want it).
To cover all the use cases (mine included), and be executor agnostic, the executor should be a parameter you provide to riker when you create the actor system, not something riker creates by itself.
This is needed because I might want to use the executor for something else, or to run async code inside the actor system, or to integrate it with other parts of my application and external libraries. In all those cases I need to have access to it, and to control it's configuration. Otherwise, why make it agnostic? Right now I can let riker run it's own executor internally and create another one for the rest (with problems/limitations, of course).
To avoid breaking changes we can introduce a new method ActorSystem::new_with_executor(...) and leave the previous new() hard coded to the futures crate executor. This would be an exception where we create the executor inside riker for backwards compatibility/simplicity.
About the problems you found, if you took the crate from crates.io, that's probably not really working, I just wanted to learn the process to upload a crate.
The version in github should work (the previous one, and the current one) but you need to enable the right features otherwise you find missing implementations. It's a little bit tricky because wasm-packer has a bug that prevents us from providing features during the tests execution and the only way to do it right now is commenting and uncommenting things in Cargo.toml. Of course all of this will go in the documentation.
But anyway, the library is still under heavy development, so expect broken things.

the executor should be a parameter you provide to riker when you create the actor system

Perfect, this is exactly what I just did. I implemented the idea I had earlier with which you could pass an executor as an argument to ActorSystem. The drawback is that this still uses oneshot channels every time. But I don't see how this can be avoided without making ActorSystem generic or compiling it differently with features. The options I see here are

Hardcode AgnosticExecutor into ActorSystem, compile riker with feature flags for agnostic_async_executors

Pros: faster, because no oneshot channels
Cons: limited support, can not pass custom executor to ActorSystem

default to futures executor in ActorSystem::new(), provide with_executor method to set custom executor

Pros: can set any type implementing some traits as executor, can reuse external executor
Cons: overhead of oneshot channels

I don't think we can throw out the oneshot channels if we want to pass the executor as an argument. If we want to use arbitrary executors with riker, we have to compile riker for each one. But I am not sure how bad the overhead of oneshot really is, and since riker already uses it, I don't think it would be a problem to use it. Also once your crate is finished, we can still use features to install AgnosticExecutor natively and give up the oneshot channels.
My concern for now is to make the riker/tests and riker-testkit agnostic to the executor. I think once that is done it will be much easier to integrate any other kind of executor implementation into riker.

Now the default executor is ThreadPool as before, and tokio can be selected with the tokio_executor feature. Tests for both features pass, but I guess the CI jobs still need to run them for tokio_executor, or all features in general.
A minor issue is that I don't know if we can test riker-macros for different features of riker, because of this issue. riker-macros can only use riker as dev-dependencies, because riker depends on riker-macros, but due to a bug dev-dependencies (riker) can not have features (tokio_executor) enabled through features of the depending crate (riker-macros). And the tests in riker-macros do use ActorSystem and therefore the executor, so it would be nice if we could test those with every executor.
@leenozara I think this PR is ready to be reviewed.

@mankinskin Sorry for the delay getting to reply to this significant PR. Are you able to provide here a short description that summarizes how to configure the tokio executor? Something that I can use as a starting point to review. This will help me build a progressive review rather than just going file by file. It will also help me updating the documentation, which we will need to do since this is a fairly significant update.
This is greatly appreciated!

@leenozara The way it works is that by selecting the tokio_executor feature (this name could still be changed):
# Cargo.toml
riker = { version = "*", features = ["tokio_executor"] }

riker's ActorSystem uses a tokio::runtime::Handle to spawn asynchronous tasks, instead of the default futures::executor::ThreadPool. This Handle is retrieved by tokio::runtime::Handle::current().
That entails that ActorSystem must be started on the executor, instead of starting the executor itself. So when using the tokio_executor, a riker application need to start the tokio executor before starting the ActorSystem, for example using this:
#[tokio::main]
async fn main() {
    let sys = riker::ActorSystem::new().unwrap();
    ...
}

Otherwise Handle::current() will panic.
So you can directly configure the tokio executor independently and ActorSystem will try to spawn tasks on the currently running executor through its runtime::Handle.
In executor.rs you can see the abstraction over executors and tasks which will hopefully make it easier to integrate other executors in the future, for example, @siriux 's agnostic_async_executor, which could use tokio more efficiently. Because right now, every spawned task uses a futures::channel::oneshot::channel (in impl Run for ActorSystem), to retrieve the return value through it's TaskHandle (spawning tasks returns a TaskHandle future).
This oneshot channel should not really be required, but it made implementing the executor agnostic code easier. But actually I am right now thinking it should be pretty easy to remove them entirely at this point, because we can simply implement the required components accordingly for each feature.. but I am not entirely sure if it is really that easy.

@mankinskin @leenozara
Greetings!
Any update on this? I'm using warp/hyper in my project and having two runtimes (futures::executor::ThreadPool and tokio) not a good idea, and sometimes and sometimes it's just inconvenient..

@BratSinot the patch is usable, it is just not using the optimization I mentioned earlier, which would get rid of the overhead of one oneshot channel when using tokio. But that should not be a disadvantage to the version without tokio.
@leenozara would have to review this and merge it after we have resolved any issues.

@BratSinot the patch is usable, it is just not using the optimization I mentioned earlier, which would get rid of the overhead of one oneshot channel when using tokio. But that should not be a disadvantage to the version without tokio.
@leenozara would have to review this and merge it after we have resolved any issues.

Greeting again!
I have some problem with using your branch. Can you give me a hand?
riker = { git = "https://github.com/mankinskin/riker.git", rev = "d691195b133abd1d37678c531b74f2e81409bcf7", features = ["tokio_executor"] }
<...>
asinotov@fedora ➜  actors git:(master) ✗ cargo build
    Updating crates.io index
    Updating git repository `https://github.com/mankinskin/riker.git`
error: failed to select a version for `riker`.
    ... required by package `actors v0.1.0 (/home/asinotov/CLionProjects/actors)`
versions that meet the requirements `*` are: 0.4.2

the package `actors` depends on `riker`, with features: `riker-testkit` but `riker` does not have these features.

failed to select a version for `riker` which could resolve this conflict

I think this may be because of https://github.com/rust-lang/cargo/issues/9060
Removing the dev-dependency to riker-testkit should solve it:
In Cargo.toml:
 [features]
 default = []
-tokio_executor = ["tokio", "riker-testkit/tokio_executor"]
+tokio_executor = ["tokio"]
...
-[dev-dependencies.riker-testkit]
-git = "https://github.com/mankinskin/riker-testkit"
-branch = "tokio_executor"

I just left this in because it would be needed for tests when the above issue is solved.

I think this may be because of rust-lang/cargo#9060
Removing the dev-dependency to riker-testkit should solve it:
In Cargo.toml:
 [features]
 default = []
-tokio_executor = ["tokio", "riker-testkit/tokio_executor"]
+tokio_executor = ["tokio"]
...
-[dev-dependencies.riker-testkit]
-git = "https://github.com/mankinskin/riker-testkit"
-branch = "tokio_executor"

I just left this in because it is needed for the tests. If you want to test you will have to switch the "tokio_executor" feature manually for riker-testkit dev-dependency.. unfortunately that is the only way I got it working due to that cargo bug:
cargo test
 [dev-dependencies.riker-testkit]
 git = "https://github.com/mankinskin/riker-testkit"
 branch = "tokio_executor"

cargo test --features tokio_executor
 [dev-dependencies.riker-testkit]
 git = "https://github.com/mankinskin/riker-testkit"
 branch = "tokio_executor"
+features = ["tokio_executor"]

Thanks a lot!


Add networkpolicies for istio-ingress

How to categorize this PR?
/area networking
/kind enhancement
What this PR does / why we need it:
Provide strict network policies for the istio-ingressgateway so that it can only establish network connectivity to the endpoints that it is configured to reach inside the cluster.
This is a second line of defence in case of a bug or misconfiguration in the instio-ingressgateway.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Release note:
Deploy network policies to namespace istio-ingress to only allow egress traffic to configured endpoints inside the cluster.

/cc @ScheererJ @DockToFuture

/approve cancel
I want to take another look after the recent changes

@rfranzke Do we want to add network policies for istiod as well here or should this be done in a separate pull request?

@rfranzke Do we want to add network policies for istiod as well here or should this be done in a separate pull request?

I don't have preferences, feel free to do whatever is simpler for your workflow.


建议增加mac M1推理💡 [REQUEST] -

起始日期 | Start Date
No response
实现PR | Implementation PR
No response
相关Issues | Reference Issues
No response
摘要 | Summary
建议增加mac m1推理功能
基本示例 | Basic Example
建议增加mac m1推理功能
缺陷 | Drawbacks
缺失mac m1推理功能，不利于大范围测试
未解决问题 | Unresolved questions
No response

借楼, 如果想在4060ti 16gb上加载,如何设置呢

I think there is a method to run this model on M1 Mac, but need an another platform PC to quant the model.

see https://github.com/QwenLM/qwen.cpp

closed in favor of https://github.com/QwenLM/Qwen/issues/17


Display Data from the Northwind Service

Tutorial URL: https://developers.sap.com/tutorials/sapui5-fiori-cf-display-data.html
small stuff
Step 7 part 1: There is a trailing comma in the javascript code to copy that should not be there... and there are also some spaces between the comma after onInit and the begin _onRouteMatched that VS Code is complaining about.

Hi,
you are right that the comma is not really needed here. I added it because the user will add more methods to this object in the next tutorial and then it is easier (especially for JavaScript-beginners) when they can simply paste the next method under it. Otherwise, I would have to ask them to add the comma then, which can lead to confusion.
But again, you are absolutely right, this is not needed. Feel free to remove it.
PS: I'm not sure about the issue with the additional spaces. My VS Code doesn't complain here.

I'll close this one due to inactivity, please reopen if needed :)


Side scrolling and render bug

Hi,
I see you just released v5.0.6, I'm just switching to this from angular ui grid, sad to see it has bugs.
I think the plunker explains everything, when scrolling from left to right the data disappears. Same goes for initial rendering of the items, not everything is rendered until scrolled a bit.
https://embed.plnkr.co/w9ppmvKejR0QVr7CFAMb/
V5.0.0 seems to have the same issue.
tracking it down, with the current angular/jquery versions in the plunker, there is a difference between release of 5.0.0-alpha.3 and release of 5.0.0-alpha.1
On alpha 1, all columns are stacked on the left, on top of each other, but the data renders correctly.
On alpha 3 the issue started to appear, where the columns are correct but the rows are not rendered correctly when side scrolling.
Since it is working on your website I guess it has to do with a angular release.

Oh wauw, as you see in my plunker, I've set colId for every column, seems like it conflicts with something. removing or changing it's name resolved the issue.
I'll leave it open if you think it is necessary to write a fix or console error for this?

What exactly is "colld"? I'm having the same issue and would love to know your resolution. Thanks!

The library adds a colid to each header column, assigning my own colid gave errors because it probably doesn't know anymore where to put the data. So just don't define a colid in your colDefs objects.

colId should be strings, not numbers. update your plunker to use strings and it works perfect.


fix: await buildStart before server start

Description
#12624 reverted #12593 partially but it was missing this line.
Additional context

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the PR Title Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

/ecosystem-ci run vite-plugin-svelte

Ummm, I thought this would fix the plugin-svelte ecosystem-ci fail.

Interesting, we should still merge this PR though.


vscode.ExtensionContext.storagePath is undefined the 1st time an extension is activated for a workspace

VSCode Version: 1.8.1
OS Version: Windows

Steps to Reproduce:

Debug the C++ extension C_Cpp.ts activate method.
context : vscode.ExecutionContext has a value of undefined for the storagePath the 1st time the extension is activated for a new workspace. It repros in all cases, such as when no other files are open, and the extension is activated after the workspace is opened.

The bug starts reproing again after the folder C:\Users\<user>\AppData\Roaming\Code\User\workspaceStorage\<guid> is deleted.
Seems like a bug in VS Code?

@jrieken assigning to you due to the async work you did here.


[BUG] Iframe content renders but cannot login

I wanted to create card that with content as Iframe and I want to embed HubSpot data. The API works fine, and Login screen is rendering. The problem I am facing is I cannot login. It works on normal html editors but not inside HTML content visual inside power BI. Clicking Login button does not perform any action.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Hi - for security reasons Power BI custom visuals do not allow redirects or session state within iframes, so it is not possible to host a web application in here. This would be the same for all custom visuals, not just HTML Content.


config file issue

config file not processing and got invalid provider error

Config file

That's pretty weird, the invalid provider message happens when provider is not equal to linode or digitalocean.
Are you sure you saved that file correctly and there are no extra spaces?

no extra spaces
provider: linode
public-ssh-file: id_rsa.pub
private-ssh-file: id_rsa
linode:
  token:
  region: eu-central
  size: g6-nanode-1
  image: private/12345678 : put your image id here (./fleex images to get it)
  port: 2266
  username: op
  password: USER_PASSWORD
digitalocean:
  token: YOUR_DIGITALOCEAN_TOKEN
  region: fra1
  size: s-1vcpu-1gb
  image: 12345678 # put your image id here
  port: 2266
  username: op
  password: USER_PASSWORD
  tags:
    - vps
    - fleex

Another issue:
Error handling not properly handle on when config file processed.If the config file is not found then error message shown Invalid provider instead of file not found
If correct config file passed then also error messahe shown invalid provider

Thanks for your feedback once again.
I've just pushed a commit to change that behavior so now it warns the user if the config file path is not valid.
Can you try again and see if your original issue is still here?
Let us know

Nevermind, I've figured it out.
In your config file there's a : instead of #:
  image: private/12345678 : put your image id here (./fleex images to get it).
It should be:
  image: private/12345678 # put your image id here (./fleex images to get it)
That typo comes from the docs and I've just fixed it there as well, apologies for that.
It should be good now :)

Woking Thank you.

Error handling issue
If image value is not correct or valid format like this image: private/12345678 : put your image id here `` It gives errorinvalid providerinstead ofinvalid image```

Hi, for the moment we have decided to solve the problem with Something went wrong, check that the data in the config.yaml is correct.
For the future we have put dynamically managing errors on the todo list.


FromRequest class say "Illuminate\Validation\ValidationException  : The given data was invalid."

Larastan Version: 5.7.21
--level used: 5 (default, and I tried --level=1 also.)

Description:
I run $ php artisan code:analyse --debug -v and I see following lines.
   Illuminate\Validation\ValidationException  : The given data was invalid.

  at /var/www/app/vendor/laravel/framework/src/Illuminate/Foundation/Http/FormRequest.php:126
    122|      * @throws \Illuminate\Validation\ValidationException
    123|      */
    124|     protected function failedValidation(Validator $validator)
    125|     {
  > 126|         throw (new ValidationException($validator))
    127|                     ->errorBag($this->errorBag)
    128|                     ->redirectTo($this->getRedirectUrl());
    129|     }
    130|

  Exception trace:

  1   Illuminate\Foundation\Http\FormRequest::failedValidation(Object(Illuminate\Validation\Validator))
      /var/www/app/vendor/laravel/framework/src/Illuminate/Validation/ValidatesWhenResolvedTrait.php:26

  2   Illuminate\Foundation\Http\FormRequest::validateResolved()
      /var/www/app/vendor/laravel/framework/src/Illuminate/Foundation/Providers/FormRequestServiceProvider.php:30

Laravel code where the issue was found:
May be this errors fire in following code. But I can't have confidence in that.
use App\Http\Requests\Contracts\Admin\Authors\AuthorStoreRequest;

final class AuthorStoreUseCase implements AuthorStoreUseCaseInterface
{
    /**
     * @param AuthorStoreRequest $request
     * @return AuthorEntity
     */
    public function __invoke(AuthorStoreRequest $request): AuthorEntity
    {
        // snip
    }
}

The App\Http\Requests\Contracts\Admin\Authors\AuthorStoreRequest is just interface like following lines.
interface AuthorStoreRequest extends BaseRequest
{
    /**
     * @return array
     */
    public function rules(): array;
}

The BaseRequest as just a interface. That was bind to following abstract class.
use Illuminate\Foundation\Http\FormRequest;

/**
 * Class BaseRequest
 * @package App\Http\Requests
 */
abstract class BaseRequest extends FormRequest
{
    //
}

It just extends FormRequest class.
But I can't have confidence in that...
I will try to rewrite more simply my code, and to check the reproducibility in my local machine.
Do you have an idea how to fix these errors?
(And sorry my poor english.)

Larastan Version: 5.7.21

Could you state your larastan version?

@szepeviktor Oh, sorry my mistake.

Larastan Version: 0.3.15

is right.
And updated my first post.

Thanks.

Why am I getting this when I type php artisan code:analyse?
There are no commands defined in the "code" namespace.

Using artisan is deprecated - maybe removed.
Please consider starting phpstan directly and configure in phpstan.neon


Setting noImplicityAny to true triggers transitive import type declaration errors with moduleResolution NodeNext

Bug Report
Setting noImplicityAny to true triggers transitive import errors like this, when using "moduleResolution": "nodenext":
node_modules/@tiptap/core/dist/packages/core/src/helpers/isTextSelection.d.ts:1:31 - error TS7016: Could not find a declaration file for module 'prosemirror-state'. '/Users/basher/code/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' implicitly has an 'any' type.
  Try `npm i --save-dev @types/prosemirror-state` if it exists or add a new declaration (.d.ts) file containing `declare module 'prosemirror-state';`

1 import { TextSelection } from 'prosemirror-state';
                                ~~~~~~~~~~~~~~~~~~~

In this setup, we're importing @tiptap/core, which is importing prosemirror-* packages. @tiptap/core is a CommonJS package. prosemirror-* packages have exports maps and appear to support CommonJS and ESM correctly. I should also note that prosesmirror-* packages come with their own types (i.e. no @types/* packages needed)
Setting noImplicitAny to true triggers these errors. Setting it to false makes them disappear (successful compile).
🔎 Search Terms

nodenext
esm
import

🕗 Version & Regression Information
With the TS 4.7 release, we're trying to migrate to NodeNext as a step to getting to ESM. It wasn't possible to use NodeNext on prior versions.
⏯ Playground Link
I can't figure out how to add node_modules to TS Playground, but I'd be happy to provide a playground link, if someone can advise there.
https://github.com/benasher44/prosemirror-nodenext
💻 Code
tsconfig.json
{
  "compilerOptions": {
    "target": "ES6",
    "module": "ESNext",
    "esModuleInterop": true,
    "lib": [
      "DOM",
      "DOM.Iterable",
      "ES2021"
    ],
    "moduleResolution": "NodeNext",
    "outDir": "build",
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "sourceMap": true,
    "declaration": true,
    "noImplicitAny": true,
  },
  "include": ["src/**/*", "__tests__/**/*"]
}

Add latest @tiptap/core to package.json (2.0.0-beta.182 in this case)
TS file that imports and consumes a type from @tiptap/core
import { JSONContent } from "@tiptap/core";

export function test(e: JSONContent): void {
    console.log(e);
}

🙁 Actual behavior
Errors that show TS can't find type declaration.
🙂 Expected behavior
Successful compile.

Once an investigation is done, I have some follow up questions:

Are there other flags we could enable that would workaround this without giving up noImplicitAny?
Would pushing @tiptap to generate an ESM build help?
If this requires a patch to TS, would it be possible to get it into 4.8 (last remaining blocker for us to adopt ESM for node)?

Same error with jsonpath-plus library which is an esm module and has builtin types.
jsonpath-plus has types declaration at the root level. If you also set types field in exports section, it builds successfully. I think it should fallback to root types declaration.
Not working
"exports": {
    ".": {
      "import": "./dist/index-node-esm.js"
    }
  },
"types": "./src/jsonpath.d.ts",

Working
"exports": {
    ".": {
      "import": {
        "types": "./src/jsonpath.d.ts",
        "default": "./dist/index-node-esm.js"
      },
    }
  },
"types": "./src/jsonpath.d.ts",

With 4.9 beta coming along, I was wondering if TypeScript folks had a chance to look at this one yet? Thanks!

Here is the example of error:
node_modules/@tiptap/core/dist/packages/core/src/CommandManager.d.ts:1:42 - error TS7016: Could not find a declaration file for module 'prosemirror-state'. 'C:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' implicitly has an 'any' type.
  Try `npm i --save-dev @types/prosemirror-state` if it exists or add a new declaration (.d.ts) file containing `declare module 'prosemirror-state';`

1 import { EditorState, Transaction } from 'prosemirror-state';

Package.json for @tiptap/core:
{
  "name": "@tiptap/core",
  "main": "dist/tiptap-core.cjs.js",
  "umd": "dist/tiptap-core.umd.js",
  "module": "dist/tiptap-core.esm.js",
  "types": "dist/packages/core/src/index.d.ts",

Here are the resolution steps:
======== Resolving module 'prosemirror-state' from<EMAIL_ADDRESS>========
Explicitly specified module resolution kind: 'NodeNext'.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>exists according to earlier cached lookups.
Loading module 'prosemirror-state' from 'node_modules' folder, target file type 'TypeScript'.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/src/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/node_modules' does not exist, skipping all lookups in it.
Found 'package.json' at 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/package.json'.
'package.json' does not have a 'typesVersions' field.
File name 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' has a '.cjs' extension - stripping it.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cts' does not exist.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.d.cts' does not exist.
File<EMAIL_ADDRESS>does not exist.
Directory 'c:/temp/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/node_modules' does not exist, skipping all lookups in it.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>does not exist according to earlier cached lookups.
File<EMAIL_ADDRESS>exists according to earlier cached lookups.
Loading module 'prosemirror-state' from 'node_modules' folder, target file type 'JavaScript'.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/src/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/node_modules' does not exist, skipping all lookups in it.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/package.json' exists according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' exist - use it as a name resolution result.
Resolving real path for 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs', result 'C:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs'.
======== Module name 'prosemirror-state' was successfully resolved to 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' with Package ID<EMAIL_ADDRESS>========

The details about the file:
<EMAIL_ADDRESS>  Imported via './CommandManager' from file<EMAIL_ADDRESS>with packageId '<EMAIL_ADDRESS>  File is CommonJS module because<EMAIL_ADDRESS>does not have field "type"

Here is the package.json from prosemirror-state
{
  "name": "prosemirror-state",
  "type": "module",
  "main": "dist/index.cjs",
  "module": "dist/index.js",
  "types": "dist/index.d.ts",
  "exports": {
    "import": "./dist/index.js",
    "require": "./dist/index.cjs"
  },

Clearly the package.json has exports field and its missing types which is the cause of this issue. I think we could give better experience by reporting "types" condition is missing in exports. But thing to note is these errors can be coming from node_modules packages. What are mitigation steps for this from user perspective.
In this scenario - which I think is practical scenario is that many packages will have .js and .cjs files side by side and they meant to use single typings file. But becase index.cjs doesnt look up index.d.ts but we aren't able to find. Do we need some tweaking in the rule where we look for .d.ts as well. Do we take this step when reporting diagnostics?.Do we know packages out there which have different shape depending on esm vs cjs.
If we look at @tiptap/core package.json, clearly it is also meant to support .cjs and esm. How do you make d.ts work as esm and cjs both depending on the context because to me thats what it feels like is intended.
@andrewbranch @weswigham to weigh in since you have spent lot of time on module resolution modes.

How do you make d.ts work as esm and cjs both depending on the context because to me thats what it feels like is intended.

{
  "name": "prosemirror-state",
  "type": "module",
  "main": "dist/index.cjs",
  "module": "dist/index.js",
  "types": "dist/index.d.ts",
  "exports": {
+   "types": "./dist/index.d.ts",
    "import": "./dist/index.js",
    "require": "./dist/index.cjs"
  }

I think we could give better experience by reporting "types" condition is missing in exports.

Yeah, there’s probably something we could do here, especially if the subpath was ., the condition was require, and there’s a top-level types.

But thing to note is these errors can be coming from node_modules packages. What are mitigation steps for this from user perspective.

File a bug or PR against the library.
The user could add an entry to paths if the relative path to the desired typings file is known and deterministic.

Do we know packages out there which have different shape depending on esm vs cjs.

Packages that use export default sym in ESM and module.exports = sym in CJS really need two different declaration files to express this accurately. I’m not sure of a real package example off the top of my head; this has come primarily for ESM-only packages whose typings fail to reflect that it’s ESM; see #50690.

@andrewbranch do you know what it is about noImplictAny that triggers this? I'm having trouble convincing the library maintainer that this is on them to fix (adding types entry under exports in addition to top-level), and I think explaining the why there would be helpful. Otherwise, it's hard to argue this isn't a TS bug, since a project that doesn't set that flag works fine with nodenext

It would also be helpful to know if there's a way to reproduce this with prosemirror alone. Going through tiptap I think is also adding to the edge-case-y feel to this issue.

Not being able to resolve dependency typings is only an error in noImplicitAny. It doesn’t work fine without noImplicitAny; the typings aren’t found and the import is silently any.

Ah. Thanks! Super helpful. I was able to get a more minimal sample. I have updated the sample project. One thing I still don't quite understand. With the smaller example, the build fails with noImplicitAny set to true (as expected) if I remove "type": "module" from the package.json, but if I put "type": "module" (essentially switching from CJS to ESM), it passes. I don't understand why it would fail for CJS but pass for ESM.

if I remove "type": "module" from the package.json

Are you referring to the dependency package.json or your own?

Assuming you’re talking about your own—when you import the dependency as ESM, the type lookup works due to TypeScript’s extension substitution. The export map is consulted, the import condition is matched, which points to the path ./dist/index.js, which causes us to look for ./dist/index.ts (not found) followed by ./dist/index.d.ts (found).
Contrast this to what happens in the CJS case: the export map is consulted, the require condition is matched, which points to the path ./dist/index.cjs, which causes us to look for ./dist/index.cts (not found) followed by ./dist/index.d.cts (also not found).
In other words, .d.ts only applies to its sibling .js file by default; it takes a .d.cts extension to match with a .cjs file.

You can also use --traceResolution (to see the steps taken during module resolution) and --explainFiles (to know more information about files like was it treated as CJS or ESM based on package.json, why was file in the program etc)

Ah! Super interesting. Thanks again! I'll leave it to you all as to whether to close this.
It would be great if TS could provide a tool to run a diagnostic and print out a what is wrong with a library's package.json in a simple table (list what is missing or misconfigured, consequences of said misconfiguration, and resolution steps).. Then we can just point library maintainers at that. If someone can make such a tool that is standalone-ish (or just a flag on tsc), more tools could be built on top of it (github actions, a bot that can be pinged on repos to check their package.json and print the diagnostic to a comment, etc.). What you just described makes sense to me now logically @andrewbranch, but the level of detail required to understand how that all fits together appears to continue to be a lot for maintainers. With the number of possible combinations that library authors have to prepare for to be ESM-ready, a tool would be super helpful in expediting fixes. Case in point, getting to where we are right now in this issue took over 2 months.
Thanks again for all of you all's help!

If it's at all possible to include more fallback behaviors that would make this scenario work, I would be appreciative. It appears I was unsuccessful at convincing this maintainer that this isn't just a bug in TypeScript https://github.com/ProseMirror/prosemirror/issues/1305#issuecomment-1290284829
Otherwise, we'll just patch the library locally using yarn's patch facilities


bind parameter use while still allowing ipaddress to have a default.

This is a replacement for https://github.com/puppetlabs/puppetlabs-haproxy/pull/132 that fixes the ipaddress redefinition.

this is resolved #147 .
Thanks for the help.


Increasing coord check for the network output

I'm implementing muP for the OLMo model, and am facing an issue with the coordinate check.

The increasing l1 is for the network output. Following the docs, I also set readout init and query init to zero. I also ensure that the initialization is applied after set_base_shapes is called.
What other things can I check to debug the issue?

hi @AkshitaB , im reproducing MuP too these days.
can you share the arch ?? or have you solved the problem?

@AkshitaB From my experience, I also tried query/readout zero-init and it didn't help. However, what I saw is that while growing at early iterations, the readout norms do stabilise across widths after a sufficient number of iterations (like 30). You might actually already see such hints on your plot for t=4, so maybe running coordinate check for longer steps will flatten your readout norms.
But even if not, it's never been a problem for me in practice to have muTransfer, most importantly is that the other layer norms looks flat, which is the case for you :)


Improvements to Matlab lexer

Detect .m files starting with a function definition as MATLAB, not
ObjC.
Require word boundaries in regexes matching numbers and floats, to
avoid mishighlighting load 123file as starting with a number.
MATLAB treats a bare word followed by arguments such as foo bar baz as
the function call foo('bar', 'baz').  As such, treat everything that
follows the bare word as a string.

Just a revival of https://bitbucket.org/birkenfeld/pygments-main/pull-requests/676/matlab-detection-float-boundaries/diff.

thanks, all comments handled.

Thanks!


Mtreadwa/davids doc edits

Implementation of documentation edits suggested by David. See commit comments for details on exactly what was changed. Got feedback/approval for edits from tool authors where necessary.

LGTM.


Preserving newlines in data-clipboard-text

I'm struggling to get newlines across to the clipboard (and no, I'm not using notepad :). The clipboard is triggered on a  element, not a button, and all is working OK except newlines.
The  looks something like:
Some text

Note the \n in the data-clipboard-text attribute after the timestamp. Like this, it becomes a literal '\n' in the copied string. I then read that for data attributes, it's necessary to use
 for newlines. Replacing it like this:
Some text

then works OK in the browser console if I print the text there. But what gets copied to the clipboard (testing in SublimeText3) is this:
Last updated: Mon, 12 Oct 2015 20:16:53 UTCLast commit id: xyz

Note the newline character has simply vanished, and the text is run together. Is there any way to specify a newline in a data-clipboard-text attribute which will be preserved all the way?

Sorry - just realised I posted this to the wrong project :(


Add OpenTofu support list

Lists of projects supporting OpenTofu.
https://github.com/northwood-labs/opentofu-support

Stale repo?


withTheme Higher Order Component (fix #272)

Fix #272.
Add the possibility to get the current theme using withTheme(component) syntax. The theme will be passed as a theme prop to the child component.

@mxstbr Isn't the ThemeProvider to provide the context and the withTheme to access the context? How is this "extendible"?

Oops, I meant the StyledComponent and the StyledNativeComponent of course, brain fart on my part! Fixed my comment 😊

@mxstbr About the extending, the only similarity is that withTheme and StyledComponent both subscribe to context, but they do different things in the subscription: one just get the theme, the other needs to handle style parsing. And it's important that this style parsing happens together with the new theme arriving, I remember it was made this way to fix some bugs, so I'm not sure it's a good idea to separate them.
Updated the commits!

All good from my end! Nice work @brunolemos <3

@mxstbr time for a 1.1.4 release? :)

Oh btw I was getting some flow warnings locally, but they don't seem to be breaking the build:
yarn flow v0.15.1
$ flow; test $? -eq 0 -o $? -eq 2
src/hoc/withTheme.js:6
  6: export default Component => class extends React.Component {
                    ^^^^^^^^^ parameter `Component`. Missing annotation

src/hoc/withTheme.js:22
 22:     this.unsubscribe = subscribe(theme => {
              ^^^^^^^^^^^ property `unsubscribe`. Property not found in
 22:     this.unsubscribe = subscribe(theme => {
         ^^^^ class expr `<<anonymous class>>`

Found 2 errors
✨  Done in 0.26s.

@mxstbr thoughts on this?

Tried to use ReactClass<{}>, fixes the flow command but eslint plugin does not understand it.
Possibly related: gajus/eslint-plugin-flowtype#107

So this withTheme(component) will it make us possible to have a defaultTheme if not <ThemeProvider /> is provided, and in case  <ThemeProvider />, it will use the passed theme ?
Also, it will allow us to extend styled is that correct ?
Where do you pass the css ?
It sounds the same as Styled(Component) to me.
I am not sure if I understand the benefits compare to the previously used method, would you mind explain to me?

Oh btw I was getting some flow warnings locally, but they don't seem to be breaking the build:

What, that's weird! We might need to tweak the CI settings and can we get that fixed @styled-components/typers?

Where do you pass the css ?

You don't pass any CSS, that's the point 😉 withTheme allows you to get the global theme in any component, even ones that aren't styled components!

What, that's weird! We might need to tweak the CI settings and can we get that fixed @styled-components/typers?

Oh, looks like CI is not running flow at all. Will create a PR fixing that and the errors that have made it to master✌

this seems awesome, plans to pull it?

Hi, is this supposed to work with functionnal components ?


Use a token to connect to a container

I'm trying to connect to a blobstorage using a token that I get like this:
cred, err := azidentity.NewClientSecretCredential(tenantID, clientID, clientSecret, nil)
I can use this function and see that return me a token:
policy := policy.TokenRequestOptions{ 		Scopes: []string{clientID + "/.default"}, } resp, err := ced.GetToken(context.Background(), policy)
In the program I call to this function
conn, err := azblob.NewContainerClient(containerURL, cred, nil)
When I try to write using this connection to the container I have the follow error:
===== RESPONSE ERROR (ErrorCode=AuthorizationPermissionMismatch) ===== Description=This request is not authorized to perform this operation using this permission. RequestId:19f268a9-301e-0027-28c1-06fd6a000000 Time:2022-01-11T08:03:07.6493384Z, Details: (none)
The devops tell me that the problem is I have to get the token using scopes, but what I see in NewContainerClient is that use this constant:
const tokenScope untyped string = "https://storage.azure.com/.default"
There is any way to pass scopes to NewContainerClient or I should use other way?

Scopes are handled internally by clients, and https://storage.azure.com/.default is the only one for Azure Storage. I'm not so familiar with Storage (I'll assign someone who is) but that error suggests the problem is with authorization, that is to say the service principal isn't authorized to perform the operation.

@Kowiste could you please make sure that you've assigned the right permissions to the service principal on the account? e.g. Storage Blob Data Contributor

Thanks @zezha-msft, I just check with the dev ops, we change the role for the app to contributor but it still give the same error. I can have a token with  azidentity.NewClientSecretCredential . I use it  in azblob.NewContainerClient and with the client when try to write I have the same error.

@Kowiste I don't think the Contributor is the correct one. Please try "Storage Blob Data Contributor" instead.
Useful reading: https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad-app?tabs=dotnet#assign-a-role-to-an-azure-ad-security-principal


NETCONF RPC Error - BGP License Requirement

I ecnountered the following error when I try to create a configuration that is related to BGP in vJunos-lab router, this should be reported as a warning and not come up as an error though the configuration was applied correctly in the router.
Status:
  Conditions:
    Last Transition Time:  2024-08-02T15:59:42Z
    Message:               rpc error: code = Unknown desc = operation error from input '<?xml version="1.0" encoding="UTF-8"?><rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="438"><commit/></rpc>'. matched error sub-string '<rpc-error>
<error-severity>warning</error-severity>
<source-daemon>
mgd
</source-daemon>
<error-path>
[edit routing-instances VRF-Example protocols]
</error-path>
<error-info>
<bad-element>
bgp
</bad-element>
</error-info>
<error-message>
requires 'bgp' license
</error-message>
</rpc-error>'. full output: ''
    Reason:  Failed
    Status:  False
    Type:    Ready

Though after some minutes the error goes away.
Sample config used:
apiVersion: config.sdcio.dev/v1alpha1
kind: Config
metadata:
  name: intent1-junos
  namespace: default
  labels:
    config.sdcio.dev/targetName: junos-central
    config.sdcio.dev/targetNamespace: default
spec:
  priority: 10
  config:
  - path: /
    value:
      configuration:
        vlans:
          vlan:
          - name: VLAN100
            vlan-id: 100
            l3-interface: irb.100
          - name: VLAN200
            vlan-id: 200
            l3-interface: irb.200
          - name: VLAN300
            vlan-id: 300
            l3-interface: irb.300
        interfaces:
          interface:
          - name: irb
            unit:
            - name: "100"
              family:
                inet:
                  address:
                  - name: "<IP_ADDRESS>/24"
            - name: "200"
              family:
                inet:
                  address:
                  - name: "<IP_ADDRESS>/24"
            - name: "300"
              family:
                inet:
                  address:
                  - name: "<IP_ADDRESS>/24"
          - name: ge-0/0/1
            unit:
            - name: "0"
              family:
                ethernet-switching:
                 interface-mode: trunk
                 vlan:
                 - members:
                   - VLAN100
                   - VLAN200
                   - VLAN300
        routing-instances:
          instance:
          - name: VRF-Example
            instance-type: vrf
            interface:
            - name: irb.100
            - name: irb.200
            - name: irb.300
            route-distinguisher:
              rd-type: "100:1"
            vrf-target:
              community: "target:100:1"
            protocols:
              bgp:
                group:
                - name: internal
                  type: internal
                  local-as:
                    as-number: 65001
                  neighbor:
                  - name: <IP_ADDRESS>
                    peer-as: 65001

Thanks

We need to distinguish the information we get back from netconf into specific errors or warning. Right now treat them all the same, but distinguishing between warning and error is going to be important here.


People autocomplete mismatch/not showing in CO Filter

Describe the bug
I see a person in search autocomplete in "People" data page search but not in CO Filter.
To Reproduce
Steps to reproduce the behavior:

When I search a person in CO Filter
Then I do not see them
And I search that person in People
And then I see them.

Screenshot of "Gloyd" search in People auto-complete in People Data Page:

Screenshot of "Gloyd" search in Determiner auto-complete in CO Filter:

Expected behavior
All potential people should return? Is current behavior only showing those with "Determiner" roles?
Environment (please identify where you experience this bug:
*** One of ***

Production
Chrome

As you can see Gloyd has never been a determiner, so they are not displayed in the filter, this is by design.