Zero rating behaviour in MemoryBackend, blocking abusive clients as part of rate limiting

During some experimenting with settings it appeared that creating a Rule(hour=0, group="blocked", zone="sensitive_api") did not block the client immediately, but allowed accessing the zone once before the block took hold. This seems to be because of how MemoryBackend is implemented presuming that minimum limit amount is 1 and after setting the new limit counter for the client postponing the validity check to next round of access. This makes limits 0 and 1 equivalent in practise.
Setting zero rate seems to be supported in implementation of RedisBackend though. If I am correct about differences in implementations I suppose unifying the behaviour would make sense?
In a broader perspective, permanently blocking users might not be part of rate limiting, which is all about 429 and not so much about 401 or 403. However in some cases it is not meaningful to consider blocking independently from rate limiting, duplicating extra layer of URL patters and zones, especially if there is no separate authentication mechanism in place and blocking happens in scope of ensuring sanity of API exploitation, for example, blocking because repeatedly failing to conform to limits, concurrently exceeding multiple limits, spamming with repeated or malformed content etc.
I think besides 0=1 issue above, zero rating works as expected in current implementation, but there might be some additional questions of Retry-After giving meaningful instructions, for example in case of Rule(second=0).

Very interesting question. I kind of want to add a numeric check to Rule - only positive integers are allowed.


Readme md file insight - please indicate versions of compatibility.

It would be great if  the readme file in the .git repository could indicated the version(s) of AngularJS it is compatible with. The link to Download 0.2.13 is good to know for the local version of the source but does not help unless there is a notice of compatibility, for example, does version 0.2.13 support AngularJS 1.3 or above up-to 1.5?
NICE-TO-HAVE info: Typescript 1.4 supported.
This site is not alone, no blame here just insights that I hope will help the future as we move towards Angular2.
Best!

The bower.json file has the required version: https://github.com/angular-ui/ui-router/blob/master/bower.json#L6

What does TypeScript 1.4 support mean exactly?

Greetings Eddie,
It was a general comment regarding compatibility with the future use of Typescript 1.5 for Angularjs 1.x. It would a nice to know what version works with 1.2 or if it makes no difference.
It's an old post.
Thanks for your response.
Best,
Matt
Sent from my iPhone 6

On Aug 19, 2015, at 1:55 PM, Eddie Monge<EMAIL_ADDRESS>wrote:
What does TypeScript 1.4 support mean exactly?
—
Reply to this email directly or view it on GitHub.


Fixed #27661 -- Moved FileSystemFinder's ImproperlyConfigured exceptions to system checks.

https://code.djangoproject.com/ticket/27661

Moved FileSystemFinder's ImproperlyConfigured checks to newly-created system check module in contrib.staticfiles.
Documented the details of the system check.
Added unit tests and the regression test.

@charettes  Thanks for the review! I updated the commit.

@felixxm @timgraham  Thanks for the reviews! Apart from the "Tag" one, all have been fixed.

I rebased the branch and force pushed a few edits, however, I thought of a further improvement. If we added a check() method to BaseFinder() (raising NotImplemented) then the staticfiles check could iterate over settings.STATICFILES_FINDERS and call check() for each one. This would be more extensible and more inline with how other checks work. Could you try making that change?

@timgraham This is a great point, thank you!
Thus, do we only have "real" checks on FileSystemFinder, but for AppDirectoriesFinder and BaseStorageFinder is it safe to define an empty check() that returns an empty list []?

I was thinking BaseLoader would raise NotImplemented and the check would skip any loaders that raise it.

@timgraham  Updated.

@timgraham

check_finders() (maybe mocking finder.check()?)

Is it okay to use the built-in finders by overriding settings.STATICFILES_FINDERS as e.g. ['django.contrib.staticfiles.finders.AppDirectoriesFinder', ...]; or go further mocking contrib.staticfiles.finders.get_finders and let it return mocked Finder classes there?

BaseFinder.check() should also have unit tests.

For BaseFinder.check(), is it simply an AssertRaises(NotImplementedError) in unit test?

Not sure about 1, see what works. For 2, correct, assertRaisesMessage.

@timgraham  Thank you! Your last comments are fixed in d7f691d.
Two unit tests are also added. I mocked get_finders() using django.test.mock. Is this good to do?
https://github.com/django/django/pull/7781/commits/d7f691d9884294a0c1df9630a833a5ca746582ff#diff-95b591fb64242a04fde85829b7fff779R21


Using beam heating parameters with no other events

I'm trying to run a beam heating simulation with no other events (i.e. no impulsive events). My beam_heating_model.cfg looks like the following
1
Time	Energy_flux	Cut-off	Spectral_index
[s]	[erg/cm^2/s]	[keV]
10.0 200000000.0 15.0 7

and my heating_model.cfg looks like the following,
4.50000000e+09 1.00000000e+300 6.026180647986545e-06

0

This causes no heating to be configured because of this conditional: https://github.com/rice-solar-physics/HYDRAD/blob/87fe71193be3f66a6797f11eb028bc84f0525f79/Heating_Model/source/heat.cpp#L106-L111
Since the number of events is 0, it returns from this function before configuring the beam. I could of course solve this problem by just adding a "dummy" heating event so that the beam is configured, but I'm curious as to why this conditional exists. Is there some reason that I need to have a typical event configured when I'm using electron beam heating? My understanding was that these two processes can be used independently.

