Proposal for JSDoc comment support to inform a better JavaScript editing experience.

Pull Request here: https://github.com/Microsoft/TypeScript/pull/2646
Problem
Providing a good JavaScript editing experience in a cross-platform/cross-editor manner is challenging.  JavaScript is a highly dynamic language, and users may write code in a manner that our default TypeScript language rules don't provide a good experience for.
For example, a user may write the following:
var val = "some_value";
if (someExpr()) {
     val = somethingThatReturnsNumber();
}
val     // <-- completion here.

TypeScript's view of this variable is that it is a string (due to its initializer).  Leading to an IDE experience like so:

(notice the lack of number properties)
The solution to this in TypeScript code is easy, just write your code as:
var val: number|string = "some_value";
if (someExpr()) {
     val = somethingThatReturnsNumber();
}
val.     // <-- completion here.

Of course, then you're not typing JavaScript anymore, defeating the purpose of providing a good JavaScript editing experience. :-)
Proposed Solution
There is, fortunately, an approach already taken by the JavaScript community to help out here.  JSDoc comments support a number of mechanisms to allow declaring valuable information about their declarations.  As part of our work to better support editing JavaScript using the TypeScript compiler, we can inform the typing experience based on these JSDoc comments.  These comments already appear to be widely used in the JavaScript community, and there is ample tooling support for them already in many other tools.
Here's an example of how we can improve our editing scenario if we take advantage of these annotations:
/** @type {number|string} */
var val = "some_value";
if (someExpr()) {
     val = somethingThatReturnsNumber();
}
val.     // <-- completion here.

If we allow these JSDoc type annotations to inform the compiler's type-system in JavaScript files, then we can see a very nice set of functionality light up immediately like so:

![image](https://cloud.githubusercontent.com/assets/4564579/7328499/efa7df82-ea8a-11e4-8eee-6cfcce1c03ee.png)

(notice both the string and number properties listed).
I've gone ahead and added support for a subset of JSDoc annotations that make sense in our compiler's existing system.  This is an initial starting point for JSDoc support, and I am performing continued investigations to see what other sort of JSDoc concepts are used commonly, and what we may be able to cheaply provide support for.  Current support has been added for a wide variety of types that we see in JSDoc types including:

Normal primitive types.  i.e.: number, string, etc.
Type references.  i.e.: ArrayBuffer.  When these are to types already in some .d.ts files, this is naturally understood by the compiler.
Generic types. i.e. Array<number>.
The * type.  This is the all type for JSDoc, and maps to our any type.
The ? type.  This maps to the unknown type.
The union type.  i.e.  number|string.
The nullable type.  i.e. number? or ?number.  There is no direct representation for this in our compiler, so we map this simply to the underlying element type (in this case number).
The non-nullable type.  i.e. number! or !number.  There is no direct representation for this in our compiler, so we map this simply to the underlying element type (in this case number).
The record type. i.e. { a: number, b: string }

Additionally, based on how we've seen JSDoc used in practice on GitHub, we also support some common types like

The array type.  i.e. number[]
The tuple type.  i.e. [number,string]

On top of the types that we understand and can map to our existing TypeScript compiler types, we also understand function, param and return annotations.  For example, a variable with an annotation of the form:
/** @type {function(new:ArrayBuffer,number)} */
var createBuffer;

Is understood to have a normal TypeScript construct signature of:

Within function or param annotations we support

The new-type annotation.  i.e. function(new:ArrayBuffer,number).  This represents a construct signature.
The this-type annotation.  i.e. function(this:ArrayBuffer,string).  The this annotation indicates the type that this has within the body of the function.  Interestingly enough, there is no TypeScript way to do the same thing (something we might want to reconsider).
The reset annotation.  i.e. function(...number).  This naturally maps to our own ... - rest parameter concept.
The optional annotation.  i.e. function(number=).  This naturally maps to our ? - optional parameter concept.
The Template annotations.  i.e. @template T.  These naturally map to our own Type-Parameters.

Here are examples of a few of these interesting cases:

Implementation
Adding support for this was fairly simple and fit nicely within our existing compiler with very little effort.  The work was broken down into the following pieces:

Parsing.  This was fairly simple.  I added parsing functionality to support handling JSDoc comments.  And, when parsing a JavaScript (.js) file, we simply look for and parse out these constructs on declarations they make sense for (currently, functions and variables).
Binding.  When the binder is binding a JavaScript file, we look for these JSDoc comments and handle certain parts of them appropriately.  This includes handling @template annotations and appropriately adding their Type-Parameters to the parent function.  Handling record types ({ ... } ) in a similar manner to how we handle TypeScript Object-Type-Literals.  And handling function types function(type1, etc.) in a similar manner to how we handle TypeScript call/construct signatures.
Checking.  In certain targeted locations, we provide specialized code-paths if we are in a JavaScript file.  For example, when asking 'what is the return type of this function?' (i.e. getReturnTypeFromBody), we check if this is a JavaScript node, and if it has an @return annotation.  If so, we defer to that as the canonical source of truth about this function's return type.  After all, if this user declared it as such, then we should respect that declaration.  If no such annotation can be found, we fall back to our normal inference model.  The places touched in the checker are fairly minimal and reuse existing compiler functionality as much as possible.
Emitting.  No work was done here.  There is no concept of 'emit' for a JavaScript file.  It's already in its final form.

The work was done in the core compiler itself as it is the most natural place for this understanding.  By doing the understanding at the compiler layer, all IDE features naturally light-up, with no additional effort.  If this work was done at the Services layer it would require an enormous amount of effort.  To understand this, let's work with a simple example:

If the Services layer wanted to handle this properly, it would not be sufficient to merely understand the types of x and y.  It would also have to understand how those types flowed and changed through arbitrary expression.  This is a somewhat simple case here but would already require the Services layer to implement understanding of binary expressions.  This immediately spirals into too much complexity the moment we would need to understand the gamut of other cases supported in the compiler (like overload resolution, contextual types, generics, etc.)
Feedback is welcome on the current design and implementation.  I will be spending the immediate present doing more investigations into how JSDoc is used in the wild to better flesh things out from here.
Thanks!

looks good!

The current plan is that this should only effect the editing experience in JavaScript files. We should consider whether we want this to work in TypeScript files as well. A couple reasons:

As noted, the JSDoc experience actually adds features that TypeScript doesn't currently support, namely 'this' typing which is a much requested feature.(https://github.com/Microsoft/TypeScript/issues/513).
For users migrating from JavaScript to TypeScript it would be unfortunate if after renaming their files to .ts suddenly their editing experience degrades as the significant effort they put into JSDoc comments is no longer leveraged by the editor. In an ideal world we could simply promote their JSDoc comments to real type annotations via an IDE command.

This does create additional complications where there are now 2 type annotations for a given element that we would want to verify and keep in sync. It's probably not an option to delete the JSDoc comments since there're plenty of good reasons to have some later portion in your pipeline still use JSDoc comments even after the TypeScript compiler is done with your file(s).

@danquirk: Regarding the second point, if the user wants to have JSDoc annotations in their code, then perhaps a solution would be to

support converting JSDoc comments to TypeScript type annotations, and
Add facilities for emitting type information in the form of JSDoc comments.

Then the programmer needs maintain only one copy of the annotations in the form of TS files.
There remains the outstanding question of whether we might be emitting too much type information, rendering the output file bloated for the remaining tools in the pipeline.

@aozgaa great minds ;) https://github.com/Microsoft/TypeScript/issues/2916


error when login

Hello,
I have installed your launcher using dmg file on release, but the login doesn´t work. I enter my ID , password without otp, with save login. When I click next, i got this error message although the usual launcher work. Can you fix it?
Thank You

Can you try again with v0.3.3?

Can you try again with v0.3.3?

Same thing happens on 0.3.3


Upload winter 2022-23 Greenland lakes data as xapres object

Currently the raw DAT files are stored on the bucket, within ldeo-glaciology/GL_apres_2022. It is therefore mixed in with the existing data.
My plan is to first do a test upload with just a few DAT files as a new xapres object, and see if it is functional with the old data structure, i.e. if I can properly append. Another option is to re-process the entire folder. Some roadblocks that I anticipate include the different attenuation settings used by the different deployment periods in addition to A104 facing recording issues in February .

@jkingslake I wanted to make sure I'm using the right functions to first upload the individual zarrs. I will be testing this by only uploading one of the subfolders within the Card A folder. From what I can tell, the function you used to upload the previous individual zarrs was xapres_to_zarr_chunked in the to_individual_zarr notebook. Outside of the explicit chunk definition, this function also uses tqdm_slack rather than just tqdm compared to xapres_to_zarr. Could you clarify this difference?
On a separate note, I think I will need to delete and reupload the winter data to a new directory that is outside the Card A directory if we want to use the same functions as before to create zarrs for just the winter data. Do you have experience moving entire folders within google bucket? It seems quite different from moving individual objects.

After some playing around it seems like the tqdm_slack thing doesn't matter. I will move forward and make all the individual zarrs in a separate folder. I think it makes sense to have separate datasets for each deployment because of our already discussed changes in attenuation settings. Furthermore, any changes to sled structure/repositioning the sled may lead to discontinuities in data.

#26 indicates this task is done.


Support more filenames

A lot of projects have a e.g. a directory per shader, which contains vert.glsl and frag.glsl files.
Similarly, a lot of people use *.vsh, *.gsh, and *.fsh as file extensions.
It's annoying that there isn't a standard on extensions on shaders 😄
I'm not an expert in C++ so I don't know if there's a better way to do this, but I replaced directly checking for extension equality with an ends_with function (a little surprised C++ doesn't seem to have such a function in the standard library - if there's something better I should use for this, do tell me!)

Looks good! Thanks!


Adding cassandra test-server image

@mml
This is required for kubernetes/kubernetes#47200.

I am trying to understand whether this code should be in this repository. I read the discussion on https://github.com/kubernetes/kubernetes/pull/47200. If the code added is purely used for testing Kubernetes, then it probably should live in the main repository. We expect that examples hosted in this repo are stuff users will run to play with Kubernetes. They would just come and explore the examples by clicking around. /cc @sebgoa please chime in.
That said, if we decide to shoehorn this stuff into this repository, a few comments:

