V2

Status

[X] Initial draft (pure python tested at 100% coverage)
[ ] Update changelog/documentation & polishing/simplifying APIs
[ ] Cython version

Changelog (draft)
This is an INCOMPLETE DRAFT of the changelog.
Breaking Changes
Important

All previously deprecated changes have been removed: @factory, @service, ...
@lazy is NOT a singleton by default anymore.
world.get returns None by default now if not found, like a dictionary. All world.get[T]  and
inject.get[T] methods have been removed.

Core

rename Wiring.wire argument :code:class_in_localns to class_in_locals.
rename parameters dependencies to fallback for Wiring and @wire
Providers cannot be accessed like dependencies in the Catalog anymore.
Exception during dependency retrieval are not wrapped in DependencyInstantiationError anymore

Lib
Interface

QualifiedBy relies on equality now, not the id anymore.

Lazy

remove call() from lazy functions.
removed __getitem__() from const.

Features
Major
Antidote core API has been entirely reworked.

AEP1: Instead of hack of module/functions world is now a proper class, a Catalog. Alternative Catalogs can be created and included in one another. Dependencies can also now be private or public.

from antidote import create_catalog, inject, injectable, world, antidote_injectable

catalog = create_catalog()
# Add injectable lib
catalog.include(antidote_injectable)

# Only accessible from providers by default.
@injectable(catalog=catalog.private)
class PrivateDummy:
    ...

@injectable(catalog=catalog)  # if catalog is not specified, world is used.
class Dummy:
    # TODO: Unclear whether this method should be injected with private or not.
    def __init__(self, private_dummy: PrivateDummy = inject.me()) -> None:
        self.private_dummy = private_dummy

# Not directly accessible
assert PrivateDummy not in catalog
assert isinstance(catalog.get[Dummy](), Dummy)
# Not inside world
assert Dummy not in world

world.include(catalog)
assert world.get[Dummy]() is catalog.get[Dummy]()

AEP1: Notion of current_catalog defined by @inject in an upper level caller:

from antidote import create_catalog, inject, injectable, current_catalog

catalogA = create_catalog()
catalogB = create_catalog()
catalogC = create_catalog()

@inject
def f():
    ...

@inject(catalog=catalogA)
def f_A():
    ...

@injectable(catalog=catalogA)
class Dummy:
    @inject
    def method(self):
        ...

    @inject(catalog=catalogB)
    def method_B(self):
        ...

    @inject(catalog=None)
    def method_None(self):
        ...

@inject(catalog=catalogC)
def g():
    f()  # uses catalogC
    f_A()  # uses catalogA

    Dummy().method()  # uses catalogA
    Dummy().method_B()  # uses catalogB
    Dummy().method_None()  # uses catalogC

    current_catalog  # read-only of catalogC

@inject  # uses world by default
def h():
    f()  # uses world
    f_A()  # uses catalogA

    Dummy().method()  # uses catalogA
    Dummy().method_B()  # uses catalogB
    Dummy().method_None()  # uses world

    current_catalog  # read-only of world

AEP2: Replacing the old Scope, dependencies can now be declared as deterministic. They will only
be recomputed when one of its StateToken dependency changes. StateToken can be arbitrarily created by a Provider. The easiest way to use it is @state.

from __future__ import annotations

from antidote import state, inject, lazy, world

@state
def counter(previous: int | None) -> int:
    return (previous or 0) + 1

# Until update, the value stays the same.
assert world[counter] == 1
counter.update()
assert world[counter] == 2

@lazy(scope='deterministic')
def dummy(count: int = inject[counter]) -> str:
    return f"Version {count}"

# dummy will not be re-computed until counter changes.
assert world[dummy()] == 'Version 2'
counter.update()
assert world[dummy()] == 'Version 3'

Testing has a simplified API:

from antidote import world

with world.test.new() as overrides:
    # add a singleton
    overrides['hello'] = 'world'
    # add multiple singletons
    overrides.update({'second': object()})
    # delete a dependency
    del overrides['x']
    # add a factory
    @overrides.factory('greeting')
    def build() -> str:
        return "Hello!"

Catalogs, such as world, behave now like a dictionary and its API is symmetrical with inject.

world.get(x) returns None by default if x is not found.
world.get[Klass]() does not exist anymore, world[Klass] and world.get(Klass) have now
proper typing.
world.get[Klass].single() and world.get[Klass].all() have been removed, use the equivalent
world[instanceOf[Klass]().single()] instead

from typing import Optional

from antidote import const, inject, injectable, world

class Conf:
    HOST = const('localhost')
    STATIC = 1

assert Conf.HOST in world
assert Conf.STATIC not in world
assert world[Conf.HOST] == 'localhost'
assert world.get(Conf.HOST) == 'localhost'
assert world.get(Conf.STATIC) is None
assert world.get(Conf.STATIC, default=12) == 12

try:
    world[Conf.STATIC]
except KeyError:
    pass

@injectable
class Dummy:
    pass

assert isinstance(world[Dummy], Dummy)
assert isinstance(world.get(Dummy), Dummy)

@inject
def f(host: str = inject[Conf.HOST]) -> str:
    return host

@inject
def g(host: Optional[int] = inject.get(Conf.STATIC)) -> Optional[int]:
    return host

assert f() == 'localhost'
assert g() is None

@interface now also supports functions. They behave similar to @lazy functions.

from antidote import interface, overridable, world

@interface
def mult(x: int) -> int:
    ...

@implements(mult)
def mult2(x: int) -> int:
    return x * 2

assert world[mult] is mult2  # returns a single implementation, the function itself.
assert world[mult.single()] is mult2
assert world[mult(3)] == 6  # returns the value computed by the singlet implementation
assert world[mult(3)] == world[mult](3)  # equivalent
assert world[mult.single()(3)] == 6

# Defines multv2 as an interface and as the default implementation
@overridable
def multv2(x: int) -> int:
    return x * 3

assert world[multv2(6)] == 18

Minor

@inject has now kwargs and fallback keywords to replace the old dependencies. kwargs takes priority over alternative injections styles and fallback is used in the same way as dependencies, after defaults and type hints.
@inject now supports properly *args.
Better static typing API for inject and world:

from antidote import const, inject, injectable, lazy, world

class Conf:
    HOST = const('localhost')

@lazy
def hello() -> str:
    return "world"

@injectable
class Dummy:
    pass

@inject
def f(host: str = inject[Conf.HOST],
      name: str = inject[hello()],
      dummy: Dummy = inject.me(),
      dummy2: Dummy = inject.get[Dummy]()) -> str:
    return ""

# Proper type is detected
world[Conf.HOST]
world[hello()]
# Simplified notation for classes
world.get[Dummy]()

Better static API for Protocol interfaces:

from typing_extensions import Protocol

from antidote import implements, instanceOf, interface, world

@interface
class Dummy(Protocol):
    ...

@implements(Dummy)  # Still needs improvements, maybe @implements.protocol[Dummy]() ?
class MyDummy:
    ...

assert isinstance(world[instanceOf[Dummy]()], MyDummy)
assert isinstance(world[instanceOf[Dummy]().single()], MyDummy)

QualifiedBy relies on equality instead of the id of the objects now. Limitations on the type of qualifiers has also been removed.

from antidote import implements, interface

@interface
class Dummy:
    ...

@implements(Dummy).when(qualified_by='a')
class A(Dummy):
    ...

@implements(Dummy).when(qualified_by='b')
class B(Dummy):
    ...

I'm going to be busy. 😀 This is an impressive amount of work @Finistere

In this: @lazy(scope='deterministic') ... is deterministic a user-defined name, or something magic in the framework?

In your state example, the first assert is wrong. It starts by returning 1, not 0.
# Until update, the value stays the same.
assert world[counter] == 0

In this: @lazy(scope='deterministic') ... is deterministic a user-defined name, or something magic in the framework?

It's "magic", properly typing with Literal. It either accepts the Scope enum their string counterpart "instance", "singleton", "deterministic". It seems nicer than importing Scope all the time.

In your state example, the first assert is wrong. It starts by returning 1, not 0.
# Until update, the value stays the same.
assert world[counter] == 0

You're right, thanks :)

I'm going to be busy. grinning This is an impressive amount of work @Finistere

Thanks! Took longer than expected and it's still not finished though. The core stuff is there, but it'll definitely need some polish

In this example:
# dummy will not be re-computed until counter changes.
assert world[dummy()] == "Version 2"
counter.update()
assert world[dummy()] == "Version 3"

I had the impression that @state was "push". Meaning, when counter changed, it found dependents (dummy) and updated them. It appears though that dummy isn't run again until you ask for it, on the last line. (Confirmed by debugger and breakpoint.)

In docs/recipes/scopes.rst it looks like you have some runaway cut-and-paste with In a Flask app for example.

I had the impression that @state was "push". Meaning, when counter changed, it found dependents (dummy) and updated them. It appears though that dummy isn't run again until you ask for it, on the last line. (Confirmed by debugger and breakpoint.)

Yes, it's only computed upon request. Each deterministic dependency keeps track of all the state tokens (~ roughly a @state) it depends on, directly or not. If any of them has been updated, the dependency is re-computed. Re-computing everything doesn't sound optimal to me and I don't expect the cost of checking the state tokens to be that big, especially for the cython version.

In docs/recipes/scopes.rst it looks like you have some runaway cut-and-paste with In a Flask app for example.

I haven't reworked the documentation at all yet. :)

Yes, it's only computed upon request.

We can discuss this if I ever get to the SSG example. I don't mind walking myself, if the data are traversable/recursable.

It should be possible to also support push when explicitly specified. I would keep a list of dependencies to be forcefully updated when the token changes. Not sure if it should be specified on the dependency or the @state though. Or both.

Sorry, at beach, can't check myself. Can the counter function take arguments beyond previous? Let's say I wanted to optionally increase by five with counter.update(increment=5)

Sorry, at beach, can't check myself. Can the counter function take arguments beyond previous? Let's say I wanted to optionally increase by five with counter.update(increment=5)

Currently no. I understand the need for it, but not sure for the API and whether it's worth it though.

update() could accept all arguments except previous and it would be used, once, when re-computing the state value.

