Guidance on objects being instantiated before application:didFinishLaunchingWithOptions:... where, when, or how should services be set up?

Many services offer iOS SDKs that require the app to set the SDK up with a one-line class method call early in the application. e.g.: Parse's initialization looks like: [Parse setApplicationId:@"<your app id>" clientKey:@"<your client key>"];.
These often go into the -application:didFinishLaunchingWithOptions: method of your XXAppDelegate.
When using Typhoon, it sometimes makes sense to inject components that make use of these services. The problem is, it's possible that these components are instantiated before -application:didFinishLaunchingWithOptions: even has a chance to execute. For instance:
@interface MYAppDelegate ()
@property(nonatomic, strong) InjectedClass(MYComponentThatNeedsParseSetUpBeforeInitialization)component;  // !!! calls to Parse made before Parse is ready
@end

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

    [Parse setApplicationId:@"<your app id>" clientKey:@"<your client key>"];

    // Parse is ready here.

    return YES;
}

So officially, where should these calls go instead?

We could debate creating a hook for this in either the AppDelegate:
- (void)typhoonWillStartUp; //for want of a better name

or TyphoonAssembly:
- (void)assemblyWillAssemble; //or something

but what I currently do is create a category on the framework class and use:
[definition performBeforeInjections:SEL];

If you wish you can use performBeforeInjections:parameters and have the parameters come from TyphoonConfig

another options:

Create some "wrapper" for Parse static calls (for example ParseManager or something), then create definition for that wrapper with singletone scope - after you can inject that wrapper into your component that need Parse. (i.e. explicit dependency)

<-- Useful when not too much objects requiers parse at startup

Create definition for class that conforms to TyphoonDefinitionPostProcessor. This definition would be registered as factory "post-processor". All "post-processors" runs at very start, before singletons creation.
Then you can do all your configurations that need to performs at very start inside postProcessDefinitionsInFactory: method

<-- Harder to read and understand (implicit) but usefull when too much objects requires one dependency (for example logging system like cocoalumberjack)

And one other existing way folks do this is create a definition that uses @selector(class) as its initializer. Eg:
- (id)loggers
{
    return [TyphoonDefinition withClass:[DDLog class] configuration:^(TyphoonDefinition *definition) {
        [definition useInitializer:@selector(class)];
        [definition injectMethod:@selector(addLogger:) parameters:^(TyphoonMethod *method) {
            [method injectParameterWith:[self ttyLogger]];
        }];
        definition.scope = TyphoonScopeSingleton;
    }];
}

This definition above has singleton scope, so will be run on startup. It won't be guaranteed to run first though, so take care. (Subsequent components that depend on this could have TyphoonScopeLazySingleton, TyphoonScopeWeakSingleton, TyphoonScopeObjectGraph (default) or TyphoonScopePrototype).
Questions:

Given all of these approaches do we need a standard approach? Or is it OK to be creative? Perhaps extract a wiki page and link it from the 'configuration' section of What can be Injected ?
Will the hooks suggested above add more value than the complexity they introduce?

@jasperblues Thanks for the response. I'll try the latter approach out. I'm comfortable declaring [Parse class] as singleton. It works best with my mental model of Typhoon. It is a bit strange of course, given that Typhoon focusses on handling objects and configuring instances as opposed to Class objects.

Which to people like:
- (void)typhoonWillStartUp; //for want of a better name
``

or TyphoonAssembly:

```objc
- (void)assemblyWillAssemble; //or something

or The way shown above using the 'class' as the initializer along with the ability to set order or instantiation?
My preference is the 2nd: asssemblyWillAssemble

Yeah I imagine the latter is better. Parse is a dependency; and therefore falls under the remit of — guess what — a dependency injection framework like Typhoon!
So I actually see that Typhoon will recommend not one, but two potential implementation options:

the super-quick cut-and-paste solution: -assemblyWillAssemble execute prior to instantiating any components in that assembly. Paste code from -application:didFinishLaunchingWithOptions: and we are done. Fantastic. The downside to this implementation is of course that API key's and other bits of configuration can't get injected.

the "But I want DI to inject my configuration, dude" solution:  so if the developer is bothered enough then they can use the [definition useInitializer:@selector(class)]; approach

I would stress that both options need to be clearly documented so that the developer has a chance of picking and choosing what's suitable for them at the time. The second option is the 'correct' way to set it up, but requires knowledge of Typhoon and is premature abstraction.
into the call. I can imagine using preprocessor macros inside of  -assemblyWillAssemble:
NSString *apiKey
#ifndef DEBUG
apiKey = @"PRODUCTION";
#else
apiKey = @"PRODUCTION";
#end
[Service setUpServiceWithApiKey:apiKey];

This works just fine, of course. I think -assemblyWillAssemble could be an answer.
In the ideal world DI should be used to inject API keys as well. . This needs documenting.
What do you think @jasperblues?

@fatuhoku
The problem with [definition useInitializer:@selector(class)]; solution is that you cannot control when time when it's performed. I had that problem using this approach, some of my singletones tries to use logging system which was not initialized yet.
Maybe we can extend API or something... After that we could recomment that as 'correct' approach

Having eg [definition setIntantiationPriority:1]; //default is 100 . . allows fine grained control but is messy since it would only apply to singletons. Would have to raise error in an attempt to use this for non-singleton. In retrospect it might've been nice if we had sub-class per scope. eg TyphoonObject (default), TyphoonPrototype , TyphoonSingleton . . this would allow specific properties for that type.
Introducing TyphoonScopeEagerSingleton could work.

Finally I think using assemblyWillAssemble is more obvous is easy to use solution because using priorities is too implicit - hard to read and understand the order.. Also that makes dependencies implicit and hard to understand too.
I prefer these two options:

Make wrapper (as I told in my first answer in this thread) - that makes dependencies explicit
Make assemblyWillAssemble or anything similar - some peice of code that guaranteed to be peformed at start. That makes dependencies implicit but easy to understand, since all in once place

@fatuhoku Would you like push access to help clean up the documentation? It would be really helpful, since the challenges you faced getting started with Typhoon (current features) are still fresh in mind. Meanwhile, you've been involved in discussions on future features.

@jasperblues Yeah I'm not objected to that. I would love to contribute what I know of Typhoon in the form of documentation. I intend to slowly refactor my application to make use of it.

@fatuhoku granted. We really appreciate your help. Its nice to meet someone who cares about good documentation. As it stands now Typhoon is helpful for folks are very familiar with Di from other languages. We'd really like if the documentation was good enough for all folks to benefit.

Please let us know if you make changes so that we can review the technical accuracy and give feedback.

@jasperblues Sure thing. I'll do this on a need-by-need basis. Got a slightly different focus right now!

@fatuhoku I just faced this issue too. Cheated by hooking resolveCollaboratingAssemblies

@jasperblues Ah, look at you, hooking into all those undocumented methods ;)

I found that init method on AppDelegate works perfectly on our needs, like this:
@implementation AppDelegate

- (instancetype)init
{
    self = [super init];
    if (self) {
        [self setupLogging];
    }
    return self;
}

The lifecycle is:

main.m
UIApplication creation
AppDelegate creation <-- init method called here
UIApplication setDelegate called <-- Typhoon created here
UI Loading
Application did finish launching called

I wondered if it still might be beneficial to create the life-cycle method? This would communicate intention to folks. Alternatively we can just add API doc to init, saying it can be safely overridden.

Fantastic. I think that has to be the most straightforward solution of all...

Once the docs have been done, let's badge as 'Ready for Review'. After that we can close off the ticket.

NB, if you add API docs to any Typhoon classes, and commit, they'll turn up on www.typhoonframework.org/docs/latest/api after a few minutes.

Hi all... I encountered this problem in my project, and I'm trying to figure out how the solution @alexgarbarev discussed works?
We're using plist integration, since our entire app relies on Storyboards. With that configuration, we'd like to find a solution to inject a dependency into the AppDelegate (for use during application:didFinishLaunchingWithOptions:).
Would @alexgarbarev's solution work for this? If so, do you think you could provide some elaboration?
Thank you!


Way to enforce PostCSS in .vue style section?

Right now to get the highlight for PostCSS it is required to set
<style lang="postcss">

Is there a way to enforce postcss parsing in *.vue style section?

eslint-plugin-vue already has something like this: https://eslint.vuejs.org/rules/block-lang.html#vue-block-lang
For a template with set up ESLint with Vue, see https://github.com/sethidden/vue3-eslint-stylelint-demo

We have tried to support this before, but we ended up dropping support it due to it's too many hacks. (#134)


[bug] Depth camera sees through walls

Under some conditions - bump into the wall and look diagonally, depth camera can see through walls.
Look up and down are NOT used here.
How to reproduce:
python3 -m minos.tools.pygame_client  --width 512 --height 512  --depth -s map --navmap --scene_ids 87f009ce2c904df0f0b75433611e74bf
And here is video of where to go:
https://drive.google.com/open?id=16Y6OSGX6HlCcktCYHaLPWyRwRNKhfxNE

Meaningful discovery. This greatly harm the performance of model. Looking forward to bug fixing.

Thanks for reporting this.  Did you observe this for other sensor types?

One thing you can try is in sensors.yml, setting the near for the depth to 0.001 (instead of the current 0.1 which is different from the other sensors).

@angelxuanchang I use only depth and RGB, so cannot say for other sensors.
Regarding threshold - I will try, but it makes problem even worse, because I would like to use challenging conditions -  "kinect" noise model, which clips depth at 0.5 > 0.1.

Please give it try and let us know if it fixes that issue and if it causes other problems.  I think we set it higher for some reason (but I can't really remember why).  For simulating kinect noise, it may make sense to clip afterwards.

@angelxuanchang yes, it helps! Thank you a lot!

That's great!  Let us know if you see other problems.  Also make sure to set the noise: true to use the simple depth noise model.  Feel free to also add your own noise models. :-)

@ducha-aiki The issue you were observing is due to the larger default near plane setting (0.1) of the depth sensor relative to the color sensor (0.001).  Thanks for reporting this -- it is indeed quite important to set the near plane distance to match.  Cutting off for near and far depth distance thresholds can then be done in the noise model functions instead.


nn.PixelShuffle的pytorch到tflite

How to convert nn.PixelShuffle from pytorch to tflite？

@douzaikongcheng
In order to expedite the trouble-shooting process here,Could you please fill the issue template,
Thanks!


"Re-Center on this contact" link broken in lightning

Issue
Clicking on "Re-Center on this Contact" in the Relationship Viewer on a Contact record, results in an error, reading:
Page REL_RelationshipViewer does not exist
Cause
In the Relationship viewer page, "Re-Center on this contact" link looks to be using relative URL rather than the URLFOR function.
Workaround
None currently available

**lurch: add

Tracking W-020124

Salesforce has determined that this issue will not be explored further.


Tracking Item Provenance

Background
Many applications wish to be able to track detailed information about the source data and production algorithms which have been used to produce the data in this Item.
We need to balance this requirement between keeping it simple while still having enough details to be useful.
Tracking Data Sources
A simple way to track source data would be to include additional links in the existing links section of Items, using new rel attributes, and potentially new type attributes.
New rel names:

derived_from
This would provide a link to the exact Item or set of Items that this used as input data in it's production.
Extras:

It can be useful to indicate a bit more information about what the source item is, or how it was used. One way of doing this would be adding a type attribute on the link. In HTML this is typically a MIME type, but we could simply use descriptive text. We could also use a different attribute name.
Do we want to provide hints about whether we're linking to STAC Items (Ideal!) or some other type or resource?

software
A link to a Git repository or other useful link to software used when producing this data.
Options:

Do we need a way to represent a specific version of software. Could be extra attributes on the link, or simply providing a more specific href.

Example
{
    "links": [
        { "rel": "self", "href": "https://www.fsa.usda.gov/my-real-home/naip/30087/m_3008718_sw_16_1_20130805.json" },
        { "rel": "root", "href": "https://www.fsa.usda.gov/programs-and-services/aerial-photography/imagery-programs/naip-imagery/catalog.json"}

        { "rel": "derived_from", "href": "https://ga.gov.au/sr/surface-prod-askj2ka/item.json",
          "type": "surface-reflectance"},
        { "rel": "derived_from", "href": "https://ga.gov.au/sr/surface-prod-KKaslkn2/item.json",
          "type": "dsm" },
        { "rel": "derived_from", "href": "https://ga.gov.au/sr/surface-prod-KKaslkn2/item.json",
          "type": "dsm" },
        { "rel": "software", "href": "https://github.com/GeoscienceAustralia/fc",
          "sha": "v0.6.2"}
    ],
}

Storing detailed information about data production (Optional Extension)
In some cases even more detailed information might be desirable. This is a quick placeholder example, but needs a lot more work before being included as a STAC Extension.
{
    "production_information": {
        "software": {
            "href": "https://github.com/GeoscienceAustralia/fc",
            "sha": "v0.6.2"
        },
        "environment": {
            "machine_uname": "Linux r1561 3.10.0-693.17.1.el6.x86_64",
            "hostname": "r1561",
            "pythonversion": "3.6.5 | (default, Mar 29 2018, 23:19:37) [GCC 4.8.2 20140120 (Red Hat 4.8.2-15)]",
        }

    }
}

The dataset group was talking about that, too. We have not really thought that out, but were thinking of something like that:
Process graph extension (pg) - Items and Datasets

Element
Type
Name
Description

description
string
Description (required)
Detailed multi-line description to fully explain the processing step. CommonMark 0.28 syntax MAY be used for rich text representation.

chain
object
Process chain
TODO: Could be similar to the openEO process graph.

I would like to use the processing chain/provenance standards, once they exist, within the Earth Engine catalog - not just for obvious provenance-displaying purposes (at both dataset and item levels), but also for error representation. Specifically, when a final EE asset is missing due to an error at one of the previous steps that I can track, I'd like to display it to the users (and eventually build some tools for summarizing/fixing the issues). Not sure whether this fits into ARD, STAC, or both - the upshot is that I would like to have a detailed provenance standard for operational purposes.

I agree that in an ideal world someone else standardizes provenance, and we just incorporate it. Especially a detailed provenance model.
But I do feel it's so important to get right as we move to the cloud, that I'd like to see us at least have a couple of tags that point the right way. And I think the ARD stuff is moving slower than we need it.
I do agree with the measure of what's in STAC as 'is it part of the discovery process'. But I think being able to do a search of images derived_from a particular landsat scene is incredibly valuable, and something that has been missing in the geospatial world.
I also think the 'links' section of STAC should be very welcoming, as good links will enable future crawlers to be a lot more effective.
So I do think we should put the data production information in its own repo - draw that line to not be STAC (though happy if people from here collaborate on it, and it's a set of work I very much want to see). But I think the 'derived_from' STAC extension that describes the use of that link makes good sense. And I think I'd include the 'software' link in there too.
@simonff and @omad  - I can start a repo for you under RadiantEarth github if you want a neutral place to collaborate on processing chain stuff.

I like the idea of a processing chain extension, but in the meantime I think a simple accepted way of defining parents (ie derived_from) in the links is a good way to start.  Just having that ability to created derived products and easily be able to follow links to what items were used to generate it is extremely useful.

I also would like to have derived_from adeed to the spec. Depending on the level of detail this could be an extension/profile or not. Just linking to derived datasets could probably be just be in the core, but if we add things like software etc. it sounds more suitable to make it an extension/profile.

Cool. 1 field added sounds good. I'm inclined to just put it in 'core', especially since it's not required, and it's no change to the json schema, etc. It's just a particular type of link that we mention as being useful.
@hgs-msmith - does that sound ok to you? Or you want it in an extension? Or feel it shouldn't be in at all?
Anyone up to make a PR? Would also be great if we can get a catalog that shows it, even just a mini-catalog sample. @omad - can you share your catalogs? Would be psyched to add one or two to our implementation list whenever you're ready, and hopefully they show this. Would be great for stac-browser to also display that link. cc @mojodna

Elaborating on my earlier comment...
Imagine for a moment that an ARD standard exists, and that as a result ARD defines many standard processing chains and that each has a unique identifier (let's call it an ARD-code).  Because it's a standard, everyone knows (or can easily look up) the detailed definition of the processing chain via its identifier.  For purposes of data discovery, I need only designate the ARD-code(s) as part of my search filter if I care about only receiving results that satisfy my provenance requirements.
The obvious analogy is EPSG. If I care about the CRS and I want to define it as a search filter, I need only use the EPSG code(s) rather than define the entire projection/CRS in my search and in my STAC data records.
This is what I meant by a "label for a provenance claim".
Back to reality for minute - it will be quite some time before ARD can do this for us. In the meantime, if the group feels there is value in a "derived_from" tag, to support data discovery, I'm OK with it. I just don't want to see us go down the path of defining a whole schema for provenance within STAC.

I think core is fine, it's not even a new field, it's just a type of rel link. I think in core we need to enumerate a list of possible rel links. It doesn't even need to be a complete list, but something for providers to go by so they don't just make it up.
I agree with @hgs-msmith's sentiments overall, but for now could really use a standard rel value for creating links when creating derived items.

Ah, that's a good point @matthewhanson - that list of possible rel link values was one of the things I was hoping for from the sprint, but focused people more on the asset types. Just made #191 for that.
And sounds like we've reached good consensus. Definitely agree with @hgs-msmith's points and they're in line with how I was thinking about it. We put in the minimal amount of 'link' relationship in STAC, for data discovery. And hope for someone to do more robust stuff. And I like the idea of the ARD-code.
PR welcome, or I'll try to get to it today...

I came across this thread late as I'm just looking at STAC for a project we have in gestation. Coming from an ISO background I have to say I find the web first approach very refreshing!
I had a specific question though about provenance modelling (and I fully accept the distinction between discovery and use metadata and the polluting effect of the latter on the former).
Anyhow, has anyone in STAC community considered the W3C prov model for provenance capture. Its done a lot of the hard work and  theres a JSON encoding to boot.. ?

Thanks for the positive words @6footdestiny!
I looked at w3c prov a bit and it looked quite promising. I do have questions about how widely used it is, do you have any insight on that? It seems to be a 'group note' status from 2013, and hasn't advanced to 'recommendation'?
We definitely do not want to re-invent a full provenance model, and do not see that in scope for STAC. But we wanted to emphasize that it was important to us, so just added the single field, keeping it as minimal as possible. Ideally we find / collaborate on a good provenance model and are able to just reference it's use, and replace derived_from with something from there.
What I'd love to see is a STAC extension that shows how to use the w3c prov model in JSON with common geospatial constructs. Indeed a lot of the interest from the STAC group is how to represent programmatic processing (generally on cloud environments) as part of the processing, and to track that provenance. From what I've seen w3c prov examples seem more about people / scientific provenance, though it does seem flexible enough for machine stuff. But I think there are lots of little quirks of geospatial processing, so some fleshing out of how to exactly use the w3c prov for STAC seems necessary.
I imagine before long we'll have a sub-group of interested STAC collaborators take on provenance, and they'll look at all the use cases and the candidates out there, and I definitely think w3c prov is the top of the list.

@cholmes I don't have any specific intel on the adoption rate of Prov although I know from colleagues in the UK academic sector that were involved in it that there is still active repo updates for software implementation (python) (see https://www.software.ac.uk/who-do-we-work/provenance-tool-suite).
The prov model was designed for scientiofc workflow in mind albeit at an abstract level to permit wider application across domains and use cases. So I think its rich enough to support the STAC use case. The only alternative I'm aware of is the ISO 1900 series lineage model which is perhaps similarly broad and whilst it hails from the geo domain I don't feel (IMO) that its that widely adopted. For my sins I sit on the ISO 19165 drafting committee which is aimed at long term preservation of geo assets. Its heavily modelled around the full ISO standards stack but is being driven by an EO use case (at least 19165-2 which is an extension of the core 19165 model is).
So, basically you have W3C or ISO as possibles or some other 'lightweight' new alternative (in many respects STAC  is an new wave approach to 19115 and corresponding CSW preoccupations that date almost to pre-web origins and have significant traction in things like INSPIRE (Europe) and GCMD/NAP in US). Personally, I think the XML centric and dense formalisms of ISO have proven somewhat counter intuitive to a web-first philosophy and are now suffering from some kick back - hence the Spatial Data for the Web charter.  I do concur that reinvention is to be avoided. Prov might be the answer as it has JSON flavours but ultimately it will fall to how many folks actually adopt and use it voluntarily. ISO has been a struggle in UK and its only legislation that effectively mandates its use  that has forced any headway.. and even then to most folks its overkill.
Anyway, happy to contribute. I'm involved in a project that will need to adopt something so I'm interested to see what evolves....


Support mainnet or testnet addresses on any derivation path

I don't believe there's an immediate rush for this feature, however inline with the expected behaviour of our addressing conventions, we do need to be able to specify network in addition to derivation path.
This could be in the form of an additional flag passed to the device.

To add to this, I don't believe I'm able to generate testnet address even with the testnet path. Using m/44'/1'/0/0/0 still returns mainnet addresses.

Hi @kyranjamie. so if I understood well, we want to generate a testnet address for any derivation path. Your idea is passing a flag for such a case, right? can you elaborate a bit more?

Hi @neithanmo, yeah that's pretty much it. From a consumer point of view:
Here's what we have now:
sign(path: string, message: Buffer): ResponseSign
here's what we're after
sign(path: string, network: 'testnet' | 'mainnet', message: Buffer): ResponseSign
Stacks doesn't follow BIP-44 exactly, which is why we need this behaviour.

his flag or network information is already part of the transaction structure,, isn't it?
so with this new flag, should we ignore the one in the transaction?

Good point. If we can infer chain from the tx, and keep the API as it is now, that would be great.

I think, this line sets the transaction version number. I did the next two experiments:

const network = StacksTestnet, and  same derivation  path
I got:

then:

const network = StacksMainnet(), keep using the same path at it is in the example, and got:

Not sure If this is the expected behavior. I guess ST stands for testnet and SP for mainnet ??

Sorry @neithanmo sign wasn't particularly demonstrative of this issue.
Consider the address generation methods, such as showAddressAndPubKey. Currently it only accepts a derivation path. Ideally we need a signature like showAddressAndPubKey(path: string, network: 'testnet' | 'mainnet').

Ok, I see that function. Yes, It seems that we can not generate a testnet address there.  I am not well versed in JS, but maybe we can define an overloaded function, and have another backend function on the ledger internal side, that allows us to pass in this flag. let me dig a bit more at what we have internally, and how we can overcome this issue.

as an update. #55 is a wip that addresses this.


network issues guide addition

https://twitter.com/quinoa1990/status/968907419328839680

In the doc give credit to OP for the suggestion!


Doest install requirements

Provide more information on the error.

No description provided.

Got same problem, solved installing microsoft build tools


Fix CI (don't use 26.2.5 on Windows; be strict when comparing versions)

Description

remove Windows 26.2.5 from tests: (resolved) <IP_ADDRESS> is not installing properly, but the action's CI shouldn't be affected for this.

properly simulate version-type strict when required to not have e.g. 27.0 identify as (recently released) 27.0.1 when that's unexpected.

Motivation
The motivation for this change was the report in #298, which made me look into why we had issues with version resolution. (issue is not in code, but tests' expectations)

[x] I have performed a self-review of my changes
[x] I have read and understood the contributing guidelines

This is part of https://github.com/erlef/setup-beam/releases/tag/v1.18.1.


Fix typo for {trackedTimeToday} replacement

When using a format string, BreakTimeToday is used instead of TrackedTimeToday for {trackedTimeToday}. I have not uploaded a rebuilt binary.

@dominikbraun hi, is this deployed?
I installed timetrace using homebrew and I still have this problem when using the tool with Starship.
The last release that I see has happened before this merge, so maybe


logo

We need logo and icon for oraganization.#55

haywire logo

psd https://monosnap.com/file/QTQamPqnVu1F8SMsVAAI7vn5oqhyYM.png
logoist https://monosnap.com/file/brDdHdCsYkxQ5lBN6LGCKVchdpDg3h

We need more better logo...

I have some idea.

This logo featuring a nib.

Or like this?

This is based on first idea.

@uetchy Oh, Thanks.
I like this https://github.com/textlint/textlint/issues/56#issuecomment-160050653
フォントのバランスが一番しっくりきました。

@azu OK. I attached a .sketch file contains all those logos.
https://www.dropbox.com/s/265wbvlwsuk0yel/textlint-logo.sketch?dl=0
You can use this file to modify logo for adapting to any situation.
Also you can modify fonts if you don't have Avenir and Avenir Next.
If you don't have Sketch, please tell me and I'll convert the file into any file format you want.
Or should I push .sketch file to somewhere on Github?

@uetchy Thanks. (I didn't have Sketch, I installed sketch trial ver)
I created textlint/media repostiory and invited @uetchy to textlint org!
if you will, please pull-request logo to this repository.
Similar approach:

power-assert-js/power-assert-js-logo
jser/media

Thank you for inviting me to textlint team!
I joined on textlint/media and created PR for logo draft.
Please check this out.

https://github.com/textlint/media/pull/1 is merged and close this issue.

Thanks.


api syntax fix

Hi,
There is typo in MultipartResource class name which breaks the API.
It would be great if it could be fixed in the master version. :)
All the best,
Istvan

Thanks @szeist

Hi @aaronweaver @szeist, greatly appreciate the PR, but I believe it was correct as is. Please this for other multipart examples http://stackoverflow.com/questions/25182131/multipart-form-data-post-put-patch-in-django-tastypie

If you saw my deleted comment. Never-mind! scratch that. I misread the files. Thank you @szeist! greatly appreciated.


'npm install "package-name@>=version"' redirect npm install output to file named 'version'

Prerequisites

[X] Write a descriptive title.
[X] Make sure you can repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
I think I found a problem installing the npm package with at least X version in PowerShell.
When you run this command in PowerShell 7.2.5 or PowerShell 7.3.0-preview.6:
npm install<EMAIL_ADDRESS>Instead of installing express with at least 5.0.0-beta.1 version installs the latest stable version (4.18.1) and redirects the output to a file named "5.0.0-beta.1"
I also tested that in cmd, and it works as expected -<EMAIL_ADDRESS>is installed.
Expected behaviour
`npm install<EMAIL_ADDRESS>should install<EMAIL_ADDRESS>or newer version