There is no good reason for this. Must be a bug that crept in while “fixing” something else. A beam ought to be runnable whether or not there is any other heating going on. Feel free to fix it.
From: Will Barnes @.>
Sent: Friday, November 3, 2023 5:54 PM
To: rice-solar-physics/HYDRAD @.>
Cc: Subscribed @.***>
Subject: [rice-solar-physics/HYDRAD] Using beam heating parameters with no other events (Issue #102)
I'm trying to run a beam heating simulation with no other events (i.e. no impulsive events). My beam_heating_model.cfg looks like the following
1
Time    Energy_flux    Cut-off Spectral_index
[s]     [erg/cm^2/s]   [keV]
10.0 200000000.0 15.0 7
and my heating_model.cfg looks like the following,
4.50000000e+09 1.00000000e+300 6.026180647986545e-06
0
This causes no heating to be configured because of this conditional: https://github.com/rice-solar-physics/HYDRAD/blob/87fe71193be3f66a6797f11eb028bc84f0525f79/Heating_Model/source/heat.cpp#L106-L111 https://urldefense.com/v3/__https:/github.com/rice-solar-physics/HYDRAD/blob/87fe71193be3f66a6797f11eb028bc84f0525f79/Heating_Model/source/heat.cpp*L106-L111__;Iw!!BuQPrrmRaQ!kvjgb-zPyXPaKYjEb0uB94JZspdPBfZCPOCE6Ia32JH9mI0DCi7bb7jZrNwb6Om-rmZspu8oTwPas9yXVenV6nddJsX4zsN-dYw$
Since the number of events is 0, it returns from this function before configuring the beam. I could of course solve this problem by just adding a "dummy" heating event so that the beam is configured, but I'm curious as to why this conditional exists. Is there some reason that I need to have a typical event configured when I'm using electron beam heating? My understanding was that these two processes can be used independently.
—
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https:/github.com/rice-solar-physics/HYDRAD/issues/102__;!!BuQPrrmRaQ!kvjgb-zPyXPaKYjEb0uB94JZspdPBfZCPOCE6Ia32JH9mI0DCi7bb7jZrNwb6Om-rmZspu8oTwPas9yXVenV6nddJsX4-SIx9HE$ , or unsubscribe https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACC6C7XC5E7V5JG4KPYY5FTYCVYX5AVCNFSM6AAAAAA65CLTBGVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3TOMBSGUYDGNY__;!!BuQPrrmRaQ!kvjgb-zPyXPaKYjEb0uB94JZspdPBfZCPOCE6Ia32JH9mI0DCi7bb7jZrNwb6Om-rmZspu8oTwPas9yXVenV6nddJsX432f2MUo$ .
You are receiving this because you are subscribed to this thread.  https://github.com/notifications/beacon/ACC6C7TXRKDVO4ALCKBGHH3YCVYX5A5CNFSM6AAAAAA65CLTBGWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHHLVYCBU.gif Message ID: @.*** @.***> >

Looks like I have to take back what I said previously, even without adding any events, the beam heating parameters are still read in and the beam heating is applied to the simulation. Given that code block above, I don't understand how that's possible though...maybe they are read in and initialized somewhere else?

I should have remembered earlier that beam heating only works when both OPTICALLY_THICK_RADIATION and
NLTE_CHROMOSPHERE are defined. There’s not much point beam heating an isothermal chromosphere; the interaction between the beam electrons and the chromosphere, at a given height in the chromosphere, won’t reproduce any observables because they depend heavily on the structure of the atmosphere.
From: Will Barnes @.>
Sent: Sunday, November 12, 2023 10:15 PM
To: rice-solar-physics/HYDRAD @.>
Cc: sjbradshaw @.>; Comment @.>
Subject: Re: [rice-solar-physics/HYDRAD] Using beam heating parameters with no other events (Issue #102)
Looks like I have to take back what I said previously, even without adding any events, the beam heating parameters are still read in and the beam heating is applied to the simulation. Given that code block above, I don't understand how that's possible though...maybe they are read in and initialized somewhere else?
—
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https:/github.com/rice-solar-physics/HYDRAD/issues/102*issuecomment-1807450159__;Iw!!BuQPrrmRaQ!kykE6b6gpOF9Ftc8BWyo9AkwZKShOhNb3MqRetToDulYNpUbtT5Fss0v3YaRkohRMydTwjVFqhZ7QZoDgoavHIplW7n8_MQXZIg$ , or unsubscribe https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACC6C7X6ETVXYUTROGFSSDLYEGNEJAVCNFSM6AAAAAA65CLTBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBXGQ2TAMJVHE__;!!BuQPrrmRaQ!kykE6b6gpOF9Ftc8BWyo9AkwZKShOhNb3MqRetToDulYNpUbtT5Fss0v3YaRkohRMydTwjVFqhZ7QZoDgoavHIplW7n8hfejpBM$ .
You are receiving this because you commented.  https://github.com/notifications/beacon/ACC6C7WVD255R4RJJARHZ2LYEGNEJA5CNFSM6AAAAAA65CLTBGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTLXOAC6.gif Message ID: @.*** @.***> >

I'm confused.  The code block linked in heat.cpp does not affect the beam heating, which is read in in a separate function (the next one down).
Has something changed regarding the chromosphere?

I'm confused. The code block linked in heat.cpp does not affect the beam heating, which is read in in a separate function (the next one down).

You're right. My initial explanation of the issue was wrong. My beam heating configuration was messed up in another place and I was confusing that issue with thinking the beam heating parameters were not being read in.

I should have remembered earlier that beam heating only works when both OPTICALLY_THICK_RADIATION and NLTE_CHROMOSPHERE are defined. There’s not much point beam heating an isothermal chromosphere; the interaction between the beam electrons and the chromosphere, at a given height in the chromosphere, won’t reproduce any observables because they depend heavily on the structure of the atmosphere.

Ah interesting. This is not something I fully appreciated since I've not thought much about observables in the lower atmosphere in the past.
Interestingly, even without the OPTICALLY_THICK_RADIATION and NLTE_CHROMOSPHERE flags, I do find that an electron beam of moderate strength ($F\approx10^9$ erg $\mathrm{cm}^{-2}\mathrm{s}^{-1}$, $E_C=15$ keV, $\delta=7$, duration of 10 s) leads to fairly significant blue shifts at around 0.5 MK in the first 20 s or so of the simulation. This is in comparison to having an event localized at the loop apex with approximately the same amount of energy (no beam) which produces only red shifts at these same temperatures.  Of course at 0.5 MK, I'm well above the chromosphere.

Did you do something to the code to get it to run without those flags, but with BEAM_HEATING defined? Without those flags it just seg. faults…
From: Will Barnes @.>
Sent: Monday, November 13, 2023 11:42 AM
To: rice-solar-physics/HYDRAD @.>
Cc: sjbradshaw @.>; Comment @.>
Subject: Re: [rice-solar-physics/HYDRAD] Using beam heating parameters with no other events (Issue #102)
I should have remembered earlier that beam heating only works when both OPTICALLY_THICK_RADIATION and NLTE_CHROMOSPHERE are defined. There’s not much point beam heating an isothermal chromosphere; the interaction between the beam electrons and the chromosphere, at a given height in the chromosphere, won’t reproduce any observables because they depend heavily on the structure of the atmosphere.
Ah interesting. This is not something I fully appreciated since I've not thought much about observables in the lower atmosphere in the past.
Interestingly, even without the OPTICALLY_THICK_RADIATION and NLTE_CHROMOSPHERE flags, I do find that an electron beam of moderate strength ($F\approx10^9$ erg $\mathrm{cm}^{-2}\mathrm{s}^{-1}$, $E_C=15$ keV, $\delta=7$, duration of 10 s) leads to fairly significant blue shifts at around 0.5 MK in the first 20 s or so of the simulation. This is in comparison to having an event localized at the loop apex with approximately the same amount of energy (no beam) which produces only red shifts at these same temperatures. Of course at 0.5 MK, I'm well above the chromosphere.
—
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https:/github.com/rice-solar-physics/HYDRAD/issues/102*issuecomment-1808662188__;Iw!!BuQPrrmRaQ!gE8tNLshmWLUa3EoQe5oQgNHKSfty0-jTZtTXzd9L6ZV5Uwlr6zWtSoNLin6XXZrSX6zQRfl2JlU6zurvHx56IykGMmREim2nPU$ , or unsubscribe https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACC6C7USO5274YKGJTLBEE3YEJLWTAVCNFSM6AAAAAA65CLTBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGY3DEMJYHA__;!!BuQPrrmRaQ!gE8tNLshmWLUa3EoQe5oQgNHKSfty0-jTZtTXzd9L6ZV5Uwlr6zWtSoNLin6XXZrSX6zQRfl2JlU6zurvHx56IykGMmRsovJRB0$ .
You are receiving this because you commented.  https://github.com/notifications/beacon/ACC6C7R5HHCSXA6XBHGL53TYEJLWTA5CNFSM6AAAAAA65CLTBGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTLZX7KY.gif Message ID: @.*** @.***> >

I've certainly run beam heating without NLTE_CHROMOSPHERE defined.  I don't recall having any requirement to have that switch turned on for BEAM_HEATING unless a more recent update changed something?  I can't remember whether I have done so without OPTICALLY_THICK_RADIATION, but that might overlap with the column density calculation.
Could you upload the configuration you're running, Will?

If I just create the default initial conditions, choose beam heating, and then run HYDRAD then I get a seg. fault. For me, choosing OPTICALLY_THICK_RADIATION and NLTE_CHROMOSPHERE resolves it. I haven’t looked into it for the reasons I described earlier (the isothermal, stratified chromosphere’s interaction with the beam isn’t very physical). However, I guess it could be a useful option for test / exploratory calculations.
From: jwreep @.>
Sent: Monday, November 13, 2023 1:15 PM
To: rice-solar-physics/HYDRAD @.>
Cc: sjbradshaw @.>; Comment @.>
Subject: Re: [rice-solar-physics/HYDRAD] Using beam heating parameters with no other events (Issue #102)
I've certainly run beam heating without NLTE_CHROMOSPHERE defined. I don't recall having any requirement to have that switch turned on for BEAM_HEATING unless a more recent update changed something? I can't remember whether I have done so without OPTICALLY_THICK_RADIATION, but that might overlap with the column density calculation.
Could you upload the configuration you're running, Will?
—
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https:/github.com/rice-solar-physics/HYDRAD/issues/102*issuecomment-1808857354__;Iw!!BuQPrrmRaQ!nhzAFnafRKbqUq1tnF7wp-T9knuM9GegCRAjTzPcgBUn_namWET0xiwWC0l0gmBqOODyrzzavYASZFOI75SO-fHyZsaXk2NKlk0$ , or unsubscribe https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACC6C7TA6HXSIFV2EPAQYEDYEJWUVAVCNFSM6AAAAAA65CLTBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYHA2TOMZVGQ__;!!BuQPrrmRaQ!nhzAFnafRKbqUq1tnF7wp-T9knuM9GegCRAjTzPcgBUn_namWET0xiwWC0l0gmBqOODyrzzavYASZFOI75SO-fHyZsaXhM6CMf0$ .
You are receiving this because you commented.  https://github.com/notifications/beacon/ACC6C7SFM4LY2BDHGALBJ33YEJWUVA5CNFSM6AAAAAA65CLTBGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTL2D4QU.gif Message ID: @.*** @.***> >

The only thing I did was add a #define BEAM_HEATING to Radiation_Model/source/config.h. I'm not sure if the GUI was doing this already, but the Python tools were missing this and without it, I was getting a compilation error (not a runtime error).
I've attached a run here (without any of the results or compiled executables) that includes the entire configuration that compiles and runs on my machine.
beam_heating_example.tar.gz

If I just create the default initial conditions, choose beam heating, and then run HYDRAD then I get a seg. fault. For me, choosing OPTICALLY_THICK_RADIATION and NLTE_CHROMOSPHERE resolves it.

Interesting. I'm using pydrad to configure the run instead of the GUI. In pydrad, I've tried to mimic the logic of how the GUI sets the preprocessor directives and writes the configuration files, but it seems there are cases where the behavior differs.

Well, if it somehow works via pydrad then I wouldn’t question it…
From: Will Barnes @.>
Sent: Monday, November 13, 2023 1:36 PM
To: rice-solar-physics/HYDRAD @.>
Cc: sjbradshaw @.>; Comment @.>
Subject: Re: [rice-solar-physics/HYDRAD] Using beam heating parameters with no other events (Issue #102)
If I just create the default initial conditions, choose beam heating, and then run HYDRAD then I get a seg. fault. For me, choosing OPTICALLY_THICK_RADIATION and NLTE_CHROMOSPHERE resolves it.
Interesting. I'm using pydrad to configure the run instead of the GUI. In pydrad, I've tried to mimic the logic of how the GUI sets the preprocessor directives and writes the configuration files, but it seems there are cases where the behavior differs.
—
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https:/github.com/rice-solar-physics/HYDRAD/issues/102*issuecomment-1808898656__;Iw!!BuQPrrmRaQ!lqNaYPs41bpMy7pn2ITUBqL1cILBwdvf-Q3ZaGotyCGmQgPsxbKJR-IbJyRXAsJF4Pa1icLiJFeTfpJydQKtlec6lYqHXz8t2Js$ , or unsubscribe https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACC6C7RMWOKC3I56TJAVJT3YEJZA3AVCNFSM6AAAAAA65CLTBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYHA4TQNRVGY__;!!BuQPrrmRaQ!lqNaYPs41bpMy7pn2ITUBqL1cILBwdvf-Q3ZaGotyCGmQgPsxbKJR-IbJyRXAsJF4Pa1icLiJFeTfpJydQKtlec6lYqH0dB2q5g$ .
You are receiving this because you commented.  https://github.com/notifications/beacon/ACC6C7RVMBGNWFGQTW2HO3LYEJZA3A5CNFSM6AAAAAA65CLTBGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTL2GNGA.gif Message ID: @.*** @.***> >

The only thing I did was add a #define BEAM_HEATING to Radiation_Model/source/config.h.

It needs to be defined in Heating_Model/source/config.h as well.

Defining BEAM_HEATING in Radiation_Model/source/config.h seems to have fixed it for me. Cheers!
I’ll make an update for the public version on GitHub.
From: jwreep @.>
Sent: Monday, November 13, 2023 2:09 PM
To: rice-solar-physics/HYDRAD @.>
Cc: sjbradshaw @.>; Comment @.>
Subject: Re: [rice-solar-physics/HYDRAD] Using beam heating parameters with no other events (Issue #102)
The only thing I did was add a #define BEAM_HEATING to Radiation_Model/source/config.h.
It needs to be defined in Heating_Model/source/config.h as well.
Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https:/github.com/rice-solar-physics/HYDRAD/issues/102*issuecomment-1808978083__;Iw!!BuQPrrmRaQ!mS3eN-9WQWnMf5kZlfi3BY9Rq0nJzfvAxaVna5kAEdndGe72glLUppG9P6E6MxcjZbhawNkrzh-A31npiu8BtbrhX582F0MGHV8$ , or unsubscribe https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACC6C7WQE7MKEBPCGFGG42DYEJ45PAVCNFSM6AAAAAA65CLTBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYHE3TQMBYGM__;!!BuQPrrmRaQ!mS3eN-9WQWnMf5kZlfi3BY9Rq0nJzfvAxaVna5kAEdndGe72glLUppG9P6E6MxcjZbhawNkrzh-A31npiu8BtbrhX5825fv17OU$ .
You are receiving this because you commented.  https://github.com/notifications/beacon/ACC6C7VYSOMVSO7SJ6BLOD3YEJ45PA5CNFSM6AAAAAA65CLTBGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTL2LIKG.gif Message ID: @.*** @.***> >

Yeah I had it defined there, but it does not get picked up in Radiation_Model/source/config.h so it needs to be defined both places.

Defining BEAM_HEATING in Radiation_Model/source/config.h seems to have fixed it for me. Cheers! I’ll make an update for the public version on GitHub.

Great! I'm still confused as to how this leads to a seg fault and not a compile time error (because BEAM_HEATING is not defined), but maybe that's down to different compilers and operating systems?

Great! I'll go ahead and close this since its been fixed in the GUI and on the pydrad side.


To many draggable handles[BUG]

Module Version: v0.4.3
Describe the bug
Gotta admit not sure if bug or styling issue.. Decided bug since its propably an issue inside the code.

As can be seen your window has "to many" draggable handles. A window is supposed to have 0 or 1 (i think). Dragging that one onto the canvas results in the entity getting created.
In the case of the quest log dragging onto the canvas doesn't do a thing. So disabling the handles would propably be the best idea (i think)

Second screenshot to show what draggable handles are
Browser:

Firefox

Foundry Version:

0.6.4

Game System:

DnD 5e 0.93

Seems to not be from Core. Inspection from Chrome and Fifefox:

If I had to guess, some module adds an element on every "render" hook, without checking if window was already rendered.

ye gotta take it bake
i can't reproduce it anymore.. sry :grimacing:


k8s: Bump CRD schema version to 1.27.x

Somehow we missed bumping the minor schema version release during the
v1.14 dev cycle. This creates a mild danger for conflict with 1.26.x
that is currently used by Cilium 1.13.x releases. Bump this up to 1.27.0
to reduce the risk of conflicting CRD schema versions between branches.

/test-backport-1.14


Make it installable through BPKG

Make it installable through BPKG, bash package manager.
Reference: https://github.com/bpkg/bpkg#packaging-best-practices

done in current-refactor branch. will be shipped with 3.0

done in #50 that is to be landing soon


Use DeepSeek-Coder instead of DeepSeek-Chat

Hi Jimmie,
Do you think that's possible to make that change?

what provider did you use? currently there is no deepseek coder. deepseek provides only deepseek-chat and the deepseek-coder in deepseek is also deepseek-chat.


kube-dns failed to resolve domain names due to lack of arg --kubecfg-file in kube-dns container starting command

environment:
bootkube version: 83b93c1c626c97feffb5ea50a62fc1be6a1e5a13
OS: centos7.2
kubelet version: 1.9.1
network-provider: flannel
Host Network: not connected to internet, behind a proxy
what happened:
kube-dns failed to resolve domain names, due to connected to wrong apiserver(https://cluster-ip:443).
How to solve it:
The solution works in my case, as follows:

mount kubeconfig-in-cluster configmap as volume in kube-dns-deployment.yaml
add --kubecfg-file in container kube-dns start args.

If above solution is OK, I can open an PR.

Is the problem that you've configured your API server's DNS name to point at the proxy? But kube-dns needs to reference an alternative name?

No,  AFAIK,  the problem has no relation with proxy.
It happened simply because it didn't use a kubecfg-file as its start command parameter. And then it connected to a wrong apiserver as its default behavior.

It happened simply because it didn't use a kubecfg-file as its start command parameter. And then it connected to a wrong apiserver as its default behavior.

Can you elaborate on what "wrong API server" means? Kube-dns sholud attempt to connect to the API server endpoint, which is an internal IP address.
$ kubectl get endpoints -n default kubernetes -o yaml
apiVersion: v1
kind: Endpoints
metadata:
  creationTimestamp: 2018-02-05T17:18:44Z
  name: kubernetes
  namespace: default
  resourceVersion: "7"
  selfLink: /api/v1/namespaces/default/endpoints/kubernetes
  uid: 9e4248aa-0a98-11e8-ae49-0615bdbc521a
subsets:
- addresses:
  - ip: <IP_ADDRESS>
  ports:
  - name: https
    port: 443
    protocol: TCP

Kube-dns sholud attempt to connect to the API server endpoint, which is an internal IP address.

In my case, the internal IP address is within a subnet(<IP_ADDRESS>/24) I built for kube-dns to use.
the kube-dns tried to connect to an ip that didn't work at that moment.
It seemed like a chicken-egg problem.

Can you elaborate on what "wrong API server" means?

the wrong API server is https://<IP_ADDRESS>:443
kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   <IP_ADDRESS>     <none>        443/TCP   6d
my-nginx     ClusterIP   <IP_ADDRESS>    <none>        80/TCP    4d

To make things clear, the ip <IP_ADDRESS> is a nodeIp or hostIp
kubectl get endpoints -n default kubernetes -o yaml
apiVersion: v1
kind: Endpoints
metadata:
  creationTimestamp: 2018-01-30T08:53:10Z
  name: kubernetes
  namespace: default
  resourceVersion: "757342"
  selfLink: /api/v1/namespaces/default/endpoints/kubernetes
  uid: ffcf56c1-059a-11e8-837f-aaaaaa1bb37c
subsets:
- addresses:
  - ip: <IP_ADDRESS>
  ports:
  - name: https
    port: 6443
    protocol: TCP

/area render


D language support

Description
Add D language support
Acceptance Criteria

Being able to select D in the select box
Having syntax highlighting

Note
I noticed it is commented, what's the reason?
https://github.com/bartTC/dpaste/blob/735f25cc04ef07b4b7d50b60a4d11cbd421d443b/dpaste/apps.py#L271
Thanks!

This is live!

@bartTC thanks a lot!


[CARBONDATA-118] Temp location clean up in compaction

Temp locations should get deleted after the compaction is completed in RDD.

LGTM


Predicate as class function not resolving correctly

I am attempting to use LinqKit to build a dynamic predicate that will function as a where clause in a SQL query.  I have created a stand-alone class with all the properties that would be used in the predicate.  I also have a function within the class that returns the predicate.
The issue I am running into is that the predicate is prefixing any property from the class with the class type.  For example, I want to filter on an ID column and the final predicate is:
{x => (Convert(x.ID) == value(Program+ContactAbbreviationsSearchCriteria).ID)}
Obviously, entity framework can't process the value(Program+ContactAbbreviationsSearchCriteria) statement and throws an error.  I have put together a fiddle as a showcase:
https://dotnetfiddle.net/kfcH4T
I've tried using both .Compile() and .Expand() with no success, so I'm wondering if what I want to accomplish here is even possible?

I found the issue.  I needed to .Compile() the predicate before passing it into the where clause.  The error only happens when I pass the compiled predicate into the IncludeFilter function of Z.EntityFramework.Plus


Support llvm compiler backend for the plugin

Describe the feature
Context: https://crates.io/crates/wasmer-compiler-llvm
It is recommended to use llvm-base compiler backend for the prod env when we run plugins.
We can't enforce this, but our plugin should be able to opt-in to use most performant backend if it's available. It is unclear at this moment if we should expose explicit config, or should do dynamic fallback based on availability - but given config should be portable across machines, I'm leaning on some sort of detection mechanism.
Babel plugin or link to the feature description
No response
Additional context
No response

Problem is that it requires global installation of llvm.
I think wapm can be a solution for this problem. (https://github.com/swc-project/swc/issues/2635#issuecomment-1006038273)
cc @syrusakbary Any thoughts?

@kdy1
That's the part

We can't enforce this, but our plugin should be able to opt-in to use most performant backend if it's available

describes. This issue's goal is let plugin_runner runs with llvm compiler if available, but doesn't enforce or do something around llvm installation at all. This should be suffecient for the experimental phase with instructions prod-env plugin running.

wapm, or any other precompiled support would be probably needed eventually but I'd expect that's probably after stablizing initial feature sets.

Yeah I agree. It should be excluded from the initial version.

ugh, I was under assumption dependency to llvm is somehow runtime, but it is actually compile time:
error: No suitable version of LLVM was found system-wide or pointed
       to by LLVM_SYS_120_PREFIX.

       Consider using `llvmenv` to compile an appropriate copy of LLVM, and
       refer to the llvm-sys documentation for more information.

       llvm-sys: https://crates.io/crates/llvm-sys
       llvmenv: https://crates.io/crates/llvmenv
   --> /home/ojkwon/.cargo/registry/src/github.com-1ecc6299db9ec823/llvm-sys-120.2.1/src/lib.rs:486:1
    |
486 | / std::compile_error!(concat!(
487 | |     "No suitable version of LLVM was found system-wide or pointed
488 | |        to by LLVM_SYS_",
489 | |     env!("CARGO_PKG_VERSION_MAJOR"),
...   |
496 | |        llvmenv: https://crates.io/crates/llvmenv"
497 | | ));

I'll leave this opened for now for backlogging purpose. But if this is hard requirement to have llvm for the compile time, we may not easily have this.

I'm actually bit unsure llvm is required for the build time and runtime both though :thinking:

I think it's both

None of the compilers are needed for processing an already compiled module. That means, that once the module is precompiled (lets say from a .wasm to a .dylib), the runtime will not need to have any of the compilers installed (that is, it can run fully headless)

That means, that once the module is precompiled (lets say from a .wasm to a .dylib)

@syrusakbary
We do not expect to let plugin author to precompile binary at this moment. In particular, making platform-dependent precompile binary (.so, .dylib) defeats one of the main goal we wanted to achieve via wasm to have single binary to run everywhere.
The story in this issue aimed was (in a theoretical perspective)

plugin is published as .wasm binary
swc runs with default compiler if llvm doesn't exists
or runs with llvm compiler if system have llvm installed
generated (or compiled) byte stored as cache on those system it'll be reused

There are some stories we need to think about supporting full-precompiled story, but that's currently out of the scope.

plugin is published as .wasm binary

I found wasmer compile has --target <target-triple>
Probably not bad to publish plugin's native code since we can cross compile them.
At least plugin author don't need to use build matrix in github action like in the past.

I'm going to close this for now, will reopen if there are any breakthrough.


Bread Production

Added Flour, altered Wheat's sag mill recipe, added Flour->Bread alloy
smelter recipe.
Added the flour to avoid any dependencies on other mods.
The main reason behind the changes is to facilitate the increase of bread yield from wheat. The usual output of a grinder/mill when given wheat is flour (both realistically and in other mods), and throwing wheat into your sag mill and getting seeds can be jarring.This fixes that entirely!

Hate to nitpick, but the item would probably fit better as part of the PowderIngot enum, not Material. This would also avoid it being automatically registered as "itemFlour"

Keep nitpicking, I'll adjust and get back to you.


Large project causes java.lang.StackOverflowError

I have a large IntelliJ project, of which there are ~102 source files in 11 modules.
Recently I started receiving this message in the Event Log quite often:
Ceylon model update failed The Ceylon model update triggered an unexpected exception: java.lang.StackOverflowError that will be reported in the Event View. To avoid performance issues the automatic update of the Ceylon model has been disabled. You can reenable it by using the following menu entry: Tools -> Ceylon -> Enable automatic update of model.

Here's the stacktrace of the error: https://gist.github.com/xDotDash/0f2008b1bca74c680eb1c63b3f049ced

The change producing this error might be that you exported a module (with a shared import) involved in a circular dependency.

Fixed

Fixed how exactly?

As davidfestal suggested, I removed a shared circular dependency.

Let's reopen it: the IDE common dependency analyzer should detect this case and stop recursion

Let's reopen it: the IDE common dependency analyzer should detect this case and stop recursion

Let's reopen it: the IDE common dependency analyzer should detect this case and stop recursion


ERROR: UNABLE TO FETCH CSRF_TOKEN PROBABLE CAUSE: IP BANNING

Hey,
I have an issue when I try to create an account :

I try to use different proxies.
Thank you for your help :)

I no longer maintain this project as it's very hard for me to find time. Try using different proxies for now :)


Try to upgrade spring-boot's version to 2.6.0-RC1, and upgrade 3rd-party dependencies version.

Not merge to main branch, just run tests, find pipeline failures and fix them.

spring-boot:2.6.0-M3: https://github.com/spring-projects/spring-boot/releases/tag/v2.6.0-RC1
Sample PR: https://github.com/Azure/azure-sdk-for-java/issues/23686

Close this issue now due to this issue https://github.com/Azure/azure-sdk-for-java/issues/25581.


metrics.agreement.AnnotationTask kappa result seems wrong

I got strange kappa result from AnnotationTask
This is how I calculated kappa.
from nltk.metrics.agreement import AnnotationTask

evaluator1 = [3, 5, 5, 5, 5, 5, 5, 5, 5, 3, 3, 5, 5, 5, 5, 3, 5, 5, 5, 5]
evaluator2 = [0, 4, 5, 2, 2, 1, 0, 0, 5, 0, 5, 0, 5, 2, 4, 0, 0, 4, 0, 2]

data = []
for i in range(len(evaluator1)):
    for j, k in zip(evaluator1, evaluator2):
        data.append(('1', str(i), str(j)))
        data.append(('2', str(i), str(k)))

task = AnnotationTask(data)

print(task.kappa()) # 1.0158730158730158

Since kappa is bigger than 1, it seems wrong enough.
In addition to this computation, I checked kappa from sklearn.
from sklearn.metrics import cohen_kappa_score

print(cohen_kappa_score(evaluator1, evaluator2)) # -0.011904761904761862

It should be like this:
`from nltk.metrics.agreement import AnnotationTask
evaluator1 = [3, 5, 5, 5, 5, 5, 5, 5, 5, 3, 3, 5, 5, 5, 5, 3, 5, 5, 5, 5]
evaluator2 = [0, 4, 5, 2, 2, 1, 0, 0, 5, 0, 5, 0, 5, 2, 4, 0, 0, 4, 0, 2]
data = []
i = 0
for j, k in zip(evaluator1, evaluator2):
data.append(('1', str(i), str(j)))
data.append(('2', str(i), str(k)))
i += 1
task = AnnotationTask(data)
print(task.kappa())  # -0.01190476190476195`
There shouldn't be a nested loop. Because of your nested loop, one assignment ends up getting multiple annotations (whereas for cohen's kappa there should be 2 annotator per assignment) - which is perhaps why it 'breaks' nltk - causing a result over 1.

@JRC1995
Thanks for the explanation!

I guess this issue could be closed 😄


finished question 6

With this question, I actually initially wrote out the function code under master. Realized my mistake and did not ACP my changes from master, cut my changes from VS code, went into terminal and created a branch, pasted my changes into VS code, then ACP from my new branch. I don't know if anything will be weird because of that, but I thought it was worth noting.

Great work.  always submit a link to your latest PR as opposed to the link to your entire repo -or the Pr that satisfies the assignement if the stretch goal isn't 100%


Further makefile targets

closes #608

"diesel database reset", I called it migration-reset so it fits to the other migration targets and is rememberable.
"diesel migration run" did already exist.
"redo migrations", got added for most recent and for all.
"scraper insert", please confirm this is what you want cd scraper && npm install && mkdir -p data && npm run start:full.

Btw, I got this error when doing migration redo -a
Failed to run 2023-06-07-120000_postgis_extension with: cannot drop extension postgis because other objects depend on it
make[1]: *** [Makefile:25: migration-redo-all] Error 1

Is that expected?

Basics

[ ] I added a line to /doc/CHANGELOG.md
[ ] The PR is rebased with current master.
[ ] Details of what you changed are in commit messages.
[ ] References to issues, e.g. close #X, are in the commit messages.
[ ] The buildserver is happy.

Checklist

[ ] I have installed and I am using pre-commit hooks
[ ] I fully described what my PR does in the documentation
(not in the PR description)
[ ] I fixed all affected documentation
[ ] I fixed all affected decisions
[ ] I added unit tests for my code
[ ] I added code comments, logging, and assertions as appropriate
[ ] I translated all strings visible to the user
[ ] I mentioned every code or binary not directly written or done by me in reuse syntax
[ ] I created left-over issues for things that are still to be done
[ ] Code is conforming to our Architecture
[ ] Code is conforming to our Guidelines
(exceptions are documented)
[ ] Code is consistent to our Design Decisions

Review

[ ] I've tested the code
[ ] I've read through the whole code
[ ] Examples are well chosen and understandable

I get an error with make distclean (also before this PR):

Oh yea that's a copy paste error, ty.

I think this is ready to be merged when the pipeline is fine with it.

Great! I think we now have everything merged for the release, except of maybe #606 if you find a solution soon.
Let us see if master builds successfully, too.


QueenAnnotationTypeDeclarationNode.java: Finish implementing the body ...

The puzzle -1937614881 originating from #10 has to be resolved:
https://github.com/jvmqueen/queen-of-java/blob/1d27c5979678b2d1f8088c3f29fdb7f3076f8fd4/src/main/java/org/queenlang/transpiler/nodes/QueenAnnotationTypeDeclarationNode.java#L44-L44
"Finish implementing the body here.".
The puzzle was created by amihaiemil at 2022-12-11 10:31:54 +0200.
Estimation is 30 minutes.
If you have any technical questions, don't ask me, I won't be able to help. Open new issues instead.

@amihaiemil this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2022-12-21T08:40:21.548070.
Estimation here is 30 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

Puzzle disappeared from the code, that's why I closed this ticket.

@amihaiemil thank you for resolving this ticket. I've just added it to your active invoice. You can always check all your invoices and more on the Contributor Dashboard.


Release: Bump version to 1.0-beta02

TL;DR
Bump version code to 22 and version name to 1.0-beta02
What changed?

Incremented versionCode from 21 to 22
Updated versionName from "1.0-beta01" to "1.0-beta02"

How to test?

Build and install the app
Verify the new version appears in the app settings or system app info

Why make this change?
Prepare for the next beta release by incrementing version numbers to maintain proper version control and release tracking in the Play Store.

Merge activity

Dec 2, 5:02 AM EST: A user merged this pull request with Graphite.


Doctest coverage of API functions

Design principle: API should be well documented, thus other people know how to use your software. As we know simple examples are the best documentation, thus doctests are very important. Luckily Julia packages define their API through export statements. My idea is to write a test, which checks that how many of our API functions have at least one doctest. We could possibly write doctest.cov file and use coverage.io service.
This is the logical next step of the issue #23.
If others agree with this principle let's also update the CONTRIBUTING.md.

I agree that this is a good idea. We also need to make sure that these doctests are passing.

Help is needed.
tero@tero-Dell-System-XPS-L321X ~/dev/JuliaFEM.jl $ make doctests
julia docs/build_doctests.jl
Docile: upgrading cache to 0.0.2.

WARNING: deprecated syntax "{a=>b, ...}" at /home/tero/.julia/v0.4/JuliaFEM/src/abaqus_reader.jl:11.
Use "Dict{Any,Any}(a=>b, ...)" instead.

WARNING: deprecated syntax "{a=>b, ...}" at /home/tero/.julia/v0.4/JuliaFEM/src/abaqus_reader.jl:32.
Use "Dict{Any,Any}(a=>b, ...)" instead.
WARNING: could not import Base.put into Requests

WARNING: deprecated syntax "install (" at /home/tero/.julia/v0.4/BinDeps/src/dependencies.jl:773.
Use "install(" instead.
WARNING: This version of the GnuTLS library (3.2.11) is deprecated
and contains known security vulnerabilities. Please upgrade to a
more recent version.

WARNING: deprecated syntax "HashDict{K} (" at /home/tero/.julia/v0.4/DataStructures/src/hashdict.jl:77.
Use "HashDict{K}(" instead.

WARNING: deprecated syntax "HashDict{V} (" at /home/tero/.julia/v0.4/DataStructures/src/hashdict.jl:78.
Use "HashDict{V}(" instead.

WARNING: deprecated syntax "HashDict (" at /home/tero/.julia/v0.4/DataStructures/src/hashdict.jl:79.
Use "HashDict(" instead.

WARNING: deprecated syntax "OrderedDict{K} (" at /home/tero/.julia/v0.4/DataStructures/src/ordereddict.jl:39.
Use "OrderedDict{K}(" instead.

WARNING: deprecated syntax "OrderedDict{V} (" at /home/tero/.julia/v0.4/DataStructures/src/ordereddict.jl:40.
Use "OrderedDict{V}(" instead.

WARNING: deprecated syntax "OrderedDict (" at /home/tero/.julia/v0.4/DataStructures/src/ordereddict.jl:41.
Use "OrderedDict(" instead.
ERROR: LoadError: LoadError: LoadError: LoadError: LoadError: UndefVarError: utf16_is_surrogate not defined
 in include at ./boot.jl:254
 in include_from_node1 at ./loading.jl:197
 in include at ./boot.jl:254
 in include_from_node1 at ./loading.jl:197
 in require at ./loading.jl:146
 in include at ./boot.jl:254
 in include_from_node1 at ./loading.jl:197
 in require at ./loading.jl:146
 in include at ./boot.jl:254
 in include_from_node1 at ./loading.jl:197
 in include at ./boot.jl:254
 in include_from_node1 at ./loading.jl:197
 in process_options at ./client.jl:308
 in _start at ./client.jl:411
while loading /home/tero/.julia/v0.4/JSON/src/Parser.jl, in expression starting on line 141
while loading /home/tero/.julia/v0.4/JSON/src/JSON.jl, in expression starting on line 7
while loading /home/tero/.julia/v0.4/Requests/src/Requests.jl, in expression starting on line 12
while loading /home/tero/dev/JuliaFEM.jl/docs/badges.jl, in expression starting on line 1
while loading /home/tero/dev/JuliaFEM.jl/docs/build_doctests.jl, in expression starting on line 3
make: *** [doctests] Error 1
tero@tero-Dell-System-XPS-L321X ~/dev/JuliaFEM.jl $

I changed to older julia-0.4 version and now it works
tero@tero-Dell-System-XPS-L321X ~/dev/JuliaFEM.jl $ make doctests
julia docs/build_doctests.jl

WARNING: deprecated syntax "{a=>b, ...}" at /home/tero/.julia/v0.4/JuliaFEM/src/abaqus_reader.jl:11.
Use "Dict{Any,Any}(a=>b, ...)" instead.

WARNING: deprecated syntax "{a=>b, ...}" at /home/tero/.julia/v0.4/JuliaFEM/src/abaqus_reader.jl:32.
Use "Dict{Any,Any}(a=>b, ...)" instead.
Warning: could not import Base.put into Requests
WARNING: This version of the GnuTLS library (3.2.11) is deprecated
and contains known security vulnerabilities. Please upgrade to a
more recent version.
Docile: updating package list...

WARNING: deprecated syntax "{a=>b, ...}" at /home/tero/dev/JuliaFEM.jl/docs/build_doctests.jl:11.
Use "Dict{Any,Any}(a=>b, ...)" instead.

WARNING: deprecated syntax "{a=>b, ...}" at /home/tero/dev/JuliaFEM.jl/docs/build_doctests.jl:32.
Use "Dict{Any,Any}(a=>b, ...)" instead.
Docile: caching 5 modules from 'JuliaFEM'.
running doctest on JuliaFEM...
running doctest on JuliaFEM.abaqus_reader...
running doctest on JuliaFEM.elasticity_solver...
running doctest on JuliaFEM.interfaces...
running doctest on JuliaFEM.xdmf...
perce: NaN
color: lightgray
WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead
 in depwarn at ./deprecated.jl:62
 in oldstyle_vcat_warning at ./abstractarray.jl:29
 in vect at ./abstractarray.jl:38
while loading /home/tero/dev/JuliaFEM.jl/docs/build_doctests.jl, in expression starting on line 37
WARNING: int(x) is deprecated, use Int(x) instead.
 in depwarn at ./deprecated.jl:62
 in int at ./deprecated.jl:49
 in on_header_value at /home/tero/.julia/v0.4/Requests/src/Requests.jl:122
while loading /home/tero/dev/JuliaFEM.jl/docs/build_doctests.jl, in expression starting on line 37
tero@tero-Dell-System-XPS-L321X ~/dev/JuliaFEM.jl $

What is our documentation and doctest status?

Documentation status is: we are now using Documenter.jl, it has doctests and "kind of" notebook thing, blocks denoted by example tag are executed during documentation generation. Doctests are inside jldoctest, more info from Documenter.jl documentation. It's also possible to request Documenter.jl to be strict, i.e. exported functions without docstrings will cause failure of of build.
About the main idea, that exported functions have at least one doctest, is still a great idea. I however have not seen such functionality in Documenter.jl. Maybe this discussion should be continued at PkgTestSuite.jl issue log, because this is related to all packages we are developing, not only JuliaFEM.jl


All images display:block

Makes it impossible to use inline images, and since this css is imported via js, makes it tricky also to override. Need to investigate further. See: index.css#L166

Haha, tracked down my bug and finally ended up right back here. I end up with readme content that looks like this:

Can this css simply be removed? It looks like github simply leaves that unset and so all images pick up display: inline from the user agent stylesheet. I believe it accomplishes block images by wrapping them in a p tag (i.e. they're on their own line), which should happen automatically.
I'll submit a PR and can discuss further from there.

(Note: wording of that sentence in my image is an entirely separate but equally serious issue :grimacing:)

Fixed by forking stackgl-readme-css. Just pointing it to the github repo at the moment. I haven't decided whether it's a good idea to maintain a separate fork of this. Leaving the issue open until it's clear whether these changes (tables too, once I get to that) should be merged or just left forked.
See, e.g.: http://scijs.net/packages/#scijs/ndarray-band


Show unknown nodes

Currently objects of unknown types are simply hidden, which can be
confusing as it would show, for example, “1 key”, but then not show any
keys.
This PR fixes that by showing a placeholder with the name of the class.
E.g. <Int8Array>.

This looks good! Thanks for the contribution! I'll publish a new version today. This library is moving to redux-devtools and will be maintained there. Please refer to that repository for future issues or contributions.

Sweet, thanks Mihail! :)


silence warden expired session "errors"

Closes #4698

@ethervoid CR please

:+1:

Frontend tests were OK :+1: (details)


[Request] Gas storage Multiblock

I was trying to fiddle with the dynamic tank for gas storage but that is not something it does. Is there a chance something could be added? Cureently an advanced injection factory requires 8 salination plants at 18 to run a constant stream of 7 ore stacks. And im not seeing a way to optimize it like i can with the power network.

As of right now this is just a use of the rotary condensentrator - converting gas to fluid for storage in a dynamic tank. Maybe in the future though :)


Multiple people querying MII issue

@stas00
I have an issue.
If multiple people query BLOOM deployed with MII then, I run into event loop is already running issue.
I tried to fix this by awaiting the generate method but that just leads to MII getting stuck

I'd say this would be a question for the DeepSpeed team. You could tag them here, but it's probably the best to post about it directly at their Issues.


Assign name to reducer-less routes. Fix blank line bug.

Fixes #765
Added component name to a route without a reducer.
The blank lines were caused by a trailing whitespace at the end of the template file. Removing it sorted the issues with the blank lines.

Coverage remained the same at 98.234% when pulling 0b85cef8d4204056ba1b58ef9981b70bc23dbaa0 on kraffslol:generator into 0f9ce5608ccfe1894df59c52976c9e4ba296fdf2 on mxstbr:master.

Awesome! The trailing line thing is a bit annoying as we have trailing lines in all other files. Any idea how we could fix this without removing the trailing line? @amwmedia maybe has an idea?

@mxstbr I haven't played around with partials much, but it seems like you could utilize them to solve this. If you were to load the template using fs, you could trim the content before registering it as a partial that could then be used in the modify action's template value.
actions.push({
    type: 'modify',
    path: '../../app/routes.js',
    pattern: /(\s{\n\s{6}path: '\*',)/g,
    template: '{{> myCleanedUpTemplate }}',
});

Thanks to @amwmedia advice, the templates are now trimmed before being returned to the generator. This gets rid of the trailing whitespace in routes.js while keeping it in the templates.

Awesome @kraffslol, this is looking great! Any idea why CI is failing?

I think it's failing because the merge is failing. I've tried correcting it but it doesn't seem to work out. Is this something you can correct on your side?

Could do, but where's the fun in that? 😉 May I refer you to Kent's excellent guide about this and you'll try yourself?

Coverage remained the same at 98.234% when pulling 3aa8caf765b38b1d3db1398ea946a185e5cb53b1 on kraffslol:generator into fda15ea63f944f1ee10dd6212c26d520ec95bffb on mxstbr:master.

Ahh there we go! Thanks for getting me to do it myself :grinning:

Awesome, thanks so much @kraffslol!

@kraffslol Confirmed, working as expected. Well done! 💯


datasets

Can you share your datasets？ thanks

Hello,The images are available using the download script in the datasets directory.AshaOn Mar 15, 2018 3:27 AM, wanglf<EMAIL_ADDRESS>wrote:Can you share your datasets？ thanks
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

But I click url error， The requested URL /cvl/combogan/$FILE.zip was not found on this server.

You have the same problem as this guy:  https://github.com/AAnoosheh/ComboGAN/issues/2
There are multiple datasets so you need to specify which one you want. View the actual download_dataset.sh to see the argument options.

thanks


act_size (v2) larger than the number of actuators

Hi,
I noticed something unexpected while playing with the humanoid environment in BRAXv2.
The MJCF file defines 17 actuators (linked to 17 joints + a free joint for the root of the character).
The link_types string of this system looks like f2131312121, which can be read as "free joint, 2 joints, 1 joint, etc". That is logical, as 2+1+3+1+3+1+2+1+2+1 = 17.
Now, the act_size of the system is expected to be 17 as well, since there are 17 motors associated to 17 hinge joints with 1DoF each. However, the act_size of this system is not 17 but 35, counting 2DoFs for each joint in a two-joints configuration, and 3DoFs for each joint in a three-joints configuration. Indeed, 2+2 + 1 + 3+3+3 + 1 + 3+3+3 + 1 + 2+2 + 1 + 2+2 + 1 = 35.
I struggle to see if this is the expected behaviour, it seems to me that the act_size should be the sum of the number of DoFs of each joint, in our case, 17.
Can someone explain if my understanding is correct ?
Thanks in advance

Hi @Theo-Cheynel  thanks for pointing this out, should be fixed now!

Thanks ! I'll have a look :smile:
In the meatime, I added pseudo bodies in between all my joints, to convert 3DoF joints to three 1 DoF joints :laughing:

Ah got it, that is indeed annoying to have to do, sorry for the delay!


test script

What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
(Fixes: #ISSUE-ID)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

cc @zhouyuan Could you please check this error?  I can reproduce this error on my machine
-- Found Boost: /usr/local/lib/cmake/Boost-1.72.0/BoostConfig.cmake (found suitable version "1.72.0", minimum required is "1.51.0") found components: context filesystem program_options regex system thread
-- Found folly: /usr/local
CMake Error at velox/CMakeLists.txt:68 (message):
  Velox library not exists:
  /opt/gluten/ep/build-velox/build/velox_ep/_build/release/velox/exec/tests/utils/libvelox_exec_test_lib.a
Call Stack (most recent call first):
  velox/CMakeLists.txt:125 (add_velox_dependency)
  velox/CMakeLists.txt:348 (add_velox_dependencies)

@zhouyuan @dcoliversun
Velox removed the VELOX_BUILD_BENCHMARKS flag recently, which is causing this
https://github.com/facebookincubator/velox/commit/f2cdf813be50cc165a104b93cabbb56319bd4822

@surnaik Thanks for reply. @PHILO-HE is working on this :)https://github.com/oap-project/gluten/issues/4159#issuecomment-1869197230

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_master_01_03_2024_time.csv
log/native_master_01_02_2024_3660e312c_time.csv
difference
percentage

q1
32.78
35.26
2.480
107.57%

q2
23.75
25.20
1.452
106.12%

q3
37.47
38.24
0.771
102.06%

q4
40.67
39.14
-1.524
96.25%

q5
73.42
71.45
-1.964
97.33%

q6
6.78
7.09
0.311
104.59%

q7
85.99
86.43
0.442
100.51%

q8
88.32
85.68
-2.642
97.01%

q9
126.96
123.79
-3.175
97.50%

q10
44.95
43.72
-1.234
97.25%

q11
19.97
20.90
0.932
104.67%

q12
28.06
26.34
-1.725
93.85%

q13
46.25
45.95
-0.298
99.36%

q14
17.13
14.28
-2.850
83.36%

q15
28.28
28.62
0.332
101.17%

q16
15.84
15.25
-0.591
96.27%

q17
102.58
102.80
0.227
100.22%

q18
148.96
149.26
0.299
100.20%

q19
14.29
12.84
-1.450
89.86%

q20
28.11
27.65
-0.462
98.36%

q21
232.01
227.40
-4.609
98.01%

q22
13.97
14.05
0.084
100.60%

total
1256.55
1241.36
-15.192
98.79%


Unable to parse valid NACHA files containing POP and ARC SEC Codes when SCC is set to 200

ACH Version: v1.18.6
What were you trying to do?
Trying to parse valid NACHA files we received from a correspondent bank. The NACHA files themselves were very similar to the MOOV examples for https://github.com/moov-io/ach/blob/master/test/ach-arc-read/arc-debit.ach and https://github.com/moov-io/ach/blob/master/test/ach-pop-read/pop-debit.ach with one change, the Service Class Code being set to 200
What did you expect to see?
The files being parsed successfully
What did you see?
A validation error stating
{
    "ID": "b9c09fab3229f13f8cdadd7d0fea1c50bb71de4d",
    "error": "line:4 record:Batches *ach.BatchError batch #1 (POP) ServiceClassCode header SCC is not valid for this batch's type: 220"
}

How can we reproduce the problem?
Replace the SCC on https://github.com/moov-io/ach/blob/master/test/ach-pop-read/pop-debit.ach with 200 and try parsing the file

While it is true that Ideally the batches for POP and ARC should have had Service Class Code set to 225 / Debits Only, It does look like there are ACH Originators who set the Service Class Code for a batch to Mixed Debits and Credits (200) and send out only Debits. Maybe we should modify the strict validation the Moov library does at https://github.com/moov-io/ach/blob/master/batchPOP.go#L65 to allow the same?

I have sent MR.

I've released v1.19.2 with this fix. Thanks again!
https://github.com/moov-io/ach/releases/tag/v1.19.2


Typo in error message: "Oops, there is a 'program' converting your code"

program should be problem in error message when code cannot convert to blocks

This is a duplicate of issue 98, which has been fixed. This issue can be closed.

still have repo on codethemicrobit.com though


replace jp2s with jpgs

would require creating jpgs instead of jp2 derivatives in duracloud
potential codebase changes that look for jp2s

kim going to talk to duracloud as a work request

Build local tiff to jpg service. (would execute during ingest process)  Store jpgs locally for IIF viewer/service. (reduce package sizes on duracloud)  Batch tiff to jpgs and update repository metadata records.  Disable jp2 option on archivematica.


Return valid pagination links

Query parameter separator should be '&' not ','
Upgrade to go 1.7 is required so we can add a new custom encoder to goa
that turn of & to \u0026 escaping in json strings
Fixes #427
Related #329

[test]

Current coverage is 64.52% (diff: 100%)

No coverage report found for master at d924d3c.

Powered by Codecov. Last update d924d3c...74c8f99


[Draft] Proposal to consolidate the Findings classes

DRAFT This is a draft proposal to update and clean up the findings classes and the related objects.
Note, the existing Security Finding class is pretty much unchanged, the goal is to replace it with the new classes.
This draft is roughly based on the for new Alert and Incident proposals.
Description of the changes:

Cleaned up the base Finding class, so it can be used as a based class by the classes defined in the Findings category.
New and updated classes:

Security Alert
Security Incident
Malware Finding (new)
Vulnerability Finding

Updated the descriptions of the Alert and Incident classes using on the NIST definitions.
To be consistent with the security profiles, used disposition_id/disposition instead of resolution_id/resolution. Updated the disposition_id values to match the different use-cases.
Cleaned up the Finding object and replaced the conclusions with findings.
Use the existing detection_uid attribute instead of defining new attributes such as incident_uid, alert_uid, etc.
Cleaned up the Analytic object.
Added a new sub_technique attribute to the MITRE Attack object.
Added a new CIS Benchmark object (cis_benchmark) to replace the existing cis_benchmark_result object.
Cleaned up the CIS Control object.

Review the proposal
The best way to review the proposal is to run locally the schema server using the origin/findings branch:
# clone the schema repo into a new ocsf-schema-findings folder
git clone https://github.com/ocsf/ocsf-schema.git ocsf-schema-findings
cd ocsf-schema-findings

# checkout the findings branch
git fetch
git branch findings origin/findings
git checkout findings

# start the schema server:
SCHEMA_DIR=../ocsf-schema-findings SCHEMA_EXTENSION=extensions iex -S mix phx.server

Changes proposed in this draft have been reviewed and addressed in separate PRs. Closing this out.


Can we safely support composing stores (like Redux)?

If not, add explicit advice to the README about how to scale to lots of properties.

This is the first thing I miss from this (otherwise) nice library. How to scale?

Hi @danigb! You have a few good options now:

Use a single store, and namespace properties in the store with a prefix.
Use multiple stores

I'm not sure Redux-style composition is very useful, so this feature would be more for parity and flexibility. Out of curiosity, how does composition help you with your use case?

Tracking this in https://github.com/bcherny/undux/issues/32


[killOnWindows error] { [Error: spawn wmic ENOENT]

my vscode output as follow, 3ks:
[getInstance] ycm is restarting
[start] data: 50293,����W����ץ)�,[object Object]
[processData: {"filepath_completion_use_working_dir":0,"auto_trigger":1,"min_num_of_chars_for_completion":2,"min_num_identifier_candidate_chars":0,"semantic_triggers":{},"filetype_specific_completion_to_disable":{"gitcommit":1},"seed_identifiers_with_syntax":0,"collect_identifiers_from_comments_and_strings":0,"collect_identifiers_from_tags_files":0,"max_num_identifier_candidates":10,"extra_conf_globlist":[],"global_ycm_extra_conf":"","confirm_extra_conf":true,"complete_in_comments":0,"complete_in_strings":1,"max_diagnostics_to_display":30,"filetype_whitelist":{"*":1},"filetype_blacklist":{"tagbar":1,"qf":1,"notes":1,"markdown":1,"unite":1,"text":1,"vimwiki":1,"pandoc":1,"infolog":1,"mail":1},"auto_start_csharp_server":1,"auto_stop_csharp_server":1,"use_ultisnips_completer":1,"csharp_server_port":0,"hmac_secret":"/8gZ9pBXBOqG+LLXpSkDyA==","server_keep_logfiles":0,"gocode_binary_path":"","rustSrcPath":""}]
[start] optionsFile: /var/folders/9n/yh5151xx7g34sm_k1ckzk07m0000gn/T/VSCodeYcmOptions-1477299539099
[_start] [ '/Users/baidu/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd',
'--port=50293',
'--options_file=/var/folders/9n/yh5151xx7g34sm_k1ckzk07m0000gn/T/VSCodeYcmOptions-1477299539099',
'--idle_suicide_seconds=600' ]
[_start] process spawn success 8372
[start] ycm started: 8372
[killOnWindows error] { [Error: spawn wmic ENOENT]
code: 'ENOENT',
errno: 'ENOENT',
syscall: 'spawn wmic',
path: 'wmic',
spawnargs:
[ 'process',
'where',
'(ParentProcessId=8372)',
'get',
'processid' ] }
[saveYcmdPidWindows] windows ycmd pid=undefined
[ycm stderr] 2016-10-24 17:08:59,559 - INFO - Server shutting down
[ycm stdout] serving on http://<IP_ADDRESS>:50293
[_start exit] 0

it seems that the option_file is non-existent。

Looks like you're not using windows?

I've updated a new version (1.0.24), could you please update to the newest version and try again?


Large data set animation lag

The line chart starts to drop some frames if the data set gets large on iOS. Under 45 items never drops frames. Under 55 is pretty reliable, but occasionally will. Once you get over 70, it's consistently dropping frames on the UI thread when animating. I wonder if there could be optimizations for this.
Possible ideas:

Investigate the fastest way to do a for loop, since we're looping through lots of data (for (let i = 0) vs .map)
Could we turn the data array into a shared value under the hood?
Since parse(path) gets used in a few places, maybe we should offload that to the provider to reduce the number of times it gets calculated.
Fork the redash helpers and try to optimize them if possible.

These are just a few off-hand ideas. I would have to do more digging.

Could we turn the data array into a shared value under the hood?

Yeah, I think this would be the main catalyst to greatly increasing the performance. I really want to toy with the idea of making a shared value version of the data prop. This may create a breaking change though, so we would either have to: document that, or create an alternative prop for shared values (I think I would prefer this method), such as reanimatedData or something.
All the other points are great ideas.

A different prop could work. It might not be necessary though. Moti lets you pass shared values or the values themselves as props. Under the hood, it checks if it’s a shared value or a normal object inside of a derived value. So we might be able to get away with that.
But you’re right, it would be a breaking change for the consumers using data from useLineChart. So at the very least, useLineChart would need to return a different value to be backwards compatible.
I think a different prop could work well though.

Oh right that makes sense!
I can put this on my TODOs for this week!

You might be right tbh, I’m not totally sure. The best possible performance is probably sticking with Reanimated in every step possible. They don’t offer the clearest guidance on performance implications of bringing JS objects into worklets.
Also, not sure if this matters for arrays, but dictionaries going from JS to UI thread don’t preserve key order. I’ve opened an issue already since this was annoying for Moti + transform style props changing order. Since we’re using arrays, this shouldn’t really be an issue if we turn JS values into shared values, but something to keep in mind ahead of time.

Been investigating making data a shared value under the hood. Seems like this problem is really not trivial as reanimated doesn't really have first-class support for external library imports. We would probably have to find a way to convert libraries such as d3-scale and d3-shape to be worklet compatible. Will probably need a bit more time to look into this one.

Relevant: https://github.com/software-mansion/react-native-reanimated/issues/1302
Also: https://github.com/sbycrosz/d3-interpolate-path/tree/feat/react-native-reanimated-support

@jxom I wonder if we should open this as an issue on Redash and specify the exact functions we want to workletize. I think it would fit better there.

Also https://twitter.com/terrysahaidak/status/1464311437954854921?s=20
looks like we should do normal for loops. I believe the technical fastest way to do them is i--. Curious if it would make a difference here.

Has there been any progress here?

i wanted to know
Has there been any progress here?


From my understanding the reason for it - when terminal is killed process inside this terminal recieves SIGHUP instead of SIGINT or SIGTERM.
Would be good if concurrently can handle SIGHUP too and pass this signal to child processes.

👍 SGTM. Happy to get PRs for this!

Landed on v5.0.0!


New app: F1 Results

With the start of the new F1 season, I've made an app that shows qualifying and race results for the latest round with some additional options to show for the race results.
Note that this is not a live timing app! It just shows the results after the qualifying session or race is over
Credit to @AmillionAirs and @jvivona for the idea and providing a very handy F1 API

wanted to give you a heads up - the ergast folks still have the Tidbyt servers (IP) on their blacklist & so when this goes into production - you aren't going to get any data.    I've been working with him on showing that the new versions of the app(s) aren't going to flood his server (it's seems like it's literally 1 guy who does this).    For right now I've been caching the data locally on one of our servers & pointing the apps to our servers.

Ah that's a shame!
My calls are once an hour just to check if the race is complete. Then if its more than 48hrs after the race has completed it calls the data for the next race and caches that for 24hrs. So this doesn't poll his API that much. His own responsible use policy says no more than 200 times per hour.
Anyway I might put this on hold then until you can assure him we're not bad guys!
Thanks for letting me know

I'm going to ping you on Discord...

FYI for the approvers - @jvivona has kindly offered to host the APIs I need as they have done for the other F1 app. So this one should be ready to go

Thanks for the PR!


fix: Try to open all files before final die

@Ms2ger does this make more sense?

@Ms2ger does this make more sense?


nm.device: support reapply on IPv6 changes

Support reapply on IPv6 changes as it is supported by NetworkManager
again. In addition, we are supporting the workaround if the
NetworkManager version is lower than 1.20.
Signed-off-by: Fernando Fernandez Mancera<EMAIL_ADDRESS>

Coverage remained the same at 61.684% when pulling d16db6f1e239c932c50ccf3988bd9735366c35e3 on ffmancera:ipv6_reapply into 61783d739ff6314666873e0505718e69455cc80f on nmstate:master.


How to config activity camera landscape?

I config the camera activity orientation on Manifest.xml is landscape and camera display error
Configutation line: android:screenOrientation="landscape"
And issue occurred like below screenshot:

Hi @tuzenvn,
Currently if you remove the screenOrientation parameter in the manifest and simply rotate the phone then landscape mode should work.
There is a bug currently where the screenOrientation specified as landscape in the manifest file doesn't work as intended and gives the result you are seeing.
For now if you need to lock the orientation to landscape you can try overloading the following function in your Activity:
@Override
   public void onConfigurationChanged(Configuration newConfig) {
       super.onConfigurationChanged(newConfig);
       this.setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
   }

Let me know if that works! Once the bug with the screenOrientation in the manifest is fixed I'll update this github issue.

Thanks a lot @VikAdvani,
My app required to lock the orientation to landscape, I add android:screenOrientation="landscape" in Manifest and in Activity I isue:
mViroViewARCore.setCameraRotation(android.content.pm.ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);


ext_workspace_unstable: zext_workspace_handle_v1.activate() is ignored

Relevant issue: https://github.com/hyprwm/Hyprland/issues/381
From that issue:

The protocol itself does not support that

But I think it does? From the protocol:

<request name="activate">
	<description summary="activate the workspace">
		Request that this workspace be activated.

		There is no guarantee the workspace will be actually activated, and
		behaviour may be compositor-dependent. For example, activating a
		workspace may or may not deactivate all other workspaces in the same
		group.
	</description>
</request>

done in 086f7249514fcbaf10247ee7bd2c5ddad643d898
rust sucks

Thanks, it works 😺


The fact that start date and end date are on separate pages is annoying

The start date (and estimated hours etc.) for a task is on the Summary page, but the end/due date is on the "Edit task" page... ideally those two should be presented on the same page. It's annoying (and a bit confusing) to constantly switch pages and have to save changes multiple times (also spamming notifications because of that).

I changed that in master.


DiffableTextStyle.

It can be reduced to two methods (plus localization)—one for upstream and one for downstream. All other requirements can be remade as style specific implementation details. I'll fix this first, then see how that affects the other issues.

Or 3 methods to separate the active and inactive state. There is also no reason to perform a snapshot when the view is idle, so that method may return text to save on resources. I’m thinking something like:

func showcase(value: Value) -> String
func editable(value: Value) -> Output
func merge(snapshot: Snapshot, input: Input) throws -> Output


Vec::iter_revi semantics seem uninutitive

the name may look better like iter_revi
i for the first itered element is not 0 but the length - 1, is this the correct behavior?

In terms of iteration order, i should start at 0, but in terms of the index of the array, i should start at length - 1. Which of these two is better?

suppose you have fold_lefti, fold_righti, both are expected to start from 0

In terms of iteration order, i should start at 0, but in terms of the index of the array, i should start at length - 1. Which of these two is better?

OCaml (Jane Street) base library takes the former one list.ml .


Uses process credential on main thread

This should be a correct one. I don't think the PS4 will allow the application main thread to use SceSysCore credential because it is a privileged one. We can find the correct answer without guessing in the function that do thread switching but the problem is I don't know where it is.

Now we instantly fail on syscall 147 :(

The good news about this is it is a correct path for the games.

Strange. Why you got int44. For me it is end up in sys_write.

And what happens after you implement it? Or rather, after you fake it and just return the len right away?

"Scepthread: Fatal error 'Can't set session id to 2 (errno = 1)'" is what it's trying to write for me btw

Strange. Why you got int44. For me it is end up in sys_write.

Sorry btw, I myself didn't realize that I had sys_write stubbed. I merged main into my WIP branch. By the way, we should be thinking about sys_mmap_dmem, that seems to be the main obstacle that's ahead of us.

I'll let you guys handle that. What I'm currently focus on is moving the application to run inside a VM.

Where do we even begin? 👀

Wait, you said @mikusp already have some ideas.

He has some ideas for dmem, but not for the privilege issue, that's what I was talking about.

Strange. Why you got int44. For me it is end up in sys_write.

You mean you got int44 after this?

yup

I guess I didn't actually say that 😅 Yeah, I get it right after. And from the description, it seems that it's the sys_setid. However, that means that is_system has to be true, doesn't it? 🤔

However, that means that is_system has to be true, doesn't it?

It should not. I'm confused why it raise int44. It seems like the PS4 expect the process to be a system process somehow.


Conan extraArguments attribute does not handle spaces correctly on Windows

Describe the bug
The extraArguments attribute of the ArtifactoryConan@1 task doesn't generate a Conan command correctly if one of the arguments contains a space. This can cause the build to fail.
To Reproduce
Assuming you have a suitable Conan package in the current working directory, add this task to the YAML build pipeline on a Windows build agent:
- task: ArtifactoryConan@1
  inputs:
    conanCommand: 'Create'
    createPath: '.'
    createReference: 'test-user/test-channel'
    extraArguments: '--env TEST_VAR="hello world"'

Expected behavior
The task should generate a valid Conan create command, with an environment variable called TEST_VAR set to value "hello world".
Actual behaviour
When the pipeline runs, it tries to execute the create command like this:
conan.exe create --env "TEST_VAR=\"hello" "world\"" D:\a\1\s\test-project test-user/test-channel

It fails with this error:
conan create: error: unrecognized arguments: test-user/test-channel

This seems to happen because the "hello world" value has been split up at the space. The Conan command only sees ""hello" as part of the environment variable, and then tries to parse "world"" as the path of the Conan recipe.
Versions

Artifactory Azure DevOps extension version: 1.10.0
Agent operating system: Microsoft-hosted agent - vs2017-win2016
JFrog Artifactory version: n/a

Additional context
I'm trying to use this to pass a file path as an environment variable to the Conan recipe. The path comes from a pipeline variable defined by a previous step. As such, I can't manually modify it or escape it.

Is this bug about to be fixed soon?
We have a problem, as the compiler "visual studio" has spaces... and can't be set,
passing it using conan command works just fine, but never tried to collect build info using cli yet.


Install Compreface on docker desktop.

Compreface-core is always restarting.

Docker restarting (132)
Installation on other windows computer give no ploblem.
Logs
024-02-07 19:43:42 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:43:42 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:43:42 2024] ***
2024-02-07 19:43:42 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:43:42 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:43:42 nodename: 1165252f5ae0
2024-02-07 19:43:42 machine: x86_64
2024-02-07 19:43:42 clock source: unix
2024-02-07 19:43:42 pcre jit disabled
2024-02-07 19:43:42 detected number of CPU cores: 4
2024-02-07 19:43:42 current working directory: /app/ml
2024-02-07 19:43:42 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:43:42 setgid() to 33
2024-02-07 19:43:42 setuid() to 33
2024-02-07 19:43:42 your memory page size is 4096 bytes
2024-02-07 19:43:42 detected max file descriptor number: 1048576
2024-02-07 19:43:42 lock engine: pthread robust mutexes
2024-02-07 19:43:42 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:43:42 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:43:42 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:43:42 Python main interpreter initialized at 0x55746e2d6810
2024-02-07 19:43:42 python threads support enabled
2024-02-07 19:43:42 your server socket listen backlog is limited to 100 connections
2024-02-07 19:43:42 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:43:42 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:43:42 *** Operational MODE: preforking ***
2024-02-07 19:43:48 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:43:48 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:43:48 2024] ***
2024-02-07 19:43:48 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:43:48 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:43:48 nodename: 1165252f5ae0
2024-02-07 19:43:48 machine: x86_64
2024-02-07 19:43:48 clock source: unix
2024-02-07 19:43:48 pcre jit disabled
2024-02-07 19:43:48 detected number of CPU cores: 4
2024-02-07 19:43:48 current working directory: /app/ml
2024-02-07 19:43:48 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:43:48 setgid() to 33
2024-02-07 19:43:48 setuid() to 33
2024-02-07 19:43:48 your memory page size is 4096 bytes
2024-02-07 19:43:48 detected max file descriptor number: 1048576
2024-02-07 19:43:48 lock engine: pthread robust mutexes
2024-02-07 19:43:48 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:43:48 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:43:48 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:43:48 Python main interpreter initialized at 0x555a50796810
2024-02-07 19:43:48 python threads support enabled
2024-02-07 19:43:48 your server socket listen backlog is limited to 100 connections
2024-02-07 19:43:48 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:43:48 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:43:48 *** Operational MODE: preforking ***
2024-02-07 19:43:55 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:43:55 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:43:55 2024] ***
2024-02-07 19:43:55 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:43:55 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:43:55 nodename: 1165252f5ae0
2024-02-07 19:43:55 machine: x86_64
2024-02-07 19:43:55 clock source: unix
2024-02-07 19:43:55 pcre jit disabled
2024-02-07 19:43:55 detected number of CPU cores: 4
2024-02-07 19:43:55 current working directory: /app/ml
2024-02-07 19:43:55 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:43:55 setgid() to 33
2024-02-07 19:43:55 setuid() to 33
2024-02-07 19:43:55 your memory page size is 4096 bytes
2024-02-07 19:43:55 detected max file descriptor number: 1048576
2024-02-07 19:43:55 lock engine: pthread robust mutexes
2024-02-07 19:43:55 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:43:55 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:43:55 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:43:55 Python main interpreter initialized at 0x561d83575810
2024-02-07 19:43:55 python threads support enabled
2024-02-07 19:43:55 your server socket listen backlog is limited to 100 connections
2024-02-07 19:43:55 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:43:55 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:43:55 *** Operational MODE: preforking ***
2024-02-07 19:44:04 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:44:04 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:44:04 2024] ***
2024-02-07 19:44:04 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:44:04 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:44:04 nodename: 1165252f5ae0
2024-02-07 19:44:04 machine: x86_64
2024-02-07 19:44:04 clock source: unix
2024-02-07 19:44:04 pcre jit disabled
2024-02-07 19:44:04 detected number of CPU cores: 4
2024-02-07 19:44:04 current working directory: /app/ml
2024-02-07 19:44:04 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:44:04 setgid() to 33
2024-02-07 19:44:04 setuid() to 33
2024-02-07 19:44:04 your memory page size is 4096 bytes
2024-02-07 19:44:04 detected max file descriptor number: 1048576
2024-02-07 19:44:04 lock engine: pthread robust mutexes
2024-02-07 19:44:04 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:44:04 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:44:04 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:44:04 Python main interpreter initialized at 0x55bb9271a810
2024-02-07 19:44:04 python threads support enabled
2024-02-07 19:44:04 your server socket listen backlog is limited to 100 connections
2024-02-07 19:44:04 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:44:04 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:44:04 *** Operational MODE: preforking ***
2024-02-07 19:44:11 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:44:11 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:44:11 2024] ***
2024-02-07 19:44:11 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:44:11 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:44:11 nodename: 1165252f5ae0
2024-02-07 19:44:11 machine: x86_64
2024-02-07 19:44:11 clock source: unix
2024-02-07 19:44:11 pcre jit disabled
2024-02-07 19:44:11 detected number of CPU cores: 4
2024-02-07 19:44:11 current working directory: /app/ml
2024-02-07 19:44:11 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:44:11 setgid() to 33
2024-02-07 19:44:11 setuid() to 33
2024-02-07 19:44:11 your memory page size is 4096 bytes
2024-02-07 19:44:11 detected max file descriptor number: 1048576
2024-02-07 19:44:11 lock engine: pthread robust mutexes
2024-02-07 19:44:11 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:44:11 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:44:11 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:44:11 Python main interpreter initialized at 0x560e4e548810
2024-02-07 19:44:11 python threads support enabled
2024-02-07 19:44:11 your server socket listen backlog is limited to 100 connections
2024-02-07 19:44:11 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:44:11 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:44:11 *** Operational MODE: preforking ***
2024-02-07 19:44:19 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:44:19 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:44:19 2024] ***
2024-02-07 19:44:19 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:44:19 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:44:19 nodename: 1165252f5ae0
2024-02-07 19:44:19 machine: x86_64
2024-02-07 19:44:19 clock source: unix
2024-02-07 19:44:19 pcre jit disabled
2024-02-07 19:44:19 detected number of CPU cores: 4
2024-02-07 19:44:19 current working directory: /app/ml
2024-02-07 19:44:19 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:44:19 setgid() to 33
2024-02-07 19:44:19 setuid() to 33
2024-02-07 19:44:19 your memory page size is 4096 bytes
2024-02-07 19:44:19 detected max file descriptor number: 1048576
2024-02-07 19:44:19 lock engine: pthread robust mutexes
2024-02-07 19:44:19 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:44:19 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:44:19 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:44:19 Python main interpreter initialized at 0x55f9a053e810
2024-02-07 19:44:19 python threads support enabled
2024-02-07 19:44:19 your server socket listen backlog is limited to 100 connections
2024-02-07 19:44:19 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:44:19 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:44:19 *** Operational MODE: preforking ***
2024-02-07 19:44:26 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:44:26 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:44:26 2024] ***
2024-02-07 19:44:26 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:44:26 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:44:26 nodename: 1165252f5ae0
2024-02-07 19:44:26 machine: x86_64
2024-02-07 19:44:26 clock source: unix
2024-02-07 19:44:26 pcre jit disabled
2024-02-07 19:44:26 detected number of CPU cores: 4
2024-02-07 19:44:26 current working directory: /app/ml
2024-02-07 19:44:26 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:44:26 setgid() to 33
2024-02-07 19:44:26 setuid() to 33
2024-02-07 19:44:26 your memory page size is 4096 bytes
2024-02-07 19:44:26 detected max file descriptor number: 1048576
2024-02-07 19:44:26 lock engine: pthread robust mutexes
2024-02-07 19:44:26 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:44:26 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:44:26 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:44:26 Python main interpreter initialized at 0x55e9629a8810
2024-02-07 19:44:26 python threads support enabled
2024-02-07 19:44:26 your server socket listen backlog is limited to 100 connections
2024-02-07 19:44:26 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:44:26 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:44:26 *** Operational MODE: preforking ***
2024-02-07 19:44:37 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:44:37 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:44:37 2024] ***
2024-02-07 19:44:37 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:44:37 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:44:37 nodename: 1165252f5ae0
2024-02-07 19:44:37 machine: x86_64
2024-02-07 19:44:37 clock source: unix
2024-02-07 19:44:37 pcre jit disabled
2024-02-07 19:44:37 detected number of CPU cores: 4
2024-02-07 19:44:37 current working directory: /app/ml
2024-02-07 19:44:37 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:44:37 setgid() to 33
2024-02-07 19:44:37 setuid() to 33
2024-02-07 19:44:37 your memory page size is 4096 bytes
2024-02-07 19:44:37 detected max file descriptor number: 1048576
2024-02-07 19:44:37 lock engine: pthread robust mutexes
2024-02-07 19:44:37 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:44:37 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:44:37 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:44:37 Python main interpreter initialized at 0x555d4b20c810
2024-02-07 19:44:37 python threads support enabled
2024-02-07 19:44:37 your server socket listen backlog is limited to 100 connections
2024-02-07 19:44:37 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:44:37 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:44:37 *** Operational MODE: preforking ***
2024-02-07 19:44:54 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:44:54 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:44:54 2024] ***
2024-02-07 19:44:54 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:44:54 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:44:54 nodename: 1165252f5ae0
2024-02-07 19:44:54 machine: x86_64
2024-02-07 19:44:54 clock source: unix
2024-02-07 19:44:54 pcre jit disabled
2024-02-07 19:44:54 detected number of CPU cores: 4
2024-02-07 19:44:54 current working directory: /app/ml
2024-02-07 19:44:54 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:44:54 setgid() to 33
2024-02-07 19:44:54 setuid() to 33
2024-02-07 19:44:54 your memory page size is 4096 bytes
2024-02-07 19:44:54 detected max file descriptor number: 1048576
2024-02-07 19:44:54 lock engine: pthread robust mutexes
2024-02-07 19:44:54 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:44:54 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:44:54 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:44:54 Python main interpreter initialized at 0x56337e4e2810
2024-02-07 19:44:54 python threads support enabled
2024-02-07 19:44:54 your server socket listen backlog is limited to 100 connections
2024-02-07 19:44:54 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:44:54 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:44:54 *** Operational MODE: preforking ***
2024-02-07 19:45:24 [uWSGI] getting INI configuration from uwsgi.ini
2024-02-07 19:45:24 *** Starting uWSGI 2.0.19 (64bit) on [Wed Feb  7 18:45:24 2024] ***
2024-02-07 19:45:24 compiled with version: 10.2.1 20210110 on 14 August 2023 20:24:09
2024-02-07 19:45:24 os: Linux-<IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
2024-02-07 19:45:24 nodename: 1165252f5ae0
2024-02-07 19:45:24 machine: x86_64
2024-02-07 19:45:24 clock source: unix
2024-02-07 19:45:24 pcre jit disabled
2024-02-07 19:45:24 detected number of CPU cores: 4
2024-02-07 19:45:24 current working directory: /app/ml
2024-02-07 19:45:24 detected binary path: /usr/local/bin/uwsgi
2024-02-07 19:45:24 setgid() to 33
2024-02-07 19:45:24 setuid() to 33
2024-02-07 19:45:24 your memory page size is 4096 bytes
2024-02-07 19:45:24 detected max file descriptor number: 1048576
2024-02-07 19:45:24 lock engine: pthread robust mutexes
2024-02-07 19:45:24 thunder lock: disabled (you can enable it with --thunder-lock)
2024-02-07 19:45:24 uwsgi socket 0 bound to TCP address <IP_ADDRESS>:3000 fd 3
2024-02-07 19:45:24 Python version: 3.8.17 (default, Jul 28 2023, 06:10:22)  [GCC 10.2.1 20210110]
2024-02-07 19:45:24 Python main interpreter initialized at 0x55d7752d1810
2024-02-07 19:45:24 python threads support enabled
2024-02-07 19:45:24 your server socket listen backlog is limited to 100 connections
2024-02-07 19:45:24 your mercy for graceful operations on workers is 60 seconds
2024-02-07 19:45:24 mapped 218712 bytes (213 KB) for 2 cores
2024-02-07 19:45:24 *** Operational MODE: preforking ***
What can be the problem?

