In other words, I don't believe that having all instances of Reactor provide a default timer implementation precludes usage with a custom timer. That, in summary, implies to me that it's safe to add handle-taking APIs for Timeout, and in turn will truly allow you to override the global event loop on an executor level.
Reactor::turn_until
Right now this function importantly takes &mut F: Future as an argument, but unfortunately you can't actually poll that, rather you'd have to take &mut Spawn<F>. Working with a Spawn directly tends to be pretty clunky, so I'd like to propose an alternative:
impl<'a> From<&'a Reactor> for NotifyHandle { /* ... */ }

This API would allow removing the future argument to Reactor as you can use functions like Spawn::poll_future_notify externally passing in the reactor as an argument. I believe this achieves the same level of flexibility in terms of being able to send custom wakeups to the reactor to force a turn_until function to return.
If we do decide to do this, I'd then propose:
impl Reactor {
    fn turn(&mut self, max_wait: Option<Duration>) -> Turn;
}

struct Turn { /* ... */ }

impl Turn {
    fn last_notify_id(&self) -> Option<usize>;
}

This removes the _until from the method name (as the future is now gone), preserves the max_wait argument, and then adds a return value, Turn, which indicates why the method returned. Originally I think we could just support a "this method returned because your future woke up" query accessor (via last_notify_id here), but we could continue to add more flavorful methods over time if necessary.

phew, I think that's it!
I'd encourage anyone with performance or implementation concerns to take a look at the implementation of the futures crate and the implementation of the tokio crate. The two should be in at least a buildable state and the examples in the tokio crate should all be buildable and runnable (tests I haven't ported yet).
This RFC required some significant rewrites of the internals of tokio, but I'm pretty pleased with how it all turned out. That being said there's likely to be at least one bug or two lurking, so extra eyes over code would always be helpful :)

Alright so now that I've gotten some rest.

Almost passed the Turing Test right there, nice try.

Perhaps the current_thread module could just be called thread?

In favor, the local aspect of current_thread maybe shouldn't be so emphasized,  a TaskRunner could very well be part of a pool of executors rather than an executor of actually local stuff. Maybe we make the naming consistent between Reactors and TaskRunners since they are kind'a similar, a TaskRunner is a reactor of futures. In that line, shouldn't it have a block_on_any method?
Should spawn immediately pool the future? should it pool the other futures?

I'd personally prefer to see the Drop implementation never panic and instead just cancel all pending tasks.

Yes, also we would abort if TaskRunner is dropped while unwinding which isn't very nice.

A interesting observation is that while the RFC speaks about a global thread pool, it never uses it, the only way it is used is by spawning a future on the Reactors Handle, which means the thread pool could be a property of the reactor. No reason to have a global one.

@leodasvacas

[...] a TaskRunner could very well be part of a pool of executors [...]

It can, but it is quite unlikely as neither TaskRunner nor Spawn are send, neither do they require the futures they accept to be Send so anything is locked to the current thread. Through giving it
a matching API is a pretty good idea, 👍  for block_on_any.

I'd personally prefer to see the Drop implementation never panic and instead just cancel all pending tasks.

If I see TaskRunner as a future not panicking on Drop is definitely what I expect. If I
see it as a type to help me queue up local tasks (through passing Spawn to places where
they might turn up) then panic makes a lot of sense as I definitely have some bug somewhere.
Alternative:

TaskRunner does not implement Future
TaskRunner::daemonize(self) turns it into a Future not which does not panic on drop if it has non daemon futures (which basically means they all are now as if attached with spawn_daemon hence deamonize)
or just simple have a daemonizing IntoFuture implementation

Perhaps the current_thread module could just be called thread?
[...] shortening TaskRunner to maybe just Tasks [...]

If we do so we lose the fact that's local/current thread only in the name.
But if the do current_thread => thread then

TaskRunner => LocalTasks
Spawner => LocalSpawner/SpawnLocal or like @alexcrichton said just Handle
would be good.

Generally it is interesting how similar Spawn and Handle are including their symmetry in
not being Send.

@dathinab I don't see why TaskRunner or Spawn would need to be Send, they would be created on a thread of the pool. I guess the futures themselves only need to be Send if you are doing work stealing.

@dathinab I don't see why TaskRunner or Spawn would need to be Send, they would be created on a thread of the pool. I guess the futures themselves only need to be Send if the thread pool does work stealing.

I briefly spoke with @alexcrichton on IRC about this.
@aturon this might be a little crazy and I get that language features are most likely out of scope for this RFC, but specifically regarding the global state, what are your thoughts around:
Allowing people to set contexts, those contexts can be changed within a specific scope but they will be implicitly passed down through the function tree.
fn child { Reactor }( ... ) {
  // use context.reactor
}

fn parent { Reactor }( ... ) {
  child(); // Would implicitly use the reactor passed into parent.

  | reactor: CustomReactor::new() | { // i.e. change the "context"
    // Both of these now use the custom reactor.
    child();
    child();
  }

  child(); // Would implicitly use the reactor passed into parent.
}

The thing I like most about this, is it is just syntax sugar for passing a reactor as a parameter, but improves the ergonomics.

It doesn't just help ergonomics for global  reactors, but also for custom ones (for example within some framework code).

It helps with other things like metrics, which are request scoped and other such structs which quickly proliferate through a service. eg. User, Database

Unless you pass these from function to function, the way Java solves this would be using Spring and scoped beans. Where scoped beans have to be on the heap, "context" values get to stay on the stack.

It might allow some cool configurations for framework authors.

eg. They might setup a custom reactor for themselves, but pass in a LocalReactor to each request.

Haven't thought it all through, but just trying to get some initial thoughts.

@yazaddaruvala Did you just propose implicit parameters? :smile:

@dathinab I don't see why TaskRunner or Spawn would need to be Send, they would be created on a thread of the pool. I guess the futures themselves only need to be Send if the thread pool does work stealing.

It's a bit of a pov think, but if you schedule work on a thread which just happens to be owned
by a thread pool, I wouldn't say you scheduled it on a thread pool. It's more like that you extended
already scheduled work.
This is quite a bit nit picking, but if you document it as scheduling tasks on a thread pool if it is run in one, its just a matter of time until some users get very irritated why their program is so slow and seems to only use one thread...

Edit: This was a misconception on my part, the RFC says it panics only if not already panicking.

you where faster than me 😉
It's still pretty bad if you pass a TaskRunner to a general executor  cancel it and it panics.
A typical example could be a library exposes a TaskRunner as a future (opaque with impl Trait),  you select over it with a timeout and forget to test the actuall timeout case => panic in production (in more than one sense)

Thanks @cramertj. Clearly I need to improve my Google-fu.
However, it is good to know this idea isn't as left field as I originally thought.

Thoughts on timers
This comment represents an overview of my thoughts on timers. It will provide a bunch of context.
There are generally two categories of timers. Coarse and high resolution timers.
High resolution timers tend to be set for sub second delays and require nanosecond resolution.
In the context of network programming, coarse timers appropriate. In this case, 1ms tends to be the highest level of resolution possible, but usually even 100ms resolution is sufficient. On top of that, even triggering the timeout with error margins as high as 30% is acceptable. This is because, in network programming, timers are usually used for:

Catching events that don’t happen (data fails to arrive on the socket).
Freeing idle resources (data in a LRU cache is no longer needed).
Sending out data to a peer on a period (every thirty seconds, send a ping).

The network is unreliable, as such it is usually OK for timers to be coarse.
Assumptions
When implementing a timer, the following assumptions are safe to make. These assumptions have guided the design of timers across many projects (Linux kernel, Nety, …)

Timer management must be as lightweight as possible.
The design should scale well as the number of active timers increases.
Most timers expire within a few seconds or minutes at most.
Long delays are rare.
Many, if not most, timeouts will be canceled before they are fired.

Algorithms
There are two common categories of algorithms for implementing timers. A heap and some variation of a hashed timer described in Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility.
Heap timer
This is using a heap data structure to store all timeouts, sorted by expiration time. Heap based timers have the following properties.

Trigger timeout: O(1)
Set timeout: O(log n)
Cancel timeout: O(log n).

Because of the assumptions stated below, heap based timers are rarely appropriate for use in networking related scenarios.
Hashed timer
While hashed timers are fairly simple conceptually, a full description is out of scope for this comment. The paper linked above as well as the overview by Adrian Colyer are good sources. There are a number of variations of the general idea, all with different trade offs, but at a high level are pretty similar.
Hashed based timers have the following properties:

Trigger timeout: O(1)
Set timeout: O(1)
Cancel timeout: O(1)

The various implementation permutations provide differing behavior in terms of the coarseness of the timer, the maximum duration of a timeout, trade offs between CPU & memory, etc… For example, a hashed wheel timer could be configured to have a resolution of 100ms and only support setting timeouts that are less than 5 minutes into the future.
Another option could be a hierarchical timer that supports a resolution of 1ms, support setting timeouts of arbitrary duration, but require some bookkeeping CPU work to happen every 3.2 seconds.
In fact, one characteristic of hashed wheel timers is that, when they are tuned for general purpose cases (i.e. supporting a resolution of 1ms and arbitrarily large duration timeouts), they tend to require book keeping every so often that could block the thread (this will be important later). However, even with these cons, the various hashed timers are much better suited for network programming cases based on the assumptions listed above.

Delays in firing timeouts is OK as timeouts don’t need to be precise.
This bookkeeping work, while it can create pauses, is much lower than the amount of work needed to maintain a heap based timer, especially as the number of outstanding timeouts grows (potentially in the millions) and most timeouts get canceled.

I/O reactor
This RFC proposes a default, global I/O reactor. Roughly speaking, its job is to spin in a loop, sleeping on epoll_wait, taking all epoll notifications and notifying the tasks that are associated with the I/O resources. The RFC details that, by default, a thread will be spawned up to run this logic, and nothing else. This means that, by default, there will be cross thread communication required for the I/O runtime thread to notify the futures being executed on another thread. As @aturon explained, while there is overhead involved, it isn’t bad. In general, the setup of a work-stealing thread pool used to drive app logic and an I/O thread to drive async I/O events has a lot of precedent and is an ideal default.
Now, enters the question of timers. The RFC details that there is also a default, global timer. A default, global, timer will also require a runtime thread in order to sleep & fire  The immediate thought would be that, since there already is a runtime thread required for the I/O reactor that this thread can be reused to drive the timer.
This would not be ideal. If cross thread communication is required to drive a default, global timer, a dedicated thread should be used. This is because:

The ideal timer algorithm is hashed based.
A hashed based timer tuned for general purpose requires CPU pauses to perform book keeping work.