I'm triple-happy with this PR! Pleasantly surprised to see the "AEP" naming being adopted, by AEP1 seeing the light of day, and even more surprised by this new AEP2 (which reminds me of NestJS's implementation of a REQUEST scope, but much more flexible)
Reading the PR and the specs in #51 again (more specifically, the part about file watchers), and recollecting my experiences with other languages, one things comes to mind, not only about this new @state implementation, but about the old implementation for scopes in general. (Excuse me if the question is too basic, or was already addressed in the docs; I couldn't find any info on that. I'm also wet behind the ears in regards to knowledge about the Python ecosystem :x)
How do states, or scopes, deal with multi-threading? Are they thread-safe? If not, is there any easy way to make them thread-safe (perhaps via the state function implementation itself)?
I remember that world has a lock somewhere, but now that we will have catalogs, where will this lock be? Does it make sense for each catalog to have its own lock, or should this be an aspect of the Provider's implementation? (or is this all unjustified anyway?)
On some Java frameworks, like Java EE (and related, like Spring MVC on top of Servlets), when a request hits the server, it'll be served by a specific thread, generally from a thread pool. Most of the time, the component that will in fact answer the request is a singleton, so it must be type-safe. You could implement type safety in the injected service itself (e.g. via threading.RLock), but knowing that @lazy reconstructs the whole dependency tree when one of its @state dependencies are updated, I see an opportunity for some of those thread-safety guarantees to be maintained by Antidote itself (e.g. each thread will have its own dependency tree, which may include some dependency to inform which request is currently being handled). This would greatly simplify service implementation when multithreading is involved -- even though I admit it does not eliminate the need to be aware of exceptional cases, or potential critical sections.
Perhaps the StateToken itself could store data (like request ID, request statistics, etc) and e.g. be a threading.local, but I'm not sure how I'd do that. It also looks like the update() function doesn't call the wrapped @state function, it just updates the StateToken, so I see no way for the @state injection to be customized per-thread by means of the decorated function. For example:
class ThreadState:
  id = uuid.uuid4()
  processed = False
  data: Any = None

@dataclass
class ThreadStateContainer(threading.local):
  current: ThreadState | None = None

__thread_state = ThreadStateContainer()

@state
def per_thread_resource(previous: ThreadState | None) -> ThreadState:
  # How to e.g. reset the value? Is this enough (once `update()` is called)?
  assert __thread_state.current is not None
  return __thread_state.current

@interface
class ThreadRunner(Protocol):
  def run(self) -> None:
    ...

@injectable
class ThreadService:
  def __init__(self, state = inject[per_thread_resource]) -> None:
    self.__state = state
  def run(self) -> None:
    print(f"Processing request {self.__state.id}")

# Also, is it possible to implement both `@lazy` and `@interface/@implements`? (I suppose not, b/c providers)
@lazy(scope='deterministic')
@implements[ThreadRunner]()
class ThreadRunner:
  def __init__(self, service: ThreadService = inject.me()) -> None:
    self.__service = service
  def run(self) -> None:
    self.__service.run()

@injectable
class Dispatcher:
  def __init__(self, catalog: inject[catalog]) -> None:  # Is there a way to reference the current catalog?
    self.__catalog= catalog
  def run(self, data: Any) -> None:
    def do_run() -> None:
      __thread_state.current = ThreadState(data=data)
      runners = self.__catalog.get[instanceOf[ThreadRunner]()]()  # Is this possible, with `@lazy`?
      for runner in runners:
        runner.run()
        if __thread_state.current.processed:
          break
      # Is this enough to collect objects/resources?
      per_thread_resource.update()
    self.__dispatch_thread(do_run)
  def __dispatch_thread(self, func: Callable) -> None:
    ...

Does any of this make sense for you guys?

Also, will compatibility with Python 3.7 be maintained? I saw some typing functionality that are only supported on 3.9+.

I'm triple-happy with this PR! Pleasantly surprised to see the "AEP" naming being adopted, by AEP1 seeing the light of day, and even more surprised by this new AEP2 (which reminds me of NestJS's implementation of a REQUEST scope, but much more flexible)

Happy to see you back ;)

Also, will compatibility with Python 3.7 be maintained? I saw some typing functionality that are only supported on 3.9+.

Yes, I'm keeping compatibility as long as Python 3.7 is maintained. Tests are passing with Python 3.7. I do have a dependency on  typing_extensions though.

How do states, or scopes, deal with multi-threading? Are they thread-safe? If not, is there any easy way to make them thread-safe (perhaps via the state function implementation itself)?
I remember that world has a lock somewhere, but now that we will have catalogs, where will this lock be? Does it make sense for each catalog to have its own lock, or should this be an aspect of the Provider's implementation? (or is this all unjustified anyway?)

Dependency instantiation is always thread-safe. Only one instance is created for any given singleton, and at most one instance will be created for each deterministic dependency. At most, since the current implementation is lazy.
Each Catalog has its own lock, shared with its private counterpart. A Catalog can also only have one parent, which should avoid any race condition on Catalog access with children. A Provider has a bit less magic now than before. Previously all methods were magically locked if not decorated with @does_not_freeze. Now methods called in a thread-safe manner by the catalog are prefixed with unsafe_, meaning they can be unsafe. This is typically the case for the method called for dependency instantiation unsafe_maybe_provide(). Except those, the ProviderCatalog given to the Provider exposes a locked() context manager which shares its lock with the catalog for simple thread-safety.
Now for the new version of scopes, the @state, Antidote guarantees that during a @inject or a Catalog.get (or equivalent) all dependencies see the same state.

Also, is it possible to implement both @lazy and @interface/@implements? (I suppose not, b/c providers)

You can, @interface/@implements works with functions. Those work like@lazy. Here's the example from the changelog:
from antidote import interface, overridable, world

@interface
def mult(x: int) -> int:
    ...

@implements(mult)
def mult2(x: int) -> int:
    return x * 2

assert world[mult] is mult2  # returns a single implementation, the function itself.
assert world[mult.single()] is mult2
assert world[mult(3)] == 6  # returns the value computed by the singlet implementation
assert world[mult(3)] == world[mult](3)  # equivalent
assert world[mult.single()(3)] == 6

# Defines multv2 as an interface and as the default implementation
@overridable
def multv2(x: int) -> int:
    return x * 3

assert world[multv2(6)] == 18

Is there a way to reference the current catalog?

Yes with from antidote import current_catalog. It's a read-only version of the current catalog, thread/async-safe.

It also looks like the update() function doesn't call the wrapped @state function, it just updates the StateToken

Yes I intend to change it though.

I'm not sure to follow your example. @state is currently meant to work in the following manner typically:
from flask import Flask, Request
from antidote import state, lazy, inject

app = Flask(__name__)

@state
def current_request(previous: Request | None) -> Request:
    from flask import request
    return request

@app.after_request
def reset_request_scope():
    current_request.update()

# Only re-computed when the current_request is updated
@lazy(scope='deterministic')
def current_user(request: Request = inject[current_request]) -> object:
    ...

What do you expect from your per_thread_resource() ? From the look of your code I understand that
ThreadRunner should be cached until the per_thread_resource is updated. But I'm not sure to see
its purpose. I feel like your understood that dependencies could be thread-specific/local. In Antidote
they're not. Each Catalog has a single cache (dict) which keeps all singleton and deterministic
dependencies. Singleton are created in a thread-safe manner once. And deterministic dependencies
are updated only when necessary, also in a thread-safe manner.
To be clear, I'm not saying it couldn't do something else, but that's currently how it works.

I think I understood what you meant @flisboac. I'm taking the Flask example again. Supposing Flask was an async framework, because there aren't any real multi-threaded web frameworks in Python to my knowledge, multiple requests would be treated concurrently. So  current_request and current_user would be inconsistent, which obviously isn't great...
from flask import Flask, Request
from antidote import state, lazy, inject

app = Flask(__name__)

@state
def current_request(previous: Request | None) -> Request:
    from flask import request
    return request

@app.after_request
def reset_request_scope():
    current_request.update()

# Only re-computed when the current_request is updated
@lazy(scope='deterministic')
def current_user(request: Request = inject[current_request]) -> object:
    ...

I suppose from a pure API standpoint, Antidote should allow specifying that a given @state is a ContextVar and a new scope would be needed such as 'deterministic-local' or 'deterministic-context-var'. Using a context var state from anything else would raise an error. I've no idea yet how this could be properly implemented though.
Did I understand you right?

Yes, I'm keeping compatibility as long as Python 3.7 is maintained. Tests are passing with Python 3.7. I do have a dependency on typing_extensions though.

typing_extensions is fine, really. I also see some from __future__ import annotations as well. My bad for not noticing it earlier.

Dependency instantiation is always thread-safe. Only one instance is created for any given singleton, and at most one instance will be created for each deterministic dependency. At most, since the current implementation is lazy.

Thanks for the explanation. As I understand, then, locking happens at catalog-level. But just to be sure, do all children of a catalog share the same lock with the parent?

You can, @interface/@implements works with functions. Those work like@lazy.

My question was more in the sense of an @implements injectable that's also lazy (which is the default, I suppose? Didn't know that).
But then, is there any way for an @implements dependency to be scoped in the manner of, e.g. @data, or REQUEST? (@implements(scope=...))

I'm not sure to follow your example.

I did an oopsie in my code. I intended to multi-inject all ThreadRunner implementations, programmatically. So, the second ThreadRunner should be really named something else, e.g. DefaultThreadRunner:
@lazy(scope='deterministic')
@implements[ThreadRunner]()
class DefaultThreadRunner:   # <<- Could have many implementations
  def __init__(self, service: ThreadService = inject.me()) -> None:
    self.__service = service
  def run(self) -> None:
    self.__service.run()

Just to explain my example further:
I imagined that per_thread_resource could fill the same role as the current_request in your example. But some other entity in the code must fill the request information, somehow. I don't know what does that in Flask, but in my example, that job would be performed by Dispatcher, when a new request comes.
Scope control is manual, and performed by Dispatcher as well. It's like a request handler. For each request, it would dispatch the sequenced execution of all registered handlers along a chain (materialized as implementations of ThreadRunner; for which I didn't care to specify any kind of priority :x but lets roll with it) in a new thread, stopping once the request has been processed (indicated by ThreadContext.processed, which would be filled by one of the ThreadRunners).
I supposed that ThreadService, and all DefaultThreadRunners, would share the same lifetime, because they're being instantiated in the same scope (and ThreadService, for being a dependency of a scoped class, would be recreated as well, but only once). This would allow request-bound services to be able to maintain their own state per request, on top of the request information managed by Dispatcher.
I imagine it's not much different from what Flask does, the difference being that Flask's implementation abstracts a lot of that away, and I had to implement everything from scratch for the sake of the example... But just in case, I need to see more examples of Python code to familiarize myself better with how the community implement this type of pattern.
So, to make things more evident, I'll rename classes and language elements, to follow something more in line with a e.g. HTTP Server:
class Request:
  id = uuid.uuid4()
  processed = False
  data: Any = None