Actual behaviour
`npm install<EMAIL_ADDRESS>installs the latest stable version of express<EMAIL_ADDRESS>at the time of writing this text)
`npm install<EMAIL_ADDRESS>creates a file "5.0.0-beta.1" with the content of npm install output

Error details
In this scenario, PowerShell does not return any error

Environment data
Name                           Value
----                           -----
PSVersion                      7.2.5
PSEdition                      Core
GitCommitId                    7.2.5
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

For preview:

Name                           Value
----                           -----
PSVersion                      7.3.0-preview.6
PSEdition                      Core
GitCommitId                    7.3.0-preview.6
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

I think I was too fast with raising the issue here. Yarn install works as expected.
yarn add<EMAIL_ADDRESS>installs<EMAIL_ADDRESS>

Closing at that was npm issue. Seems to be fixed in<EMAIL_ADDRESS>


[main] Upgrade to latest dependencies

Cron -knative-prow-robot
/cc knative-sandbox/kn-plugin-operator-approvers
/assign knative-sandbox/kn-plugin-operator-approvers
Produced by: knative-sandbox/knobots/actions/update-deps
Details:
bumping knative.dev/operator 0c54e49...009492b:
  > 009492b Change the version to resume the development (# 1005)
  > 7c8756d upgrade to latest dependencies (# 1004)

/lgtm
/approve


Can't build/install/configure multiple copies of the client

Currently it's difficult and/or impossible to build / install / configure multiple separately installable copies of the client, for different pods.  While the earlier dmg distribution allowed this (albeit with some build hackery), the pkg distribution does not appear to support the same capabilities (albeit I've only spent about an hour attempting to hack this up).
This is an issue for anyone who wishes to have different copies of the client installed simultaneously for different pods, which is typical for both Foundation members (who will typically have access to the ODP as well as their production pod) and Symphony's enterprise customers (who have a test pod and a production pod).

if you want to build dmg, it is all still there, we just plan on supporting only pkg format.  if you want to build dmg, then do these two at the cmd line:
npm run prebuild
node_modules/.bin/build --mac

How will users install multiple copies of the application, for different pods, simultaneously with the supported pkg format installer?

Also, the commands above still emit an installer (albeit in dmg format), not a raw .app file.
To clarify, the end result I'm looking for is two .app files, each of which is configured to use a different pod.  I don't mind if that's achieved via a pkg or a dmg file or anything else.

we have never supported that in the past.  not something our typical customer wants.  there are ways around, you could manually edit the url in symphony.config file.

As mentioned above, most Foundation members and all of your enterprise customers have this requirement.

if you look in the dist directory, you will see Symphony.app (next to the dmg).

And how do I create a second .app file with a different name, configured against a different pod?

just copy the Symphony.app and rename to Symphony-xyz.app and edit config file as above.

Where "as above"?

four comments above :-)

