Azure cfcr support

What this PR does / why we need it:
This PR added the support for the cfcr running in azure.
How can this PR be verified?
follow the docs/terraform/azure/README.md to do the test.
and here's comformance test result file https://opensourcerelease.blob.core.windows.net/alphareleases/sonobuoy.tgz
Is there any change in kubo-deployment?
yes
Is there any change in kubo-ci?
no.
Does this affect upgrade, or is there any migration required?
no.
Which issue(s) this PR fixes:
Release note:

this pr depends on this pr: https://github.com/cloudfoundry/bosh-agent/pull/174

Thanks for the PR. Currently Azure is not a priority in our backlog and we would also have to wait on the bosh-agent PR for this to be merged. We'll keep you updated if and when we have news.

@mordebites the bosh-agent pr is merged which this pr depends on. please help review : )

Maintaining a fork here https://github.com/svrc-pivotal/azure-kubo-release

@alex-slynko FYI the azure cloud provider supports the equivalent of IAM roles but the Azure CPI doesn’t yet from what I can tell
Also I added a fix to this PR in my fork:
https://github.com/svrc-pivotal/azure-kubo-release/commit/078910c96523b136e9295b810e1228962ea9d697
There needs to be a broader conversation about DNS handling for Bring Your Own DNS server for this PR.  I’m not sure if it’s realistic to expect enterprises to turn on DDNS hostname registration.  This might require a BOSH dns feature.


Portable Dungeon's Hub GUI

u/romin0
Dungeons hub GUI: So i think it'd be dope to enter Dungeon while in the hub/Island. Basically, you create a gui, accessible via a command. In the gui, you can access any Floor using /joindungeon catacombs 7 (example) And before starting, it would Tell you the average cata level of your party, average secrets and amount of Members on your party. Pretty easy to make in a developper perspective. (Add a Burton for each Floor)

Added in 0.0.2 update with Party Manager
#41


Updated gradle, regions and a queue

Builds all fail

replaced by https://github.com/tools4j/mmap/pull/11


Database refactoring for Training Module

AS AN Architect
I WANT Training Module Postgres databases and their tables to be refactored
SO THAT they would be compliant with best practices
Acceptance Criteria

[ ] All AC from https://github.com/buerokratt/Buerokratt-Architectural-Decision-Records/issues/46 apply

Currently, it seems that the database in the Training Module does not need any refactoring.
The training module database (postgres) only has one table and it is for intents. As it stands today, only a single operation fetches data from the intents table - getting the 'last modified' date information on opening any specific intent in the Training Module. The columns seem to be compliant with best practices: ID (bigint), intent (varchar), created (timestamp with time zone) and status (varchar(10)).
On any sort of CRUD operation with intents, the only statement that is used is INSERT.

On adding a new intent, it inserts a new line with the intent's name and an ACTIVE status.
On deleting an intent, it inserts a new line with the intent's name and a DELETED status.
On updating an intent, it inserts a new line with the intent's updated name and an ACTIVE status, and changes the old to DELETED.

This is useful for tracking all changes made for intents.
On fetching the 'last changed' data, it just fetches the timestamp of the recently created line with the input intent name and the front-end converts it into a readable format.

Currently, it seems that the database in the Training Module does not need any refactoring.
As it stands today, the training module database (postgres) only has one table and it is for intents. Only a single operation fetches data from the intents table - getting the 'last modified' date information on opening any specific intent in the Training Module. The columns seem to be compliant with best practices: ID (bigint), intent (varchar), created (timestamp with time zone) and status (varchar(10)).
On any sort of CRUD operation with intents, the only statement that is used is INSERT.

On adding a new intent, it inserts a new line with the intent's name and an ACTIVE status.
On deleting an intent, it inserts a new line with the intent's name and a DELETED status.
On updating an intent, it inserts a new line with the intent's updated name and an ACTIVE status, and changes the old one to DELETED.

This is useful for tracking all changes made for intents.
On fetching the 'last changed' data, it just selects the timestamp of the recently created line with the input intent name and the front-end converts it into a readable format.

@turnerrainer Most of training module operations are done via Open Search and it does not use the chatbot db and it has only 1 table intents with the correct data types, so no liquibase queries are required here

Close due to @KasparMinn and @1AhmedYasser valid comments.


ng build with --baseHref is not working in Angular 9

🐞 Bug report
Command (mark with an x)

[ ] new
[x ] build
[ ] serve
[ ] test
[ ] e2e
[ ] generate
[ ] add
[ ] update
[ ] lint
[ ] xi18n
[ ] run
[ ] config
[ ] help
[ ] version
[ ] doc

Is this a regression?

yes
Description
 A clear and concise description of the problem...
When you ng build --prod --baseHref 'any_other_path' >>> it only goes to dist/[output_folder]
there is no regard to an output path other than the output folder path
🔬 Minimal Reproduction

Angular 9.1.2

Hi @xtianus79,
I am not totally sure what is the regression/expected behaviour here, but the baseHref option doesn't effect the output path.
If the problem persists, please open a new issue, provide a simple repository reproducing the problem, and describe the difference between the expected and current behavior. You can use ng new repro-app to create a new project where you reproduce the problem.
Thanks.


[TRO-3588] Rebuilt buffer code extensively, now passing tests after manual checks of values.

Reworked buffers to correct behaviour and simplify. Now provides square metres of each of several buffered classes (independently and all unioned together), as well as square metres of the buffer zone.
Buffer zones are growing areas, designed for subtracting from each other where ring "defensible space" style buffers are desired.
Buffer zones that intersect the AOI boundary that may not be valid are left as nan values.

@hirokob  and @mlopeman - I'm now happy that this PR is behaving as expected, with correct buffers, clipping of multiparcel buildings and child objects, and passing all tests.
Noting that the "not working" case is if a truncated multiparcel building buffer is desired, that is not possible at the moment with nmaipy (as pulling an area around a building means it is no longer treated as a multiparcel building, and therefore the full building's buffers are returned).
Please hit approve if ready, and we can merge!


Design decision query: recommended pattern for auxiliary loss terms that should be ignored during evaluation?

Hello!
I came across texar-pytorch while in the process of writing my own version of the Executor, and am really happy that someone's already done the work for it, so firstly, thanks for the excellent repository.
Broad Query
One of the main questions I have pertains to the design requirement of including the loss as an item in the dictionary returned by the forward method of the model. Essentially, I'm wondering what's the recommended pattern for including terms in the loss (for eg. regularization terms) that ought to not be a part of the validation loss? Conceptually, I think of the forward pass as being completed with the model making its predictions, which is what I believe the predict() method is for. However, having the computation of the loss as a responsibility of the forward pass could lead to certain problems.
Context
Ideally, the training loss ought to be computed in a separate forward pass after the training epoch is completed. I'm aware that most people use an average over the training batches as an approximation of the training loss. However, this becomes an issue when comparing against a validation loss curve, where the difference between the training and validation curve indicates generalization error. This is for two reasons in the typical case:

The model changes at the end of each batch when the optimizer takes a step, so it's an unfair comparison against the evaluation setting. The model might also overfit on a single batch.
The model might have dropout and batch norm turned on during training which behave differently during evaluation.

As far as I can tell, the training loss is computed within the training loop in the executor, as opposed to an additional forward pass over the training set with model.eval(). Is my understanding correct?
On regularization
Typically, any regularization terms over the model parameters is added to the loss before the call to backward. With the given interface, it seems like the right place to do this would be in the forward pass. However, I find it a little weird to make the model responsible for regularizing itself. I usually have a separate nn.Module subclass responsible for regularizing a model and dependency-inject the model into this class. That way I can swap out different regularizers without changing the model, in compliance with the Open-Close SOLID principle.
Could you please explain how to achieve these two things (loss computation over the training set after the train loop, and computing auxiliary loss terms outside the model) with the current setup of the executor? It seems like this is a direct consequence of requiring the model to compute the loss, which seems to be a little problematic. This is currently the main two problems precluding my use of this otherwise awesome repo, so I'd appreciate any insight.
Thanks!

Hi Chirag, thank you for your interest in Texar-PyTorch! I'm the main developer behind the Executor module, and I can address your questions.

For your first question, I'm not sure I completely understood, but I guess that your intention was to perform evaluation (under model.eval() mode) on the training set after each epoch. While the Executor doesn't do this by default, you can add a custom action using Executor.on like this:
executor = Executor(train_data=datasets["train"], ...)

@executor.on(cond.epoch(1))
def eval_on_train(executor):
	executor.test(datasets["train"])
    # obtain results from the status dictionary
    metrics = executor.status["eval_metric"]
    # compare it with your stored validation results ...

However, please pay attention to your validation/testing settings as test() uses testing metrics while status["eval_metric"] refers to the validation metrics. This is not a problem if your validation and testing metrics are the same (the default if you leave test_metric as None), but it could be a source of hard-to-find bugs.

For your second question, the design principle of the Executor is to leave all model-related computations to the model, so that the Executor itself can be as general as possible. Our recommended approach is to create a "wrapper" model class that takes care of everything, including re-structuring of inputs/outputs, and the regularization as you mentioned. This is also what we did in the examples (e.g., XLNet).
This might seem like a bit of boilerplate, which I agree, but I currently don't see any way of avoiding this. Most built-in (PyTorch or Texar-PyTorch) or third-party modules does not take a batch as input, nor do they return a dictionary, so it's probably necessary to have this wrapper to at least re-structure inputs and outputs.

I would say that Executor is still in its early stages of development, and is far from complete. I encounter many tough spots while using the module myself, and I think it can be further improved. If you have any suggestions or are willing to contribute, please feel free to ask any questions and create pull requests!

Zecong! Small world! I think I ran into you at the LTI just before I left haha, wonderful to know you are developing the Executor :) Thanks for getting back to me so quickly!

