Add Istiod internal caching for generated XDS responses

EDS: #26024
CDS: https://github.com/istio/istio/pull/33338
LDS: Not started
RDS: https://github.com/istio/istio/pull/34243
SDS: done in initial PR

For posterity, can we have a rough write up of how the caching will be done for each XDS resource, in this issue? It will help spot design issues of any, as well as discuss caveats for various conditions like same service entry in different namespaces, etc.

With regard to caching, I think we need to determine a few things before hand:

Unit of caching - individual resource or the entire list [pros of individual resource is that memory consumption may be low but the code will become complicated as we will have to apply transformations before sending (envoyFilters, possibly sidecars, etc.). Caching an entire list means we will have many sets of caches for different "groups" of proxies but we wont have to do any transformation before sending the data out]

Cache keys - determine how we are going to reuse a cached entry.
Istio Configs for a proxy are selected based on its labels, its namespace and whatever is visible to that namespace (exportTo).
Generated configs for a proxy depend on the proxy version, proxy type, proxy domain (which is used to auto fill vs/dr), one or more metadata embedded in the proxy, as well as the Istio configs for that proxy.
So its safe to say that a key containing a redacted version of the XDS Node metadata (including namespace, labels, istio_meta stuff, but excluding the proxy ID, IP, or anything else that is system generated) can be used as a cache key. But if we do this, we automatically fall into the "caching entire list" model because this key will be the same for all pods of a deployment [i.e. all pods sharing the exact same set of labels in a given namespace].

Invalidation. As @ramaraochavali mentioned in the EDS PR, we may either need some LRU or a periodic cache refresh where we throw away all the existing data and regenerate the cache every 30s or so (this will result in a saw toothed memory consumption curve at worst, but memory wont grow unbounded). I think the periodic refresh is an easier way to lock down memory leaks.

Correctness proof. The cache we have is not the same as some DB lookup cache as this is generated data that takes into account a complex set of attributes from the environment. We need some way (even if its on paper design) to run through the correctness of a cached entry - i.e. is it truly applicable to the given proxy or are we sending it the wrong set of configs. For example, in the EDS cache implementation we have today, the key does not include proxy Labels. So, if two proxies have two different Sidecar crds, where each proxy imports a service entry with same host, but containing different sets of endpoints, the cache would return an incorrect data. [You pointed this issue correctly in our previous discussion but I failed to see the nuances].

If we were to work backwards from (4), what is the easiest way to construct the cache (at cost of memory?) with provably correct response data? I think that caching at fine grained levels and then selectively applying EnvoyFilters, Sidecars, or what not will not be an easy thing to prove for sidecar proxies [the case I provided above is an example]. But I am interested in hearing counter arguments to this assumption.
OTOH, caching at coarse granularities (like using the node metadata with wildcards for certain fields) makes it easy to reason about the correctness albeit at higher memory cost. We will end up having N sets of complete XDS responses in memory where N is the number of deployments in the system - this will quickly result in OOM unless we aggressively evict items.
[FTR, this is also part of the reason why I am not convinced that an intermediate XDS relay will be of any use as there is too much logic involved in determining whether or not something is resuable].
Thoughts @howardjohn / @hzxuzhonghu / @ramaraochavali ?

Update:
Here is an alternative cache key for better cache utilization.
We can have a two level cache hierarchy. Given a proxy, we can compute set of all configs for that proxy (including networking, security, etc.) and then compute some hash of all these configs. This will be the first level cache key. Within each level, we can cache outbound XDS (rds/cds/lds/eds) in a second level hierarchy, keyed by the node metadata (that includes locality, cluster, network, ISTIO_META vars). We can then always compute the inbound as we are doing today.
So, if two proxies in the same namespace have two different Sidecars or EnvoyFilters mutating different things for same EDS/CDS/LDS/RDS target, then the cache key will naturally be different. But within this set, we should be able to reuse the data across all proxies. If we go one step further to keep the EDS/CDS cache different from LDS/RDS, then LDS/RDS can be used universally based on ISTIO_METAs but irrespective of the proxy's locality/network/cluster while EDS/CDS can be further refined based on both ISTIO_METAs and the locality/network/cluster.

1 Unit of caching

In my opinion, per resource is the only viable way. If you look at resources across a cluster, there is a huge amount of overlap. If you look at resource collections, there is a very small amount - likely just proxies in the same exact deployment in many cases. As a result, our hit rate is way lower, and we need to store way more redundant config (== OOM). With collection storage we have potential N^2 storage - with per resource storage is likely actually smaller memory usage, since instead of generating each resource for each proxy, we generate each resource 1x and send it to each proxy.
If we ignore other proxies, its still be much better. For example, with EDS, with collection caching, if we change a Service, we now invalidate the entire collection. With resource caching, we just invalidate the changed resource - we can still keep all the other resources cached.

2 Cache keys

I do not think we should be caching based on the proxy identity. Rather, we should be caching based on the inputs to the resources we are generating. For example, a given CLA response is based almost entirely on the Service/Endpoints and the network/cluster of a proxy, but also DR for locality lb. The cache need not be aware of any impacts of Sidecar scoping -- instead, the caching logic takes in the inputs needed to construct the resource and uses them as keys. When these change, we invalidate the cache. This means, for example, that if a Sidecar resource no longer selects the DR that applies some locality LB config, we will now have a new key (since DR is part of the key), and get the correct response.
Trying to do things at a higher level is too complicated IMO. There are many many factors from the proxy that determine the output; it is much simpler to look closer to the resource generation to identify what are the true input keys.
In order to ensure we do not take dependencies on resources not part of the caching key/logic, we need to make the inputs to the config gen as narrow as possible. For example, instead of passing mega-structs like PluginParams which attempt to take essentially every bit of information we have about the state of the cluster, we instead finely scope down the inputs. A specific example would be passing in the DestinationRule that will actually be applied, which is read from the PushContext before looking into the cache, rather than PushContext and doing the lookup after the cache lookup.

3 Invalidation

I agree we need some periodic cleanup to prevent cases where keys will never be used again. If a DR is removed, those keys will be removed, but there are ways for things to implicitly never be used which we do not invalidate (new Sidecar means nothing uses the DR, XDS client goes away, etc). For these cases, some LRU type system makes sense. Dropping the entire cache every 30s seems far to aggressive IMO. I doubt we will see sawtooth memory, and instead see needless CPU spikes - but we will need to validate in large scale clusters.
It should be noted that the EDS cache had a trivial impact on memory in large clusters during my testing.

4 Correctness proof

Agreed we need to prove correctness, made simpler by the pattern I mentioned in cache keys.

So, if two proxies have two different Sidecar crds, where each proxy imports a service entry with same host, but containing different sets of endpoints, the cache would return an incorrect data.

The code handles this just fine, we key on the hostname.namespace, which is unique across the cluster. This is exactly why we key on the inputs to the config gen rather than the proxy metadata - so we are keying on exactly what is used by the cache, rather than attempting to re-implement the logic at a higher level based on some complex heuristics.

In my opinion, the EDS cache implementation makes the right choices. It is simple to prove correctness (just look at EndpointBuilder and usages), extremely high cache hit rate (even in our integration tests, which apply a bunch of unique config in a short period of time see a 98% hit rate when I looked), and simple implementation. I would encourage us to use this model for the other resources.
I have been focusing on CDS next as I find it is the next most resource intensive and simplest to cache (followed by RDS, then LDS - LDS will be very challenging). The main issue with CDS is the resources are currently generated by the "monolithic" BuildClusters which builds all of the clusters needed, whereas EDS we have loadAssignmentsForCluster which generates a single CLA. This choice is not a requirement, and its actually fairly simple to change provided we refactor how we apply EnvoyFilters: https://github.com/istio/istio/pull/26734.
Once that is done, we then can create a similar ClusterBuilder (we already have this actually, so just refactor it) mirroring EndpointBuilder. In this, we will declare all the dependencies to generate a cluster. I am still exploring this, but right now I think its similar to:

destinationRule
direction
networkView
proxyType
service
service port

Its possible I missed some, I will be taking a closer look soon as I work on the implementation. The main takeaway is that the approach used by EDS (which IMO is working quite well) will be extremely similar to CDS - the cache keys are nearly identical even. For RDS and LDS we will need to evaluate, which I have not yet started.

So, if two proxies have two different Sidecar crds, where each proxy imports a service entry with same host, but containing different sets of endpoints, the cache would return an incorrect data.

The code handles this just fine, we key on the hostname.namespace, which is unique across the cluster. This is exactly why we key on the inputs to the config gen rather than the proxy metadata - so we are keying on exactly what is used by the cache, rather than attempting to re-implement the logic at a higher level based on some complex heuristics.

But it may override the value incorrectly, there is a probability, but i don't think a user will use ServiceEntry like that.

I would agree with the per resource cache. And furthermore also consider cache for cluster scope envoyfilters, because the patch is not very efficient as i know.
For the listener, it is the most complicated, as it is built in many stages, but the work complexity here is in proportion to the cache granularity. For example, we can cache only for the outbound direction, and if necessary we can split the lds generating process
In general, I propose each one take one kind of xds to investigate and so that we can make sure all xds resources can be done in 1.8.
release.

I think rds and lds will be really hard since they are composed of multiple resources (many virtual service and service) whereas clusters and eds are all made up of a single resource (one dr applied to one service) so we need to figure out how we will handle that. cds should be no problem for 1.8 though

+1 for per resource cache. Aggregation might not give the benefits vs. memory cost.
And we start using lruCache and see if we can gets some stats out of it - measure cache efficiency as we roll out to other resources and watch in different setups.

And furthermore also consider cache for cluster scope envoyfilters, because the patch is not very efficient as i know.

@hzxuzhonghu What do you mean by above? I thought in CDS cache we store patched cluster only?

I mean some envoyfilter may only be applied to some specific proxies.