While pauses delaying triggering timers is not critical for timers (see previous section), if they are are run on the same thread as the I/O reactor, they could cause delays in dispatching I/O events, which is not acceptable.
Running the timer on a dedicated thread solves these problems.
Executors
Now, lets take a moment to talk about strategies for executing futures. Generally, these are the same considerations taken when scheduling actors or green threads. As such, lessons from other environments apply here.
Locality, locality, locality!
When executing small tasks across a set of threads, you want to move data around threads as little as possible. This improves cache hits, locality, reduces synchronization, etc…
This guiding principle highly influenced the design of futures-rs’s futures and tasks. This is why futures own their own data and futures themselves are owned by executors, which are responsible for scheduling those futures. Hopefully, those executors are as smart as possible and avoid moving the futures across threads.
In fact, an efficient scheduling strategy is a pool of threads that keeps all futures local as much as possible. This is the work-stealing approach implemented by futures-pool.
Now, given that locality is key. The way timers would fit in to futures-pool would be for each thread in the pool to have its own timer. This way, when a future sets a timeout, it would require no cross thread communication and when the timeout fires, it would notify a future that is (ideally) on its thread.
So, given that I mentioned that the timer will have significant pauses. One could ask: wouldn’t it be bad to run on a future scheduler? No, because of the following reasons:

The timer bookkeeping work would be spread out between scheduling futures (this doesn’t work in the case of the I/O reactor because epoll_wait is a sys call, which is quite heavy and we don’t have any visibility into how much work is pending in the epoll queue).
Because the timer is almost entirely for futures that are on the same thread, if the thread is scheduling a future, there are by definition no timeouts that can fire because any timeout that would fire would notify a future on the same thread that can’t run until the current future is done executing (and the reverse applies to).