I think the two problems are related; even if I wrap the model, the loss would still need to be computed by the model, which is the larger issue. I'd argue that this is just an incorrect class design. I agree that the Executor shouldn't be responsible for this, but neither should the model. I think a better abstraction would be to have another object responsible for computing the loss; the base behaviour would be to do this using the predictions and labels, but one could extend this behaviour to accept the model itself too, and compute the regularization terms for instance. The executor's behaviour is then to call backprop() on whatever this criterion like object returns. This way the model is only responsible for performing the forward pass, which is a good division of responsibility.
As an example usecase, say you are doing something related to domain generalization and need to induce orthogonality in the representation space, and you choose to do this by adding some cosine similarity terms to the loss. As it stands, this needs to be the responsibility of the model wrapper, but conceptually, it isn't really a wrapper, and there ought to be some point at which the end user can extend the behaviour without opening up the model and changing it's behaviour.
Which brings me to the XLNet example. While you can indeed implement this by using inheritance, it seems like an incorrect usage. A far better example of a model wrapper is in the BERT example, where the wrapper accepts the model as a dependency. I think the doc might benefit from using a similar XLNet wrapper that doesn't need to call super(), but can still perform it's computations by wrapping the loss into a dictionary. Thoughts?

On Return Types
Prior to Python 3.8, I've been using NamedTuples in my own code to maintain some sanity in terms of what my methods return, since having dictionaries flying all around can quickly lead to highly uncivilised code. However, with the introduction of PEP 589, it seems like TypedDict might be a better return type to get from the forward() method. I think it would be more prudent to wait for pytorch to support Python 3.8 before this happens, but I was curious about your thoughts on this.

It's great to know you are willing to accept pull requests, I can modify the parts of the executor to fix this design assumption and issue a pull request. We can figure out the final design in this thread if it's the best way to keep track of things.

Wow, I didn't realize that! It is a small world indeed :D

On the topic of whether the model should compute the loss, I guess it's more of a personal preference. I've seen quite a lot of code (albeit research code) that computes the loss within the model, so I would say habit-wise this is acceptable to most people. You example of adding additional terms outside the model is a very reasonable use case, but there are also cases that favor having the model compute the loss, such as losses that consist of several parts.
Indeed, the XLNet example is not a good example in terms of class hierarchy, because as you said, it's weird to inherit the wrapper from the model. I think the better term to describe what we want here is an "adapter" that somehow connects the model and the Executor. Since the user will probably need to write such an adapter anyway, I think it would be better to keep the current design, instead of creating a new general adapter module. What do you think?

I've used the TypedDict type in a couple of cases in the Texar codebase, but IIRC it has a number of limitations: 1) you can't add keys that are not defined in the type signature; 2) you have to use a string literal but not an str variable; otherwise it won't typecheck. These are against the intended usage of the returned dictionary (the user should be able to add arbitrary fields), so I don't think it's necessary to use TypedDict as the return type.

I'm happy to know that you'd be willing to contribute! Let's keep the discussion within this issue. In the meantime, you're more than welcome to take a look at other outstanding issues as well 😄

Ah I should probably have explained it better; I am not against the model computing the loss if the programmer so intends, I am mostly against the framework being prescriptive about requiring the model to compute it, and offering no other obvious opportunities to inject the logic.
The current way of doing this would indeed require the user to write a wrapper for the model. For a running example, say the loss consists of three terms, followed by a regularization term, and we want to compare L1/L2/L1+L2 regularization. Let the model compute the first three terms. In the current design I could write one model class and three regularization modules that accepts the model, compute the forward pass, add the regularization term to the loss term and return the dictionary with the composite loss. The only nuance is that this module is masquerading as the model itself, while it isn't.
So in essence, what I am proposing is something like a Criterion module that assumes the sole responsibility of returning the loss, parts of which could indeed come from the model itself, but it's no longer the responsibility of the model. So the pseudocode algorithm is as follows:
outputs = model(batch, **model_kwargs)
# Currently subsumed by the previous step. Here, one could even follow
# the pred_name, label_name setup for metrics and pass in only the relevant
# items, allowing for a Metric object to serve as a criterion, but the following
# allows the user to pass in other items to the criterion by forwarding the outputs
# and the batch. This seems like the safest abstraction for now.
loss = criterion(outputs, batch)
if regularizer:
    loss += regularizer(model)
loss.backward()

Indeed, this essentially performs the steps that an adapter would, like you said, without needing the user to write an adapter in the most common usecase, and just passing in some default criterion and regularizer.  I'm advocating for the criterion to be a first class entity in the pipeline, since it conceptually matches the training process in my opinion, and allows for . As for the XLNet example, my comment was mostly about updating the docs with a non-inheritance example, so as to not encourage people to adopt that pattern when the examples already execute a better pattern. Thoughts?

Ah yes, I agree that the inability to have extra keys is extremely restrictive, but I found that the expected behaviour is supported for function arguments. For convenience, from that link:
from mypy_extensions import TypedDict

A = TypedDict('A', {'x': int})
B = TypedDict('B', {'x': int, 'y': str})

def f(x: A) -> None: ...

b: B = {'x': 1, 'y': 'foo'}
f(b)  # Ok

The restriction on extra keys applies to creating the dict, but I imagine the way to use it in the executor loop would be similar to the above example. There's probably a few other considerations I am missing, but this one seems manageable in terms of the extra keys?

I understand your concern, but in my opinion this is more of a naming problem instead of a design problem. If you think the name "model" is confusing, I'm willing to change it to "module" or something else.
The problem with the criterion approach that you're proposing is that the user would probably have to write their own "criterion adapter" as well. I know PyTorch provides module-style losses, but in order to use them you'd need to pass in the label tensor, not the batch object. The metric approach could work for simple losses, but not for stuff like the sequence_sparse_softmax_cross_entropy which requires text_ids and length, or for more complex ones such as the GAN loss.
My point is, we want to make this simple for the user, and having one custom class is probably better than having two. For switching between training and validation modes, the model adapter can use the nn.Module.training flag to determine the current mode, and apply dropout/regularization accordingly. If you wish to separately control training mode and regularization, you can always add a new argument to the adapter (and personally I believe this is better than built-in support because IMHO this is not a very commonly used feature).
For the XLNet example, I agree with you that using non-inheritance adapter-style is better, and will create a PR to change that.

The support for function arguments does not completely solve the problem. Take this snippet as an example:
from mypy_extensions import TypedDict
import torch
from torch import nn

class ReturnDict(TypedDict, total=False):
    loss: torch.Tensor

class ModelAdapter(nn.Module):
    def forward(self, input: torch.Tensor) -> ReturnDict:
        return {
            "loss": torch.sum(input),
            "something_else": input,
        }

mypy would complain on the return line that there are extra keys in the TypedDict. I think it's better to just use Dict[str, Any] until there's official support for extra keys for TypedDict.

Hey Zecong, thanks for getting back to me.

** On side-effects of the model adapter**
So I'm assuming we have the overarching goal that simple things should be simple, but complex things should still be doable in preferably not complicated ways. Ideally, in the simplest use-cases, the user shouldn't have to write any adapter at all. This is covered by having the model's forward method return the loss. So far so good.
Now if you're writing an adapter, my concern is not so much to do with the name, but with the responsibility. As far as possible, I think it's better to have a class have a single well-defined responsibility.
So what is the responsibility of a model adapter? Currently, this is to wrap any outputs into a dictionary that has a loss item. It's well-defined. If you start using it as a catch-all to add branching logic about training and validation, it's purpose is going to quickly start bloating.  Also, if you recommend that the adapter can change model state, it's harder to have any guarantees about the side-effects of the adapter down the road. Will dependent methods be able to work with the guarantee that the model adapter does not alter the model state as a side effect?
Besides, it seems appropriate that the executor should encapsulate any branching logic of that nature because it has to do with execution anyways.  As of now, the executor handles the model mode via calles to self.model.train(self.test_mode == 'train') during the evaluation methods.  I don't think that's a responsibility that needs to be split between the adapter and the executor when it's already appropriately taken care of.
For these reasons, I am of the opinion that the adapter shouldn't be responsible for more complex logic than simple transforming of output data from the forward pass into an appropriate data structure. If you believe it's alright for the adapter to alter model state, I'd request you to consider how these side effects might affect the building of future behaviour using these interfaces.

** On regularization **
I'm a little confused about what you're referring to as a not commonly used feature; is it turning off regularization during computation of the validation loss? If that's what you're referring to, I think how commonly it is used depends on whether people want to compare the validation and training losses. If only the training loss is being looked at, sure it's not as important. But the difference between the curves is something that's taught in Intro to ML courses, so it ought to be supported without having to right custom logic to turn off regularization. To me this is a similar responsibility to calling model.train() or model.eval(), and therefore falls under the purview of the executor.

** On losses as a separate module **
I agree that the user shouldn't have to write a criterion wrapper in the simple cases, and I now that I think of it more, they need to be modules as such; what I was proposing is that the executor accept any callable object. This could be a function itself or an nn.module. In the simple cases, any metric can be passed in.
As for the arguments being labels or batch, this is easily solved for the simple cases by having a default decorator that extracts labels from the batch object and passes it in. But having a general interface for passing in the batch as well as the outputs allows for easier extension of custom behaviour that is not currently possible since you might need more information than the labels and pred in computing losses; you can think of variational inference applications as an example where you need to compute KL terms between different things that's not just the labels of preds.