move everything related to testing under cassandra/test-image

move {vendor/,Godeps/} there, these don't have to be on repo root
add a README.md explaining what this test-image directory is for

I'll go ahead and close this per offline discussions. A test-images repo or something similar would be the better place to host this.


langchain4j-chatglm get rid of lombok

Issue

Closes #1636
Change

langchain4j-chatglm get rid of lombok
add logRequestsAndResponses parameter.

General checklist

[x] There are no breaking changes
[ ] I have added unit and integration tests for my change
[x] I have manually run all the unit and integration tests in the module I have added/changed, and they are all green
[x] I have manually run all the unit and integration tests in the core and main modules, and they are all green

[ ] I have added/updated the documentation
[ ] I have added an example in the examples repo (only for "big" features)
[ ] I have added/updated Spring Boot starter(s) (if applicable)

@Martin7-1 there are conflicts, could you please check? Seems Ollama changes somehow got into this branch


[PE-13] Allow only single-quote strings unless they involve substitution

Inspired by a PR conversation
No functional changes
Reference info on the rule details: https://eslint.org/docs/latest/rules/quotes

@kyuksel was this done through some utility/automatic correction? Wondering how carefully I should review.
Also, what problem does using `` in strings that don't involve substitution introduce?

I personally prefer single-quote. Also, single-quote rule is enforced in AoU and DDP projects.


Add a lenient mode to QueryParser