Lastly, you might ask, if it makes sense to have a timer per thread, shouldn’t we also have an I/O reactor per thread? In short, the answer is: ideally we would (see seastar but doing so requires a user land TCP stack. OS level async I/O primitives don’t provide the necessary flexibility to run an I/O reactor per thread efficiently (the exact reasons are out of scope of this comment).
Conclusion
The point of this lengthy comment is to illustrate why, in most cases, it is better to keep the I/O reactor and the timer on separate threads. Specifically, the only time they would be on the same thread is when the entire system is single threaded.
Thus, it does not make sense to bake in a timer to the I/O reactor or to pass an I/O reactor handle when setting a timeout. This links the timers to the I/O reactor, which, as this comment argues, is the opposite of what is ideal. I am opposed to any proposal that makes the Tokio &Handle a timer handle.

@carllerche I am not an expert in this by a long shot, but have you considered letting the kernel handle the timers, e.g. timerfd in Linux? Too slow? Too much overhead? Not portable?

@bluetech
timerfd on Linux is backed by a great general purpose timer implementation. There are also advantages to having the OS handle timers. However, the drawbacks are:

It isn't portable.
Using it requires syscalls.
It is a general purpose timer. You can usually do much better with a timer tuned to the use case at hand.

@carllerche What timer implementations will be available in Tokio? Will it still be possible to have a single thread running a core, executor and high-res timers used in the futures scheduled on it?

@tanriol I would like the timer implementation to be completely decoupled from the reactor. This would let you swap in whatever impl you want. And yes, the goal would be for it to still be possible to run everything (I/O reactor, timer, and executor) on a single thread.
However, you cannot pair a high-res timer w/ tokio (and probably futures in general...). Assuming you mean a high-res timer in the sub millisecond granularity, this just isn't possible due to OS APIs being roughly ms granularity and up.

Thanks @carllerche for the writeup about timers!
I've been talking some with @alexcrichton and @carllerche, and want to propose we make some revisions to the RFC based on the feedback so far:

Tighten up naming and Drop behavior around the current_thread module, as proposed by @alexcrichton

Refactor the turn_until API, again as proposed by @alexcrichton. This should be considered a lowest-level primitive for working with reactors directly.

Potentially extract timer functionality out of this crate altogether, but at any rate have it use a dedicated thread by default (much like tokio-timer).

It's also clear that we need a much more crisp story about how to customize the defaults the library would provide. In particular:
Hard constraints

Must be possible to use arbitrary libraries from the ecosystem, with a guarantee that no threads are spawned

Implies: must be able to “repoint” the global reactor + timer to a custom one you’re managing yourself

Must be able to customize the defaults at least at the executor level
Must be easy to tell, for certain, what reactor/timer a given piece of code is using

e.g., it can use the global default (whatever I set that to), or any reactor an already-bound I/O object that I pass in is using

Note: these hard constraints mean, in particular, that the library is fully "zero cost" in the sense of "pay only for what you use": if you want to exert full control over reactor and timer management, you can do so, and no threads or reactors will be created behind your back. But for the common case, you can use the defaults and have a good experience.
Soft constraints

Align as much as possible with executors

In particular, try to make executors be, in general, an “execution context” for a task, which says how to find various expected “global” resources

Avoid need for Handle-passing APIs if possible

This is in tension with the previous goal, because of the need to create an I/O object in one task, but use it in another
May be possible to work around this by “lazily binding” I/O objects to reactors

@alexcrichton is going to look into some concrete APIs for meeting the above constraints. It seems best for this RFC to include the basic customization story, to ensure that we have the bases fully covered. After that, I'll plan to update the RFC text itself.

I've spent way too long reading this entire thread top to bottom twice now
to be able to ask questions and reply appropriately.
In the end, I'm generally for these changes, but before getting into that,
I'd like to ask questions and make comments on everything else. I'm sure that
some of these questions were answered and I'm just being dense, so please bear
with me if I ask something that has been answered, or ask for further
clarification. Thanks!
Re: rendered RFC

On the other hand, if the woken task does non-trivial work (even just to
determine what I/O to do), it is effectively blocking the further processing
and dispatch of I/O events, which can limit the potential for parallelism.

This is only true if the reactor is used for multiple threads, right? If
there is one core per thread, it makes sense to block further io dispatch
because being blocked means that thread is working.

A global thread pool for executing compute-intensive or blocking tasks;
tasks must be Send.
Optionally, a dedicated thread for running thread-local (non-Send) tasks in
a cooperative fashion. (Requires that the tasks do not perform too much
work in a given step).

How would this look in libraries that need to spawn or return tasks? I think
this would force most library authors to make their tasks Send, right?

we can incorporate recent changes to mio

Out of curiosity, what recent changes is this referring to? I looked through
the commit subject's for a few pages and none jumped out.

we need control over the way the event loop is run in order to support
timers

Why is this the case?

This is later discussed in much more detail from
and @alexcrichton
@carllerche,
but I think a one or two sentence summary on this would be nice. @carllerche's
Conclusion is pretty good on this matter, but I know that there is a lot of
confusion about timer's in this thread.

spawn_daemon

For my own curiosity, when is this useful?

This is later answered with @alexchrichton's comment

this API is carefully crafted to help ensure that spawned tasks are actually
run to completion

How does this differ from before? I saw it a few times in this comment thread,
but what is an exact case where a spawned task is not run to completion?

executor's enter()

Does this API need to exist? Can it not just be a hidden thread local variable?
Re: first comment

Moreover, when running tasks thread-locally ... provide more fool-proof APIs
that help avoid lost wakeups

When and why do lost wakeups happen today?

If Reactor provides the turn API with a timeout, then there is no need to
couple a timer ...

I'm a bit confused here, so I'm going to write what I think it means, ask
for confirmation, and then ask a question or two:
The global event loop should probably come with a timer because turn takes
a Duration, and that needs a timer to run, right? The next line indicates
that a timer isn't paired with a reactor - but in this scenario, wouldn't each
reactor be paired specifically with its one timer?

In terms of the "this is talked about later" comments above - again, this is
talked about. One part not talked about is whether multiple reactors would
all share the same timer thread or not.

Re: why multiple event loops

where we anticipate actually using multiple Tokio event loops

I agree with @alex's event loop per thread.
I thought @carllerche already
implied something like this a few comments back ("threads that are fully isolated").
Re: event loops, again

This does indeed mean that using functions like Handle::default are buying
into future pain if you want to not use the default event loop, but that's a
price that can be explicitly bought into!

What would be unfortunate here is that all libraries that use the global event
loop would be eliminated immediately.
The compromise of overriding the default event loop seems to make this concern
go away.
Re: different profile workloads

Ultimately it gets saturated with different profile workloads and cause
starvation, over utilization, thrashing, etc

This is also something to worry about when doing a lot of file IO - we want to
do file io on separate threads not only because they sleep but to better let
the OS predict these threads don't need scheduled as much.
Summary Comment about how most concerns are resolved
This comment agrees that a default that can be overriden solves a lot of issues
that people have with it - really, overrideable defaults seems to solve most
issues in the thread. However, it does bring up a problematic issue of tokio in
dynamically linked libraries and what threads those are using.

@aturon adds more Hard constraints
that should resolve most remaining issues in the thread.

Timer's cannot take a &Handle
I'm still confused on why - the reason here is "the goal was to decouple timers
from the I/O reactor", but I'm still not fully sure on why that means Timer's,
which are decoupled from I/O reactor, can't take a reactor anyway?
In terms of not sending data across threads

Because the sockets stay on the thread that use them. Thus, the reads /
writes all happen on the thread that use them.

But these sockets need to send events to register with epoll to the reactor,
which is the cross thread communication.
But again, this shouldn't be a problem because the default global reactor can
be overridden on a per-executor basis, meaning the Seastar architecture can
still be imitated.
Ergonomic need

the ergonomic goal here is to avoid the need to pass around information
that's just going to be the same everywhere

For this point, I'm not so sure. Go has, over the prior few releases, been
slowly introducing context through anything
that has a connection. I know Go is derided a lot around Rust, but context
itself has proven to not be awkward.
Re: name shortening
thread as opposed to current_thread is shorter, but for me, mental context
when reading the code is lost. Whose thread? Which thread? I disagree with
@Ralith's later comment
about how it is appealingly consistent. std::thread is for thread utilities,
std::thread::current is the function that gets the current thread.
Same with Tasks - what does that mean? TaskRunner is obvious. Spawner is
obvious. These are words that imply what they do.
Also, later, NotifyHandle - this has always read to me as an action (notify
this handle!), whereas it's actually an object, a handle that can notify. Small
distinctions like this make the API incredibly confusing to read through for
me.
General comments
There are multiple places in this thread that mention the main problem is
documentation. I definitely agree, but not just that examples are missing. It's
to to know exactly what happens as futures chain into each other. Are they
run sequentially until one blocks, or is there a point at which other futures
are maybe run? What happens when a future returns Async::NotReady but
doesn't install something that will wake it back up? It never gets called
again - how do I change that for some user space thing that is difficult to
install notifications for?
As a last critique, I want to bring up again the api naming. For Reactor, why
turn or turn_until?  Every time I see these names without the corresponding
documentation, I am confused. If the answer is the same as this comment in
that it the parlance for those in the know that have history, I'm not too large
a fan of keeping that parlance. It seems like a bit odd to choose a more
obscure name even if it is more technically correct, and, other than the
Wikipedia page on "Reactor pattern" I've never seen it before.
Overall, I'm conflicted about this change. Global state is usually code
smell. This new proposal is introducing a runtime into a language whose core focus
is minimal overhead and speed.
However, the compromises that @aturon listed as hard constraints
just above should truly mean that users can override the global state
defaults with what they want. Since everything in the tokio ecosystem would
need one or all of a handle, a reactor, or a timer, it makes sense to have
this global state. Since that global state can be overridden, it seems
non-controversial.
About the only thing that does not seem addressed is the comment about
loading DLLs
that may be using threads.
Did I capture everything? Also, sorry for any odd formatting, I took notes in and wrote this in an editor.

@twmb

This is only true if the reactor is used for multiple threads, right? If there is one core per thread, it makes sense to block further io dispatch because being blocked means that thread is working.

Yes and no. The question is if every person doing anything async should have to always think about keeping their tasks short running. It's not always obvious when a bit of async code consumes too much CPU. Even if you are running a reactor per thread, while you will keep the CPUs busy, you will starve other tasks that are waiting for time.
Basically, running a reactor & executor on the same thread can be more efficient but is harder to get right.

How would this look in libraries that need to spawn or return tasks? I think this would force most library authors to make their tasks Send, right?

This puts emphasis on Send, but it isn't a requirement. Lib authors can request an executor that is !Send.

Out of curiosity, what recent changes is this referring to? I looked through the commit subject's for a few pages and none jumped out.

It is referring to work that has happened throughout most of 2017.
re: executor enter

Does this API need to exist? Can it not just be a hidden thread local variable?

The API is intended to only by used by authors of executors, not end users.

When and why do lost wakeups happen today?

It's a common issue that comes up in gitter / IRC. Users spawn tasks onto an executor but never start the executor. A local thread executor can't be implicitly started (unlike a thread pool), so this results in the spawned tasks never running and it is confusing to debug for new users.

@twmb

The global event loop should probably come with a timer because turn takes
a Duration, and that needs a timer to run, right?

The duration only indicates the max duration to block. This is passed through to epoll_wait (and the equivalent on other OSes).

But these sockets need to send events to register with epoll to the reactor,
which is the cross thread communication.

No, epoll ops happen on the same thread. epoll is Sync.
Re: go context, that is a separate feature and is similar to finagle's async task local variables (or whatever they call it).

I've made several updates to the RFC based on the feedback here, but due to a Github glitch, I need to put this in a new PR. In any case, here are the key changes:

The RFC now includes a fleshed-out API for customizing the default reactor, which can be used to prevent any automatic thread-spawning.

The timer APIs are moved out to a futures-timer crate, and by default spawn a dedicated timer thread (as per @carllerche's argument). We eventually plan to make this behavior customizable as well, but want to punt on that bit of design work for now.

The current_thread APIs are significantly tightened up, and in particular the panic-on-drop behavior has been removed. The main downside to this change is that, if you want to couple together a reactor and a single-threaded executor, you'll need to do this manually using FuturesUnordered. However, external crates (like tokio-core!) can provide this coupling for you.

Thank you for the great work on Tokio. This is my favourite rust crates system.
I agree with @alex. Please don't add a global event loop, or anything global.
I did some of async programming, first with Twisted and then with asyncio (Both python). I was also a contributor to the Twisted. The global event loop caused me lots of troubles.
(1) Almost every API I used had a hidden possibility to add an argument of loop=.... Each such API was a chance to shoot yourself in the foot. If you forgot to specify your own loop, the default loop will be used by default and nobody will tell you about it.  I remember one time it took me a few days to find the API that defaulted to the global loop.
As a concrete example, take a look at this pythonic API (asyncio):
asyncio.ensure_future(coro_or_future, *, loop=None)

From here.
This is the equivalent of spawn in rust Tokio. If you accidentally forget to specify loop=my_loop in your test case, you should expect days of debugging, searching for the problem.
 They just assume that you will want to use the default one. It could become very difficult to test your code against those kind of libraries.
One experience I had was testing asyncio python code that waits. I created a mock event loop that simulated the passage of time (Called asyncio time travel), because I couldn't afford having my tests wait a few minutes for a timeout. The author of a library I used decided to use the global event loop, and I couldn't replace it with my mock time travel loop. In the end I had to create a test environment that actually waits many minutes in order to run the tests.
(3)

there are many other environments (Go, erlang, node / libuv, ...) in which a global event loop has been successful.

Rust is not the same. Rust is a systems programming language. I like Rust because it is very explicit. There are no hidden stuff. When I write code in rust I don't want implicit global things to happen. If I want an event loop, I will create one.
I really liked the current rust Tokio way of creating a new loop and then putting your futures into it, and I prefer it every day over other magically global loops constructions.
I also think that having an explicit creation of an event loop follows the way of rust, rather than having a global construct that is created implicitly for you.
It is true that people could write their libraries to allow using the default global event loop, and also give an alternative API for handing over your custom loop, but people tend to take the easier path.
For me the hard parts about learning Tokio wasn't the event loop. The event loop code is usually just a few lines that you slap in the end, after you wrote all your futures.
The hard parts were finding out that mixing futures with references and lifetimes doesn't go very well, and understanding how to transform the types correctly, so that I won't get huge cryptic compile messages about mismatch in the error type between two futures.


Remove navigation block warning in programming page when navigating to add more programs

Often times I remove programs, or edit the lineup in the programming screen, then click 'add media' to add some more. If you don't save after altering the lineup, you get a nav blocker about unsaved changes. We should be able to keep a working copy of changes in local state and allow adding media w/o saving.

This is another bug blocked by https://github.com/TanStack/router/pull/1790 - we may just have to remove the navigation block completely.


Create nigerian.js

Based on Pan Nigerian Keyboard https://en.wikipedia.org/wiki/Pan-Nigerian_alphabet#Keyboard

Thanks a lot @bkmgit ! The Nigerian layout is now live as of version 1.15.36
Regards,
Francisco Hodge


import failure due to class-level txaio.make_logger()

Is it really necessary to instantiate the ApplicationSession logger at class level (see https://github.com/crossbario/autobahn-python/blob/master/autobahn/wamp/protocol.py#L277)?
It is causing import failure of autobahn.wamp.protocol (if txaio.use_twisted/txaio.use_asyncio has not been called yet at import time).

So what is the issue? You have to call txaio.use_twisted/use_asyncio before importing Autobahn stuff.

Do you mean that should be done everywhere any autobahn stuff is imported? It does not look like that is widely advertised in the docs. I took a look at a few examples and they don't do that either.
Or maybe I misunderstood?

This is a "best practice" WAMP client: https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/wamp/basic/client_using_apprunner.py

See also: http://txaio.readthedocs.io/en/latest/programming-guide.html#logging

@petri what is the import error you're seeing? To import the correct ApplicationSession class, the right txaio.use_{twisted,asyncio} method should already have been called.

I don't understand. Taking a look at several examples and running them, I see that invoking txaio.use_{twisted,asyncio} is definitely not always required - at all.

So you shouldn't be importing autobahn.protocol.ApplicationSession (it's a base class), but instead import from one of the "framework-specific" classes (i.e. autobahn.twisted.wamp.ApplicationSession or autobahn.twisted.asyncio.ApplicationSession) and then the right txaio.use_*() call should already have been made properly.

Ah, thanks, got it now.

@petri do you know which docs could have made this more-clear? I guess perhaps all of protocol should maybe be in a _protocol package instead to make it's "internal" nature more obvious?

I don't know. I don't remember actually using protocol directly, I just tracked the import error down there. Which happened when I was taking first steps writing a custom ApplicationRunner.


FR Real-time update while drawing, or pause to update composite render

When drawing, currently the display isn't updated until we let go of the button.

In this example, I am drawing a black box, under a font layer.
However, the display isn't updated as I drag  the box, it's instead obstructing the view of the font, which makes it difficult to align the box under the font.
Until I let go of the button, at which time it renders:

But this workflow is kind of poor. It would be nice if either:

A real-time update could happen as we work. or...
A pause while dragging for a second or two will update the display to give us a preview of what we're doing.

This is problematic because what we have to do now instead is use trial and error to line things up.

Try to figure out where to draw the box start, and hope it's correct.
Try to drag until we think it looks like it will cover what we want and end where we want.
When it's wrong, now undo, and repeat 1-3 until correct.

fixed.


SQL Tools Service component exited unexpectedly

Azure Data Studio Version: 1.6.0

Steps to Reproduce:

Open

I've just upgraded to Ubuntu 19.04

Hi @ewinterrms, thanks for reporting the issue. Could you Toggle the Developer Tools (Ctrl + Shift + I) and paste the error on the console?

I just ran into the same problem. I'm also on Ubuntu 19.04.

From Ubuntu 18.10 to Ubuntu 19.04 libssl1.0 has been replaced by libssl1.1 and it is nicely installed, so there should be no reason for this error.

Which makes this issue a duplicate of #5134

Thanks, Forage, I missed those dups, and installing libssl1.0.0 solved the problem for me:
wget http://archive.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu6_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu6_amd64.deb

Closing as a duplicate.  We'll look into the missing Ubuntu 19.04 dependencies using one of the other issues.


Pass warmup and counted iterations separately to return_results and use them in run_benchmarks.rb

Before this run_benchmarks.rb would fail if there were less than 15 iterations and also it could consider a different amount of warmup than the harness does (e.g. for harness-warmup).

Example failure:
ruby run_benchmarks.rb --harness test -e "yjit::ruby --yjit" fib
Running benchmark "fib" (1/1)
setarch x86_64 -R taskset -c 15 ruby --yjit -I harness-test benchmarks/fib.rb
RSS: 270.6MiB
Total time spent benchmarking: 0s

/home/eregon/code/yjit-bench/misc/stats.rb:15:in `mean': undefined method `sum' for nil:NilClass (NoMethodError)

    @data.sum(0.0) / @data.size
         ^^^^
	from run_benchmarks.rb:143:in `mean'
	from run_benchmarks.rb:467:in `block in <main>'
	from run_benchmarks.rb:455:in `each'
	from run_benchmarks.rb:455:in `<main>'

That's with a test harness to reproduce it easily:
require_relative "../harness/harness-common"

def run_benchmark(num_itrs_hint)
  return_results([0.2] * 5 + [0.1] * 5)
end

But it also hapenned most of the times for psych-load on 3.2 YJIT with harness-warmup (since harness-warmup requires 10 iterations at minimum but not more if it's already stable).

Definitely agree it shouldn't crash. While warmup is a property of the standard harness (though not all harnesses), right now reporting back on the benchmark settings is not. Which is one reason this is a little odd. Until recently, this JSON file didn't exist, so it's not 100% clear what should be in it.

Sorry, I'm only seeing this now.
I think it's essential to include warmup iterations in the resulting JSON, otherwise we definitely lose this data and can't assess if it warmed up properly from looking at the result files.
I think the JSON file produced by run_benchmarks.rb should just put together the various JSON files for each benchmark run, and nothing more.
We're already basically there, but there is duplication since https://github.com/Shopify/yjit-bench/pull/228#issuecomment-1529731670.
I can address that in this PR too, otherwise it will very likely conflict.
I can try to finish this PR soon.
@maximecb I would like clear directions though, can you confirm that from https://github.com/Shopify/yjit-bench/pull/229#discussion_r1180704737 we should have an array of warmup iterations and an array of timing iterations?
And that we then represent it like that in JSON files too?

PR updated to passed warmup and counted iterations to return_results.
And the resulting JSON file is now just metadata + raw_data, so there is no duplication of iterations anymore.
Here is a run to show it:
$ WARMUP_ITRS=2 MIN_BENCH_ITRS=3 MIN_BENCH_TIME=0 ruby run_benchmarks.rb --rss fib nbody
Running benchmark "fib" (1/2)
setarch x86_64 -R taskset -c 15 /home/eregon/.rubies/ruby-3.2.1/bin/ruby -I harness /home/eregon/code/yjit-bench/benchmarks/fib.rb
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
itr #1: 190ms
itr #2: 189ms
itr #3: 189ms
itr #4: 189ms
itr #5: 189ms
RSS: 16.2MiB
Average of last 3, non-warmup iters: 189ms
Running benchmark "nbody" (2/2)
setarch x86_64 -R taskset -c 15 /home/eregon/.rubies/ruby-3.2.1/bin/ruby -I harness /home/eregon/code/yjit-bench/benchmarks/nbody/benchmark.rb
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
itr #1: 122ms
itr #2: 121ms
itr #3: 121ms
itr #4: 121ms
itr #5: 121ms
RSS: 16.2MiB
Average of last 3, non-warmup iters: 121ms
Running benchmark "fib" (1/2)
setarch x86_64 -R taskset -c 15 /home/eregon/.rubies/ruby-3.2.1/bin/ruby --yjit -I harness /home/eregon/code/yjit-bench/benchmarks/fib.rb
ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]
itr #1: 51ms
itr #2: 50ms
itr #3: 51ms
itr #4: 51ms
itr #5: 51ms
RSS: 16.6MiB
Average of last 3, non-warmup iters: 51ms
Running benchmark "nbody" (2/2)
setarch x86_64 -R taskset -c 15 /home/eregon/.rubies/ruby-3.2.1/bin/ruby --yjit -I harness /home/eregon/code/yjit-bench/benchmarks/nbody/benchmark.rb
ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]
itr #1: 53ms
itr #2: 51ms
itr #3: 50ms
itr #4: 50ms
itr #5: 50ms
RSS: 16.8MiB
Average of last 3, non-warmup iters: 50ms
Total time spent benchmarking: 2s

interp: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]
yjit: ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]

