Timer may block other futures from being processed

Hi,
I'm not sure if it is a bug or some expected behavior, but I've noticed that spawning tokio timer may prevent other futures from being processed. I've noticed that issue when I worked on my work project, it uses tokio timer. My application has an architecture which is quite similar to the chat.rs example from tokio-core. So basically I have a client which connects to the server. After the connection to the server is done, I split the stream to Sink and Stream futures and then I have a for_each futures for messages coming in where I process them, and tx.forward(sink). So basically the client processes incoming messages and uses tx.send() whenever some messages has to be sent, then tx is forwarded to the Sink part. Like in chat.rs both futures are combined with select(). Then I've realized that my application has to have a timer which checks the state of the system each 100ms and performs some actions which may involve sending a message to the Sink via tx. So I decided to use a tokio-timer for that. I created a timer and tried to use select() to combine the timer future to those 2 other futures, unfortunately I could not succeed in that, the compiler gave me huge compile time errors which I don't know how to solve. So what I decided to do is to use Handle::spawn() method to spawn a timer future. When I did that, I've noticed that after the timer is started, other futures (futures which handle sending and receiving messages) are never being processed, i.e. after the timer future is spawned, no messages are sent or received on the client side. I was able to workaround this issue by increasing the timer timeout time to 200ms (maybe it did not work because the tick time was equal to the timeout time?), but it turned out soon that it is not a good solution as sometimes the situation repeats, I have a feeling that it happens when the code which is executed after the timer timeout takes longer than 200ms.
I used slightly modified chat example from tokio-core to reproduce the problems I've had. This is what happens in case if I set the interval to 100ms, in this case the client never receives or sends any messages, seems like the timer prevents other futures from being processed by the tokio:
//! A simple example of hooking up stdin/stdout to a TCP stream.
//!
//! This example will connect to a server specified in the argument list and
//! then forward all data read on stdin to the server, printing out all data
//! received on stdout.
//!
//! Note that this is not currently optimized for performance, especially around
//! buffer management. Rather it's intended to show an example of working with a
//! client.

extern crate futures;
extern crate tokio_core;
extern crate tokio_timer;

use std::env;
use std::io::{self, Read, Write};
use std::net::SocketAddr;
use std::thread;
use std::time::Duration;

use futures::{Sink, Future, Stream};
use futures::sync::mpsc;
use tokio_core::reactor::Core;
use tokio_core::io::{Io, EasyBuf, Codec};
use tokio_core::net::TcpStream;
use tokio_timer::Timer;

fn main() {
    // Parse what address we're going to connect to
    let addr = env::args().nth(1).unwrap_or_else(|| {
        panic!("this program requires at least one argument")
    });
    let addr = addr.parse::<SocketAddr>().unwrap();

    // Create the event loop and initiate the connection to the remote server
    let mut core = Core::new().unwrap();
    let handle = core.handle();
    let tcp = TcpStream::connect(&addr, &handle);

    // Right now Tokio doesn't support a handle to stdin running on the event
    // loop, so we farm out that work to a separate thread. This thread will
    // read data from stdin and then send it to the event loop over a standard
    // futures channel.
    let (stdin_tx, stdin_rx) = mpsc::channel(0);
    thread::spawn(|| read_stdin(stdin_tx));
    let stdin_rx = stdin_rx.map_err(|_| panic!()); // errors not possible on rx

    // After the TCP connection has been established, we set up our client to
    // start forwarding data.
    //
    // First we use the `Io::framed` method with a simple implementation of a
    // `Codec` (listed below) that just ships bytes around. We then split that
    // in two to work with the stream and sink separately.
    //
    // Half of the work we're going to do is to take all data we receive on
    // stdin (`stdin_rx`) and send that along the TCP stream (`sink`). The
    // second half is to take all the data we receive (`stream`) and then write
    // that to stdout. Currently we just write to stdout in a synchronous
    // fashion.
    //
    // Finally we set the client to terminate once either half of this work
    // finishes. If we don't have any more data to read or we won't receive any
    // more work from the remote then we can exit.
    let mut stdout = io::stdout();
    let client = tcp.and_then(|stream| {
        let (sink, stream) = stream.framed(Bytes).split();
        let send_stdin = stdin_rx.forward(sink);
        let write_stdout = stream.for_each(move |buf| {
            stdout.write_all(buf.as_slice())
        });

        let timer = Timer::default(); // currently the tick duration is 100ms
        let timer = timer.interval(Duration::from_millis(100)).for_each(move |_| {
            println!("timeout");
            Ok(())
        });
        handle.spawn(timer.map_err(|_| ()));

        send_stdin.map(|_| ())
                  .select(write_stdout.map(|_| ()))
                  .then(|_| Ok(()))
    });

    // And now that we've got our client, we execute it in the event loop!
    core.run(client).unwrap();
}

/// A simple `Codec` implementation that just ships bytes around.
///
/// This type is used for "framing" a TCP stream of bytes but it's really just a
/// convenient method for us to work with streams/sinks for now. This'll just
/// take any data read and interpret it as a "frame" and conversely just shove
/// data into the output location without looking at it.
struct Bytes;

impl Codec for Bytes {
    type In = EasyBuf;
    type Out = Vec<u8>;

    fn decode(&mut self, buf: &mut EasyBuf) -> io::Result<Option<EasyBuf>> {
        if buf.len() > 0 {
            let len = buf.len();
            Ok(Some(buf.drain_to(len)))
        } else {
            Ok(None)
        }
    }

    fn encode(&mut self, data: Vec<u8>, buf: &mut Vec<u8>) -> io::Result<()> {
        buf.extend(data);
        Ok(())
    }
}

// Our helper method which will read data from stdin and send it along the
// sender provided.
fn read_stdin(mut rx: mpsc::Sender<Vec<u8>>) {
    let mut stdin = io::stdin();
    loop {
        let mut buf = vec![0; 1024];
        let n = match stdin.read(&mut buf) {
            Err(_) |
            Ok(0) => break,
            Ok(n) => n,
        };
        buf.truncate(n);
        rx = rx.send(buf).wait().unwrap();
    }
}

If I change the interval time to 200ms, it seems that the problem is solved (like I did when I worked in my project), but as said before, sometimes it still may keep other futures from being processed, I guess that it may happen if the code which is executed after the timer timeout is fired takes longer than the interval between timer. And indeed, if I change
        let timer = timer.interval(Duration::from_millis(100)).for_each(move |_| {
            println!("timeout");
            Ok(())
        });

to
            use std::{thread, time};
            println!("timeout");
            thread::sleep(time::Duration::from_millis(205));
            println!("timeout2");
            Ok(())

then the problem occurs again.
Can you please suggest me what to do in such cases and if it is a bug? I want to start a timer with the interval of N milliseconds and I want to ensure that other futures are also executed.

Note that spawning doesn't spawn a thread, just a future. If you call thread::sleep it'll block the reactor, which may be causing problems here?
In general futures are unable to block the current thread as it'll bring the whole system to a grinding halt.

Note that spawning doesn't spawn a thread, just a future.

Yeah, I know. But I did not expect that a spawned task can somehow prevent other task from being processed.

you call thread::sleep it'll block the reactor, which may be causing problems here?

I thought about that, but the real code which I have inside my real project, does not have any sleeps. I have a timer there, the interval is set to 200ms and when the timer fires, I do some proessing. I've noticed that in some cases  (I believe it happens when the timer "handler" processing timer exceeds 200ms (interval time)) other futures are not executed, i.e. reading and writing futures (which work in within a different task) did not do any process.

In general futures are unable to block the current thread as it'll bring the whole system to a grinding halt.

The timer future, which was spawned in a separate task (I used Handler::spawn) did not block the thread, I was receiving timeout "events" every time they happened, but in some cases, only the timer task was "active", another tasks (reading and writnig futures) did not make any progress at all (they resumed their activity immediately after I changed the conditions [I reduced the time for processing stuff in for_each timer future]).

But I did not expect that a spawned task can somehow prevent other task from being processed.

Yeah this should be correct, modulo starvation (e.g. if one task just spins in a loop preventing others from running)
Do you have the example code you were working with? It may be more helpful to just take a peek at that. If it's a bug in the library then that's invaluable for reproduction and confirming a fix, and if it's a local bug then it'd also be invaluable to help diagnose!

You can use the code from the modified version of chat which I've shown above, my code has very similar architecture.
Have a look at:
    let mut stdout = io::stdout();
    let client = tcp.and_then(|stream| {
        let (sink, stream) = stream.framed(Bytes).split();
        let send_stdin = stdin_rx.forward(sink);
        let write_stdout = stream.for_each(move |buf| {
            stdout.write_all(buf.as_slice())
        });

        let timer = Timer::default(); // currently the tick duration is 100ms
        let timer = timer.interval(Duration::from_millis(100)).for_each(move |_| {
            println!("timeout");
            Ok(())
        });
        handle.spawn(timer.map_err(|_| ()));

        send_stdin.map(|_| ())
                  .select(write_stdout.map(|_| ()))
                  .then(|_| Ok(()))
    });

Let's call the code that resides inside the for_each as a timer event handler. I've just made a test. I decided to measure the time for the timer event handler in my project, so basically that's what I did:
        let timer = timer.interval(Duration::from_millis(200)).for_each(move |_| {
            let start = PreciseTime::now();
            // here is some code which executes some business logic of the application
            my_object.do_some_processing();
            debug!("Time spent: {}", start.to(PreciseTime::now()).num_milliseconds());
            Ok(())
        });

I've noticed that the "freeze" (when all other futures except timer future are not processed) occurs when the Time spent becomes greater than 200ms (which is an interval duration in my case). Normally the Time spent is between 20-150 milliseconds, but in some cases in my application it may grow up to 350ms, when it happens Timer spent becomes ~320ms and all other futures (except the timer future) never receive a processing time. The system returns to its normal state when the processing time decreases to the normal value.
Seems like the timer's task in such cases somehow remains active all the time and consumes all the time. It does not allow tokio to switch to another task (which does the networking patr in my case).
Is there a way to say something like: "Please, check the event queue (or something similar) and try to process other tasks before getting back to the current task?". At the moment it seems that the timer task is just always active (when the timer handler time exceeds the interval time) and so it does not let the tokio to work on other tasks.