@dataclass
class RequestContainer(threading.local):
  current: Request | None = None

__request = RequestContainer()

@state
def current_request(previous: Request | None) -> Request:
  # How to e.g. reset the value? Is this enough (once `update()` is called)?
  assert __request.current is not None
  return __request.current

@lazy(scope='deterministic')
class RequestService:  # <<- Could also be a "ControllerService", etc
  def __init__(self, state = inject[current_request]) -> None:
    self.__state = state
  @property
  def request_id(self) -> str:
    return self.__state.id
  @property
  def user_name(self) -> str:
    ...

@interface
class RequestHandler(Protocol):
  def run(self) -> None:
    ...

@implements(RequestHandler)
class HelloRequestHandler:   # <<- Could just be a function as well, like you showed!
  def __init__(self, *, __request: RequestService = inject.me()) -> None:
    self.__current = __request
  def run(self) -> None:
    print(f"Processing request {self.__current.request_id} for user {self.__current.user_name} on handler {type(self).__name__}")

@injectable
class Server:
  # For the sake of simplicity, I only implemented the `run` method,
  # but imagine I could have an open socket, etc.; on each new data,
  # I make a new `run()` call
  def run(self, data: Any) -> None:
    def do_run() -> None:
      __request.current = Request(data=data)
      handlers = current_catalog.get[instanceOf[RequestHandler]()]()
      for handler in handlers:
        handler.run()
        if __request.current.processed:
          break
      current_request.update()
    self.__dispatch_thread(do_run)
  def __dispatch_thread(self, func: Callable) -> None:
    """Dispatches a new "thread".
    (maybe from a thread pool? or maybe it uses a job queue, where threads pick jobs from?)
    """

Hope it's clearer now.
Btw, by no means I'm implying my example is some kind of state of the art! I'm sure there's a much better way to implement e.g. HTTP/API Servers, etc. I just tried to elaborate an example, based on some previous experiences (mostly outside Python).

I feel like your understood that dependencies could be thread-specific/local.

Then I think my understanding was correct. I was only trying to envision a scenario where, given what Antidote is offering now (@data), downstream users would need not to worry much about thread-safety, even though some services would be called by a multithreaded "orchestrator", like in my example. The request data visibility was one of them. The Flask was the perfect example for that, and a much better one, in fact.
But back again to my initial example, this kind of use case could easily be implemented differently, e.g. by passing the request explicitly, as if we had RequestHandler.run(self, r: Request) -> None instead.

Thanks for the explanation. As I understand, then, locking happens at catalog-level. But just to be sure, do all children of a catalog share the same lock with the parent?

Yes, locking is done at catalog level. No, children do not share the same lock. As they can only have one parent, two catalogs A and B cannot race for the lock of another one C as only one of them would be its direct parent. The other one would need to go through the direct parent first. So I don't think being stricter than that is necessary. The private and public parts of a catalog do share the same lock though.

My question was more in the sense of an @implements injectable that's also lazy (which is the default, I suppose? Didn't know that).
But then, is there any way for an @implements dependency to be scoped in the manner of, e.g. @data, or REQUEST? (@implements(scope=...))

 And @injectable lazily instantiate the class. If you want to customize the implementation, you just need to apply @injectable yourself. It's the same for a function with @lazy. Hereafter is an example, I hope it'll be clearer. :) I could provide the arguments in @implements directly but it would to code duplication in Antidote and composing the different decorators does feel natural to me. I definitely need to enhance the documentation/tutorial/readme on this.
from typing import Protocol

from antidote import implements, injectable, interface, lazy, world

@interface
class RequestHandler(Protocol):
    def run(self) -> None:
        ...

@implements(RequestHandler)
class HelloRequestHandler:
    def run(self) -> None:
        ...

# The HelloRequestHandlerV2 is strictly equivalent to HelloRequestHandler
# for @implements. Using `world.private` is really that useful for `world`, but it can be for a custom
# catalog.
@implements(RequestHandler)
@injectable(catalog=world.private)
class HelloRequestHandlerV2:
    def run(self) -> None:
        ...

# this would be the way to change the scope of an injectable without worrying about private/public.
@implements(RequestHandler)
@injectable(scope='deterministic')
class HelloRequestHandlerV3:
    def run(self) -> None:
        ...

@interface
def run() -> object:
    ...

@implements(run)
def run_impl() -> object:
    ...

# This is also equivalent for @implements, but in this case, run_impl_v2() is a LazyCallable
# (returned by @lazy) while run_impl is the actual, injected, function.
@implements(run)
@lazy(catalog=world.private)
def run_impl_v2() -> object:
    ...

Hope it's clearer now.

Definitely, thanks for the example! I've updated the example based on how it could work in Antidote:
from __future__ import annotations

import uuid
from typing import Any, Callable, Protocol

from antidote import app_catalog, implements, inject, injectable, instanceOf, interface, lazy, state

class Request:
    id = uuid.uuid4()
    processed = False
    data: Any = None

# The function doesn't do anything, it's merely there to accept an argument in update() and
# return it. Antidote could expose a simpler StateVar which could have a similar API to a ContextVar
# for those cases.
# `contextvar=True` would specify that the state needs to be stored in a ContextVar which is
# similar to a thread local variable except it also works properly with async code.
# `initial` would allow specifying an alternative initial value, which would default to `None`
@state(initial=None, contextvar=True)
def current_request(previous: Request | None, request: Request) -> Request:
    return request

# Being deterministic with a contextvar state would automatically force the RequestService
# to behave in a similar way, stored in a ContextVar.
@lazy(scope='deterministic')
class RequestService:
    def __init__(self, state=inject[current_request]) -> None:
        self.__state = state

    @property
    def request_id(self) -> str:
        return self.__state.id

    @property
    def user_name(self) -> str:
        ...

@interface
class RequestHandler(Protocol):
    def run(self) -> None:
        ...

@implements(RequestHandler)
class HelloRequestHandler:
    # Injecting the request in __init__() would fail as HelloRequestHandler is defined as a
    # singleton. A singleton cannot depend on a deterministic dependency as it doesn't make sense.
    # This is enforced at runtime when building the singleton, ensuring no deterministic dependency
    # was used
    def run(self, request: RequestService = inject.me()) -> None:
        print(
            f"Processing request {request.request_id} for user "
            f"{request.user_name} on handler {type(self).__name__}")

@injectable
class Server:
    def run(self) -> None:
        def do_run() -> None:
            request = Request()
            # update() will invalidate the current value of `current_request`, any deterministic
            # dependency will be re-computed on access, so lazily. I'm considering exposing an
            # alternative version which would eagerly re-compute everything and/or at least
            # remove any references to the invalidated values.
            current_request.update(request=request)

            # renamed current_catalog to app_catalog to re-use the terms of AEP1 which are seems
            # clearer. The Catalog now exposes the same API as a dictionary for [] & get() with proper
            # typing.
            handlers = app_catalog[instanceOf[RequestHandler]().all()]
            for handler in handlers:
                handler.run()
                if request.processed:
                    break

        self.__dispatch_thread(do_run)

    def __dispatch_thread(self, func: Callable) -> None:
        pass

@state could expose a contextvar=True option which would force the use of a ContextVar to store the state. Any deterministic dependency depending on it would also be stored by a ContextVar. All of this would be handled by the Catalog itself, @lazy, @injectable and any other dependency declaration code wouldn't need to handle it itself. I haven't tried this out but from an API point of view, it seems relatively simple would solve the visibility problem. What do you think of it?

As they can only have one parent, two catalogs A and B cannot race for the lock of another one C as only one of them would be its direct parent. The other one would need to go through the direct parent first.

Thanks for your patience, and for the explanation! And I apologize in advance again for asking yet more basic questions... :x
I'm trying to grasp how those parent-child relationships are established. More specifically, the fact that "they can only have one parent". Going back to the example from the first message:
catalog = create_catalog()
# Add injectable lib
catalog.include(antidote_injectable)

In this case, would antidote_injectable be the parent of catalog?

I could provide the arguments in @implements directly but it would to code duplication in Antidote and composing the different decorators does feel natural to me.

I also think this greatly improves the DX as well. It's a much better design, because it's more... unambiguous? (For the lack of a better word).

# The HelloRequestHandlerV2 is strictly equivalent to HelloRequestHandler
# for @implements. Using world.private is not really that useful for world, but it can be for a custom
# catalog.

I imagine the only difference would be that, if I multi-inject RequestHandler, inside the catalog I'd get both HelloRequestHandler, HelloRequestHandlerV2 and HelloRequestHandlerV3, but outside I'd get only HelloRequestHandler and HelloRequestHandlerV3.
But considering that we don't have a @data in this example, when would HelloRequestHandlerV3 be recreated, considering that there's no ContextVar or token to update? (Perhaps it'll be recreated in the context of some other upstream injectable which depends on a token-bound value? But what happens when it doesn't, e.g. in a "global" dependency/singleton?)
I guess what I'm trying to say is that I don't understand what is a deterministic dependency, at least in this case.

@state(initial=None, contextvar=True)

So contextvar=True essentially does what I was doing (with the thread-local example), but much better. That's what I initially understood @data would do. Also, that's really nice!

# Injecting the request in init() would fail as HelloRequestHandler is defined as a
# singleton. A singleton cannot depend on a deterministic dependency as it doesn't make sense.
# This is enforced at runtime when building the singleton, ensuring no deterministic dependency
# was used

So HelloRequestHandler must also be deterministic for it to be able to receive RequestService as a dependency?
If so, does this also apply to upstream dependants (ie. dependents on HelloRequestHandler)?

current_request.update(request=request)

Again, that's a nice addition. Thanks!

# renamed current_catalog to app_catalog to re-use the terms of AEP1 which are seems
# clearer. The Catalog now exposes the same API as a dictionary for [] & get() with proper
# typing.

I agree. Nice DX there, as well, with the dictionary-like API.

As a side-note, I want to say that functions being injectable is amazing! For simpler use-cases, where all you want to pass along is a callable (with some scoped state), it can save a lot of development time! It could be especially useful to implement Commands, a pattern I find really useful for bigger codebases.