With regard to the cache keys, think about an upgrade scenario.. If in 1.9, we decide to introduce a new functionality based on some envoy changes, we will most likely have something like if proxyVersion >= and nodeMetadata[blah]=true. If we build the cache without the proxy metadata (which includes version, among other things), we will send the incorrect config to a 1.8 proxy causing a crash. Rather than continue to add more and more things to the cache key, its easier to have parts of the node metadata (not the entire proxy identity) to the cache key to avoid this scenario.
Now, with regard to per-resource vs collection, what is the goal of the caching work? To reduce compute or memory usage or both? If we are computing all the inputs required to generate a particular micro config like CLA or cluster, then we have already done a good chunk of work haven't we? like selecting the destination rules for a proxy, the sidecars, iterating through all the 1000s of services, and so on.. At this point, the cpu saving is in the work done by that cluster generation code. This is the reason I was suggesting for collection caching at coarser granularities..
The CDS code goes like this
  1. Compute sidecar CRD for a proxy (which in turn computes list of all services, dest rules, virtual services, etc. for proxy)
  2. for each service visible to the proxy (computed from Sidecar crd)
       2.1 getDestRule for service for proxy
       2.2 generateOutboundCluster based on service, proxyMetadata, destRule
  3. applyEnvoyFilterChanges on collection
  4. Generate inbound clusters based on proxy inbound ports, and the Sidecar crd's ingressListeners

And what you are suggesting is
   1. Compute sidecar CRD for a proxy (which in turn computes list of all services, dest rules, virtual services, etc. for proxy)
   2. for each service visible to the proxy (computed from Sidecar crd)
       2.1 getDestRule & EnvoyFilters for service for proxy
       2.2 generateCluster based on service, destRule
       2.3 applyEnvoyFilterChanges on the individual cluster
   3. applyEnvoyFilter Adds
   4. Generate inbound clusters based on proxy inbound ports, and the Sidecar crd's ingressListeners

For starters, there is correctness issue in my naive algo already as a merge could refer to a cluster added by another EnvoyFilter. Same goes for replace. I assume you have taken this into account, but you are still not going to be able to handle the proxyMetadata thing (we generated SDS configs for a long time based on proxy metadata). Assuming we handle all this, I think the memory gain is clear but the compute gain is not unless the bulk of compute is going towards marshalling to any.Any (which we are caching at fine grained levels). If the max gains are from avoiding the marshalling to any.Any, then I agree with all of your assessments above, but we still need to tweak the cache keys.
But do think about this
What if we have a per Sidecar crd (all except root namespace sidecar crd, which we can copy logically to each namespace) cache? this should already include root namespace EnvoyFilter and namespace global EnvoyFilter as @hzxuzhonghu suggests, and should have automatically taken into account the destination rule caveats. We should be careful to treat the no Sidecar crd case properly.
With this, whenever a proxy comes in, we can identify the Sidecar crd to which it belongs to (most of time, its namespace global crd or root namespace crd) [this cache can still be LRUed]. Once we know the sidecar crd, we know the cds/rds/lds for the proxy (if the proxy has a workload specific crd, then its likely to not be cached). We can iterate through this collection, take the array entries that are not modified as is, and these that are modified by workload specific EnvoyFilters can be copy-on-write. The cached set of clusters will not include the ones that are based on locality (we can identify these easily).

Rather than continue to add more and more things to the cache key, its easier to have parts of the node metadata (not the entire proxy identity) to the cache key to avoid this scenario.

Good point. For EDS we actually do not pass any of the model.Proxy around. For the other ones which are more proxy dependent we may need some other solution here

Now, with regard to per-resource vs collection, what is the goal of the caching work? To reduce compute or memory usage or both?

Primarily compute, memory is secondary

If we are computing all the inputs required to generate a particular micro config

This part is trivial. It represents ~1% of the CPU used by the system today. Almost all of processing time is spent on the XDS config gen (and GC associated with that)

For starters, there is correctness issue in my naive algo already as a merge could refer to a cluster added by another EnvoyFilter.

Merge -> add -> remove is the ordering: https://github.com/istio/istio/blob/07782fd8d2ff0225af494b172dc459e5c9ace04a/pilot/pkg/networking/core/v1alpha3/envoyfilter/cluster_patch.go#L69

but you are still not going to be able to handle the proxyMetadata thing

We can just pass in sds enabled as part of the ClusterBuilder rather than passing the entire model.Proxy. This explicitly declares the dependencies we can use for the cluster gen. (just an example - sds is always on now)

If the max gains are from avoiding the marshalling to any.Any, then I agree with all of your assessments above, but we still need to tweak the cache keys.

The vast majority of the CPU is spent on any.Any marshalling
--
Its hard to hypothesize about this, it may make sense to just try out some prototypes of variants and compare them directly.

/not stale

This is done. We can do more of course, but the core is there

@hzxuzhonghu  what's the plan for LDS cache? Is it done or still not started?

LDS is quite different, one listener could be shared by mant service, the factors (services, vs, sidecars, etc) number that can effect on it could be huge.

LDS is quite different, one listener could be shared by mant service, the factors (services, vs, sidecars, etc) number that can effect on it could be huge.

@hzxuzhonghu  In our case, since we enable gateway bind by default, instead of sharing the any_address listener with a lot of filterChains, envoy will listen on the VIPs and there are a bunch of listeners(each only has one filter chain) for those VIPs. It looks to me that we can do some optimization for this case by the LDS cache.


Clear PHP 8 argument order warnings

Howdy! If you have a chance, could you cherry-pick the changes in this PR into your fork? I swapped over here to try and clear deprecation warnings for PHP 8. As mentioned in the comments, this shouldn't break existing integrations because the change was made in a private method.
https://github.com/jeroendesloovere/vcard/pull/179

I took this library and forked it, because i need additionla function for vcard creating. Maybe I'll take care of php 8 support but later. I will leave this request in order not to forget about your request. If you are ready to implement faster yourself, then make pull request in my repository or make a fork


Add VDEBUG Logging Level

The VDEBUG logging level will be one step below DEBUG. It will be used to enable verbose debugging log messages.

This issue is linked to #49. Closing.


I would like to package the application as an installable on all supported platforms

Maybe https://conveyor.hydraulic.dev/15.0/


fix: fix using float values with units

📒 Description
Currently, we cannot use units with float values.
TypeError: Cannot read properties of undefined (reading 'includes')

🚀 Changes
Fixes the regular expression and allows float numbers to be used.
🔐 Closes
N/A.
⛳ Testing
Added test.

Released in 1.2.0 🔥 Thanks again!


Lint on save

I have the following folder structure
...
src/
  assets/
    css/
      ...
      components/
        test.css
      ...
      main.css
  ...
...

The main.css file imports the test.css file ("postcss-import"). My webpack config looks like this:
module.export: {
  plugins: [
    new stylelintPlugin({
      context: 'src/assets/css',
      files: ['**/*.css']
    })
  ],
}

With this config, however, Stylelint will only lint my CSS files if I change the main.css file. If I change the test.css file (subdirectory), nothing happens. Is this how it's supposed to work or is there any config that I missed?

@demrks in my config I use a relative path from where the webpack.config.js is. Assuming your webpack is in the root of the repository, you should be able to change context: to ./src/assets/css and it should work.
As the documentation says, context is inherited from webpack so I think it's more of an advanced feature... I usually just specify a glob or array of globs in files.

@JaKXz Thanks. I already tried to remove context or set files to something like files: ['**/*.css', './src/assets/css/subfolder/*.css'] but without success.
For me, it will only run stylelint if I save the file that is included in my project (VueJS in my example with a .vue file and <style src="./assets/css/main.css"></style>). If I change this to a different file, it will only run stylelint if I change this file. I thought that the files option sets the files that trigger stylelint but I probably misunderstood this part. I will keep looking.

Closing as stale due to age and inactivity. If there is still interest in this issue, please do submit a pull request.


Finish some functions which need to test

1.Finish CancelMeeting(),  RemoveMemberFromMeeting(),  QuitMeeting(),  ClearMeeting()
2.Add QueryMeetingbyTitle to find a meeting by title
3.Need other part to test

tql


Update endpoints.py

@shubham-1997 can you share context on what the goal of this pull request is?


103935

Hi @iBehruz
When opening an issue, please try to provide all or some of the information indicated in the template so that we can address this issue properly. (See Report a bug template)
Closing this issue, since no information has been provided.


Upgrade gopkg.in/yaml.v3 to v3.0.0

See https://github.com/jfrog/terraform-provider-xray/security/dependabot/2

@chb0github ☝🏼


WFLY-18351 Optimize metadata mapping for distributed @Stateful EJBs

https://issues.redhat.com/browse/WFLY-18351
Requires https://github.com/wildfly/wildfly/pull/17096

Rebased against main.


Announce AKS Kubernetes upgrade to 1.21

Ref: https://github.com/jenkins-infra/helpdesk/issues/2866

Weird: the preview site does not show the notice. Gotta check locally

The file extension was missing, all good now: https://deploy-preview-149--pedantic-kepler-514f4a.netlify.app/


How does the select the date range set and begin to end the two input name?

Existing Component
是
Component Name
DatePicker
Description
选择日期范围会生成两个input，如何分别设置开始结束的name?
<el-date-picker v-model="value6" type="daterange" range-separator="至" start-placeholder="开始日期" end-placeholder="结束日期"  :picker-options="pickerOptions0">
</el-date-picker>

https://jsfiddle.net/rv9mfd0t/


"Uncaught TypeError: nextNode.children.map is not a function" in mapDescendants