you'll might also run into another issue...  only a single instance of the app can run at a time.  this is because we have a protocol handler implemented and it would be confusing otherwise which app to invoke, likely causing lots of confusion.  so if you need to run multi-instances simultaneously, then we might have to provide some way to work around this.  if you are building yourself anyway, you could just turn off by modifying code here: https://github.com/symphonyoss/SymphonyElectron/blob/master/js/main.js#L44

That seems a tad involved for end users who have this same requirement (i.e. Foundation members & all of your enterprise customers), surely?

So here's (part of) a script that seems to work correctly:
sed -i .bak 's/if (!isDevEnv \&\& shouldQuit) {/if (!isDevEnv \&\& shouldQuit \&\& false) {/g' ./js/main.js
rm ./js/main.js.bak
npm install
npm run unpacked-mac
cp ./dist/mac/Symphony.app/Contents/config/Symphony.config ~/tmp/Symphony.config
jq '.url="https://foundation.symphony.com"' ~/tmp/Symphony.config > ./dist/mac/Symphony.app/Contents/config/Symphony.config
cp -R dist/mac/Symphony.app /Applications/Symphony-Foundation.app

The last two lines can be repeated for each pod that needs to be configured into a separate binary (with a different target name in the cp command).

(apologies for close/reopeon - accidentally clicked the wrong button)
Any updates on being able to simultaneously run multiple instances of SymphonyElectron against different pods?
As of rev 04c5b8d the workarounds above are no longer sufficient - running a second copy of SymphonyElectron causes the first running instance to terminate.

@VikasShashidhar please assist peter here, thanks.

@pmonks We are looking into this. Will update you soon.

Any updates on this @VikasShashidhar ?  I've been tracking the latest commits and this issue persists (starting a second copy of the Symphony app causes the first one to terminate).

@pmonks The latest builds don't have this feature yet. Although we have some leads, there's no easy way to implement this. @lneir and I will be having a discussion with Thibaud regarding this today. Will update you after our discussions.

@pmonks We are waiting for Thibaud's inputs for this. Will update you.
CC: @lneir

Thanks @VikasShashidhar.  I am still able to build multiple binaries using the tricks described above, but continue to be unable to run more than one of those binaries at a time (running a second one causes the first to terminate).

As of rev 99f3f86 this issue has gone away.  I'm again able to run two copies of the client in parallel, configured against different pods using the config file hacks described above.

As of rev 992503e this issue is back again.

@pmonks We'll take a look at this.


Fix #3062

What does this PR change? What problem does it solve?
Fixes invalid context in parallel repacking code.
Was the change discussed in an issue or in the forum before?
Hopefully closes #3062
Checklist

[x] I have read the Contribution Guidelines
[x] I have enabled maintainer edits for this PR
[ ] I have added tests for all changes in this PR
[ ] I have added documentation for the changes (in the manual)
[ ] There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
[x] I have run gofmt on the code in all commits
[x] All commit messages are formatted in the same style as the other commits in the repo
[x] I'm done, this Pull Request is ready for review

Thanks for the really quick response and diagnosis!
Is this ready for review?

Is this ready for review?

It is.
Just write if this needs a changelog entry.
I'm wondering why this wasn't covered by tests so far - if I find some time, I can have a closer look and add a testcase (but this may take a couple of days..)

Ah, since it's a fix for a not-yet-released feature I think it's not relevant to add a changelog entry. I can confirm the PR fixes the issue.
It feels to me that the big part in the middle of the function could be extracted to its own function, thereby making the scope of the context object more obvious, but that'll do for now.
It'd be great if you could look into how we can test that. I think we don't have integration tests which run a real prune on a real cloud backend yet...

It'd be great if you could look into how we can test that. I think we don't have integration tests which run a real prune on a real cloud backend yet...