Yes of course, that's what I meant by the problem only being during creation of the dictionary. The reason I said this isn't a problem while using is something like this:
# ... imports ...

## LIBRARY CODE ----
# Somewhere in the Executor
# Not quite sure why you have `total=False`, I believe we don't want to omit the loss key
DictWithLoss = TypedDict("DictWithLoss", {"loss": torch.Tensor}, total=True)
...
def some_executor_method(d: DictWithLoss):
    loss = d["loss"] # should be okay according the example below
    loss.backward()
...
## -----

## USER CODE ----
UserReturnDict = TypedDict("UserReturnDict", {"loss":torch.Tensor, "something_else":torch.Tensor})

class ModelAdapter(nn.Module):
    def forward(self, input: torch.Tensor) -> UserReturnDict:
        return {
            "loss": torch.sum(input),
            "something_else": input,
        } # ---> should be okay
## ----

So I think in terms of usage, this should be fine. I don't have a strong opinion on TypedDict being used, but coming from a C++ background I liked the typing constraints and having users think about what they put in their dictionaries to avoid bloat. But I'll admit this is me probably reacting to looking at code updates where people start sticking more things in dictionaries just because they can.

Sorry for getting back to you late; been busy during the holidays.

I think the word "statefulness" better describes the case than "having side-effects". I don't think the adapter being stateful is a bad thing, since all PyTorch modules have states built in them (e.g., the train/eval flag). However, I do agree that the example I showcased is not the best design, as it requires users to manually switch states outside of the executor, and they might forget to do so.
The purpose of the example was to provide an easy solution for the goal of "computing training loss under eval mode but keep regularization terms", without modifying any of the executor internals. After reading your replies again, I realize that I have probably misunderstood your requirements. Let me try to rephrase the question you were asking:

You would like to add to the training loss some regularization terms (e.g., L1/L2), which should not be computed during validation or testing.
You would like to compare the curves of training and validation losses over epochs, and to do properly it is necessary to compute the loss on the training set under evaluation mode.
You would like to separate the actual model (that computes logits/predictions), the loss computation, and regularization into different modules.

For 1., I guess the better way to do it would be to check for self.training in the forward function of the adapter and add the regularization term only during training. This is similar to how dropout is implemented and requires no modifications to the current framework.
For 2., my argument of this not being a very commonly used feature, is mainly limited to deep learning applications, where the training set is often too large for this to be practical. I'm less familiar with applications outside of the NLP domain, but I can see how this would be useful on smaller datasets or computationally cheaper models. But, as you said, this can be done in the current framework by manually evaluating on the training set in a custom validation action. What could be improved here is to allow the custom action to return metric values so the training losses (w/o regularization) can also be registered as a validation metric.
For 3., I stand with my previous opinion that coupling the loss/regularization with the model makes more sense. My major points are:

Having separate model and loss modules would mean introducing a large number of custom loss modules, which introduces more boilerplate code for the user.
Having regularization outside the model would only work for regularization methods that considers only model parameters, such as L1/L2. Not all models use this kind of regularization. Other methods such as dropout or batch/layer normalization are embedded into the model architecture, and don't work this way.
In terms of switching between different losses/regularizations, both designs would require equal efforts for the user: to switch modules (with appropriate constructor arguments) in the executor config, or to switch function (with appropriate call arguments) in the adapter.

Of course, it is also possible, for instance, to allow the user to add regularization in the executor arguments. However, this gives the user less control over the training process. For example, the user might want to also return the loss value without the regularization terms in a separate dictionary entry, but it's not possible (or less straightforward) to do so with regularizers handled by the executor. Similarly, it wouldn't be difficult to observe individual loss components in a complex loss module, or to enable/disable loss computation for evaluation.

I see your point with the TypedDict, and I think they can be integrated into the current framework. My concern is that mypy might throw errors where we access the return dictionaries using metric pred_names, if the type of the return dictionary is restricted to DictWithLoss.
I'll look into this and submit a separate issue, but you're also more than welcome to propose changes!

No worries about the delay in response, enjoy your holidays!

I think we are ultimately saying the same thing on this subpoint, but for clarity:

It's statefulness if the adapter is a subclass of the model, because the state of the model is the state of the adapter. In this case it seems wasteful to have the model internally branch in every forward pass depending on state.
It's a side-effect if the adapter is any class that wraps a model; the adapter in this case need not even be of type nn.Module, and could call the forward on the model, compute and embed the loss in a dictionary and return it. The reason it's a nn.Module subclass is so that the executor can call a forward on it. Changing model state in this forward pass is a side effect because the model goes in in some state and may or may not remain in the same state once the adapter is done with its operation. Function interfaces are like contracts, and if the contract semantics is to just return the loss in a dictionary, altering the model state qualifies as a side-effect in this case.

Before I try and distill the essence of why I think the former is the poorer choice, let me restate the principle of the executor from your comment above:

the design principle of the Executor is to leave all model-related computations to the model, so that the Executor itself can be as general as possible.

With this in mind, I think the essence of the design flaw as I see it this:

It is sort of weird for the model to have to care about anything to do with training itself. A model performs some task given some inputs. In most cases, this involves making some predictions. It shouldn't have to have knowledge of the concept of a loss,  or existence or absence of ground truth labels to compute a loss, or how well it is performing.

The exception to this is that the model has some gradients sure, but it shouldn't need to know how those are computed. That is the job of the training apparatus, so at the very least it should happen outside the model.
If you can concede this, then it makes sense that the the measures required for making a model better at its task, the loss, regularization, metric, etc. live outside the model, because while they relate to the model, they aren't inherently a part of the model's task, and so not a part of "model-related computations". This is more than a naming problem; if you think of the adapter as a model subclass, it's a behavioural semantic. I agree these computations shouldn't be within the executor, and that it should be possible to modify the executor's behaviour by injecting such logic. So option 2 above, with the adapter wrapping the model is a better option, and still in line with the design principle.

For ease of consumption, I'll respond to your specific proposed solutions in a  follow-up comment, but I wanted to leave the core argument here, and use it as context next.

Right, so hopefully we agree that the computations pertaining to training the model should be outside the core model, and outside the executor itself, with the adapter being the candidate to hold this logic. With that,

For 1., I guess the better way to do it would be to check for self.training in the forward function of the adapter and add the regularization term only during training. This is similar to how dropout is implemented and requires no modifications to the current framework.

I agree. If this is done within the adapter though, it needs to branch on the model state, which isn't too bad, but not the most elegant I think since the check needs to be performed in every forward pass.

For 2., ... What could be improved here is to allow the custom action to return metric values so the training losses (w/o regularization) can also be registered as a validation metric.

That's an interesting idea, registering the loss w/o regularization as a validation metric. The way I had envisioned it, the regularization bit comes from a separate callable, so the same core loss function could be reused across the train and val loops.

For 3., I stand with my previous opinion that coupling the loss/regularization with the model makes more sense.

I can partially agree if you mean the coupling occurs with the adapter and not the core model for reasons covered in my previous comment. However, even with the adapter, this solution condemns the user to having to write an adapter in almost all cases, which to me is a symptom of a design flaw. In the most simple case, the user ought to be able to write the core model, specify a core loss, an optional regularizer, and optimization procedure and let the executor handle the rest. No adapters needed, since the criterion returns the loss anyways. The need for an adapter is itself in some way boilerplate code to me.

Having separate model and loss modules would mean introducing a large number of custom loss modules, which introduces more boilerplate code for the user.

I should clarify that I'm not advocating for module losses. In my pseudocode above I assumed any callable object that accepts the labels and outputs and computes the loss. This could be a function, an object, an nn.Module subclass, left upto the user. In this case, there are specific loss functions already provided, so this falls under the same category. These functions should just be passed in like they are, and the user can write custom ones if so desired.

Having regularization outside the model would only work for regularization methods that considers only model parameters, such as L1/L2.

True. Although, there are some papers that argue that dropout doesn't necessarily perform the regularization it is thought to perform. However, this is irrelevant to the spirit of your argument, which holds. I was indeed referring to reg terms that are computed from model parameters and used in the optimization.

In terms of switching between different losses/regularizations, both designs would require equal efforts for the user: to switch modules (with appropriate constructor arguments) in the executor config, or to switch function (with appropriate call arguments) in the adapter.

I think I have to disagree here. In the most common case with what I am proposing, the user doesn't have to write any adapter at all, or at best a thin adapter that wraps the loss in a dictionary. The branching logic, etc. is handled by the executor. So the user has to write a custom regularizer if there is a need, such as for maintaining orthogonality of RNN weights, and pass that in. Even with similar work, I'd argue configuring the executor is a more elegant solution than branching logic in the adapter, with the user having to write one in most situations.

Of course, it is also possible, for instance, to allow the user to add regularization in the executor arguments. However, this gives the user less control over the training process.

This statement seems a little self-contradictory, perhaps? An optional argument to inject logic ought to afford the user more flexibility without being prescriptive. The other use-cases you describe are still supported by the library in my proposed alteration, and the user can choose to completely ignore the optional regularizer and compute all those terms in an adapter if they choose to write one. It's just not required in most cases by the relaxation of the need for the model wrapper to return a loss.

Sorry for the long comments, I thought it best to err on the side of being more specific to avoid confusion. In any case, thanks for engaging in this discussion!

Thanks for the reply. I appreciate you putting so much thought into the executor design!