Thanks for your patience, and for the explanation! And I apologize in advance again for asking yet more basic questions... :x

No worries, It's my pleasure to answer them! All of @pauleveritt and your comments helped me a lot for Antidote, so thank you again to both of you. :)

In this case, would antidote_injectable be the parent of catalog?

In this case antidote_injectable isn't a Catalog, it's a function that modifies a catalog. Catalog.include accepts multiple inputs: functions, child catalog, and a provider class. With the first, it will just execute the function passing itself as an argument. Here's the source code. It allows one to re-use parts of Antidote for its own Catalog, or not at all.
@API.public
def antidote_injectable(catalog: Catalog) -> None:
    from ._provider import FactoryProvider

    if FactoryProvider not in catalog.providers:
        catalog.include(FactoryProvider)

As you can see it's just adding a provider if not present already. What I meant with only one parent is the following:
from antidote import create_catalog, world

a = create_catalog()
b = create_catalog()

a.include(b)

# `b` has already `a` as a parent
world.include(b)  # fails
world.include(a)  # works

For another Catalog to access b it must either be its direct parent, of which there can be only one, or go through its direct parent. So my point is just that one cannot create a graph of Catalogs in Antidote which may lead to a deadlock. You can obviously still create a deadlock if you're doing your own child relation outside of Catalog.include.

I imagine the only difference would be that, if I multi-inject RequestHandler, inside the catalog I'd get both HelloRequestHandler, HelloRequestHandlerV2 and HelloRequestHandlerV3, but outside I'd get only HelloRequestHandler and HelloRequestHandlerV3.

That's correct.

But considering that we don't have a @data in this example, when would HelloRequestHandlerV3 be recreated, considering that there's no ContextVar or token to update? (Perhaps it'll be recreated in the context of some other upstream injectable which depends on a token-bound value? But what happens when it doesn't, e.g. in a "global" dependency/singleton?)
I guess what I'm trying to say is that I don't understand what is a deterministic dependency, at least in this case.

In this example HelloRequestHandlerV3 would be equivalent to a singleton, so not useful at all obviously.
During dependency instantiation, when requesting a dependency, Antidote keeps track of all @state dependencies that have been requested. For a dependency X with a 'deterministic' scope, those are stored. Whenever X is requested, Antidote will check if any of those @state have changed or not since the last request. If so, it's recomputed

So HelloRequestHandler must also be deterministic for it to be able to receive RequestService as a dependency?

Yes, either 'deterministic' or 'instance' scope. Well, renaming the latter 'call'. A scope for which the dependency is never cached and re-computed each time. A HelloRequestHandler can still manipulate the RequestService, but only in methods. It cannot rely on it when being built. I think this can only avoid design errors similar to your first version of HelloRequestHandler which would inadvertly use the same Request object.
The goal with @state is to remove the need to propagate the actual "scope" to upstream dependents. With the previous scope implementation, you had to specify to which scope a dependency belongs (singleton/request/...). But it's easy to forget and really complex when you start to have more than one scope.  'deterministic' is not really the best name for the scope, but I haven't found a better one yet. I also consider changing the "scope" name to "lifetime" which feels a bit more explicit. And @data might also be a better name than @state!

In this case antidote_injectable isn't a Catalog, it's a function that modifies a catalog. Catalog.include accepts multiple inputs: functions, child catalog, and a provider class.

That's amazing, it's very flexible! Passing a function is like building the catalog dynamically.
Btw, I commented on the AEP about something that I think is related. Should I migrate that post to here?

For another Catalog to access b it must either be its direct parent, of which there can be only one, or go through its direct parent.

Ok, so once a catalog is included in another, only its parent can be included further. This reduces flexibility a little, but it's a good compromise, to avoid circular catalog dependencies (and makes locking easier, too, I imagine).

So my point is just that one cannot create a graph of Catalogs in Antidote which may lead to a deadlock. You can obviously still create a deadlock if you're doing your own child relation outside of Catalog.include.

Would a "provider object" (here with a different meaning, in the sense of a "proxy", or injector) alleviate this issue in any way? in either end, so that it breaks the circular dependency at runtime:
@inject
def app(*, service: Injected[Service] = inject.me()) -> None:
  injected_service = service.get()
  # ...