-----  -----------  ----------  ---------  ---------  ----------  ---------  ------------  -----------
bench  interp (ms)  stddev (%)  RSS (MiB)  yjit (ms)  stddev (%)  RSS (MiB)  yjit 1st itr  interp/yjit
nbody  121.4        0.2         16.2       51.0       0.0         16.8       2.28          2.38
fib    189.8        0.0         16.2       51.2       0.1         16.6       3.73          3.71
-----  -----------  ----------  ---------  ---------  ----------  ---------  ------------  -----------
Legend:
- yjit 1st itr: ratio of interp/yjit time for the first benchmarking iteration.
- interp/yjit: ratio of interp/yjit time. Higher is better for yjit. Above 1 represents a speedup.

Output:
./data/output_068.csv

And the JSON file is: jq < ./data/output_068.json:
{
  "metadata": {
    "interp": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]",
    "yjit": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]"
  },
  "raw_data": {
    "interp": {
      "fib": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]",
        "warmup": [
          0.1903009080015181,
          0.18946522600163007
        ],
        "counted": [
          0.18986358199981623,
          0.1898057409998728,
          0.18981377100135433
        ],
        "rss": 16945152
      },
      "nbody": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]",
        "warmup": [
          0.12290628900154843,
          0.12113980199865182
        ],
        "counted": [
          0.1217336610025086,
          0.1211329809993913,
          0.12123488300130703
        ],
        "rss": 16969728
      }
    },
    "yjit": {
      "fib": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]",
        "warmup": [
          0.05104860099891084,
          0.050835276997531764
        ],
        "counted": [
          0.051196702999732224,
          0.05116483199890354,
          0.05126774399832357
        ],
        "rss": 17444864
      },
      "nbody": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]",
        "warmup": [
          0.05398684499959927,
          0.0510213500019745
        ],
        "counted": [
          0.05099459900156944,
          0.05096003899961943,
          0.05094057899987092
        ],
        "rss": 17661952
      }
    }
  }
}

I did the rename from counted to bench.
Here is the JSON file as an example:
{
  "metadata": {
    "interp": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]",
    "yjit": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]"
  },
  "raw_data": {
    "interp": {
      "fib": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]",
        "warmup": [
          0.1906929040005707,
          0.19077419499990356
        ],
        "bench": [
          0.19018388599943137,
          0.19044638000013947,
          0.1907679249998182
        ],
        "rss": 16941056
      },
      "nbody": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux]",
        "warmup": [
          0.12172503800047707,
          0.12082949400064535
        ],
        "bench": [
          0.12125646000004053,
          0.12175059700075508,
          0.12236642700008815
        ],
        "rss": 16969728
      }
    },
    "yjit": {
      "fib": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]",
        "warmup": [
          0.05064881900034379,
          0.05044320599972707
        ],
        "bench": [
          0.05039404499984812,
          0.05043602500063571,
          0.05042806599976757
        ],
        "rss": 17444864
      },
      "nbody": {
        "RUBY_DESCRIPTION": "ruby 3.2.1 (2023-02-08 revision 31819e82c8) +YJIT [x86_64-linux]",
        "warmup": [
          0.05591815899970243,
          0.053505412000049546
        ],
        "bench": [
          0.05329649900068034,
          0.05348349199994118,
          0.05350072200053546
        ],
        "rss": 17661952
      }
    }
  }
}

Thanks for this contribution Benoit :)


PROXY configuration unclear

Proxy configuration documentation is currently unclear and incomplete in webapp.

Notify: @afaulconbridge
I tried to propose some improvements here: https://github.com/opentargets/webapp/pull/303/files#diff-04c6e90faac2675aa89e2176d2eec7d8

One question I had regarding the PROXY config: are only certain domains allowed? I tried using the proxy prefix to fetch some data from an internal server and this failed.

Correct. You would need to add them to nginx_conf/nginx.template

Correct. The webapp /proxy should redirect to the proxy that is (as of 19.02) built into the rest api, which is where the additional domains would need to be added. https://github.com/opentargets/rest_api/tree/master/docker

aha! Thanks! Should we document this in webapp?

I think the full documentation should be in rest_api but yes it should also be mentioned in the webapp. Do you want to update your existing PR a bit?

@afaulconbridge ok, yes, I will update https://github.com/opentargets/webapp/pull/303 a bit.

@afaulconbridge updated the PR.

@afaulconbridge I also made this one https://github.com/opentargets/rest_api/pull/187

@afaulconbridge I added this one as well to make the configuration easier at runtime: https://github.com/opentargets/rest_api/pull/188

These PRs have been merged now (303 is approved but pending final merge), so I think this is complete? What do you think @pieterlukasse ?

excellent. Thanks @afaulconbridge 👍


Expose all labels in config.yaml

Please consider exposing all used labels in the config.yaml, so one can build a complete german version for example.
I noticed these yet to be done:

4 SERVING
1 HOUR

Those aren't preset labels – they're spelled out in the recipe metadata, e.g., here. That enables using different terms depending on what's appropriate for the recipe in question, e.g. the size of the required springform for a cake, or "minutes" for a quick recipe.
Just write 'em in German. 😉

That was totally my mistake, sorry for wasting your time.
I think the footer "UPDATED ON" would nevertheless fit the label collection 😀

True. I'll add that to my list of changes to make this weekend!


Investigate pattern day trading requirements and configuration

Description

Instead of being purely long-only or avoiding PDT designation, we want the flexibility to move in and out of positions rapidly.
Specifics

[ ] review PDT requirements
[ ] review/plan out model updates to utilize PDT designation

[ ] this will be a separate series of issues to implement

[ ] configure account/balance to meet requirements

Closing to consolidate into separate issues.


support GPU?

Although I have not enough information about the intent of this issue, I guessed you might be curious about one of the followings:

(a) Using GPU in objective functions to accelerate your ML library:

There is no limitation to use GPU for this purpose.
For instructions on how to use the GPU with the library you are using, please follow the documentation of the library.
cf. How can I use two GPUs for evaluating two trials simultaneously?

(b) To accelerate Optuna's optimization speed by using GPU:

Optuna doesn't have computations that can be speeded up by GPU.
Therefore, we aren't planning to use GPU for Optuna itself.

If your intent differs from the above, please let me know the detail.

Closing the issue. Please reopen this if you still have any concern.


Use fixed positioning for pagination controls

Also fix issue with double scrollbars on the right for explorer views.
https://www.pivotaltracker.com/story/show/143656745
@miq-bot add_label fine/yes, bug

@ManageIQ/core-ux does that spacing look good to you?
@miq-bot add_label ux/review

Fine backport details:
$ git log -1
commit 2a51091beb899d04a055a14056ea60f9c7887bc8
Author: Chris Kacerguis<EMAIL_ADDRESS>Date:   Sat Apr 22 11:54:29 2017 -0500

    Merge pull request #698 from jjlangholtz/position-pagination-controls-fixed

    Use fixed positioning for pagination controls
    (cherry picked from commit 9b52094fc574c9dae539090cca6f51804acd3b05)