I think your core argument is that loss computation and regularization is not part of the model's responsibility, and should not be done in the model class. However, I believe this is more of a personal preference than a rule to follow. True, in machine learning definitions the model is separate from the loss, but in practice they're often coupled together. Forcing them to be separate modules or functions seems, to me, a bit like abstraction for abstraction's sake.
I can give examples where changing loss functions would require modifying the model's internal computations. Consider word-level language models with a large vocabulary size. At each time step, the model predicts the next word given previous context. The most straightforward way to do this is compute the entire logits as a tensor of [B x V], where B is batch size and V is vocab size, and then apply the cross-entropy loss. However, in practice this is too slow, so people use a variety of techniques:

Sampling-based losses, including importance sampling, noise-contrastive estimation, and negative sampling (not exactly for LMs, but often for word2vec-style stuff). These allow the model to only compute logits for a sampled subset of words.
Hierarchical losses, including hierarchical softmax and adaptive softmax. Both methods group vocabularies into a tree structure, where leaves are words. The model then only computes logits for each non-leaf node along the path from the root to the leaf (word).

As you can see, each different technique requires the model to compute logits differently. These losses can be used interchangeably in the same model, but would require non-trivial modifications to the model itself. If you're interested, check out this article for more information on these techniques.

And let me address your refutations to my claims in the previous reply:

The adapter is boilerplate code.

This is true, and is something I'm trying to get rid of. The problem is mainly with the return values -- most existing modules would just return the output as a tensor or a tuple of tensors, but not as a dictionary. However, the adapter is not for the sole purpose of computing the loss, so separating model and loss would not get rid of the adapter.

On losses module.

My argument is not limited to module-like losses. My point was that having the loss computed outside of the model would require the user to write additional code to adapt between the model and the loss, be it in the form of a class or a function.

Branching logic.

I'm not sure what you mean by "the branching logic is handled by the executor". I would assume that if the loss or regularizer is set in the executor arguments, it would be something like this:
executor = Executor(
    ...,
    loss=tx.losses.sequence_sparse_softmax_cross_entropy,
    regularizer=tx.core.L1L2(l1=0.5),
    ...)

Then if the user were to choose between multiple losses, they would still have to write something like:
if args.loss_type == "mle":
    loss_func = tx.losses.sequence_sparse_softmax_cross_entropy
elif args.loss_type == "adversarial":
    loss_func = some_adversarial_loss_function
# or, something like:
# loss_func = tx.utils.get_function(args.loss_func_name, tx.losses)
executor = Executor(loss=loss_func, ...)

I don't see how this would be too different from doing things in the model class. And this is assuming the losses can be used as is, without adapting to your model or setting additional arguments.

Optional argument for regularizer.

What I was talking about is if we only allowed specifying the regularizer through executor arguments. I agree that if we allow both choices, it would be more flexible for the user. But in my opinion it might also become a source of confusion to the user -- the user might apply regularization in both places and not realize so.

Thanks for the link! I am aware of some of these, and the thrust of the argument seems to be that the model computations might have to change depending on the loss computation. This is true, and in these cases the model ought to change anyways so it's okay to write multiple model classes. However, this doesn't seem to me to be a reason to couple the responsibilities, because it  makes the simpler cases significantly more convoluted than needed.  I also don't think I explained my point very clearly.
For having a common reference, here's a complete-ish example with suitable adaptation of the ConditionalGPT2 Model example for illustration. Say I would like to train the model with two losses (sequence_sparse_softmax_cross_entropy, sequence_softmax_cross_entropy), and orthogonal regularization (arbitrary choice, might not make most sense, but works for illustration):
# ... imports ...

## ------------ Ideal minimum user required code ---------------

class ConditionalGPT2Model(nn.Module):
  """An encoder-decoder model with GPT-2 as the decoder."""
  def __init__(self, vocab_size):
    super().__init__()
    # Use hyperparameter dict for model configuration
    self.embedder = tx.modules.WordEmbedder(vocab_size, hparams=...)
    self.encoder = tx.modules.TransformerEncoder(hparams=...)
    self.decoder = tx.modules.GPT2Decoder("gpt2-small")  # With pre-trained weights

  def _get_decoder_output(self, batch, train=True):
    """Perform model inference, i.e., decoding."""
    enc_states = self.encoder(inputs=self.embedder(batch['source_text_ids']),
                              sequence_length=batch['source_length'])
    if train:  # Teacher-forcing decoding at training time
      return self.decoder(
          inputs=batch['target_text_ids'], sequence_length=batch['target_length'] - 1,
          memory=enc_states, memory_sequence_length=batch['source_length'])
    else:      # Beam search decoding at prediction time
      start_tokens = torch.full_like(batch['source_text_ids'][:, 0], BOS)
      return self.decoder(
          beam_width=5, start_tokens=start_tokens,
          memory=enc_states, memory_sequence_length=batch['source_length'])

  def forward(self, batch): ## modified to return only outputs
    """Compute training loss."""
    outputs = self._get_decoder_output(batch)
    return {"outputs": outputs.logits}

  def predict(self, batch):
    """Compute model predictions."""
    sequence, _ = self._get_decoder_output(batch, train=False)
    return {"gen_text_ids": sequence}

# Adapted from github.com/kevinzakka/pytorch-goodies into a module for illustration
class OrhogonalRegularizer(nn.Module):
    def __init__(self, reg=1e-6):
        self.reg = reg

    def forward(self, model):
        orth_loss = torch.zeros(1)
        for name, param in model.named_parameters():
            if 'bias' not in name:
                param_flat = param.view(param.shape[0], -1)
                sym = torch.mm(param_flat, torch.t(param_flat))
                sym -= torch.eye(param_flat.shape[0])
                orth_loss = orth_loss + (self.reg * sym.abs().sum())
        return orth_loss

# Losses
loss_func = tx.losses.sequence_sparse_softmax_cross_entropy
loss_func_sparse = tx.losses.sequence_softmax_cross_entropy

# Instantiate
model = ConditionalGPT2Model(...)
regularizer = OrthogonalRegularizer()

Ideal Scenario
With the previous user specification, it would be great if the user can just leave the rest to the executor using an interface like so:

executor = tx.run.Executor(
    model=model,
    loss=loss_func,
    regularizer=regularizer,
    keys = {pred_name:"outputs",  labels:"target_text_ids"} # something like this,
    ....
)

executor_sparse =  tx.run.Executor(
    model=model,
    loss=loss_func_sparse,
    regularizer=regularizer,
    keys = {pred_name:"outputs",  labels:"target_text_ids"} # something like this,
    ....
)

I'm using keys as some dictionary that specifies how the executor can unpack the data returned by the model, and the batch, and pass those into the loss in the simplest case for provided losses. Of course, the user can write a custom loss and pass that in too. Alternatively, the functionality can be extended via helpers provided by the Executor, without needing to modify the Executor class (Open-Close principle).
Current reality
In the current design, to make this work, the user is forced to write the following additional code unless I am mistaken:
class GPT2WithSoftmaxCrossEntropy(nn.Module)
    def __init__(self,  gpt2, regularizer=None):
        self.gpt2 = gpt2
        self.regularizer = regularizer

    def forward(self, batch):
        logits = self.gpt2(batch)["outputs"]
        loss = tx.losses.sequence_softmax_cross_entropy(
            labels=batch['target_text_ids'][:, 1:], logits=logits,
            sequence_length=batch['target_length'] - 1)
        if self.training: ## Branching
            if regularizer:
                loss += regularizer(self.gpt2)
    return {"loss": loss}

    def predict(...):
       ....

class GPT2WithSparseSoftmaxCrossEntropy(nn.Module)
    def __init__(self,  gpt2, regularizer=None):
        self.gpt2 = gpt2
        self.regularizer = regularizer

    def forward(self, batch):
        logits = self.gpt2(batch)["outputs"]
        loss = tx.losses.sequence_sparse_softmax_cross_entropy(
            labels=batch['target_text_ids'][:, 1:], logits=logits,
            sequence_length=batch['target_length'] - 1)
        if self.training: ## Branching
            if regularizer:
                loss += regularizer(self.gpt2)
    return {"loss": loss}

    def predict(...):
       ....

Issues
The above code that the user is forced to write is problematic for several reasons:

Additional code:
The executor is truly useful if the user can specify the experiment parameters similar to the minimum specification above and use the executor to run the rest. Currently the above two classes are required (or one if you branch on loss type, refer next point), which can be easily handled by auxiliary helper classes within the executor.

Avoidable code duplication:
One might argue that instead of two classes, the user can write a single adapter and accept the loss function as an argument and branch on that. That's really bad for testing on the user side. I understand people in academia don't usually write tests, but if you start writing these, you have to add validation tests for different behaviours, increasing development time and writing less maintainable code.

Worse, people might start passing in the loss function and regularizers into the original GPT2Model class instead of the adapter, which is even messier.
This is a case of the library violating the Single Responsibility Principle, and in turn forcing the user to write unnecessary code, or worse, violating the Dependency Inversion and Open-Close principles themselves.

Responsibility leaking:
The logic in both of the adapters is execution logic. Even in this straight-forward case the user has to handle some of the execution branching logic that should be the responsibility of the executor. The simple scenarios ought to work out of the box while allowing the user to inject more advanced logic via helpers etc.

Branching:
Note that my comment about branching logic wasn't on the type of loss, but on the model state. Also note that this branching check will be performed on every iteration of the data iterator

From a user's perspective, the overhead of adding a dependency to a project ought to be overshadowed by the benefits. Currently if I advocate of adding this library for the repositories I am responsible for, I would have to invest in a more robust testing suite for the user code, owing to easily avoidable issues in an otherwise excellent library interface. Hopefully I have done a slightly better job of explaining the bigger picture and considerations that go into adopting a new library, and the potential issues of dropping texar-pytorch into the workflows I am responsible for.

