Global param store?

Curious why all the params are auto-magically global with a shared namespace. Seems like a very different design choice than the nice cleanly scoped pytorch variables.

We're definitely planning to add a dynamic scoping mechanism of some sort for both param and sample, it just didn't make it into this release.  See #73 for some discussion about this.

Sorry, but I don't really get this. The plan seems to be to copy TensorFlow's heavyweight design. PyTorch is so nice because it piggybacks on python's natural scoping rules.

For models that can be written as nn.Modules, where all parameters can be created before function evaluation, pyro.module will add the correct scope to the parameter names automatically.
Unfortunately, parameters in Pyro don't always work this way; consider e.g. per-datapoint variational parameters that are created on the fly each time a new data point appears.
sample statements are also problematic because names are used to identify corresponding random variables in models and guides, which may have arbitrarily different control structure.  Lexical scoping for sample names would break this identification.

Not sure I understand.
Why should you be able to sample a random variable that you don't have pointer access to? Needing to do that sounds dangerous.
Why does having non-global scoping prevent per-data point parameters? Presumably whatever object is creating the parameters should own them, not some global store.

(Sorry, this library is great, and I was thinking of using it for teaching. But I am really worried about this design decision.)

(Sorry, this library is great, and I was thinking of using it for teaching. But I am really worried about this design decision.)

No problem! The parameter store is definitely a weak point, and this is great feedback.

Why does having non-global scoping prevent per-data point parameters? Presumably whatever object is creating the parameters should own them, not some global store.

nn.Modules expose references to all of the parameters of their child modules, making it possible to completely separate the definition of losses that only interact with output and optimizers that only interact with parameters and gradients.  Since Pyro models can be regular Python functions that call other regular Python functions, you can't in general automatically track parameters through the call stack in the same way, so it seems to me that you end up with something that looks like a parameter store.  I guess we could have a per-model parameter store instead, though, sort of like a dynamically generated nn.Module wrapper for a function with param calls.