[chip, dv] False error of alert-ping-timeout

The alert monitor does not recognize the response to a ping.
The 1st issue:
The alerts monitor, used in the chip level env., has an issue that causes false errors of “ping timeout”:
The monitor …/opentitan/hw/dv/sv/alert_esc_agent/alert_monitor.sv
has these parallel threads in a fork in task “ping_thread()”:
begin : wait_ping_timeout
repeat (cfg.ping_timeout_cycle - 1) @(cfg.vif.monitor_cb);
req.ping_timeout = 1'b1;
end
begin : wait_ping_handshake
// In case there is an alert happened before ping.
if (alert_p != 0) wait_alert_complete();
// TODO: could use "wait_alert()" but right now scb needs to be cycle accurate to
// predict esc_cnt.
while (cfg.vif.alert_tx_final.alert_p !== 1'b1) @(cfg.vif.monitor_cb);
req.alert_handshake_sta = AlertReceived;
wait_ack();
req.alert_handshake_sta = AlertAckReceived;
under_ping_rsp = 0;
end
Thread wait_ping_handshake (1) Is supposed to detect the alert ping  handshake.
Thread wait_ping_timeout (2) counts a timeout interval.
Thread (1) does not work well and fails to detect the handshake.
so thread(2) terminates the fork and an item with “ping timeout” is sent to the scoreboard.
The scoreboard …/opentitan/hw/dv/sv/cip_lib/cip_base_scoreboard.sv
gets the item and reports:
end else if (item.ping_timeout && cfg.en_scb_ping_chk == 1) begin
uvm_error(gfn, $sformatf("alert %s has unexpected timeout error", alert_name))
As workaround, in test "chip_sw_power_idle_load", we set cfg.en_scb_ping_chk=0 to disable this error.
The 2nd issue:
In addition, the timeout is fixed at …/opentitan/hw/dv/sv/alert_esc_agent/alert_esc_agent_cfg.sv
int unsigned ping_timeout_cycle = 32;
Ignoring the actual H/W settings.

Thank you for reporting this issue!
Currently there is a known issue for this alert_esc_agent, as this is mainly used for block level testitng.
In chip level, we mainly use it to make sure there is no fatal alert firing continuously at the end of the test.
For now, could you try adding a switch to disable this check?
https://github.com/lowRISC/opentitan/blob/master/hw/top_earlgrey/dv/chip_sim_cfg.hjson#L717
      run_opts: ["+en_scb_ping_chk=0"]

I will fix it post-M2 ;)

Regarding "Currently there is a known issue for this alert_esc_agent": is this issue already reported in GitHub?

Hi Yehuda,
I do not think so. Sorry about that. Could you keep this open until I fix it?

The test chip_sw_power_idle_load mentioned above failed in the nightly with the following error:
  UVM_FATAL @ 14551.395600 us: (chip_sw_power_idle_load_vseq.sv:29) [uvm_test_top.env.virtual_sequencer.chip_sw_power_idle_load_vseq] timeout waiting for S/W sync GPIO2
  UVM_INFO @ 14551.395600 us: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
  --- UVM Report catcher Summary ---

Is this issue intented to fix it, or should we open a new one?

@engdoreis I've created a new issue to track the now failing chip_sw_power_idle_load issue at https://github.com/lowRISC/opentitan/issues/16533

This alert issue is fixed here: https://github.com/lowRISC/opentitan/pull/16663


BEP process: source and target data requirement?

Following up on a conversation with @neurolabusc at the steering group meeting just now and related to https://github.com/bids-standard/bids-specification/issues/1350. This page: https://github.com/bids-standard/bids-website/blob/gh-pages/_pages/bep_guide.md needs be edited to better describe the need for complete source and target datasets -- across different vendors -- that describe how conversion should occur. This could also describe how interaction with tool-builders, with instrument vendors, and with the dicom working group should proceed, so that the implementation of conversion into standard-compatible data can be consistent with the implementation, and with the existing dicom standard, where such exists.

I have a feeling that people will lament us adding this as a hard requirement to the BEP process, but if we only suggest it then it's likely not be be followed.  Happy to make it an actual requirement instead of a suggestion if we don't have to rely on an amendment.

You know what, we just went ahead and did it.


Licence needed

Another thing, I don't see a LICENCE file in the root of your repository, which means this repo is under exclusive copyright and other contributions are illegal. Please put a fitting licence (I would use GNU GPL v3.0) on this repo. See here for help picking one. ChooseALicence's SSL certificate seems broken, follow the instructions in your browser to bypass the security warning.

I already had an ISC license in the README.md but I should've probably added the LICENSE.md file, I've now switched to a GNU GPL v3.0 and added the LICENSE.md file!


magic exceptions

if I want to log in from the form, I get magic exceptions. WTF ?!

There is no bugs at my Intellij IDEA D:

I will show you it tomorrow, before sprint


add gcc icon

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

[ ] Filename in the lowercase format
[ ] Image format: png
[ ] Image size: 256 by 256 px