Don't remember if we have something like this. @lazy seems to serve another purpose, I think?
Injected[Service]  is lazy. Conceptually, in Java/Jakarta EE, I think Injected is called Provider, or is almost the same thing.
In NestJS, we have forwarding references](https://docs.nestjs.com/fundamentals/circular-dependency#forward-reference), but they serve a purpose that's more aligned with postponed evaluation of annotations and "dynamic/conditional/in-function" imports, etc. Perhaps using ModuleRef and looking the dependency up programmatically is the nearest thing to that sentinel object, with the difference that NestJS (unlike Antidote, in this example) would be entiely unaware of that dependency until the code is run.

In this example HelloRequestHandlerV3 would be equivalent to a singleton, so not useful at all obviously.

So, specifying scope='deterministic' in this case (ie. in HelloRequestHandlerV3 ) is most probably a mistake.

A HelloRequestHandler can still manipulate the RequestService, but only in methods.

Ah, didn't even know that was a possibility. This way, on each method call, the proper RequestService is injected, then. In a sense, the method itself is "deterministically injectable". That's very powerful.

I also consider changing the "scope" name to "lifetime" (...)

I agree, even though "scope" is somewhat a standard term for this kind of DI concept.

'deterministic' is not really the best name for the scope, but I haven't found a better one yet.

I think most injections made by Antidote could be qualified as "deterministic", if we consider that word in a vacuum. I admit the terminology confused me a bit in the beginning.

Well, paraphrasing @pauleveritt, this is much more than I asked for!

I submitted before I was finished writing. :(

'deterministic' is not really the best name for the scope, but I haven't found a better one yet.

What about bound (like in scope-bound dependencies)?

Would a "provider object" (here with a different meaning, in the sense of a "proxy", or injector) alleviate this issue in any way? in either end, so that it breaks the circular dependency at runtime:

You can do something similar with:
@inject
def app() -> None:
    injected_service = world[Service]
    # ...

It doesn't solve the locking problem though. Supposing a catalog X needs to access catalogs A, B, and C. And another catalog Y needs the same. X might lock A and B, and Y lock C. Now you're in a deadlock. The parent limitation helps avoid those cases, as neither A, B, nor C would be accessible naturally from both X and Y. But you could still create similar situations yourself by manipulating the catalogs directly as I did in the previous code example.

So, specifying scope='deterministic' in this case (ie. in HelloRequestHandlerV3 ) is most probably a mistake.

Yes, unfortunately, I can't detect it. The dependency tree is only built at runtime, the closest is debug() which only imitates it as long as the underlying Providers do their job correctly.

Ah, didn't even know that was a possibility. This way, on each method call, the proper RequestService is injected, then. In a sense, the method itself is "deterministically injectable". That's very powerful.

To be a bit more precise it depends on how you call the method. There is no special treatment for __init__(). It's just the fact that it's used during the creation of a singleton that will raise an error:

@inject
def f(request: RequestService = inject.me()) -> None:
    pass

@injectable(scope='singleton')
class Service:
    def __init__(self, handler: RequestHandler = inject.me()) -> None:
        handler.run()

f()  # OK
world[Service]  # fails

I think most injections made by Antidote could be qualified as "deterministic", if we consider that word in a vacuum. I admit the terminology confused me a bit in the beginning.

It would feel easier from an API point of view, but "deterministic" implies caching. That's the reason why I have the default scope from "singleton" to "call"/"instance" in @lazy. One must be aware when Antidote will cache objects for you as they won't be GC.

Well, paraphrasing @pauleveritt, this is much more than I asked for!

Glad to hear it! I just need to ship now. :D

It looks like mypy doesn't like the typing in your example above, the one with Dummy:
foo.py:23:21: error: Value of type overloaded function is not indexable  [index]
        dummy2: Dummy = inject.get[Dummy](),
                        ^
foo.py: note: At top level:
foo.py:32:1: error: Value of type overloaded function is not indexable  [index]
    world.get[Dummy]()
    ^
Found 2 errors in 1 file (checked 1 source file)

PyCharm also dislikes all 3:
world[Conf.HOST]
world[hello()]
world.get[Dummy]()

That's an error in the changelog, world.get now behaves exactly like dict.get. There's no world.get[Dummy]() anymore, I've fixed the typing problems I had when I designed that part. In the V2 a Catalog behaves exactly like a dict for __contains__, __getitem__ and get with proper typing. And the overrides of with world.test.new() as overrides: behaves like a dict for __setitem__, __delitem__ and update.
I'm currently in the process of updating the reference documentation, so the changelog should be accurate this week.

What about for callables, like where you have world[hello()]? Is it world.get(hello())?

Yes, dependencies defined with @lazy also work, const also. Underneath it's defined as:
# for lazy, const, instanceOf[T], custom dependencies...
@overload
def __getitem__(self, __dependency: Dependency[T] | Type[instanceOf[T]]) -> T:
    ...

# for @injectable
@overload
def __getitem__(self, __dependency: Type[T]) -> T:
    ...

# for anything else
@overload
def __getitem__(self, __dependency: object) -> object:
    ...

def __getitem__(self, __dependency: Any) -> object:

All dependencies, except @injectable which has a special overload, rely on Dependency so that both world and inject detect properly the dependency value type. And Dependency will be part of the public API

Just to make sure I have it right: @lazy defaults to scope="instance" and @injectable defaults to scope="singleton" ?

Yes, the problem IMO is that @lazy needs to cache parameters to be accurate. This isn't obvious and also implies that parameters can be hashed. Furthermore, it feels less necessary to me that it is for @injectable. A pure function for example wouldn't need any caching to be accurate, eventually only for performance reasons.

In my tests I do:
 greeter = world.get(Greeter)
 assert greeter.salutation == "Hello!"

mypy doesn't like this:
error: Item "None" of "Optional[Greeter]" has no attribute "salutation"

So I put a type guard around it:
greeter = world.get(Greeter)
if greeter:
    assert greeter.salutation == "Hello!"

mypy is now happy. But PyCharm puts a warning on greeting.salutation:
Unresolved attribute reference 'salutation' for class 'object'

Why? Because PyCharm thinks greeter is greeter: Greeter | None | object = world.get(Greeter). Meaning, it could be None or it could be object.

Codecov Report

Merging #64 (f815c1b) into master (89afd30) will decrease coverage by 0.05%.
The diff coverage is 100.00%.

:exclamation: Current head f815c1b differs from pull request most recent head ac6fb8c. Consider uploading reports for the commit ac6fb8c to get more accurate results

@@             Coverage Diff             @@
##            master      #64      +/-   ##
===========================================
- Coverage   100.00%   99.94%   -0.06%
===========================================
  Files           71       48      -23
  Lines         3992     3692     -300
  Branches       681      565     -116
===========================================
- Hits          3992     3690     -302
- Misses           0        1       +1
- Partials         0        1       +1

Impacted Files
Coverage Δ

src/antidote/__init__.py
100.00% <100.00%> (ø)

src/antidote/_internal/API.py
100.00% <100.00%> (ø)

src/antidote/_internal/__init__.py
100.00% <100.00%> (ø)

src/antidote/_internal/config.py
100.00% <100.00%> (ø)

src/antidote/_internal/localns.py
100.00% <100.00%> (ø)

src/antidote/_internal/typing.py
95.91% <100.00%> (ø)

src/antidote/_internal/utils.py
100.00% <100.00%> (ø)

src/antidote/core/__init__.py
100.00% <100.00%> (ø)

src/antidote/core/_annotation.py
100.00% <100.00%> (ø)

src/antidote/core/_catalog.py
100.00% <100.00%> (ø)

... and 39 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Banner always "true" and never "false"

Version
0.10.11
Operating System
linux-amd64
How are you running SpoofDPI?
Run as service:
spoof-dpi -dns-addr <IP_ADDRESS> -addr <IP_ADDRESS> -port 4435
Description
Default option = "true"
Args set only to "true"

-banner=false

Have you tried running it with -banner=false?

Have you tried running it with -banner=false?

This worked. Thanks.


Use openmm energies for helical modeling tool

In the future, as we add more energy terms to the helical modeling tool, we should obtain the energies from openmm rather than an internal function in cg_openmm. This will require making an openmm topology object.
Not sure if possible to do the minimization itself in openmm with constraints to keep the backbone particles along the helical line, but could be worth looking into.

The option to use openmm energies in the helix optimization was added in #122, closing this


Missing instruction and test case in "Problem 461: Almost Pi"

According to Project Euler's official site, the following string is missing at the end of freeCodeCamp's challenge.
Find g(10000).

Project Euler Official
https://projecteuler.net/problem=461
Since the function is renamed to almostPi in the freeCodeCamp's challenge, the missing string should be:
Find almostPi(10000).

If we were to provide the same content as the Project Euler's site, it seems the test for almostPi(10000) is missing too.
Affected page
Coding Interview Prep > Project Euler > Problem 461: Almost Pi
https://www.freecodecamp.org/learn/coding-interview-prep/project-euler/problem-461-almost-pi
Expected behavior
Add the missing string and the test case.
Screenshots

System

Device: Laptop
OS: Windows 10
Browser: Chrome
Version: 96.0.4664.45(Official Build)(64 bit)

Additional context
Originally reported in a comment on Crowdin
https://freecodecamp.crowdin.com/translate/690087755819f2f67b26dbee3be0eb53/22866/en-ja?filter=basic&value=17#q=731694

That wasn't added on purpose when challenge was reworked, with current added solution internal tests would always time out. The same would be very likely for any solution user might try to submit (this is also applying to a number of other Project Euler problems that weren't yet reworked). See #41333.
I guess there could be added some note that original problem was considering way higher input number.

@gikf Sorry I didn't notice there have been reworks for these challenges.
But I still think the instruction is missing at the end. I guess we should add "Write a function almostPi to fulfill the above conditions" or something like that?

Just taking a glance at some random Euler challenges, it looks like none of them have instructions like "write a function name" - presumably to keep the verbiage as close to the original problem as possible.

Thanks @nhcarrigan for checking it. I think we can close this issue in that case.


Removing material from checkbox component

Closes #1187

When the checkbox is checked, if we make hover on the label, the checkbox should not be hovered. We cold add a test of this in Chromatic.

Since the unchecked checkbox was reacting to the label being hovered, we pondered if the checked checkbox should also change state and it was decided to add it.


Pair-Programming

Comment beginner, advanced or expert here to state your level if you're interested in a pair programming session to solve some gitevents issues. We'll use AtomPair for the session.

yep,
i would like. advanced

I'm in. Advanced?

hola Sergi,
Let's do some pair if you want. We could start maybe doing some refact at webhook.
I'm working this weekend, what  about do some pair next week? could u contact me by email? I'm not atom user but suppose i will handle it
Let me know
Salut!

@PatrickHeneise is this still valid?

Valid yes; used no.


added optional boolean ack field to HAVE messages

This patch adds an optional boolean ack field to HAVE messages to finish the acknowledgement feature in hypercore. For more context see: https://github.com/mafintosh/hypercore/pull/215#issuecomment-515804589
I ran the protobuf build script and the latest version is now 4.1.0 so it changed a few extra things. If you'd prefer I can refactor this to only include the schema and test changes.

6.12.0


Change replaceWith calls to transitionTo to fix back button issues

@mixonic, for you. I'm not sure why we had as many replaceWith calls as
we did. I've hand-tested for deleterious effects of making these changes
and have not found any.
fixes #95

transitionTo makes a history entry. if you are redirected and click back, you often don't want to return to the redirect itself. Instead the redirect is mean to rewrite where you currently are. Obviously this isn't true 100% of the time, but I think in many of these cases it is true.
For instance the database index route. There is no reason I would want a click of the back button to return me to that route (which does nothing but redirect).

@mixonic if you change the transitionTo to a replaceWith in the database/index/route.js you get this behavior (for me, in Chrome):

Click "apps" tab
click "databases" tab
click a database
back button
end up erroneously on "apps" page

Changing to transitionTo fixes this for me.
Screencap:

Ok. My understanding must be flawed? I would like to know what is actually happening here. I don't doubt these changes improved some specific behavior, I was wondering if the change was warranted in so many places.
I'll pull it down and figure out what is happening then report back.

let me know what you find, or if you want to pair. It doesn't fit my mental model of how replaceWith works, either.

Let's review this in the AM.


vscode-extensions.13xforever.language-x86-64-assembly: add alias

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Hi,
Why is this needed?

Why is this needed?

because it is impossible to refer to an extension whose name begins with a digit. the method with quotes doesn't work either


Wrong resolution of html5 on android devices.

Godot version
3.3~
System information
Android 11
Issue description
Wrong display resolution on android devices when a project is exported to html5.
These are screenshots captured on my android mobile.
(I don't have iOS device)

exported with godot 3.2.3

exported with godot 3.3 and later

OS.window_size.x seems like dp width of the display.
Canvas resolutions are different too.
Open these exported html links by mobile .
https://ninetones.github.io/godot_test_mobile_resolution/export3.2.3/
https://ninetones.github.io/godot_test_mobile_resolution/export3.3/
https://ninetones.github.io/godot_test_mobile_resolution/export3.4.4/
Steps to reproduce
Export a godot project to html5 and upload it to a web server and open on android mobile.
Minimal reproduction project
https://github.com/ninetones/ninetones.github.io/tree/main/godot_test_mobile_resolution

This is an intentional change, 3.3+ defaults to enabling HiDPI support on Web too, and not just on other platforms. You can change it in the project settings if you don't want it to handle HiDPI.

Closing per the above comment.


Clarity of Basic Functionality

This document states
"[2] Basic functionality of Editor remains available even if you're not connected to the internet.  In both cases, no data about the use of Editor is sent to Microsoft."
What is basic functionality? What is the impact to each connected experience if they are disabled? Is there a minimal basic functionality that still works for these experiences?

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

ID: f9f215c4-d995-2d6c-0693-bca19f66fe2f
Version Independent ID: a9aa816b-f30d-3bbe-8fdc-204777b25dfe
Content: Connected experiences in Office - Deploy Office
Content Source: DeployOffice/privacy/connected-experiences.md
Service: o365-proplus-itpro
GitHub Login: @DHB-MSFT
Microsoft Alias: danbrown

@TheAlistairRoss  We'll double-check with the Editor product team. There was a discussion with them about this awhile back which led to this note being added about "basic functionality" but don't recall the specifics right now.

https://github.com/MicrosoftDocs/OfficeDocs-DeployOffice/issues/1050

#1050

https://subscriberhelp.granicus.com/s/contactsupport

To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.
As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.
If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.
With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.
Here's what the new experience looks like.
Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.
First, select whether the article was helpful:

Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:

Article was helpful
Article was unhelpful

Finally, select Submit and you're done!


Plugin stops working randomly

Hi, at first good job writing this plugin. But for me it isn't working properly. The plugin stops working randomly and it requires a restart of homebridge to start working again. Unfortunately there are no additional log, even with debug mode on. The plugin detects absence once or twice a day without disconnecting from the network. I checkt router logs but the device didn't disconnected.
Thanks in advance

Fix it by turning of private address in iphone wlan settings.


Add graphviz output for the task system

Producing a graphviz .dot from an iree_task_submission_t or per-worker task list after coordination would be very useful. As I was doing some of the HAL bringup I was reaching for that: as new submissions get chained in to existing ones with semaphores it'd be really nice to see how they are all wired up.

Would be neat, but meh.


Add test for Steel.Array.malloca_of_list

Adds a small test for the malloca_of_list function proposed in https://github.com/FStarLang/FStar/pull/2696
This example extracts to the following C code
int32_t test()
{
  uint8_t p[2U] = { (uint8_t)0U, (uint8_t)1U };
  uint8_t *res = p;
  uint8_t *res0 = res;
  uint8_t *r = res0;
  uint8_t *pt = r;
  uint8_t x = pt[0U];
  if (x == (uint8_t)0U)
  {
    uint8_t *p = r;
    KRML_HOST_FREE(p);
    return (int32_t)1;
  }
  else
  {
    uint8_t *p = r;
    KRML_HOST_FREE(p);
    return (int32_t)0;
  }
}

Looks good, but please fix build failures before merging, thanks

Currently fails with free() : invalid pointer. This is actually expected since malloca_of_list allocates on the stack, so the corresponding array shouldn't be freeable. This will need to be fixed directly in the F* model.


This link to Kerlink build is broken

The link is now fixed in develop, which will be merged as soon as v2.0.2 is released (probably today).


]training-kit

Overview
TL;DR

Extra Detail
Screenshots
<If bug fix, please upload images of the error to better showcase the problem.>
Reasoning
<If new idea or direction, please create a checklist of proposed ideas or next steps. Example.>
Push your changes to your repository.
How to Contribute

[ ] Comment on this issue if you'd like to work/collaborate on it!
[ ] Fork the repository.
[ ] Use the GitHub Flow to make changes to your fork. This is a refresher course if you're unsure about how to make a change on GitHub.
[ ] Push your changes to your repository.
[ ] Submit a Pull Request

Base Dropdown: github/training-kit
Compare Dropdown: Your fork

Testing Locally
If you'd like to make and test changes locally (and see how they would look if merged), do the following:

In your command line:

Install Git
Install Ruby
[ ] Run script/setup
[ ] Run script/server.

When successful, the script will initiate a local server at http://<IP_ADDRESS>:4000/.

Questions?

Leave a comment on this issue! Make sure to use @mentions if you want a specific person's attention!

Hello 👋🏻 It looks like you may be practicing using GitHub. That's great! But, this repository is in active use, and this may be distracting those who maintain it. I'm going to close this, but if you'd like to suggest a bug fix or feature, please open a new issue with the context and information in the body. Thanks!


Problem creating fields attached to taxonomy terms in code

I'm running Orchard v.<IP_ADDRESS> and developing a module.
In Migrations, I am creating a taxonomy and adding fields to the taxonomy term.
The problem I'm having is that when I go to the content definition view for the term, my fields are not appearing. I have determined the missing piece.
The first section of code below creates the taxonomy and it's term successfully.
Here (among others), a record created in Settings_ContentTypeDefinitionRecord.
The second section of code creates the fields for the term.
Here (among others), a record created in Settings_ContentPartDefinitionRecord.
The missing piece however is that a record is not being created in Settings_ContentTypePartDefinitionRecord tying together the ids from the Settings_ContentTypeDefinitionRecord and the Settings_ContentPartDefinitionRecord records.
When adding a field to a taxonomy from within the content definition view directly, this record is created automatically. Without it, the fields do not appear.
Can you tell me what call I can make to have this record created?
Sample Code:
var taxonomyName = "Merchants";
var taxonomy = _taxonomyService.GetTaxonomyByName(taxonomyName );
if (taxonomy == null)
{
taxonomy = _orchardServices.ContentManager.New("Taxonomy").As();
taxonomy.Name = taxonomyName;
taxonomy.ContentItem.As().Title = taxonomyName;
_orchardServices.ContentManager.Create(taxonomy);
_orchardServices.ContentManager.Publish(taxonomy.ContentItem);
}
        ContentDefinitionManager.AlterPartDefinition("MerchantsTerm", builder => builder
            .Attachable()
            .WithField("Website", cfg => cfg
                .OfType("TextField")
                .WithDisplayName("Website")
                .WithSetting("TextFieldSettings.Flavor", "Large")
                .WithSetting("TextFieldSettings.Required", "False"))
        );

I think you are missing a step. You didnt create the term content type for the taxonomy. This is how I've done it:
private const string KnowledgeTaxonomyName = "Knowledge";

private void EnsureKnowledgeTaxonomy() {

    var knowledgeTaxonomy = _taxonomyService.GetTaxonomyByName(KnowledgeTaxonomyName);
    if (knowledgeTaxonomy == null)
    {
        knowledgeTaxonomy = _contentManager.New("Taxonomy").As<TaxonomyPart>();
        knowledgeTaxonomy.Name = KnowledgeTaxonomyName;
        knowledgeTaxonomy.ContentItem.As<TitlePart>().Title = KnowledgeTaxonomyName;

        // See this following step:
        _taxonomyService.CreateTermContentType(knowledgeTaxonomy);
        // Now the term content type exists (and therefore also its part)

        _contentManager.Create(knowledgeTaxonomy);
        _contentManager.Publish(knowledgeTaxonomy.ContentItem);
    }
}

Hi,
Thanks for your reply.
I had that line of code in at one point but I was getting duplicate content type records, so I removed it.
The term part itself is not my problem at the moment though I’ll explain my findings on the duplicate term part records in a moment.
My problem is the record that ties the term part to the content type for the part is not being created.
Using your code as an example, 2 of the tables and the resulting records affected by creating the taxonomy and the term are:
Settings_ContentTypeDefinitionRecord
Id     Name                        DisplayName              Hidden    Settings
50    KnowledgeTerm      Knowledge Term        0
Settings_ContentPartDefinitionRecord
Id     Name                        Hidden       Settings
69    KnowledgeTerm      0
The missing record that is causing the fields to not display on the content definition view is:
Settings_ContentTypePartDefinitionRecord
Id     Settings               ContentPartDefinitionRecord_id     ContentTypeDefinitionRecord_Id
95             69                                                          50

As for the duplicate content Type records, this is what I’ve found:
If you run the code example that you provided and then to create a field for the term programmatically use the following code:
ContentDefinitionManager.AlterPartDefinition(“KnowledgeTerm”, builder => builder
.Attachable()
.WithField(“MyField”, cfg => cfg
.OfType(“TextField”)
.WithDisplayName(“MyField”))
);
The resulting records are as follows:
Settings_ContentTypeDefinitionRecord
Id     Name                        DisplayName              Hidden    Settings
50    KnowledgeTerm      Knowledge Term        0
51    Knowledge2             Knowledge Term        0
Interestingly enough, I happened to find this morning that if the code is run in 2 steps as follows, the duplicate does not occur.
ContentDefinitionManager.AlterPartDefinition(“KnowledgeTerm”, builder => builder
.Attachable()
);
ContentDefinitionManager.AlterPartDefinition(“KnowledgeTerm”, builder => builder
.WithField(“MyField”, cfg => cfg
.OfType(“TextField”)
.WithDisplayName(“MyField”))
);
Sorry for being so long winded, but I’ve tried virtually all combinations in an attempt to find a solution. I hope that my findings will help you find a solution to my problem but also help with some the minor bugs I’ve discovered as well.
Thanks,
Juan
From: Devqon
Sent: Monday, August 3, 2015 8:05 AM
To: OrchardCMS/Orchard
Cc: Juan Quintana
I think you are missing a step. You didnt create the term content type for the taxonomy. This is how I've done it:
private const string c= "Knowledge";
private void EnsureKnowledgeTaxonomy() {
var knowledgeTaxonomy = _taxonomyService.GetTaxonomyByName(KnowledgeTaxonomyName);
if (knowledgeTaxonomy == null)
{
    knowledgeTaxonomy = _contentManager.New("Taxonomy").As<TaxonomyPart>();
    knowledgeTaxonomy.Name = KnowledgeTaxonomyName;
    knowledgeTaxonomy.ContentItem.As<TitlePart>().Title = KnowledgeTaxonomyName;

    // See this following step:
    _taxonomyService.CreateTermContentType(knowledgeTaxonomy);
    // Now the term content type exists (and therefore also its part)

    _contentManager.Create(knowledgeTaxonomy);
    _contentManager.Publish(knowledgeTaxonomy.ContentItem);
}

}
—
Reply to this email directly or view it on GitHub.

Don't create taxonomies by hand, create then through TaxonomyService. That will do all the necessary setup. If the issue persists that way too please re-open.

The TaxonomyService does not expose a method for creating taxonomies, only terms.
Did the op get this working?
Also, Devqon's reply is obsolete because the TaxonomyPartHandler calls _taxonomyService.CreateTermContentType() in its OnPublished handler. That's why you are getting a duplicate content type.
@Piedone: Any clarification on the proper way to set up a taxonomy, add terms, and create a taxonomy field in a migration would be greatly appreciated.

@hec-adam you're right, I'm sorry. Creating Taxonomies like this works on the almost latest source:
                if (taxonomyService.GetTaxonomyByName(name) == null)
                    contentManager.Create<TaxonomyPart>("Taxonomy", taxonomy => taxonomy.Name = name);

Sorry to be a pain but my original problem has never been addressed. I never had a problem with creating a taxonomy (aside from the duplicate term record). The problem I need help with is in creating fields for the taxonomy term.
The problem is not that the fields aren't being created in the database but that they do not display when you edit the content definition for the taxonomy term via the admin view or when adding terms to the taxonomy.
In my testing I discovered that a crucial record is not being added to the Settings_ContentTypePartDefinitionRecord table that links the term record in the Settings_ContentTypeDefinitionRecord table with the term record in the Settings_ContentPartDefinitionRecord table.
Once that record is added (I added the missing record manually), the fields display everywhere as they should.
Below is a test block of code to demonstrate what I am doing (I've incorporated the suggestion by @Piedone in creating the taxonomy).
If my code for creating the fields is incorrect, I'd appreciate feedback on the proper method. Thanks.
            //Create the Knowledge taxonomy
            var name = "Knowledge";
            if (_taxonomyService.GetTaxonomyByName(name) == null)
                _orchardServices.ContentManager.Create<TaxonomyPart>("Taxonomy", taxonomy => taxonomy.Name = name);

            // Create the fields for KnowledgeTerm
            ContentDefinitionManager.AlterPartDefinition("KnowledgeTerm", builder => builder
                .Attachable()
                .WithField("KnowledgeField", cfg => cfg
                    .OfType("TextField")
                    .WithDisplayName("Knowledge Field"))
            );

Well I am not sure exactly what you are trying to do, but "KnowledgeTerm" is not a part, it is a type. You add fields to parts not types, and I don't think you want the field to be part of the KnowledgeTerm type anyway.
You probably want to create a part (e.g. KnowledgePart) add your field to that part, and then attach that part to whatever content type needs the field.
Here is an example:
            // Get or Create Taxonomy
            var name = "KnowledgeTypes";
            var taxonomy = _taxonomyService.GetTaxonomyByName(name);
            if (taxonomy == null) {
                taxonomy = _contentManager.Create<TaxonomyPart>("Taxonomy", t => t.Name = name);
                // This will have triggered the TermContentType "KnowledgeTypesTerm" to be created
            }

            // Define Part
            ContentDefinitionManager.AlterPartDefinition(typeof(YourPart).Name, part => part
                .WithField("KnowledgeType", field => field
                    .OfType("TaxonomyField") // This should be TaxonomyField not TextField
                    .WithDisplayName("Knowledge Type")
                    .WithSetting("TaxonomyFieldSettings.Taxonomy", taxonomy.Name)
            ));

            // Define Type
            ContentDefinitionManager.AlterTypeDefinition("YourType", type => type
                .DisplayedAs("Your Type")
                .WithPart(typeof(YourPart).Name)
                .Creatable()
            );

I hope that helps.

I finally got it. I was hung up with the way Orchard creates the records when doing all this via the admin screen. When a user adds fields, a part is created behind the scenes with the same name as the type and then the part is associated to the type. I could have called the part anything I wanted rather than using the same name as the type...hence the confusion.
What I was missing was the following (which follows the 2 other chunks of code):
            // Associate the part to the type
            ContentDefinitionManager.AlterTypeDefinition("KnowledgeTerm", type => type
                .WithPart("KnowledgeTerm")
            );

Thanks for your help.


Convert caffemodel mobilenet

I want to convert a caffe model (https://github.com/chuanqi305/MobileNet-SSD) to mxnet model. When i run the command python convert_model.py MobileNetSSD_deploy.prototxt mobilenet_iter_73000.caffemodel ssd_converted or python convert_model.py MobileNetSSD_deploy.prototxt MobileNetSSD_deploy.caffemodel ssd_converted i get the following error:
Using mxnet as:
<module 'mxnet' from '/home/sstojanoski/.virtualenvs/mxnet/local/lib/python2.7/site-packages/mxnet/init.pyc'>
Warning: using pre-installed version of mxnet may cause unexpected error...
(export MXNET_EXAMPLE_SSD_DISABLE_PRE_INSTALLED=1) to prevent loading pre-installed mxnet.
Traceback (most recent call last):
File "convert_model.py", line 135, in
main()
File "convert_model.py", line 45, in main
prob, input_dim = proto2symbol(args.caffe_prototxt)
File "/home/sstojanoski/converter/mxnet-ssd-master/tools/caffe_converter/convert_symbol.py", line 306, in proto2symbol
sym, output_name, input_dim = proto2script(proto_file)
File "/home/sstojanoski/converter/mxnet-ssd-master/tools/caffe_converter/convert_symbol.py", line 227, in proto2script
max_size = math.sqrt(param.min_size[0] * param.max_size[0]) / input_dim[2]
IndexError: list index (0) out of range

the converter is too old and I do not have plan to fix it.

@stefanstojanoski I had the same trouble with you. Did you find the way to solve it?

@stefanstojanoski @zhreshold
I have following error when convert:
Traceback (most recent call last):
File "/home/prdcv/Downloads/pycharm-community-2018.1.3/helpers/pydev/pydevd.py", line 1664, in
main()
File "/home/prdcv/Downloads/pycharm-community-2018.1.3/helpers/pydev/pydevd.py", line 1658, in main
globals = debugger.run(setup['file'], None, None, is_module)
File "/home/prdcv/Downloads/pycharm-community-2018.1.3/helpers/pydev/pydevd.py", line 1068, in run
pydev_imports.execfile(file, globals, locals)  # execute the script
File "/home/prdcv/PycharmProjects/gvh205/mxnet_ssd/tools/caffe_converter/convert_model.py", line 168, in
main()
File "/home/prdcv/PycharmProjects/gvh205/mxnet_ssd/tools/caffe_converter/convert_model.py", line 150, in main
wmat = wmat.reshape(arg_shape_dic[weight_name])
ValueError: cannot reshape array of size 288 into shape (32,32,3,3)
Do you guys have any suggestion to solve it?

I am not converting the caffe model. You can train ssd_mobilenet512 with --data-shape 300. The model I trained got good accuracy 76% and is much faster that the model with 512 shape (82% accuracy). You can try this approach.

@stefanstojanoski i know i could do it but my purpose is to build a network as small as possible. Now im trying to modify mobilenet's network in Mxnet as similar as possible with mobilenet-ssd-300 model in Caffe. Can you give me some suggestion to do it @zhreshold ?

[Update] The caffe converter tool has issue with depthwise convolution layer in mobilenet. I fixed it manually and i could run mobilenet_ssd_300 model in Mxnet now with mAP=70.9% on VOC 2007

@titikid  Nice work. Can you send me the model, so i can try it? Thank you. My email is<EMAIL_ADDRESS>

@stefanstojanoski You can find them here https://github.com/titikid/DeepLearning

@titikid are you able to put your code for a MXNet MobileNet SSD 300 on GitHub so I can see and replicate it?

@madhavajay you can use mobilenet_ssd_300 models in my repo


[improve][test] Fix test retries for tests that don't call internalSetup

Motivation
Tests that support retries with TestRetrySupport class should call incrementSetupNumber method as part of initialization so that while retrying the test, it can be detected that the initialization methods should be called before retrying. This support is needed when BeforeClass/AfterClass methods are used for initializing the test state.
Some tests which extend MockedPulsarServiceBaseTest call the init method instead of using internalSetup where the incrementSetupNumber method is called. By moving the call to the init method, these tests will also properly handle test retries where initialization is done in a method annotated with @BeforeClass.
Modifications
Move the incrementSetupNumber call in MockedPulsarServiceBaseTest from the internalSetup method to init method.
Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

/pulsarbot rerun-failure-checks

Codecov Report

Merging #21422 (605b2cd) into master (a0f8b0d) will increase coverage by 38.74%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master   #21422       +/-   ##
=============================================
+ Coverage     34.55%   73.30%   +38.74%
- Complexity    12083    32573    +20490
=============================================
  Files          1711     1888      +177
  Lines        130708   140307     +9599
  Branches      14245    15420     +1175
=============================================
+ Hits          45172   102852    +57680
+ Misses        79503    29369    -50134
- Partials       6033     8086     +2053

Flag
Coverage Δ

inttests
24.17% <ø> (?)

systests
24.85% <ø> (+0.06%)
:arrow_up:

unittests
72.57% <ø> (+40.70%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1472 files with indirect coverage changes


chore(stuff): Fix bugs and add new email setting functionality

This PR resolves

MOPLAT-631 - On Android, the artwork details bottom sheet is missing the shadow
MOPLAT-630 - Swiping between artworks often opens the image overlay
MOPLAT-629 - Set max height for artwork images in Artwork screen
MOPLAT-638 - Can't send an album by email
MOPLAT-636 - Email settings aren't reflected in emails
MOPLAT-639 - Create album input goes off screen (Android)

Description
Fixes some bugs, adds some missing features and adds the ability to send email containing whole albums.
PR Checklist

[x] I have tested my changes on iOS and Android.
[ ] I have included screenshots or videos, or I have not changed the UI.
[ ] I have added tests, or my changes don't require any.
[ ] I added an app state migration, or my changes do not require one.
[ ] I have documented any follow-up work that this PR will require, or it does not require any.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Need help with something? Have a look at our docs, or get in touch with us.

Warnings

:warning:

It looks like you've modified a store model. If necessary, please be sure to add a migration to migrations.ts. See the migration-docs for more info.

  Generated by :no_entry_sign: dangerJS against adf6c5a6591e9e57568d11dcbbd785b7f9df2d7b


Fix Dockerfile issue

I copied the kvconfig.yml to the wrong place :(
Roll Out:

[ ] Remember to deploy both s3-to-redshift and s3-to-redshift-fast

LGTM


Correctness of Compiling Static While Loops

(This is from a synchronous discussion w/ @paili0628, so @paili0628 feel free to add any clarifications).
Counter Example (Sort of)
(Rachit: Added the code example here for ease of reading)
import "primitives/core.futil";
import "primitives/pipelined.futil";

component main () -> () {
  cells {
    p = std_reg(5);
    w = std_wire(5);
    A_exec_wire = std_wire(1);
    incr = std_add(5);
    l = std_lt(5);
    @external mem = std_mem_d1(5, 1, 1);
  }

  wires {
    static group A <1>{
      incr.left = p.out;
      incr.right = 5'd1;
      p.in = incr.out;
      p.write_en = 1'd1;
      // let w.out be the input to l.left
      w.in = incr.out;
      A_exec_wire.in = 1'd1;
    }

    static group B <1>{
      incr.left = p.out;
      incr.right = mem.read_data;
      mem.write_data = incr.out;
      mem.write_en = 1'd1;
      mem.addr0 = 1'd0;
    }

    w.in = !A_exec_wire.out ? p.out;
    l.left = w.out;
    l.right = 5'd6;

  }

  control {
    while l.out {
      static seq {
        A; B;
      }
    }
  }
}

The following file, test_static_while.futil.txt, produces different answers for when we compile "normally"/TDCC (it gives us 21 in the memory) vs. when we compile using the technique in #1431 (it gives us 15 in the memory). However, this program relies on the fact that undefined ports (e.g., when we read from an undriven combinational component) default to 0 in order to get the result we want. (so this discussion sort of relates to #922). I think that, if there are no undriven combinational cells that are ever being read from, it's impossible to make a counterexample and our compilation in #1431 is fine.
The basic explanation is this: the while loop is in the form while l.out { A; B: } where l is a std_lt cell. l uses the following continuous assignments: l.right = 5'd6; l.left = w.out, where w is a wire.
The key in the program is how w is driven: w is driven by incr.out when A is executing, whereas it is driven by p.out anytime A is not executing. We do this by adding the assignment w.in = incr.out to group A and then adding the continuous assignment w.in = !A_exec_wire.out ? p.out. A_exec_wire is driven by 1'd1 in A, but is not driven anywhere else, meaning that it defaults to 0 everywhere else. Therefore, w.in is driven by is driven by incr.out while A is executing, whereas it is driven by p.out anytime A is not executing (since A_exec_wire will default to 0 anytime A doesn't execute), as desired. This means that our trick from #1431 of "checking on the first cycle" doesn't actually work, since it will read from incr.out to check the condition, whereas we really should be reading from p.out to check the condition.
General Takeaway
In general, it seems there is a difficulty with while loop behavior in Calyx. For example, consider the following while loop: while port { body}. It seems, just from looking at this, that port should be checked in the time in between the end of the body's execution and the start of the body's next execution. However, if we want to avoid "wasting" a cycle in between the execution of bodies of the while loop, then this "in between" time doesn't actually exist: the last cycle of the body is immediately followed by the first cycle of the body's next execution.

I haven't looked into the example deeply yet but worth reading our documentation on undefinedness in presence of undriven reads

Wow wow wow; really nice work tracking this down to a concrete counter-example, @paili0628 and @calebmkim! Thank you for the complete code listing and the clear explanation. It's really helpful to keep the issue grounded.
I think your summary at the end is a perfect distillation of the semantic question here. "When" should we consider the condition to be evaluated? Or, to put it in terms of the programmer's obligation, when should the program be sure to make the condition defined and relevant?
Let's enumerate the possible answers to this question:

The condition is evaluated before the body executes, during a cycle in which the body must not be executing.
The condition is evaluated during the first cycle of the body's execution.
The condition may be evaluated at any time during or before the body's execution, so the body has an obligation to keep the condition value stable throughout its entire duration.
The condition is evaluated at some point before the first cycle of the body's execution finishes. But the body is not guaranteed to have started execution when the condition is evaluated. So the body has an obligation to avoid changing the condition's value during its first cycle. (Updating a register in the first cycle, and hence affecting the register's value in the second cycle, is fine.)

(I hope I am missing other possibilities, because none of these are 100% satisfying.)
Options 1 and 2 are meant to be direct reflections of our implementation strategies, for TDCC and this new compiler pass respectively. I don't like those options very much because they are really specific about exactly when the condition must be evaluated, which constrains how the compiler must work. What we want, I argue, is a semantic definition that allows either implementation to be correct—one that comes with a well-formedness "law" that disqualifies programs that can tell the difference between the two strategies.
Option 3 is tempting, but I don't think it works. Say your condition is driven by a register (the common case); you want to be able to update that register at any point in the loop's body. This policy would require loops to leave the register alone until the very end of the body, when they're finally allowed to make that exit decision.
Option 4 is a straightforward attempt to unify options 1 & 2. Basically, it says "the compiler's policy may be option 1 and it may be option 2; the program must be written carefully to avoid telling the difference." This is OK, but I don't love the fact that it still "thinks" in terms of clock cycles. The rest of Calyx's semantics (static stuff aside) don't say anything about individual clock cycles, just what happens before, after, or during other stuff.
Another category of approach could be to define the semantics differently for while loops with dynamic bodies vs. while loops with static bodies. That is a little bit unsatisfying too because we like the property where "static erasure" preserves program semantics. But perhaps we can still preserve that property, in the sense that the well-formedness requirements on while-static loops are engineered to be stricter than those on while-dynamic loops.

One possible answer to the question: "can we have undriven signals in this program" comes from this issue: https://github.com/cucapra/calyx/issues/1169
One of the conditions for something to be a @data component is that it doesn't affect a cell that shows up as a port for if or while. I think another way to parse this constraint is that ports in those locations are probably never allowed to take undefined values since that would mean that the guard for everything under the if might be triggered?
One way to think about undriven ports is that they are allowed to take any value they want so perhaps that's the reason this program should be ruled out

@calebmkim implemented the requirement that conditional ports are @stable (https://github.com/cucapra/calyx/pull/1467) and @paili0628 implemented the proposed compilation scheme for unbounded loops (#1431)


Add Xi'An University of Finance and Economics

Official website(in chinese): https://www.xaufe.edu.cn
We have a Information Institute provided CS and SE major, see the intro page(also in chinese): https://www.xaufe.edu.cn/yxsz1/xxxy1.htm for more details.
We use @xaufe.edu.cn as a school issued email suffix for students, you can view it at the email login page(also, in chinese). The @mail.xaufe.edu.cn suffix is for faculty use.
Last, I use the school issued email as a git commit email to let you make sure it's vaild for use.

@shaokeyibb First stage of verification passed, official domain is xaufe.edu.cn as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@shaokeyibb Thank you for your patience while waiting for a review and processing your request. Pull request merged.


g4music: 3.7.2 -> 3.8 and rename package to gapless

Description of changes
Simple update, but also rename the package to gapless which seems to be the new name, see: the flathub or the repo for proof of this.
Also removed myself as a maintainer, mainly because I don't really use the app much anymore due to having mostly qt apps these days, so it doesn't make much sense for me to maintain it anymore (I was going to do this anyway so might as well do it in this pr).
I don't know if there is some specific things needed when renaming packages, so this might not be perfect. I also kept the mainProgram to g4music since the binary is still called this.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

(Builds already passed)


Mention security issue in issue template

Just got an idea, Github supports multiple issue templates, you can try that on most https://github.com/dnncommunity repositories. There is one for a bug, another template for an improvement, feature request, etc. I suggest adding a template for a security related issue, that template could have in uppercase a clear message to not submit this issue on github and give the security email address instead.


Question : Need to hide or redirection on URL

Hello
This is a question because I cannot find in documentation how to hide an url
For example, I would like to hide /config/* urls
Is there a solution with Kong ?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: myapp
  namespace: staging
  annotations:
    kubernetes.io/ingress.class: "kong"
spec:
  tls:
    - hosts:
        - toto.app.com
      secretName: cert
  rules:
    - host:
      http:
        paths:
          - path: /
            backend:
              serviceName: myapp
              servicePort: 8080

I would like to hide /config/* urls

Could you elaborate on what you mean by "hide"?
Is that you would like to not expose paths starting with /config outside the cluster?

exactly

You can create a /config ingress rule and point that to a different service which returns back a 404. Or you can create that Ingress rule and use Kong's request-termination plugin to terminate requests on that path at Kong itself.

good idea it's works ! thanks !
- host:
  http:
    paths:
      - path: /config
        backend:
          serviceName: dummyyyyy
          servicePort: 8080


feat(pixels): add my new pixel(3,8)

Checklist

[x] I ran npm test locally and it passed without errors.

[x] I only edited the _data/pixels.json file.

[x] I entered the username in the pixels.json that I'm also using to create this pull request.
[x] I acknowledge that all my contributions will be made under the project's license.

Sure!I will remove it as soon as possible!!Thank you for your feedback!!
On Wed, 23 Oct 2019, 12:10 a.m. Tilde Ann Thurium<EMAIL_ADDRESS>wrote:

@annthurium requested changes on this pull request.
hi
In _data/pixels.json
https://github.com/twilio-labs/open-pixel-art/pull/1404#discussion_r337686222
:

@@ -816,5 +817,6 @@
{"y": 39, "x": 37, "color": "#00b2e2", "username": "duncanleung"},
{"y": 39, "x": 38, "color": "#000080", "username": "rmkubik"},
{"y": 39, "x": 39, "color": "#0f111a", "username": "PrateekPunetha"}

hi there. Thanks for your contribution! Would you mind removing the empty
line on 829? Everything else looks good.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/twilio-labs/open-pixel-art/pull/1404?email_source=notifications&email_token=AK3WBCJ5BQUGALATGRXC3PTQP5CLBA5CNFSM4JDTCUJKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCI2G2OY#pullrequestreview-305425723,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK3WBCI47GY52WPP7DCXDPDQP5CLBANCNFSM4JDTCUJA
.


feat(inquiry): implements basic info step

Implements the "basic info" step. I'm going to follow this up with an update to Metaphysics to expand the mutation there to support these other fields (location, phone number).
https://user-images.githubusercontent.com/112297/130673517-5cfd74d9-0ae8-4549-9f98-fa946ba0f7fc.mov

Woops, forgot to add the spec for this one. BRB


remove glycoprotein trimming terms representing molecular functions

GO:0036511	trimming of first mannose on A branch
GO:0036512	trimming of second mannose on A branch
GO:0036509	trimming of terminal mannose on B branch
GO:0036510	trimming of terminal mannose on C branch
GO:1904382	mannose trimming involved in glycoprotein ERAD pathway (this one is an MF and a process. A n annotation to the correct molecular function term
i.e.
mannosyl-oligosaccharide 1,2-alpha-mannosidase activity involved in
GO:1904382	glycoprotein ERAD pathway
the actual moiety which is trimmed is actually more  specific info than we have on current MF terms, but if we want them, they should move to the MF ontology

Looks like this was done on purpose based on the complexity of the biology:
#11888

OK


[VS Code] Already connected to a workspace.

Error:
Already connected to a workspace.
Steps to Reproduce:

Version Data

extensionName
VSLS

extensionVersion
0.3.834

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.28.2

platformName
Linux

platformVersion
4.15.0-36-generic

Hi,
Thanks for reporting the issue. To help us investigate, could you please describe how you got into this state? Also can you please run the command "Live Share: Export Logs" and drag-and-drop the zip here or send it to<EMAIL_ADDRESS>

I'm going to resolve as a dupe of #1123. If you can get the logs, please attach them either here or on #1123.


Revert to 0.x releases.

We depend on glam which is a 0.x release. That means whenever glam bumps its version, we have to bump our major version. (2.x).
I have no idea how to do this. Maybe just yank all the versions? This kinda sucks...

Fixed by 2edfd25.


Add process_running and process_total to LoadAvg

In this test file, they would be 1 and 135, respectively.
Not sure how to implement this myself - I'll look into it likely tomorrow - just wanted to match diamond's loadavg collector here.

Hi, the content was based on Ubuntu Linux:
Something like this:
0.00 0.02 0.05 1/230 22187

Yeah I'm aware. I'm just learning golang, so I haven't yet gotten to how strings.Fields() works :)


ench: Making a globalcontext slice for org & workspace

Notes for Reviewers
This PR fixes #
Signed commits

[ ] Yes, I signed my commits.

@rishabhsharma1997 Let's discuss this issue during the Meshery dev meeting call. Please add it as an agenda item to the meeting minutes.


Add open file descriptor test

https://developers.redhat.com/articles/2023/01/09/how-use-valgrind-track-file-descriptors#valgrind___track_fds_yes

valgrind needs to be 3.23.0 version for --track-fds to work https://valgrind.org/docs/manual/valgrind_manual.pdf

computers at school have 3.18, so this will not be done


group Issues Per Label by category type

via Slack:

This part might be a bit messy, but
Issues Per Label should be grouped by category type (`status`) and then sorted by number
with a hr or something between successive categories

where category type is the ": " prefix. (for RubyGems this would be type, status, category, platform, contribution.)

Got a ways in and realized the entire section I'm working in needs refactoring. So, gist of my current WIP code for reference later: https://gist.github.com/duckinator/e7e6fac4cdba10a7c1e483fbb9711d66#file-report-rb-L42

Closing in favor of #244.


Screenshots?

I would like to see some screenshots of what the app can look like before I spend the time implementing it. Can you include some in the README and post them to this issue so I get a notification?

Closing old issues in preparation for the new version of the library. Thank you for your input, I will take it into account when writing the new documentation!