I encountered the same problem 。。。。

答案：https://github.com/exadel-inc/CompreFace/issues/1026


Add a folder for program in Python for Selection sort.

@ADITIBAGADDEO22 assign this to me.

@ADITIBAGADDEO22 assign this to me.

Follow the folder sequence and add algorithm accordingly.


Place tag highlight to the right in the scrollbar ruler

Currently comment-anchors put tag highlight on the left side of the scrollbar ruler, but the left side area often contains vscode build-in git highlight, in this case it will mix them up(pointed in the image) which will make people like me confused.

I think it will be better and clearer to place tag highlight to the right in the scrollbar ruler.

Thanks for your issue!
You should be able to change the positioning of the ruler highlight with the commentAnchors.tags.rulerStyle setting, or optionally disable it with the commentAnchors.tags.displayInRuler setting.

Thanks! It helps me a lot.


How to use redux-saga with event emmiters?

I had an API call made with a promise, called with call, and it was great. But I wanted to show a progress bar of the download (the API response is very large), and fetch doesn't support progress update, so I rewrote it using an XMLHttpRequest, but I don't know how to connect it to a saga. This would be the code:
function * download () {
  const xhr = new XMLHttpRequest()
  xhr.open('GET', `/verylargedownload`, true)

  xhr.onload = (e) => {
    yield put({type: DOWNLOAD_SUCEEDED, data: xhr.response})
  }

  xhr.onprogress = (e) =>  {
    yield put({type: UPDATE_DOWNLOAD_PROGRESS, progressEvent: e})
  }

  xhr.onerror = (e) => {
    yield put({type: DOWNLOAD_FAILED, error: e)
  }

  xhr.send()
}

Of course this code is wrong, but it roughly explains why I'm trying to do.
I also know that it would be trivial to implement with redux-thunk, but that's not the point.

Take a look at http://yelouafi.github.io/redux-saga/docs/advanced/Channels.html, specially eventChannel.

Oh, exactly what I was looking for. Thanks.


enableManifestClasspath should also affect linux and init.sh start scripts

You can now define a customClasspath for the distribution which will
override the expansion of all *.jar files in the runtime configuration.

This change is

further, we should fix the classpath at compile time; so it shouldn't contain * and other run-time -evaluated things like ../ etc

I still think this is a little convoluted, sorry. (I should have been more specific here from the start.) The default behaviour is to to use the concatenation of the jar and the runtime dependencies. I would propose to make provide an optional FileCollection classpath configuration point such that: if it is set, then this FileCollection becomes the classpath, else the default is the classpath (see above).

Review status: 0 of 5 files reviewed at latest revision, 1 unresolved discussion.

a discussion (no related file):
Further, the ManifestClasspathJarTask must be updated accordingly, so this is likely a slightly bigger refactor.

Comments from Reviewable

So this PR is now about enabling the classpath jar, rather than about allowing to customize the classpath, right?

Review status: 0 of 5 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 3 unresolved discussions.

src/test/groovy/com/palantir/gradle/javadist/JavaDistributionPluginTests.groovy, line 338 at r3 (raw file):

    }

    def 'produces manifest-classpath jar and windows start script with no classpath length limitations'() {

stale test name

src/test/groovy/com/palantir/gradle/javadist/JavaDistributionPluginTests.groovy, line 362 at r3 (raw file):

        String launcher = file('dist/service-name-0.1/service/bin/launcher-static.yml', projectDir).text
        !launcher.contains("external.jar")
    }