@LyonNee
Also, you can use these graphics to say that your ERC20 token fully compatible with Trust Wallet (https://trustwalletapp.com/logo-assets). Tokens will show up automatically once the user receives them.
Feel free to share this on social media and tag Trust Wallet:

Twitter: @trustwalletapp

Facebook: @trustwalletapp


feat(csharp/src/Drivers): introduce Interop.FlightSql driver

Introduces the Interop.FlightSql driver to use the FlightSQL Go driver from C#
Adds support for testing against multiple FlightSQL environments simultaneously in the configuration (something we may want to carry forward to other projects)
Has a first set of test sample data specific to Dremio, DuckDB and SQLite using https://github.com/voltrondata/SQLFlite as the server(s).
Adds support for the IntervalType in a generic capacity

Is there any way to make the process of creating something to load the driver and wrap it more generic so that potential future drivers don't require as much boiler plate as this appears to?
Otherwise, this looks pretty fine to me but I'm not very experienced with C#

Like a base class that https://github.com/apache/arrow-adbc/blob/7fc08cce7404b000c400e00f208ded6dc80f6bb8/csharp/src/Drivers/Interop/FlightSql/FlightSqlDriverLoader.cs could implement?

I do agree there's some boilerplate that might be good to factor out eventually, if we're going to have multiple packages like this

Is there any way to make the process of creating something to load the driver and wrap it more generic so that potential future drivers don't require as much boiler plate as this appears to?
Otherwise, this looks pretty fine to me but I'm not very experienced with C#

I added this in a recent push.

I also verified this against Denodo https://community.denodo.com/docs/html/browse/9.1/en/vdp/developer/access_through_flight_sql/access_through_flight_sql#current-restrictions

@davidhcoe Can you please resolve the build conflicts?

@davidhcoe Can you please resolve the build conflicts?

ready now


Including FSSSignalDiscovered event to list of allowed events to send over EDDN

It will allow EDDN listeners to:

Track FCs movements
Track combat zones
Track Resources extraction points (not quite useful since body info isn't included)
Track NonHuman signals
Track high grade emissions signals
Track installations
Match FCs IDs and names

In order to decide which fields have to be removed I analyzed all keys in all my own journals record for FSSSignalDiscovered event, here is the list with some comments:
SignalName
TimeRemaining - on USS, I don't think it can be useful for anybody but I also don't think it is private information
timestamp
SpawningFaction_Localised - candidate to removing
SignalName_Localised - candidate to removing
IsStation
USSType
USSType_Localised - candidate to removing
SpawningState
SpawningFaction
event
SpawningState_Localised - candidate to removing
ThreatLevel
SystemAddress

There is also an event type that can be considered as personal information, it is missions related signals
{ "timestamp":"2021-10-27T20:33:30Z", "event":"FSSSignalDiscovered", "SystemAddress":3107509342922, "SignalName":"$USS; ", "USSType":"$USS_Type_MissionTarget;", "USSType_Localised":"Mission target", "SpawningState":"$FactionState_None;", "SpawningState_Localised":"None", "SpawningFaction":"$faction_none;", "SpawningFaction_Localised":"None", "ThreatLevel":4 }

Also please note that every jump for single player can generate more than 100 FSSSignalDiscovered events.
Additional values:
horizons
odyssey
StarSystem
StarPos
With appropriate values as in journal-v1.0.json schema.

Localized names are already typically scrubbed from the EDDN messages so I see nothing controversial there.
I see limited value in reporting USS, since the time wherein each signal exists is quite limited and the most useful USS signals (HGE) can already be readily predicted from faction states and allegiances. Omitting USS would also remove the $USS_Type_MissionTarget; USS type event identified by the OP as personal information.

There is an issue with some FSSSignalDiscovered events being written to the Journal before a jump has actually been made/completed, certainly before the matching FSDJump or CarrierJump event (maybe even before Location on login?).
Now, we could just leave this event as only having SystemAddress from the actual journal event. The point of those augmentations is for listeners to get 'full' data on a system they've not seen before without them needing to cross-check against data they hold.  But this is not 100% necessary if it's going to be problematic.
If we insist on SystemName and StarPos then senders would need to cross-check that SystemAddress with a 'location' event before adding those augmentations.  If it doesn't match then they can either:

Just not send this event (but this loses data).
Not include the augmentations in this mesage when sent.

Localized names are already typically scrubbed from the EDDN messages, I see nothing controversial there.

Agreed.

I see limited value in reporting USS with TimeRemaining, since the time wherein each signal exists is quite limited and the most useful of these USS signals (HGE) can already be readily predicted from faction states and allegiances.

Yes, no point to including this.

I would also agree with removing USS like the $USS_Type_MissionTarget; USS type event identified by the OP as personal information.

Yup, personal, and not really useful to anyone else.

Combat zones (except perhaps for nonhuman combat zones) follow naturally from faction states as well - there is limited value to be gained from reporting individual combat zones to EDDN.

Knowing how many CZ there are, and if the data is there, of what type/size, can be useful, even if you don't yet know exactly where they are.  I'd leave this up to listeners to decide on the usefulness.

Without body information, is resource extraction data still useful?

Again, it might be useful, so I see no reason to not include it.
Someone has mentioned that perhaps some sort of batching of these events into a single message might be useful.  Timing that post-jump might be tricky, but should be considered.

Yes, the FSSSignalDiscovered  can happen even before Location event at the startup, so to avoid complications (and possible incorrect values) stuff like star system coord and name I suggest to have these properties as SHOULD rather than MUST.
The batching is a MUST, to not compromise the server (I can clearly imagine that for highly populated system congested with fleet carriers, with just a few senders at the same moment the server will need to handle hundreds of HTTP requests at once instead of just a couple of requests. I guess it will be better even for the users as their machines won't be making 100+ HTTP requests at the same time.
It can follow an easy mechanics in journal parsing:

If the event is FSSSignalDiscovered, store it to the temporal list and proceed to next event.
If the next event is also FSSSignalDiscovered, repeat 1.
If the next event is any other or there is no other event for more than 10 seconds, send the temporal list in a single message to EDDN.
???
Profit! ;)

Something just mentioned on Discord is that currently Canonn gain the names (rather than just call signs) of Fleet Carriers from FSSSignalDiscovered events.  Currently EDDB etc only get data with thw call sign, giving no way to map them to the names.
The format is a little awkward though, as you get both the name and the call sign in the same field:
{ "timestamp":"2021-10-18T08:42:23Z", "event":"FSSSignalDiscovered", "SystemAddress":3240309557611, "SignalName":"WARD'S OLOGIES X3F-N5Z", "IsStation":true }

It's easy to parse though. I certainly recommend for the specs that senders MUST NOT alter the SignalName any way.

I also think messages should be transmitted as is with minimum changes. Receivers might want to implement some special logic to parse it.

Confirming those 14 fields are all I have in my journals
Possible formats:

USS
```
{
  "timestamp": "2021-01-15T02:54:18Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>859,
  "SignalName": "$USS_HighGradeEmissions;",
  "SignalName_Localised": "Unidentified signal source",
  "USSType": "$USS_Type_ValuableSalvage;",
  "USSType_Localised": "Encoded emissions",
  "SpawningState": "",
  "SpawningFaction": "Free Marlinists of Carinae",
  "ThreatLevel": 0,
  "TimeRemaining": 718.508789
}
```

Station/FC
```
{
  "timestamp": "2021-10-30T17:43:06Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>6,
  "SignalName": "BUYING PAINITE 230K  H8N-TXQ",
  "IsStation": true
}
```
```
{
  "timestamp": "2021-10-30T12:40:33Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>921,
  "SignalName": "Al-Jazari Orbital",
  "IsStation": true
}
```

CZ/RES/etc
```{
  "timestamp": "2021-10-29T11:56:53Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>514,
  "SignalName": "$Warzone_PointRace_High:#index=1;",
  "SignalName_Localised": "Conflict Zone [High Intensity]"
}```
Full list of `$` signal names I've encountered. I've noted the indexes I've seen, but there *could* be larger
```
$Aftermath_Large:#index=1; # Goes from 1-2
$AttackAftermath;
$FIXED_EVENT_CAPSHIP;
$FIXED_EVENT_CHECKPOINT;
$FIXED_EVENT_CONVOY;
$FIXED_EVENT_DEBRIS;
$FIXED_EVENT_DISTRIBUTIONCENTRE;
$FIXED_EVENT_HIGHTHREATSCENARIO_T5;
$FIXED_EVENT_HIGHTHREATSCENARIO_T6;
$FIXED_EVENT_HIGHTHREATSCENARIO_T7;
$Fixed_Event_Life_Cloud;
$Fixed_Event_Life_Ring;
$Gro_controlScenarioTitle;
$ListeningPost:#index=1;
$MULTIPLAYER_SCENARIO14_TITLE;
$MULTIPLAYER_SCENARIO42_TITLE;
$MULTIPLAYER_SCENARIO77_TITLE;
$MULTIPLAYER_SCENARIO78_TITLE;
$MULTIPLAYER_SCENARIO79_TITLE;
$MULTIPLAYER_SCENARIO80_TITLE;
$MULTIPLAYER_SCENARIO81_TITLE;
$NumberStation:#index=1;
$USS;
$USS_CeremonialComms;
$USS_ConvoyDispersalPattern;
$USS_DegradedEmissions;
$USS_DistressCall;
$USS_HighGradeEmissions;
$USS_NonHumanSignalSource;
$USS_SalvageHaulageWreckage;
$USS_Type_Aftermath;
$USS_Type_Convoy;
$USS_Type_DistressSignal;
$USS_Type_NonHuman; $USS_ThreatLevel:#threatLevel=4; # Goes from 4-9
$USS_Type_WeaponsFire;
$USS_WeaponsFire;
$Warzone_PointRace_High:#index=1; # Goes from 1-3
$Warzone_PointRace_Low:#index=1; # Goes from 1-10
$Warzone_PointRace_Med:#index=1; # Goes from 1-4
```

Installations/Beacons/Outposts(!)
```
{
  "timestamp": "2021-10-26T21:13:26Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>92,
  "SignalName": "Enlightened Mathematic Analysis"
}
{
  "timestamp": "2021-10-29T12:02:34Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>921,
  "SignalName": "SVA-046 Dionysus-class Cropper"
}
{
  "timestamp": "2021-10-26T20:25:20Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>9665,
  "SignalName": "What is Interpol?"
}
{
  "timestamp": "2021-10-26T21:35:04Z",
  "event": "FSSSignalDiscovered",
  "SystemAddress":<PHONE_NUMBER>811,
  "SignalName": "Sekelj Port"
}
```

Out of curiousity, have you got any with IsStation = False?

Nope, none

One valuable info that can be obtained from this schema would be Nav Beacon status.
{ "timestamp":"2021-11-12T05:16:07Z", "event":"FSSSignalDiscovered", "SystemAddress":147949848947, "SignalName":"$MULTIPLAYER_SCENARIO42_TITLE;", "SignalName_Localised":"Nav Beacon" }

{ "timestamp":"2021-11-12T05:15:10Z", "event":"FSSSignalDiscovered", "SystemAddress":3996240546163, "SignalName":"$MULTIPLAYER_SCENARIO80_TITLE;", "SignalName_Localised":"Compromised Navigation Beacon" }

For anyone following this and wondering if it's been forgotten, it hasn't.
However I do have some concerns about the possible flood of data adding this would cause, so there are some caveats.

We need a sender implementation - if anyone wants to beat me to a PR against ED Market Connector, please do.  The purpose of this is to actually test it in action to ensure that we identify any issues with things like batching the events for arrival in a new system into just a single message.  During this testing phase it should only attempt sending to beta.eddn.edcd.io (which isn't always up and working).
That will match up with a beta implementation of the schema running on beta.eddn.edcd.io.
We then need to at least get an idea of the message and data rate when e.g. a commander flies around the populated (more signals from things like FCs) bubble for an hour.  We'd then combine this with some guesstimate of how many Cmdrs might do that over the course of a week to get an idea of any extra load it would cause on both the EDDN Gateway and listeners.
Some listeners may well not want this data at all.  Ideally they would use ZeroMQ features to filter it out.  However the version of zeromq that is supported by the legacy version we're currently using for all of EDDN doesn't perform server-side subscription filtering, i.e. the data would get sent to listeners anyway, even if they then subscription-filter it on their end.  Thus:

We would need to complete the migration to Python3 and verify that server-side subscription filtering works with the version that uses.
Verify that we are definitely setting ZeroMQ topic correctly per message so that this actually functions.

So, apart from anything else this is now dependent on first completing the migration to Python3.  If no-one has the ability and time to assist me in verifying that https://github.com/EDCD/EDDN/pull/155 doesn't break any functionality or introduce regressions, then this is further dependent on implementing as many automated unit and functional tests as possible.  That's a whole project in itself.

I parsed all my journals. Of hours that have at least one FSSSignalDiscovered:
Top 10:
Hour FSSSignalDiscoveredCount
2022-03-26T18 3963
2022-03-25T18 3019
2021-09-20T12 2780
2022-03-25T17 2376
2022-06-11T23 2360
2022-06-11T21 1834
2022-03-25T19 1729
2021-09-20T14 1672
2022-03-25T00 1613
2022-01-08T14 1534
Median: 64
Average: 132

The new schema has been live for many weeks now without anyone bringing up an issue, so closing this.


.gitignore ignores node_modules folder, but causes problem when deleting Libraries

Currently .gitignore ignores the node_modules folder, this caused problem for me when I deleted React.xcodeproj and tried to get it back.  What happens is that the .xcodeproj file is gone and you can't see it in the Libraries folder in Xcode, build fails, but when you go back to the branch before you deleted this library, you can see React.xcodeproj in red letters in Xcode, this seems to imply that Xcode can't find it, but build succeeds...
Of course, after you deleted React.xcodeproj, the file is gone in the node_modules folder for good, changing branch won't get it back
After you delete everything in Libraries

Going back to the older branch, you see the following:

Would it be a good idea to not ignore node_modules in the .gitignore file?  I am not completely sure about the upside and downside of this decision, so was just curious...
Thanks!

@kevindeleon not ignoring node_modules means that all the changes in that directory (which may be massive) and the code not written by you go to your version control. Also, some node modules are compiled on the system, and the binaries won't be cross platform.

@satya164 thanks!  That makes sense, I found a resolution which is delete the node_modules folder, type npm install into command line in the React Native project folder, then the .xcodeproj files will show up again, I just have to remove all the old references one by one and add in the new .xcodeproj files one by one


docs: state management

docs about state management
more helpful error message when trying to run a SvelteKit store on the server

closes #8524
The docs are WIP, I'd like to add more stuff to it.

maybe move the explanation about cookies from Loading Data in there?
touch on invalidation as a method to handle state
in general a bit more indepth about the global gotchas, maybe more code examples?
other thoughts?

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Agree that we should clarify why you can't subscribe to app stores outside component initialization (though the improved error messages are the real win here), but I do think we should be careful about how far into the weeds we go. For example the 'types of state' section feels a bit intimidating ("I need to understand all these different kinds of things? I just wanted to load some data") and yet is arguably incomplete (it doesn't mention stores, or how API/backend relates to page data).
There's a cost to adding documentation — it makes it harder for a newcomer to RTFM — and so we need to be sure that we're solving a real problem. #8524 is painfully vague about our docs' shortcomings, to the point that I'm not sure any PR could claim to close it.

I agree the docs in this PR are too broad. It seems like the thing that people trip over a lot is how to use stores with SSR. I think we could cover that much more concisely. Perhaps we could document the pattern Rich recommended in https://github.com/sveltejs/kit/issues/7105#issuecomment-1305856190 in the load docs or something

I'm good with removing the broader section, it was intended as a start to a more full-fledged docs page - imagine about twice the content there is now in the end. But I don't have a good vision of how it all could look like.
We already have a short section on stores and SSR in the load docs, which noone reads because noone thinks that it's hidden in there. I think a general "State Management" page makes sense since it's a widely used term so people are far more likely to click on that to see how things are done "the SvelteKit way".

Perhaps the docs should simple focus on the "API" instead.
And in addition you make a guides segment that goes a bit deeper in certain parts like state management.
NextJS has for example a more in detail section on how to make forms https://nextjs.org/docs/guides/building-forms
Remix also has a "Guides" section in their docs that cover things like data loading in more detail.

I update the doc to remove that "types of state" prelude and added a section on form interaction instead. It has reminiscents of a trouble shooting or "do it this way instead" which I think is a good addition.

I was debating this myself, there's duplication to the form actions section, but if you browse the docs just from looking at the titles, you may end up here searching for the best way to do this. It's a little like the error docs which also contain references to various other places in the docs.

I moved most of the details around form actions to its respective docs page, but kept a reference to it so it's more discoverable. I also added a short URL section.

#9239


legendary actions not parsing correctly

Divine strike legendary action did no parse correctly.
Also a minor issue, spells do not have links (but that may be by design, idk).
Another minor issue, yesterday I made a monk that had 18 dex(+4) but the stat block used a lower AC.
God
Colossal deity, unaligned
Armor Class 22 (divine armor)
Hit Points 605 (70d12 + 150)
Speed 40 ft., fly 120 ft. (hover), swim 60 ft.
STR DEX CON INT WIS CHA
30 (+10) 18 (+4) 22 (+6) 12 (+1) 20 (+5) 18 (+4)
Saving Throws CON +15, WIS +12 (These should always be higher than attribute bonuses)
Skills Perception +12, Religion +9
Damage Resistances Acid, Lightning, Force, Radiant
Damage Immunities Necrotic
Condition Immunities Blinded, Charmed, Deafened, Frightened, Grappled, Incapacitated, Paralyzed, Petrified, Prone, Restrained, Stunned, Unconscious
Senses Truesight 120 ft., passive Perception 22
Languages All
Challenge 30 (155,000 XP)
Divine Presence. All creatures within 60 feet of the God have disadvantage on saving throws against spells and magical effects.
Godly Spellcasting. The God can cast a variety of powerful spells from all spellcasting classes. It uses its Wisdom as the spellcasting ability (spell save DC 20, +12 to hit with spell attacks). It can cast the following spells as 9th-level spells, and does not require material components to cast them: Banishment, Heal, Meteor Swarm, True Resurrection
Legendary Resistance (3/Day). If the God fails a saving throw, it can choose to succeed instead.
Actions
Multiattack. The God makes two attacks with Divine Smite and one attack with Divine Wrath.
Divine Smite. Melee Weapon Attack: +12 to hit, reach 10 ft., one target. Hit: 84 (12d12 + 6) radiant damage.
Divine Wrath. Ranged Spell Attack: +12 to hit, range 120 ft., one target. Hit: 90 (13d12 + 6) force damage. The creature must make a DC 19 Constitution saving throw or become paralyzed for 1 minute.
Divine Fury. Line of Divine Energy (60 ft. long, 5 ft. wide). Each creature in the area must make a DC 19 Dexterity saving throw, taking 156 (24d12) radiant damage on a failed save, or half as much damage on a successful one.
Legendary Actions
Divine Strike (Costs 2 Actions). Melee Weapon Attack: +12 to hit, reach 10 ft., one target. Hit: 65 (10d10 + 10) slashing damage.
Divine Blessing (Costs 1 Action). DON'T DEAL DAMAGE WITH THIS ACTION. The God bestows a blessing upon an ally within 60 feet, granting them advantage on their next saving throw.
Divine Nova (Costs 3 Actions). The God releases a burst of divine energy in a 30-foot radius. Each creature in that area must make a DC 19 Constitution saving throw, taking 85 (13d12) radiant damage on a failed save, or half as much damage on a successful one. In addition, all creatures of the God's choice that fail the saving throw are stunned for 1 minute.

Version 1.68 should fix Divine Smite not showing up. The issue with the spells is because this statblock doesn't follow the standard formatting for spells. It should be something like...
Spellcasting. The lich is an 18th-level spellcaster. Its spellcasting ability is Intelligence (spell save DC 20, +12 to hit with spell attacks). The lich has the following wizard spells prepared:
Cantrips (at will): mage hand, prestidigitation, ray of frost
1st level (4 slots): detect magic, magic missile, shield, thunderwave
2nd level (3 slots): acid arrow, detect thoughts, invisibility, mirror image
3rd level (3 slots): animate dead, counterspell, dispel, magic, fireball
or...
Innate Spellcasting. The lamia’s innate spellcasting ability is Charisma (spell save DC 13). It can innately cast the following spells, requiring no material components.
At will: disguise self (any humanoid form), major image
3/day each: charm person, mirror image, scrying, suggestion
1/day: geas
If you want to open a new issue for the Monk I can look into it. I need the text of the statblock though. Without it there's no way to know why it wasn't using the right AC.


Utils issue on Comic_Generation.ipynb notebook

This code from the notebook gives errors.
%load_ext autoreload
%autoreload 2
import gradio as gr
import numpy as np
import torch
import requests
import random
import os
import sys
import pickle
from PIL import Image
from tqdm.auto import tqdm
from datetime import datetime
from utils.gradio_utils import is_torch2_available
if is_torch2_available():
from utils.gradio_utils import
AttnProcessor2_0 as AttnProcessor
else:
from utils.gradio_utils  import AttnProcessor
import diffusers
from diffusers import StableDiffusionXLPipeline
from diffusers import DDIMScheduler
import torch.nn.functional as F
from utils.gradio_utils import cal_attn_mask_xl
import copy
import os
from diffusers.utils import load_image
from utils.utils import get_comic
from utils.style_template import styles
ModuleNotFoundError                       Traceback (most recent call last)
 in <cell line: 14>()
12 from tqdm.auto import tqdm
13 from datetime import datetime
---> 14 from utils.gradio_utils import is_torch2_available
15 if is_torch2_available():
16     from utils.gradio_utils import \
ModuleNotFoundError: No module named 'utils.gradio_utils'

The "gradio_utils.py" file is in the utils folder of StoryDiffusion

hey, you probably did not clone the repo. As Malik as mentioned, you need to clone the repo first and then run the colab file. The gradio_utils.py is a part of the utils folder that you will have only if you clone the repo.
Hopefully this helps!


Can not get User structure for some users

When I receive a greeting from a new user, most of them can get the user structure by: Users.TryGetValue(peerUser.user_id, out var user),
but some new users cannot get the user structure, I try use
var inputPeer = new InputUserFromMessage
{
    user_id = unm.message.Peer.ID,
    peer = new InputPeerUser(unm.message.Peer.ID, user.access_hash),
    msg_id = unm.message.ID
};

But since I can't get the user structure, I can't get user's access_hash, I try use 0 repalce, but can not send message to this user by await _client.SendMessageAsync(inputPeer.peer, "hello").
How should I respond to users like this?
I can't add them to my contacts with _client.Contacts_AddContact(...) too, but I can add them with a manual click on the telegram client.

that's not a Github issue
see https://stackoverflow.com/a/71058797/3365403 and https://wiz0u.github.io/WTelegramClient/EXAMPLES.html#get-chat-and-user-info-from-a-message


Added instagram connections

Post processing closes GH-21:
Classifier, typescript interface and random data generator.
Svelte component closes GH-22

Also added a post processing function to reformat the dates.
Svelte components can be reused for other visualisations


Suggests for auto import only works if you have imported a library at least once somewhere else

Environment data

Language Server version: 2021.5.2
OS and version: macOS 11
Python version (& distribution if applicable, e.g. Anaconda): Python 3.9.5

Expected behaviour
I expect the suggest for an auto import to work immediately and without having to import the library elsewhere.
Actual behaviour
Currently, I don't get a suggestion for auto import (Screenshot 1) until I manually add the import somewhere. I can even remove it afterwards and still get suggestions for the autoimport (Screenshot 2). It seems PyLance needs some kind of warmup here?

Logs

Enabling python.analysis.logLevel didn't create any meaningfull output on a suggest. I post the content anyway. Maybe it helps.
User belongs to experiment group 'pythonaacf'
User belongs to experiment group 'pythonJediLSP'
User belongs to experiment group 'pythonDiscoveryModuleWithoutWatcher'
User belongs to experiment group 'pythonTensorboardExperiment'
User belongs to experiment group 'pythonFindInterpreter'
User belongs to experiment group 'PythonPyTorchProfiler'
User belongs to experiment group 'CollectLSRequestTiming - experiment'
Python interpreter path: ./.venv/bin/python
Starting Pylance language server.
> conda --version
> /usr/local/bin/black --diff --quiet ~/Projekte/privat/bla/bla/routers/version.py.8df8aade3f37070484540e5c92926a2d.tmp
cwd: ~/Projekte/privat/bla

Code Snippet / Additional information

At the moment, this is expected, but if you enable the (work in progress) indexing setting, you should see this working.
"python.analysis.indexing": true

This indexes user and library code at startup, which is then used for auto-import completions and quick fixes.
You can also enable our insiders build, where this is currently enabled by default: #1287 623

@jakebailey If I try to add this to my config, it tells me that it is an unknown configuration option. I also activated the insiders build without success.

The option is hidden; if it's present then it will be used. With trace logging enabled, you should be able to see indexing happening.
Are you saying that the insiders system didn't work (and you weren't upgraded), or that it didn't fix the issue? If insiders didn't get installed when you changed the setting, then that'd certainly be worth a bug.

Okay, the suggestion does (mostly) work now. Nice to learn that there are also hidden options.
Concerning the insiders system. I still have the same version of Pylance as before.
[Info  - 18:46:32] Pylance language server 2021.5.2 (pyright df8b6b3c) starting

Hm, curious. If you've set "pylance.insidersChannel": "daily", it should automatically install the update and prompt you to reload; can you check in your extensions menu to see if it's waiting for a reload?
You can also try removing the setting and adding it again, which will force a recheck. Otherwise, if you could make a new issue for tracking this discrepancy, that's be great.

I did uncomment and change the setting now various, but nothing happened. Now as I was about record a video of it, the update is incoming, and I was asked to reload. :)