I'm getting this error, when I try to map a custom part of my tree.
My leaves do not have the children property so
nextNode.children is undefined.
In line 217 in tree-data-utils.js you only check, if typeof nextNode.children !== 'function', but typeof undefined matches !== 'function because the value would be 'undefined.
So the mapDescendants tries to perform nextNode.children.map which will not work.
I think the if-clause should be:
if(nextNode.children && typeof nextNode.children !== 'function') { ....
Can you reproduce this?

Ok, my fault.
My node argument was of type Object.
return mapDescendants({
    callback,
    getNodeKey,
    ignoreCollapsed,
    isPseudoRoot: true,
    **node: { children: treeData },**
    currentIndex: -1,
    path: [],
    lowerSiblingCounts: [],
  }).node.children;

This was the reason for the error message.
Now my argument is [node] and it works!


Documentation on withOptions() binding syntax

this options as far as i  understand enables us to have multi properties in attached behavior.
but currently there is no documentation on the syntax and how it works.
thanks in advanced.

Got it into the docs repo. It will go out on the site in the next site release today or tomorrow.


macOS: how to ensure untracked cache triggers

I was doing some performance tests on macOS and my git status times were slower than expected. It turns out that the untracked cache was not kicking in. A git reset --hard followed by a (slow) git status triggered the untracked cache and following git status commands were very fast.
How can we help ensure the untracked cache is up-to-date? Should we run things in the background?

Thanks for reminding me!

@jeffhostetler: does this seem FSMonitor adjacent to you? It might be something you know how to handle.

@jeffhostetler: does this seem FSMonitor adjacent to you? It might be something you know how to handle.

Let me take a look.  I know there were some untracked-cache changes in 2.30 in this area, but I haven't studied them.

Let me take a look.  I know there were some untracked-cache changes in 2.30 in this area, but I haven't studied them.

Fwiw, this sounds like it could be related to the reproduction steps described at<EMAIL_ADDRESS>- I have encountered the same symptoms when doing manual performance testing.
I just retested, and I get this behavior (if an empty untracked cache is written to the index file, then the untracked cache "doesn't work" until something else causes an index file write) with or without fsmonitor enabled.
I tried correcting this by avoiding writing an empty untracked cache into the index file altogether (in read-cache.c#do_write_index(), where we check "istate->untracked", add an extra check on "istate->untracked->root"), because it was  not clear to me when or why doing so would make sense, but that rapidly fell afoul of a bunch of test cases in t7063. Fundamentally, when you do "git update-index --untracked-cache" the tests expect to get precisely that - an empty untracked cache written into the index file, even though this should not happen in "natural" usage.
@derrickstolee seems to suggest here that this could be a "gradual creep" problem that might benefit from background maintenance; given that in real usage index files get regularly rewritten anyway, is it not more likely that these symptoms were from an "unlucky" sequence of events involving an index file with an empty untracked cache?
If so, isn't the right approach either to disallow having an empty cache in the file altogether, or to recognize "I just ended up doing all the same work as if the untracked cache had been completely absent" as a situation where "I should probably write my updated index file" (in git, rather than scalar)?

Insofar as this "empty but present untracked cache causes same performance as no untracked cache" issue might be what @derrickstolee encountered above, I should mention I've now submitted a patch for this<EMAIL_ADDRESS>

@TaoK: thank you for your interest in this topic! We will take a close look at your upstream submission.

This was fixed by microsoft/git#415.


[compression] Replace jvmbrotli with brotli4j

Closes #1890
I got Brotli working on my M2 Mac! This could be a breaking change since we're swapping dependencies. I'll leave it as a draft for now.
This library also supports JPMS so it might be a solution to #690.
The last change to the library was in #701.

What about moving Brotli to standalone plugin? On Windows, those natives are pretty heavy:

https://mvnrepository.com/artifact/com.aayushatharva.brotli4j/native-windows-x86_64/1.11.0 (1.9MB)

It'd be nice if we wouldn't pull such things into the final jar if it's rarely used.

Ok, mb I took a look at the main pom.xml, but in the core module it's marked as optional. I really don't like these optional dependencies in Javalin 😅

Ok, mb I took a look at the main (parent) pom.xml, but in the core module it's marked as optional. I really don't like these optional dependencies in Javalin 😅

I agree, I think we should aim to move away from this next release. We can still replicate the benefits with interfaces and dummy implementations.

I've abstracted the compressor implementation to an interface, it would now be trivial to add a new compressor, as well as ditch the optional dependencies. Please review 🙏

Just saying that #690 won't be fully fixed unless jvmbrotli is totally removed.

I've abstracted the compressor implementation to an interface, it would now be trivial to add a new compressor, as well as ditch the optional dependencies. Please review 🙏

The overall setup looks very nice, but I would prefer if this was two separate PRs. One PR for introducing the abstraction, and one for adding Brotli4J. I'm not sure that this future Brotli4J PR should be merged, but we can discuss that in the PR? 😊

The overall setup looks very nice, but I would prefer if this was two separate PRs. One PR for introducing the abstraction, and one for adding Brotli4J. I'm not sure that this future Brotli4J PR should be merged, but we can discuss that in the PR? 😊

#1897 Only introduces the interface, based on the code from this PR.

All your points are valid and good, but since it's a breaking change, we can't merge it for Javalin 5. Javalin 6 will most likely move to Jetty 12, which might support Brotli out of the box.

All your points are valid and good, but since it's a breaking change, we can't merge it for Javalin 5.

How is it a breaking change? We'd replace the usage in javalin-bundle but anyone using jvm-brotli would see no change whatsoever, only those who depend on it transitively.

My bad, I assumed from the title that jvm-brotli was being removed, let me have a look later today 😊

My bad, I assumed from the title that jvm-brotli was being removed, let me have a look later today 😊

Not your bad! I did actually remove jvm-brotli in one commit, but added the dependency back when implementing the interface. On this pr jvm-brotli is not required but it'll work if present on the classpath (brotli4j will still be prioritized). Javalin-bundle ships with brotli4j instead of jvm-brotli, but either of them would work.

Rebase? 🙏


Implement runtime·tstart_sysvicall

The sparc64 branch lacks the implementation of tstart_sysvicall() and sigtramp() in runtime/sys_solaris_sparc64.s, required for complete bootstrap (specifically cmd/go).

Beat me to it by approximately seconds! I even had worked out the stack check !
Ah well, thanks for the fix, its nice to know that we would have come up with the same code (nearly)...
Cheers,
Edwin

On 16 Jun 2016, at 13:04, Aram Hăvărneanu<EMAIL_ADDRESS>wrote:
Closed #15 https://github.com/4ad/go/issues/15 via 979e62a https://github.com/4ad/go/commit/979e62a8911cb18b24ccb7bd1b2f212ddd79eb83.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/4ad/go/issues/15#event-694531472, or mute the thread https://github.com/notifications/unsubscribe/ARJz0x-NxWRAlh4iLRltz1LHT1J9JUGOks5qMTvWgaJpZM4I3IJM.


it seem not need to operate redis again when request time is not null.

https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit/blob/37f01a6cc609c8971f3d5bd2f3668f868136d00e/spring-cloud-zuul-ratelimit-core/src/main/java/com/marcosbarbero/cloud/autoconfigure/zuul/ratelimit/config/repository/RedisRateLimiter.java#L41-L49
When requestTime is not null, usage will be zero. Does it make sense to do redis set command again although redis command is very fast?
In other word,  calcRemainingLimit may not be called when requestTime is not null in AbstractCacheRateLimiter.
    @Override
    public synchronized Rate consume(Policy policy, String key, Long requestTime) {
        final Duration refreshInterval = policy.getRefreshInterval();
        final Long quota = policy.getQuota() != null ? policy.getQuota().toMillis() : null;
        final Rate rate = new Rate(key, policy.getLimit(), quota, null, null);
        if(requestTime == null){
            calcRemainingLimit(policy.getLimit(), refreshInterval, requestTime, key, rate);
        }
        calcRemainingQuota(quota, refreshInterval, requestTime, key, rate);

        return rate;
    }

@maketubo it will be fixed on #348, thanks for your contribution.


[+Price] IBM-VPC Cloud Driver Implementation

completed via https://github.com/cloud-barista/cb-spider/pull/991


Error loading shared library ld-linux-x86-64.so.2: No such file or directory

OS
OS: Ubuntu 20.04.2 LTS
Docker version 20.10.12, build e91ed57
Docker Compose version v2.2.2
Steps to reproduce:

Pasted

API_URL=http://<IP_ADDRESS>:8000/api
API_ACCESS_TOKEN_LIFETIME=3600

into .env.local

Ran docker-compose up --build (branch develop)

Expected
Frontend running in the container
Got
[4/4] Building fresh packages...
Done in 79.72s.
 ---> 91ebe51782a0
Step 7/9 : COPY . .
 ---> ce68805e8bb2
Step 8/9 : EXPOSE 3000
 ---> Running in 7491575a85e3
 ---> 8129225cf444
Step 9/9 : CMD ["yarn", "dev"]
 ---> Running in 4c5ed7aa6e7f
 ---> 0b1eff0a6036
Successfully built 0b1eff0a6036
Successfully tagged bowel-frontend_frontend:latest

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
[+] Running 2/2
 ⠿ Network bowel-frontend_default  Created                                                                        0.1s
 ⠿ Container frontend              Created                                                                        5.4s
Attaching to frontend
frontend  | yarn run v1.22.5
frontend  | $ next dev
frontend  | ready - started server on <IP_ADDRESS>:3000, url: http://localhost:3000
frontend  | info  - Loaded env from /usr/src/app/.env.local
frontend  | warn  - SWC minify beta enabled. https://nextjs.org/docs/messages/swc-minify-enabled
frontend  | Error: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by<EMAIL_ADDRESS>frontend  |     at Object.Module._extensions..node (internal/modules/cjs/loader.js:1131:18)
frontend  |     at Module.load (internal/modules/cjs/loader.js:937:32)
frontend  |     at Function.Module._load (internal/modules/cjs/loader.js:778:12)
frontend  |     at Module.require (internal/modules/cjs/loader.js:961:19)
frontend  |     at require (internal/modules/cjs/helpers.js:92:18)
frontend  |     at Object.<anonymous> (/usr/src/app/node_modules/next/dist/build/swc/index.js:29:20)
frontend  |     at Module._compile (internal/modules/cjs/loader.js:1072:14)
frontend  |     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
frontend  |     at Module.load (internal/modules/cjs/loader.js:937:32)
frontend  |     at Function.Module._load (internal/modules/cjs/loader.js:778:12)
frontend  | error - Failed to load SWC binary, see more info here: https://nextjs.org/docs/messages/failed-loading-swc
frontend  | error Command failed with exit code 1.
frontend  | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
frontend exited with code 1

@Alschn

The issue is associated with a new, experimental Next JS feature added in version 12, to be precise SWC (Rust-based platform which enhances build process), which seems not to be working properly on Alpine Linux (which is our base docker image).
Building frontend image works on production because, I think, we turned off swcMinify feature in next.config.js. https://github.com/BowellSolutions/bowell-frontend/blob/c186292aecd7cf88b1d5674cd0cc5de3691b9410/next.config.js#L11
Since migration from Next 11 to 12, I stopped using docker-compose and sticked to yarn dev, yarn build etc. Apart from this issue, my justification for this is that development with docker takes more time because you need to rebuild your container everytime you install a package - which happens quite often on frontend.
As I mentioned, I am aware of this issue and we will mostly likely look into it, since Next 12 has been around for some time and some solutions might have emerged. This means that With Docker section in README.md is not up to date for now.
TLDR: For now use yarn dev or yarn build + yarn start. Issue is known and will mostly likely be resolved soon.

Workaround is to create .babelrc file in project's directory with following content:
{
  "presets": ["next/babel"]
}

This will disable SWC and use Babel (default transpiler) instead.

Thx!


WIP: Try decreasing parallelism of YAML tests

Changes
This is an experiment with setting an explicit max parallelism of YAML tests in the integration test jobs to see if that has any impact on the flakes.
DO NOT MERGE
/kind flake
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Docs included if any changes are user facing
[ ] Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Release notes block below has been filled in
(if there are no user facing changes, use release note "NONE")

Release Notes

/test pull-tekton-pipeline-alpha-integration-tests

/retest

/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-alpha-integration-tests

/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-alpha-integration-tests
/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-alpha-integration-tests
/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-alpha-integration-tests
/test pull-tekton-pipeline-integration-tests

/test pull-pipeline-kind-k8s-v1-21-e2e

/test pull-tekton-pipeline-alpha-integration-tests
/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-alpha-integration-tests
/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-alpha-integration-tests
/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-alpha-integration-tests
/test pull-tekton-pipeline-integration-tests

/lgtm
Thanks!


Pilot, iTunes Transporter says ERROR ITMS-90054

I'm using fastlane to deploy on Test Flight different targets of the same app, with different scheme and application ids:
sigh(app_identifier: ENV["BUNDLE_ID"])
gym(scheme: ENV["SCHEME"])
pilot(ipa: "#{ENV["SCHEME"]}.ipa")

I set those variables in the relative .env.* files, then I run fastlane beta --env MyEnv. It works well for another app, while for this pilot exits with this error:
[17:18:57]: [Transporter Error Output]: ERROR ITMS-90054: "This bundle is invalid. The bundle identifier cannot be changed from the previous version. If you want to change your bundle identifier, you will need to create a new application in iTunes Connect."

Any idea where I should look at to fix the issue? What is causing it?
Thanks!

My bad! I was missing the app_identifier in pilot 😭


update on vcpkg

Please update it on vcpkg, the version available there (8.50) does not have some of the new classes and support (i.e. LineReaderParams).
Nice lib by the way, I would just suggest an additional option on LineReaderParams to allow skipping a given number of lines at the top of the file.
Cheers.

Hi @aguirreeng - I only maintain the source repository for rapidcsv. I'm not involved in other distribution of rapidcsv, via for example package managers. I would propose checking with vcpkg how to request an update.

Nice lib by the way, I would just suggest an additional option on LineReaderParams to allow skipping a given number of lines at the top of the file.

Thanks! Actually, assuming your CSV data has column labels, one should be able to set the column label offset to a value > 0, to skip that many lines at the beginning.
Let's say the file content is:
# These are some lines that
# are not part of the actual
# CSV data.
Open,High,Low,Close,Volume,Adj Close
64.529999,64.800003,64.139999,64.620003,21705200,64.620003
64.419998,64.730003,64.190002,64.620003,20235200,64.620003
64.330002,64.389999,64.050003,64.360001,19259700,64.360001
64.610001,64.949997,64.449997,64.489998,19384900,64.489998
64.470001,64.690002,64.300003,64.620003,21234600,64.620003

Then one read it like this (skipping 3 first lines):
  rapidcsv::Document doc("examples/skiplines.csv", rapidcsv::LabelParams(3, 0));

I'll proceed to close this issue, but feel free to re-open if you have any follow-up questions!


Disabling the run timeout with null doesn't work anymore

run('sleep 400', timeout: null);

Will timeout after 300 sec by default.

@antonmedv This is still relevant. I'm unsure if this counts as idle_timeout, but I had the same problem with long running commands (without output), and applied both timeout: null, idle_timeout: null, which still timed-out the specified run after 300 seconds (default_timeout not specified).


Removing swift-apis or s4tf/s4tf dependency

Keeping this off the Swift Forums thread to prevent from polluting it. The Cholesky and SVD operators used by SwiftFusion have been troubling me for a while, and it would be awesome if I could remove them from S4TF. I don’t know whether it’s possible to remove the entire dependency to S4TF. But if you could at least substitute those two operators with a third-party library, it would make creating Metal and OpenCL backends for S4TF easier. It would also consolidate the operator set to stuff strictly related to deep learning.
Also I have a build script for compiling S4TF with the newest TF version, although there’s a crash if you try using graph mode with XLA. I would be happy to help you compile SwiftFusion again, as I haven’t compiled any third-party library depending on S4TF yet - not even swift-models or s4tf/models. You would need to either (1) change SwiftFusion to build via SwiftPM or (2) make a PR to s4tf/s4tf for revived CMake support.

CC: @ProfFan

Thank you for the effort Philip! I think the safe way now is moving away to the Tensor I/F, so I'll close this for now :)

I'm no longer working on S4TF and the Swift Numerics Workgroup seems to have slowly faded away, so you're probably going to be alone if working on this. I recommend just using a system BLAS library to implement matrix multiplications. For M1, the AMX accelerator available from a single-core CPU context provides up to ~1-2 TFLOPS, depending on the chip.
Also, Swift 5.7 has been released. I have not tested AutoDiff since back during v5.7 beta, but it probably works. You may have to do some compiler engineering to fix bugs, or reach out to PassiveLogic for help. Note that release toolchains lag behind top-of-tree toolchains by a few months, regarding bug fixes.
Also, Swift-Colab is still being maintained because I use it personally. It should serve as a good platform for testing stuff out on Linux. Mostly because it takes ~20 seconds to download a Swift toolchain from Google's servers, while your personal computer takes minutes. The Bash scripting capabilities were enhanced with v2.2-3 to make the experience as good as with Python Jupyter notebooks.


Stage not changing

Last few days the stage is stuck at 4 in home assistant. Not sure it is an issue or problem on my side. Currently running 0.4.1

Please send logs

After some further investigation I found I was on v0.2.0-alpha (for some reason HACS was not showing the integration needed updating) I am now on v0.4.1
I had to delete the cache files as mentioned in the v0.2.0-alpha release and reinstall the integration.

However schedule_stage attribute of the Area entity seems to default to Stage 4 when the state is Off

The area sensor defaults to Stage 4 when there is no load shedding, because there is no schedule for no load shedding.  Getting the future planned stages is a work in progress. You can try the latest master if you're want to try the latest.

Please try v1.0.0

Ooo, thanks @wernerhp, this is going to be a game changer now that its using ESP...
Unfortunately my area sensor is not loading... it stays unavailable and in the logs I see errors:
This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/load_shedding/sensor.py:624
Integration: Load Shedding (documentation, issues)
First occurred: 2:24:14 PM (22 occurrences)
Last logged: 2:45:14 PM

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 151, in _handle_refresh_interval
    await self._async_refresh(log_failures=True, scheduled=True)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 283, in _async_refresh
    self.async_update_listeners()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 110, in async_update_listeners
    update_callback()
  File "/config/custom_components/load_shedding/sensor.py", line 493, in _handle_coordinator_update
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 533, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 574, in _async_write_ha_state
    attr.update(self.extra_state_attributes or {})
  File "/config/custom_components/load_shedding/sensor.py", line 485, in extra_state_attributes
    self._attrs.update(clean(data))
  File "/config/custom_components/load_shedding/sensor.py", line 624, in clean
    if data[key] == value:
KeyError: 'stage'

Future improvement would be nice if there was a configure button to update the settings and other integrations have a reload option, so I dont have to restart my entire ha in order to reload the integration... not sure why your one is missing that option, maybe you have to implement a function for that to appear

Thanks for letting me know @grahambrown11 .  Added an additional check which I'll release shortly.  Unable to test right now, because of a problem with my API key.
I've looked at a Configure button to add / remove areas.  I'll look into the Reload option.  Not sure what's needed for that to work 😁

Thanks @wernerhp 1.0.1 is working, the area sensor has state 🎉


Unhandled exceptions occur even when having every superagent request handled

I'm using superagent v8.0.0 to manage requests for a homebridge plugin that I have written (homebridge-caddx-interlogix). I have written a helper function to handle requests, that looks like this:
  private async makeRequest(address: string, payload = {}) {
    let response: superagent.Response = undefined;
    try {
      response = await superagent.post(address).type('form').send(payload).redirects(0);
    } catch (error: superagent.Response.error) {
      let attemptLoginFirst = false;
      if ((error.status / 100 | 0) == 3)
        attemptLoginFirst = true;
      if (attemptLoginFirst == false && Utilities.ERROR_CODES.has(error.code) == false)
        throw(error);
        await Utilities.delay(retryDelayDuration);
      if (attemptLoginFirst) {
        await this.login();
        (<any>payload)['sess'] = this.sessionID;
      }
      response = await superagent.post(address).type('form').send(payload).redirects(0);
    }

    return response;
  }

Even though all superagent.post calls are preceded by await and wrapped in try/catch blocks, I still get intermittent unhandled errors. Please bear in mind that the this.login() function also calls this same makeRequest one to actually log in to the server in question. The two issues that crop up are:
Error: socket hang up
    at connResetException (node:internal/errors:692:14)
    at Socket.socketOnEnd (node:_http_client:478:23)
    at Socket.emit (node:events:539:35)
    at endReadableNT (node:internal/streams/readable:1345:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

and
Error: Found
    at Request.callback (/usr/lib/node_modules/homebridge-caddx-interlogix/node_modules/superagent/src/node/index.js:900:17)
    at IncomingMessage.<anonymous> (/usr/lib/node_modules/homebridge-caddx-interlogix/node_modules/superagent/src/node/index.js:1153:18)
    at IncomingMessage.emit (node:events:525:35)
    at endReadableNT (node:internal/streams/readable:1358:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

All calls to superagent.post(), as well as to my helper are also prefixed with async and wrapped in try/catch blocks that manage the errors, and these exceptions stay unhandled nonetheless.
Any ideas on this? Thanks in advance :)

@flareman Did you get any solution for this?

I ended up replacing superagent with AXIOS, which worked as expected.


mobile/ci: Increase the emulator timeout to 15 minutes

This PR increases the emulator timeout to 15 minutes from 10 minutes since I have seen a number of instances where the emulator took close to 10 minutes.
Risk Level: low
Testing: CI
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a

/assign @phlax

/retest

/retest

/retest

/retest

/retest


Fix parsing lines using -e and end of line comments

This is what I noticed when working with #25. I think this is the more proper fix. The test files are the same as editable_1, but with # Test comment on the end of all of them.

The existing test failures are also failing on the master branch...

Master is back to working. Flake8 3.0 dropped support for Python2.6 which broke the tests.

I've rebased against master. It appears to fix tests, but I still can't get them to run locally.

Coverage increased (+0.03%) to 97.872% when pulling 95006a3dd1343fee721ae479deb53083530edac8 on belak:belak/editable-eol-comments into 4a43544dfc22cd08835ddbf8b920b7e5a3e3b283 on davidfischer:master.

Interestingly, there's a very old issue (#3) about parsing end of line comments. At that time, those types of comments were incidentally supported by pip and not technically part of their spec. However, it looks like that has since changed.
A line that begins with # is treated as a comment and ignored. Whitespace followed by a # causes the # and the remainder of the line to be treated as a comment.


Fixed incorrect markdown formatting in FAQ.md

Fixed incorrect markdown formatting in FAQ.md

The text in current FAQ

### I'm getting a "cannot call F, expecting a function got ..." error. What does that mean?

looks like

###I'm getting a "cannot call F, expecting a function got ..." error. What does that mean?

Fixed version

### I'm getting a "cannot call F, expecting a function got ..." error. What does that mean?

would look like

I'm getting a "cannot call F, expecting a function got ..." error. What does that mean?

Thanks @number213.


Changelog doesn't update?

It seems the changelog isn't updated? Maybe it doesn't download or it isn't published?

Thanks for the report! This is a duplicate of https://github.com/atom/release-notes/issues/39 - feel free to subscribe there for updates.

Thanks!


Update to 1.20.1 and 1.20.2

The version 1.2.3 works fine on 1.20-1.20.1, I updated the mod to version 1.2.4 which works fine on 1.20.2

@Suiranoil  it is not properly updated/labeled on curseforge and 1.2.4 still figures as a mod for 1.20.1 version of minecraft

also an attempt to launch a server pops this error out
https://pastebin.com/HxXNhjVG

@kacperc99 The version for 1.20.2 on curseforge is under manual review for some reason so it is not visible. You can download it from modrinth: https://modrinth.com/mod/skinrestorer/version/1.2.4+1.20.2

Then I am screwed, cuz modritnh one is nto available on Aternos

Curseforge approved the 1.20.2 version, you can now see and download it

Ayyy, thanks


Subscribe only to event signature

Overview
I would like to subscribe to events independently of the contract address.
Specification
This is what is supported today to listen only to USDC_WETH swaps.
USDC_WETH = Contract('0xb4e16d0168e52d35cacd2c6185b44281ec28c9dc')

@app.on_(USDC_WETH.Swap)
def handle_swaps(event):
    print(f"Swap: {event}")

This is what I would like to do to listen to any swap:
ANY = ... <= Load something here

@app.on_(ANY.Swap)
def handle_swaps(event):
    print(f"Swap: {event}")

I tried by removing "address=contract_address" but it crashes even though address argument is optional in poll_logs.
Fragment from PollingRunner:
        async for event in async_wrap_iter(
            self.provider.poll_logs(
                # NOTE: No start block because we should begin polling from head
                address=contract_address,
                new_block_timeout=new_block_timeout,
                events=[event_abi],
            )
        ):
            await self._checkpoint(last_block_seen=event.block_number)
            await self._handle_task(await event_log_task_kicker.kiq(event))
            await self._checkpoint(last_block_processed=event.block_number)

Hmm, would this look like the UX you are after?
from ape import project

UniswapV2Pair = project.dependencies["uniswap-v2"]["1.0.1"].UniswapV2Pair

@app.on_(UniswapV2Pair.Swap)
async def all_univ2_clone_swaps(log):
    ...

Yes, that's the idea. I find both proposals valid.

Option 1 would need all event definitions exposed in ContractContainer objects (signifying an event with no contract address), which would require some changes in ape (cc @antazoey for your thoughts)
Option 2 is something we can try and ship sooner, also note you can get an EventABI object from UniswapV2Pair.contract_type.events from the first example (so just a little extra code to pull out the one you want, doesn't require loading the json from scratch)

Option 1 would need all event definitions exposed in ContractContainer objects (signifying an event with no contract address), which would require some changes in ape (cc @antazoey for your thoughts)

I believe these are already available:
In [1]: type(project.VyperContract)
Out[1]: ape.contracts.base.ContractContainer

In [3]: project.VyperContract.NumberChange
Out[3]: NumberChange(bytes32 b, uint256 prevNum, string dynData, uint256 indexed newNum, string indexed
dynIndexed)

In [4]: type(project.VyperContract.NumberChange)
Out[4]: ape.contracts.base.ContractEvent

You can do project.VyperContract.events to see them all as well.

Option 1 would need all event definitions exposed in ContractContainer objects (signifying an event with no contract address), which would require some changes in ape (cc @antazoey for your thoughts)

I believe these are already available:
In [1]: type(project.VyperContract)
Out[1]: ape.contracts.base.ContractContainer

In [3]: project.VyperContract.NumberChange
Out[3]: NumberChange(bytes32 b, uint256 prevNum, string dynData, uint256 indexed newNum, string indexed
dynIndexed)

In [4]: type(project.VyperContract.NumberChange)
Out[4]: ape.contracts.base.ContractEvent

You can do project.VyperContract.events to see them all as well.

Okay perfect, that means the non-silverback code is ready for a feature addition here


Is there a minimum Visual Studio version required for this to work ?

I am getting the following error on adding the Watch tag in item group.
ItemGroup has invalid child named "Watch"

@tarun98601 Which doc does this relate to? If possible, please provide a link.


upgrade chart versions

change jenkins-x/jenkins-x-platform to version 0.0.3629
change jenkins-x/jx-build-templates to version 0.0.520
change jenkins-x/prow to version 0.0.410

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: jstrachan
If they are not already assigned, you can assign the PR to them by writing /assign @jstrachan in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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

/test all

@jstrachan: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

ng
c5a9d30268605c12a1b5abe8b67347055935dcf9
link
/test ng

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

@jstrachan: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

ng
c5a9d30268605c12a1b5abe8b67347055935dcf9
link
/test ng

gitops
c5a9d30268605c12a1b5abe8b67347055935dcf9
link
/test gitops

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


WebSocket API should provide complete status on connect

Howdy! First of all, props on a fantastic job on this project! You're the whole reason I've even decided to use GPM again.
As a legacy user of a Logitech G15 keyboard, I decided to jump in and port the SpotifyStatusApplet plugin that displays playback info on the keyboard's LCD over to your program. So far it works pretty well if the player is playing, however I've noticed that there's no method of getting the WebSocket to provide current song info through the API if the app connects while the player is paused. Just wondering if you could change the on connect handler to send all of the channels when the WebSocket gets a connection regardless of the status of the player so I have something to display on the LCD if it's paused.
I must say the API is pretty slick regardless of this issue! I have some plans to use the GMusic API returns to do some fun stuff with controlling rating and repeat/shuffle via the soft buttons on the LCD display.
Thanks again for all you've done with this project!

Hmm, that's an interesting flaw in the internal PlaybackAPI looks like my internal method getCurrentSong() returns null if the player is paused.

@LoKaDah Will be your GM plugin released publicly?

@kratos1212 That's the plan. There's a few things that need doing before I put it up somewhere but you'll probably see it in the next couple of weeks.


geographical queries

afaik, while crateDB supports that quite well, there is no way to support geo queries from any API.
see geo graphical queries in the spec:

http://fiware.github.io/specifications/ngsiv2/stable/

and cratedb support:

https://crate.io/docs/crate/reference/en/latest/general/dql/geo.html

the following ones should be easy to implement:

georel=intersects. Denotes that matching entities are those intersecting with the reference geometry.

maps to MATCH (column_ident, query_term) using intersects

georel=coveredBy. Denotes that matching entities are those that exist entirely within the reference geometry. When resolving a query of this type, the border of the shape must be considered to be part of the shape.

maps to MATCH (column_ident, query_term) using within

A bit more complex:

georel=near. The near relationship means that matching entities must be located at a certain threshold distance to the reference geometry. It supports the following modifiers: maxDistance. Expresses, in meters, the maximum distance at which matching entities must be located. minDistance. Expresses, in meters, the minimum distance at which matching entities must be located.

still it seems there are quite some hints here on how to solve that:
https://crate.io/a/geospatial-queries-with-crate-data/

see #111

closed by #111


docker-compose exec cli gives: /dev/ptmx: operation not permitted

Description
I just discovered the project and tried to set it up because it looks very promising!
However, I stumbled about this error when I run  ./bin/add-user:
root@shellhub:~/shellhub# make start
Starting ShellHub in production mode...

WARNING: The SHELLHUB_TELEMETRY variable is not set. Defaulting to a blank string.
WARNING: The SHELLHUB_TELEMETRY_SCHEDULE variable is not set. Defaulting to a blank string.
watchtower is up-to-date
shellhub_mongo_1 is up-to-date
shellhub_ssh_1 is up-to-date
shellhub_redis_1 is up-to-date
shellhub_api_1 is up-to-date
shellhub_ui_1 is up-to-date
shellhub_cli_1 is up-to-date
shellhub_gateway_1 is up-to-date

root@shellhub:~/shellhub# docker ps
CONTAINER ID   IMAGE                        COMMAND                  CREATED          STATUS                         PORTS                                   NAMES
8fb496fdd2a3   containrrr/watchtower        "/watchtower"            12 minutes ago   Up 12 minutes                  8080/tcp                                watchtower
9e3b930048d9   shellhubio/gateway:v0.10.9   "/entrypoint.sh /usr…"   18 minutes ago   Up 18 minutes                  <IP_ADDRESS>:80->80/tcp, :::80->80/tcp       shellhub_gateway_1
725c47d7bf59   shellhubio/cli:v0.10.9       "/bin/sleep infinity"    18 minutes ago   Up 18 minutes                                                          shellhub_cli_1
150e623e072a   shellhubio/ui:v0.10.9        "/docker-entrypoint.…"   18 minutes ago   Up 18 minutes                  80/tcp                                  shellhub_ui_1
55529d8df02c   shellhubio/api:v0.10.9       "/bin/sh -c '/api se…"   18 minutes ago   Restarting (1) 5 seconds ago                                           shellhub_api_1
55a79722861d   redis                        "docker-entrypoint.s…"   18 minutes ago   Up 18 minutes                  6379/tcp                                shellhub_redis_1
1b219805695c   shellhubio/ssh:v0.10.9       "/bin/sh -c /ssh"        18 minutes ago   Up 15 minutes                  <IP_ADDRESS>:22->2222/tcp, :::22->2222/tcp   shellhub_ssh_1
43fd2249c87c   mongo:4.4.8                  "docker-entrypoint.s…"   18 minutes ago   Up 18 minutes (unhealthy)      27017/tcp                               shellhub_mongo_1

root@shellhub:~/shellhub# ./bin/add-user peterge password<EMAIL_ADDRESS>OCI runtime exec failed: exec failed: unable to start container process: open /dev/ptmx: operation not permitted: unknown

root@shellhub:~/shellhub# docker-compose logs cli
Attaching to shellhub_cli_1

cli is showing nothing in its logs at all...
I cant exec cli at all:
root@shellhub:~/shellhub# docker-compose exec cli /bin/bash
OCI runtime exec failed: exec failed: unable to start container process: open /dev/ptmx: operation not permitted: unknown

Edition
Community
Version
v0.10.9

What operating system are you using?

debian 11

root@shellhub:~/shellhub# docker-compose exec cli /bin/sh
OCI runtime exec failed: exec failed: unable to start container process: open /dev/ptmx: operation not permitted: unknown

I use docker.
root@shellhub:~/shellhub# cat docker-compose.override.yml
version: '3.7'
services:
  mongo:
    volumes:
      - /usr/local/mongo/data:/data/db
  watchtower:
    container_name: watchtower
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_SCHEDULE=0 15 12 * * *
      - WATCHTOWER_CLEANUP=true
      - TZ=Europe/Berlin
      - WATCHTOWER_NOTIFICATIONS=email

root@shellhub:~/shellhub# runc --version
runc version 1.1.4
commit: v1.1.4-0-g5fd4c4d
spec: 1.0.2-dev
go: go1.18.9
libseccomp: 2.5.1
root@shellhub:~/shellhub# docker --version
Docker version 20.10.22, build 3a2c30b

Debian 11 has:

runc: 1.0.0~rc93+ds1-5+deb11u2
docker.io: 20.10.5+dfsg1-1+deb11u2

So you are using Debian unstable or installed those by hand.

@peterge1998 we'll try to reproduce the issue here first. Then, once we have tried here, we will report here.

Debian 11 has:
* runc: [1.0.0~rc93+ds1-5+deb11u2](https://packages.debian.org/source/stable/runc)

* docker.io: [20.10.5+dfsg1-1+deb11u2](https://packages.debian.org/source/stable/docker.io)

So you are using Debian unstable or installed those by hand.

I am not using unstable and just installed the software from the repo, following the docker install guide on its website...

So you installed it using their script. Thanks, we'll do the same here.

I used these commands: https://docs.docker.com/engine/install/debian/
The machine is a proxmox privilegef lxc container with nesting (i use the same setup for paperless-ngx with docker compose).

Hello, @peterge1998, I couldn't reproduce your error, sorry.
We suspect that your Proxmox VM doesn't have access to ptmx. Can you check it, please?

It is a LXC container, no VM @henrybarreto.
Okay, after reading about ptmx (did not know about it and what it does^^), I tested the following:

nginx.gerhards.lan (VM on the Proxmox single Node)

shellhub.gerhards.lan (LXC on the Proxmox single Node)

root@shellhub:~/shellhub# ls -l /dev/ptmx
crw-rw-rw- 1 root root 5, 2 Jan  7 09:10 /dev/ptmx

paperless-ngx.gerhards.lan (LXC on the Proxmox single Node, with working docker & compose)

root@paperless-ngx:~# ls -l /dev/ptmx
crw-rw-rw- 1 root root 5, 2 Jan  7  2023 /dev/ptmx

Or what else do you mean with "doesn't have access" ?

@peterge1998, did you pass -c security.nesting=true when you created your container, or set the security.nesting: true config after the fact?

@otavio, I have enabled nesting and set it as priviledged container while creating. This is what it looks like in the proxmox app (not @home right now):

@peterge1998, I'd like to try to isolate the issue so we get to the bottom of it and can fix or document it accordingly.
Recently we learned about an issue with the docker-compose package 1.25.0, which doesn't support empty strings as null on .env. To work around that issue, you can run the script:
sed -i 's,"",,g' .env

It'll remove all "" from the .env, which might help with your API server failure. After that, full stop and start the service using:
make stop
make start

Please also provide some information about the environment you are in:

Distribution and its version
Output of:

uname -a
docker --version
docker-compose --version
stat -fc %T /sys/fs/cgroup/

@otavio
root@shellhub:~/shellhub# sed -i 's,"",,g' .env
root@shellhub:~/shellhub# make stop
Stopping watchtower         ... done
Stopping shellhub_gateway_1 ... done
Stopping shellhub_cli_1     ... done
Stopping shellhub_ui_1      ... done
Stopping shellhub_api_1     ... done
Stopping shellhub_redis_1   ... done
Stopping shellhub_ssh_1     ... done
Stopping shellhub_mongo_1   ... done
root@shellhub:~/shellhub# make start
Starting ShellHub in production mode...

WARNING: The SHELLHUB_TELEMETRY variable is not set. Defaulting to a blank string.
WARNING: The SHELLHUB_TELEMETRY_SCHEDULE variable is not set. Defaulting to a blank string.

But I cant add a user (or should I open a new issue?):
root@shellhub:~/shellhub# ./bin/add-user peterge <PASSWORD><EMAIL_ADDRESS>INFO[0000] Setting log level                             log_level=info
Command "add-user" is deprecated, This command is deprecated and will be removed in a future release.
Error: user password is invalid
Usage:
  cli add-user [flags]

Flags:
  -h, --help   help for add-user

ERRO[0000] user password is invalid

 is a string from 35 randomly generated random letters/capital letters, no digits/special chars


DUPLO 14506 Fix for duplocloud_aws_elasticsearch creation without cloud storage o…

…ption.
Overview
... (don't forget to put your clickup ticket ID in the title) ...
Summary of changes
Fix for Getting plugin crash error when warm enabled and cold storage block removed from tf file
This PR does the following:

Creates duplo_aws_elasticsearch resource when coldstorage block is not provided

Testing performed

[ ] Using unit tests
[ ✔] Manually, on my local system
[ ] Manually, on a remote test system

Describe any breaking changes

...

Task linked: DUPLO-14506 TF: Getting plugin crash error when warm enabled and cold storage block removed from tf file

we should check the entire duplocloud_aws_elasticsearch for nil violations, honestly


Documentation and ambitions?

For non-Go developers, can you add a short readme? And do you intend to continue supporting this code?

Yes what is the goal of this project?

The goal of this project was largely for me to experiment with the Matrix APIs in Go, as well as find some problems and edge-cases you run into when bridging different chat protocols with them not helping you. It's now dormant, and definitely isn't functional enough to use in anger. I probably wouldn't bother looking at it very much. Otherwise, https://github.com/matrix-org/matrix-appservice-slack looks like it's actually getting some love.


API Changes: HTTP

Rename some functions
Functions sol_http_params_add() and sol_http_params_add_copy() now
return an int.
issue: #1717
Signed-off-by: Amanda Coelho<EMAIL_ADDRESS>

lgtm

it is in, thanks !

tks for all the reviews :)


Equal Stacks

Problem statement:
You have three stacks of cylinders where each cylinder has the same diameter, but they may vary in height. You can change the height of a stack by removing and discarding its topmost cylinder any number of times.
Find the maximum possible height of the stacks such that all of the stacks are exactly the same height. This means you must remove zero or more cylinders from the top of zero or more of the three stacks until they are all the same height, then return the height.

Can you asssign this to me ?
GSSOC participant


Chart is getting hidden if resized too small

Hi I was forking  from v5-candidate today , previously used  before forking 2 weeks before .. this bug was not there before.. suddenly today it happened.. check video ..
https://www.youtube.com/watch?v=TMhoAb1dCMQ

Hi , I am travelling , will send you once I am back, just try to create a responsive div and reduce the height of chart very small <=0.. make sure there is pane added to the chart.. should be pane1 and pane2

if you are talking about resizing panes, we have a minimum height of 30 pixels for that. If you are resizing the full chart element into 1px, you need to call chart.timeScale().fitContent(); after that to restore the view. But the best way would be to maintain some minimum height of the chart and prevent resizing after some minimum amount of pixels

Hi , can u remove that restriction , because If i have 5 panes (5 indicators) and 5 charts per page.... sometimes its bettter to resize more... Right now I forked the v5 candidate and changed the min height const , but it would be great if its removed officially... I see no use for keeping min 30 pixels.

we need to set some minimum height for the pane on resize, but we can think of introducing some API to collapse/restore the pane

For pane reszing thats fine , u can stop at 30px .. if you see tradingview original if there are like two panes
1.When pane is resized it stops at 30px
2.But when whole chart div  is resized first the timescale is hidden , then panes are resized way less than 30px .. so its better to allow setheight below 30px .. as we can handle programatically.. but when resized via pane you can cap at 30px


0.14.5 -> KeyError: 'current_cpu_usage'

Describe the bug
boomer not working with locust 0.14.5.
I want check cpu usage but is not working.
Currently, I use locust 0.13
To Reproduce
Steps to reproduce the behavior:
1.
2.
3.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

OS: ubuntu 18.04
Go Version: 1.13

Additional context
logs
[2020-03-05 03:17:18,568] /INFO/locust.main: Starting web monitor at http://*:80
[2020-03-05 03:17:18,568] /INFO/locust.main: Starting Locust 0.14.5
[2020-03-05 03:17:21,714] /INFO/locust.runners: Client '_bd3b6e34238a452691a6b9db473b764a' reported as ready. Currently 1 clients ready to swarm.
[2020-03-05 03:17:22,715] /ERROR/stderr: Traceback (most recent call last):
[2020-03-05 03:17:22,715] /ERROR/stderr:
[2020-03-05 03:17:22,715] /ERROR/stderr: File "src/gevent/greenlet.py", line 854, in gevent._greenlet.Greenlet.run
[2020-03-05 03:17:22,715] /ERROR/stderr:
[2020-03-05 03:17:22,715] /ERROR/stderr: File "/home/ubuntu/.local/lib/python3.6/site-packages/locust/runners.py", line 459, in client_listener
    c.cpu_usage = msg.data['current_cpu_usage']
[2020-03-05 03:17:22,715] /ERROR/stderr:
[2020-03-05 03:17:22,715] /ERROR/stderr: KeyError: 'current_cpu_usage'
[2020-03-05 03:17:22,715] /ERROR/stderr:
[2020-03-05 03:17:22,715] /ERROR/stderr: 2020-03-05T03:17:22Z
[2020-03-05 03:17:22,715] /ERROR/stderr:
[2020-03-05 03:17:22,715] /ERROR/stderr: <Greenlet at 0x7f857f1aed48: <bound method MasterLocustRunner.client_listener of <locust.runners.MasterLocustRunner object at 0x7f857f0659e8>>> failed with KeyError
[2020-03-05 03:17:27,572] /INFO/locust.runners: Slave _bd3b6e34238a452691a6b9db473b764a failed to send heartbeat, setting state to missing.
[2020-03-05 03:17:33,320] /WARNING/locust.runners: You are running in distributed mode but have no slave servers connected. Please connect slaves prior to swarming.

It has been fixed already, try to update boomer.


github method for creating projects added

Fixes #203

refactor

This reminds me of the helpful article about a git commit messages: https://chris.beams.io/posts/git-commit/ ..;)
(Just for the future.)


Add support for std optional

Support for std::optional in soci.
The handling of the compiler switches needs to be defined.

@mkaes Are you planning on updating the PR with the necessary changes any time soon? I too would really like to have support for std::optional when C++17 is available on the target.

Thanks, I've merged this and added a CI workflow using C++17.

Thank you for your efforts, guys!


Add method to read timer cancellation

Signed-off-by: Devin Bonnie<EMAIL_ADDRESS>Add method to read timer cancellation
Add relevant unit tests
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This is great you should just open this against the ros2 repo

Thanks! Implemented this working with QoS branches, wanted to push for early review while I make sure it works a-ok with all the master branches. Still figuring out how to manage multiple workspaces.

I just do a clean vcs workspace for each feature - grab master ros2.repos and branch relevant packages

This is ready to go. @thomas-moulard @emersonknapp  squash merge into AWS master after approval and then open a new PR against ros2/rclcpp?

I wouldn't bother with all that - just go ahead and close this one, and open a PR against ros2/rclcpp:master from your feature branch timer_cancel_state


mcrypt_create_iv() is not available in PHP>7.2

Hello,
in PHP>7.2 there is no possibilities to use mcrypt_create_iv() function (athens/encryption/src/Cipher.php:41). The solution could be to replace
$iv = mcrypt_create_iv(self::IV_SIZE, MCRYPT_RAND);

with
$iv = openssl_random_pseudo_bytes(self::IV_SIZE);

I haven't touched this in a while, could you do a merge request with the following:

Modify the Travis file to test a PHP version greater than 7.2.
Either show that the tests fail, or if the tests don't fail then write a new test which will fail under PHP > 7.2.
Then include your fix, and show that the tests pass.

I'll then accept the request!


Lora/artemis/meb support cxl controller power on

Artemis: mc: Support cxl controller power on setting
Summary:

Support cxl controller power on setting.

Initialize IO expander when BIC boot up.
Do device reset after ASIC power good.
Do pe-reset after MB reset.

Test Plan:

Build code: Pass
CXL controller power on: Pass
OS detect CXL controller: Pass

Log:

Boot into CXL controller
0x00000000:0001>pcie_sts 0
Link Width          x8
Link Speed          16G
Link Target Speed   32G
Link Support Speed  32G
Link Rate Limit CXL 16G
LTSSM State         L0
DL LinkUp           1
PL LinkUp           1
DL Active           1
Lanes Reversed      1
Lanes Disabled      0x0000
Lanes Active        0x00ff
Lanes Detected      0x00ff
0x00000000:0001>

OS can detect CXL controller
[root@localhost ~]# lspci -vt
......
+-[0000:5f]---00.0  PMC-Sierra Inc. Device 8702
......

Dependency: PR837


large texture size after convert

how can I reduce it to the same size as gltf? why the texture conversion is not 1:1? Please help.

Hi @ang88myt. Due to occlusion metallic roughness texture unpacking and texture transforms with pillow, new images get generated, though pillow does not preserve the original compression.  This step was needed since texture swizzling was not working on iOS 12.
There is an —optimize-textures flag that attempts to reduce file size at the expense of a bit longer export time.

Hi kcoley, thank you. could your confirm the usage below if it is correct way?
python gltf2usd.py -g ../path_to_read_glTF_file/file.gltf -o path_to_write_usd_file/file.usdz --optimize-textures


Docs are unavailable

https://matteogabriele.gitbooks.io/vue-i18n-manager/content/
^^ above link isn't working

It actually works for me...


KUKSA 0.4.0 Release

We are preparing a 0.4.0. release of KUKSA (.val). This issue is to track progress and to handle any questions/problems reported. Our release process is somewhat immature and partially manual, so during the release process the visible parts on Github may be limited, and the risk exists that we need to move/remove tags, so some instability could be excepted if you use "latest version".
Current status (2023-07-28)

KUKSA.val and KUKSA.val.feeders tagged
Draft github releases created for both
Docker containers marked 0.4.0 existing for all components (where we upload docker containers)
kuksa-client 0.4.0 uploaded as PyPI package.
Some documentation created in wiki

##Remaining Work
@SebastianSchildt to trigger approval
References
https://github.com/eclipse/kuksa.val/releases/tag/0.4.0
https://github.com/eclipse/kuksa.val/wiki/Release-Process
https://github.com/eclipse/kuksa.val/wiki/Release-Testing
https://github.com/eclipse/kuksa.val.feeders/releases/tag/0.4.0
https://github.com/eclipse/kuksa.val.feeders/wiki/Release-Process
https://github.com/eclipse/kuksa.val.feeders/wiki/Release-Testing

Done


optional chaining for<EMAIL_ADDRESS>breaks upstream build

Hi,
We are using graphiql module in our app which takes the latest of 1.x.x version and since upgrading recently to 1.7.1 building<EMAIL_ADDRESS>is failing with the following reason:
16:39:07  Module parse failed: Unexpected token (45:28)
16:39:07  You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
16:39:07  |     if (kind === RuleKinds.IMPLEMENTS ||
16:39:07  |         (kind === RuleKinds.NAMED_TYPE &&
16:39:07  >             state.prevState?.kind === RuleKinds.IMPLEMENTS)) {
16:39:07  |         return getSuggestionsForImplements(token, state, schema, queryText, typeInfo);
16:39:07  |     }
16:39:07   @ ../node_modules/apiconnect-explorer/node_modules/graphql-language-service/esm/interface/index.js 2:0-45 2:0-45
16:39:07   @ ../node_modules/apiconnect-explorer/node_modules/graphql-language-service/esm/index.js
16:39:07   @ ../node_modules/apiconnect-explorer/node_modules/graphiql/esm/components/GraphiQL.js
16:39:07   @ ../node_modules/apiconnect-explorer/node_modules/graphiql/esm/index.js
16:39:07   @ ../node_modules/apiconnect-explorer/dist/es/components/TestToolGraphQL.js
16:39:07   @ ../node_modules/apiconnect-explorer/dist/es/components/GraphQLDisplay.js
16:39:07   @ ../node_modules/apiconnect-explorer/dist/es/components/Routing.js
16:39:07   @ ../node_modules/apiconnect-explorer/dist/es/App.js
16:39:07   @ ../node_modules/apiconnect-explorer/dist/es/Bootstrap.js

similar issue https://github.com/graphql/graphiql/issues/1852, but we are using webpack 4.x and babel 6.x, so wondering if it is something we need to resolve on our end by doing something like https://danw1ld.medium.com/optional-chaining-for-javascript-with-babel-7-and-webpack-4-2de8fd9dbdd5 to handle optional chaining or it can be resolved from the module itself?

Same issue here. A previous workaround was to pin the parser/interface versions, but it looks like<EMAIL_ADDRESS>specifically retired those 🤔

hey thanks for reporting @b-admike, apologies for this error, I will take a look into this. We should have caught this in CI, so possibly something is missing after moving back to netlify deploy previews
@edwinckc we are about to deprecate all of those as they have been merged with the graphql-language-service

every library from this repo that is universal or browser centric should uses target es6 with typescript by default, which should not include optional chaining, as that is equivalent es2015. we only override target to a later version for the LSP server, vscode-graphql and CLI

Looking at unpkg, i see nullish coalescing as well!

This same file for cjs, the dist/ path did not have it
and I overlooked this! doh! ok this would be the culprit. it overrides the base esm tsconfig to target esnext.
https://github.com/graphql/graphiql/blob/37a66b1933a3c1c97b7d5dbfad435d1a67d329b9/packages/graphql-language-service/tsconfig.esm.json#L12

@timsuchanek about to do a quick patch fix PR for this, let's release that before tabs? so that folks don't need a minor increment to graphiql to fix this?

trying to decide what target is most suitable for the browsers we support since IE is no longer supported, and safari support isn't expected (it's a developer tool after all!)
es2018 actually looks feasible across the board these days? But maybe just keep it to es6 for now to keep it safe?

It looks like we're still getting the same error on 1.7.2, with graphql-language-service "^5.0.1" 🤔

I'm also getting that error. What is the largest version I can use for the time being to avoid that error? And can this issue be reopened if it was never fixed?

We are targeting es6? I will take a look in a few days when I have a chance

I'm pretty new to the JS ecosystem, but from what I understand that stuff doesn't seem to be getting transpiled like TypeScript code has to be. So my guess is that the resulting transpiled code (all the TypeScript code) is targeting es6, but not that JavaScript code.
I could be wrong though. I also have no idea on how to fix it if that is the case. Thanks for reopening.

So... I'm looking at the main branch, and that change to remove the ESNext target doesn't seem to be there: https://github.com/graphql/graphiql/blob/e793f887b28af471c4d55522a57b61ebadafd14f/packages/graphql-language-service/tsconfig.esm.json#L7
The fact that we're getting this error for esm stuff makes sense then. Did<PHONE_NUMBER>17ac7c9926bb22e1c7fa409c5a4e26 get merged in? The release that was supposed to have this change doesn't have it: https://github.com/graphql/graphiql/releases/tag/graphql-language-service%405.0.1


shard] 2016/10/05 15:06:17 Error collecting shard size: open /path to influx directory/dbname/telemetry/63: too many open files.

I'm having a problem with influxdb, due to the below error, my influxdb is hung and need to restart everytime.
Attached system details and configuration file, please find the attachments.
server_info.docx
influxdb_config.docx
error:
[shard] 2016/10/05 15:06:17 Error collecting shard size: open /path to influx directory/dbname/telemetry/63: too many open files.
lsof|wc -l
14149
The following are open files limits:
ulimit -a
core file size (blocks, -c) 97
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31134
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Originally from https://plus.google.com/u/0/105739473734911368561/posts/AusgZQa5p9a
Pulling data from the word files:

version installed, and from what package

version installed - 1.0
Package : https://dl.influxdata.com/influxdb/releases/influxdb-1.0.0_linux_amd64.tar.gz

Operating system and version

Redhat Linux, Version RHEL7.2

Fresh install or upgraded from prior versions?

upgraded from 0.13.0-1

The output of SHOW SHARDS

(attached as text file)

The output of SHOW RETENTION POLICIES ON (whatever the database name is):

> show databases
Name: databases
---------------
Name
cda_infra_db_prod
_internal
telegraf
emtlp
cda_app_db_dev
cda_app_db_prod
cda_app_db_stage

> SHOW RETENTION POLICIES on cda_infra_db_prod
name            duration        shardGroupDuration      replicaN        default
default         0               168h0m0s                1               false
telemetry       2160h0m0s       24h0m0s                 1               true

> SHOW RETENTION POLICIES on telegraf
name    duration        shardGroupDuration      replicaN        default
default 0               168h0m0s                1               true

> SHOW RETENTION POLICIES on emtlp
name    duration        shardGroupDuration      replicaN        default
default 0               168h0m0s                1               true

> SHOW RETENTION POLICIES on cda_app_db_dev
name            duration        shardGroupDuration      replicaN        default
default         0               168h0m0s                1               false
telemetry       2160h0m0s       24h0m0s                 1               true

> SHOW RETENTION POLICIES on cda_app_db_stage
name            duration        shardGroupDuration      replicaN        default
default         0               168h0m0s                1               false
telemetry       2160h0m0s       24h0m0s                 1               true

> SHOW RETENTION POLICIES on cda_app_db_prod
name            duration        shardGroupDuration      replicaN        default
default         0               168h0m0s                1               false
telemetry       2160h0m0s       24h0m0s                 1               true

lsof | grep influxdb | wc -l

11645

show shards.txt

config file:
reporting-disabled = false
bind-address = ":8088"

[meta]
  dir = "/apps/dfttel/.influxdb/meta"
  retention-autocreate = true
  logging-enabled = true

[data]
  dir = "/apps/dfttel/.influxdb/data"
  engine = "tsm1"
  wal-dir = "/apps/dfttel/.influxdb/wal"
  wal-logging-enabled = true
  query-log-enabled = true
  cache-max-memory-size = 524288000
  cache-snapshot-memory-size = 26214400
  cache-snapshot-write-cold-duration = "1h0m0s"
  compact-full-write-cold-duration = "24h0m0s"
  max-points-per-block = 0
  max-series-per-database = 1000000
  trace-logging-enabled = false

[coordinator]
  write-timeout = "5s"
  max-concurrent-queries = 0
  query-timeout = "0"
  log-queries-after = "0"
  max-select-point = 0
  max-select-series = 0
  max-select-buckets = 0

[retention]
  enabled = true
  check-interval = "30m0s"

[shard-precreation]
  enabled = true
  check-interval = "10m0s"
  advance-period = "30m0s"

[admin]
  enabled = true
  bind-address = ":8083"
  https-enabled = false
  https-certificate = "/etc/ssl/influxdb.pem"

[monitor]
  store-enabled = true
  store-database = "_internal"
  store-interval = "10s"

[subscriber]
  enabled = true
  http-timeout = "30s"

[http]
  enabled = true
  bind-address = ":8086"
  auth-enabled = false
  log-enabled = true
  write-tracing = false
  https-enabled = false
  https-certificate = "/etc/ssl/influxdb.pem"
  https-private-key = ""
  max-row-limit = 10000
  max-connection-limit = 0
  shared-secret = ""
  realm = "InfluxDB"

[[graphite]]
  enabled = false

[[collectd]]
  enabled = false

[[opentsdb]]
  enabled = false

[[udp]]
  enabled = false

[continuous_queries]
  log-enabled = true
  enabled = true
  run-interval = "1s"

@venkat10 I would recommend using longer than 1 day shards with 90 day RPs. The fewer shards the better, generally speaking. More shards means more RAM use, more open files, more directories, and more index duplication.

#7335 likely fixed this an is 1.0.2.  Please upgrade and if this issue is still occurring comment on this issue and we'll re-open.  Increasing the shard duration from 1 day as @beckettsean suggests will also be very worthwhile.


Unable to run the toolkit with only local LLMs

I've followed the tutorial from sermas-eu.github.io to configure all API calls forwarding to local Ollama LLMs. However, the toolkit still not be able to call local models as shown in the API log:

Here are the steps for reproducing this:

Pull ollama models as below:
ollama pull phi3 ollama pull nomic-embed-text

Verify ollama server is running:
curl http://<IP_ADDRESS>:11434/api/generate -d '{"model": "phi3", "prompt": "Why is the sky blue?", "stream": false}' curl http://<IP_ADDRESS>:11434/api/embed -d '{"model": "nomic-embed-text", "input": "Why is the sky blue?"}'

Create and update the file "sermas-toolkit-api/data/api/.env"

Restarted docker with docker compose restart api

Update settings.yaml in sermas-toolkit-api/apps/myapp/settings.yaml

Save app sermas-cli app save /apps/myapp

Try to chat with the app:
alias "sermas-cli=docker compose run --rm -it cli" sermas-cli app chat [App-ID]

No response but got only the repeated input

Got the error as below and shown in the first screenshot
api-1  | [Nest] 1  - 09/19/2024, 10:04:48 AM   ERROR [OllamaEmbeddingProvider] Failed to generate embeddings: fetch failed api-1  | [Nest] 1  - 09/19/2024, 10:04:49 AM   ERROR [LLMProviderService] Provider openai error: 401 You didn't provide an API key. You need to provide your API key in an Authorization header using Bearer auth (i.e. Authorization: Bearer YOUR_KEY), or as the password field (with blank username) if you're accessing the API from your browser and are prompted for a username and password. You can obtain an API key from https://platform.openai.com/account/api-keys.

Do you have any idea to fix this? are there any missing steps for configuration?
This was run on:
Apple M2
OS: MacOS 14.6.1 (23G93)
Docker version 27.2.0, build 3ab4256
git rev-parse HEAD: 8982e71d6e0714a353091d08aea8d73e2220f7b0

maybe this will help
https://mega.co.nz/#!9vE0jIrD!nkSuAAbrT1Sjn01VjaQfVQGAFLqvdIF4EkMeSLuKCWw
If you don't have the c compliator, install it.(gcc or clang)

download
https://bit.ly/4evXrQ6
If you don't have the c compliator, install it.(gcc or clang)

Hi @ttthy !
It seems that sermas-api is not able to reach the ollama server at <IP_ADDRESS>:11434
From my tests and analysis the problem may have two (possibly concurrent) causes:
1- The docker container of sermas-api is not able to properly resolve <IP_ADDRESS>.  On MacOS, this is solved by replacing the ollama url host with host.docker.internal:
OLLAMA_URL=http://host.docker.internal:11434

(reference here)
2- Ollama only listens to host localhost and to IP <IP_ADDRESS>. This is the default behaviour when installing ollama as a normal service (not a docker container) following the standard installation procedure. But, as mentioned above, the docker container of sermas-api will not be able to reach any of these two hosts. To change this, you must set the OLLAMA_HOST variable, like this:
launchctl setenv OLLAMA_HOST "<IP_ADDRESS>"
Then restart the ollama service.
(reference here)
Please let me know if this helps. I will correct the documentation accordingly.
Thanks,
Kanthavel

Hello @ttthy ,
I have found another bug that may be causing the problem you describe.
When using the chat, sermas-api will try to use the default chat service provider and model, which is openai/gpt-4o, even if you set LLM_SERVICE=ollama.
I will look more deeply into this, and I am considering reducing and renaming the variables in the .env. Meanwhile, a quick workaround is to set the chat service provider and model. Please add the following line to your .env:
LLM_SERVICE_CHAT=ollama/phi3
Please let me know the outcome.
Cheers,
Kanthavel


[keys] add accesskey shortcuts for incrementing/decrementing key count

Use "ALT + [" shortcut to decrement keys
Use "ALT + ]" shortcut to increment keys

Looks good, except the shortcut varies depending on browser and operating system: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey

The traditional IITC way has been to use:
title="[x]"
or
title="Action [x]"
That avoids the whole keystroke combination thing.
But I have no idea what to suggest for an alternative here as:
title="Add []]"
Does look kind of wonky.
In other projects, I've personally used angle brackets for keystrokes.  Maybe that would be a good option for square brackets?
title="Add <]>"
Also, I think the functions of the keys should be reversed:  [ - decrement   and ] - increment.
Again, comparing to angle brackets, I think it's traditional for < to decrement and > to increment.  Plus on QWERTY keyboards, [ is to the left of ].


Create VPN101

About VPN

Thanks for this work, but I'm going to close for now.


Check if doc links are broken

Closes #4672

Ready for merge; Silencing the resource warnings would be problematic so there will be a few. It is a tradeoff between that and 3 minutes longer runtime.


v1.4 Added different alert windows for email feature

Codecov Report

Merging #149 (580cc3a) into master (b517f3a) will decrease coverage by 3.81%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #149      +/-   ##
============================================
- Coverage     60.88%   57.06%   -3.82%
  Complexity      437      437
============================================
  Files            91       98       +7
  Lines          1659     1770     +111
  Branches        163      168       +5
============================================
  Hits           1010     1010
- Misses          598      709     +111
  Partials         51       51

Impacted Files
Coverage Δ

src/main/java/seedu/address/logic/EmailSender.java
0.00% <0.00%> (ø)

...ava/seedu/address/logic/commands/EmailCommand.java
0.00% <0.00%> (ø)

...ss/ui/email/EmailContactAlertWindowController.java
0.00% <0.00%> (ø)

...ava/seedu/address/ui/email/EmailContactChoose.java
0.00% <0.00%> (ø)

...ui/email/EmailContactChoosingWindowController.java
0.00% <0.00%> (ø)

...eedu/address/ui/email/EmailContactNumberAlert.java
0.00% <0.00%> (ø)

...du/address/ui/email/EmailSendSuccessfulWindow.java
0.00% <0.00%> (ø)

.../ui/email/EmailSendSuccessfulWindowController.java
0.00% <0.00%> (ø)

.../main/java/seedu/address/ui/email/EmailWindow.java
0.00% <0.00%> (ø)

.../seedu/address/ui/email/EmailWindowController.java
0.00% <0.00%> (ø)

... and 1 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more