Technically, you have answered my original questions within the current interface design, so feel free to close this issue. However, we have wandered into the territory of proposed changes, and there might be valuable discussions here, so perhaps it's easier if we continue this discussion if you find it useful by changing the labels? I might test a few interface changes in my fork and am happy to issue a PR if you find it useful too.

Hey, so sorry for the late reply. Been caught up by work piled up during the holidays.
I'm fine with continuing the discussion here, and I've changed the label from "question" to "discussion".

Thank you for explaining your point in detail with code examples. However, I'm afraid I can't agree with you on all these points.

Additional code. This one I agree with. Your design can reduce a part of the boilerplate code.
Responsibility leaking and branching. I kinda feel that these are talking about the same thing. It is true that with the current design, the user must take on the responsibility of checking the model state, and it might be sub-optimal. If this is really a big issue, I think the better option might be to adopt what is already in the framework, i.e. regularizer classes like nn.Dropout that handles state checking within.
Avoidable code duplication. I think this point is more about testing. I don't think there's too much difference here, and I'll show that in an example below.

In your example you assumed that the keys dictionary are the same for both loss functions. However, when they're different, in the current design, you can write:
class GPT2WithSoftmaxCrossEntropy(nn.Module)
    def __init__(self,  gpt2, loss_func: str):
        self.gpt2 = gpt2
        self.loss_func = loss_func

    def forward(self, batch):
        logits = self.gpt2(batch)["outputs"]
        if self.loss_func == "sparse":
            loss = tx.losses.sequence_sparse_softmax_cross_entropy(
                labels=batch['target_text_ids'][:, 1:], logits=logits,
                sequence_length=batch['target_length'] - 1,
                label_smoothing=0.1)
        else:
            loss = tx.losses.sequence_softmax_cross_entropy(
                labels=batch['target'][:, 1:], logits=logits,
                sequence_length=batch['target_length'] - 1)
        return {"loss": loss}

In your alternative design, you'd have to write (or put these in a config):
if args.loss_func == "sparse":
    loss_func = tx.losses.sequence_sparse_softmax_cross_entropy
    keys = {"logits": "logits", "labels": "target_text_ids",
            "sequence_length": "target_length",
            "label_smoothing": 0.1}  # additional kwargs too
else:
    loss_func = tx.losses.sequence_sparse_softmax_cross_entropy
    keys = {"logits": "logits", "labels": "target",
            "sequence_length": "target_length"}
executor = tx.run.Executor(
    model=model,
    loss=loss_func,
    regularizer=regularizer,
    keys=keys,
    ....
)

which I think is more or less the same. It doesn't really enable you to test less code -- you'd still need to cover both branches; if you're loading everything from a config, you'll need to test that the config is written correctly. Either way, even a well-tested library doesn't give you that benefit, it's the user code you'd still have to test.
Also, the code you showcased was not exactly fair comparison. In the current design the model outputs cannot be directly used in the loss, it needs to be sliced or subtracted. So, in order to specify the loss in the executor arguments, you'd need to return a bunch more in the model adapter:
def forward(self, batch):
    outputs = self.gpt2(batch)
    return {"outputs": outputs["logits"],
            "target_text_ids": batch["target_text_ids"][:, 1:],
            "target_length": batch["target_length"] - 1}

which also makes it longer, or at least not much shorter compared to the current version.

To summarize, as I said before, I think your design is reasonable and would make the code shorter and perhaps more readable in certain cases, and those are probably the cases that you often work with. However, the design would make other cases harder to implement, and does not really serve the purpose it's supposed to serve. Since we want Texar-PyTorch to be a general-purpose library, we probably have to choose the current design over yours.
But still, thank you for bringing up the topic and engaging in the discussion. It made me think about the current design and gave me ideas for improvement.

Closing due to lack of activity.


Add pt-br/docs/reference/glossary/cloud-provider.md

Added translation for portuguese of the glossary term cloud-provider.

/assign

Thanks!
/lgtm

/approve
Thanks!


Preview images for Issue cards in Project Board view

Original Issue: https://github.com/go-gitea/gitea/issues/22102
This addition would be a big benefit for design and art teams using the issue tracking.
The preview will be the latest "image type" attachments on an issue- simple, and allows for automatic updates of the cover image as issue progress is made!
This would make Gitea competitive with Trello... wouldn't it be amazing to say goodbye to Atlassian products? Ha.
First image is the most recent, the SQL will fetch up to 5 latest images (URL string).
All images supported by browsers plus upcoming formats: *.avif *.bmp *.gif *.jpg *.jpeg *.jxl *.png *.svg *.webp
The CSS will try to center-align images until it cannot, then it will left align with overflow hidden. Single images get to be slightly larger!
Tested so far on: Chrome, Firefox, Android Chrome, Android Firefox.
Current revision with light and dark themes:

I think maybe make it optional is beter.

I think maybe make it optional is better.

Done, video:
https://user-images.githubusercontent.com/24665/207960088-4c651f61-c617-4c05-9663-6b433c92ed2a.mp4
Also allows us to add new card types per-project in the future.

A migration in models/migrations/migrations.go is required to change the database schema to help user to create a new column smoothly. And you could also update the old records as CardTypeTextOnly.

I do not think this feature is good for all users.
IMO it only looks "good" for art teams, but it may look bad for other users/cases.
For example, if the issues in a  project board are mostly for software testing purpose, there will be full of various screenshots. Showing a lot of screenshots on the project view might make the UI messy?

That's why there is a card option here.

Oh I see, just missed that option.

Added migration.

@lunny Apologies for the wait, added.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@b878155). Click here to learn what that means.
The diff coverage is 48.07%.

@@           Coverage Diff           @@
##             main   #22112   +/-   ##
=======================================
  Coverage        ?   48.10%
=======================================
  Files           ?     1046
  Lines           ?   142433
  Branches        ?        0
=======================================
  Hits            ?    68513
  Misses          ?    65739
  Partials        ?     8181

Impacted Files
Coverage Δ

services/forms/repo_form.go
39.50% <ø> (ø)

models/project/project.go
33.78% <7.14%> (ø)

routers/web/repo/projects.go
16.30% <40.00%> (ø)

models/project/board.go
31.05% <66.66%> (ø)

models/repo/attachment.go
56.81% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Another improvement could be to store the attachment type i.e. is_image when upload, but that could be another PR.

Please resolve the conflicts.

Good to go. Thanks for all the feedback. @lunny @wolfogre

Also thank you @silverwind

@wxiaoguang Good catch! My bad, was left over when I re-merged with master.

@delvh Thanks for the help with the migration, btw! Still getting used to how that works in gitea, and it's great to see simpler patterns in there.

LG-TM bot

The attached migration causes db migration to fail on startup.

@zeripath I'll make a PR. Figured that might be the case on non-sqlite.
@wolfogre For future reviews, re: https://github.com/go-gitea/gitea/pull/22112#discussion_r1095411471

It's actually on sqlite that I noticed it!


Add path to generated env var for project

To get users to implementing the project quicker and less likelihood of stalling progress. They can specify the path to the generated credentials within project. Users can have multiple projects that can require different credentials.

Yeah, I was stalled on this part of the project for a while. This is what got me over the issue.

@nimicent Looks good, as Steve mentioned, can you add a note to the README so users would be aware of the option?


Adding more capabilities

Hi there!
First of all, what a great package! Thank you for creating this.
I was wondering if you'd be open to any PR on the below areas:

Files
Fine tuning

I would like to extend the package so we could upload training files and ultimately fine-tune also.
Let me know :)

Hi, @oliverbj file uploading is shipped. 🚀 🚀 🚀 🚀 🚀