Hah, of course.
Let us know how the indexing setting works for you; we're currently working on improving its performance and impact on other features (lots of auto-imports can make completions slow from the sheer number of items, for example), hence why it's not enabled by default.
I'm going to close this issue, as indexing helps and is the intended fix (though currently with caveats like #1055).


Write the "Continuous integration" article for "actors/development"

Ask Ondra for notes/tips on how they do this, the Mara will help with the content


GA: Delete by Client ID instead of by User Id

Unticketed
❗ Depends on https://github.com/ethyca/fides/pull/2356
Code Changes

[ ] Update the google analytics saas config to specify that we're deleting the user by client_id not user_id.

Steps to Confirm

[ ] list any manual steps for reviewers to confirm the changes

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md

Description Of Changes
Update google analytics user deletion request to delete by client id instead of user id.

@allisonking my follow-up PR to yours mostly just sends in the CLIENT_ID instead of the USER_ID in the user deletion request

thanks for the review!


PDF to Excel feature

Convert PDF to excel would be an  amazing feature.

I believe we have that feature implemented and be released! Will get back to you

To be released*

Thanks a lot, very nice tool you guys made. 💯

Should be a csv table extractor added now, its a work in progress let me know how it is

Tested it today and works, some times its messed up but it's ok to start. I'm coding a pdf to excel (xls, xlsx)  that keeps structure. I will repo it later and if you like feel free to use it as u like.