I guess I get that, but now I'm much more worried about this type of name matching though. This feels very scary though.
If model was a class with member z_1 = sample. Then this could be done correctly instead of asking the user to manage this alignment.
""To be very explicit, if the model contains a random variable z_1
def model():
pyro.sample("z_1", ...)
then the guide needs to have a matching sample statement
def guide():
pyro.sample("z_1", ...)
The distributions used in the two cases can be different, but the names must line-up 1-to-1."""

I guess I get that, but now I'm much more worried about this type of name matching though. This feels very scary though.

To compute the Monte Carlo Elbo log(P_model(observations, latents) - log(P_guide(latents)) where latents ~ P_guide, you need to be able to identify sample statements in the model with sample statements in the guide so that you can compute individual terms log(P_model(latent_i | ...)) - log(P_guide(latent_i| ...)).

If model was a class with member z_1 = sample. Then this could be done correctly instead of asking the user to manage this alignment

In Pyro, we made the choice to completely separate the definitions of model and guide and allow both of them to be callables with arbitrarily different structure and control flow, so there has to be some way to identify latent_i in the model with latent_i in the guide.  The user pays for this flexibility by having to manage things themselves, but could implement the safer functionality you describe on top of the more general behavior we provide.

Okay, sure. I get it, I just disagree.
I would love to have a PyTorch style mode that looks like this:
"""
class Model:
def init(self):
self.z_1 = pyro.sample()
def forward(self):
....
def Guide:
def init(self, z_1):
self.z_1 = pyro.sample()
def forward(self):
...
m = Model()
g = Guide()
SVI2(variational= [[m.z_1, g.z_1]...])
"""
This seems clean to me, has no globals, and could even allow you to reuse guide functions that with differently named samples.

This seems clean to me, has no globals, and could even allow you to reuse guide functions that with differently named samples.

This is actually the design in Edward (e.g., bayesian_linear_regression.py). This is difficult for dynamic graphs where it's harder to specify that matching a priori as the sets of random variables can change during runtime.
The string-matching is a sensible solution for Pyro. A similar manual alignment could, for example, assume identical class members in Model and Guide.

Could one of you give me an actual example that can't be handled with real variable scoping? Just asserting that this is reasonable is not convincing. It seems to me like PL 101 that a programming language should avoid having the user reinvent scoping using all global string lookups.
You say that this is a problem with dynamic functions. But PyTorch is a dynamic graph library that never requires the user to do this kind of black magic.

An example of what we're discussing is air.ipynb. I think it's very possible to solve with non-global scoping.

Manual alignment of different names in model and guide is a separate issue from scoping.  It's actually possible now to do manual alignment in Pyro; that functionality is already implemented in ReplayPoutine, and could easily be exposed to SVI.
I guess I don't really understand what you're proposing.  Scoping for samples is about names, not access; sample statement inputs and outputs are lexically scoped just like function applications.

@dustinvtran Not sure I understand. I'm arguing that global scoping is not necessary.
@eb8680 I see these issues as very connected. The fact that string alignment is done this way is a warning sign symptom of a programming language that is using a problematic internal scoping model.
I made my proposal above. If you want to expose something to an inference algorithm, you should have to have a reference to it, not a string in a global namespace.
Innumerable programming languages thought it was a good idea to have global string references (early php, javascript, etc.) but that always turns out to be a bad idea, and we think of them bad languages to work with. It seems early enough that pyro can avoid this issue.

@srush I updated my example to make my point clearer.

If you want to expose something to an inference algorithm, you should have to have a reference to it, not a string in a global namespace.

But the namespace isn't global, it's local to the model.

It seems effectively like a global to me. You access it by constructing its global string name, not by having a reference to it. Compare this to the way PyTorch params respect the natural scoping rules of python. You cannot magically access them, you need a reference. This is how I expect non-global variables to work.
I think I understand your example. How about this?
class Model:
    def __init__(self):
        self.mus = pyro.LatentList(dist.normal) # no string global name, can't be accessed without pointer
        self.x = pyro.Latent(dist.normal)

   def forward(self):
           mu = self.mus.next_sample(torch.zeros(1), torch.ones(1))
           for i in range(t):
               self.mus.next_sample(mu, torch.ones(1))
           return self.x.sample(mus[-1], torch.ones(1))

def Guide:
    def __init__(self):
        self.q = pyro.LatentList(dist.normal) # no string global name, can't be accessed without pointer

   def forward(self, t):
       return [self.q.next_sample(pyro.param()) for i in range(t)]

m = Model()
g = Guide()

SVI2(variational= [[m.mus, g.q]...])

we've talked about doing things of this sort (LatentList etc.) but more so as an additional construct for helping the user deal with names than as a total replacement. my concern would be that some use cases won't be adequately covered using some set of built-in constructs like LatentList and we'd end up with an ever expanding zoo of such constructs. for example, one of our inference tests uses a conjugate gaussian model with the structure of a N-layered pyramid. see this figure for N=3:
https://gist.github.com/martinjankowiak/af061c7a00e86e2874a217a0853efb2c
on the left is the model and on the right is (one possible factorization) of the guide. the way in which i need to sample things in the guide is quite different from the natural ordering in the model. constructing the guide and aligning it with the model using some generalization of LatentList might be a bit unwieldy and awkward. it might also be tricky to write multiple guides with different factorizations for the same model. of course, having the user provide explicit names can be tedious too, but at least he or she has the flexibility to support all possible model/guide structures/alignments.
we all agree that we need to think through how naming works more carefully, and this is certainly a good time to be doing it. i think it's definitely worth taking a look at various constructs like LatentList. i'd want to see that they can provide all the flexibility we want before making any breaking changes to how names work in pyro. in any case thanks for your suggestion: these are exactly the kinds of conversations we were looking forward to having once we opened up the repo : )

Thanks Martin. That's helpful to know.
Let me reiterate my point once more though, because I feel it is being lost. My argument is not for a particular style of handling locals (I made up this latentlist thing on my phone), but it is against globals as a default option that is the "documented way to do it". If there are corner case models that really require string matching based alignment, then have a LatentDict object that is owned by that part of the model and can use whatever strings it wants giving the ability to "support all possible model/guide structures/alignments". You can then do something similar in the guide and match them up. This has all the functionality you want but does not requiring what to me feels like late 90's PHP query string construction.

I think we all agree it would help to have more concrete examples 😃 To help explore syntax, I hacked together a pyro.anon module on an anonymous-sites branch (never intended to be merged). This has a single example examples/anonymous.py that actually runs in Pyro. @srush does this look any closer to your ideal syntax? If so, would you be able to provide a more complex example? If not and I've missed your point, perhaps we should all meet over video conference to help clarify.

Yeah!  This is perfect, exactly what I imagined. Maybe can be bit less verbose, but it checks all my boxes. Also it is heighrarchical, so you can easily nest groupings of latent variables without string building. (It's kind of a statemonad in Python).
My one quibble is that it still matches the guide variables by name match, but otherwise way better.

@fritzo that's pretty neat.  It might make sense to implement a LatentObject layer on top of nn.Module, so that those sorts of models can inherit Module parameter handling directly.
@srush we'll definitely consider including something like that as we iterate on naming and scoping, though I see it existing alongside with rather than replacing the current syntax, much like torch.nn exists alongside the raw autograd API.

So just imagining a bit how you could make this even more friendly.

Maybe this is too much, but you could have a @pyro decorator that wraps this class thing, and returns the object with all the contained variables. That way it makes it easy to build up models as little blocks.
Since these functions are lazy. I am imagining that the explicit alignment in SVI could be done by passing in a lambda.
Since models are stacked. You can pretty print all the variables based on how they are grouped in the code.

@pyro
def TimeSeries(model, obvs):
        model.sigma = anon.param(Variable(torch.ones(1), requires_grad=True))
        model.steps = []
        for obv in obvs:
            prev = models.step[-1] if model.steps else Variable(torch.zeros(1))
            model.steps.append(TimeStep()(obv, models.steps[-1], model.sigma))

@pyro
def TimeStep(model, x, prev, sigma):
       model.y = anon.sample(dist.normal, prev, sigma))
       model.x = anon.observe(dist.normal, x, prev.y, sigma))

@pyro
def Guide(model, obvs):
        model.mus = [anon.param(Variable(torch.zeros(1), requires_grad=True)) for _ in range(len(xs))]
        model.sigmas = [anon.param(Variable(torch.ones(1), requires_grad=True)) for _ in range(len(xs))]
        model.ys = [anon.sample(dist.normal, model.mus[i], model.sigmas[i]) for i in range(len(xs))]

def main(args):
    model = Model()
    guide = Guide()
    optim = Adam({"lr": 0.01})
    inference = SVI(model, guide, optim, loss="ELBO",
                              align=lambda m, g: return [([s.y for s in m.steps], g.ys) ])
    data = Variable(torch.Tensor([0, 1, 1, 0, 1, 2]))
    for step in range(args.num_epochs):
        if step % 100 == 0:
            loss = inference.step(data)
            print('{}\t{:0.5g}'.format(step, loss))
    print('Parameters:')

    # Will automatically collect all the sub variables and
    for name in model.get_all_variable_names():
        print(name)

haha @eb8680 good design is not about compromise, I would encourage you to make a choice :) torch.nn is not a great analogy, as it is entirely built on top of torch.autograd. Building a nice well scoped library, on top of scary functions like clear_param_store() will be dangerous.

Since these functions are lazy. I am imagining that the explicit alignment in SVI could be done by passing in a lambda.

I agree. To reiterate my last comment:

More generally, the alignment could be an arbitrary callable passed into SVI that creates the dictionary/list thing. (Although clunky, I actually think this lattermost design makes sense for puritanical reasons in that the alignment is a feature during inference and not a feature during model/guide specification.)

Oh yes @dustinvtran I agree. I was mostly responding to a change to @fritzo 's sample code. My main mission here is to kill the global variable store. I see these string alignment sub-issues as symptoms of the global variable store.

@srush I like your decorator idea. I've updated examples/anonymous.py to use an @anon.function decorator similar to your @pyro. The resulting modeling language looks good but has lots of sharp edges.

Nice! This is looking great, let me play around a bit and try some of the examples.

Curious does it chain? Could we call a subfunction and assign it's returned latent to a member?

I think I might also be in favor of making the user call LatentList, LatentDict explicitly (kind of like ModuleList in pytorch).

Oh wait, I see @fritzo . So the LatentList thing is only there to ensure that all of the anon's have names that match their variables? So it automatically calls them "x[0]" "x[1]" etc.?
What's the argument for why that is necessary? Now that you have actual objects, why not just give them a random address?

pyro.sample(uuid.uuid4(), ...)

Am I missing something?

Could we call a subfunction and assign it's returned latent to a member?

Hmm assignment from a return value doesn't generally work yet (since the returned latent must be attached to the top-level model before* assignment). But it does work to let subfunctions mutate parts of the latent:
@anon.function     # Decorator is only used for top-level models.
def model(latent, size):
    latent.params.mu = Variable(torch.zeros(1))
    latent.params.sigma = anon.param(Variable(torch.ones(1))
    latent.samples = []
    my_subfunction(latent.params, latent.samples, size)

def my_subfunction(params, samples, size):
    for i in range(size):
        samples.append(anon.sample(dist.normal, params.mu, params.sigma))

Am I missing something?

One crucial behavior you might be unaware of is that pyro.sample() statements execute differently depending on their name. In the model, we need to know the name of a sample statement before executing it, so that if it was sampled as part of the guide we can use that value instead.

oh! I see, that makes a lot of sense. That also explains a lot of the decisions I didn't understand.

yep, refer to the elbo implementation to see how the 'alignment' occurs under the hood.  in _get_traces() we get the trace of both the model and the guide, and then we use the value sampled from the guide (in the guide trace) to calculate the ELBO. this matching happens via unique sample names

Hmm, so given that this swap happens through some cps/poutine trick that is invisible to the user,
and I assume happening at a global level. Maybe in the anon version latent should also be the object that controls sampling?

latent.y = latent.sample(dist.normal, prev, sigma)

That way the user can grok that latent may have different semantics depending on its caller, versus anon.sample which looks harmless.

Here's a similar notation that works: examples/attribute.py. Feels very protobuffy.

I like it.
The object setting is a little too weird for me though :) Maybe go even more protobuffy?

latent.mus = LatentList() #

....

latent.mus.add().param(Variable(torch.zeros(1), requires_grad=True))

I think dict could work out of the box as well.

latent.qs = LatentDict()

...

latent.qs["new"].param()

@fritzo  Okay, I went through and ported all the documentation to use anon. (I mostly did the intro and svi. a lot of the other documentation is not runnable. )
https://github.com/harvardnlp/pyro/tree/anonymous-sites/tutorial_ette/source
Mostly it worked great. Here are the remaining issues I saw:

Instead of using the decorator, I just used latent as the first arg. To get this to work, I made a wrapper for passing into SVI etc. Think this is less magic, although maybe these functions could just know to do this.

def anonwrap(fn):
    def wrap(*args):
        latent = anon.Latent("")
        return fn(latent, *args)
    return wrap

The inference objects (SVI) don't return or carry the current latent state or parameters. The only way I could figure out how to get out the parameters afterwards was by using a global call to param. Seems like you should be able to get to the current guide parameters through SVI object.

alpha_q = torch.exp(pyro.param(".log_alpha_q")).data.numpy()[0]

Similarly .marginal seems to return a dictionary. But it should instead return a (maybe read only) Latent object.

Yeah, the [object() for _ ] notation is tough. Think that's an easy fix.

The biggest issue I saw was with the condition function. That function is cool, and useful. But it needs to give the observations as a dict with strings....

conditioned_scale = pyro.condition(
    scale, data={"measurement": Variable(torch.Tensor([8.5])), "xs_1": Variable(torch.Tensor([1]))})

I think the anon version should have these string names be not globals, but localized to the function (scale). Also we should be able to pass in arrays and reference nested modules "submodel.mu".
Maybe for complicated data, there should be a data_fn=obs where obs is a function that takes latent and fills in variables it wants.

There is a similar issue in the sites argument of some of the inference algorithms. Not sure how to get around a string argument there. Maybe something like: sites=lambda latent: [latent.weights]

There seem to be global params in pyro.iarange("data_iarange") but honestly I found the documentation unreadable and gave up. random_module also seems to create a variable name and could maybe be included in latent. That function seems incredible though, I gave up trying to understand.

Okay, fixed most of these issues in my branch:
https://github.com/harvardnlp/pyro/blob/anonymous-sites/pyro/anon.py
https://github.com/harvardnlp/pyro/blob/anonymous-sites/tutorial_ette/source/intro_part_i.ipynb
https://github.com/harvardnlp/pyro/blob/anonymous-sites/tutorial_ette/source/intro_part_ii.ipynb
https://github.com/harvardnlp/pyro/blob/anonymous-sites/tutorial_ette/source/svi_part_i.ipynb
There is some more to do, but I think this already way cleaner, maintains scope, makes the semantics cleaner, supports real arrays and nesting, and uses less code.

Trying to find a compromise that we could merge soon: #540

@srush thanks for your ongoing feedback.  This issue keeps growing in scope, and it would be really helpful if you could open new issues about things like inadequate documentation for iarange and random_module.
As I said, you've made some great points about the parameter store, whose design was largely borrowed from webPPL, and changes like the ones you've sketched seem like clear wins.  We're also more than willing to include an anon-like module ( #540 ), provided it's properly fleshed out.
However, let me try to give some more background on the way sample names work to explain why a similar solution is not an unambiguous improvement there:

The biggest issue I saw was with the condition function. That function is cool, and useful. But it needs to give the observations as a dict with strings...

There's not really any way around this, and condition is not just a cool feature that can be ignored or removed; it or something like it is essential for implementing advanced inference algorithms like EP or particle Gibbs with arbitrary guides.

There is a similar issue in the sites argument of some of the inference algorithms. Not sure how to get around a string argument there

You've also identified the same fundamental problem with your model-guide alignment solution: in general, aligning execution traces or observations with an arbitrary Pyro program can be as hard as executing the program, since you need to refer to variables before they exist.  As @fritzo said:

In the model, we need to know the name of a sample statement before executing it, so that if it was sampled as part of the guide we can use that value instead.

A corollary to this fact is that in Pyro's current incarnation, sample names don't really correspond conceptually to Python variable names and scopes, and there's no particular reason that they should unless the model and trace being aligned already share the same structure; think of them instead as tags or database queries attached to stochastic function applications (where the function and its return value could both be anonymous Python variables) that solve the problem of alignment by construction.
This design choice is rooted in both practical considerations and historical context.  A particularly common workflow in Pyro is to write a single model, then write multiple guides specific to that model with different structure and one or more condition/do queries and combine these ingredients with SVI.  We don't particularly like string manipulation either, but Pyro's sample names mean that, rather than effectively re-expressing the model's control flow for every guide and condition query in the form of a new alignment, we only need to write it once.  Other naming/addressing schemes, like the one in anon, can only move complexity around to different places, and we feel that the current approach works well in the use cases we've explored in depth.
Historically, previous universal PPLs like Church, webPPL, Venture, and Anglican handled alignment by automatically generating name strings based on call stack position (which could be done easily in Pyro with Python's advanced runtime introspection facilities, e.g. a memoized version of traceback.extract_stack()).  Guides were handled by threading the guide code through the model code (as in webPPL) or by simply not allowing arbitrary guides.  condition is also a new construct for a universal PPL; previously observations were handled by threading data through models.
Building up names manually through Pyro programs instead of data and guides is one natural generalization of these previous approaches.  It cleanly separates the specification of model, data, and inference, and provides a clear point of contact for more advanced techniques (like code transformations, static analysis, alignment specifications like your proposal that completely decouple model and guide names, or the current implementation of anon (!)) that reduce the burden of manual naming when possible.
As @dustinvtran said, Edward's behavior is closer to what you have in mind.  This is precisely because it is possible to refer to nodes in a TensorFlow graph before you know their values, which also limits Edward's expressivity.  Indeed the alignment mechanism you added to your anon example, which uses simultaneous references to model and guide variables with no strings, is only possible if anon is placed under similar constraints, such that it would effectively be identical to Edward (albeit with lexical scope rather than TensorFlow's dynamic scope).
Ultimately, we only see Pyro as one hypothesis in the space of possible language designs.  It may well turn out to be a bad hypothesis!  That said, our development process was driven by the interaction of our design principles, properties of previous PPLs, and our tests and anchor examples, and we found that what we have strikes a good balance.  Larger changes to the syntax and internals to Pyro represent different hypotheses, and should generally be justified on the basis of similar evidence.

Wait, sorry, I'm confused by this response. I think the last anon solution I posted and wrote examples for captures everything you would like, i.e. keeping around arrbitrary condition statements and the alignment of guides, while also providing a syntax that doesn't require the user to reason about a global store or global CPS. Which part of that is a failure?

Which part of that is a failure?

There's no failure here!  I'm just trying to point out that anon is a different point on the Pareto frontier induced by the fact that models, guides, and data can be arbitrarily different.

I meant in the sense of "what flexibility is it giving up?". Different point implies there are negatives, but I don't see how it is more constrained.


Migrate to Rust 2018

This migrates all crates to Rust 2018.
The first commit contains the minimal changes needed for the migration. This was mainly done by cargo fix --editon.
The second commit migrates the code to be the Rust 2018 idiomatic style. This mainly based on suggestions from rust_2018_idioms lint.

Thanks!
bors r+


Bug: Old Files with calibrated data are not shown in the Plot Region

Issue: Files with calibrated data that are loaded into the software are not shown in the Plot Region.
Reproduction: Measuring with a calibrated device, saving the data, click on "Load old Data" and checking the box for the old data:

I currently dont know if the data is not shown at all or if it is shown in a wrong place.
Definition of Done:
Data of a loaded file should be shown as it was before in the Plot Region :

Yes, as told you, it certainly does.
Found the source of the issue and need to get what was meant to be done by the code then fix the bug.

https://github.com/skunkforce/OmniView/pull/177


Update copyright year in documentation

Proposed changes:

Update copyright year from 2017 to 2018

Status (please check what you already did):

[x] made PR ready for code review
[ ] added some tests for the functionality
[x] updated the documentation
[ ] updated the changelog

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

thhanks :+1:


Move pandas upper bound to 2.2.0

Move pandas upper bound to latest release (2.2.0 as of today).

Thanks, FYI @fdosani if you look in the actions tab, apparently our edgetest runs are failing silently.

Will take a look!

Thanks for the quick turnaround -- any chance you'll be cutting a release soon?


user.network-config not passed into the container

Required information

Distribution: Ubuntu
Distribution version: 16.10
The output of "lxc info" or if that fails:
apiextensions:

storage_zfs_remove_snapshots
container_host_shutdown_timeout
container_syscall_filtering
auth_pki
container_last_used_at
etag
patch
usb_devices
https_allowed_credentials
image_compression_algorithm
directory_manipulation
container_cpu_time
storage_zfs_use_refquota
storage_lvm_mount_options
network
profile_usedby
container_push
apistatus: stable
apiversion: "1.0"
auth: trusted
environment:
addresses:

<IP_ADDRESS>:8443
architectures:
x86_64
i686
certificate: |
-----BEGIN CERTIFICATE-----
MIIFZzCCA0+gAwIBAgIRAMeZgktaVRiendqhGAxOxoMwDQYJKoZIhvcNAQELBQAw
......
0223Mb4+cHgh4VUoys6vsZXz64mFDUa/gwmHRfyb9+BThRb7vh/iTnsumA==
-----END CERTIFICATE-----
certificatefingerprint: 02cc3f7c235af6ce3ce15d8e364b28d24ace2ce49a916f83c13f5537414c90d2
driver: lxc
driverversion: 2.0.5
kernel: Linux
kernelarchitecture: x86_64
kernelversion: 4.8.0-26-generic
server: lxd
serverpid: 1929
serverversion: 2.4.1
storage: btrfs
storageversion: 4.7.3
config:
core.https_address: <IP_ADDRESS>
core.trust_password: true
public: false

Issue description
I'm trying to setup containers with static IP addressing. I've tried to setup both profiles and individual containers with 'config.network-config':
:~$ lxc profile show bootstrap
name: bootstrap
config:
user.network-config: |-
version: 1
config:
- type: physical
name: eth0
subnets:
- control: auto
type: static
address: <IP_ADDRESS>
gateway: <IP_ADDRESS>
netmask: <IP_ADDRESS>
description: used for bootstrapping of containers
devices:
eth0:
name: eth0
nictype: bridged
parent: vlan2
type: nic
but when I spin up a container using that profile the seed data contains dynamic config:
root@test1:~# cat /var/lib/cloud/seed/nocloud-net/network-config
version: 1
config:
- type: physical
name: eth0
subnets:
- type: dhcp
control: auto
Steps to reproduce

Create user.network-config key in a profile
Spin up a container using that profile

Is this a feature or is it possible to pass static network config?

What image are you using exactly?
Support for user.network-config was only added to the image building scripts for the cloud images about a week ago, so it may still take a while before all images have support for it.
You can try grabbing an image from "ubuntu-daily" rather than "ubuntu", those should be more likely to have the change.

Looking on my local systems, those appear to be the images that have support for network-config:
root@dakara:~# ls -lh /var/lib/lxd/images/*/templates/*network*
-rw-r--r-- 1 root root 208 Oct 20 15:45 /var/lib/lxd/images/1e66f9fa622c0cf03ac395d6fddddcdb0a1ea08bd8753900b0f2a18acf42f2b3.zfs/templates/cloud-init-network.tpl
-rw-r--r-- 1 root root 208 Oct 20 13:57 /var/lib/lxd/images/315bedd32580c3fb79fd2003746245b9fe6a8863fc9dd990c3a2dc90f4930039.zfs/templates/cloud-init-network.tpl
-rw-r--r-- 1 root root 208 Oct 13 14:08 /var/lib/lxd/images/6f25adef061c3f2186c6910bff8cacd0c63e1493e3f8b616e52eb84076890bd1.zfs/templates/cloud-init-network.tpl

Oh, right, my check was wrong, you don't just need the template, you need the latest version of it.

Any idea if there are any ubuntu images that already have that newest version?

root@dakara:~# lxc launch ubuntu-daily:16.04 latest
Creating latest
Retrieving image: 100%
Starting latest

root@dakara:~# cat /var/lib/lxd/containers/latest/templates/cloud-init-network.tpl
{% if config_get("user.network-config", "") == "" %}version: 1
config:
    - type: physical
      name: eth0
      subnets:
          - type: {% if config_get("user.network_mode", "") == "link-local" %}manual{% else %}dhcp{% endif %}
            control: auto{% else %}{{ config_get("user.network-config", "") }}{% endif %}

So yeah, as I suggested above, using "ubuntu-daily" will get you an image with that feature.
Images in the normal stable stream will get this next time they're updated (I think it's every couple of weeks or whenever there's a big security issue to fix).

Just looking at that template - there is no way to generate 'static' entry (unless I'm completely blind) like the one I'm after:
version: 1
config:

type: physical
name: eth0
subnets:

control: auto
type: static
address: <IP_ADDRESS>
gateway: <IP_ADDRESS>
netmask: <IP_ADDRESS>

stgraber@dakara:~$ lxc profile create test
Profile test created

stgraber@dakara:~$ lxc profile edit test

stgraber@dakara:~$ lxc profile show test
name: test
config:
  user.network-config: |-
    version: 1
    config:
      - type: physical
        name: eth0
        subnets:
          - control: auto
            type: static
            address: <IP_ADDRESS>
            gateway: <IP_ADDRESS>
            netmask: <IP_ADDRESS>
description: ""
devices: {}
usedby: []

stgraber@dakara:~$ lxc launch ubuntu-daily:16.04 -p default -p test test
Creating test
Starting test

stgraber@dakara:~$ lxc exec test -- ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:3e:b4:9d:c6
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::216:3eff:feb4:9dc6/64 Scope:Link
          inet6 addr: fd42:a4f6:6365:4106:216:3eff:feb4:9dc6/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:69 errors:0 dropped:1 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8933 (8.9 KB)  TX bytes:750 (750.0 B)

stgraber@dakara:~$

Thank you for your help. This is exactly what I was after :-)


[Request] Java 8 Support

I am running 1.12.2 Modpack servers and unfortunately stuck at Java 8.
This looks like a fantastic plugin, is there any chance to get a Java 8 port?
Thank you.

Ignore. It seems that 1.3.4 supports older Java.


support existing secret docker-registry

What this PR does / why we need it:
To support existing secret.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign rendhalver

/assign davidkarlsen


Dialog in docs refer to MdDialog and not MatDialog

Bug, feature request, or proposal:
In the docs, is used the old Md prefix, isn't possible to provide some toggle between Md and Mat in the example code? Also, could be good some disclaimer about that update to use Mat instead Md prefix.
What is the expected behavior?
What is the current behavior?
What are the steps to reproduce?
Providing a StackBlitz/Plunker (or similar) is the best way to get the team to see your issue.
Plunker starter (using on @master): https://goo.gl/uDmqyY
StackBlitz starter (using latest npm release): https://goo.gl/wwnhMV
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Is there anything else we should know?
Sorry if isn't the right place to say this.

Most likely you're getting a cached version of the docs. The caching issues should be resolved next time we release.

any estimates of the next release, @crisbeto?


Update all deprecated methods and refactor gutter

Hi,
I've refactored to be compliant with the latest Atom APIs.
Everything seems to be working in Atom 0.201.0 but I can't get the node-debugger and node-debugger-view specs to run, all other tests are passing fine.
Cheers

Thanks mate, I will publish a new version from this pr.

No worries, Thanks for the great package


Update page with new highlights instead of delete and reimport

When importing an html file, it will check which highlights are new and only import them. It no longer checks if the page already exists.
This is needed if you want to import highlights while still reading a book. Otherwise any block ref and such would be deleted

When this merge will be approved?


Nightly check for Helm Upgrades

Goal
A pipeline scheduled to run daily should check that Helm upgrades of our charts work
Technical Details
A new workflow that verifies that we can upgrade our Helm chart from version x to version x+1.
A version matrix should be used to be ready to have tests for an upgrade from vx to vx+2.
The pipeline shall be run nightly like it is for the Keptn Integration Tests.
If the upgrade fails, we should generate an issue with the error message.
DoD

[ ] Tests for Helm upgrades are run nightly
[ ] An issue is created when it fails

Interested

Hi @DahunsiJ, are you currently working on this issue? If yes, do you need any support ?
Thank you!

I want to take up this issue @odubajDT

Thank you @rizul2108, assigned!

@odubajDT can you please elaborate i have to check for the upgrade for all 4 charts (as here in the workflow named validate-helm-chart.yaml) or only for the one in root directory
and I have to check for upgrade by comparing it with one on the registry online or with locally available Chart.yaml?

just the root keptn helm chart is enough for this, no need to test the subcharts, as they are dependencies of the root one

Ok thank you @mowies

Unassigned due to inactivity


Changing value in a multiple line value, thing breaks

Original YAML:
FOO: BAR
HELLO: WORLD

MULTIPLE_LINES_1: |
  Line 1
  Line 2
  Line 3
  Line 4

MULTIPLE_LINES_2: |
  Line 1
  Line 2
  Line 3
  Line 4

Modified JSON. Changing MULTIPLE_LINES_1 to:
{
  "FOO": "BAR",
  "HELLO": "WORLD",
  "MULTIPLE_LINES_1": "This line is changed",
  "MULTIPLE_LINES_2": "Line 1\nLine 2\nLine 3\nLine 4\n"
}

Output:
FOO: BAR
HELLO: WORLD

MULTIPLE_LINES_1: This line is changedMULTIPLE_LINES_2: |
  Line 1
  Line 2
  Line 3
  Line 4

Expected:
FOO: BAR
HELLO: WORLD

MULTIPLE_LINES_1: This line is changed

MULTIPLE_LINES_2: |
  Line 1
  Line 2
  Line 3
  Line 4

This is reproducible on http://azimi.me/yawn-yaml/demo/index.html, just paste Original YAML in first column and modified JSON in second column.

This might be related, but I found another one:
Original YAML:
FOO: BAR
HELLO: WORLD

Modified JSON:
{
  "FOO": "BAR1",
  "HELLO": "WORLD2"
}

Output YAML:
FOO: BAR1
HELLO:WORLD2D

As you can see, the value for HELLO is translated into WORLD2D, which is different from WORLD2.

I don't have enough time to work on this. I appreciate it if you look for a fix in the source. This lib is surprisingly simple


repo: Release 1.23.0

Commit Message: Release v1.23.0
Additional Description:
Risk Level: N/A.
Testing: N/A.
Docs Changes: N/A.
Release Notes: N/A.
Platform Specific Features: N/A.
Signed-off-by: Adi Suissa-Peleg<EMAIL_ADDRESS>

landed


[CM-1752] Collect email on Away Mode | iOS SDK

Summary

Added the regex to verify the email is in correct format.
Added the code to update email for user when passed is conversation while email collection is enabled (On Away Mode).

@coderabbitai review


build_geometry method is inconsistent

Hello,
the method build_geometry for the different types of geometry (i.e. Lamination, Slot, ...) is inconsistent, since the input parameter are not the same. Slots build_geometry method has no input parameter for example.
At least all build_geometry methods should have the alpha and delta parameter in common.
Best regard,
Sebastian

Hello Sebastian,
It is something that bother me also. The issue is that build_geometry for the Lamination and for the Slot are not the same thing. The Lamination one will return the corresponding surface list, the Slot one wil return a list of Line. So maybe the solution is to rename the slot method ? I have no objection to add the alpha and delta parameter to the Slot build_geometry method.
Best regards,
Pierre


[WIP] Extract topological_inventory-persister

cc @agrare
Here is the current extracted repo: https://github.com/ManageIQ/topological_inventory-persister  - It's not ready yet as I need to figure out db rake tasks still.

@Fryguy this ready to take out of WIP?

This can be better as is, and I will make a follow up PR with more specific removals after


Print out dictionary line number on match

(We've been talking about this for a while but wanted to consolidate as an issue @khaledJabr @philip-schrodt ).
Petrarch1 and Petrarch2 both had the ability to print out the dictionary line number of a match. This is very useful for debugging the dictionaries, since otherwise we don't know what pattern resulted in a coding. UniversalPetrarch does not have this ability and needs it so we can debug dictionaries.

Here's the original issue for this https://github.com/openeventdata/UniversalPetrarch/issues/40 @JingL1014  already made a suggestion to do something similar, but it is not quite the same thing as we're looking for.

It sounds like this is resolved now. Is that right? If so, we should close.

Yes. This is solved.


[Task]: Find directly referenced onPageLoad module instances

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks
No response

Resolved through this https://app.zenhub.com/workspaces/modules-pod-63e0d668a7fea03850c89c6f/issues/gh/appsmithorg/appsmith/27087


Convert Kakoune from Docbook to CommonMark

This issue tracks the conversion of /doc/builders/packages/kakoune.xml from Docbook to CommonMark per RFC 72.
If you intend to work on this conversion, please comment below!
Conversion instructions

Comment here that you intend to work on it. (Please also post if you stop working on it.)
Checkout a new branch of nixpkgs master.
Edit doc/builders/packages/index.xml: change kakoune.xml to kakoune.section.xml.
Rename doc/builders/packages/kakoune.xml to kakoune.section.md.
Convert the contents from Docbook to CommonMark. Follow conversion best practices. Use existing .md sections for inspiration.
Use nix-build from the doc/ folder to build the manual.
Preview the manual on your computer at http://<IP_ADDRESS>:8000/manual.html after running from doc/ folder:

nix-shell -p python3 --run 'python3 -m http.server --directory ./result/share/doc/nixpkgs'

When it looks good, submit a PR and reference this issue.

This is a very small file, I think it canm be done just now!


run: markdown preview edit window constricts text to narrow column

Expected: constraint the text comfortably to the width of the text area.
Actual

Hey @grayside, what is the next step here?

Any ideas on timeline? Working on cleaning up issues in this repo.

I expect this quarter.


Release v1.4.0 -> main

Merging of all prior reviewed changes to main for 1.4.0 release
Testing notes: https://cuhbioinformatics.atlassian.net/wiki/spaces/DV/pages/3114467337/eggd_conductor_testing_v1.4.0?atlOrigin=eyJpIjoiZjEwMzFkMzgyNmY0NDU1ZTllYTMyMWZkYTk1OTM3OTAiLCJwIjoiY29uZmx1ZW5jZS1jaGF0cy1pbnQifQ
Fixes #88
Fixes #89
Fixes #94
Fixes #98
Fixes #100

This change is

Hello @jethror1! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file resources/home/dnanexus/run_workflows/run_workflows.py:

Line 133:80: E501 line too long (82 > 79 characters)
Line 444:13: E122 continuation line missing indentation or outdented
Line 538:80: E501 line too long (82 > 79 characters)
Line 747:80: E501 line too long (80 > 79 characters)

In the file resources/home/dnanexus/run_workflows/tests/settings.py:

Line 3:58: W292 no newline at end of file

In the file resources/home/dnanexus/run_workflows/tests/test_dx_requests.py:

Line 333:5: E303 too many blank lines (2)

In the file resources/home/dnanexus/run_workflows/tests/test_manage_dict.py:

Line 14:1: E402 module level import not at top of file
Line 15:1: E402 module level import not at top of file
Line 445:13: E128 continuation line under-indented for visual indent
Line 447:13: E128 continuation line under-indented for visual indent
Line 449:13: E128 continuation line under-indented for visual indent
Line 451:13: E128 continuation line under-indented for visual indent
Line 456:80: E501 line too long (83 > 79 characters)
Line 608:80: E501 line too long (81 > 79 characters)
Line 1278:17: E131 continuation line unaligned for hanging indent
Line 1281:80: E501 line too long (86 > 79 characters)
Line 1285:80: E501 line too long (82 > 79 characters)
Line 1301:80: E501 line too long (83 > 79 characters)
Line 1302:80: E501 line too long (83 > 79 characters)
Line 1303:80: E501 line too long (89 > 79 characters)
Line 1304:80: E501 line too long (89 > 79 characters)
Line 1305:80: E501 line too long (89 > 79 characters)
Line 1310:9: E303 too many blank lines (2)
Line 1353:5: E303 too many blank lines (2)
Line 1382:5: E303 too many blank lines (2)
Line 1411:5: E303 too many blank lines (2)
Line 1435:5: E303 too many blank lines (2)

In the file resources/home/dnanexus/run_workflows/tests/test_run_workflows.py:

Line 14:1: E402 module level import not at top of file
Line 275:5: E303 too many blank lines (2)
Line 282:13: E122 continuation line missing indentation or outdented
Line 283:13: E122 continuation line missing indentation or outdented
Line 284:9: E122 continuation line missing indentation or outdented

In the file resources/home/dnanexus/run_workflows/utils/dx_requests.py:

Line 80:80: E501 line too long (81 > 79 characters)
Line 95:80: E501 line too long (85 > 79 characters)
Line 374:9: E125 continuation line with same indent as next logical line
Line 424:80: E501 line too long (81 > 79 characters)
Line 425:80: E501 line too long (80 > 79 characters)
Line 427:80: E501 line too long (90 > 79 characters)
Line 704:80: E501 line too long (86 > 79 characters)
Line 778:80: E501 line too long (85 > 79 characters)
Line 944:80: E501 line too long (94 > 79 characters)
Line 953:80: E501 line too long (80 > 79 characters)
Line 1001:80: E501 line too long (90 > 79 characters)
Line 1026:80: E501 line too long (83 > 79 characters)
Line 1070:80: E501 line too long (87 > 79 characters)
Line 1217:5: E303 too many blank lines (2)
Line 1254:5: E303 too many blank lines (2)

In the file resources/home/dnanexus/run_workflows/utils/manage_dict.py:

Line 17:1: E402 module level import not at top of file
Line 196:80: E501 line too long (88 > 79 characters)
Line 273:80: E501 line too long (81 > 79 characters)
Line 473:80: E501 line too long (80 > 79 characters)
Line 511:30: E272 multiple spaces before keyword
Line 874:5: E303 too many blank lines (2)
Line 880:9: E125 continuation line with same indent as next logical line
Line 968:80: E501 line too long (82 > 79 characters)
Line 974:80: E501 line too long (83 > 79 characters)
Line 1004:80: E501 line too long (81 > 79 characters)

In the file resources/home/dnanexus/run_workflows/utils/utils.py:

Line 61:80: E501 line too long (84 > 79 characters)
Line 77:80: E501 line too long (95 > 79 characters)
Line 79:80: E501 line too long (90 > 79 characters)
Line 131:80: E501 line too long (85 > 79 characters)
Line 285:80: E501 line too long (80 > 79 characters)
Line 450:80: E501 line too long (85 > 79 characters)
Line 503:80: E501 line too long (81 > 79 characters)


Registration: Add terms of service and privacy policy checkboxes

Add the checkboxes for terms of service and privacy policy to the password page in the registration flow.

Blocked by absence of TOS and Privacy Policy.

https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=1125%3A4220

The User model needs two new columns:

accept_privacy_policy_at (datetime)
accepted_terms_of_service_at (datetime)

They need to be set to now() within App\Actions\Fortify\CreateNewUser::create().


Added manual deletion to temp files

Because windows doesn't allow multiple processes on a file

@llllllllll


Example code hanging

Hi, Thanks for taking this on.  I have a problem with the 'Accessing Igor Pro from Python' example on my Mac using Igor Pro 8.04.  Igor is opened and sine wave created, but the igor("sinwave += 1") command is not executed.  When I restart the code is tells me that the queue is full.  The full error message is:
Traceback (most recent call last):
File "/Users/ll275/opt/anaconda3/lib/python3.9/site-packages/flask/app.py", line 1473, in wsgi_app
response = self.full_dispatch_request()
File "/Users/ll275/opt/anaconda3/lib/python3.9/site-packages/flask/app.py", line 882, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/Users/ll275/opt/anaconda3/lib/python3.9/site-packages/flask/app.py", line 880, in full_dispatch_request
rv = self.dispatch_request()
File "/Users/ll275/opt/anaconda3/lib/python3.9/site-packages/flask/app.py", line 865, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
File "/Users/ll275/opt/anaconda3/lib/python3.9/site-packages/pyigor/pyigor.py", line 136, in got_message
self._queue.put_nowait(("ok", uid, None))
File "/Users/ll275/opt/anaconda3/lib/python3.9/queue.py", line 191, in put_nowait
return self.put(item, block=False)
File "/Users/ll275/opt/anaconda3/lib/python3.9/queue.py", line 137, in put
raise Full
queue.Full
Any help gratefully received!
Leon

Thank you for reporting the issue. It seems the problem arises when Igor Pro is not already running.
This command is meant to execute the specified COMMAND in an already running instance of Igor Pro. In this case, the COMMAND is PyIgorLoadWave().
If Igor Pro is not running, this shell command starts Igor Pro as a subprocess.
The call to subprocess.run([executable_path, "-Q", "-X", command]) in line 35 does not complete while the subprocess is running, which prevents the next command from being executed and causes the issue you reported.
To avoid this problem, make sure Igor Pro is running before executing the Pyigor commands.
Additionally, a similar issue can occur if the Command key is held down while executing commands, as this also causes IgorPro -Q -X COMMAND to start a new process.
Please let me know if the issue continues.

Thanks so much! Works now.  Looking forward to using PyIgor.
All the best,
Leon
From: chocolate-icecream @.>
Date: Thursday, 20 June 2024 at 17:22
To: chocolate-icecream/pyigor @.>
Cc: Leon Lagnado @.>, Author @.>
Subject: Re: [chocolate-icecream/pyigor] Example code hanging (Issue #3)
Thank you for reporting the issue. It seems the problem arises when Igor Pro is not already running.
This command is meant to execute the specified COMMAND in an already running instance of Igor Pro. In this case, the COMMAND is PyIgorLoadWave().
If Igor Pro is not running, this shell command starts Igor Pro as a subprocess.
The call to subprocess.run([executable_path, "-Q", "-X", command]) in line 35 does not complete while the subprocess is running, which prevents the next command from being executed and causes the issue you reported.
To avoid this problem, make sure Igor Pro is running before executing the Pyigor commands.
Additionally, a similar issue can occur if the Command key is held down while executing commands, as this also causes IgorPro -Q -X COMMAND to start a new process.
Please let me know if the issue continues.
—
Reply to this email directly, view it on GitHubhttps://github.com/chocolate-icecream/pyigor/issues/3#issuecomment-2181086434, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGD7H4M7EKM4ZI4UO5VTNCTZIL6UPAVCNFSM6AAAAABJTVB6YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBRGA4DMNBTGQ.
You are receiving this because you authored the thread.Message ID: @.***>


Product layout masthead and content contained within main div

To potentially resolve issue #169
I did not wish to change the div class govuk-main-wrapper as this could be a potential breaking change for others using this layout.

Started having a think about this and ended up with #171.
It’s probably true that  should encapsulate the masthead component; annoying that the base template from govuk-frontend isn’t as flexible as we’d perhaps like to account for this scenario.
I wonder if this is worth raising upstream, changing the template to the following:
    {% block main %}
-

+
        {% block beforeContent %}{% endblock %}
-
+

          {% block content %}{% endblock %}
-
+

-

+
    {% endblock %}

That would bring beforeContent inside the main element, but I suspect the intention is for anything in beforeContent, such as breadcrumbs or back links to remain outside of it.
Will have to noodle on this one; perhaps it is a case of special casing these layouts to move  around a bit.


potential security vulnerability in dependencies

Github says

We found a potential security vulnerability in one of your dependencies.
A dependency defined in package-lock.json has known security vulnerabilities and should be updated.

Acceptance Criteria

[x] We detailed have analysis what's happening here
[ ] replace dependency if possible

Tasks

[x] Do the analysis
[x] re-generate package.json and package-log.json and update the repo

Closing as FIXED. 2 dependencies (indirect) still have potential vulnerability issues but there is no way to fix it as it should be fixed upstream (by maintainers of libraries). We also don't think that the code is actually used in our repo.
Dependencies that have issues:

cryptiles (suggested to upgrade to v4.1.2 but we're not using this lib directly)
string.js (no suggestion for fix)


set package long description

Resolves https://github.com/graphite-project/graphite-web/issues/2404

Codecov Report

Merging #2407 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2407   +/-   ##
=======================================
  Coverage   80.11%   80.11%
=======================================
  Files          85       85
  Lines        8910     8910
  Branches     1906     1906
=======================================
  Hits         7138     7138
  Misses       1504     1504
  Partials      268      268

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c3b06cc...22e8348. Read the comment docs.


⚠ Bofrost.lu has degraded performance

In c88294a, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1511 ms

Resolved: Bofrost.lu performance has improved in ad508fa after 6 minutes.


Ошибка парсера тела при нажатии на панель администратора входа

WrongArgumentError:
You probably used old body-parser middleware, which is not compatible
with @admin-bro/express. In order to make it work you will have to

move body-parser invocation after the admin bro setup like this:

const adminBro = new AdminBro()
const router = new buildRouter(adminBro)
app.use(adminBro.options.rootPath, router)
// body parser goes after the AdminBro router
app.use(bodyParser())

Upgrade body-parser to the latest version and use it like this:
app.use(bodyParser.json())

How to solve this?

Порядок поменяй, дословно же написано =)
Change the order, literally it is written =)


Incomplete address searches produce unreliable results

For example, when a user types in "200 C Street" the site responds with "You live in ANC 6D, single member district SMD 6D02."
However, 200 C Street could refer to "200 C STREET SE" which is in 6B01, or "200 C STREET SW" which is indeed SMD 6D02.
Ideally, the ANCFinder would prompt the user with "Did you mean...? 200 C Street NW or 200 C Street SW". At minimum, it should fail if the address is ambiguous rather than making an assumption.

@lemwerks do you know if there is a mapbox solution to this? @kelshew and I were talking about it today and thought mapbox may already have this functionality.

@rbmy + @ilyagerner YES!
GL Geocoder should work for you.
And I'd set the search to use only a bounding box (BBOX) parameter outlined here.


Feature/develop mvp

Showcase the diversity increase when re-ranking by inverse of cosine similarity.

Add metrics for MSE
Add function for topic clustering
implement driver code for measuring metrics

Re-ranking looks great! You can go ahead and merge with main but please look at my code for the wrapper classes for the RS model and for metrics - the metrics that we want to track need to be built on top of / implemented within the t-recs framework so that we can track them as the simulation runs.


Capistrano Racecar

FYI

Can you open a PR mentioning this in the README?

Thanks for sharing. Please feel free to open a PR to include this in the readme


Uncaught TypeError: Cannot read property 'top' of undefined

[Enter steps to reproduce below:]

...
...

Atom Version: 0.207.0
System: Mac OS X 10.10.3
Thrown From: omnisharp-atom package, v0.12.0
Stack Trace
Uncaught TypeError: Cannot read property 'top' of undefined
At /Users/jason/.atom/packages/omnisharp-atom/lib/omnisharp-atom/views/solution-status-view.js:67

TypeError: Cannot read property 'top' of undefined
  at SolutionStatusCard.verifyPosition (/Users/jason/.atom/packages/omnisharp-atom/lib/omnisharp-atom/views/solution-status-view.js:67:24)
  at /Users/jason/.atom/packages/omnisharp-atom/node_modules/lodash/index.js:1777:43

Commands
     -6:31.6.0 core:confirm (atom-text-editor.editor.mini.is-focused)
 18x -6:30.2.0 vim-mode:move-left (atom-text-editor.editor.vim-mode.command-mode.is-focused)
     -6:29.3.0 omnisharp-atom:get-code-actions (atom-text-editor.editor.vim-mode.command-mode.is-focused)
     -6:28.3.0 core:confirm (atom-text-editor.editor.mini.is-focused)
     -5:53.7.0 application:quit (atom-text-editor.editor.vim-mode.command-mode.is-focused)
 54x -5:06.2.0 vim-mode:move-down (atom-text-editor.editor.vim-mode.command-mode.is-focused)
 76x -4:59.5.0 vim-mode:move-up (atom-text-editor.editor.vim-mode.command-mode.is-focused)
     -4:45.4.0 omnisharp-atom:solution-status (atom-workspace.workspace.scrollbars-visible-when-scrolling.theme-gruvbox.theme-atom-dark-ui.editor-background.find-visible)
     -4:43.1.0 omnisharp-atom:toggle-dock (atom-workspace.workspace.scrollbars-visible-when-scrolling.theme-gruvbox.theme-atom-dark-ui.editor-background.find-visible)
     -4:37.1.0 editor:consolidate-selections (atom-text-editor.editor.mini.is-focused)
     -4:37.1.0 core:cancel (atom-text-editor.editor.mini.is-focused)
     -4:24.9.0 omnisharp-atom:code-format (atom-text-editor.editor.vim-mode.command-mode.is-focused)
  2x -4:20.2.0 vim-mode:scroll-half-screen-down (atom-text-editor.editor.vim-mode.command-mode.is-focused)
  2x -4:12.8.0 omnisharp-atom:code-format (atom-text-editor.editor.vim-mode.command-mode.is-focused)
     -0:53.6.0 omnisharp-atom:solution-status (atom-workspace.workspace.scrollbars-visible-when-scrolling.theme-gruvbox.theme-atom-dark-ui.editor-background)
     -0:02.7.0 omnisharp-atom:restart-server (atom-workspace.workspace.scrollbars-visible-when-scrolling.theme-gruvbox.theme-atom-dark-ui.editor-background)

Config
{
  "core": {
    "disabledPackages": [
      "metrics",
      "autocomplete",
      "web-browser",
      "atom-browser-webview"
    ],
    "ignoredNames": [
      ".git",
      ".svn",
      ".DS_Store"
    ],
    "themes": [
      "atom-dark-ui",
      "gruvbox"
    ]
  },
  "omnisharp-atom": {
    "developerMode": true
  }
}

Installed Packages
# User
.bin, vundefined
atom-fuzzy-grep, v0.2.0
atom-typescript, v4.5.7
atom-yeoman, v0.3.2
editor-background, v0.15.6
editorconfig, v1.0.0
gruvbox, v0.3.2
language-csharp, v0.5.0
language-cshtml, v0.1.1
linter, v0.12.6
omnisharp-atom, v0.12.0
sync-settings, v0.2.2
vim-mode, v0.51.0

# Dev
No dev packages

doing anything special at the time this happened?

Opened NRefactory.sln. Had to remove one of the slns to make it load.

There was another error too... but the stack trace was too big to post to github.

I was getting the same error on both Windows and OS X. It happened when you stop/restart the server from the solution info card.
However, after updating to 0.12.4, it only seems to happen on Windows.

I haven't seen this recently and looking at the code there is a null check in place now.


Increase communication speed

Flash writer supports sup command that can be used to increase serial port baud rate. This will increase flash upload speed.

As agreed, we need to implement the field sup_baud in yaml for boards that support SUP command.
This field will specify the baud rate after SUP, and will be used as a flag that such a command is supported.

Merged.


dash fails to compile on gcc 12.

dash fails to compile on gcc 12.  System was Fedora 36.
Error in code is on like 139 in block.h
https://github.com/dashpay/dash/blob/master/src/primitives/block.h#L139
gcc error is
 error: cannot convert 'CompressedHeaderBitField::Flag' to 'std::byte' in initialization
      |   static constexpr std::byte VERSION_BIT_MASK = std::byte{Flag::VERSION_BIT_0} | std::byte{Flag::VERSION_BIT_1} | std::byte{Flag::VERSION_BIT_2};
      |                                                           ~~~~~~^~~~~~~~~~~~~
      |                                                                 |
      |                                                                 CompressedHeaderBitField::Flag

You can reproduce the error with the code snippet in https://privatebin.at/?84cd632fa5f958dd#8i7yrKwctM75DkinypkBAgyGmZCSESWvq2YykjFVqb2h
#include <iostream>
#include <cstddef>
#include <cstdint>
#include <type_traits>

class CompressedHeaderBitField
{
    std::byte bit_field{0};

public:
    enum class Flag : std::underlying_type_t<std::byte> {
        VERSION_BIT_0 = (1 << 0),
        VERSION_BIT_1 = (1 << 1),
        VERSION_BIT_2 = (1 << 2),
        PREV_BLOCK_HASH = (1 << 3),
        TIMESTAMP = (1 << 4),
        NBITS = (1 << 5),
    };

private:
    static constexpr std::byte VERSION_BIT_MASK = std::byte{Flag::VERSION_BIT_0} | std::byte{Flag::VERSION_BIT_1} | std::byte{Flag::VERSION_BIT_2};
};

int main(){
        CompressedHeaderBitField chbf = CompressedHeaderBitField();
                std::cout<<&chbf<<std::endl;
        return 0;
}

compile with g++ -Wall -std=c++17  try.cpp && ./a.out assuming you called it try.cpp.  gcc 12 will fail, all previous versions will compile and run.
Fix suggested, is.
static constexpr std::byte VERSION_BIT_MASK = std::byte{static_cast<std::byte>(Flag::VERSION_BIT_0)} | std::byte{static_cast<std::byte>(Flag::VERSION_BIT_1)} | std::byte{static_cast<std::byte>(Flag::VERSION_BIT_2)};

which compiles and runs on gcc12.

should be fixed


Testnet was down???

Testnet was down? no more block

Denali: https://explorer.avax.network/

Hi @pefish , please ask questions like this in our Discord server: https://chat.avalabs.org/. Yes, the testnet was down for a little bit a few days ago but is back up now. Thanks for your patience and if you have any more questions general questions like this feel free to reach out on discord

@aaronbuchwald Testnet is not back up now!!!

@pefish The test network is up right now. What issue are you facing that makes you think otherwise?

Looks like there is an ingestion problem with the explorer. The explorer
makes it look like there has been no activity on the testnet for the last 3
days. In reality, testnet is up, but the explorer is having issues.
On Fri, Jul 10, 2020 at 8:47 AM danlaine<EMAIL_ADDRESS>wrote:

@pefish https://github.com/pefish The test network is up right now.
What issue are you facing that makes you think otherwise?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ava-labs/gecko/issues/277#issuecomment-656658344, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AALEYX3MPPEOQWB5QTG27N3R24EX3ANCNFSM4OVFTIXA
.

I run a node with latest version 0.5.7. Call "timestamp.getBlock" method, got latest block with timestamp<PHONE_NUMBER>, it is 2020-07-03
params:
{
     "jsonrpc": "2.0",
     "id": 1,
     "method": "timestamp.getBlock",
     "params":{

     }
}

result:
{
    "jsonrpc": "2.0",
    "result": {
        "timestamp": "1593778925",
        "data": "SkB92YpWm4Q2iPnLGCuDPZPgUQMxajqQQuz91oi3xD984f8r",
        "id": "8SJeZracg9vfRD3EBRRBoZgRuahxeMwFTEPwQDZ2aahM8ZVnf",
        "parentID": "PcaMPRtpfcD3RYHV6pciqerMwkM46vM1vAQa1EWgh6QCzZPj3"
    },
    "id": 1
}

The problem still exists.

@pefish
Ah, I see. You're misunderstanding what the return value from this API call means.
The API you're hitting is that of a blockchain that acts as a timestamp server.
You can upload a 32 byte hash to this blockchain and it will be timestamped.
Avalanche is a collection of blockchains, not one blockchain, and this this API is returning the time at which the most recent block was accepted on this chain, not on any chain.
You can read more here or on our Discord server.


question about adding special permission for single user/group

Hi, I commented last month about the anonymous user behavior - thanks for the quick response on that.
I am now trying to implement more features in my app, and I'm having some trouble. For example, let's say I have a resource which has permissions
__permissions__ = dict(
        owner=['read', 'update', 'delete', 'revoke'],
        group=['read', 'update'],
        other=[]
    )

In other words, this resource is not public. The owner has all permissions, while the group can read or update. I would like to give a specific user (or other group) read permission as well. Is there a built in way to do this using this package?

If you know the name of the extra user/group beforehand, you could update your request handler to use something like:
@app.route('/articles/<uuid>', methods=['GET'])
def get_article(uuid):
    article = db.session.query(Article).filter_by(id=ident).first()
    if not article:
        raise NotFound

    # check read permissions or that the user is in a specific group
    if not authorize.read(article) and not authorize.in_group('my-extra-group'):
        raise Unauthorized

    return jsonify(id=article.id, name=article.name), 200

Another option would be to use role functionality for that type of access. Using an admin check in your app might look something like:
@app.route('/articles/<uuid>', methods=['GET'])
def get_article(uuid):
    article = db.session.query(Article).filter_by(id=ident).first()
    if not article:
        raise NotFound

    # check read permissions or that the user is an admin
    if not authorize.read(article) and not authorize.has_role('admin'):
        raise Unauthorized

    return jsonify(id=article.id, name=article.name), 200

Note that you'd need to configure your models to reflect role functionality (if you haven't already done so). The documentation has examples of configuring an app with roles.

If you know the name of the extra user/group beforehand, you could update your request handler to use something like:
@app.route('/articles/<uuid>', methods=['GET'])
def get_article(uuid):
    article = db.session.query(Article).filter_by(id=ident).first()
    if not article:
        raise NotFound

    # check read permissions or that the user is in a specific group
    if not authorize.read(article) and not authorize.in_group('my-extra-group'):
        raise Unauthorized

    return jsonify(id=article.id, name=article.name), 200

Another option would be to use role functionality for that type of access. Using an admin check in your app might look something like:
@app.route('/articles/<uuid>', methods=['GET'])
def get_article(uuid):
    article = db.session.query(Article).filter_by(id=ident).first()
    if not article:
        raise NotFound

    # check read permissions or that the user is an admin
    if not authorize.read(article) and not authorize.has_role('admin'):
        raise Unauthorized

    return jsonify(id=article.id, name=article.name), 200

Note that you'd need to configure your models to reflect role functionality (if you haven't already done so). The documentation has examples of configuring an app with roles.

I've also previously considered extending PermissionsMixin with the ability to handle permissions checks for multiple group associations to a piece of content. Currently, that mixin only supports a single group association, but I'm sure some developers would find multiple group associations useful in certain contexts.
If the suggestions above don't solve your problem, I can try to include that feature to the next release.

I've also previously considered extending PermissionsMixin with the ability to handle permissions checks for multiple group associations to a piece of content. Currently, that mixin only supports a single group association, but I'm sure some developers would find multiple group associations useful in certain contexts.
If the suggestions above don't solve your problem, I can try to include that feature to the next release.

Thanks! I don't know beforehand, so I need something to handle that. What I'm attempting now is to have an association object (table) between an entity (user or group) and a resource (for example a file). This would have permissions like "read", "write" etc, so that they could be updated as the app is run.
I've been working this week on trying to make a mixin (or rather a factory for mixins) which creates associations/allows specification of permissions for individual resources. I'll let you know if/when I get a working example for that. Assuming that does work, it would be an additional check on permissions for a resource (after checking other, owner, group, you would look to see if the object is in/has permissions on the association table)

Thanks! I don't know beforehand, so I need something to handle that. What I'm attempting now is to have an association object (table) between an entity (user or group) and a resource (for example a file). This would have permissions like "read", "write" etc, so that they could be updated as the app is run.
I've been working this week on trying to make a mixin (or rather a factory for mixins) which creates associations/allows specification of permissions for individual resources. I'll let you know if/when I get a working example for that. Assuming that does work, it would be an additional check on permissions for a resource (after checking other, owner, group, you would look to see if the object is in/has permissions on the association table)

Hi @bprinty - i was wondering if any of the recent changes address this?

Hey @janash! They do not. The recent changes enable developers to change the names of User/Group models and table names when using the PermissionsMixin.

I've also previously considered extending PermissionsMixin with the ability to handle permissions checks for multiple group associations to a piece of content. Currently, that mixin only supports a single group association, but I'm sure some developers would find multiple group associations useful in certain contexts.

This is what I sort of had a hard time wrapping my head around where only a single entry is given to a group only. With this limitation you have to know groups before hand if you want to allow other groups to do something. An example would be "editors" group whom can make changes to something, but an "admin" group wouldn't have any permissions to that object.
There's also the owner flag which is something my app doesn't need. I can understand where it would make sense like in a blog with all the examples provided, but in my case its KPI collection engine and there is no single owner of a metric, but rather a group(s) of people who manage or view the data.


[PORT] Fix issues with TestBot.

Port this change from botbuilder-dotnet/master branch:
https://github.com/microsoft/botbuilder-dotnet/pull/3485

TestBot was no longer working because Tom remove the connection to user-secrets.  Added that back in and fixed some other minor issues.
Changed projects

Microsoft.Bot.Builder.AI.LUIS
Microsoft.Bot.Builder.TestBot.Json

dotnet specific.


Flat Array Transformer

Present an object as a flat array.

https://github.com/nilportugues/serializer/commit/b6a3ccbe05df83779e4dcba944379358a45610a4


⚠ ClamAV has degraded performance

In 6ab1e84, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 50 ms

Resolved: ClamAV performance has improved in 6d720b3.


Always allow editing excluded list, not just when idle

Is your feature request related to a problem? Please describe.
I wanted to install Maestral with selective sync, since i only wanted 2-3 folders out of my 30+.
However, during the initial setup, when selecting which folders to sync, I accidentally pressed "Enter" when I tried to check my folders, which proceeded with 0 folders selected.
Maestral now went into "Indexing..." status, during which I wasn't allowed to edit the excluded folders list.
$ maestral excluded remove /personal
! Cannot include item. Please try again when idle.

This is extremely frustrating, because I know indexing may take a long time, maybe hours?
I come back the next day, indexing is done. Ideally I would have all my folders synced by now, but I wasn't allowed to edit the excluded list.
I try to remove the folders I want from the excluded list:
$ maestral excluded remove /personal /images /dotfiles
Error: Got unexpected extra arguments (/images /dotfiles)

No way... Please don't tell me...
$ maestral excluded remove /personal
✓ Included '/personal'. Now downloading...
$ maestral excluded remove /images
! Cannot include item. Please try again when idle.

No... NOOO! I actually have to finish syncing 1 directory at a time, then come back and remove another one from the excluded list? This is going to take ages.
Describe the solution you'd like
The excluded list should always be editable, or at the very least multiple edits should be possible at the same time, so I don't have to spend hours or days slowly editing my config.
 Hopefully I won't next time.
Additional context

Passing multiple items to maestral excluded add | remove is now supported. Regarding modifying this list while indexing and syncing, this is a duplicate of #958.

https://github.com/samschott/maestral/issues/958#issuecomment-2016792961

@samschott, you've linked https://github.com/samschott/maestral/issues/958#issue-1840988001, this issue, as a duplicate of itself. XD

Argg, I meant to link #303.


Updates to OpenSource Intro page

Spelling error: sourc -> source

@hyperdriveguy Could you make a pull request to fix it :)  Thanks


TensorFlow installation for Python 3.7

I have Python 3.7 running on Anaconda on my new Windows PC. MSVCP140.dll is present
I still have no clue why is it not working. I tried creating a virtual environment for Python 3.6 which is the only fix.
If Python 3.7 is official, can you please fix Tensorflow module to support the same?
Screenshots :

I tried creating a virtual environment for Python 3.6 which is the only fix.


adding migration doc

Mike is this a new topic that has to be added to the TOC?
From: Mike Jones<EMAIL_ADDRESS>Sent: Tuesday, September 15, 2015 3:09 PM
To: Microsoft/cordova-docs<EMAIL_ADDRESS>Subject: Re: [cordova-docs] adding migration doc (#73)
Merged #73https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73&data=01|01|normesta%40exchange.microsoft.com|0413dbdc758e4259f2a908d2be1a54c6|72f988bf86f141af91ab2d7cd011db47|1&sdata=0igJQeHEDL5fyxqZQ6G7UCLoQhWzSPAzOHl0n6kA04E%3D.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73%23event-410346981&data=01|01|normesta%40exchange.microsoft.com|0413dbdc758e4259f2a908d2be1a54c6|72f988bf86f141af91ab2d7cd011db47|1&sdata=ubNThXAw9BugMascUSkCH2iVmwptckbq5hL6Gws%2Bawk%3D.

Yes, it does. I was going to check whether you’re still working on the TOC. If you are, maybe you can add it?
Ryan wants people to find this info more easily, so I think it should go at the end of Getting Started section for a period of time.
Mike
From: Norm Estabrook<EMAIL_ADDRESS>Sent: Tuesday, September 15, 2015 3:17 PM
To: Microsoft/cordova-docs<EMAIL_ADDRESS>Cc: Mike Jones (DEVUE<EMAIL_ADDRESS>Subject: Re: [cordova-docs] adding migration doc (#73)
Mike is this a new topic that has to be added to the TOC?
From: Mike Jones<EMAIL_ADDRESS>Sent: Tuesday, September 15, 2015 3:09 PM
To: Microsoft/cordova-docs <cordova-docs<EMAIL_ADDRESS>Subject: Re: [cordova-docs] adding migration doc (#73)
Merged #73https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73&data=01|01|normesta%40exchange.microsoft.com|0413dbdc758e4259f2a908d2be1a54c6|72f988bf86f141af91ab2d7cd011db47|1&sdata=0igJQeHEDL5fyxqZQ6G7UCLoQhWzSPAzOHl0n6kA04E%3D.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73%23event-410346981&data=01|01|normesta%40exchange.microsoft.com|0413dbdc758e4259f2a908d2be1a54c6|72f988bf86f141af91ab2d7cd011db47|1&sdata=ubNThXAw9BugMascUSkCH2iVmwptckbq5hL6Gws%2Bawk%3D.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73%23issuecomment-140561867&data=01|01|mikejo%40microsoft.com|cd9b7c00ec8545924d5408d2be1b552a|72f988bf86f141af91ab2d7cd011db47|1&sdata=ZPYdezIafn0K41Eic5EbmMYDYNltSdvdXSQYSmRcYoQ%3D.

No problem.  Where’s the path on github? I don’t see it in the “getting-started section.
From: Mike Jones<EMAIL_ADDRESS>Sent: Tuesday, September 15, 2015 3:20 PM
To: Microsoft/cordova-docs<EMAIL_ADDRESS>Cc: Norm Estabrook<EMAIL_ADDRESS>Subject: Re: [cordova-docs] adding migration doc (#73)
Yes, it does. I was going to check whether you’re still working on the TOC. If you are, maybe you can add it?
Ryan wants people to find this info more easily, so I think it should go at the end of Getting Started section for a period of time.
Mike
From: Norm Estabrook<EMAIL_ADDRESS>Sent: Tuesday, September 15, 2015 3:17 PM
To: Microsoft/cordova-docs <cordova-docs<EMAIL_ADDRESS>Cc: Mike Jones (DEVUE) <mikejo<EMAIL_ADDRESS>Subject: Re: [cordova-docs] adding migration doc (#73)
Mike is this a new topic that has to be added to the TOC?
From: Mike Jones<EMAIL_ADDRESS>Sent: Tuesday, September 15, 2015 3:09 PM
To: Microsoft/cordova-docs <cordova-docs@noreply.github.com<mailto:cordova-docs@noreply.github.commailto:cordova-docs<EMAIL_ADDRESS>Subject: Re: [cordova-docs] adding migration doc (#73)
Merged #73https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73&data=01|01|normesta%40exchange.microsoft.com|0413dbdc758e4259f2a908d2be1a54c6|72f988bf86f141af91ab2d7cd011db47|1&sdata=0igJQeHEDL5fyxqZQ6G7UCLoQhWzSPAzOHl0n6kA04E%3D.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73%23event-410346981&data=01|01|normesta%40exchange.microsoft.com|0413dbdc758e4259f2a908d2be1a54c6|72f988bf86f141af91ab2d7cd011db47|1&sdata=ubNThXAw9BugMascUSkCH2iVmwptckbq5hL6Gws%2Bawk%3D.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73%23issuecomment-140561867&data=01|01|mikejo%40microsoft.com|cd9b7c00ec8545924d5408d2be1b552a|72f988bf86f141af91ab2d7cd011db47|1&sdata=ZPYdezIafn0K41Eic5EbmMYDYNltSdvdXSQYSmRcYoQ%3D.
—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fcordova-docs%2Fpull%2F73%23issuecomment-140562346&data=01|01|normesta%40exchange.microsoft.com|d3c4980bd9a44ebfd68908d2be1bc78e|72f988bf86f141af91ab2d7cd011db47|1&sdata=C%2FYlWkx2bjZeJZi%2BUEfjcDW39TzMH1OpigI8hbJr24k%3D.


bugfix(expand): Fix expand to stay open until the source Observable completes.

Can you rename the Commit to start with fix() rather than bugfix? That way it falls into one category.

@blesh done

LGTM

merged with 20ef785
Thanks!


[Figma] Tabs extended media

Add the Tabs extended media component to Figma kit. Remember we are only building variants for xlg, md, and sm.
Design spec
Website
Must haves:

[ ] Content should be flexible - the designer should be able to condense or stretch the component and the content should respond. Removing text for example should maintain the right padding automatically through auto layout.
[ ] Should live in the same page as Tabs extended
[ ] Use existing components in Figma: Tabs extended and Content item horizontal

Resources

C4IBM.com Component checklist is available in the Read Me 👀 page of the Figma library
Bases demo from the Figma Fridays (Episode 23)
Reference the best practices from Figma guild
Info on auto layout

Assigned to Julia L


[BUG] - datepicker calendarProps classnames don't apply

NextUI Version
2.4.8
Describe the bug
When I want to apply a className to the calendar within the datePicker, the original design is damaged, and the classNames that are added do not work.

import { Card, CardBody, DatePicker } from "@nextui-org/react";

export default function Home() {
  return (
    <Card className="mx-auto mt-4 max-w-md">
      <CardBody className="text-center">

Date picker test

          <DatePicker
            hideTimeZone
            showMonthAndYearPickers
            calendarProps={{
              content: "bg-primary",
              tw: "bg-primary text-white",
              navButtonProps: {
                //className: "text-red-500", // <- if uncommment this, all styles fails
              },
              color: "secondary",
              classNames: {
                headerWrapper: ["bg-transparent"],
                gridWrapper: ["bg-primary"],
                pickerWrapper: ["bg-primary"],
                nextButton: "text-red-500", // <- This do not work
              },
              buttonPickerProps: {
                color: "secondary",
                style: {},
                variant: "solid",
                //className: "text-white", // <- if uncommment this, all styles fails
              },
            }}
          />

      </CardBody>
    </Card>
  );
}

Your Example Website or App
https://codesandbox.io/p/devbox/elated-khayyam-9nkpz3?workspaceId=809e93b8-69d3-49b4-b28e-5ff7a616bda9
Steps to Reproduce the Bug or Issue

add classNames on calendarProps of DatePicker

Expected behavior
Apply the classNames
Screenshots or Videos
No response
Operating System Version
macOs
Browser
Chrome

calendarProps is not propagated correctly to the calendar and has been resolved in this PR. You may use canary version or wait for the next release.


RHashMap::raw_entry[_mut] support

This PR adds support for the upcoming raw_entry API. This is possible by switching to hashbrown instead of std. Furthermore, this PR enables support for halfbrown, an empirically more performant implementation of hashbrown, with support for raw_entry, too:

Hashmap implementation that dynamically switches from a vector based backend to a hashbrown based backend as the number of keys grows

The halfbrown part works by switching the underlying struct for RHashMap to a halfmap::HashMap when activated. Its interface is meant to be the same as hashbrown's.
The only error I haven't been able to fix is the following, any help?
error[E0271]: type mismatch resolving `<iterator_stuff::RefIterInterface<K, V> as erased_types::traits::InterfaceType>::Clone == impl_enum::Unimplemented<type_leve
l::trait_marker::Clone>`
   --> abi_stable/src/std_types/map/extern_fns.rs:123:13
    |
123 |             DynTrait::from_borrowing_value(iter, RefIterInterface::NEW)
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `impl_enum::Unimplemented`, found struct `impl_enum::Implemented`
    |
    = note: expected struct `impl_enum::Unimplemented<type_level::trait_marker::Clone>`
               found struct `impl_enum::Implemented<type_level::trait_marker::Clone>`
note: required because of the requirements on the impl of `erased_types::vtable::GetVtable<'_, std::iter::Map<halfbrown::Iter<'_, map_key::MapKey<K>, V>, fn((&map_
key::MapKey<K>, &V)) -> tuple::Tuple2<&K, &V> {map_iter_ref::<'_, K, &V>}>, std_types::boxed::private::RBox<()>, std_types::boxed::private::RBox<std::iter::Map<hal
fbrown::Iter<'_, map_key::MapKey<K>, V>, fn((&map_key::MapKey<K>, &V)) -> tuple::Tuple2<&K, &V> {map_iter_ref::<'_, K, &V>}>>, iterator_stuff::RefIterInterface<K,
V>>` for `interface_for::InterfaceFor<std::iter::Map<halfbrown::Iter<'_, map_key::MapKey<K>, V>, fn((&map_key::MapKey<K>, &V)) -> tuple::Tuple2<&K, &V> {map_iter_r
ef::<'_, K, &V>}>, iterator_stuff::RefIterInterface<K, V>, downcasting::TD_Opaque>`
   --> abi_stable/src/erased_types/vtable.rs:333:13
    |
333 |               GetVtable<'borr,$value,$erased_ptr,$orig_ptr,$interf>
    |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
334 |           for This
    |               ^^^^
...
495 |   declare_meta_vtable! {
    |  _-
    | |_|
    | |
496 | |     interface=I;
497 | |     value  =T;
498 | |     erased_pointer=ErasedPtr;
...   |
757 | |     ]
758 | | }
    | | -
    | |_|
    | |_in this macro invocation
    |   in this macro invocation
note: required by a bound in `priv_::DynTrait::<'static, rref::RRef<'static, ()>, ()>::from_borrowing_value`
   --> abi_stable/src/erased_types/dyn_trait.rs:877:44
    |
870 |         pub fn from_borrowing_value<'borr, T, I>(
    |                -------------------- required by a bound in this
...
877 |             InterfaceFor<T, I, TD_Opaque>: GetVtable<'borr, T, RBox<()>, RBox<T>, I>,
    |                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `priv_::DynTrait::<'static, rref::RRef<'static
, ()>, ()>::from_borrowing_value`
    = note: this error originates in the macro `declare_meta_vtable` (in Nightly builds, run with -Z macro-backtrace for more info)

I understand that the way to fix it would be to remove Clone from here:
declare_iter_interface! {
    K => V;
    /// The `InterfaceType` of the `Iter` iterator for `RHashMap`.
    #[sabi(impl_InterfaceType(Iterator, Clone))]
    interface = RefIterInterface;
    type Item = Tuple2<&'a K, &'a V>;
}

But then I get errors, because .clone() is actually used a few times.
TODO:

[ ] Fix error above
[ ] Disable hashbrown when halfbrown is being used? That would mean hashbrown would also be a (default) feature. But if someone uses --no-default-features it would fail without also adding hashbrown back.
[ ] Update the tests and the docs
Implement "nightly" features for halfbrown/hashbrown:

[ ] insert_nocheck
[ ] raw_entry

[ ] Wait for https://github.com/rodrimati1992/abi_stable_crates/pull/85 and rebase (this branch points to it right now, so the diff is a bit messed up)

Ok, I'm gonna look at this today.

Having tried this locally, the error is caused by halfbrown::Iter deriving Clone, the solution is for it to manually implement Clone with no bounds on type parameters.
halfbrown::Iter requires Clone for all type parameters because #[derive(Clone)] implicitly adds a Clone bound to all type parameters.

Here's an update about the status of this PR.
I have concluded my work with Tremor, so I won't be able to continue working on it. For now, the PR is just part of research in trying to optimize Tremor's plugin system. It analyzes halfbrown vs hashbrown, and memoizing JSON hashes (see https://nullderef.com/blog/plugin-end/#_hash_table_optimization). If the rest of the Tremor team end up considering this worth implementing, then some more polishing is still required. The wrapped API is incomplete, and doesn't include the builder pattern for simplicity.
Even if the change ends up being worth it, I'm not fully sold on merging it into the main branch. raw_entry isn’t going to make it to a stable release, and the Rust team is working on a different interface. It will probably be similar enough that updating our raw_entry usage won’t be too much work, but we should make sure first to minimize the breaking changes.
Any more doubts please let me know!