I think I'm still confused. In the first code snippet of your last comment the timer doesn't actually do anything? It just prints out information but otherwise isn't hooked up into message processing.
In the second example, the do_some_processing function takes hundreds of milliseconds? Is that doing CPU bound work or is it blocking? If it's blocking that's the problem (it shouldn't block) but if it's doing CPU bound work that's different.

Ah, ok, I'll try to explain.
In my application I have some processing code inside and I always had this issue, in order to test the behavior of the timer and create an issue I decided to write some SSCCE.
In the first example I wrote the timer which indeed does not do anything. And even with such code it is enough to reproduce the bug. You can see that the interval time in the first code snippet is 100ms; 100ms is also a default value for the tick duration, based on this information I assumed that the bug occurrs due to the the interval time which is equal to the default tick duration.
To workaround the issue, I decided to increase the interval time to 200ms (so the tick duration remains 100ms as before), when I tried that, it solved the issue, (at least I thought that the issue was solved) so I changed the interval to 200ms in my application as well. But then it turned out that the problem is reproducible even when the interval is bigger than the tick duration.
So if you use the first code snippet, where the timer did nothing and the interval is equal to 100ms, it will produce a behavior which I described.
If you take my 2nd snippet, where the timer does something and the interval is 200ms, it will work as long as the event handler execution takes less than the interval time (200ms).

In the second example, the do_some_processing function takes hundreds of milliseconds? Is that doing CPU bound work or is it blocking? If it's blocking that's the problem (it shouldn't block) but if it's doing CPU bound work that's different.

Sometimes the function (not always, the behavior depends on some internal state of the application and business logic) does some trivial stuff which takes less than 30ms, in other cases it does more CPU extensive tasks such as JPEG/PNG encoding which may take 150-320 milliseconds.

Sounds quite suspicious! @carllerche mind taking a look (you're more familiar with the impl than I)

It's looking like this behavior isn't a bug per se, but it's a sharp edge with coarse timers.
The implementation of Interval can definitely be fixed to handle this specific case, but there are subtle things at play besides that.
The quick fix is, assuming that you are only setting timeouts in the 100ms range, you should reduce the interval size to ~10ms or so. I would say that the interval size should be no bigger than 1/10th the smallest timeout set.

The quick fix is, assuming that you are only setting timeouts in the 100ms range, you should reduce the interval size to ~10ms or so.

Did you mean the tick duration? If so, then I tried to set the tick duration to 10ms (the timer interval was set to 200ms), but unfortunately it did not help.

It would be helpful to have a minimal test case that illustrated the failure then. I did the following and it seemed to work fine:
extern crate futures;
extern crate tokio_core;
extern crate tokio_timer;

use std::env;
use std::io::{self, Read, Write};
use std::net::SocketAddr;
use std::thread;
use std::time::Duration;

use futures::{Sink, Future, Stream};
use futures::sync::mpsc;
use tokio_core::reactor::Core;
use tokio_core::io::{Io, EasyBuf, Codec};
use tokio_core::net::TcpStream;
use tokio_timer::Timer;

fn main() {
    // Parse what address we're going to connect to
    let addr = env::args().nth(1).unwrap_or_else(|| {
        panic!("this program requires at least one argument")
    });
    let addr = addr.parse::<SocketAddr>().unwrap();

    // Create the event loop and initiate the connection to the remote server
    let mut core = Core::new().unwrap();
    let handle = core.handle();
    let tcp = TcpStream::connect(&addr, &handle);

    // Right now Tokio doesn't support a handle to stdin running on the event
    // loop, so we farm out that work to a separate thread. This thread will
    // read data from stdin and then send it to the event loop over a standard
    // futures channel.
    let (stdin_tx, stdin_rx) = mpsc::channel(0);
    thread::spawn(|| read_stdin(stdin_tx));
    let stdin_rx = stdin_rx.map_err(|_| panic!()); // errors not possible on rx

    // After the TCP connection has been established, we set up our client to
    // start forwarding data.
    //
    // First we use the `Io::framed` method with a simple implementation of a
    // `Codec` (listed below) that just ships bytes around. We then split that
    // in two to work with the stream and sink separately.
    //
    // Half of the work we're going to do is to take all data we receive on
    // stdin (`stdin_rx`) and send that along the TCP stream (`sink`). The
    // second half is to take all the data we receive (`stream`) and then write
    // that to stdout. Currently we just write to stdout in a synchronous
    // fashion.
    //
    // Finally we set the client to terminate once either half of this work
    // finishes. If we don't have any more data to read or we won't receive any
    // more work from the remote then we can exit.
    let mut stdout = io::stdout();
    let client = tcp.and_then(|stream| {
        let (sink, stream) = stream.framed(Bytes).split();
        let send_stdin = stdin_rx.forward(sink);
        let write_stdout = stream.for_each(move |buf| {
            stdout.write_all(buf.as_slice())
        });

        let timer = tokio_timer::wheel()
            .tick_duration(Duration::from_millis(10))
            .build();

        let timer = timer.interval(Duration::from_millis(100)).for_each(move |_| {
            println!("timeout");
            Ok(())
        });
        handle.spawn(timer.map_err(|_| ()));

        send_stdin.map(|_| ())
                  .select(write_stdout.map(|_| ()))
                  .then(|_| Ok(()))
    });

    // And now that we've got our client, we execute it in the event loop!
    core.run(client).unwrap();
}

/// A simple `Codec` implementation that just ships bytes around.
///
/// This type is used for "framing" a TCP stream of bytes but it's really just a
/// convenient method for us to work with streams/sinks for now. This'll just
/// take any data read and interpret it as a "frame" and conversely just shove
/// data into the output location without looking at it.
struct Bytes;

impl Codec for Bytes {
    type In = EasyBuf;
    type Out = Vec<u8>;

    fn decode(&mut self, buf: &mut EasyBuf) -> io::Result<Option<EasyBuf>> {
        if buf.len() > 0 {
            let len = buf.len();
            Ok(Some(buf.drain_to(len)))
        } else {
            Ok(None)
        }
    }

    fn encode(&mut self, data: Vec<u8>, buf: &mut Vec<u8>) -> io::Result<()> {
        buf.extend(data);
        Ok(())
    }
}

// Our helper method which will read data from stdin and send it along the
// sender provided.
fn read_stdin(mut rx: mpsc::Sender<Vec<u8>>) {
    let mut stdin = io::stdin();
    loop {
        let mut buf = vec![0; 1024];
        let n = match stdin.read(&mut buf) {
            Err(_) |
            Ok(0) => break,
            Ok(n) => n,
        };
        buf.truncate(n);
        rx = rx.send(buf).wait().unwrap();
    }
}

I did the following and it seemed to work fine:

It does work as long as the timer handler requires less than 100ms to complete. Currently the only thing you do when the timeout is triggered, you print a single line to the console. But what will happen in case if the code inside the timer event handler is more complex, i.e. what would be if in some cases this code takes more than 100ms? That's exactly the case which happens in my actual project - my actual code looks similar to your example, but instead of println!() it has some business logic, which may take more than 100ms to finish (sometimes it takes 110ms), what would happen in such case?
Let's image the following situation: we started a timer with the interval of 100ms and the tick duration of 20ms, the timer runs well and everything works as expected. The code which is executed whenever the timeout is triggerred is a bit more complex: in most cases it only prints something to the console, but sometimes it does some more complex computations which may take up to 120ms. Let's say that we got to the point when the timer event handler starts doing some complex computations (takes ~120ms to finish).
The expected behavior:

Timestamp
The actions taken by the tokio

Nms
The timeout event is triggered => we started executing our complex code (which will take 120ms to finish)

N+20ms
Our code is still doing some processing, i.e. tokio does nothing at this point

N+40ms
Our code is still doing some processing, i.e. tokio does nothing at this point

N+60ms
Our code is still doing some processing, i.e. tokio does nothing at this point

N+80ms
Our code is still doing some processing, i.e. tokio does nothing at this point

N+100ms
Our code is still doing some processing, i.e. tokio does nothing at this point

N+120ms
Our code is still doing some processing, i.e. tokio does nothing at this point

(N+121ms)
Our code has finished the execution, so the control is passed back to the tokio

N+140ms
Tokio knows that the next timer timeout should occur at N+200ms, since there is nothing the tokio-timer can do right now, we let other tasks (futures) to work

N+160ms
Tokio knows that the next timer timeout should occur at N+200ms, since there is nothing the tokio-timer can do right now, we let other tasks (futures) to work

N+180ms
Tokio knows that the next timer timeout should occur at N+200ms, since there is nothing the tokio-timer can do right now, we let other tasks (futures) to work

N+200ms
The timeout event is triggered => we started executing our complex code (which will take 120ms to finish)

N+220 ms
Our code is still doing some processing, i.e. tokio does nothing at this point

N+240 ms
Our code is still doing some processing, i.e. tokio does nothing at this point

...
...

It seems that unfortunately it does not work like this. Currently during the steps (N+140ms), (N+160ms), (N+180ms) other tasks do not make any progress, I don't know what tokio (or tokio-timer) does within these periods of time, for some reason it does not switch to other tasks/futures which leads to the problem I'm trying to describe.

Sorry, I don't understand what you mean by "tasks don't make progress".

They do not receive any processing time (or pending something). It behaves like if tokio's "execution context" (if I can use this term here) is always on the timer's task and never switches to other tasks (when the conditions described in my previous comments are met).
I'll give you a couple examples, maybe it will make things clearer:

If we're talking about them in terms of your example: there is 2 tasks -- the 1st one contains the futures which send and receive data and the 2nd one is spawned for the timer future. So, when the conditions for triggering the bug are met, the 1st future "will not work", i.e. you will not see any messages coming from the server, i.e. you will not get inside:

        let write_stdout = stream.for_each(move |buf| {
            stdout.write_all(buf.as_slice())
        });

block. Also you won't be able to send anything to the server.
2. (happened in my project) I had the similar architecture, so the situation was the same: when the bug occurred, only the timer future was active -- I received several messages from the server, but I've never got inside the for_each(|message| { ... }) of my Stream future (which represents the stream of incoming messages). So the timer future was always "active" and other futures looked completely frozen (I even tried to add some println!() inside the poll function and it was not called). After the conditions had changed (as a consequence, the timer handler execution time became less than the interval time), only then I've noticed that other futures started to do something useful (and immediately received a bunch of messages which I received from the server within the last 20 seconds).

Are you saying that if a task is CPU bound then no other tasks on the executor run? If so, this is intended behavior. CPU bound tasks should run on a thread pool in order to not block execution.

One of the functions which is called inside the timer's timeout handler is CPU bound, but the problem not in CPU bound function as such. The problem is what happens next. Take a look at the table in my coments above. N+140ms -- at this moment tokio had to switch to another task to perform some actions, but instead of that nothing happened, and so no futures were being processed at that point

Ok, I wrote another one simple example. Both files are based on chat.rs and connect.rs from tokio-core examples. I changed some things. The server now pushes some messages to the connected clients. If you start the server (modified chat.rs) and then connect to it using the connect.rs example from tokio-core, it would work fine, you will see a messages from the server on the client side. However if you try to run the modified connect.rs (the one which contains the timer), you will see that the client does not receive any of the messages from the server, neither it sends one.
Server:
//! A chat server that broadcasts a message to all connections.
//!
//! This is a simple line-based server which accepts connections, reads lines
//! from those connections, and broadcasts the lines to all other connected
//! clients. In a sense this is a bit of a "poor man's chat server".
//!
//! You can test this out by running:
//!
//!     cargo run --example chat
//!
//! And then in another window run:
//!
//!     nc -4 localhost 8080
//!
//! You can run the second command in multiple windows and then chat between the
//! two, seeing the messages from the other client as they're received. For all
//! connected clients they'll all join the same room and see everyone else's
//! messages.

extern crate tokio_core;
extern crate futures;
extern crate tokio_timer;

use std::collections::HashMap;
use std::rc::Rc;
use std::cell::RefCell;
use std::iter;
use std::env;
use std::io::{Error, ErrorKind, BufReader};

use tokio_core::net::TcpListener;
use tokio_core::reactor::Core;
use tokio_core::io::{self, Io};

use futures::stream::{self, Stream};
use futures::Future;

fn main() {
    let addr = env::args().nth(1).unwrap_or("<IP_ADDRESS>:8080".to_string());
    let addr = addr.parse().unwrap();

    // Create the event loop and TCP listener we'll accept connections on.
    let mut core = Core::new().unwrap();
    let handle = core.handle();
    let socket = TcpListener::bind(&addr, &handle).unwrap();
    println!("Listening on: {}", addr);

    // This is a single-threaded server, so we can just use Rc and RefCell to
    // store the map of all connections we know about.
    let connections = Rc::new(RefCell::new(HashMap::new()));

    let srv = socket.incoming().for_each(move |(stream, addr)| {
        println!("New Connection: {}", addr);
        let (reader, writer) = stream.split();

        // Create a channel for our stream, which other sockets will use to
        // send us messages. Then register our address with the stream to send
        // data to us.
        let (tx, rx) = futures::sync::mpsc::unbounded();
        connections.borrow_mut().insert(addr, tx);

        // Define here what we do for the actual I/O. That is, read a bunch of
        // lines from the socket and dispatch them while we also write any lines
        // from other sockets.
        let connections_inner = connections.clone();
        let reader = BufReader::new(reader);

        // Model the read portion of this socket by mapping an infinite
        // iterator to each line off the socket. This "loop" is then
        // terminated with an error once we hit EOF on the socket.
        let iter = stream::iter(iter::repeat(()).map(Ok::<(), Error>));
        let socket_reader = iter.fold(reader, move |reader, _| {
            // Read a line off the socket, failing if we're at EOF
            let line = io::read_until(reader, b'\n', Vec::new());
            let line = line.and_then(|(reader, vec)| {
                if vec.len() == 0 {
                    Err(Error::new(ErrorKind::BrokenPipe, "broken pipe"))
                } else {
                    Ok((reader, vec))
                }
            });

            // Convert the bytes we read into a string, and then send that
            // string to all other connected clients.
            let line = line.map(|(reader, vec)| {
                (reader, String::from_utf8(vec))
            });
            let connections = connections_inner.clone();
            line.map(move |(reader, message)| {
                println!("{}: {:?}", addr, message);
                let mut conns = connections.borrow_mut();
                if let Ok(msg) = message {
                    // For each open connection except the sender, send the
                    // string via the channel.
                    let iter = conns.iter_mut()
                                    .filter(|&(&k, _)| k != addr)
                                    .map(|(_, v)| v);
                    for tx in iter {
                        tx.send(format!("{}: {}", addr, msg)).unwrap();
                    }
                } else {
                    let tx = conns.get_mut(&addr).unwrap();
                    tx.send("You didn't send valid UTF-8.".to_string()).unwrap();
                }
                reader
            })
        });

        // Whenever we receive a string on the Receiver, we write it to
        // `WriteHalf<TcpStream>`.
        let socket_writer = rx.fold(writer, |writer, msg| {
            let amt = io::write_all(writer, msg.into_bytes());
            let amt = amt.map(|(writer, _)| writer);
            amt.map_err(|_| ())
        });

        // Now that we've got futures representing each half of the socket, we
        // use the `select` combinator to wait for either half to be done to
        // tear down the other. Then we spawn off the result.
        let connections_in = connections.clone();
        let socket_reader = socket_reader.map_err(|_| ());
        let connection = socket_reader.map(|_| ()).select(socket_writer.map(|_| ()));
        handle.spawn(connection.then(move |_| {
            connections_in.borrow_mut().remove(&addr);
            println!("Connection {} closed.", addr);
            Ok(())
        }));

        let connections = connections.clone();
        let timer = tokio_timer::wheel().tick_duration(std::time::Duration::from_millis(10))
                                        .build()
                                        .interval(std::time::Duration::from_millis(200))
                                        .for_each(move |_| {
                                            println!("test");
                                            let mut conns = connections.borrow_mut();
                                            for item in conns.iter_mut() {
                                                item.1.send("Message from server\n".to_owned()).unwrap();
                                            }
                                            Ok(())
                                        });
        handle.spawn(timer.map_err(|_| ()));

        Ok(())
    });

    // execute server
    core.run(srv).unwrap();
}

Client:
//! A simple example of hooking up stdin/stdout to a TCP stream.
//!
//! This example will connect to a server specified in the argument list and
//! then forward all data read on stdin to the server, printing out all data
//! received on stdout.
//!
//! Note that this is not currently optimized for performance, especially around
//! buffer management. Rather it's intended to show an example of working with a
//! client.

extern crate futures;
extern crate tokio_core;
extern crate tokio_timer;

use std::env;
use std::io::{self, Read, Write};
use std::net::SocketAddr;
use std::thread;
use std::time::Duration;

use futures::{Sink, Future, Stream};
use futures::sync::mpsc;
use tokio_core::reactor::Core;
use tokio_core::io::{Io, EasyBuf, Codec};
use tokio_core::net::TcpStream;
use tokio_timer::Timer;

fn main() {
    // Parse what address we're going to connect to
    let addr = env::args().nth(1).unwrap_or_else(|| {
        panic!("this program requires at least one argument")
    });
    let addr = addr.parse::<SocketAddr>().unwrap();

    // Create the event loop and initiate the connection to the remote server
    let mut core = Core::new().unwrap();
    let handle = core.handle();
    let tcp = TcpStream::connect(&addr, &handle);

    // Right now Tokio doesn't support a handle to stdin running on the event
    // loop, so we farm out that work to a separate thread. This thread will
    // read data from stdin and then send it to the event loop over a standard
    // futures channel.
    let (stdin_tx, stdin_rx) = mpsc::channel(0);
    thread::spawn(|| read_stdin(stdin_tx));
    let stdin_rx = stdin_rx.map_err(|_| panic!()); // errors not possible on rx

    // After the TCP connection has been established, we set up our client to
    // start forwarding data.
    //
    // First we use the `Io::framed` method with a simple implementation of a
    // `Codec` (listed below) that just ships bytes around. We then split that
    // in two to work with the stream and sink separately.
    //
    // Half of the work we're going to do is to take all data we receive on
    // stdin (`stdin_rx`) and send that along the TCP stream (`sink`). The
    // second half is to take all the data we receive (`stream`) and then write
    // that to stdout. Currently we just write to stdout in a synchronous
    // fashion.
    //
    // Finally we set the client to terminate once either half of this work
    // finishes. If we don't have any more data to read or we won't receive any
    // more work from the remote then we can exit.
    let mut stdout = io::stdout();
    let client = tcp.and_then(|stream| {
        let (sink, stream) = stream.framed(Bytes).split();
        let send_stdin = stdin_rx.forward(sink);
        let write_stdout = stream.for_each(move |buf| {
            stdout.write_all(buf.as_slice())
        });

        const TICK_DURATION: u64 = 10;
        const TIMER_INTERVAL: u64 = 100;
        let timer = tokio_timer::wheel().tick_duration(Duration::from_millis(TICK_DURATION)).build();
        let timer = timer.interval(Duration::from_millis(TIMER_INTERVAL)).for_each(move |_| {
            // Let's simulate some CPU bound function which did not met the expected timeframe,
            // i.e. took longer than the `TIMER_INTERVAL`.
            std::thread::sleep(Duration::from_millis(TIMER_INTERVAL + 1));
            Ok(())
        });
        handle.spawn(timer.map_err(|_| ()));

        send_stdin.map(|_| ())
                  .select(write_stdout.map(|_| ()))
                  .then(|_| Ok(()))
    });

    // And now that we've got our client, we execute it in the event loop!
    core.run(client).unwrap();
}

/// A simple `Codec` implementation that just ships bytes around.
///
/// This type is used for "framing" a TCP stream of bytes but it's really just a
/// convenient method for us to work with streams/sinks for now. This'll just
/// take any data read and interpret it as a "frame" and conversely just shove
/// data into the output location without looking at it.
struct Bytes;

impl Codec for Bytes {
    type In = EasyBuf;
    type Out = Vec<u8>;

    fn decode(&mut self, buf: &mut EasyBuf) -> io::Result<Option<EasyBuf>> {
        if buf.len() > 0 {
            let len = buf.len();
            Ok(Some(buf.drain_to(len)))
        } else {
            Ok(None)
        }
    }

    fn encode(&mut self, data: Vec<u8>, buf: &mut Vec<u8>) -> io::Result<()> {
        buf.extend(data);
        Ok(())
    }
}

// Our helper method which will read data from stdin and send it along the
// sender provided.
fn read_stdin(mut rx: mpsc::Sender<Vec<u8>>) {
    let mut stdin = io::stdin();
    loop {
        let mut buf = vec![0; 1024];
        let n = match stdin.read(&mut buf) {
            Err(_) |
            Ok(0) => break,
            Ok(n) => n,
        };
        buf.truncate(n);
        rx = rx.send(buf).wait().unwrap();
    }
}

I think the expected behavior would be if we could still see messages coming from the server (after the timer timeout has been finished there is still a lot of time till the next timeout, tokio has to switch to another tasks to handle other futures), but it does not work this way.

Alright, I think I see what you mean. There is very probably a scheduling fairness issue that I will dig into. However, I would highly recommend to not run CPU intensive tasks on the tokio-core reactor. Instead, run them on futures-cpupool.

So, the issue is that your for_each over the interval stream is starving the reactor. Because the processing time is longer than the stream interval, the for_each runs in an infinite loop and control is never returned to the reactor.

Alright, I think I see what you mean. There is very probably a scheduling fairness issue that I will dig into.

Thanks Carl, yeah, I think that was my of my major points.

However, I would highly recommend to not run CPU intensive tasks on the tokio-core reactor. Instead, run them on futures-cpupool.

I thought about that, but the problem is that if I start the CPU intensive task in a futures-cpupool during timeout processing, I will still have to wait until it is completed, so the timer handling future will still take nearly the same amount of time. In additional it could be that I'll have to add an additional thread synchronization via mutexes.

So, the issue is that your for_each over the interval stream is starving the reactor. Because the processing time is longer than the stream interval, the for_each runs in an infinite loop and control is never returned to the reactor.

But there is a plenty of time between the intervals, isn't it? I mean when the processing is finished, there is still some time left until the next timeout, right?
Or does it work this way: if we missed a timeout (due to the long processing of the previous one), the missed timeout will be fired right after the processing ot the previous one is finished?

if we missed a timeout (due to the long processing of the previous one),
the missed timeout will be fired right after the processing ot the previous
one is finished?

That is correct
On Thu, Mar 9, 2017 at 3:28 AM Daniel Abramov<EMAIL_ADDRESS>wrote:

Alright, I think I see what you mean. There is very probably a scheduling
fairness issue that I will dig into.
Thanks Carl, yeah, I think that was my of my major points.
However, I would highly recommend to not run CPU intensive tasks on the
tokio-core reactor. Instead, run them on futures-cpupool.
I thought about that, but the problem is that if I start the CPU intensive
task in a futures-cpupool during timeout processing, I will still have to
wait until it is completed, so the timer handling future will still take
nearly the same amount of time. In additional it could be that I'll have to
add an additional thread synchronization via mutexes.
So, the issue is that your for_each over the interval stream is starving
the reactor. Because the processing time is longer than the stream
interval, the for_each runs in an infinite loop and control is never
returned to the reactor.
But there is a plenty of time between the intervals, isn't it? I mean when
the processing is finished, there is still some time left until the next
timeout, right?
Or does it work this way: if we missed a timeout (due to the long
processing of the previous one), the missed timeout will be fired right
after the processing ot the previous one is finished?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tokio-rs/tokio-timer/issues/9#issuecomment-285327045,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAYJIDny_mvNvG0JHvclxkAgnF5vclzks5rj-JDgaJpZM4MPcwi
.

Hm, understood.
So if I got it right, referring to my table with timestamps, the actual behavior at N+140ms would be "tokio notices that we missed a timeout which should have occurred at N+100ms [due to the processing of the previous timeout which had occurred at N+0ms] and so it schedules handling of this timeout immediately and we're starting processing of this missed timeout", is it correct?
If so, then it explains the observed behavior; you're right -- it seems to be related to the scheduling fairness.

Yep. There are a bunch of issues open in the futures-rs repository regarding yielding / fairness. So I'll close this issue in favor of those.


Make the Buildpack API version check more robust

Previously, if a buildpack.toml either:

Didn't match the specific custom buildpack type (used when custom fields are specified under [[metadata]])
Didn't match the CNB spec

...then a generic "failed to deserialise buildpack.toml" message was shown, rather than any error about the buildpack API version not matching.
In cases where the chosen API version is actually the cause of the error (for example if a future API version makes breaking changes to the schema), then this means the underlying cause isn't mentioned.
Now, the check uses a minimal BuildpackDescriptorApiOnly type when deserialising buildpack.toml, to ensure the API version can still be determined in those cases.
The BuildpackDescriptorApiOnly type was used instead of a raw toml::value::Table, since otherwise there are a myriad of Options and related to handle, from both the potential lack of api field and it not having a value of type string etc.
GUS-W-11324328.

@Malax Yeah I wasn't sure if it should be or not. I can move it into runtime.rs and make it private perhaps?

@edmorley Yeah, that is what I had in mind. 👍🏻


Unhandled rejection error on query

Hi,
We are having an issue with the following query:
DefectCount
    .query()
    .whereIn('caseId', caseIds)
    .orderBy('created_at')
    .select()

where DefectCount is a Bookshelf model. The error is:
Unhandled rejection error: select * from "defect_counts" where "caseId" in ($1, $2, $3
...
$81857, $81858) order by "created_at" asc - bind message supplies 16322 parameters, but prepared statement "" requires 81858

Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at null.Connection.parseE (/app/node_modules/pg/lib/connection.js:567:11)
Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at null.Connection.parseMessage (/app/node_modules/pg/lib/connection.js:391:17)
Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at Socket.<anonymous> (/app/node_modules/pg/lib/connection.js:129:22)
Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at emitOne (events.js:90:13)
Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at Socket.emit (events.js:182:7)
Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at readableAddChunk (_stream_readable.js:147:16)
Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at Socket.Readable.push (_stream_readable.js:111:10)
Jun 28 06:31:52 qcir-staging app/scheduler.6343:      at TCP.onread (net.js:525:20)

As you can see the caseIds array is very long (~81k) which might be part of the issue. We use this same query in a different code path that includes a much smaller collection of caseIds and this error is not raised.
Any ideas?

can you enter debug mode with knex and check the raw sql query end messages?
I think you are hitting some size limit, I don't know where

You are right, it was a statement length issue. We restructured the query similar to
knex('foo').whereIn('barId', knex('bar').select('id').where('count', 0));

and fixed the problem.


Adding Navia

[x]  New character package
[x]  Config in character package
[x]  Run pipeline with added config
[x]  Character key
[x]  Shortcuts for character key
[x]  Add Character package to imports
[x]  Character talent stats
[x]  Character curve
[x]  Normal Attack
[x]  Skill
[x]  Burst
[x]  A1
[x]  A4
[x]  C0
[x]  C1
[x]  C2
[x]  C3
[x]  C4
[x]  C5
[x]  C6
[x]  Other necessary talents (custom dash/jump, low/high plunge, ...)
[x]  Hitlag
[x]  ICD
[x]  StrikeType
[x]  Hitboxes
[x]  Attack durability
[x]  Particles
[x]  Frames
[ ]  Update documentation
[ ]  Update localization (IngameNames.json)

Missing documentation.
Some notes regarding that:

legal actions: walk should have notes saying that NA -> Walk doesn't have proper frames
frames: make sure to link all videos from Shizuka
use the following names for abilities: N1, N2, N3-1, N3-2, N3-3, N4, E, Q

actually missing localization as well

Also pls install VS Code/fix the linting errors somehow


Assert incarnation count is incremented when replacing resident instance reservation

This occurred to me after clicking "merge". Adding this assertion helps to ensure that the logic to increment the incarnation in this special case doesn't regress with future changes.


Pairing not triggering in teams, Logic app is working fine and successful. but no triggers in teams

Hi Team,
we have deployed icebreaker bot into teams, after all azure resources deployed in portal. Logic app is working fine and successful triggering as per schedule. but no alerts in teams. How to debug or what could be issue.

@salaman we have deployed icebreaker bot into teams, after all azure resources deployed in portal. Logic app is working fine and successful triggering as per schedule. but no alerts in teams. How to debug or what could be issue.

Hi @Nandeesh82, did you manage to find a solution to this issue? I am having the same problem and have not yet found a solution.

Hi @Nandeesh82, did you manage to find a solution to this issue? I am having the same problem and have not yet found a solution.

@wy62 , It is working fine now. Check your manifest package and app Id details. Mine was a network configuration issue. If no changes to gitub code, Then it should work fine.

I've checked the manifest file multiple times. All looks ok.
Can you be more specific about your network configuration issue?
I'm pulling my hair out with this!

@wy62 , Mine was network configuration issue, which I have done as per organization settings, firewall was blocking and configured it with Vnet and Subnet details.
but I have configured the same GitHub bot in my subscription without any issues, here I have not done any changes to Network.

@Nandeesh82 Thanks for your help. I finally managed to get this working today. The problem was that we had deployed the app to one tenant but it would be used in a different tenant. So when deploying the app I had to change the tenant ID to the tenant where the app was going to be used.


Problem scrollbar with niceScroll plugin

Hello, I use niceScroll plugin, I have a little problem with your magnific popup, when I click on an image in lightbox, the original scrollbar appears on the side of the custom scrollbar, you can help me solve this little problem? Otherwise, your plugin is perfect.
Thank you.

Conflict with "jquery.nicescroll" #183


Tests

Adds support for testing the SDK, including React components, through mocha and chai.
Adds coverage reporting via nyc.
Adds some tests for the basic building blocks of the SDK, allowing them to be used as an example for writing tests in the future.
Adds two modes of running tests:

npm run test for one-time test run + coverage reporting
npm run test:watch for running tests in watch mode, to be used in development

Fixes #7

Hm, the issue seems to be that much of the ancient stack is not supported on old Node versions. @robertjd @typerandom are these old versions really necessary anymore? The bare-bones build process works there, we know as much, but I cannot seem to find decent replacements for some of the dev tools here, which require Node >= 4. Any change we could migrate Travis to test 4, 6 and 7? We're just pushing a build library anyway.
Everything works fine on version 4+.
Also, I added just some basic text examples for every type of object in the app. I can either test everything, but that will take a while, or we can go with a policy of adding tests when you touch something (and appropriately moving the minimum coverage percentage up as we go).


Add support for indexers in assign param

Fixes https://github.com/Azure/azure-sdk-for-net/issues/42082
Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Provisioning


Multiple use of on('init') might cause inconsistencies

I don't have a concrete issue, but I was looking for some  other stuff and noticed this code -
https://github.com/DockYard/ember-validations/blob/master/addon/validators/base.js#L16
The base object is calling multiple functions using on init.
Some of this functions are relying on other function on the on init process to finish (like pushConditionalDependentValidationKeys that has to run before addObserversForDependentValidationKeys ).
But since the execution order of on init is not guaranteed  this create a very fragile code.
I made this pull request to fix this issue.
I couldn't  get the automatic test to work so a more careful examination of this fix might be necessary .
P.S - On another look I think the pushDependentValidationKeyToModel  is not really doing any thing so I removed it. It treated model.dependentValidationKeys as an object even it was an array, and it tries to add this property to it even though it was add in the main init function

@yonjah Can you rebase on master, now that we have fixed the test suite?

on('init') was considered a best practice before ES6 gave use the spread operator. It is no longer the case: https://dockyard.com/blog/2014/04/28/dont-override-init

@bcardarella I'm sure there was a good reason to use on('init') when this code was first created but I can't see it now.
Even if its best practice having multiple on('init') calls in your object which are dependent on each other is fragile and bad practice in any circumstance.
@martndemus I'll try to pull in the changes from master and rebase

How are you guys with breaking  changes to the API ?
I saw the failing tests and they are do to  some tests adding parameters to the dependentValidationKeys after init super has finished.
There are two ways around it -

having a dedicated method to do that ( That's what I did in this commit)
having one method that will be called "on('init')" and will be in charge of syncing all this actions.

I personally prefer the first way but it is not how the API is currently designed.
Also there is a test that actually check if pushDependentValidationKeyToModel actually overloaded the array with the dependency parameter. I'm not sure why this code and test is there but if it is really necessary I might have to push it back in (but then I'll probably have to use the second way)

Technically the library is still in alpha, so if it is a valid change we can do it

I reverted most of the changes only aggregating everything into a single on('init')
method. There might be some benefits in changing that and moving away from on('init') use in the base class but this should probably be as part of a larger change that will consider the entire class API


Creating my Profile in Bonganibendi.json

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers
I created a new fork for this project.
I fixed the errors from my previous pull request: #1514.

Looks good to me! Thank you for contributing.
__
  Summary: :ok_hand: This code looks good


"Exposures with low risk on n day(s)" vs "Exposures on n day(s) with increased risk"

Where to find the issue
Inside of the app on the main risk card, see "Steps to reproduce the issue".
Steps to reproduce the issue

Open the Corona-Warn-App
Get an exposure with low risk
See that the text for a low risk "Exposures with low risk on n day(s)"
Get an exposure with increased risk
See that the text for a increased risk exposure is "Exposures on n day(s) with increased risk"

Describe the issue
The app does not display the number of encounters in the same place for an increased risk encounter (middle of the sentence) as it does for a low risk encounter (end of the sentence).
Suggested change
Let the app display the number of encounters for both, low and increased risk, in the same place of the sentence (either in the middle or on the end).
So either
"Exposures with low risk on n day(s)" &
"Exposures with increased risk on n day(s)"
or
"Exposures on n day(s) with low risk" &
"Exposures on n day(s) with increased risk"
Screenshots
See https://www.coronawarn.app/en/screenshots.

Internal Tracking ID: EXPOSUREAPP-6264

@Ein-Tim Thanks. Internal Tracking ID: EXPOSUREAPP-6264

I provided PR https://github.com/corona-warn-app/cwa-app-ios/pull/4458 addressing this issue.

Hi @Ein-Tim, suggestion: in order to avoid working on a PR that might be rejected, you can ping me or another Corona-Warn-App Open Source Team member and we will try to get feedback from the dev team.

Hey @dsarkar, yes, I will do that in the future, however, issues should not only be rejected when someone wants to work on it but continuously, so that the issue trackers are kept clean and so that the community knows that open issues are valid and can be worked on / are worked on by the team. Do you agree with me here?

Hi @Ein-Tim, sure we try to sync as much as possible between the Community and dev team/management/etc... Some issues unfortunately snow under, and only when there is a comment, or in this case a PR,  they "awake again to life". This happens particularly with non-critical issues.

@Ein-Tim for what it's worth, let me elaborate on the wording:

Exposures with low risk on n day(s) describes the exposures as being low risk
Exposures on n day(s) with increased risk describes the day as having an increased risk

This makes sense, because the risk calculation (1) first distinguishes between exposures as being either low risk or increased risk and then it aggregates the data by date to decide if the day has a low risk or increased risk.
That means there can be a day with increased risk, while all exposures on that day were actually low risk.
This would overlap with Exposures on n day(s) with low risk and exclude Exposures with increased risk on n day(s).
That's why we have the current wording. Apologies for not explaining this earlier.
1 - risk_calculation.svg

@mlenkeit Thank you very much for the explanation! This makes sense!

That's why we have the current wording. Apologies for not explaining this earlier.

That's absolutely no problem, I understand that the team has a huge workload and that it is nearly impossible to keep up with everything! Have a relaxed evening & weekend!


Matplotlib Deadlock in a Slurm job

Hi,
We just came across a dead lock issue in using NeMo training on Slurm with pyxis+enroot:
  File "/opt/NeMo/examples/nlp/language_modeling/megatron_gpt_pretraining.py", line 19, in <module>
    from nemo.collections.nlp.models.language_modeling.megatron_gpt_model import MegatronGPTModel
  File "/opt/NeMo/nemo/collections/nlp/__init__.py", line 15, in <module>
    from nemo.collections.nlp import data, losses, models, modules
  File "/opt/NeMo/nemo/collections/nlp/data/__init__.py", line 42, in <module>
    from nemo.collections.nlp.data.zero_shot_intent_recognition.zero_shot_intent_dataset import (
  File "/opt/NeMo/nemo/collections/nlp/data/zero_shot_intent_recognition/__init__.py", line 16, in <module>
    from nemo.collections.nlp.data.zero_shot_intent_recognition.zero_shot_intent_dataset import (
  File "/opt/NeMo/nemo/collections/nlp/data/zero_shot_intent_recognition/zero_shot_intent_dataset.py", line 30, in <module>
    from nemo.collections.nlp.parts.utils_funcs import tensor2list
  File "/opt/NeMo/nemo/collections/nlp/parts/__init__.py", line 17, in <module>
    from nemo.collections.nlp.parts.utils_funcs import list2str, tensor2list
  File "/opt/NeMo/nemo/collections/nlp/parts/utils_funcs.py", line 24, in <module>
    from matplotlib import pyplot as plt
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/pyplot.py", line 52, in <module>
    import matplotlib.colorbar
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/colorbar.py", line 19, in <module>
    from matplotlib import _api, cbook, collections, cm, colors, contour, ticker
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/contour.py", line 13, in <module>
    from matplotlib.backend_bases import MouseButton
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/backend_bases.py", line 45, in <module>
    from matplotlib import (
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/text.py", line 16, in <module>
    from .font_manager import FontProperties
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/font_manager.py", line 1551, in <module>
    fontManager = _load_fontmanager()
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/font_manager.py", line 1546, in _load_fontmanager
    json_dump(fm, fm_path)
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/font_manager.py", line 958, in json_dump
    with cbook._lock_path(filename), open(filename, 'w') as fh:
  File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
    return next(self.gen)
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/cbook/__init__.py", line 1814, in _lock_path
    raise TimeoutError("""\
TimeoutError: Lock error: Matplotlib failed to acquire the following lock file:
    /root/.cache/matplotlib/fontlist-v330.json.matplotlib-lock
This maybe due to another process holding this lock file.  If you are sure no
other Matplotlib process is running, remove this file and try again.

I thought different processes should be using different container resource, but such dead lock issue seems to indicate something different from what I thought. Any insight will be appreciated. Thanks!

If you have ENROOT_MOUNT_HOME y in /etc/enroot/enroot.conf then /root will be mounted from your HOME , e.g. /home/felix -> /root. And if your HOME is a filesystem shared across compute nodes (like NFS), then the same folders might be reused across ranks / jobs.
You can edit the enroot configuration file, or add --no-container-mount-home to the srun command line.

@flx42 We already have --no-container-mount-home in the srun command.

@flx42 any other idea?

Do you have multiple processes running per node? In this case they will also share the same filesystem.

There are 8 processes per node, with each using one GPU.

Please file an issue against NeMo then, I'm not sure in which scenario you need to call matplotlib on 8 processes simultaneously.

Sure. I will file an issue with NeMo. Pytorch lightning also has an import matpotlib which causes this timeout in the distributed training with enroot.


Update v4l2m2m interface & create videoio.h

Update v4l2m2m interface & create videoio.h

Copy part of linux videodev2.h which is used by ffmpeg v4l2m2m
Move userspace interface from nuttx/video/video.h to include/sys/videoio.h

Impact
N/A
Testing
CI

@shizhenghui what is the purpose of this command:
ffmpeg -vcodec h264_v4l2m2m -i /stream/333.mp4 -pix_fmt rgb32 -f fbdev /dev/fb0

I assume it is only used on Linux side, since we don't have ffmpeg ported.
Please include more information and documentation about how to use video support on NuttX

@shizhenghui what is the purpose of this command:
ffmpeg -vcodec h264_v4l2m2m -i /stream/333.mp4 -pix_fmt rgb32 -f fbdev /dev/fb0

I assume it is only used on Linux side, since we don't have ffmpeg ported.

Xiaomi made a porting two years ago.

Please include more information and documentation about how to use video support on NuttX

this is the first step, m2m driver and documentation will provide in the next step.

@shizhenghui what is the purpose of this command:
ffmpeg -vcodec h264_v4l2m2m -i /stream/333.mp4 -pix_fmt rgb32 -f fbdev /dev/fb0

I assume it is only used on Linux side, since we don't have ffmpeg ported.
Please include more information and documentation about how to use video support on NuttX

@xiaoxiang781216 is it possible to submit the ffmpeg port to mainline or we need to wait for h264_v4l2m2m support first?

@xiaoxiang781216 is it possible to submit the ffmpeg port to mainline or we need to wait for h264_v4l2m2m support first?

it will open source publicly within 6 months.


Remove clone() functions

No more required

I just checked out this library for this function :D is there an alternative?

JSON.parse(TSON.stringify<T>(input)) can replace it.

It doesn't, my use case was to convert a class T to interface I so that the resulting object contains only properties defined in the interface I without additonal properties from T


Crash at editor startup on Linux

Godot version:
All versions after 6f3486c4866a0a0e0408c2e0dbd65f128995abf4
OS/device including version:
Linux 4.14.4
mesa 17.2.8
xorg-server 1.19.6
i3 4.14.1 / dwm 6.0
Issue description:
The project manager starts normally.
When the editor is started (from the project manager or standalone), it produces an unresponsive window.
Removing the code added in 6f3486c4866a0a0e0408c2e0dbd65f128995abf4 fixes this bug.
I have only tested this with the i3wm and dwm window managers (versions above), both tiling WMs.

Duplicate of #15068.


lmdbxx: switch to active fork, <IP_ADDRESS> -> 1.0.0; nheko: 0.8.1 -> 0.8.2

Motivation for this change
The original lmdbxx project is dead since 5 years. The fork was already adopted
by gentoo and by the downstream application nheko (still unreleased).
I'm waiting for the nheko release now.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 115052 at 473bdb59 run on aarch64-linux 1

1 package failed to build:

nheko

#119962 does the same and was merged two days ago, closing


new release https://github.com/KhronosGroup/SPIRV-Tools/archive/refs/tags/vulkan-sdk-1.3.280.0/SPIRV-Tools-1.3.280.0.tar.gz

There is a recent new release,
at:
https://github.com/KhronosGroup/SPIRV-Tools/archive/refs/tags/vulkan-sdk-1.3.280.0/SPIRV-Tools-1.3.280.0.tar.gz
but it is not mentioned in the main repository here, at:
https://github.com/KhronosGroup/SPIRV-Tools/releases
Not every visitor may see this. I only noticed because I follow the BLFS project and
the above .tar.gz appeared there, so I downloaded it. By the way, extracting the
.tar.gz archive yields a different name, which I think is incorrect packaging. The
general way to package something is:
foobar-1.2.3/
foobar-1.2.3.tar.gz

Everything else is IMO incorrect. Most programs follow that scheme.

The supported distribution for SPIRV-Tools is through the LunarG Vulkan SDK. LunarG does additional validation and may cherry pick bug fixes for the final release.


PFPMP rule now use CORE_DIR for firrtl location

I tied to go back and just push this to master but it already made the branch and PR so oh well.


💡 [REQUEST] - Add images to fooditems in list

Start Date
No response
Implementation PR
No response
Reference Issues
No response
Summary
Add images of the food items on their specific cards within the search pop up screen. Allows the user a better experience.
Basic Example
Pictures added
Drawbacks
No response
Unresolved questions
No response

Good issue! Adding images would allow the user to visually identify items more easily.


ErrImagePull with custom Spark operator image

I am trying to build a custom spark-operator image without Helm. So I tried to build Dockerfile in a cluster for that.  The Dockerfile is in the master branch. For Kubernetes I use Minikube.
This is the sequence of command I have executed:

eval $(minikube docker-env)
docker build -t in-cluster . (in a directory with Dockerfile)

The delpoyment is created but Pod status shows such message:  ErrImagePull
What should I change to fix this error?
I also tried to create a deployment manually but the results were the same.
The steps:

Downloaded this repository
docker build -t spark:2.4.0 .

Spark-operator deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spark-operator-custom
  labels:
    role: spark-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      role: spark-operator
  template:
    metadata:
      labels:
        role: spark-operator
    spec:
      serviceAccountName: spark
      containers:
        - name: spark-operator-custom
          image: spark:2.4.0

Where did you push your image to?

I didn't push it. I use it locally

UPDATE: I pushed the image to DockerHub. When I tried to use it in the deployment I get such behavior:
sparkoperator   0/1   Pending   0     0s
sparkoperator   0/1   Pending   0     0s
sparkoperator   0/1   ContainerCreating   0     0s
sparkoperator   0/1   Error   0     5s
sparkoperator   0/1   Error   1     8s
sparkoperator  0/1   CrashLoopBackOff   1     9s

Same when I run the image in-cluster using docker run.
Here is the deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spark-operator-custom
  labels:
    role: spark-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      role: spark-operator
  template:
    metadata:
      labels:
        role: spark-operator
    spec:
      serviceAccountName: spark
      containers:
        - name: spark-operator-custom
          image: roksolanad/spark-in-cluster:v2.4.0

Is the image roksolanad/spark-in-cluster:v2.4.0 a Spark driver/executor image or one that contains the operator binary? It looks like the former. Can you try gcr.io/spark-operator/spark-operator:v2.4.0-v1alpha1-latest?

The newer image does have the same errors, indeed. Thanks

The error above means you haven't setup RBAC for the operator to give it the necessary permissions to create/update CustomResourceDefinitions. How did you install the operator?

I redefined RBAC and indeed it started to work properly.

I redefined clusterrolebinding for the default service account and indeed it started to work properly.
This is what I did:
kubectl create clusterrolebinding spark-admin --clusterrole=cluster-admin --serviceaccount=default:default --namespace=default

I redefined clusterrolebinding for the default service account and indeed it started to work properly.
This is what I did:
kubectl create clusterrolebinding spark-admin --clusterrole=cluster-admin --serviceaccount=default:default --namespace=default

can this be added somewhere to the documentation, i've installed everything in a namespace called dev, applies the rbc example (changed default to dev) and spent 2 hours figuring it out why i had the following error
Error: sparkapplications.sparkoperator.k8s.io is forbidden: User "system:serviceaccount:dev:default" cannot list resource "sparkapplications" in API group "sparkoperator.k8s.io" in the namespace "dev"

i applied the example above and it worked
kubectl create clusterrolebinding spark-admin --clusterrole=cluster-admin --serviceaccount=dev:default --namespace=dev


fix: add .gitignore to create-remdx template

Referenced from: https://github.com/nkzw-tech/dev-velocity-talk/blob/main/.gitignore
Closes https://github.com/cpojer/remdx/issues/9

Thank you!

Published as 0.7.0.


[Feat] Add Or Yarok Logo to all widget when Or Yarok user is logged in

As part of our personalization feature, when someone from a specific organization (that partners with us) is logged in, the widgets will contain its logo on it instead of the Lamas logo. First organization will be Or Yarok.

Hi
when user log in you should please use get user info api
https://github.com/hasadna/anyway/blob/dev/docs/USERAPI.md#get-user-info
to verify OR YAROK ID


Add BenchmarkDriver to run common benchmark flow.

Note that every push triggers a new benchmark job. After pushing a new change, you'd want to cancel previous jobs if they still runs, or only apply the label when the pull request is ready. We don't want to waste cycles on old builds.

There is a limited number of phones so this helps to save them for real needed benchmarking.
(There might be a configuration to cancel old builds once a new one pushed, might be good to look at Buildkite docs.)

Thanks @antiagainst I forgot this PR is tagged with buildkite benchmark.


allover: Disambiguate int size on public facing API

In some cases, int won't necessary be the of the size the code using it
expects, so we need to make sure to specify that size where it matters.

+1

Merged


Automatic summary table display for tabular data?

Related to custom inspectors #51, we could automatically detect tabular data and give a better default display using the summary table #23.

SQL cells use Inputs.table. But it would be nice to have column summaries.

SQL cells have the added benefit that we can use the SQL engine to create the histograms (and other summaries), and (later) the filtering.

Given that was have SQL cells using Inputs.table, I think this issue is basically covered by #23 — we’ll switch SQL cells to use that when it’s ready, and we’d have a programmatic way of getting the same display from JavaScript if desired. But I don’t think we’ll do “automatic display modes” where we change the behavior of the default inspector.


Referring to Components not working with Next.js

Hi! I configured my project according to https://github.com/zeit/next.js/tree/canary/examples/with-astroturf
const Child = styled.div`
    opacity: .5;
`

const Parent = styled.div`
    &.active {
        ${Child} {
        	opacity: 1;
        }
    }
`

But i get an error, when run next build:
ModuleNotFoundError: Module not found: Error: Can't resolve 'index-Child.css'

Yeah that is likely bc next's css plugin is using an ancient css-loader which doesn't support the features necessary (due to how css modules is coupled to css-loader)

If you can upgrade the case loader to at least v3 it should work

yarn resolutions fix my problem.

Yep, Gatsby also stuck with<EMAIL_ADDRESS>:(


I cannot use custom attributes.

In my opinion, Markup controls all Monobehaviors.
Therefore, it prevents me from creating my own custom Attribute.
How can I create custom attributes?
I delete below,
[CustomEditor(typeof(MonoBehaviour), true), CanEditMultipleObjects]
internal class MarkedUpMonoBehaviourEditor : MarkedUpEditor
{
}
below code is worked.
[CustomEditor(typeof(ButtonAttribute), true)]
internal class ButtonPropertyDrawer : MarkedUpEditor
{
private ButtonsDrawer _buttonDrawer;
private new void OnEnable()
{
    _buttonDrawer = new ButtonsDrawer(target);
}

public override void OnInspectorGUI()
{
    base.OnInspectorGUI();
    _buttonDrawer.DrawButtons(targets);
}

}
but....
not delete that code, its not worked.
How can I create custom attributes?

In conclusion, I want to make something that puts a button function in a method as an attribute.

Hi! There is no attribute for adding a button for a method currently. I'll consider adding it in the future.


Fixes a network problem

Since networks were shared across all benchmark runs, this could lead to one benchmark attempting to delete it while it was still in use
Also make the the way we open ports on the firewall compatible with having VMs from different clouds in the same benchmark

A few small comments, LGTM

Fixed


Error: @ngx-formly/core/lib/templates/field.type.d.ts(10,33): error TS1005: ';' expected.

I'm submitting a ...  (check one with "x")
[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request

Current behavior
Does not build due to
ERROR in node_modules/@ngx-formly/core/lib/templates/field.type.d.ts(10,33): error TS1005: ';' expected.
Expected behavior
has to build
Minimal reproduction of the problem with instructions

just install version 5v
What is the motivation / use case for changing the behavior?

Please tell us about your environment:

Angular version: 2.0.X

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript X.X | ES6/7 | ES5]

Node (for AoT issues): node --version =

couldn't reproduce it, just ensure your deps are updated or match angular/formly requirements.


Is this a fork of NoahGameFrame?

This is such similar to NoahGameFrame, any successful experience from that one?

We are the core developers of NF, after some different ideas, we create this new repo with some better performance.

The POD of the variant base data structure
Better network performance
Some new modules
New Unity3D client
Clean and simply
etc.

Using POD instead of protobuf? I don't think it a good way, even in many cases POD is a top priority to serialization.
Thanks for answering.

Please read AFCData.h, we use the POD in the memory data structure, not in network data transmission, we still use PB in network data transmission. PB is an excellent solution is this filed.


remove python2 compatibility code and tidy imports in tests directory

i'm assuming pathlib2 should also be removed from the test-requirements?

note: for consistency, imports have been sorted using isort

Close & reopen to trigger travis

sphinxcontrib.needs.services.github.NeedGithubServiceException: GitHub: API rate limit exceeded (twice). Stop here.

Argh shit, that's because of the new "needservice" feature, which loads data from github.
And github only allows a certain amount of requests.
As I have just triggered so many parallel builds, maybe it exceeded the rate limit quite fast.
I need a better solution here (stubbing the requests by monkepatches.)
Created #183 for this.

rebase on master

And again, thanks for all your effort!
Makes the code much cleaner.


add diagrams to explain tech env for schema lab in journey one

validate lab and update doc.

fixed in commit c05c3df


Update timeShiftBufferDepth on every manifest fetch

Hi
We are in the process of switching encoder solution for our live streams. Previously we have used a straight forward SegmentTemplate based solution with a sliding DVR-window. The new solution is based on just-in-time packaging, were every event in a live stream is served with individual SegmentTimeline manifests that are timeboxed for the event duration.
Our problems arise when playing an ongoing SegmentTimeline stream. As far as we understand, there are two ways of doing this:
1.  Dynamic timeShiftBufferDepth
UPDATE 1 - ([S][S][S][S])
UPDATE 2 - ([S][S][S][S][S])
UPDATE 3 - ([S][S][S][S][S][S])

(timeShiftBufferDepth) in relation to available [S]egments

Your current implementation seem to assume the first variant, but of course we use the second one. On every manifest update, the timeShiftBufferDepth grows slightly to reflect the actual available buffer. However this is not honored by shaka. The available seek range seems only to update at very sporadic intervals (minutes apart). If we monkey patch the logic to always assume a huge timeshiftBufferDepth things work as expected.
Is there a specific reason why this is not supported? Could it be?

Put simply, it's not supported because we've never seen it before.  :-)  I think this is something we can fit into v2, though.


v0.1.0-beta.7

Hrm, publishing to NPM failed apparently due to an upload size limit:
npm ERR! 413 Payload Too Large - PUT https://registry.npmjs.org/@matrix-org%2fmatrix-sdk-crypto-nodejs - Payload Too Large

@poljar Any idea of how to address this?

Ah, the release workflow included debug files in its tarball for some reason.  For comparison, the previous release has only 8 files, while the draft release created by the workflow has 2195.

Oh, I may have figured it out: under the matrix-rust-sdk repo, the default build profile excluded debug info, but in this repo, it includes it.  Updating the release workflow to use npm run release-build ought to put a stop to that.

The other missing piece was to update .npmignore, which after the repo split, needs to cover a few more files/directories that now get placed in the project root.


ntr: abolished microtubule cortical anchoring

PMID:25736293
fig 3B and supp 3B
descendent of:
FYPO:0005464	abnormal maintenance of protein location at cell tip
x product with ?
https://github.com/geneontology/go-ontology/issues/13348

This reads as though it would refer to a GO BP rather than MF term, perhaps GO:0097248 'maintenance of protein location in cell cortex of cell tip', plus another xp part to make it specific for microtubules. That would certainly be a better fit for the suggested ancestor, which is in the BP phenotype department of FYPO. (Also, the MF term suggested in the linked GO ticket isn't tip-specific so it wouldn't capture all the necessary conditions anyway.)

Scratch that - better idea for new GO term for xp based on existing 'microtubule anchoring' terms: "microtubule anchoring at cell cortex of cell tip"

abnormal protein localization to cell tip FYPO:0005987
abolished microtubule anchoring at cell cortex of cell tip during meiotic cell cycle FYPO:0005988
renamed FYPO:0001584 and some descendants to make 'vegetative' explicit
FYPO:0005988 is not under FYPO:0005464 because the existing terms are all specific for vegetative growth. For now, I've just put FYPO:0005988 directly under FYPO:0005987; we can fill in non-veg-specific intermediate terms as the need arises.
edit file: 01ba4a11eebc4116f235ea963c18d01e231dc4ef
release: acbc41b365922deb2a26ca46510834c779d780c0


Menu does not work in the send-error sample

After we run the demo, Features menu does not work.

Closing as repo is deprecated.


cosign sign --allow-insecure-registry does not behave as expected over http/https proxy

Description

Having --allow-insecure-registry should work for BOTH insecure and secure registries (as the name suggests "allow"). If --allow-insecure-registry flag is set, cosign will fail to resolve DNS for even secure registries (e.g. myregistry.azurecr.io)
e.g.
$ export HTTP_PROXY="mycorp.proxy.com"
$ export HTTPS_PROXY="mycorp.proxy.com"
$ cosign sign --key=cosign.key "myregistry.azurecr.io/my-image:some-tag"
Pushing signature to: myregistry.azurecr.io/my-image:some-tag
# WORKS !

$ export HTTP_PROXY="mycorp.proxy.com"
$ export HTTPS_PROXY="mycorp.proxy.com"
$ cosign sign --key=cosign.key --allow-insecure-registry "myregistry.azurecr.io/my-image:some-tag"
Error: signing [myregistry.azurecr.io/my-image:some-tag@sha256]: accessing image: Get "https://myregistry.azurecr.io/v2/": dial tcp: lookup myregistry.azurecr.io: no such host
main.go:74: error during command execution: signing [myregistry.azurecr.io/my-image:some-tag@sha256]: accessing image: Get "https://myregistry.azurecr.io/v2/": dial tcp: lookup myregistry.azurecr.io: no such host
# FAILS

Version

GitVersion:    v2.0.2
GitCommit:     871448050b924a7946ebe47678f23aae09ef432d
GitTreeState:  clean
BuildDate:     2023-04-24T17:31:42Z
GoVersion:     go1.20.3
Compiler:      gc
Platform:      darwin/amd64

Same issue here,
COSIGN_LOG=debug cosign sign -y --allow-insecure-registry --key cosign.key --verbose=true <registry>/project-1732/alpine:latest
WARNING: Image reference <registry>/project-1732/alpine:latest uses a tag, not a digest, to identify the image to sign.
    This can lead you to sign a different image than the intended one. Please use a
    digest (example.com/ubuntu@sha256:abc123...) rather than tag
    (example.com/ubuntu:latest) for the input to cosign. The ability to refer to
    images by tag will be removed in a future release.

2024/11/22 09:27:45 --> GET https://<registry>/v2/
2024/11/22 09:27:45 GET /v2/ HTTP/1.1
Host: <registry>
User-Agent: cosign/v2.2.3 (linux; amd64) go-containerregistry/v0.18.0
Accept-Encoding: gzip


Make partials work in Alephant

We'd like to include common mustache templates using mustache partials.
Currently by default it will look for partials in the current directory, but as we have different queues in the election data renderer project it's not possible to store them in the same directory.
We have got around this issue by setting the following in our view model:
self.template_path = File.dirname(__FILE__) + '/../../lib/templates/'

It would be nice for this to be set somewhere in Alephant::Views::Base - however the only caveat with that, is that '/../../lib/templates/' is very specific to the election data renderer project.
Perhaps we can call a static method on Alephant::Views::Base from the election data renderer project which sets a path for partials?

I'll get round to this any day now ...

@kenoir glad to hear it, I've been waiting all this time ;)


WMS ID = 11526 - GoldenGate Microservices for License deployments 21c to 23ai upgrade

WMS ID = 11526
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[x ] All filenames are lower case (including folders, images, files, etc.)
[x ] Filenames are descriptive
[x ] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[x ] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[x ] Image references in markdown contain an alternate text

Adopted the new livelabs URL as requested


Skip the fips check under arm64

For some reason the output of the strings do not work properly under arm64. Skip it for now until we implement it the same way as immucore does

only happens on master when it tries to build the missing packages


Bug in SubmissionQueueEvent::prep_read_fixed

Setting  self.sqe.flags |= SubmissionFlags::FIXED_FILE.bits(); https://github.com/withoutboats/iou/blob/master/src/sqe.rs#L134 сausing Error: Os { code: 9, kind: Other, message: "Bad file descriptor" }
Code to reproduce:
#[test]
fn test_read_fixed() -> io::Result<()> {
    let mut io_uring = iou::IoUring::new(32)?;

    let mut path = PathBuf::from(env!("CARGO_MANIFEST_DIR"));
    path.push("props");
    path.push("text.txt");
    let file = File::open(&path)?;
    let mut buf0 = [0; 4096];
    let mut buf1 = [0; 4096];
    let mut buffs = &[IoSlice::new(&buf0), IoSlice::new(&buf1)];
    let registrar = io_uring.registrar();
    registrar.register_buffers(buffs);
    unsafe {
        prep_fixed(&mut io_uring, &mut buf0, file.as_raw_fd())?;
    }

    let dirt = dirty_stack();

    let n = {
        let mut cq = io_uring.cq();
        let cqe = cq.wait_for_cqe()?;
        assert_eq!(cqe.user_data(), 0xDEADBEEF);
        cqe.result()? as usize
    };

    assert_eq!(&TEXT[..n], &buf0[..n]);
    drop(dirt);

    Ok(())
}

#[inline(never)]
unsafe fn prep_fixed(ring: &mut iou::IoUring, buf: &mut [u8], fd: RawFd) -> io::Result<()> {
    let mut sq = ring.sq();
    let mut sqe = sq.next_sqe().unwrap();
    sqe.prep_read_fixed(fd, buf, 0, 0);
    sqe.set_user_data(0xDEADBEEF);
    sq.submit()?;
    Ok(())
}

Does this work if the code is patched so that the flag is not set?
My read of the io_uring PDF was that this flag was supposed to be set for fixed reads and writes, but perhaps I was mistaken.

I see, I've conflated fixed files and fixed buffers.

yeah

The same applies to write_fixed

If you don't mind, I will make a pull request to fix this issue(s)

Just fixed in master #13 :) Thanks for the report!


Make sendStats customizable

By analyzing the blame information on this pull request, we identified @mlmorg and @Raynos to be potential reviewers


 Tag example pasted into a Blazor wasm project does not work.

 It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5ea474d5-234a-f393-8609-892a2deb5d2e
Version Independent ID: c11d981c-05af-c19d-a333-feedd5978639
Content: ASP.NET Core Blazor file uploads
Content Source: aspnetcore/blazor/file-uploads.md
Product: aspnet-core
Technology: aspnetcore-blazor
GitHub Login: @guardrex
Microsoft Alias: riande

OOF for the :gift: holidays :snowman:
This issue has been marked for triage on the Blazor.Docs project, and I'll respond as soon as I return in 2021.
We only work on documentation on this repo. If you need product support, close this issue and seek assistance through one or more of the following support channels:

Stack Overflow (tagged: blazor)
General ASP.NET Core Slack Team
Blazor Gitter

If you think that you found a potential bug in the framework or have product feedback, close this issue and open a new issue for the ASP.NET Core product unit at aspnet/AspNetCore issues.
For problems or feedback on Visual Studio or Visual Studio for Mac, close this issue and use the Report a Problem or Suggest a Feature processes from within VS, which open internal issues for the VS team. For more information, see Visual Studio feedback options or How to report a problem in Visual Studio for Mac.
For problems with Visual Studio Code, close this issue and ask for support on community support forums. For bug reports and product feedback, open an issue on the microsoft/vscode GitHub repo.
⛄🎁 Happy Holidays! :dancer::man_dancing::partying_face: Happy New Year! :balloon::champagne::tada:

@Spottigus ... I can't repro a problem with it here in 5.0 ...

If you're still having trouble with it, open an issue with the product unit for investigation at ...
https://github.com/dotnet/aspnetcore/issues


2.0.0-alpha.25 加载 CTB5_POS_RNN 出错

Describe the bug
2.0.0-alpha.25 加载 CTB5_POS_RNN 出错
Code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate the problem.
tokenizer = hanlp.load('CTB5_POS_RNN')
print(tokenizer('商品和服务'))

Describe the current behavior
加载 CTB5_POS_RNN 出错
试了几次，此处出错
Downloading https://github.com/SUDA-LA/CIP/archive/master.zip#BPNN/data/embed.txt to /root/.hanlp/thirdparty/github.com/SUDA-LA/CIP/archive/master.zip
100.00%, 4 KB/4 KB, 14.1 MB/s, ETA 0 s
......
FileNotFoundError: [Errno 2] No such file or directory: '/root/.hanlp/thirdparty/github.com/SUDA-LA/CIP/archive/master/BPNN/data/embed.txt'
Expected behavior
能够运行测试代码
System information

Ubuntu 18.04
Python version: 3.6
HanLP version: 2.0.0-alpha.25

Other info / logs
Downloading https://file.hankcs.com/hanlp/pos/ctb5_pos_rnn_20191229_015325.zip to /root/.hanlp/pos/ctb5_pos_rnn_20191229_015325.zip
100.00%, 52.4 MB/52.4 MB, 4.2 MB/s, ETA 0 s
Extracting /root/.hanlp/pos/ctb5_pos_rnn_20191229_015325.zip to /root/.hanlp/pos
Downloading https://github.com/SUDA-LA/CIP/archive/master.zip#BPNN/data/embed.txt to /root/.hanlp/thirdparty/github.com/SUDA-LA/CIP/archive/master.zip
100.00%, 4 KB/4 KB, 14.1 MB/s, ETA 0 s
Extracting /root/.hanlp/thirdparty/github.com/SUDA-LA/CIP/archive/master.zip to /root/.hanlp/thirdparty/github.com/SUDA-LA/CIP/archive
Failed to load https://file.hankcs.com/hanlp/pos/ctb5_pos_rnn_20191229_015325.zip. See stack trace below
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/hanlp/utils/component_util.py", line 43, in load_from_meta_file
obj.load(save_dir, **load_kwargs)
File "/usr/local/lib/python3.6/dist-packages/hanlp/common/component.py", line 244, in load
self.build(**merge_dict(self.config, training=False, logger=logger, **kwargs, overwrite=True, inplace=True))
File "/usr/local/lib/python3.6/dist-packages/hanlp/common/component.py", line 255, in build
loss=kwargs.get('loss', None)))
File "/usr/local/lib/python3.6/dist-packages/hanlp/components/taggers/rnn_tagger.py", line 34, in build_model
embeddings = build_embedding(embeddings, self.transform.word_vocab, self.transform)
File "/usr/local/lib/python3.6/dist-packages/hanlp/layers/embeddings/init.py", line 53, in build_embedding
trainable=config.get('embedding_trainable', False))
File "/usr/local/lib/python3.6/dist-packages/hanlp/layers/embeddings/word2vec.py", line 22, in init
self.vocab, self.array_np = self._load(path, vocab, normalize)
File "/usr/local/lib/python3.6/dist-packages/hanlp/layers/embeddings/word2vec.py", line 50, in _load
word2vec, dim = load_word2vec(path)
File "/usr/local/lib/python3.6/dist-packages/hanlp/utils/io_util.py", line 420, in load_word2vec
with open(realpath, encoding='utf-8', errors='ignore') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/root/.hanlp/thirdparty/github.com/SUDA-LA/CIP/archive/master/BPNN/data/embed.txt'
https://file.hankcs.com/hanlp/pos/ctb5_pos_rnn_20191229_015325.zip was created with hanlp-2.0.0, while you are running 2.0.0-alpha.25. Try to upgrade hanlp with
pip install --upgrade hanlp

[x] I've completed this form and searched the web for solutions.

苏大删库了。
感谢反馈，已经修复，请参考上面的commit。
如果还有问题，欢迎重开issue。


ServiceCatalog service controller

New ACK Service Controller
Support for AWS Service Catalog
List of API resources
List the API resources in order of importance to you:
I am working with a team who would like to provision products from an AWS Service Catalog portfolio.

Hey @eamonnfaherty, can you please provide more information on what resources you want to manage using ACK?

Hey @eamonnfaherty, can you please provide more information on what resources you want to manage using ACK?

Service Catalog Provisioning Controller would be awesome. This would enable to provision sc products.
Ideally entire lifecycle management of product portfolio and share can be outside tge ACK as it involves hub and spoke model.

Hi Team,
Is there any way this proposal can be priotized?

@krijan-devops After examining the Service Catalog HTTP APIs, it looks like we could support at least the following resources:

Portfolio
Product
Constraint
ProvisionedProductPlan
ServiceOption

We would not support the CreatePortfolioShare API or the PortfolioShare resource, since this resource doesn't align with the Kubernetes Resource Model. In order to create a portfolio share, there is a manual accept/reject API call from the target account/organization that does not play nicely with the declarative resource model in Kubernetes.
Not sure when we could prioritize working on this controller, though. I have to get the SSM controller created before I would be able to work on this. If you or your team is interested in learning about ACK development, we could accelerate the development of this controller with your help.

@jaypipes it would be more around provisioning the service catalog products. There is no current managed pipeline to provision service catalog products itself. Similar to Lambda or ec2 we would need functionality to provision the existing service catalog product. We are not interested in sharing and create portfolios and products as they are done only during development and sharing. Provisioning is the biggest benefactor of a sc Support through ACK. We can definitely jump on a call to discuss this further.


Default cargo features should include doc-default features

Crate maintainers should be allowed to specify features which are off by default, but enabled by default in docs. This would allow people to compile docs for all of the extra features, while also turning these features off by default for most builds.

rust-lang/rust#9461  has some discussion related to this (in the context of docs.rs), and also links to onur/docs.rs#73  which contains a similar thing, but specifically for docs.rs.
Given that other folks are generating documentation than docs.rs, it does seem like a general configuration variable would be appropriate.

Personally, I think that a default = "docs" option would suffice; it'd be not too difficult to implement, and could be implemented in cargo itself. I think that just isolating this to docs.rs isn't the best because I personally would like to run cargo doc and get the same default behaviour that docs.rs has.


chore(publish): update config

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 96.747%

Totals

Change from base Build<PHONE_NUMBER>3:
0.2%

Covered Lines:
473

Relevant Lines:
480

💛  - Coveralls


table of challenges aren't responsive

I'm not satisfied with the current state of the table with challenges, it doesn't feels responsive. As I'm pretty inexperienced with front-end, I'd like to hear opinions about how to make them feel better at different screen sizes.

Thanks for the suggestion! It looks like a good way to do it, I might try it later.


[docs]Add topic-level policy config

Motivation
Topic-level policies are available since Pulsar 2.7.0.
Modifications
Add how to configure topic-level policies.
Related to #9161

LGTM

LGTM

@freeznet Thank you for your comments. Is it better to keep consistent for them in the code?

@freeznet Thank you for your comments. Is it better to keep consistent for them in the code?

@Jennifer88huang I think all commands should in lower case and unified format, as for the blue blocks, like get-maxProducers, should changed to get-max-producers. For the red blocks, I think they are fine, since the command name is just same as the function name, like GetMaxConsumersPerSubscription -> get-max-consumers-per-subscription.

@Jennifer88huang I think all commands should in lower case and unified format, as for the blue blocks, like get-maxProducers, should changed to get-max-producers. For the red blocks, I think they are fine, since the command name is just same as the function name, like GetMaxConsumersPerSubscription -> get-max-consumers-per-subscription.

@freeznet I think get-maxProducers is mistaken in the previous PR. We can add get-max-producers command first and add @Deprecated for the non-lower-case commands. And we can also make the non-lower-case command does not appear while run bin/pulsar-admin topics. This will guarantee compatibility.

@freeznet I think get-maxProducers is mistaken in the previous PR. We can add get-max-producers command first and add @Deprecated for the non-lower-case commands. And we can also make the non-lower-case command does not appear while run bin/pulsar-admin topics. This will guarantee compatibility.

@freeznet I think get-maxProducers is mistaken in the previous PR. We can add get-max-producers command first and add @Deprecated for the non-lower-case commands. And we can also make the non-lower-case command does not appear while run bin/pulsar-admin topics. This will guarantee compatibility.

@freeznet I think get-maxProducers is mistaken in the previous PR. We can add get-max-producers command first and add @Deprecated for the non-lower-case commands. And we can also make the non-lower-case command does not appear while run bin/pulsar-admin topics. This will guarantee compatibility.

@freeznet @codelipenghui thank you for your confirmation.
For those in the red boxes, I want to say that in namespaces, we use the word "xxx-per-xxx" (see screenshot below). Since those topic-level polices come from the namespace level, is it more user-friendly if we keep consistent and use the word "per" for topic-level policies? Otherwise, users might use the wrong commands if they want to adopt namespace-level policies to topic-level polices.

@freeznet @codelipenghui thank you for your confirmation.
For those in the red boxes, I want to say that in namespaces, we use the word "xxx-per-xxx" (see screenshot below). Since those topic-level polices come from the namespace level, is it more user-friendly if we keep consistent and use the word "per" for topic-level policies? Otherwise, users might use the wrong commands if they want to adopt namespace-level policies to topic-level polices.

@Jennifer88huang No, topic policy always for one topic, so we don't need to add -per-topic

@Jennifer88huang No, topic policy always for one topic, so we don't need to add -per-topic

@sijia-w confirmed with eng, we need to keep topic-level commands consistent with that in the namespace-level.
So it should be "get-max-producers", "get-max-unacked-messages-per-consumer", get-max-unacked-messages-per-subscription". Use this kind of format in the docs, and eng will refine the code accordingly.
cc @codelipenghui @freeznet

@sijia-w confirmed with eng, we need to keep topic-level commands consistent with that in the namespace-level.
So it should be "get-max-producers", "get-max-unacked-messages-per-consumer", get-max-unacked-messages-per-subscription". Use this kind of format in the docs, and eng will refine the code accordingly.
cc @codelipenghui @freeznet

Thank you @315157973 for fixing the command name issues in #9215. Shall we go on with the doc PR? @freeznet

Thank you @315157973 for fixing the command name issues in #9215. Shall we go on with the doc PR? @freeznet

Thank you @freeznet
@315157973 @codelipenghui @Huanli-Meng do you have any concern on it?

Thank you @freeznet
@315157973 @codelipenghui @Huanli-Meng do you have any concern on it?


Change MIN_GHOST_GENERIC_DELTA to match measure definition

Fixes #1646

Seb's :+1:ed the proposal on the original issue, so I'll merge this now.  (Thanks for the review!)


1021 Refactor Pet instance method to use the Match model instead of the AdopterApplication model

🔗 Issue
#1021
✍ Description

Refactored Pet#is_adopted? method to reference Match association rather than AdopterApplication
Fixed related tests

I'm sure that performance isn't a priority at the moment, but I noticed while refactoring the is_adopted? method, that there is an N+1 on the /staff/pets page because of this method and the in_foster?/open? methods are called in order to fetch the status of every pet.
Before changes:

After changes:

You can see the number of Active Record queries goes down significantly. I can put this into a separate PR, or just stash these changes for now, if we don't want to look at performance yet.