I'm talking about something like this

oh wow thats impressive

use this https://www.e-iceblue.com/Tutorials/JAVA/Spire.PDF-for-JAVA/Program-Guide/Spire.PDF-Program-Guide-Content-for-JAVA.html

I see

Thats odd when i looked into spire last year i didnt see this free message, where is that?

Here
https://www.e-iceblue.com/Download/pdf-for-java-free.html

I think you can use it, not sure 100% but since you dont charge money for the app , or you planning to do so?

Not planning to ever charge certainly not for the base app etc
I will contact their customer services to know what license their free version is registered under
i have tried spire before and it worked well so that would be awesome

first 3 pages of a file.. i think this is not possible to use then sadly, although its results are impressive

Yeah, the old way , but I will work out something, no matter if I need to port a c++ lib. I know I have some code to do that somewhere in my code hard drive, but I need to look for it , there is a lot, over 10 years of code.

I got a code I created back in 2021 that extract text and keeps layout

I think I will be able to create a sort of skeleton with the metadata and create an excel file

closing issue ticket for now as initial request as been done


[Functional - MIME Error] MIME Error after loading external CSS file

Description:
MIME Error after importing an external root.css file and call it in the index.html file.
Steps to Repro:

Putt he index.html in .\webserver\ folder
Put the root.css in .\CSS\ROOT\
Boot the Minecraft server
Observe the result

Repro rate: 5/5
Repro: 100%
Issue level: Major
Notes:
I attached the HTML and CCS File.
I play on Minecraft 1.19.2 - Fabric 0.14.22
Fabric API 0.76.0
CODEBLOCK:
index.html
`

Home

    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Chelsea+Market&display=swap">

    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link href="https://fonts.googleapis.com/css2?family=Chelsea+Market&display=swap" rel="stylesheet">

    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link href="https://fonts.googleapis.com/css2?family=Chelsea+Market&display=swap" rel="stylesheet">

    <link rel="stylesheet" href="root.css">

STEAMVERSE - A Steampunk Modded Server

WELCOME!

            <button onclick="window.location.href='./HTML/DOCUMENTATION/documentation.html';" type="button" class="button">Documentation</button>
            <button onclick="window.location.href='./HTML/LIVEMAPS/liveMaps.html';" type="button" class="button">Live Maps</button>
            <button onclick="window.location.href='./HTML/CONTACT/contactKira.html';" type="button" class="button">Conact Kira</button>
            <button onclick="window.location.href='./HTML/REPORT/report.html';" type="button" class="button">REPORT ANONYMOUSL</button>

        SteamVerse is a server administrated and created by Kira T. It is about SMP and RPG. There will be machines, trains, buildings, cars, weapons, airships, all in a flatworld as the base map.

        You can join this server by this link:

        INSERT DISCORD SERVER INVITE LINK

`
root.css
`.body{
display: flex;
flex-direction: column;

font-family: 'Finger Paint', cursive;
font-size: 25px;

color: black;

margin: 0px;
padding: 10px;

}
.title{
font-family: 'Rubik Moonrocks', cursive;
font-size: 45px;

color: black;

margin: 0px;
padding: 10px;

}
.button{
margin: 0px;
padding: 15px;

margin: 40px;

border-color: white;
background-color: rgb(0, 0, 0);
lighting-color: white;
color: white;

font-family: 'Creepster', cursive;
font-size: 18px;
}

.maps{
height: 720px;
}

.googleForms{
height: 2350px;;

}
.googleDocs1{
height: 4000px;
width: 1850px;

}
.googleDocs2{
height: 10000px;
width: 1850px;

}
.googleDocs3{
height: 1290px;
width: 1850px;

}
.alert-title{
padding: 20px;
background-color: red;
color: white;
text-align: center;
font-size: large;

}
.alert-text{
padding: 20px;
background-color: red;
color: white;
text-align: center;
font-size: large;

}
`

You say you are putting the css file in .css/root/ in step 2? that's an easy fix. you are supposed to put the file in the same folder as the html file since in index.html you are importing the css file with <link rel="stylesheet" href="root.css">, requesting a file called root.css in in the same directory as the the html file.
You can fix this by moving root.css into the webserver/ folder together with the index.html file.
I realize that this is hard to debug since when the webserver doesn't find the file, it sends an html file (404.html), causing the MIME issue. I'll probably change the code to return a 404 error, in form of json or text and not html, unless an html file was requested. Thank you for bringing this up :)
The website looks like this for me:

Is that the fix? OMG! Thank You!! TWT <3 <3 I will test it ASAP and reply if it's resolved or not! Cheers! <3 <3

No worries, if the website should look the way it does in my screenshot then yeah, that's it! I am working on a way of making it easier to troubleshoot since not everyone will know the code as well as I do lol.
Btw, your server sounds amazing :)

Thank Chuuuuuuuu! And You would be an angelical God if You could! TWT <3 And trueeee XD I am a speed-run taught hobbyinst web developer XD
AND AWHEEEEEEEH! THANK CHUUUUUUUUU!!! TWT <3 <3 <3 <3 I will let You join once I have it run 24/7 and it's open for the public ;w; <3

Hewoo!!
So I have tested it, and it renders some of the stuff but it doesn't look like in Your picture.
It looks like this:

Also the MIME issue is gone but it doesn't render as for You.
Also I have the following brousers:
Chrome
Opera GX
Microsoft Edge
Also! root.css is in the same folder as index.html and it is imported like this:
`

Home

    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Chelsea+Market&display=swap">

    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link href="https://fonts.googleapis.com/css2?family=Chelsea+Market&display=swap" rel="stylesheet">

    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link href="https://fonts.googleapis.com/css2?family=Chelsea+Market&display=swap" rel="stylesheet">

    <link rel="stylesheet" href="root.css">

STEAMVERSE - A Steampunk Modded Server

WELCOME!

            <button onclick="window.location.href='./HTML/DOCUMENTATION/documentation.html';" type="button" class="button">Documentation</button>
            <button onclick="window.location.href='./HTML/LIVEMAPS/liveMaps.html';" type="button" class="button">Live Maps</button>
            <button onclick="window.location.href='./HTML/CONTACT/contactKira.html';" type="button" class="button">Conact Kira</button>
            <button onclick="window.location.href='./HTML/REPORT/report.html';" type="button" class="button">REPORT ANONYMOUSL</button>

        SteamVerse is a server administrated and created by Kira T. It is about SMP and RPG. There will be machines, trains, buildings, cars, weapons, airships, all in a flatworld as the base map.

        You can join this server by this link:

        INSERT DISCORD SERVER INVITE LINK

`

I used firefox for the screenshot above. Using Chrome I get the following result:

I think there might be an issue with your fonts and how they render in different Browsers since for me it isn't rendering the font at all? This doesn't change when I just open the html file in Chrome so it's something with your css. you might want to check if some of the fonts don't work. What am I supposed to see? is my first screenshot of Firefox the correct way? the only difference between that and your screenshot is the font and that you're using a dark mode extension I assume. Do you get any difference between when you open the html file and when you use the server link?

Heyyoooooo!!
So the first pictures You sent are the right fonts that this document should look like.
 Am so so so so so sorry T.T <3
So for everyone who doesn't know the solution follow this tutorial:
https://stackoverflow.com/questions/22011139/google-fonts-are-not-rendering-on-google-chrome/22025804#22025804
"remove the 'http:' in:
 "
That should do the trick!
Also the funny part is that Google gives You the https link inside the Google Font website but they didn't think that ppl may use Chrome when doing google stuff XD _(O.O???)_/
Also thank You so much for EVERYTHING and again ,am sowwy T.T <3

No worries, glad I could help :)
Yes, the fact that some google fonts don't render in google chrome is ironic but I have to say I'm not surprised, I've had many issues with google fonts in the past. your safest bet is to download the font in form of a .ttf file (which is possible on the google fonts website) and import those into your CSS code locally without the link to google fonts. this should work in 100% of cases (I think), BUT I just tested it and the mod doesn't support it yet. I will however add it shortly as well as a few other types. I am working on some new features so this will integrate nicely! I'll close the issue once ttf is supported.

Ooooooooh! AMAZIIIIIIIIIIIING!!! Thank Chu thank Chu!  IT WORKS WITH .ttf font files!  TWT <3 <3 <3
Thank Chuuuuuuuuuuuuuuuuuuuuuuuu!  I'm currently writing a wiki at https://github.com/J-onasJones/McWebserver/wiki/ to make it easier for anyone to setup their server and I'll add a few examples so that mistakes such as your's don't happen again! I'm also working on a way of displaying server information on the website such as player list and much more so stay tuned for that if you're interested :)

OMG that is great and I sure will! Thank You so much for this amazing sneak peek! I am def. excited! ^w^ <3 <3


Disabled redefining of already defined constant in routes

Should fix this warning from Rails console:
/home/rblanco/devel/manageiq/config/routes.rb:120: warning: already initialized constant CONTROLLER_ACTIONS
/home/rblanco/devel/manageiq/config/routes.rb:120: warning: previous definition of CONTROLLER_ACTIONS was here

@romanblanco Can you explain how/why it is being defined twice?

@chessbyte It's defined once, but the code can be loaded more than once, and then you can get the previous definition warning in console.

@romanblanco So you are saying that config/routes.rb is evaluated twice?

@chessbyte yes

I can confirm that, fix verified, none warning displayed with "Nil Guard", ACK

Can we switch to a local variable instead? At a glance, I can't find anywhere else we use this constant.

@matthewd thanks, i've tried and it works fine. updated.


Minimize the requirements.txt

I think the current state of the requirements.txt is too specific in it's versions. We could probably emit the "==" version specifications and specify them with ">=" or leave the version out completely.
Inspiration: requirements from the sentence-transformer library
https://github.com/UKPLab/sentence-transformers/blob/master/requirements.txt

fixed, thanks Mo! :-)