@orhanerday This is awesome - thanks for pushing this out so quickly. Did you ever get a chance to look at Fine Tuning? (Docs: https://beta.openai.com/docs/api-reference/fine-tunes)
Again, happy to contribute with a PR if needed!

Sorry I forgot that part. Fine tuning similar to file upload. I’ll check tomorrow. UTC 14:00 🕑
If I need help I’ll touch thanks 🙏

Sorry I forgot that part. Fine tuning similar to file upload, so seem easy. I’ll check tomorrow. UTC 14:00 🕑 If I need help I’ll touch thanks 🙏

Really appreciate you taking the time to do this - thank you!!!

Your welcome @oliverbj,
I create PR could you please review it?

Your welcome @oliverbj ,
I create a PR could you please review it?

Just reviewed it, and it looks good from my end! Thanks!

Code shipped to packagist.
Have fun with v2.1 y'all 🚀🚀🚀


Use of unnamed union

There was an issue compiling the squash density plugin, which I believe might be due to the use of an unnamed union in src/main_header.h. Support for this was not added until C11, but many versions of GCC supports it as an extension. If you compile density with -pedantic, you get the following warning:
../src/main_header.h:55:6: warning: ISO C99 doesn't support unnamed structs/unions [-Wpedantic]

Note that this causes compilation to fail with GCC 4.4 (on CentOS 6, gcc 4.4.7) when compiling with -std=c99.  Compiling with -std=gnu99 works, but unfortunately setting the C standard in CMake to C99 will use c99 not gnu99.


Port is already being used using mdillon/postgis:latest

Getting this error message when running the image setup:
listening on IPv4 address "<IP_ADDRESS>", port 5432
could not bind IPv6 address "::1": Cannot assign requested address
Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
I've already checked that nothing is running on port 5432 locally. I'm using docker-compose with a bridged network, so the port conflict shouldn't have anything to do with locally running ports anyways.
The weird thing is that it did work just a week ago, but now the port is occupied on that network.
I've even tried reinstalling docker, and it still isn't working. It is however working when I use the 9.6 version.
Changing the port doesn't do anything either.
My guess is that there are conflicting processes in the container

Please check with the the official postgres image ( https://hub.docker.com/_/postgres/ )
Can you replicate the problems?

The weird thing is that it did work just a week ago,

mdillon/postgis:latest  == mdillon/postgis:10 (  Created:  6 weeks ago )
$ docker images
REPOSITORY                          TAG                        IMAGE ID            CREATED             SIZE
mdillon/postgis                     10                         a6ca3144c3c6        6 weeks ago         630MB
mdillon/postgis                     latest                     a6ca3144c3c6        6 weeks ago         630MB

This is based on  postgres:10
https://github.com/appropriate/docker-postgis/blob/master/10-2.4/Dockerfile
So please test with postgres:10 image.  Can you replicate ?

I've tried with both tags, and they don't seem to work.
Dockerfile:
FROM mdillon/postgis

RUN apt-get update
RUN apt-get install -y  postgresql-plpython-$PG_MAJOR

# Install awscli, the credentials are set in the .env file
RUN apt-get install -y  python-pip
RUN pip install awscli

# ... some other work here copying sql files to container

docker-compose-file:
version: '3'
services:

    # Database (postgis)
    postgis:
        container_name: postgis
        build:
            context: ./postgis/
        restart: unless-stopped
        networks:
            - test-network
        ports:
            - "5001:5432"
        env_file: ./.env
        environment:
          # These are set empty to override the .env file. We need other
          # variables from there but these two interfere with the postgres
          # docker image setup.
          - PGDATABASE=
          - PGHOST=
        volumes:
          - test_data:/var/lib/postgresql

networks:
  test-network:

volumes:
  test_data:

Worked a week ago, but then when I removed the container, images and all volumes, this error message is shown:
postgis      | 2018-08-14 21:20:30.071 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
postgis      | 2018-08-14 21:20:30.071 UTC [1] LOG:  could not bind IPv6 address "::1": Cannot assign requested address
postgis      | 2018-08-14 21:20:30.071 UTC [1] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
postgis      | 2018-08-14 21:20:30.074 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgis      | 2018-08-14 21:20:30.087 UTC [148] LOG:  database system was shut down at 2018-08-14 21:20:29 UTC
postgis      | 2018-08-14 21:20:30.094 UTC [1] LOG:  database system is ready to accept connections

Okay, so when I switch network to network_mode host, it works. Although when I use another network, let's say dev-network, I still get the issue

Don't know if it has something to do with postgresql-plpython-10. When I run the Dockerfile without including the extension, I get this:
postgis      | 2018-08-15 07:35:17.591 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
postgis      | 2018-08-15 07:35:17.591 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postgis      | 2018-08-15 07:35:17.594 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgis      | 2018-08-15 07:35:17.608 UTC [94] LOG:  database system was shut down at 2018-08-15 07:35:17 UTC
postgis      | 2018-08-15 07:35:17.659 UTC [1] LOG:  database system is ready to accept connections

But as soon as I include installing postgresql-plpython-10, I get this:
postgis      | 2018-08-15 07:37:04.252 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
postgis      | 2018-08-15 07:37:04.252 UTC [1] LOG:  could not bind IPv6 address "::1": Cannot assign requested address
postgis      | 2018-08-15 07:37:04.252 UTC [1] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
postgis      | 2018-08-15 07:37:04.257 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgis      | 2018-08-15 07:37:04.272 UTC [94] LOG:  database system was shut down at 2018-08-15 07:37:04 UTC
postgis      | 2018-08-15 07:37:04.330 UTC [1] LOG:  database system is ready to accept connections

@jesperlandmer:
probably a weird docker network problems.    :cry:     Try to search the docker / docker-compose problems ..
I have had a similar problem - and this tip was life-saving for me:

https://github.com/moby/moby/issues/20486#issuecomment-243688178

# be carefull!
docker stop $(docker ps -aq)
docker rm   $(docker ps -aq)
#  docker system prune
systemctl stop docker
ls -la /var/lib/docker/network/files/local-kv.db
rm /var/lib/docker/network/files/local-kv.db
systemctl start docker
ls -la /var/lib/docker/network/files/local-kv.db

and upgrade your docker system if you need ..
$ docker -v
Docker version 18.06.0-ce, build 0ffa825
$ docker-compose -v
docker-compose version 1.22.0, build f46880fe

Okay, so I found this response to a similar issue #230 for postgres. Apparently the postgres-package gets updated when you go to install plpython

Also, when I try the solutions mentioned there, I get this error:
postgresql-plpython-10 : Depends: postgresql-10 (= 10.5-1.pgdg90+1) but 10.4-2.pgdg90+1 is to be installed
Is there a possiblity to publish this image with a 10.4-2 version?

Worked when I specified postgres version 10.5. I’ll create a pull request!


Playlist Endpoint

If possible, a playlist endpoint with followers and songlist would make this project 100%.

Does the desktop client have certain playlist data that the Web API doesn't? Follower count and tracks of a playlist can already be retrieved through Spotify's Web API.

Didn't know that, will use that then. Thanks! Looking forward to the next release.


Issue/410 migrate to nsurlsession

Closes #410
How to test:

Run Unit Tests and check if all pass
Run the Stats demo app and check if everything is working ok.

Needs Review: @astralbodies

:shipit: once Travis finishes.


Add HD Wallet form to Onboarding Wizard

This PR adds a new steps to the Onboarding Wizard: the HD Wallet creation form.
Why:

This is part of this issue https://github.com/iron-wallet/iron/issues/311.

How:

Add a new component/step (HDWalletStep );
Add reset form to HDWalletForm` so that the cancel button works properly.

Preview:

HDWalletStep  - HD Wallet creation form.

After saving the HD wallet, a success message is displayed below:

superseded by #614


feat: add topaction right on vtmncard component. introduction of with…

Changes description
Introduction of the class 'without-image' to remove the rendering of the image
Introduction of the 'topActions' prop and component
Implementation of two CSS classes for 'topActions'
Update of Storybook by adding the 'topActions' component inside.
Update of engine restriction version to be compatible with 18
Context
In Singapore we are using a custom component that introduce the topActions for the card

Does this introduce a breaking change?

No

 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.

Hi @AKLEIN26,
Thanks a lot for your proposition.
Unfortunately, when I check on Figma, we don't have any "top actions" for this variant of the Card without image:
That's why I suggest you create an issue on vitamin-design: https://github.com/Decathlon/vitamin-design/issues/new/choose. So it can be analyzed and potentially implemented by Vitamin's design team on all the platforms we support (web, android, iOS).
In the meantime, I'll convert your issue into a draft.
Thanks for your contribution.

Hello @AKLEIN26, as discussed together, and here, feel free to open an issue on our other repository https://github.com/decathlon/vitamin-web.
I close this issue, this will delete your branch but no worries, we will be able to restore it if your issue arrives on vitamin-web after his way on vitamin-design.
Thanks again.
Laurent


rvdm88 gif: Wrong H sweep direction ?

Hi there !
In the description, you are using a gif animation which I think is built from rvdm88's video.

Looking at a 960fps slow motion video, I can see the wheels sweeping from left to right, and from bottom to top (looking at the optical parts).
So I'm pretty surprised by the direction of the horizontal sweep (the one highlighting the vertical plane) in the animation from rvdm88. I think it should go from left to right.
Am I right ?
Note: I also posted a comment to ask the same question directly on rvdm88's last version of the video "HTC Vive Lighthouse Chaperone tracking system Explained".
PS: Thanks for sharing !

Yes! You're definitely right. It's happening from left to right if you're looking at base station from sensor point of view.


Getting Embeddings from sequence of one-hot vectors

I have input sequences that contain not just single elements, but also lists.
Eg : i1 = [2, 5, 10, [1, 7 ,9 , 20], 11, 32].
If it were just a sequence like [2,4,6,7] that does not contain a nested sequence, I would just directly pass them to the embedding layer.
But, in my case, that's not possible. So, I have decided to one-hot encode my sequences.
For example,
input = [2, 3, [1,4], 5]
Its one hot representation would be :
one_hot = [[0,0,1,0,0,0],
                  [0,0,0,1,0,0],
                  [0,1,0,0,1,0],
                  [0,0,0,0,0,0]]

How do I get embeddings for such one hot vector sequences ? Or, could someone suggest better ways to represent my inputs to get embeddings, rather than using one-hot vectors ?

@Bharathi-A-7,
From the One-Hot-Encoded Vector, I understood that the List inside the sequence has no special significance but its elements are just considered as part of sequence. If that is the case, you can remove the Lists and add its elements directly in the sequence.
This can be one way to simplify the problem. What do you think?

@Bharathi-A-7,
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you.

Closing as stale. Please reopen if you'd like to work on this further.


Switch to GitHub workflow + faster tests

Description

Motivation and Context

[ ] I have raised an issue to propose this change (required for new features and bug fixes)

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (update in the documentation)

Checklist:

[ ] I've read the CONTRIBUTION guide (required)
[ ] I have updated the changelog accordingly (required).
[ ] My change requires a change to the documentation.
[ ] I have updated the tests accordingly (required for a bug fix or a new feature).
[ ] I have updated the documentation accordingly.
[ ] I have ensured pytest and pytype both pass (by running  make pytest and make type).

Until we have some news (hopefully) from @hill-a , I will move current PRs to https://github.com/Stable-Baselines-Team/stable-baselines

Merged in https://github.com/Stable-Baselines-Team/stable-baselines/pull/1


Segmentation fault (core dumped) when main_inference

After installing the env successfully, run python scripts/main_inference.py  would incur Segmentation fault (core dumped). What's the possible reasons and how to solve them?

hi we never meet this issue before, but as for my experience, its probably due to the wrong version of pytorch and cuda you've installed, you can do a double check :)

Close for now, reopen if needed


Option to disable timestamp comparison

Part of how hard-source-webpack-plugin invalidates the cache is to check the timestamps of the source files.  This is all well and good on a single machine, but it prevents CI environments from being able to successfully share a build cache (barring some trickery).
Would it make more sense to store a hash of each file's contents rather than timestamps?

Thank you @alexose for opening this issue. I want this to be possible in 0.1 but I don't want to support it in 0.0.x. For this kind of thing I'm currently considering these kind of features by whether they support the single machine case or rather a developer on the machine they develop on. As well as I'd need to build enough of env-hash (the dependency doing the mentioned work) to replace it. Its not really that much but its extra surface area I don't want to do currently.
To answer your technical question, what is included in the hash is the timestamps of the directories in the given directories array, the timestamps of the package.json files in child directories, and the content of the package.json files in child directories.
Eventually for 1.0 I'm thinking env-hash would be an optional dependency that if installed is the default behaviour but plugin hooks would be available to overwrite that functionality either way to any degree a developer may need. An alternative to env-hash could also be chosen for a good default. (Ultimately any good "default" will hopefully be light on options.)

Thanks for the detailed response, @mzgoddard.  Can't argue with your logic there :)
For future developers looking for a solution, I ended up using a script (from [this[(http://stackoverflow.com/questions/1964470) discussion) to set my source's timestamps equal to git's last modified date.
This makes me slightly uneasy since I haven't done any research to know if this is a good idea.  Still, it seems to be working in our Travis environment.


[BUG] On small custom maps (5 points), some points appear more often than others, or twice in a row.

Describe the bug
I created a small custom map, made of 5 Points. But when playing, some points appear more often than others, and some twice in a row : I wouldd expect to have all the 5 points once in a game.
To Reproduce
Create custom map :

  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          -86.10796395608769,
          39.75757874775252
        ]
      },
      "properties": {}
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
<PHONE_NUMBER>7675675,
          37.56048137961429
        ]
      },
      "properties": {}
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          3.0630908873607723,
          36.785391600650165
        ]
      },
      "properties": {}
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          -0.13509788453040983,
          51.50966895098276
        ]
      },
      "properties": {}
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          7.00547185134451,
          51.44244264508981
        ]
      },
      "properties": {}
    }
  ]
}

Play.
Expected behavior
Every location displayed once in each game (5 rounds, 5 locations).
Observed behavior
Sometimes, I have the same point to guess twice in a row, or some points are never played.
Desktop : (not very relevant here I think but let's give it a go)

OS: Ubuntu & Windows
Chrome
Ubuntu 20.04, Chrome 98.0.4758.102 (Build officiel) (64 bits)

Nice ! Thx for the fix


Reinstate named=true for ranef, fixes #187

Codecov Report

Merging #188 into master will increase coverage by 0.82%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #188      +/-   ##
=========================================
+ Coverage   93.48%   94.3%   +0.82%
=========================================
  Files          18      18
  Lines        1135    1141       +6
=========================================
+ Hits         1061    1076      +15
+ Misses         74      65       -9

Impacted Files
Coverage Δ

src/gausshermite.jl
100% <ø> (ø)
:arrow_up:

src/MixedModels.jl
100% <ø> (ø)
:arrow_up:

src/linearmixedmodel.jl
91.8% <100%> (+0.51%)
:arrow_up:

src/generalizedlinearmixedmodel.jl
91.57% <0%> (+0.52%)
:arrow_up:

src/simulate.jl
100% <0%> (+19.35%)
:arrow_up:

src/mixed.jl
100% <0%> (+33.33%)
:arrow_up:

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 1a0b81c...6ef7d4d. Read the comment docs.


Update README.md

added shopybot.com case
Please review our Contribution Guidelines to ensure your changes abides by it.
Review your changes and complete the checklist below.

[ ] Company name
[ ] Company description
[ ] Company location
[ ] GitHub link
[ ] How Elixir is used
[ ] Sorted alphabetically

Thank you @alexfilatov!


Allow comments on questions and answers

Allow comments for short snippets of text in reply to both questions and answers.

@lauralorenz here it is! It's probably the exact same type of things as the voting app ... using a generic foreign key, etc. etc. We'll get it in at some point but now I have to work on other things like presentations for data day seattle ..


Add convenience methods to proxy httpmock and handle success/error

Adds handling for the following methods on $http:

.get(url, config)
.delete(url, config)
.head(url, config)
.jsonp(url, config)
.post(url, data, config)
.put(url, data, config)
.patch(url, data, config)

Adds wrapper functions to make the promise returned behave more like the one from $http:

.success(f(data))
.error(f(data))

Hi @nielssj and @ReactiveRaven sorry for the delay. This code has finally been merged. Its the new version 0.1.5. I'm still working on adding a few more examples but the code is ready to be used.

Awesome @nielssj !!


Ambassador application - Domenico D'Alterio

Email
<EMAIL_ADDRESS>Bio
Domenico D’Alterio is the IBM Principal Product Manager focused on The Linux Foundation's ZoweTM and IBM Z distribution for Zowe projects. He contributes to the open-source project strategy and direction as well as market success of IBM Z distribution for Zowe.
Prior to his current role, Domenico was the Product Manager for offerings in the IBM Z AIOps area working on the strategic directions of multiple offerings. In the previous years, he covered different managerial positions in IBM Development and Customer support organization as well as the role of Product Manager of Z Analytics products, Domenico joined IBM in 1999. Starting as designer, moved to a managerial role in 2006, acting as Development and Customer Support manager in the former Tivoli division of IBM. He graduated in Electronic Engineering, in Italy.
Projects within OMP you would want to be an ambassador for
Zowe
List any other topics you would be able to speak about
Extensions of Zowe in the System Management area.
Why do you want to be an ambassador?
I joined Zowe project at the beginning of 2022 and I think that there is agreat potential in this project.
Benefit for the users that are already leveraging the framework are incredible and I would like to help in spreading the word about the project, use cases to attract more users and contributors.
Attach a headshot

Application accepted by the TAC


Equation numbering within align environment with commands utilizing "\"

General conditions: regarding the setup:

Obsidian v1.4.16
Math Booster v2.1.3

Bug description
The logic behind the equation numbering within an align environment breaks as soon as commands are used which also utilize the double backslash \\. For instance, matrix environments break the align environment due to the \\ for new row entries.
Minimal example
\begin{align}
a = \begin{pmatrix} 1 \\2 \\ 3 \end{pmatrix}
\end{align}

Referencing this equation fails with
\begin{align} a = \begin{pmatrix} 1 \tag{4-1}\\2 \tag{4-2}\\ 3\end{pmatrix} \tag{4-3}\end{align}.

Basically, each matrix row gets a tag.

Seems that it's working now
$$
\begin{align}
a = \begin{pmatrix} \begin{bmatrix} 1\\2 \\ 3 \end{bmatrix} \\2 \\ 3 \end{pmatrix}
\end{align}
$$

Released in 2.1.4

Thank you very much!

Thanks for the detailed report. I will fix it before long.
By the way, I'm thinking about deprecating the "number line by line" setting because it's incompatible with an update I'm planning to improve equation numbering performance.
Is this feature valuable for you? If so, I'll rethink the plan.

I think it is fine to deprecate the option and make it the default behavior. The user can then just add \notag commands to the appropriate rows.  However, I am not sure about the numbering within align environments.  Debating with myself if it would be better to have just an increasing count rather than subindices as (1-1).

Thanks for sharing your thoughts.

I think it is fine to deprecate the option and make it the default behavior. The user can then just add \notag commands to the appropriate rows.

Apologies if my previous communication was unclear. I'm planning to remove the "line by line" setting. It means all we will be able to do is just assigning a single equation number to an entire $$\begin{align} ... \end{align}$$.
(Feel free to ignore if there was no confusion on your end.)

Debating with myself if it would be better to have just an increasing count rather than subindices as (1-1).

Using subindices is actually intentional. Obsidian doesn't allow linking to a specific row inside align. So incrementing the number row by row will make the equation number for the entire align environment not "well-defined."

Of course, thank you for the plugin!

Apologies if my previous communication was unclear. I'm planning to remove the "line by line" setting. It means all we will be able to do is just assigning a single equation number to an entire $$\begin{align} ... \end{align}$$.
(Feel free to ignore if there was no confusion on your end.)

Sorry for the misunderstanding. I do find it very useful to be able to assign multiple numbers within such environments. Optimization equations are one example. It's often useful to reference specific constraints to explain them further, e.g.,

where I could now go into details for the cost function and the constraints (just a random example) and reference them accordingly.

Using subindices is actually intentional. Obsidian doesn't allow linking to a specific row inside align. So incrementing the number row by row will make the equation number for the entire align environment not "well-defined."

I see, then this won't be an option.

Thanks, then I will rethink my plan!


[Feature] Add ramp-headphones format to pulseaudio module

I used to use the alsa module, and having a ramp-headphones format is great! Sometimes I start listening to music with headphones and then I take them out, without turning the music off. Having that little extra icon helps me remind I have the music on, and not be bombarded when I take the headphones out.
Since the alsa sound module already has this format, I think it would make sense for the pulseaudio format to have it as well.

Hi,
This feature was already proposed in #1071. There was some work done there but I think we got stuck at some point.
Closing in favor of #1071


C1 does not work with ultra_simple tests

Hi!
I am testing a brand new C1 Lidar.
I downloaded master branch today, compiled it in a Jetson Orin (Ubuntu 20.04) and then
sudo ./ultra_simple --channel --serial /dev/ttyUSB0
After a second, this message comes up:

Ultra simple LIDAR data grabber for SLAMTEC LIDAR.
Version: 2.1.0
Error, cannot bind to the specified serial port /dev/ttyUSB0.

Lidar does nothing at all (no noise, buzzs...). Only a green light in the serial-USB board lights up.
Any clue?

Tested in windows, with robotstudio, and lidar works. Also tested sdk in a linuxmint laptop, and does not work.

It's trying to bind to an IP and it doesn't appear that they've added support for serial ports.  custom_baudrate is the only app that works, and only if you pass it the default baud of 460800
https://github.com/Slamtec/rplidar_sdk/issues/128

I was able to get the sample apps working by applying the patch in https://github.com/Slamtec/rplidar_sdk/pull/125 and running custom_baudrate first
$ ./output/Linux/Debug/custom_baudrate /dev/ttyUSB0 460800
Baudrate negotiation demo for SLAMTEC LIDAR.
Try to establish communication to the LIDAR using the baudrate at /dev/ttyUSB0@460800 ...
The baudrate detected by the pair is 0 bps. Error: 100.000 %
Warning, actual BPS error is too large. Communication based on this baudrate may fail.
Wow, we just communicate with the LIDAR using non-standard baudrate : 460800!.
SLAMTEC LIDAR S/N: 706AE1F4C2E398C4BCEA9AF3FEB14802
Model ID: 65

Firmware Ver: 1.01
Hardware Rev: 18

$ ./output/Linux/Debug/simple_grabber --channel -s /dev/ttyUSB0 460800
Try to connect to the /dev/ttyUSB0 with the baudrate at 460800...
SLAMTEC LIDAR S/N: 706AE1F4C2E398C4BCEA9AF3FEB14802
Version:  SL_LIDAR_SDK_VERSION
Firmware Ver: 1.01
Hardware Rev: 18
Lidar health status : OK. (errorcode: 0)
waiting for data...

                                                                         **
        **   **  **************************************                  **
***************************************************************************
---------------------------------------------------------------------------


Surfacing information to users

Problem
Platform builders want to surface information to users of the platform.
Example
A platform builder may build supply chains that support a variety of underlying runtimes for web applications. For example using default k8s Deployment type or on a specialized runtime like Knative. In either case the platform builder may want to surface the URL that should be used to access the web service.  Today platform tools would have to be aware of the resources created by the supply chain and know to look in a variety of locations.  It would be useful if there was a canonical location that platform builders could look for any info they want to surface to users.
Considerations
There is ongoing work to surface information about the resources that a supply chain stamps out on the Workload status, including the "healthiness" of the resource.  This makes sense for developer users since the Workload is their interface for the system.  However in the example above the URL might more align to a runtime cluster that has a Deliverable rather than a Workload.  This would be true for other runtime information a developer might wish to know like health and number of replicas.

From my point of view, having the information readily available from the workload resource would be ideal. I.e. if you want to know the 'clickable url' for a given workload, you get the workload's yaml or json representation via k8s api or kubectl get -o json and the info should be in there (e.g. today we can find the url in the in knative service resource's 'status' field).
This just my 2 cents, feel free to ignore it completely.  (Because I don't know much about the technicallities / internals of cartographer and how you'd make something like this happen or of it is practically feasible at all. So I don't really know if this is a good idea or not.)

This might be tricky for cartographer to achieve. It only knows about resources that it stamps out, not the underlying children. This is especially tricky on the runtime cluster where all the resources typically get bundled together as a config blob, and applied through a kapp App. In this instance cartographer doesn't know anything about knative.

Arguably if it is tricky, then... all the more reason you do not want everyone looking for that piece of information to implement their own fragile implementation of solving this tricky problem. So hopefully you can come up with some way to make this a reality.

The apps cli today will query Knative Services that match a label, the URL is then read from the status of those resources. If there are no Knative Services, or those services exist on a different cluster, the URL will not be discovered by the cli.

There is no workload on the runtime cluster so no workload.status to inspect for the URL.
For env's where there is a workload, can cartographer provide the URL as part of the workload.status reliably (regardless of which runtime the workload lands on)?

There is no workload on the runtime cluster so no workload.status to inspect for the URL.
For env's where there is a workload, can cartographer provide the URL as part of the workload.status reliably (regardless of which runtime the workload lands on)?

The Deliverable is actually what's responsible for creating the resources defined by the Workload/SupplyChain. I don't think we should surface information on the Workload from the Deliverable, even when they are both defined in the same cluster. We need to decouple the Workload and Deliverable resources to have a sane multi-cluster story, while the ask is to further entangle the two resources. Users and clients should become more aware of the Deliverable.
What information to surfaced on the Deliverable status is a conversation worth having. As @jwntrs points out, this is further complicated by ClusterDelivery often delegating to a kapp-controller App to manage the individual resources.

I don't think I understand most of the technical arguments I read above.
Anyhow, the request from me is really not to push for making the information available on the workload.status. That would be convenient, sure, but any solution that allows a user or client to reliably answer the question "given workload X, what is the public URL (if any) associated with that workload" is really acceptable to me.
The point is really, that this is a high-level question that any user/tool might ask and they should be able to get the answer easily and reliably. I think that if that's not possible then that is a problem that needs to be solved somehow. Saying that it is 'too hard' isn't a very good argument for not solving it. (That just means hoisting the responsibility of solving the problem onto various other tools such as tanzu cli or vscode-tanzu tools, or... even worse, the end users themselves).
I realize answering the question reliably is hard for various technical reasons (the details of which are a bit lost on me). But I think it boils down to the fact that when someone creates a workload resource, that sets of a complex chain of causally connected events, ultimately this is intended to 'publish' a running app on a public url.
Clearly there is a causal connection / relation between the workload and the url in the user's mind. Clearly one exists only because the other one caused it indirectly. These things are not therefore not 'disconnected'.
The arguments I read above, (disclaimer: as far as I understand them :-) seem to boil down to saying:

"it is hard to propagate information backwards on this causal chain"
"we don't want to propagate information backwards because thing X and thing Y should be 'decoupled'.

I grant that it is hard, I'm sure that's true.
I also grant that this kind of 'decoupling' is desirable.
However I disagree that this decoupling means we shouldn't provide the tools to understand how they are connected.
To make the point clear. I am thinking of an analogous argument that sounds 'false' to me. Consider procedures calls in a programming language.
We do want to design interfaces/apis such that callers are 'decoupled' from the 'callee' side.
However this does not mean that we don't want to be able to get a stacktrace when something goes wrong in the 'callee'.
The ability to connect errors / stacktraces back to an 'original caller' through a long chain of calls is clearly something we do want, and it is something every programming language works hard at giving you.
Similarly when a user asks 'is there a problem with my workload' and 'which exact component / resource / cluster' does that problem originate from, should be a question our tools/users should be able to answer. If we design things in such a way that answering these questions reliably is not possible or very hard, then I think that is a problem.
As @zrob also mentions in the original ticket description. The "understand my workload's healthiness" and "what is my workload's URL" are similar questions in that both of them require understanding the structure of 'the causal chain' that connects all the 'stuff' that a workload causes to happen/exist.

related: https://github.com/vmware-tanzu/cartographer/issues/829

In either case the platform builder may want to surface the URL that should be used to access the web service

In some cases, the application may not surface a web interface, or a web interface may not be the primary way that work is submitted to the application (two examples are alternate protocols like MQTT or SMTP and pull-based queues like RabbitMQ or Kafka). Additionally, some workloads (both Knative and otherwise) may only be accessible from within the cluster, so "surfacing a URL" may not be sufficient for an end user to interact with the application.
As a simple example, consider an application which is deployed as a GRPC+HTTP (i.e. "web") application as a cluster-internal service using a Deployment + a K8s Service of type: ClusterIP. In order to access the web interface of this application, it's necessary for the user to run kubectl port-forward or run a container on the application's cluster to be able to reach the application. As a simple example, the goldilocks tool uses this to require k8s credentials to be able to see the cluster sizing recommendations: https://goldilocks.docs.fairwinds.com/installation/#viewing-the-dashboard
A second example is that a service may only be accessible at an external URL by combining a resource which already exists on the cluster with the delivered application. An example of this would be creating a Kubernetes Ingress on the cluster which references a Service delivered through a cartographer Workload. The URL would be determined by the Ingress, which might look like the following:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  rules:
  - host: example.com  # This might be different per-cluster
    http:
      paths:
      - path: /app  # Endpoint for my-app would be http://example.com/app
        pathType: Prefix
        backend:
          service:
            name: my-app
            port:
              number: 80

In some cases, the application may not surface a web interface, or a web interface may not be the primary way that work is submitted to the application

Those are valid points, but I think that merely means that it doesn't make sense for all workloads to advertise a URL on which they can be reached. There are however still many workloads for which it does make sense and it is for those workloads that we want to be able to obtain the url relatively easily (e.g. by reading 'status.url'). (And for those workloads for which the concept of 'url on which you can be reached' doesn't make sense... then that could be indicated setting 'status.url" field to some value like 'false' or 'nil' or nil something like that.