The role of the QueryParser is to give an off-the-shelf solution to people wanting to deliver a search box to end user.
Currently QueryParser::parse can return an error if the query does not match our query grammar.
e.g.: +(happy  : the parenthesis is not closed.
This is great, but how should somebody writing a site handle this error?
Maybe for a log analysis search engine, displaying an explicit syntax error is a good idea, but for most use case, (ecommerce, document search, etc.) we want to never return an error and just do our best to handle the user query.
For this reason, we want to add a new parse_lenient that would never fail and always return a result.
pub fn parse_query_lenient(&self, query: &str) -> Box<Query> {
    // ...
}

The behavior of this lenient mode does NOT have to be very smart...
For instance, it could be a second very naive parser taking over when the initial parser failed.
For instance, this naive parser could remove all special characters and run the initial parser.
Smarter attempts to interpret the faulty user query are also welcome, as long as we return Box<Query> and we are confident the code will never panic.

Not really a bug... but well.

Requires #57

If you can give me some more specs I'd be willing to take a look at this. I like things that are about making it better for the user

Improved the description. The ticket voluntarily does not give much implementation details.

What's the status of this?
I see the opened PR has recently been closed, seemingly without result?
I'm currently working on a web application, which exposes search functionality to non-technical users, and I was hoping I could let them try their hands into using advanced queries, with some sort of fallback in case they fail. This would be just what the doctor ordered.
If #382 has merely stalled, and not dropped due to fundamental problems, I can put in the hours to get it over the finish line.

Any news on this? It's problematic we still don't have a lenient mode when exposing the search feature to non-technical users...

If someone wants to pick this feature it is up for grabs.

Reassigning to @trinity-1686a


Node shutdown not implemented sufficiently

I saw in https://github.com/metal-stack/metal-ccm/pull/71 that we implemented machine shutdown like:
// InstanceShutdown returns true if the instance is shutdown according to the cloud provider.
// Use the node.name or node.spec.providerID field to find the node in the cloud provider.
func (i *InstancesController) InstanceShutdown(ctx context.Context, node *v1.Node) (bool, error) {
	klog.Infof("InstanceShutdown: node %q", node.GetName())
	machine, err := i.MetalService.GetMachineFromProviderID(ctx, node.Spec.ProviderID)
	if err != nil || machine.Allocation == nil {
		return true, err
	}
	return false, nil
}

We can really tell if a machine is shut down through the machine IPMI information now, so we could adjust that information.

I am not sure if this is better, from the kubernetes perspective a machine without a allocation is not usable anymore. If it is powered down it might come back ??


added geoadd and georadius features

I have added beta features of geoadd and georadius available with redis 3.2

Coverage decreased (-0.4%) to 92.12% when pulling 092eae306554cd49ff6b92793750d967f5eb7b6e on arpitsr:master into f1c1101a87ebe858f7bcd6b4222e4698c06524df on etaty:master.

Hi, could you write some tests?

Hi guys, thanks for the great project .
@etaty when this PR will be merged and closed ?
@arpitsr do you plan to add other GEO methods (e.g :
GEODIST,
GEOHASH,
GEOPOS,
GEORADIUSBYMEMBER) ? if not pls LMK and I will add them .

@123avi I can't merge it without tests ;)
feel free to open a new PR (with test) and I will merge and publish a new release

@etaty  , OK, I will add that functionality,  which branch should I base from ? tests are not running properly. some are falling due to java.io.IOException: Cannot run program "/usr/local/bin/redis-trib.rb": error=2, No such file or directory some for other exceptions (using master branch, also I have redis server running on docker ) . please advise

Merged GEO with PR #164


The raw response is not working after the last update

          Hi @DevYSM , update to the [latest release](https://github.com/pdphilip/laravel-elasticsearch/releases/tag/v4.0.4) and try the rawAggregation now. The update fixed the issue where only 1 agg result was being returned.

However, given the complexity of your query it may not return all the data you need. If that's the case then this update also has an upgrade on rawSearch() where you can add your body with a second parameter set to true to return the full unsanitized result. This will give you what you need, ex:
YourModel::rawSearch($body,true)

Good luck!
Originally posted by @pdphilip in https://github.com/pdphilip/laravel-elasticsearch/issues/35#issuecomment-2294989971

Hi, v4.3.0 introduced a breaking change for rawSearch, see  Release 4.3.0

Breaking Change
rawSearch($bodyParams, $returnRaw = false) has now been split into rawSearch($bodyParams) and rawDsl($bodyParams) where:

rawSearch($bodyParams) returns an ElasticCollection of results
rawDsl($bodyParams) returns the result body as is from Elasticsearch. Equivalent to $returnRaw = true previously.

We cannot bump breaking changes to the next major versions (ex 5) since the major version is committed to the compatible Laravel version, but there should not be any more with 4.x. These changes are as a result of a package overhaul, sorry about that.


Training parameter is always default (True) in DCGAN lesson

Up until now we've seen that, when using tf.layers.batch_normalization, we set it's second parameter to True or False depending on whether we are training or not. However, I noticed that in the DCGAN class this parameter is always True since we are not passing any specific value when running the session (so it keeps the default value specified in the method definition). Is there any reason for this or is this an issue?

I haven't looked at this notebook, but it doesn't seem to do batch normalization correctly. The way it's written now it requires training to be True because it never updates the population statistics. But I need to run through this today to see if that was intentional.

So I tried setting batch norm's training=False in the training process, but the generator wouldn't actually generate good images. From the documentation, it says setting training=False takes a moving average of the batches. This makes sense when you're just doing inference. But when you're training, the weights are changing between batches so the moving average gets messed up. I believe you want to keep training=True when generating images during training, but set training=False after training.
At least, this is what I found when developing the DCGAN model.

First, you should be on vacation. :|
Second, I think the real problem is in the generator. It should set training to False when it's not training, like when we show the sample images. I think the discriminator in our examples is only ever used during training, so it doesn't matter that it's always set to True, but if you want to use the discriminator for something later, like a classifier, then you'd need to set it to False there, too.
And just to clarify, setting training to True calculates the moving averages, and setting it to False uses the averages it calculated during training. You want the network to learn good population statistics during training so it can use them later.
I'll be making changes to the notebook tomorrow because there are still errors in how the batch normalization is implemented, even if it doesn't seem to change the results in this notebook. Students are using this as a template for project 5, and the code as shown here does not work properly there.

Ok, explained why it's ok to use training True for the discriminator in this project, and changed so the generator sets training to False when sampling.


feat: revamp the design of newsletter section ⚒✨

Description

The current look of newsletter section have many number issues in terms of alignment and spacing.
We need to revamp them into fully fledged Newsletter component without any issues.

Screenshot (Current State)

Hey there @SurajPratap10 👋🏻
Please make sure to assign this issue to me to make the work done, Thank you!


Overwriteablehandler: OverwriteableAttribute

Hi,
I Created an opportunity to overwrite handlers. You are probably thinking, in what scenario will you ever do this?
Well let me explain.
I have packages that are developed that i want to use all over my software. There i use MediatR to call my EFCore handling. Now i have scenario's where i do not want to keep all of my entities, some i want to expand with more details because that's related only to that software. But my basic package will still do the same calls that i did before but these calls should not handle Entity, they should handle ExtendedEntity. So i needed a new handler.
Now for this scenario, i created handlers based on the interface of my Entity and not based on the Entity himself, else what i am telling before will not work. So i have for example an IRequest<IPong> named OverwriteablePingRequest.
In the normal way without changing the current DbContext with extended entities it will just call OverwriteablePingRequestHandler.
When i extend the entity Pong with ExtendPong i also become and ExtendedDbContext so i want to call OverwrittenPingRequestHandler with the same OverwriteablePingRequest.
With MediatR you can load multiple assemblies where it will register all your handlers with your requests, but what comes first will be used first.
So you could just replace every service in your ServiceCollection with the handlers that should be overwritten, true, but what if you have more then 1000Handlers that should be overwritten? So why are we here? To make this happen automatically.
In this pull request you only see the Attribute that i created to make you say which Handler can be overwritten. If you add this OverwriteableAttribute and it finds a second Handler that suits your Request it will overwrite the Handler with the OverwriteableAttribute.
I need this pull-request to be accepted if you want to build and test run the changes in MediatR.DI.
I also have a couple of questions:

Does the naming suits you? If not could you just modify it to a proper naming that suits you instead of denying my pull-request please? Because i could use this as quickly as possible.
Do you approve to let it work this way with the attribute or do you have other suggestions?

I you have questions for me, just ask.
Thanks.

@Condra963 Why does this belong in MediatR? You don't have anything in MediatR using this Attribute.  It seems this attribute is more suited to exist in your own project.

@lilasquared can you please read the complete explenation? Because i need it in MediatR.DI. But an Attribute should not be defined in MediatR.DI, it does not belong there.

@Condra963 why wouldn't the attribute just exist in that project then?

what is your reason for "it should not be defined in MediatR.DI"?

Hi
It is because an Attribute does not require other dependencies, so it should be in the core project.
Also because if you want to create a base handler like OverwriteableRequestHandler like you have AsyncRequestHandler it is also required in this assembly to prevent loop references.
And it is also needed when you create an alternative for MediatR.DI where you also want to use the same attribute.
Actually if i understand it correctly, this attribute should be here by design.
I hope my explanation is what you need to approve this?

I can't approve this at all I'm just asking questions.  Are you particularly blocked in your solution because this is not a feature of MediatR or have you solved it for your use case?

Yes what it does is very clear, but why it should be part of this project and the DI project is not clear to me.  It appears to me to be a very specific architecture that your software has.  I am not sure if the project benefits much from having this overriding logic.  Just my two cents though as I am not the project maintainer.

Let me explain again in another situation.
You use a package of nuget in your software, that one is using MediatR en does some handling. But you want to perform some other actions when one of these handlers is called, you can overwrite this handler and add extra stuff to it.
I really do not understand why you are being so difficult about this, being able to write a handler that is called from code that you are not able to modify yourself is useful in multiple scenarios.

Why can't you use pipeline behaviors?
On Wed, Oct 17, 2018 at 2:39 PM Condra963<EMAIL_ADDRESS>wrote:

Let me explain again in another situation.
You use a package of nuget in your software, that one is using MediatR en
does some handling. But you want to perform some other actions when one of
these handlers is called, you can overwrite this handler and add extra
stuff to it.
I really do not understand why you are being so difficult about this,
being able to write a handler that is called from code that you are not
able to modify yourself is useful in multiple scenarios.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/pull/320#issuecomment-430761349, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGYMlDUFKKybd1f2NmqplWFYFfozBe5ks5ul4ePgaJpZM4XkPZt
.

How would pipeline behavior work to overwrite an existing handler that is already been written?

Pipeline behaviors fire before the handler, so you can skip the handler processing altogether.  The issue of registering thousands of them would still be a problem, especially registering them at the right point so they don't skip any other pipeline behaviors that may be in place.

Because you decide whether or not to call "next" in a pipeline behavior:
public class OverridingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse> {
    public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next) {
        await Logger.InfoAsync($"Handling {typeof(TRequest).Name}");
        TResponse response;
        if (MyApp.Reasons)
            { response = await next(); }
        await Logger.InfoAsync($"Handled {typeof(TResponse).Name}");
        return response;
    }
}

But the handler already exists in the package that i depend on and it will be registered no matter what i do, these handlers will be registered by default. So if i call my request it will call a pipeline and that will just call the handler that is defined by the package and then i can choose if i want to call mine as well if i understand correctly? But i want to replace the handler of the package, i only want my handler to be called. What about that?

You can also replace their handler in the DI configuration. The ServiceCollection is mutable, so you can find their registered instances, remove them, then add your own.

@Condra963 instead of having a OverwrittenHandler, the work for that would be in the pipeline behavior in your project.
You would skip calling next() at all.  next() is where the original handler would be called.

Yes i know, and that is what i tell in my current explanation that i know that you can do this, but with my solution i just need to define my assembly and it will be defined correctly without all that extra work. I do not need pipelinebehavior what in my opinion is to do call after call after call after call instead of overwriting something. And it's also extra unnecessary work because like i say my solution just pick the handler you want and register in into the dependencyinjection container.
And than i'm still wondering, are you sure with pipelinebehavior will catch my scenario? Because the request i call is one and the same, it only goes to another handler. You will still have the same problem and that is i cannot choose which handler i want to register to my container that the current request should call.

And i am looking for a solution that if i just derive from that current handler that it will take the handler that derives from the current handler. In that scenario you do not need the attribute, but the Handle method should be a virtual. I don't know what you prefer?

Why can't you override the container configuration? What container are you using?

@jbogard the actual change is in https://github.com/jbogard/MediatR.Extensions.Microsoft.DependencyInjection/pull/46

Ah OK. But ServiceCollection already lets you do Replace, so you can already replace handlers.

I do not say that i cannot override the container, i say it is not necessary with my solution. In a scenario where you want to do this for 1000Handlers i only have 1 line code and else i will have 1000. So my choice was made fast. I really do not understand why you are being so difficult about this. I take care of the fact that you shouldn't replace every service in you container. It looks before registering which one it wants to use. Instead of people everytime in every project that they want to overwrite a handler need to do servicecollection.ReplaceService (x1000 times) it is already taken care of in MediatR. Why shouldn't this be useful at all? And if you 1000 project where you have 1000handlers that you want to overwrite you have 1 000 000 handlers to overwrite and 1 000 000 lines to write that can be easily just take care of in MediatR.DI. I really do not get it that you people do not see the use of it.

Well, I've never needed to do this, and since I write my OSS for my projects/clients first, I have quite a high bar for features I'd never use, especially if adding a feature only to support a particular way of registering.
There could be a simpler solution here. Right now when you pass in assemblies, the DI project doesn't do any checking to see if there are already handlers registered. One solution would be "if there's already a handler defined, overwrite it". We now have a config object, so it's be pretty easy to turn this kind of behavior off/on.

Also, I assume that whether there are 1 or 1000000 handlers to override, you would have the same amount of code to apply your override rules. Just like the DI package scans assemblies for types you could do the same.

Having an attribute in MediatR core project without any code using it, is unnecessary. It would be logical if MediatR was split up in two projects, MediatR/MediatR.Abstractions. But even then, it will be unused code.
I think the better solution would be to create a separate packages for this, like 'MediatR.OverwritableHandler.DI / MediatR.OverwritableHandler'. Where in one the attribute will live, in the other the code to link it to a DI container.

Package that i use

OverwritableHandler1 : IRequestHandler<Request1, IResult1>
OverwritableHandler2 : IRequestHandler<Request2, IResult2>
OverwritableHandler3 : IRequestHandler<Request3, IResult3>

My software

OverwrittenHandler1 : IRequestHandler<Request1, IResult1>
OverwrittenHandler2 : IRequestHandler<Request2, IResult2>
OverwrittenHandler3 : IRequestHandler<Request3, IResult3>

When two handlers are registered with the same ServiceType (interface) and Request1 is called, the handler that is resolved (the base one, or the overwritten one) is undefined. What I want is that, by design, the most derived handler is called (or only the most derived is registered in the first place).
So for example in my software, At the moment I have to replace all handlers manually like this:

serviceCollection.Replace(new ServiceDescriptor(typeof(IRequestHandler<Request1, IResult1>), typeof(OverwrittenHandler1), ServiceLifeTime.Transient)
serviceCollection.Replace(new ServiceDescriptor(typeof(IRequestHandler<Request2, IResult2>), typeof(OverwrittenHandler2), ServiceLifeTime.Transient)
serviceCollection.Replace(new ServiceDescriptor(typeof(IRequestHandler<Request3, IResult3>), typeof(OverwrittenHandler3), ServiceLifeTime.Transient)

My suggested change does this automatically, saving complexity, time, and lines of code.
Maybe the attribute is not necessary and it could be handled like this:
My software

OverwrittenHandler1 : OverwritableHandler1
OverwrittenHandler2 : OverwritableHandler1
OverwrittenHandler3 : OverwritableHandler1

When a handler that is derived from another handler is being registered, the base handler should be replaced (or not be added in the first place). So in the end only the most derived handlers are registered.

I believe this is a useful feature, however, I am not sure if using an attribute is the best way to do it. I am also unsure if this is only a useful feature in Mediatr or if it could also benefit ServiceCollection, since the registering of multiple same ServiceTypes (interfaces) and the resolving of them is the responsibility of ServiceCollection.

Your way of registering could be greatly simplified.
On Thu, Oct 18, 2018 at 3:20 AM Condra963<EMAIL_ADDRESS>wrote:

Package that i use

OverwritableHandler1 : IRequestHandler<Request1, IResult1>
OverwritableHandler2 : IRequestHandler<Request2, IResult2>
OverwritableHandler3 : IRequestHandler<Request3, IResult3>

My software

OverwrittenHandler1 : IRequestHandler<Request1, IResult1>
OverwrittenHandler2 : IRequestHandler<Request2, IResult2>
OverwrittenHandler3 : IRequestHandler<Request3, IResult3>

When two handlers are registered with the same ServiceType (interface) and
Request1 is called, the handler that is resolved (the base one, or the
overwritten one) is undefined. What I want is that, by design, the most
derived handler is called (or only the most derived is registered in the
first place).
So for example in my software, At the moment I have to replace all
handlers manually like this:

serviceCollection.Replace(new
ServiceDescriptor(typeof(IRequestHandler<Request1, IResult1>),
typeof(OverwrittenHandler1), ServiceLifeTime.Transient)
serviceCollection.Replace(new
ServiceDescriptor(typeof(IRequestHandler<Request2, IResult2>),
typeof(OverwrittenHandler2), ServiceLifeTime.Transient)
serviceCollection.Replace(new
ServiceDescriptor(typeof(IRequestHandler<Request3, IResult3>),
typeof(OverwrittenHandler3), ServiceLifeTime.Transient)

My suggested change does this automatically, saving complexity, time, and
lines of code.
Maybe the attribute is not necessary and it could be handled like this:
My software

OverwrittenHandler1 : OverwritableHandler1
OverwrittenHandler2 : OverwritableHandler1
OverwrittenHandler3 : OverwritableHandler1

When a handler that is derived from another handler is being registered,
the base handler should be replaced (or not be added in the first place).
So in the end only the most derived handlers are registered.
I believe this is a useful feature, however, I am not sure if using an
attribute is the best way to do it. I am also unsure if this is only a
useful feature in Mediatr or if it could also benefit ServiceCollection,
since the registering of multiple same ServiceTypes (interfaces) and the
resolving of them is the responsibility of ServiceCollection.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/pull/320#issuecomment-430918995, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGYMudhoqHmSA-5V6pKzBYk12bhLzPRks5umDnMgaJpZM4XkPZt
.

Could you tell me how you simplify this? Because everything is registered through MediatR except the Handlers that wants to overwrite the basehandlers.

Use reflection just like I do in the DI package to scan for handlers in your assembly and register them.
Is the problem that the DI package doesn't allow you to override handlers? If so it's a small change to that library to allow that to be configurable in some way besides an attribute.

Yes, I know you can use reflection, but why should I write reflection for something that already exists and can be simply modified once? Now I need to copy this to every project over and over again or build some package between while the solution I suggest is a solution for everyone without any extra work.
The only thing I suggest is adding a non-breaking and simple change that takes care of registering the deriving handlers with the exact same interfacetype only once so that I don't have to deal with it in every project in the future. Because at this moment it's like a bug that you can register 2 times the same IRequestHandler<Request1, IRespond1> for example. Isn't?
I can throw the attribute away if you want like I said before. Then I will make a fix in MediatR.DI that looks for deriving handlers. But I need to know if you are considering to accept this pull request if I modify it, if not I will look for another solution for this.
Thanks.

No, I don't think the fix is in this library, it's how the DI package registers handlers. It's not a bug either - you're registering a handler twice. It's unsupported behavior.
I do agree that the behavior to allow some choice in handlers would work, but that's for the DI project. Can you create an issue, something like "Allow user to select/configure which handler to use for duplicate handlers"?

Ok, then i remove this attribute from this package and continue my work in MediatR.DI but big change i already made is in MediatR.DI, here is just the attribute and i did my explenation here about both pull-requests because else you would be thinking "why does someone add some attribute in here?".
But let us move the discussion to MediatR.DI where i will link my original pull-request in MediatR.DI of how we could implement this? And if we figure out what the best way to implement this is, i can modify my pull-request.
Just a little explanation why i see this more as a bug than unsupported behavior:
Registering 2 times the same interface in your servicecollection will shoot out the first it finds, so when registering 2 times the same IRequestHandler<Request1, IRespond1> servicecollection should already throw an exception because it makes the injection unreliable. It's like you have identical twins, they look the same but they don't answer the same if you ask them something so if it's called by DependencyInjection you have 50% change the right twin will answer your question with the answer you expect. But this would be more something that should be discussed in ServiceCollection behavior.
But whatever, discussion will be moved to: jbogard/MediatR.Extensions.Microsoft.DependencyInjection#47


Implements delete cluster and toolbox dumper command

This PR implements delete cluster and toolbox dump command for kops.
Fixes #14

After deleting cluster A, the state store of cluster A should be deleted too.
Just wondering if the state store clean should be another PR?

@luomiao the cluster state and kubeconfig gets deleted. So we don't need separate PR

LGTM.


bumping minimum version

Testing out a minimum version bump. 5.6 is erroring out because of dependencies.

Current coverage is 19.166% (diff: 100%)

Merging #103 into master will not change coverage

@@             master       #103   diff @@
==========================================
  Files            18         18
  Lines           720        720
  Methods         104        104
  Messages          0          0
  Branches          0          0
==========================================
  Hits            138        138
  Misses          582        582
  Partials          0          0

Powered by Codecov. Last update 087e2c2...6fdbd4c


[Feature #786] Introduce Scalafmt to auto format scala code

Purpose of this pull request
closes #786
Introduce Scalafmt to auto format scala code
Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] Change does not need document change, or I will submit document change to https://github.com/InterestingLab/seatunnel-docs later

cc @zhongjiajie @CalvinKirs

cc @zhongjiajie @CalvinKirs

please check CI fail

we already working on convert scala to java, https://github.com/InterestingLab/seatunnel/issues/766

we already working on convert scala to java, #766

Module plugin-spark-* still developed on scala, maybe we can remove it after all scala has been converted to java?

It seems better for plug-in modules to not restrict the language, WDYT? @timothy1024 @simon824

It seems better for plug-in modules to not restrict the language, WDYT? @timothy1024 @simon824

There are still many prs using scala now, I think the language can be unrestricted in the early stage, and maybe unified convert them later.

hi @simon824, I think these format codes are very good, but still think we should introduce scalafmt.

It seems better for plug-in modules to not restrict the language, WDYT? @timothy1024 @simon824

I agree with that, some developers maybe love scala better than java

hi @simon824, I think these format codes are very good, but still think we should not introduce scalafmt.

Do you have another way to format our code? And why not scalafmt? So sorry about that cause I am not familiar with scala

hi, we had discussed about scala or java in wechat, and already decided to remove scala.

hi, we had discussed about scala or java in wechat, and already decided to remove scala.

This is not an open process (WeChat), we should at least reflect it in the issue or mail list.

This is not an open process (WeChat), we should at least reflect it in the issue or mail list.

ok, I think we should use mail list / slack later, and should not use wechat group. wechat is not friendly for open source.

back to this question, I think we can introduce scala-format, uniform code format and style are important.

back to this question, I think we can introduce scala-format, uniform code format and style are important.

Agree with that, I think unless we totally remove scala or just in plugin scope, otherwise keep code in format is a good idea.

Agree with that, I think unless we totally remove scala or just in plugin scope, otherwise keep code in format is a good idea.

+1

Agree with that, I think unless we totally remove scala or just in plugin scope, otherwise keep code in format is a good idea.

+1, sounds resonable, thanks.


lib.lists.{commonPrefix,commonPrefixLength}: init

Description of changes
Adds two new functions:

lib.lists.commonPrefixLength :: [ a ] -> [ a ] -> int: The length of the common prefix of two lists:lib.lists.commonPrefixLength [ 1 2 3 4 ] [ 1 2 4 8 ]
-> 2

lib.lists.commonPrefix :: [ a ] -> [ a ] -> [ a ]: The common prefix of two lists:lib.lists.commonPrefix [ 1 2 3 4 ] [ 1 2 4 8 ]
-> [ 1 2 ]

This is distantly part of the path library effort, in order to be able to work with lists of path components. Relates to https://github.com/NixOS/nixpkgs/pull/243511
This work is sponsored by Antithesis :sparkles:
Things done

[x] Docs
[x] Tests

Just brainstorming here: what do you think about extracting out findFirst into findFirstIndex and reusing that here? Pseudocode being:
commonPrefixLength list1 list2 =
    let pairs = zipLists list 1 list2
    let firstDiffIndex = findFirstIndex ({ fst, snd }: fst != snd) pairs
    if firstDiffIndex was found then
        firstDiffIndex
    else
        length pairs

Not sure about the performance of this or if firstFindIndex is the best generalization of the foldl' idea you have.

Thinking about this a little more, the following can also be a route if commonPrefixLength is otherwise not too useful by itself (which I am unsure about but think it might be only useful as a helper function for commonPrefix):
We use your algorithm and create the more general:
findFirstWithIndex = predicate: list:
    return first { index, value } matching predicate

and then use that to define:
takeWhile = predicate: list:
    let sentinel = findFirstWithIndex (elem: !(predicate elem)) list in
    if sentinel != null then
        take sentinel.index list
    else
        list

and finally:
commonPrefix = list1: list2:
    takeWhile (predicate comparing list1[i] with list2[i])

where forming that last predicate depends on some design decisions (like does predicate accept the index, do we use zipLists, do we first get the shorter list and take over it explicitly).

findFirstWithIndex

This seems like a useful function to factor out.
To simplify it a bit, you could return just the index. That way you don't have to allocate the { index, value } attrset just to ignore value. You could call it findFirstIndex then.

@tjni Nice idea! This turned out to work out really well since I was able to reuse a lot of code. I removed commonPrefixLength again, it's not really necessary to expose that, it's really just a helper function as you suggested. Instead findFirstIndex is now available :)


Too small clickzone of toggle, scroll position not retained

This is a great Gitbook plugin, thank you!
I'm seeing a few UX issues however. Maybe you find a way to improve it.
If you click on the toggle to collapse/expand chapters, you must be careful where you click. The clickzone seems to be limited to the icon instead of using the padding/margin around too.
Example:
https://docs.arangodb.com/devel/
If you expand a few chapters further down and then navigate to a sub-chapter, the scroll position of the navigation will be changed - it ends up somewhere at the top, but not at the very to (?!). It would be great if it could either keep the last scroll position, or scroll to a position in which the current chapter is visible. It should not show the clicked chapter at the very top however, but as 2nd/3rd. Rationale: If a user mis-clicked on a chapter and wanted to click the one above, it's easier to correct if there are also a few chapters displayed above the active (no scrolling required).
Video: http://youtu.be/-tx_NFKS-7A

Hi, sorry for the long delay - just back from vacation ;-)
Regarding the click area - that's sth I will fix as soon as I've some energy left (would take some time as there is many more important work upfront - feel invited to fork, change & I will merge and publish your changes).
Regarding the scrolling enhancement - therefore I know no nice solution - so I'm unsure whether I will implement. If you've an good idea, feel invited also ...
BR, jerger


Investigate installing regolith

What does it look like to download and use regolith for the random user?
Can they rely on regolith gopath thing, or do they need to include an .exe in every project.
What can we do to make this process awesome and easy?

we could probably throw together a simple installer which throws regolith (and an auto-updater?) in a Program Files/ directory, and then adds regolith to the path. meaning they can use it wherever. I'm hesitant to rely on the gopath, as needing Golang installed should not be a usage requirement in my opinion

Partially added in https://github.com/Bedrock-OSS/regolith/commit/bb1b6af352c883958f6f43a0aa91cba11d72deac
Currently generates MSI installer for windows, but fails to generate it in GitHub Action.


Documentation wrong for Installing the IBM Blockchain Platform on Openshift

I did a first try to install the IBP console on Openshift via Ansible, I hit an issue which is related to this documentation:
https://ibm-blockchain.github.io/ansible-collection/tutorials/installing.html#installing-the-ibm-blockchain-platform
I noticed a wrong setting for install-ibp.yml:
I changed the setting to target: openshift to overcome this issue.
Can you please check? Thanks.

Fixed under #325, will publish a release this week.


Bug: multi-labels don`t work as expected

I added the ec2 runner for test ...
cdk code:
    const cloudPlatformsEc2Runner = new Ec2Runner(
      this,
      `${props.serviceName}-${props.stage}-ec2-runner`,
      {
        labels: ["cloudplatforms", "ec2"],
        vpc: existingVpc,
        subnetSelection: vpcSubnets,
        spot: true,
        instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
      }
    );

workflow.yml:
name: fargate example
on: workflow_dispatch
jobs:
  self-hosted:
    runs-on: [self-hosted,cloudplatforms,ec2]
    steps:
      - run: echo hello world

stepfunctions:
these labels have been transmitted:
  "labels": {
    "self-hosted": true,
    "cloudplatforms": true,
    "ec2": true
  },

result:
it`s taking the wrong label :O

I assume because of this weird parent label

ok, fine I figured out that the order of the runners is important ... like in a classic if, else if, else order ...

@kichik  Would be nice if the state machine checks exactly for the given labels.

I need to think about this one. Not sure if people would want to include labels that are not taken into consideration to carry some meta data with them.

Ok having two different github runner stacks running (one prod, one experimental) this leads to confusion.
On each app a runner will be started when one of the same tags is used in both GitHubRunners stacks.

Can you please include the labels both runner stacks are waiting for and the labels used by the job? I'm not sure I understand how this specific issue will cause two runners to start.
Either way, I'm still not 100% sure about this issue. How about we start with a flag that's off by default? The webhook function would have to generate a string of sorted labels joined by a comma. It should get an environment variable flag switching between the old and new behavior. Or maybe just always send both in two different fields.
https://github.com/CloudSnorkel/cdk-github-runners/blob/29708ebe9a83cf84566a7073cda60dd6bbff402a/src/lambdas/webhook-handler/index.ts#L92-L94
Then our comparison below can be labels == "self-hosted,cloudplatforms,ec2".
https://github.com/CloudSnorkel/cdk-github-runners/blob/29708ebe9a83cf84566a7073cda60dd6bbff402a/src/runner.ts#L295-L302

As I was writing the documentation for this feature, I realized why this is a bug bug. The provider took a job that it cannot actually execute. The job will never be assigned to the ["cloudplatforms"] provider. The job requires ["cloudplatform", "ec2"]. So the provider will start an unused runner.
I still feel like I'm missing something, so I'll open the PR and leave it open for a few days.

I think I will end up adding a warning if labels collide this way. I can't think of a way to make this work in a way that will also be pleasant for the user. The only solution I can think of is forcing the user to always specify all the labels including OS and architecture.

Next version should have a warning (and an error for duplicate labels). If anyone could think of a better way, please re-open this ticket.


HELP WANTED: Relay example

Would be great if there's an example of this using Relay instead of Redux.
It would make more sense to use Relay with GraphQL than Redux IMO.

We are planning to add more examples in the future including Relay, it will take a while though until we're ready to do that.

Yeah, but to use relay, the server needs to handle the variables as well.

@flomotlik Could you provide some indication when you could release an update graphql sample based on serverless 1.x?
Currently what would you recommend to use this repo as a base or rather use serverless rc 1.0 and integrate graphql ourself?
Thank you!

@tobias-sc at the moment we don't have a timeframe to update this, so the best way forward is to use rc1 and integrate graphql directly. We've used it in one of our projects and its pretty straight forward.

Hey @tobias-sc, @rafanami & @M1chaelTran, we just updated the repository and added the setup for a Relay client. We are going to announce it later today. Please let us know if you have some feedback for us.

That's wonderful news @nikgraf 👍
Look forward to trying it out.

@M1chaelTran looking forward to your feedback 👍

@nikgraf & team - thank you for the upgrade and release.
We decided to go with the old version 0.5.x + Redux earlier and do not consider Relay at this stage.


launch sync images and fix volume name

What type of PR is this?
/kind enhancement
/sig iot
What this PR does / why we need it:
The controller works on the images of the openyurt repo. Therefore, the mirror synchronization function needs to be enabled. yurt-app-manager has a naming convention and cannot use ’_‘,  so it is changed to ’-‘.

/lgtm


Some events are not shown in event log/list

region27.zip
Steps to reproduce:

Load in DF native legends mode historical figure called Beben Wandmotte / Benen Walledmoth - check how for example in 245 he got married to Arbeiten Brassrain
Load world in LevendsViewer 1.0 or 1.1 and check same historical figure and see there are no events listed after the year 244

I can not use the save file because it uses mods, can you provide the exported legends files?

mods.zip
Sorry, the exact save was lost due to progress on the same world and the current save doesn't have the issue. I have attached the custom mods I play with so you can try and reproduce with the provided save if you have the time and resources. The other mods on the save are from the steam workshop, only these I attached here are custom.


Add Most Severe Accidents widget (map)

Add a widget that receives an array of data in the format:
{
  "longitude": 34.9780568296871,
  "latitude": 32.4543458814189,
  "accident_severity": "קשה",
  "accident_timestamp": "2016-05-15 21:00:00"
}

And shows it on a map.
There's a location widget component that you can use for this, but it might need modification to work with multiple locations.

solved by #92


Limit of 250 devices

I experiencing a problem at the moment with connecting new Zigbee devices. I am using Domoticz on a Raspberry PI. The plugin is updated and has version v.1.17.1 (zStack3x0 20200925)
It looks like there is a limit in devices that can be connected. In the logging I see the following error:
2021-02-19 14:16:30.246 Error: Python Plugin System: (Zigbee2MQTT) 'CDevice_init' failed 'TypeError':'an integer is required (got type NoneType)'.
2021-02-19 14:16:30.246 Error: Device creation failed, Device object is not associated with a plugin.
2021-02-19 14:16:30.246 Error: Expected: myVar = Domoticz.Device(Name="myDevice", Unit=0, TypeName="", Type=0, Subtype=0, Switchtype=0, Image=0, Options={}, Used=1)
2021-02-19 14:16:30.246 Error: Python Plugin System: (Zigbee2MQTT) 'CDevice_init' failed 'TypeError':'an integer is required (got type NoneType)'.
2021-02-19 14:16:30.246 Error: Device creation failed, Device object is not associated with a plugin.
How can this be fixes.
Thanks in advance.

This is a duplicate, please see issue 325

Same problem.

Duplicates #325


GitDiffFilter: expand -git-project-root argument to absolute path

cc @ligurio
The paths should now expand correctly.
Thanks for reporting this!


ci: add rhel-8 linter run

We support multiple release targets but only run linters (and unit-tests, fwiw) on a single target. This often causes downstream release-tests to report failures after the code is already merged.
While we can easily run our CI in UBI-8 containers, the better approach would probably be to integrate with testing-farm via packit. This looks quite simple to integrate, yet no-one has stepped up to do this, yet.
This is to track the progress on this.

FWIW, we should also test on c9s / rhel-9


Linking VCs via API does not work

Problem description
Linking VCs via the API still does not work. This issue was originally raised as a discussion, but the problem still persists. My first contributions to the discussion were based on Guardian v2.21.1. I have since tested it on a newer version of Guardian (not entirely sure which one, because the version number does not show up when I go to 'Administration' > 'About', but I think it's v2.24.1 or v2.25.0), still without success.
Attached is a screen recording I made just now.
Note that I have tested it on both /api/v1/policies/{policyId}/tag/{blockTag}/blocks and /api/v1/policies/{policyId}/blocks/{blockId}; neither was successful.
Expected behavior
Linking VCs via POST requests to requestVcDocumentBlock elements of a policy should succeed.
https://github.com/hashgraph/guardian/assets/11308324/0c70694f-65a8-4f44-a86b-ac165139aa85

@AlexIvanHoward thank you for the detailed explanation. Could you please upload a policy with which you have observed this behaviour so we are able to reproduce this exactly how you observe it?

@anavbar Here is the policy that I used in the screen recording:
policy_1713185713329.zip


Refactor release reconciliation

@seaneagan noted, and thank you for taking the time.
I am open to suggestions for improvements and/or alternative approaches, as the issues you have brought up do seem valid (but preventable) at this moment (although it is late here, and I need to reweigh them again tomorrow with fresh energy).
Given the goal of this PR is to improve testability, my item on the list for this PR is to create Go tests for the reconciler actions so that we can properly test and cover the uncertainties you describe.
First step to achieve this is to untangle some of the Runner code to make it possible to inject Helm's fake kube client and their memory based storage driver, after that it should be fairly easy to mock state and confirm the reconciliation outcome.

the install/upgrade retry exhaustion now no longer applies to test and remediation actions

It still does? https://github.com/fluxcd/helm-controller/blob/release-refactor/controllers/helmrelease_controller_release.go#L276-L280

Also when a release is not remediated, either intentionally (remediateLastFailure=false), or has a failed remediation, this can lead to infinite test retries as well, since LastSuccessfulReleaseRevision != LastReleaseRevision, which could lead to silently ignoring test failures when a subsequent one succeeds, which may be ok but one probably wants a way to prevent that.

I think this actually all captured by the state observations we do on the release object itself? https://github.com/fluxcd/helm-controller/blob/release-refactor/controllers/helmrelease_controller_release.go#L183-L200

the install/upgrade retry exhaustion now no longer applies to test and remediation actions

It still does? https://github.com/fluxcd/helm-controller/blob/release-refactor/controllers/helmrelease_controller_release.go#L276-L280

Sorry, not sure how I missed that. One scenario I'm still not sure about, if we have say 5 upgrade retries enabled, and the first upgrade fails, and then the rollback repeatedly fails, the upgrade retries will thus be skipped, and thus the release revision will continue to rev to infinity for each new failed rollback. I assume solving this would mean adding a retry limit (whether configurable or not) and failure count status field for rollbacks. I don't think uninstall has the same issue since a failure to uninstall shouldn't rev the release revision, although perhaps it makes sense to stop retrying at some point anyways, not sure.

Also when a release is not remediated, either intentionally (remediateLastFailure=false), or has a failed remediation, this can lead to infinite test retries as well, since LastSuccessfulReleaseRevision != LastReleaseRevision, which could lead to silently ignoring test failures when a subsequent one succeeds, which may be ok but one probably wants a way to prevent that.

I think this actually all captured by the state observations we do on the release object itself? https://github.com/fluxcd/helm-controller/blob/release-refactor/controllers/helmrelease_controller_release.go#L183-L200

Missed that as well, thanks.


missing contrirbuting.md file

Hey i think this is amazing repo having a , contributing.md file is amazing for the new contributors like me and other

You can find this info already at https://github.com/ucsc-ospo/ucsc-ospo.github.io/graphs/contributors

Thats amazing. Thanks


Fix will cause error if trying to get romaji position with no ruby.

The easy way to fix that is make sure that this.Rubies should not be null in the GetRomajiTagPosition()

Not tested but seems fixed.


Disqus avatar not displaying

The disqus user avatar isn't displayed in the comment section when browsing in width lesser than 540px. This is due to disabling scroll for post-list class which it is part of.

#Fixed Seems that the html style overflow-x:hidden; was messing with disqus.


old version on https://getbootstrap.com/

Hi,
i just noticed that the Bootstrap website delivers different content for HTTP and HTTPS!

https://getbootstrap.com/ Currently v4.0.0
http://getbootstrap.com/ Currently v4.1.1

When i open the source code of both pages I see
<!-- Bootstrap core CSS -->
<link href="/docs/4.1/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-WskhaSGFgHYWDcbwN70/dfYBj47jz9qbsMId/iRN3ewGhXQFZCSftd1LZCfmhktB" crossorigin="anonymous">

And when I open the css file
/*!
 * Bootstrap v4.1.1 (https://getbootstrap.com/)
 * Copyright 2011-2018 The Bootstrap Authors
 * Copyright 2011-2018 Twitter, Inc.
 * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
 */

So I can't confirm this. (Or they fixed it)

No, for me the HTTPS version is still v4.0.0
Where are you from? I'm from germany and the website is served by cloudflare, maybe their CDN is just wrong?

Already been discussed here - https://github.com/twbs/bootstrap/issues/26441, issue has been fixed as far as I'm aware and will go live at some point


support loading and saving models

support saving models with syntax of
@emulate(samples={
    'a': np.random.rand(100),
    'b': np.random.rand(100)
}, backend='sklearn', save="test.pkl")
def test_em(a=1, b=1):
    x = np.linspace(0, 10, 100)
    return np.sin(a*x) + np.sin(b*x)

and then loading it with
@emulate(backend='sklearn', load="test.pkl")
def test_em(a=1, b=1):
    x = np.linspace(0, 10, 100)
    return np.sin(a*x) + np.sin(b*x)

Codecov Report
Base: 0.00% // Head: 0.00% // No change to project coverage :thumbsup:

Coverage data is based on head (66930c4) compared to base (a4a6508).
Patch coverage: 0.00% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@          Coverage Diff           @@
##           master      #4   +/-   ##
======================================
  Coverage    0.00%   0.00%
======================================
  Files           3       3
  Lines         172     223   +51
======================================
- Misses        172     223   +51

Impacted Files
Coverage Δ

galilei/emulator.py
0.00% <0.00%> (ø)

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Bump cuDNN to v8.0.4

pfnCI, test this please.

Would you fix the CI failure on flake8?

pfnCI, test this please.

Jenkins CI test (for commit 14e7fa4c1504778e26619e602c630fec7c42ff10, target branch master) failed with status FAILURE.

pfnCI, test this please.

Jenkins CI test (for commit 14e7fa4c1504778e26619e602c630fec7c42ff10, target branch master) succeeded!


Add timestamps to log messages

Looks like: [2018-08-09T12:13Z] [Debug] Received message of type PING
Issue: https://github.com/aspnet/SignalR/issues/2750

Ping 😄

Updated 👍

Can you update your example above? With the change you made it should no longer be printing a Z at the end (or if it is, we'll need to figure out how to fix that because the Z indicates UTC which is inaccurate :))

[2018-08-11T23:00-0700] [Debug] Received message of type PING

Why is this inaccurate? Also, it's what we did for TS client

Because the TS client renders a UTC time, but the Java client is rendering a local time.


Create plugin script doesn't run on download

On macOS Ventura the create plugin command doesn't work it just returns to the command prompt:
sudo curl -o- https://raw.githubusercontent.com/beezwax/bzBond/main/packages/bzBond-server/bin/create-plugin.sh | bash
Password:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   477  100   477    0     0   5078      0 --:--:-- --:--:-- --:--:--  5482
# bzBond-server-microbonds %

The read command doesn't work when executing from curl. Fixed by changing command to:
bash <(curl -s https://raw.githubusercontent.com/beezwax/bzBond/main/packages/bzBond-server/bin/create-plugin.sh)
@gosukiwi


feature request - add vwgen cli option to create N number of Node configs using a basename & a number specifying how many

Could you add a vwgen command line option to create a large number of Node configs.
example:
_

vwgen add wg-meshvpn node1 node2 node3

_
is fine for 2,3.. maybe 10 Nodes.
But what if you needed 50 Nodes (or more)?   Specifying them all this way would be alot of repetitive typing.
Could some option be created  to do this for the user.
example:
_

vwgen add wg-meshvpn nameroot="string"  numbernodes="#"

where:   nameroot would be something like "node" or "cn" or anything
where:  numbernodes would be the number of "namerootXX" to
maximum number of Node Configs to generate
_

So

vwgen add wg-meshvpn nameroot=mycn numbernodes=25

would create 25 Node Configurations and they would be named as a concatenation of
the "nameroot" and the "number" so in the above it would generate:
mycn1
mycn2
mycn3
...
mycn25
The above is just my .02 cents and there may be a better way to do this but I think it would
be helpful to have something like this?

What you want might be:
vwgen add wg-meshvpn $(seq -f 'mycn%.f' 50)

Cool I wasn't aware vwgen could execute an external program like 'seq'.
This works for me regarding this issue but read the section in the following URL
titled:

The seq command to create standard bash for Loop (outdated method)

https://www.cyberciti.biz/faq/bash-for-loop/


[Feature] Remove specific label/annotations for configmap/secret

Contextualization
When I use kubed and argo-cd together, kubed will sync labels such as argocd.argoproj.io/instance which will make argo-cd classify the configmap/secret as a part of application and mark app as "OutOfSync".
Solution
Use annotation/labels like argocd.argoproj.io/remove-label: labelA, labelB and argocd.argoproj.io/remove-annotation: AnnoA, AnnoB to remove the label/annotation from the annotation/labels.
Any help will be highly appreciated :)

Any ideas/workarounds?


⚠ Samsung has degraded performance

In 34cf659, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2506 ms

Resolved: Samsung performance has improved in 5a4ef33.


[UPDATE] Backup banner

Please update the backup banner on main view according to figma:

QA done.


Fix 174 delete list returns warning

I just added a return statement to prevent the server from generating a warning about the promise being created but not returned.

@ZackWard I think you created a new branch on top of another branch (which fixes another bug).  There are two commits in this branch. You can check the commits tabs. Also, can you make a PR to staging branch instead of master ? Both are at different positions now and I am sorry, I think it's not mentioned anywhere officially that contributions are to be done to staging branch

@karuppiah7890 Oops! I'll fix and resubmit. 😃


Cleanup script fails when there is an Adapter with no name

When running the following:
.\WindowsContainerNetworking-LoggingAndCleanupAide.ps1 -Cleanup -ForceDeleteAllSwitches
And when there is a network adapter with no name (null) like this:

The script fails here:

To work around this, I altered the script to go by $adapter.InterfaceDescription instead of $adapter.Name. To fully correct the issue I suggest handling with both fields and checking for null values.

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


localtunnel is down?

Hi, localtunnel is not working for me. Someone have same problem?

Same issue. I just opened #539

Yeah having the same

Should be back up everyone! Datacenter had some networking issues 😭


read_spikes doesn't handle an empty file properly

If you have a parameter file that fails to induce spiking in cells and doesn't have any evoked inputs (e.g. only rhythmic inputs), then the spk_0.txt file will be empty. This causes an error in read_spikes (last line below). It's not clear how to skip one empty spike file because the method uses concatenation in order of trial index 0, 1, 2, 3, etc.
/Users/blake/repos/hnn-core/hnn_core/network.py:40: UserWarning: loadtxt: Empty input file: "/Users/blake/hnn_out/data/gamma_L5weak_L2weak_bursty/spk.txt"
  spike_trial = np.loadtxt(file, dtype=str)
(0,)
Traceback (most recent call last):
  File "/Users/blake/repos/hnn/hnn_qt5.py", line 596, in run
    self.runsim() # run simulation
  File "/Users/blake/repos/hnn/hnn_qt5.py", line 678, in runsim
    updatedat(self.params)
  File "/Users/blake/repos/hnn/simdat.py", line 121, in updatedat
    spikes = read_spikes(dfile['spk'])
  File "/Users/blake/repos/hnn-core/hnn_core/network.py", line 42, in read_spikes
    spike_times += [list(spike_trial[:, 0].astype(float))]
IndexError: too many indices for array: array is 1-dimensional, but 2 were indexed

I suppose you would append an empty list to spike_times?
@samikane do you want to give this a shot? It looks like a nice issue to get your hands dirty with some of the code while not being too complicated.

@rythorpe @samikane this should be a quick fix. any takers?


Update sbt-protoc to 0.99.27

Updates com.thesamet:sbt-protoc from 0.99.18 to 0.99.27.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.thesamet", artifactId = "sbt-protoc" } ]

labels: semver-patch

Codecov Report

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

@@          Coverage Diff           @@
##           master    #332   +/-   ##
======================================
  Coverage    80.5%   80.5%
======================================
  Files         128     128
  Lines        3334    3334
  Branches      136     136
======================================
  Hits         2684    2684
  Misses        650     650

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 69c58a5...52d8979. Read the comment docs.


Update fork

This PR:

Renames the package to FFC from FFaCiL

The combination of upper and lower case, and the length of FFaCiL made it somewhat unpleasant to type

Removes the dependence on Yatima Standard Library by migrating the necessary files to the Util submodule.

I don't plan on maintaining YSL which is a much larger codebase than what is needed for this library
It should be a top priority to minimize the Util files. I did a rough job of moving over the functionality from YSL, but a lot of it has since been superseded by std4 and a lot is likely not strictly necessary for functionality.

Bumps the toolchain to leanprover/lean4:nightly-2023-07-24.

This still has a failing SWM test.
I believe the failing tests are coming from the change in Lean's integer division behavior which were discussed in the lean 4 dev Zulip channel...
There's also a totally possible change that I wasn't completely careful transferring the Yatima Standard Library files into Util which broke everything.

Tests pass now, the PR should be good for review!

This still has a failing SWM test.
I believe the failing tests are coming from the change in Lean's integer division behavior which were discussed in the lean 4 dev Zulip channel...
There's also a totally possible change that I wasn't completely careful transferring the Yatima Standard Library files into Util which broke everything.

I would fix that as a separate issue.


is it support Zcoin/XZC?

Zcoin had founders reward,like zcash
XZC algo is lyra2Z begin block 20500
our z-nomp was support it?

no, z-nomp will only support equihash currencies

Ocminer has a fork of NOMP working for Zcoin's new algo https://github.com/ocminer/node-multi-hashing-xzc

thx
my pool is running

[zcoin] Cannot run a pool for unsupported algorithm "lyra2Z"
what's wrong ?
coins/zcoin.json
{
"name": "zcoin",
"symbol": "xzc",
"algorithm": "lyra2Z",
"requireShielding": false
}
install  https://github.com/ocminer/node-multi-hashing-xzc
using npm 0.12.8
npm install multi-hashing
npm WARN package.json<EMAIL_ADDRESS>No license field.
npm WARN cannot run in wd<EMAIL_ADDRESS>node-gyp rebuild (wd=/home/user/z-nomp-zcoin/node-multi-hashing-xzc/node_modules/multi-hashing)
<EMAIL_ADDRESS>node_modules/multi-hashing
└──<EMAIL_ADDRESS>


clementine: provide free derivation by default

Motivation for this change
The clementine package is actually released under Apache license, but
requires the unfree libspotify package to build.
Now nixpkgs.clementine points to the free derivation and
nixpkgs.clementineUnfree has been introduced for the package bundled
with spotify support.
Fixes #38315
Note: I had to revert commit ca54d50 as it broke clementine previously (see the Hydra logs at https://hydra.nixos.org/build/72403466)
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Success on aarch64-linux (full log)
Attempted: clementine
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1
shrinking /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1/bin/clementine-tagreader
shrinking /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1/bin/clementine
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1/bin
patching script interpreter paths in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1
checking for references to /build in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1...
/nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1

Success on x86_64-linux (full log)
Attempted: clementine
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/r7m7rnsp0dmpx24p5yjz6cbwq5kpf6z5-clementine-free-1.3.1
shrinking /nix/store/r7m7rnsp0dmpx24p5yjz6cbwq5kpf6z5-clementine-free-1.3.1/bin/clementine-tagreader
shrinking /nix/store/r7m7rnsp0dmpx24p5yjz6cbwq5kpf6z5-clementine-free-1.3.1/bin/clementine
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/r7m7rnsp0dmpx24p5yjz6cbwq5kpf6z5-clementine-free-1.3.1/bin
patching script interpreter paths in /nix/store/r7m7rnsp0dmpx24p5yjz6cbwq5kpf6z5-clementine-free-1.3.1
checking for references to /tmp/nix-build-clementine-free-1.3.1.drv-0 in /nix/store/r7m7rnsp0dmpx24p5yjz6cbwq5kpf6z5-clementine-free-1.3.1...
/nix/store/r7m7rnsp0dmpx24p5yjz6cbwq5kpf6z5-clementine-free-1.3.1

Success on aarch64-linux (full log)
Attempted: clementine
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1
shrinking /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1/bin/clementine-tagreader
shrinking /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1/bin/clementine
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1/bin
patching script interpreter paths in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1
checking for references to /build in /nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1...
/nix/store/xcr05zy9xr94ggsn1vvlfl4srn6sifmx-clementine-free-1.3.1

I'm not sure if this is the right thing to do. Shouldn't we just add a config option to "celementine", something like "withSpotify"? You can just call it with clementine.overideAttrs { withSpotify = true; } etc.

So you propose to disable the unfree build by default?
What I’m trying to do is to use the entirely free clementine build by default and clementineUnfree comes with libspotify. Both variants will be prebuilt on Hydra so noone will have to recompile locally.
I may be misunderstanding you, but why would you want to solve this with override parameters only?

A config option is possible, but less convenient/discoverable at the moment without module system.

previously we used clementine and clementineFree as toplevel attributes, I didn't introduce a new one. In order to remain consistent I justed swapped both attributes and renamed clementineFree accordingly to clementineUnfree.


Tutorials section on the website

I propose to add a new tutorials section on the website (givent we write some of them):

getting started
instantsearch.js + React (once we are able to do it)
instantsearch.js + Bootstrap
building a widget
plug any jQuery plugin into instantsearch.js

What do you think?

instantsearch.js + Bootstrap is very important for us. Currently almost no layout works for us :-(

@powtac Can you open a new issue with specific issues while working with bootstrap? Also feel free to close issues that were solved, thanks


DataGranules.get raises IndexError when Granules found = zero

What Happens
If I do a simple search for granules that returns zero hits, I get an index error.
In [12]: results = earthaccess.search_data(short_name='ATL07', temporal=('2023-01-01','2023-01-01'), bounding_box=(-180.,65.,180.,90.))
Granules found: 0
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
Cell In[12], line 1
----> 1 results = earthaccess.search_data(short_name='ATL07', temporal=('2023-01-01','2023-01-01'), bounding_box=(-180.,65.,180.,90.))

File ~/src/earthaccess/earthaccess/api.py:124, in search_data(count, **kwargs)
    122 if count > 0:
    123     return query.get(count)
--> 124 return query.get_all()

File ~/mambaforge/envs/earthaccess-dev/lib/python3.10/site-packages/cmr/queries.py:105, in Query.get_all(self)
     96 def get_all(self):
     97     """
     98     Returns all of the results for the query. This will call hits() first to determine how many
     99     results their are, and then calls get() with that number. This method could take quite
   (...)
    102     :returns: query results as a list
    103     """
--> 105     return self.get(self.hits())

File ~/src/earthaccess/earthaccess/search.py:402, in DataGranules.get(self, limit)
    386 """Get all the collections (datasets) that match with our current parameters
    387 up to some limit, even if spanning multiple pages.
    388
   (...)
    398     query results as a list of `DataGranules` instances.
    399 """
    400 response = get_results(self, limit)
--> 402 cloud = self._is_cloud_hosted(response[0])
    404 return list(DataGranule(granule, cloud_hosted=cloud) for granule in response)

IndexError: list index out of range

What I expect
I would expect this to return an empty list as print Granules found: 0 to stdout.
Proposed change
Check that response is not empty before checking _is_cloud_hosted.  Return empty list if it is empty.

https://github.com/nsidc/earthaccess/blob/0e4f3928c39e32c93acf1671389fbc9c65121544/earthaccess/search.py#L521-L525
This has a smell to me. Why are we doing this post-process step to calculate if all granules are cloud-hosted based on the first granule, instead of having the DataGranule class set cloud_hosted for each granule at init-time? It would be great to put that rationale in a comment for future us.
If there's good rationale, or if we're looking for a short-term fix, I think we can add a quick:
if not results:
    return []

to resolve the bug.

https://github.com/nsidc/earthaccess/blob/0e4f3928c39e32c93acf1671389fbc9c65121544/earthaccess/search.py#L521-L525
This has a smell to me. Why are we doing this post-process step to calculate if all granules are cloud-hosted based on the first granule, instead of having the DataGranule class set cloud_hosted for each granule at init-time? It would be great to put that rationale in a comment for future us.
If there's good rationale, or if we're looking for a short-term fix, I think we can add a quick:
if not results:
    return []

to resolve the bug.

I would suggest simply changing the assignment to cloud to this to fix the IndexError:
cloud = len(response) > 0 and self._is_cloud_hosted(response[0])

However, I think this reveals another bug. It is erroneous to assume that if response[0] is (or is not) cloud hosted, then the rest of the granules in the response are (or are not) cloud hosted as well. If the query does not specify the cloud_hosted parameter, then the results could possibly be a mix of cloud hosted and non-cloud hosted granules.
For example, it is valid to specify multiple collection concept IDs in a CMR granule search query. If one collection is cloud hosted and the other is not, then the granules will be a mix of cloud hosted and non-cloud hosted.
Therefore, I believe the proper fix to address both bugs (IndexError and wrong assumption) is to completely remove the line that assigns a value to cloud and then change the return statement to this:
return [DataGranule(granule, cloud_hosted=self._is_cloud_hosted(granule)) for granule in response]

However, I think this reveals another bug. It is erroneous to assume that if response[0] is (or is not) cloud hosted, then the rest of the granules in the response are (or are not) cloud hosted as well. If the query does not specify the cloud_hosted parameter, then the results could possibly be a mix of cloud hosted and non-cloud hosted granules.

:100: This is the smell I was trying to communicate, thanks for explaining it better than me!

https://github.com/nsidc/earthaccess/blob/0e4f3928c39e32c93acf1671389fbc9c65121544/earthaccess/search.py#L521-L525
This has a smell to me. Why are we doing this post-process step to calculate if all granules are cloud-hosted based on the first granule, instead of having the DataGranule class set cloud_hosted for each granule at init-time? It would be great to put that rationale in a comment for future us.
If there's good rationale, or if we're looking for a short-term fix, I think we can add a quick:
if not results:
    return []

to resolve the bug.

I would suggest simply changing the assignment to cloud to this to fix the IndexError:
cloud = len(response) > 0 and self._is_cloud_hosted(response[0])

However, I think this reveals another bug. It is erroneous to assume that if response[0] is (or is not) cloud hosted, then the rest of the granules in the response are (or are not) cloud hosted as well. If the query does not specify the cloud_hosted parameter, then the results could possibly be a mix of cloud hosted and non-cloud hosted granules.
For example, it is valid to specify multiple collection concept IDs in a CMR granule search query. If one collection is cloud hosted and the other is not, then the granules will be a mix of cloud hosted and non-cloud hosted.
Therefore, I believe the proper fix to address both bugs (IndexError and wrong assumption) is to completely remove the line that assigns a value to cloud and then change the return statement to this:
return [DataGranule(granule, cloud_hosted=self._is_cloud_hosted(granule)) for granule in response]

Since DataGranule constructor and _is_cloud_hosted both depend on this granule object (loaded JSON), what do you think of encapsulating that logic within DataGranule and moving the _is_cloud_hosted method from DataGranules to DataGranule?

Therefore, I believe the proper fix to address both bugs (IndexError and wrong assumption) is to completely remove the line that assigns a value to cloud and then change the return statement to this:
return [DataGranule(granule, cloud_hosted=self._is_cloud_hosted(granule)) for granule in response]

Since DataGranule constructor and _is_cloud_hosted both depend on this granule object (loaded JSON), what do you think of encapsulating that logic within DataGranule and moving the _is_cloud_hosted method from DataGranules to DataGranule?

Agreed that _is_cloud_hosted makes sense to be moved to DataGranule. I would say there's also no need to make it "private" either (i.e., drop the underscore prefix), and should perhaps even be a cached property (from functools) on DataGranule, similar to this (I also suggest dropping the is prefix, but not utterly opposed to keeping it):
@cached_property
def cloud_hosted(self) -> bool:
    ...

I might also suggest dropping the cloud_hosted parameter of DataGranule, but I don't know if there's a specific reason that's there. Perhaps there are cases where we want to force cloud_hosted to be True even though the logic currently in _is_cloud_hosted would evaluate to False, so it serves as an override in the "I know what I'm doing" sense.
cc: @betolink

The cloud_hosted parameter enables searching for only cloud-hosted data when cloud_hosted=True and only DAAC-hosted (a.k.a on-prem) when cloud_hosted=False.

The cloud_hosted parameter enables searching for only cloud-hosted data when cloud_hosted=True and only DAAC-hosted (a.k.a on-prem) when cloud_hosted=False.

I'm referring to the cloud_hosted param to DataGranule (singular, not plural).

Agreed that _is_cloud_hosted makes sense to be moved to DataGranule. I would say there's also no need to make it "private" either (i.e., drop the underscore prefix), and should perhaps even be a cached property (from functools) on DataGranule

:100:

I might also suggest dropping the cloud_hosted parameter of DataGranule, but I don't know if there's a specific reason that's there. Perhaps there are cases where we want to force cloud_hosted to be True even though the logic currently in _is_cloud_hosted would evaluate to False, so it serves as an override in the "I know what I'm doing" sense.

Anybody know why DataGranule takes a cloud_hosted parameter?
With my current understanding, it doesn't seem to make sense to me to explicitly specify such a parameter, particularly if we move the logic in DataGranules._is_cloud_hosted to a new attribute DataGranule.cloud_hosted. Note that we're moving logic from DataGranules (plural) to DataGranule (singular).
I would think that with such a move, we would want to deprecate the cloud_hosted parameter to DataGranule.__init__.

I might also suggest dropping the cloud_hosted parameter of DataGranule, but I don't know if there's a specific reason that's there. Perhaps there are cases where we want to force cloud_hosted to be True even though the logic currently in _is_cloud_hosted would evaluate to False, so it serves as an override in the "I know what I'm doing" sense.

Anybody know why DataGranule takes a cloud_hosted parameter?
With my current understanding, it doesn't seem to make sense to me to explicitly specify such a parameter, particularly if we move the logic in DataGranules._is_cloud_hosted to a new attribute DataGranule.cloud_hosted. Note that we're moving logic from DataGranules (plural) to DataGranule (singular).
I would think that with such a move, we would want to deprecate the cloud_hosted parameter to DataGranule.__init__.

@betolink, do you have any background knowledge on why this is implemented this way?

Sorry for the delayed response, there are collections that exist both in the DAAC and AWS with the same short_name. cloud_hosted is a flag to indicate that we can use the S3 links. The ultimate reason is to simplify open() and download() so it defaults to S3 if the code is running in us-west-2. We could check for the S3 links in "RelatedUrls" (umm) but injecting a flag from the search results was faster if I recall. @chuckwondo

Sorry for the delayed response, there are collections that exist both in the DAAC and AWS with the same short_name. cloud_hosted is a flag to indicate that we can use the S3 links. The ultimate reason is to simplify open() and download() so it defaults to S3 if the code is running in us-west-2. We could check for the S3 links in "RelatedUrls" (umm) but injecting a flag from the search results was faster if I recall. @chuckwondo

Sure, injecting a flag would be faster (although I suspect this would be negligible, thus a questionable "optimization"), but more importantly, it's possibly simply wrong, per an earlier comment I made:

However, I think this reveals another bug. It is erroneous to assume that if response[0] is (or is not) cloud hosted, then the rest of the granules in the response are (or are not) cloud hosted as well. If the query does not specify the cloud_hosted parameter, then the results could possibly be a mix of cloud hosted and non-cloud hosted granules.
For example, it is valid to specify multiple collection concept IDs in a CMR granule search query. If one collection is cloud hosted and the other is not, then the granules will be a mix of cloud hosted and non-cloud hosted.

Observations added from duplicate #816:

we better also make sure that earthaccess.download doesn't choke when given [].

perhaps when [earthaccess.search_data] returns an empty list we should log a warning?

As a workaround, I used the following:
try:
                granules = earthaccess.search_data(concept_id = id, temporal = (start_date,end_date))

```...

`except:  print("no granules found")`


Version released on python package index has no license data

While trying to get jupysql imported into my corporate repository, it is refused because internal scans can determine no license statement for the nested dependency ploomber-core==0.2.7.
Is there any chance we can get the released pip package to have a specification that includes the usual things, such as what license is used?  Currently pypi seems to know nothing but the name of the package.

Thanks for your feedback.
Sure! We can make a release and add the missing License details, I can work on this today and upload it to PyPI!

I released 0.2.8 and added license metadata: https://pypi.org/project/ploomber-core/0.2.8/

does this fix the problem?

It does indeed fix things.  Thanks for the help!


Added backend api of contact form

**Title: Backend for contact form
**Issue No.: #221
Close #221
https://github.com/user-attachments/assets/0ff05566-0958-4c52-a634-8ab86b4516b6

Followed proper folder structure !!
MONGO DB compass SS , data submitted successfully on database !!
Checklist:

[ X] I have mentioned the issue number in my Pull Request.
[ X] I have commented my code, particularly in hard-to-understand areas.
[ X] I have created a helpful and easy-to-understand README.md if it's a new page/tech stack.
[ X] I have gone through the contributing.md file before contributing.

Additional context (Mandatory):
Are you contributing under any Open-source programme?

[X ] I'm a GSSOC-EXT contributor
[ X] I'm a HACKTOBERFEST contributor

@Anuj3553 this PR doesn't get merge is there something wrong with it or its under review ?

Well done @Sawan-Kushwah


Update live to 0.39.0

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 9 committers have signed the CLA.:x: femiagbabiaka:x: cristiangreco:x: paulojmdias:x: mtt88:x: Scott McCracken:x: vkobets:x: thomaspeitz:x: ch4rms:x: sedan07Scott McCracken seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


feat: allow users to add new pages

Extend the page list view with a floating button that adds a new page to the list

Appends page always at end of list
Selects and focuses new page for editing

Usefulness very limited via https://github.com/meetalva/alva/issues/387, let's tackle this next
Fixes #24

Screencast

@marionebl Nice one! Is there a reason why Undo/Redo Operations do not work for renaming and creating pages? I think we should support that, too. Or what’s your opinion?

Update: As the delete-page function is not built for the moment, an Undo/Redo does not make a lot of sense. The renaming issue with the files will be done in a separate PR.


Add 300+ missing Emoji

With this pull request:

Rumoji supports all the emoji displayed in the standard iOS/OSX Emoji selector
Rumoji is now fully compatible with tools like https://github.com/needim/wdt-emoji-bundle
Some miscategorized emoji were moved from Symbols to the appropriate categories.

Awesome! Thank you! 👍


[devcenter] pass mypy 1.0.0

Adding type hints where mypy asks for them so devcenter can pass with mypy==1.0.0. This is already fixed in the python generator (https://github.com/Azure/autorest.python/issues/1764) and will include hints upon next generation.

API change check
API changes are not detected in this pull request.


Radial annotator - Ctrl + C

Ctrl + C (copy) standard windows behavior is overwritten with some navigation, which is very inconvenient. Could you please do not overwrite standard Windows shortcuts.

What is this linked to currently?

one of the sectors, I believe Confidences.

it actually jumps between citations and confidences.

@jlpereira leave the 'c' for Citations.  Change to confidences to "n" if it is free.
Then, if, any annotator form is open, disable the pie-switching keys.

I am using Ctrl-C inside annotor.

Not before you are opening a form, there is nothing to Ctrl-C, is there?

true

Ctrl + C (copy) standard windows behavior is overwritten with some navigation, which is very inconvenient. Could you please do not overwrite standard Windows shortcuts.

It isn't overriding Ctrl+C
Radial annotator has a function to navegate between slices using the first letter of the slice. So if you press "C" it will open "Citations", if you press again, it will open "Confidence" or whatever slice is present for that object. Shortcuts are disabled when the focus is on an INPUT or TEXTAREA element. But clearly we need to change this and use a key combination to avoid problems like this.

Changed to key combination:
Mac: Ctrl + First letter of the annotator
Windows/Linux: Alt + First letter of the annotator


Fix #2013: Make testSuite a cross-compiling project.

Review by @sjrd

That's all for now, though I skipped Build.scala for now.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2429/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3151/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2431/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3153/
Test PASSed.

That's all.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2433/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3156/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2436/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3159/
Test PASSed.

LGTM