would like to see an end-to-end test for launching the service through the unix classpath jar

Comments from Reviewable

Reviewed 5 of 7 files at r3.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

Comments from Reviewable

Done, but producing a manifest classpath jar is busted until you merge in YY's commit fixing how the plugin reaches into the gradle object model

Closing since there wasn't much  movement. Feel free to reopen if this is still an issue.


Despite using --init option, it's still trying to initialize a git repository

Describe the bug
cargo-generate with --init is still trying to initialize a git repository. I wanted to use my already existing Github repository.
make sure you

[x] I'm on the latest rust version rustup update
[x] I'm on the latest cargo-generate version cargo install cargo-generate

To Reproduce
Steps to reproduce the behavior:

git clone my already existing repository, enter the directory.
cargo generate --init --git https://github.com/aya-rs/aya-template
Answered all the prompt questions.
See error:

Error: ⚠   File already exists: /home/vadorovsky/repos/aya-btf-maps/.git/index

Expected behavior
Because of using --init option, I would expect cargo-generate to not try to create any files in .git.
Screenshots

Desktop (please complete the following information):

OS: Manjaro Linux
Version: rolling releasse
Build tools: gcc
Shell: nushell
rustc --version: rustc 1.64.0 (a55dd71d5 2022-09-19)
cargo generate --version: cargo-generate 0.16.0