@fd0: I was still a bit irritated about why this error didn't show up in the tests. I thought - despite you telling me - that it wouldn't matter if this is called with a local or a cloud backend as in both cases we will call some backend methods with a cancelled context.
So I took some more time to analyze this. Turns out you are right about the cloud backends :wink:  - in the local backend the context is simply unused in almost all methods... Same applies to the mem backend.
So the backends we use in the tests simply do not detect the cancelled context.
I suggest to check for the context in the mem backend which is anyway only used in tests and I am about to prepare a PR. This would have detected this cancelled context (and also reveals some other context issues in the archiver code, which I'm about to fix within that PR).
A second possibility would be to add these context checks to the local backend - either directly in the backend or using the hook @MichaelEischer proposed. But here I'm not perfectly sure about the way to go...

I feared a bit that the archiver code had some context issues. Turned out this is all just in the archiver test code - same problem as here, but with tomb instead of errgroup. I fixed these in #3068.

Great, thanks for taking the time to debug this further.


fix: migrate from k8s.gcr.io to registry.k8s.io

What type of PR is this?
/kind cleanup

Any specific area of the project related to this PR?
/area registry

What this PR does / why we need it:
This PR migrates the image registry from k8s.gcr.io to registry.k8s.io
Which issue(s) this PR fixes:
[Umbrella Issue] Migrate CNCF Ecosystem projects from k8s.gcr.io to registry.k8s.io

Fixes https://github.com/kubernetes/k8s.io/issues/4780

Welcome @CIPHERTron! It looks like this is your first PR to falcosecurity/plugins 🎉

Hi @CIPHERTron. Thanks for your PR.
I'm waiting for a falcosecurity member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: CIPHERTron
Once this PR has been reviewed and has the lgtm label, please assign jasondellaluce for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

This PR is a duplicate of #232. Didn't know it was already there
Hence closing!


BulletRun

Author: Vivaan Shahani (use this as nickname for author of game)
What is your game about?
My game is about thinking ahead and planning out a route to make it to the goal without getting hit by a bullet.
How do you play your game?
Press WASD to move run to the green portal to move on for the next level, avoid the bullets.

[ x] The game was made using the Sprig editor.
[ x] The game is placed in the in the /games directory.
[ x] The code is significantly different from all other games in the Sprig gallery (except for games labeled "demo").
[x ] The game runs without errors.
[ x] The name of the file/game contains only alphanumeric characters, -s, or _s.
[ x] The game name is not the same as the others from gallery

@grymmy > Looked at this game today. Still awaiting author to make changes.
Hi there, thanks for the feedback, I've been bust for the last two weeks but finally made changes. I've added a timer feature and the ability to try randomly generated levels once you finish the game, by pressing K once your done.
Please let me know if this is enough and what I need to do from here
Sincerely,
Vivaan Shahani

Entertaining and challenging game that actually made me stop and think for a second re: how I should proceed at certain points.  Good job!
If you're a teen, and haven't already received a Sprig device, please feel free to fill out this form to receive one of your own!  Additionally, please join Hack Club's Slack and share your creation in the #sprig channel!

@grymmy Hi there, Thank you so much. I filled out the form and it said I should receive a confirmation email. However it's been two days and I still haven't received anything, I was just wondering if you could guarantee my form when through or not. The name is Vivaan Shahani. The email id should be<EMAIL_ADDRESS>Let me know if you need any more info here, though everything should be on the form.


Hhh 10515

Includes the commits from https://github.com/hibernate/hibernate-orm/pull/1264 . Additionally, it covers the case where JDBC DatabaseMetadata is not available.

Hi @gbadner,
it looks fine, my only doubt is in case the DatabaseMetadata is not available if it is better to consider the Dialect supporting or not named parameters.

Merged.


[Code health] Add unit tests for FeatureHelper

I've added all possible cases by looking at the code. PLMK if i've missed any.
@scolsen  PTAL?

/gcbrun

I couldn't run code coverage for this particular test file. Works for the rest of the tests though.


Add Glendale, CA

Feature request
Want to add a new feature to the site? Please describe the requested feature and provide any relevant information:

Thank you for doing this!!

Hi @madelinelazer ,
To add your city, please provide email addressed and an email so we can add it! Check out the guidelines here and submit an new request: https://github.com/defund12/defund12.org/blob/gh-pages/EMAIL_TEMPLATE_STYLE_GUIDE.md
Thanks!


server: change TiKvServer to TiKVServer

Signed-off-by: zhangjinpeng1987<EMAIL_ADDRESS>
What is changed and how it works?

What's Changed:

Typo: change TiKvServer to TiKVServer

Related changes

No

Check List
Tests

No code

Side effects
No
Release note
None

Per https://rust-lang.github.io/api-guidelines/naming.html, if we consider TiKV as a single word, the camel case should be TikvServer instead of TiKVServer

Per https://rust-lang.github.io/api-guidelines/naming.html, if we consider TiKV as a single word, the camel case should be TikvServer instead of TiKVServer

@sticnarf TiKV is a “Distinguished Name”

@sticnarf TiKV is a “Distinguished Name”

That doesn't account for using TiKV in camel case. If we have to keep the original cases in camel case, why we do not in snake case, for example it's certainly  modify_tikv_config instead of modify_TiKV_config.

It's named TiKv on purpose to follow rust naming convention. https://github.com/tikv/tikv/pull/12395

@sticnarf TiKV is a “Distinguished Name”

That doesn't account for using TiKV in camel case. If we have to keep the original cases in camel case, why we do not in snake case, for example it's certainly modify_tikv_config instead of modify_TiKV_config.

both TiKV and tikv are acceptable distinguished name, but TiKv or Tikv is not.

It's named TiKv on purpose to follow rust naming convention. #12395

I think TiKv or Tikv is very ugly.

Close this PR since above oppositions.


docs: fix comparison 3rd party website links

Hey! I noticed 3rd party library website links don't work properly on comparison page . This PR fixes it.

:tada: This PR is included in version 2.22.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Feature/enable exclusion areas

Adds input arguments to allow creation of a filter.
All the pieces individually have been tested, I'm still need to run a full up test with a valid set of filter files.

Can one of the admins verify this patch?

test this please


select example in docs

I am an async noob but the 'simple example' in docs on select may be a bad example.
The example selects one of the futures:
let future1 = async { 1 };
let future2 = async { 2 };

The problem in this is that the computations are both Poll::Ready immediately (at least on my machine).
So the result of the select is always Either::Left, as I would expect from the implementation.
Therefore, the assert! in the example is misleading IMHO.
I would suggest being explicit about one future finishing first.
The simplest example I came up with is here.

I would accept a PR that improves this example.

Thanks @taiki-e! Created the PR #2345


HAWQ-140. Add more information in HAWQ build instructions file

Add more information about instructions building apache hawq.
Change txt file to markdown style for better display on github.

+1

+1


Java in-process agent version to be upgraded

Is your feature request related to a problem? Please describe.
Java in-process agent version deployed is 3.3.1
Describe the solution you'd like
Java in-process agent version should be updated to latest 3.4.4
Describe alternatives you've considered
N/A
Additional context
N/A
@msftgits @xscript

Since App Insights agent has been upgraded in Jan 2023, I'm closing this issue now.


Day ago fix

🗣 Description
#1007 "1 days ago" in domain vuln table

@sramaswami11 can you add a screenshot of the new UI? I didn't mean adding a screenshot of the code; there's no need to do that.

Thanks -- can you also add this fix to DomainDetails.tsx?
https://github.com/cisagov/crossfeed/blob/a70e552308996d7d396c101e331372122ab2fb0c/frontend/src/components/DomainDetails.tsx#L111-L124

The fix is already there:

@sramaswami11 sorry, I meant Vulnerabilities.tsx: https://github.com/cisagov/crossfeed/blob/a70e552308996d7d396c101e331372122ab2fb0c/frontend/src/pages/Vulnerabilities/Vulnerabilities.tsx


Additional context
I first noticed this issue a few days ago on the nixos-unstable channel.
Notify maintainers

@doronbehar @samuelgrf @garbas @msfjarvis @dezgeg @Profpatsch
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.27, NixOS, 23.05 (Stoat), 23.05pre481752.897876e4c48`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.3`
 - channels(mightyiam): `""`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Did you try a relogin? Or reboot?

Had this problem too. Running fc-cache -f fixed it.

@doronbehar Just for completeness: relogin and reboot did not fix it for me as well. The solution by @gaykitty  (run fc-cache -f) fixed it for me as well.

The issue here is that nix profile install doesn't take care of activation scripts like nixos-rebuild and home-manager switch. This is inherited by nix profile's design. I'm not sure there's much that can be done besides perhaps documenting this.

@doronbehar In my case, I did not use nix profile at all - I rebuilt the system from a flake.

I'm not certain that fc-cache -f solves the problem. When I ran it, some codepoints rendered using a font different than I had expected.

Nerd Fonts was upgraded to 3.0.0 which has sweeping changes to what codepoints it places icons in, you may have caught that.

I'm not certain that fc-cache -f solves the problem. When I ran it, some codepoints rendered using a font different than I had expected.

Nerd Fonts was upgraded to 3.0.0 which has sweeping changes to what codepoints it places icons in, you may have caught that.

No, it's not just those code points. It's some English ones.

I'm not certain that fc-cache -f solves the problem. When I ran it, some codepoints rendered using a font different than I had expected.

this fixed nerdfonts not loading on kitty(this was causing to crash when opening with error message fast_data_types.FreeTypeError: Failed to load face from path: /run/current-system/sw/share/fonts/truetype/NerdFonts/JetBrains Mono Regular Nerd Font Complete Mono.ttf with error: cannot open resource) and konsole(probably all programs too)

Would anyone like to have a session with me on this?

I tried reproducing on another machine. And couldn't. fc-cache -f seems to have solved an intermittent issue. But I'm wondering whether fc-cache -f is necessary or would it have occurred on reboot or at any home-manager command?


Automatic versioning

We could use something like setuptools_scm but then we cannot install from the tarballs.
An alternative is using bump-my-version: (https://github.com/callowayproject/bump-my-version/)

that's what the SETUPTOOLS_SCM_PRETEND_VERSION is for - and it's being used by pretty much every single Linux distribution, Fedora, Arch, etc.

How is it to publish new versions with setuptools_scm (and also to publish on Pypi? Do we just need to tag a new commit and there are hooks that do all the work?


iotdb-web-workbench后端0.12.1代码

本代码是iotdb-web-workbench后端0.12.1代码，主要功能如下图：

请审核。

add apache license files

Apache Rat finds some files with missing headers. See https://github.com/apache/iotdb-web-workbench/pull/2#issuecomment-917369842
java -jar ~/apache-rat-0.13.jar .

*****************************************************
Summary
-------
Generated at: 2021-09-11T10:52:19+02:00

Notes: 2
Binaries: 18
Archives: 1
Standards: 107

Apache Licensed: 85
Generated Documents: 0

JavaDocs are generated, thus a license header is optional.
Generated files do not require license headers.

22 Unknown Licenses

*****************************************************

Files with unapproved licenses:

  ./.gitignore
  ./.ratignore
  ./NOTICE-binary
  ./backend/.drone.yml
  ./backend/.gitignore
  ./backend/Dockerfile
  ./backend/README.md
  ./backend/build.gradle
  ./backend/build.sh
  ./backend/pom.xml
  ./backend/settings.gradle
  ./backend/doc/config.md
  ./backend/doc/log.md
  ./backend/doc/maven.md
  ./backend/doc/release.md
  ./backend/src/main/java/org/apache/iotdb/admin/mapper/DeviceMapper.java
  ./backend/src/main/java/org/apache/iotdb/admin/mapper/GroupMapper.java
  ./backend/src/main/resources/application-prod.properties
  ./backend/src/main/resources/application-test.properties
  ./backend/src/main/resources/log4j2-prod.xml
  ./backend/src/main/resources/log4j2.xml
  ./backend/src/main/resources/META-INF/app.properties

*****************************************************

This pull request is closed as the code was merged with PR #3 together with minor fixes.


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>chore(scripts): cover@#overwrite c8 --temp-directory build/tmp ava && c8 report -r lcov -o build/coverage --temp-directory build/tmp
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/*-test.mjs' as in template
chore(package): set $.ava.extensions='mjs' as in template

Coverage decreased (-0.01%) to 40.711% when pulling a7c33854ef68bc6f3742b27fc4f2a5235f34ae27 on npm-template-sync-1 into 2cd23a16d4e46a5539bf5b687550705b73513984 on master.

:tada: This PR is included in version 8.1.62 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Optimize Type collection Logic in OpenApi

Description:
Optimize the type collection logic which is used to generate the service template.

No longer relevant


RangeError: invalid array length

From @seiyria on March 10, 2017 19:10
Short description of the problem:
Whenever I use ionic upload, it fails with this error (during the "uploading snapshot" step):
C:\Users\Kyle Kemp\AppData\Roaming\npm\node_modules\ionic\node_modules\@ionic\cli-utils\dist\index.js:23463
  complete = Array(completeLength + 1).join(this.chars.complete);
             ^

RangeError: Invalid array length
    at ProgressBar.render (C:\Users\Kyle Kemp\AppData\Roaming\npm\node_modules\ionic\node_modules\@ionic\cli-utils\dist\index.js:23463:14)
    at ProgressBar.tick (C:\Users\Kyle Kemp\AppData\Roaming\npm\node_modules\ionic\node_modules\@ionic\cli-utils\dist\index.js:23418:8)
    at Task.progress (C:\Users\Kyle Kemp\AppData\Roaming\npm\node_modules\ionic\node_modules\@ionic\cli-utils\dist\index.js:21613:30)
    at uploadSnapshot (C:\Users\Kyle Kemp\AppData\Roaming\npm\node_modules\ionic\dist\ionic.js:8089:28)
    at Request.superagent.post.field.field.on (C:\Users\Kyle Kemp\AppData\Roaming\npm\node_modules\ionic\dist\ionic.js:8065:21)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at Transform.progress._transform (C:\Users\Kyle Kemp\AppData\Roaming\npm\node_modules\ionic\node_modules\superagent\lib\node\index.js:860:16)
    at Transform._read (_stream_transform.js:167:10)
    at Transform._write (_stream_transform.js:155:12)

What behavior are you expecting?
To be able to upload my app.
Steps to reproduce:

ionic upload

Which @ionic/app-scripts version are you using?
  "devDependencies": {
    "@ionic/app-scripts": "^1.1.0",
    "@ionic/cli-build-ionic-angular": "0.0.3",
    "@ionic/cli-plugin-cordova": "0.0.9",
    "@ionic/cli-utils": "0.0.1-alpha.12e4141f",
    "typescript": "^2.2.1"
  },

Other information: (e.g. stacktraces, related issues, suggestions how to fix, stackoverflow links, forum links, etc)
Your system information:
Ionic Framework Version: 2.2.0
Ionic CLI Version: 3.0.0-beta.4
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Windows 10
Node Version: v7.3.0
Xcode version: Not installed

Copied from original issue: driftyco/ionic-app-scripts#810

From @brane53 on March 14, 2017 21:20
I'm having this same issue and I have no idea how to fix it. Same system information except running node v6.9.2

From @seiyria on March 14, 2017 21:20
I solved this by downgrading, unfortunately.

Hi, the CLI version you were using was ancient.
Also, duplicate of https://github.com/driftyco/ionic-cli/issues/1984


--noEmit doesn't indicate an intent to use ES6 modules

Sequel to #23576.
I don't think it makes sense to view --noEmit as permission to suggest ES6 modules, because any JS project is likely to have --noEmit set.

Yes previously there were quite a few node developers who did not like seeing the suggestion since it would end up breaking their code (if they were not using a transpiler)

Yes previously there were quite a few node developers who did not like seeing the suggestion since it would end up breaking their code (if they were not using a transpiler)

When you say "previously", you mean it is not an issue any longer? or are you still getting feedback about this?
For context #23576 disabled this suggestion for many projects. this change limits it further. wondering if we need to take this change, or we are in a good place with #23576 only.

No, when the suggestion was first introduced I heard a lot about it but I have not heard anything after we restricted when it will be shown with #23576

@RyanCavanaugh Can this please be reviewed? There's no guarantee that noEmit means someone is compiling. There's plenty of useful type-checking options that are gated behind compilerOptions:

tsc can be used to type-check JS files without compiling, but only supports tsconfig.json. Obviously if there's no compiling involved it makes sense to set noEmit to avoid generating output.
noErrorTruncation is not allowed in a jsconfig.json file.
Node 12 has a lot of ES2019 features (but not import syntax without that problematic experimental mode), so setting "target": "ES2019" now has this erroneous suggestion appearing.
Why shouldn't a Node environment be allowed to set "module": "CommonJS" to indicate the module type for type-checking purposes?

The logic around this suggestion seems to be quite negatively-geared against development scenarios where we need to stick with CommonJS due to Node scripting. I absolutely prefer to use import syntax when I'm allowed a compiler to support it, but it's absolutely maddening to be prompted on every file about this when working with Node scripts where I literally can not use the import syntax…


fi CI test

All recent actions fail. Exploring options to solve this. Last tried: https://github.com/docker/buildx/issues/1513

@why-not-try-calmer ok for you?


Document functions v3 for F#

Functions v3 don't support .fsx files. It would be nice to have up-to-date docs.

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

ID: feb56d1a-4b15-05df-a896-d3f7b7c96210
Version Independent ID: 31786b95-1a18-87dc-ec86-c1aa3d95358e
Content: Azure Functions F# developer reference
Content Source: articles/azure-functions/functions-reference-fsharp.md
Service: azure-functions
GitHub Login: @sylvanc
Microsoft Alias: syclebsc

Hi @estensen Thanks for your feedback. We will review and update as appropriate.

@estensen It is already mentioned in the public docs : Because of .NET Core limitations, support for F# script (.fsx) functions has been removed. Compiled F# functions (.fs) are still supported.
See Changes in features and functionality after version 1.x

Yes, this is mentioned, but it would be great with actual examples with running code.

@estensen I have assigned this to content author for further review and update as appropriate.

This is more of a product limitation rather than a docs issue at the moment. Once there is more formal support for Functions v3.x, then we can update the docs to reflect the changes.
#please-close

When Functions v3 is the default I expect all the docs to be up-to-date


[IcSelect / IcMenu]: Add a placement prop to control the placement of IcMenu

Summary
Sometimes, the IcMenu will initially appear anchored to the bottom of an IcSelect while being cut off by the viewport. This ticket to add a placement prop so the position of the IcMenu can be explicitly set.
💬 Description
Clicking on IcSelect while it is positioned at the bottom of a viewport sometimes anchors the IcMenu below even if there is not enough space. As a result of this, the IcMenu is cut off. By having a placement prop, the position of IcMenu can be explicitly set to appear above IcMenu if required. This puts less onus on PopperJS which can, at times, be temperamental when dealing with the viewport.
💰 Use value
By explicitly positioning the popover element (i.e. IcMenu), consumers are able to avoid situations where the IcMenu is being cut off by the viewport
📝 Acceptance Criteria
If relevant, describe in full detail the different interactions and edge cases that the component or patterns needs to fulfil.
Given that I have clicked on an IcSelect
When the placement prop has been set to a particular position
Then the IcMenu should render in that position
✏ Designs
If there's a Figma design file (or other mock-up), include it here.
🧾 Guidance
If there's written guidance or documentation, include a link to it here.
Additional info
This is an issue caused by PopperJS which doesn't happen in all environments so it may potentially be a browser issue.
In the future, there is a desire to move away from PopperJS and use the Browser API for Popover and Anchor. There is currently a ticket to investigate this: https://github.com/mi6/ic-ui-kit/issues/2434

User has asked for this functionality in the Popover Menu component too.
Potential provide two props: "placement" and "fallbackPlacements" which allow users to pass down those things into PopperJS for both IcMenu and IcPopoverMenu


CircleMarker not showing when setting preferCanvas to true in map option

I'm reporting a bug, not asking for help
I've looked at the documentation to make sure the behaviour is documented and expected
I've searched through the issues to make sure it's not yet reported

How to reproduce

Leaflet version I'm using: 1.0.0
Leaflet plugins used: proj4leaflet v0.7.2 and leaflet.markercluster 1.0.0
Browser (with version) I'm using: Chrome (but this can be seen in Mozilla Firefox and Edge)
OS/Platform (with version) I'm using: Windows 10
step 1 check link in minimal example
step 2 use the scroll or zoom in/out buttons

What behaviour I'm expecting and which behaviour I'm seeing

Expected behaviour:  the map zooms in and the object geometries are visible at each zoom level (if not clustered);
Actual behaviour: the map zooms in/out but the geometries disappear (totally or partially) when zooming in / out (the clustering functionality still works)

Minimal example reproducing the issue

using leaflet + marker cluster + svg [ works as expected ]: https://codepen.io/anon/pen/YGLbGq?editors=1010
using leaflet + marker cluster + canvas [ fails to work ]: https://codepen.io/anon/pen/PGZONy?editors=1010
using leaflet + canvas [ no clustering works as expected]: https://codepen.io/anon/pen/wzjbgP?editors=1010

Weird. I can reproduce the problem in FFX in Linux, there is some weird flickering of the circle markers when zooming in and out.
I'm gonna hope this is reproducible without markerclusters, need a simpler test case.

@IvanSanchez well for a simple test case i've added all the points to a geojsonLayer and removed the markercluster, the flickering efect is gone (is this what you wanted ?): https://codepen.io/anon/pen/GjddoV?editors=1010

That's... weird. This one will need more analysis to see what's going on.

ok i think i found what starts the bug, but i don't know why ...
var markersLayer = L.markerClusterGroup({         disableClusteringAtZoom: 13,         animate: false,         spiderfyOnMaxZoom: false,         removeOutsideVisibleBounds: false,         singleMarkerMode: true     });
remove the animate: false; to test use https://codepen.io/anon/pen/XjYGzX and comment line 60

I think this is a bug in https://github.com/Leaflet/Leaflet.markercluster/ then.

Moved to https://github.com/Leaflet/Leaflet.markercluster/issues/727.


Add examples for SYCL Spark

We should consider this a draft, since I'd like your comments. It's useful to have this out here to enable discussion.
Most noteworthy is that the histogram example doesn't compile with the current intel/llvm SYCL implementation because we do not support array reductions (but see https://github.com/intel/llvm/issues/5941)

With the change from https://github.com/UoB-HPC/everythingsreduced/pull/16#discussion_r851307803, the code compiles using the functionality from https://github.com/intel/llvm/commit/863383bac8eeab168f39f4da8e94df860458cbf0.
It doesn't pass the correctness test, but I think that's because nothing here resets the histogram.  The test expects histogram[8] == N, but the behavior I see is that histogram[8] == N * iteration.  Adding property::reduction::initialize_to_identity{} fixes it, but I don't understand why this is necessary -- some of the other benchmarks have this, but not all of them.
@tomdeakin, could you please take a look?  What do you think the correct fix is, here?

@Pennycook All the original benchmarks set property::reduction::initialize_to_identity{} so if it's missing it's likely an oversight in the new benchmarks. That being said, it's up the benchmark to decide how it tests correctness, so if we want to preserve the initial value, that's OK too - it just needs a comment in the header.

Thanks, @tomdeakin.  I don't think I have permissions to modify Jason's branch, and I think he's lost access to his "-intel" GitHub account.... So, I've just added a suggested change to the line that I think needs to be updated.
Do you have permissions to accept the suggested changes?

@Pennycook - think I have those changes in now.
We might want to merge this and #17 into a spark branch in the short term as both these PRs will likely break compiling the other models which don't implement these kernels (yet).

I still have access! I changed the email address before I left. But this looks good and I thank you for making the changes.

All good to merge into a spark branch? I can then merge #17 into the same branch; Im predicting minor conflicts in the driver code but should be simple to fix.

All good to merge into a spark branch? I can then merge #17 into the same branch; Im predicting minor conflicts in the driver code but should be simple to fix.

Sounds good to me.  Thanks again for doing this.  And sorry, @jasonsewall-intel -- I don't know why I thought you'd lost access!


mkcloud: Disable want_ldap checks for known-broken cloud sources

triggered an upgrade gating, after addressing @bmwiedemann it looks good +1

+1

+1


WIP docs-builder

Work-in-progress implementation of https://github.com/polkadot-api/polkadot-api/issues/585.
There're couple of bugs left to fix, but it still conveys the general idea

I'm a bit hesitant to include it as part of the top-level client though, because it needs some polishing and it's something I'm not sure we'll be able to maintain. Would it be possible to have it as a new sub-package? this would also provide a better separation for those who only want one of the features (connect to a chain vs generate docs from metadata).
My idea is to accept the changes in @polkadot-api/codegen's types-builder, because that has some tightly coupling to codegen, but then move the generate-docs-descriptors and the client's CLI changes to another package (maybe @polkadot-api/docgen?) that depends on it.

No objections about separating cli, but generate-docs-descriptors is coupled extremely tight to types-builder and also built as a structural sibling to generate-descriptors, copying entire approach; are you sure that it'll be a good separation from architecture perspective?

Independently from that, something else I've noticed is that this has two steps: generate the TS files with the docs, then generate the actual docs, but both artifacts are kept in the project's folder. I think the TS files should be automatically removed after the docs are generated (or maybe have them directly in a tmp folder), as they are not being used for anything else.

Sure, good point!

Moved cli part to a separate package, but left generate-docs-descriptors in codegen for now


Remove usage of cosign binary [0.4]

There are concerns that some folks may have a copy of the Task definition which would still require the cosign binary in the image. We'll use EC-817 to come up with a different approach.


@mjsax

@mjsax
Is there a possibility that the task will be reflected?
We'll follow up if possible.
Originally posted by @highluck in https://github.com/apache/kafka/pull/8022#issuecomment-647141512

I'm not sure what the question is here? Could you please follow the template for creating issues under the Docker Roadmap? Thank you!

I think this is a typo. I'm going to close it: it can be reopened later if necessary.


Failure to upload code coverage report shouldn't mark the "run unit tests" action as failed

Perhaps we want this behavior, but I've empirically seen transient failures uploading code coverage even when all of the unit tests passed (https://github.com/seattle-uat/civiform/runs/7344962435?check_suite_focus=true).
Could we either 1) make this failure still consider the overall action as successful or 2) add retries?
Initially assigning to @swatkat1 for triage / determining if either option is feasible or worth prioritizing.

Additional note: Retrying the failed task typically succeeds, but adds a few minutes of latency to the overall process.

@swatkat1 --Is this still open?

@elisekalstad - This is no longer an issue. It was an issue with the previous version of Codecov. Also I have made ccodecov as informational only so it shouldn't break the build. This item can be closed.


Crash on older Androids while starting LibsActivity with LibsBuilder (missing FLAG_ACTIVITY_NEW_TASK)

About this issue
The app crashes while trying to start the activity on older Android devices. It does not happen on Android 7.1 and onwards but definitely does on Android 5. What happens in between, I cannot tell.
Here is the code I use to run it:
new LibsBuilder()
    .withActivityStyle(Libs.ActivityStyle.LIGHT_DARK_TOOLBAR)
    .withAboutIconShown(true)
    .withAboutVersionShown(true)
    .withActivityTitle(getString(R.string.licenses_title))
    .withAboutDescription(getString(R.string.licenses_about_libraries_text))
    .start(getApplicationContext());

And this is the logcat from the crash:
E/AndroidRuntime( 2494): FATAL EXCEPTION: main
E/AndroidRuntime( 2494): android.util.AndroidRuntimeException: Calling startActivity() from outside of an Activity  context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?
E/AndroidRuntime( 2494): 	at android.app.ContextImpl.startActivity(ContextImpl.java:942)
E/AndroidRuntime( 2494): 	at android.app.ContextImpl.startActivity(ContextImpl.java:936)
E/AndroidRuntime( 2494): 	at android.content.ContextWrapper.startActivity(ContextWrapper.java:276)
E/AndroidRuntime( 2494): 	at com.mikepenz.aboutlibraries.LibsBuilder.start(LibsBuilder.java:583)

Details

Used library version: 6.0.8 (and 6.0.6)
Used support library version: v7:27.1.0
Used gradle build tools version: com.android.tools.build:gradle:3.0.1
Used tooling / Android Studio version: Android Studio 3.1
Build #AI-173.4670197, built on March 22, 2018
JRE: 1.8.0_152-release-1024-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.9.0-6-amd64

Checklist

[x] Searched for similar issues
[x] Checked out the sample application
[x] Read the README
[x] Checked out the CHANGELOG
[x] Read the MIGRATION GUIDE

Possible fix
I have actually had exactly the same problem with a library of mine: Actually adding the flag like the log says seems to solve the problem:
if (android.os.Build.VERSION.SDK_INT < Build.VERSION_CODES.N_MR1) {
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
}
context.startActivity(intent);

I didn't want to add it for most modern versions, as I know it does work there, but I am just not sure for some of the older ones.
Thanks
Thank you very much for this cool library! :+1:

Actually, I just realised that the most modern Android versions add the flag themselves:
04-13 07:58:26.547  1295  2002 W ActivityManager: startActivity called from non-Activity context; forcing Intent.FLAG_ACTIVITY_NEW_TASK for: Intent { cmp=org.example.app/com.mikepenz.aboutlibraries.ui.LibsActivity (has extras) }

So another option would be to just always add it instead of using the if I proposed in my previous comment.


Testing, please ignore. (hdljxz)

This is a bug bounty test. Please ignore.. Please DO NOT APPROVE THIS! (hdljxz)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.hdljxz qlopd 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.


Pydantic 2.0 Migration / Support

Wondering whether the LS team have a Pydantic 2.0 migration on the roadmap for this year? As you probably know, security + maintenance fixes/support will stop for Pydantic 1.x this year.
At ZenML we're going to be migrating to use 2.x in the coming weeks and since there's a hard incompatibility between the local label_studio since it has a hard pydantic = "<=1.11.0,>=1.7.3" dependency.
I realise that the Python SDK is much more relaxed which probably is enough for us to work around. We'd just have to remove support for running LS locally in our examples / use case and instead suggest people deploy LS somewhere.
I'm wondering, though, whether there is a plan to migrate to Pydantic 2.x. Thanks!

Are there any breaking changes in pydantic2? If no, we will upgrade soon, especially if there are any security issues.

https://docs.pydantic.dev/2.6/migration/ this is the migration guide. If you're not doing anything too fancy with Pydantic you might find that you can run their migration script and everything just works. If you're unlucky, it'll be a bit of work to handle.

Any updates on this?

At this moment we haven't yet switched to pydantic v2.

Got it. I guess you'll be forced soonish in due course. In any case, at ZenML we're strongly motivated by various integrations to upgrade (since they start not working any more, not to mention the lack of bug fixes / security support for Pydantic starting in the next month or two), which means that probably we'll need to remove support for locally running label_studio in the way we previously suggested people do it (i.e. using the label_studio package itself). Our integration mainly uses label_studio_sdk package to interact with the instance, so that part is fine as you have much more relaxed pydantic requirements there. So I guess we'll encourage people to spin up LS with Docker or perhaps HF Spaces as their way to easily get started.


How to use it

Is there a sample way to use this? I also don't see any test cases which would help to use, looks interesting though. Might be interesting to plug in any schema validator to help those projects, I use networknt's validator.

I found this:
https://github.com/vndly/json-schema/blob/master/src/test/java/com/mauriciotogneri/jsonschema/test/TestSchema.java


Firefox isn't working in 1.3.2

Describe the bug
Context: here I wrote the working setup for Firefox with livekit-server 1.2.5 with disabling ice lite.
Here is an (most likely the same) issue with Firefox. Here is fix for it.
Server

Version: 1.3.2
Environment: docker swarm, centos 7

port: 7880
rtc:
    udp_port: 7882
    #tcp_port: 7881
    tcp_port: 0
    use_external_ip: true
    #use_ice_lite: true
    use_ice_lite: false
    #port_range_start: 35200
    #port_range_end: 35400
    #force_tcp: true
    allow_tcp_fallback: false
#room:
#    enabled_codecs:
#        - mime: audio/opus
#        - mime: video/h264

turn:
    enabled: true
    udp_port: 3478

    image: livekit/livekit-server:v1.3.2
    ...
    ports:
      # turn udp port
      - target: 3478
        published: 3478
        protocol: udp
        mode: host

      # turn tls port
#      - target: 5349
#        published: 5349
#        protocol: tcp
#        mode: host

      # webrtc udp port
      - target: 7882
        published: 7882
        protocol: udp
        mode: host

      # webrtc tcp port
#      - target: 7881
#        published: 7881
#        protocol: tcp
#        mode: host

log is attached (132.txt)
132.txt
Client

SDK: JavaScript "livekit-client": "1.6.0",

So I see that existing setup made for 1.2.5 is not working for 1.3.2
To Reproduce
Just connect from Firefox Linux 106.0.4 to the room
After some time (5-40 seconds it disconnects and tries to reconnect)
Expected behavior
Not to reconnect
Additional context
I made the custom build with disabled patch https://github.com/livekit/livekit/pull/1226/files#diff-5c2446a24723d589881637c71008cafa7e3c16159fee094a8ab028eb2a5638bcR261
func (c ClientInfo) SupportPrflxOverRelay() bool {
	return true
}

and it works again.
My thoughts:
Having this long-term weird Firefox behavior, which is not working for some cases -
to make this patch configurable, to make a config option to disable this firefox-related behavior - something like
rtc:
  firefox_prflx_over_relay_patch: false

I know that it is not the best solution, but it will fix my case.

Here is about:webrtc from the different attempt - becasue of this timestamps are different
aboutWebrtc.zip
I see Nominated false and Selected for all the candidates. It has 4 sessions due to reconnect (At the start it was 2 sessions)

How does it look like:
Screencast from 2022-12-27 17-52-41.webm
Related about:webrtc
aboutWebrtc2.zip

cc @cnderrauber

So you disabled the #1226 patch and firefox works well now?

@cnderrauber yes

I have test combination of enable/disable udpmux and #1226 in my test server, found udpmux is conflict with #1226, because we closed the duplicate candidate in 496 to fix the goroutine leak. But #1226 is required for firefox connect to server though TURN, both w/o udpmux. So the issue is we need a solution to fix the udpmux broken by 496 and #1226

@nkonev We need to remove the duplicate candidates from NATMapping, Can you try #1270, and add the ip filter config to you config file, it would solve the issue
rtc:
    tcp_port: 7881
    udp_port: 7882
    ips:
      includes:
        - <IP_ADDRESS>/24 # your private address that mapping to the public address

@cnderrauber
Your https://github.com/livekit/livekit/pull/1270 is working, along with manual adding ip mask, thank you
port: 7880
rtc:
    #node_ip: <IP_ADDRESS>
    udp_port: 7882
    tcp_port: 7881
    #tcp_port: 0
    use_external_ip: true
#    use_ice_lite: true
    use_ice_lite: false
    #port_range_start: 35200
    #port_range_end: 35400
    #force_tcp: true
    #allow_tcp_fallback: false
    ips:
        includes:
#            - <IP_ADDRESS>/24 # your private address that mapping to the public address
            - <IP_ADDRESS>/16

also works with UDP-only
port: 7880
rtc:
    #node_ip: <IP_ADDRESS>
    udp_port: 7882
    #tcp_port: 7881
    tcp_port: 0
    use_external_ip: true
#    use_ice_lite: true
    use_ice_lite: false
    #port_range_start: 35200
    #port_range_end: 35400
    #force_tcp: true
    allow_tcp_fallback: false
    ips:
        includes:
#            - <IP_ADDRESS>/24 # your private address that mapping to the public address
            - <IP_ADDRESS>/16

also works with TCP-only
port: 7880
rtc:
    #node_ip: <IP_ADDRESS>
    #udp_port: 7882
    tcp_port: 7881
    #tcp_port: 0
    use_external_ip: true
#    use_ice_lite: true
    use_ice_lite: false
    #port_range_start: 35200
    #port_range_end: 35400
    #force_tcp: true
    #allow_tcp_fallback: false
    ips:
        includes:
#            - <IP_ADDRESS>/24 # your private address that mapping to the public address
            - <IP_ADDRESS>/16

Some thoughts:
It was hard to guess which one is the correct
[root@selectel videochat]# docker exec -it VIDEOCHATSTACK_livekit.1.ti1haad2y6ulrvlaqhhz01dj5 sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
23402: eth0@if23403: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
    link/ether 02:42:0a:00:04:4b brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
23404: eth1@if23405: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:12:00:1b brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth1
       valid_lft forever preferred_lft forever

So can we somehow reuse the code from rtc/config.go getNAT1to1IPsForConf()
	localIPs, err := config.GetLocalIPAddresses(conf.RTC.EnableLoopbackCandidate)
	if err != nil {
		return nil, err
	}

to automate choosing the appropriate IP ? It would be helpful, it DevOps/Admin isn't forced to search the IP mask manually.

@nkonev we add #1226 because firefox has problem to connect through relay candidate, a user report that and can be reproduced by the test env, unfortunately, it breaks the udpmux case like yours. Need to figure out a way to automatic add the mapping ip instead of add it manually

we'll cut 1.3.3 shortly!


feature request: up metric ?

It would be convenient to have postgres exporter provide 'up' metric.
Just like most other popular exporters do (mysql, redis, etc)
The idea of this metric is that it outputs the value of 1 when there is a connection to postgres and 0 when there is no connection.
Having this metric one could set up an alert on postgres unavailability.
Here is the example from mysql:
# Mysql service not up
ALERT MysqlUp
  IF mysql_up{job = "mysql"} != 1
  FOR 1m
....
...

Does anyone have an idea for a rule to alert when postgres goes down ?

Oh, I thought I replied to this - you need to look at pg_exporter_last_scrape_error which will be 1 when scrape's are failing. It's not reliable for "service down" but a properly working exporter should successfully return a scrape with no error.

@wrouesnel thanks, that should be enough for a while.