Additional context

This bug can be tested with the following script:
#!/bin/sh
set -xe

cargo build

rm -rf test
mkdir test
git -C test init
sh -c 'cd test && ../target/debug/cargo-generate generate --git https://github.com/rustwasm/wasm-pack-template --name=foo --init'


fix shrinkwrap

You have committed a shrinkwrap version that don't match devDependencies

Hey lcalvy. If you look at the test details, I'm afraid nothing actually passed despite the false positive (not sure why failing to run counts as passing). Some of the entries in the shrinkwrap file that you removed, like gobble-babel, were the point of the shrinkwrap in the first place -- there were problems with needing to specify upper version bounds for dependencies-of-dependencies.
I just used the npm command to generate it and I don't doubt it could use cleaning up. If you can get it to pass I'd be happy to merge.

Closing since it's been a while with no response -- if you do have a working version / more detailed explanation of what you're seeking to address feel free to comment & I can reopen it.


Up-to-date check is broken for resources that have a map to be late-initialized

What happened?
When a resource has a map field with at least one value, it's not late-initialized because the field is considered to have non-zero value, hence the user's desire about the field. However, in some cases, external APIs assign defaults to other fields of the same map. So, you end up with a map that is not late initialized but also doesn't match what's in the cloud API, so it repeatedly reports that resource is not up to date.
How can we reproduce it?
aws_backup_region_settings resource gets to Ready and Synced states but it never marks Test state to be True, which is how we make sure resource gets into a stable state where there is no update needed. So, at every reconcile, it requests the update call to be made. The reason is that it has two maps under spec.forProvider and if you give only some of the fields, then it reports diff since it can't fill the rest with late-init.

Currently we don't have an assessment of the impact and we will revisit this. Please add your example if you encounter this.


Offer to install IngressController with HostPort

Expected Behaviour

We should offer to install IngressController with HostPort for Kubernetes running on bare metal, or where an LB is not available. This could also reduce the cost for testing clusters by removing the need for an LB.
This would also enable the use-case with "k3s" from @ibuildthecloud
Possible Solution

See the Nginx helm chart on configuring a HostPort / Host networking so that the ingress controller binds to port 80/443 from the container.

@affix fixed and available