WIP: Add GitLab CI Support to FluentD

Which issue(s) this PR fixes:
No Issue Open
What this PR does / why we need it:
This PR enables GitLab CI support on GitLab. By adding this file we enable GitLab CI to build fluentd. This can speed up the process of builds and also adds another service to assist in the event one service goes down. I.e. Travis CI goes down and builds stop, GitLab CI can pickup the slack.
Docs Changes:
No documents changed.
Release Note:

@edsiper This setup is CI for fluent-bit, right?

Fluentd, just noticed the wrong link.
@Digi59404 would you please update check the list ink problem?


feat: add container config page

The contains the following:

Added a new page to edit container/image config
Removed the InstanceContainerConfig/CompleteContainerConfig/ExplicitContainerConfig
Extracted the config field in the database. (ContainerConfig, InstanceContainerConfig).
Reworked the SecretKeyInputField. It is no secret specific anymore.

Codecov Report
Base: 13.56% // Head: 13.56% // Decreases project coverage by -0.00% :warning:

Coverage data is based on head (86e6069) compared to base (7c2471b).
Patch coverage: 2.32% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #297      +/-   ##
===========================================
- Coverage    13.56%   13.56%   -0.01%
===========================================
  Files           51       51
  Lines         4828     4830       +2
===========================================
  Hits           655      655
- Misses        4151     4153       +2
  Partials        22       22

Impacted Files
Coverage Δ

golang/api/v1/deploy.go
80.61% <ø> (ø)

golang/internal/grpc/grpc.go
0.00% <0.00%> (ø)

golang/internal/mapper/grpc.go
0.00% <0.00%> (ø)

golang/pkg/crane/crux/deploy.go
0.00% <0.00%> (ø)

golang/pkg/dagent/utils/docker.go
12.21% <0.00%> (ø)

golang/internal/util/image.go
100.00% <100.00%> (ø)

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

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

Missing E2E tests 🤡


⚠ ClamAV has degraded performance

In 3112a9f, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 252 ms

Resolved: ClamAV performance has improved in 6096d1d.


Failed to validate the SSL certificate for releases.hashicorp.com:443

centos 6.8 2.6.32
ansible <IP_ADDRESS>
python 2.6.6
download consul failed
TASK [savagegus.ansible-consul : download consul] ******************************
fatal: [dbtest02]: FAILED! => {"changed": false, "failed": true, "msg": "Failed to validate the SSL certificate for releases.hashicorp.com:443. Make sure your managed systems have a valid CA certificate installed. If the website serving the url uses SNI you need python >= 2.7.9 on your managed machine or you can install the `urllib3`, `pyopenssl`, `ndg-httpsclient`, and `pyasn1` python modules to perform SNI verification in python >= 2.6. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tls/certs, /usr/share/ca-certificates/cacert.org, /etc/ansible"}

Sorry, it's network problem.


Stop building community packages for 2.0 and onwards in favour of kata-deploy

Although this may look controversial, kata-deploy is a way simpler, more elegant, and less time consuming way to have kata-containers installed in a way users can taste the project.
This was discussed as part of Today's Kata Architects Meeting (Aug 25th 2020), and the reasoning behind that is to have one simple approach that is not time consuming. Fortunately we already have some distros packaging kata (thanks openSUSE, thanks SLE, thanks Fedora, thanks CentOS), but a single project doing the packaging for all possible distributions is something that simply doesn't scale.
As we already have kata-deploy, we must take advantage of that, update our documentation (as mentioned in https://github.com/kata-containers/documentation/issues/708), and move forward with this approach.

My concern about this approach is that kata-deploy installs static binaries. Since that is done without using a package manager, there is no easy way to notify users that a new release is available.
This problem will mostly affect users of those distros which don't yet package Kata (Debian, etc), but will realistically affect many more users who wish to use the latest release of Kata (the packaged version will lag behind the latest static builds I suspect meaning many users will prefer the kata-deploy-installed version of Kata over the packaged version).
What we could consider doing is adding a check to kata-runtime kata-check that compares the currently installed (static) version with the newest static release (by querying https://github.com/kata-containers/kata-containers/releases). That check should probably be part of the default checks run by that command, however we must provide a CLI flag to disable that check (something like --no-network-checks).
Related:

https://github.com/kata-containers/documentation/issues/708
https://github.com/kata-containers/packaging/issues/1119


[W5.11][T09-04]Zeng Hao

Finished version about the 2KLoC code base

Enhancement looks to be valid. However, may I know what information is shown when the command "info" is being called?

Perhaps you can add different sort category for name, phone number and email?


Reduce typescript package size

Search Terms
size, bloat, install
Suggestion
The typescript package is large, and it only getting larger.

Version 3.1.3 is a whopping 40MB.
Use Cases
TypeScript is used in many contexts.
A TypeScript formatter (e.g. prettier) does not need an entire compiler. It only needs a parser. And 45MB scripted parser is orders of magnitude larger than one would normally expect. (For reference, the installed npm package for Esprima -- the most compatible and compliant ES parser in the ecosystem -- is a mere 0.3MB.)
Examples
Solution 1: Split up packages

typescript (existing package; depends on typescript-compiler, typescript-parser, typescript-server)
typescript-compiler (depends on typescript-parser)
typescript-parser
typescript-server (depends on typescript-compiler)

Optionally, there could be separate packages for typescript-config and typescript-i18n.
Solution 2: Don't duplicate code
There is a lot of code duplication between

lib/typescriptServices.js
lib/typescriptServices.js
lib/tsserver.js
lib/tsserverlibrary.js

Don't duplicate the code.
Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)

Interesting reading, thanks.

TypeScript [2.9.0] has doubled in size since v2.0.0 - now 35 MB

It was closed in #25901, released in 3.1.1, which was 40MB. :slightly_frowning_face:

It won't be hard at all to shrink the package size. For example, lib/tsserver.js and lib/tsserverlibrary.js are 98% identical.
$ du -b node_modules/typescript/lib/tsserver.js node_modules/typescript/lib/tsserverlibrary.js
7290127	node_modules/typescript/lib/tsserver.js
7308140	node_modules/typescript/lib/tsserverlibrary.js
$ comm -12 <(sort node_modules/typescript/lib/tsserver.js) <(sort node_modules/typescript/lib/tsserverlibrary.js) | wc -c
7207205

And 99% of lib/typescript.js is identical to those.
$ du -b node_modules/typescript/lib/typescript.js
6859801	node_modules/typescript/lib/typescript.js
$ comm -12 <(sort node_modules/typescript/lib/tsserver.js) <(sort node_modules/typescript/lib/typescript.js) | wc -c
6850490

And lib/typescriptServer.js is 100% identical to that.
$ sha1sum node_modules/typescript/lib/typescript.js node_modules/typescript/lib/typescriptServices.js
0cff9734eba3d721a7ba3c72026e16f267610e24  node_modules/typescript/lib/typescript.js
0cff9734eba3d721a7ba3c72026e16f267610e24  node_modules/typescript/lib/typescriptServices.js

I can't begin to guess at the kinds of decisions to produce this, but I trust there is a good solution.

I can't begin to guess at the kinds of design decisions that produce this (or what kind of compatibilities the TS team needs to support), but I trust there is a solution the maintainers would be happy with.

It's done this way so that every file can be used by itself without having to deal with the nastiness of modules in JavaScript. Every file is a functional library/program in itself. I think that is a great thing, at the cost of some disk space.

Reading the linked issue #23339, it appears that it desire is in fact to use modules.
https://github.com/Microsoft/TypeScript/issues/23339#issuecomment-380632662

If we used modules, we'd be able to share each file and avoid this duplication

it is something we want to do, but no plans for the short term. that is where the majority of savings would come from.

nastiness of modules in JavaScript

ES module systems in general can are hit-and-miss, but reminder that we're talking specifically about an npm package.
npm, npm packages, node_modules, package.json, etc. are tailored specific to Node.js (or clones).
AFAIK, there is zero nastiness with using CommonJS modules in an npm package. Right?

A simpler solution: inspired from Busybox.
Combine N near-duplicate files into 1 polymorphic file that can do N things based on a parameter passed in.
It would introduce a performance overhead of parsing tiny % of unnecessary JS code, but can make the tool integration story way simpler. Maybe worth it?
One trivial way to know which feature is expected would be to directly copy Busybox approach: symlink all the duplicate files and differentiate at runtime based on the __filename. Saves disk space, package size, bandwidth. There are more interesting options too.

From speaking with @RyanCavanaugh, it sounded like @orta 	was interested in working on this.

+1 for splitting up typescript into multiple packages. One major benefit would be that these individual packages (other than the "typescript" package) could use semantic versioning on at least their APIs then other libraries could just depend on the packages they need. Right now it's kind of a pain to maintain a library that has a peer dependency on the typescript package (without being super strict about the supported version).

Yeah, I'm chatting with folks internally this week, but my goal is roughly:

Let the package typescript be the same as right now (as removing things would break the world) which provides all tooling

Then have subset packages which are smaller and focused on a specific task:

@typescript/tsc for folks who are just doing compilation (e.g. tsc compiles on the server, prettier for the AST)
@typescript/services for folks building dev tools like monaco-typescript, or executeprogram etc

I doubt I can offer any useful semver on them, as they link to the main TS version. That'd need the API to actually be classed as "stable" which doesn't look like that's happening soon

Removing tools from the package doesn't reduce overall size. Compilation, dev tools etc reuse a lot of the same code that is now copied to multiple commands without changes. The issue is how to share the very duplicated part between the tools, reduce the duplication, or pack the tools into one bundle.

Yeah, I'm chatting with folks internally this week, but my goal is roughly

Oh, we're generally for it (and have been for years, provided we still provide a services bundle for our (browser) consumers who use it) - we just need an automated way to remap the current namespace-based code layout into modules, this way we can keep a PR doing the migration up to date and not stop development on other things. I have a branch from two years ago that migrated all of src/compiler to modules (by hand) - checker.ts had something like 100 lines of imports on it. And that took quite awhile to make. That gave some of us some pause and reduced enthusiasm, but... I'm hoping the final result is still seen as worth it.
With respect to said automation, I think we could probably write a kind of codemod for it using the APIs we have today, but nobody's put in the effort yet.

@orta VS Code is very interested in this work. Right now we consume TypeScript in two ways:

tsserver.js — Used by our JS/TS extension
typescript.js — Used by our html extension

Each of those files is around 8MB on disk. Additionally, are interested in shipping built-in support for tsc (tsc.js), but that's another 4.5MB and that's difficult for me to justify. It seems to me like all these various TypeScript components should be able to share a lot of code.
Let me know if you would like any additional info about how VS Code consumes TS

As a side note, typingsInstaller.js is pretty huge too (6MB)!! Does it pull in a lot of stuff from TS core?

I brought this up during the most recent design meeting - https://github.com/microsoft/TypeScript/issues/34899
Where the end result was basically, we're meeting about trying to get modules happening again
As mentioned above - all of these files are basically the same but with a bit of flavor difference because they represent different sets of the compiler + services - for example I think you can probably use tsserverlibrary for both the html + JS/TS cases in vscode, buttsc.js doesn't look like it lives in there.

I am skeptical that tree-shaking is useful for shipping our own package because presumably everything we ship is used in some capacity, or is part of our public API

If it's not much effort to add into the build, this could still be a worthy goal. There are a few consumers, like Prettier and the new VS Code JS debugger extension, who ship TypeScript in a bundled form. It would double the size on disk if you shipped both ESM and CommonJS in a single package--maybe it could be a separate typescript-esm package?

@connor4312 You'll be able to give it a shot when it's migrated, I'm just saying to temper expectations about the savings you'll see.

Has anybody tried implementing an executable typescript multiplexer following the native pattern of crunchgen or toybox, per @mihailik's suggestion? It would generate the most savings I think.

npm install<EMAIL_ADDRESS>results in a 60MB node_modules on my Mac (56MB of which is typescript itself). Typescript is by far the largest module in our stack (and we have 146 explicit deps in package.json) – would love to see some reduction here 🙏

Yup. This is the second largest module in my stack<EMAIL_ADDRESS>is taking up 52M on disk - while its fine for prod since people typically dont ship typescript as well in images but the transpiled js files, still a reduction in size can impact the dev env significantly.

The install size of<EMAIL_ADDRESS>is 61 MB:
However most of that (51.8 MB) is just these six JavaScript files. Minifying them using uglify-js with just basic configuration reduces their size drastically (to 16.5 MB):

File
Size
Minified size

tsc.js
5621 kB
2206 kB

tsserver.js
10378 kB
3237 kB

tsserverlibrary.js
10331 kB
3220 kB

typescript.js
9728 kB
2989 kB

typescriptServices.js
9728 kB
2989 kB

typingsInstaller.js
7298 kB
2273 kB

The resulting package size (25.7 MB) is less than half of the current install size at the cost of one additional build step. Is this maybe something that should be explored? I didn't manage to find any thread discussing this except for one mention in #23339.

@vostrnad They're working on modularizing the compiler. #35561

From an outsiders perspective, it seems there hasn't been much work done on this recently. People from a lot of corners of the typescript universe have chipped in their approval towards a smaller typescript package. I'm no expert on anything low-level, but I'm just chipping in to start the discussion. Could the community be of any resource to this?

I have (and another dev or two before me has) been working on #35210 (turning the TS package into modules, mentioned in this thread before), which would directly impact this by only having one copy of everything in the package (like most npm packages). Then, the package would be smaller, and the lack of namespace generation into single files would allow importers to properly tree shake (allowing consumers to ship less).
Forgive the lack of obvious progress; this work is done out of tree in a code transformer that will do the conversion from namespaces/outFile to modules in bulk, since this sort of thing is far too difficult of a task to do solely by hand (and probably not gradually either).

This is what my work environment github folder looks like; the repeated yellow chunks are all typescript.

👋 Based on @vostrnad's observation, I created a small redistribution of TypeScript: https://github.com/kidonng/tsc
It is pretty much an experiment though, but I've successfully used it to build the Vite repo.
Bundle size gain:

@kidonng/tsc: package size 890.5 kB, unpacked size 4.1 MB
@kidonng/typescript: package size 1.2 MB, unpacked size 5.5 MB

FYI: We(Prettier) just reduced bundled package size from ~3.5m to ~1.4m by manually remove unused code. https://github.com/prettier/prettier/pull/13431

I am filing followup issues now that the modules PR has been merged.
One such issue of interest here is #51440; the TL;DR is that if we raise our minimum supported Node version to Node 12, we could safely ship our executables as ESM, which would save us roughly 7 MB more on top of the 43% reduction above.

The reduction from modules is very significant. (Thanks!!!!!!)
If your math is correct, that reduces the package size from 65MB to 36MB.
Which is still larger than it was when #23339 was filed, asking for it to smaller.
But alas, such is progress.
This was the largest possible improvement to the size. More could be done, but it's not gonna cut in half again.

Eventually, we may be able to ship as ESM and achieve the smallest possible package. Or, go further and publish individual packages for parts of our repo. That goal's a long way off, but there is work left o be done here.

Confirmed, TS nightly is much smaller now, thanks!

Before
After:

Following the migration to modules in<EMAIL_ADDRESS>I ran my minification tests again. Using uglify-js on the five largest JavaScript files now reduces the package size from 35.6 MB to 18.0 MB:

File
Size
Minified size

tsc.js
5097 kB
2281 kB

tsserver.js
7923 kB
2999 kB

tsserverlibrary.js
7886 kB
2983 kB

typescript.js
7338 kB
2705 kB

typingsInstaller.js
1756 kB
985 kB

I mentioned minification in the module conversion PR; we are restricted on that front because so many people still parched our package. If we minify, patching becomes difficult to impossible.
I'd love to be able to do so, but we have to figure out what to do about that first.
(We'd also probably not go "full" minify; we need to keep names for backtraces.)

Minify only saves space if you don't include source maps.
And excluding source maps seems like deal-breaker.

We already exclude source maps in the package, but our output is left "pretty" so that stack traces are meaningful when provided by downstream users.
If we were enabling minification, we would likely only have it remove whitespace and optimize syntax, leaving names in the output.

Re: ES Modules, I think we have to take performance as a serious goal. We get a big speed boost from esbuild's whole-program-aware bundling and giving that up for a better sticker number isn't a good trade-off for most users. People who want to vendor TS and get the smallest possible final output should pick up our mid-build artifacts and tree shake them.

Yeah, this is something I want to performance test; my impression is that ESM imports should be as fast as the whole-program bundling.

People who want to vendor TS and get the smallest possible final output should pick up our mid-build artifacts and tree shake them.

It's worth noting that vendoring has some big tradeoffs which might leave a user worse off. If someone still installs TypeScript (due to another dependency, for custom build tasks, or for having their editor use a workspace version), that person gets even more duplication of TypeScript, possibly with mismatched versions.

This is closed, but since people do still follow this issue, #55273 is on the docket for an early 5.3 merge; this PR effectively replaces typescript.js with tsserverlibrary.js and removes the latter. This leaves typescript.js as the sole provider of the public API, saving roughly 8MB unpacked. Copy/pasting the package size report that is run on PRs:

Before
After
Diff
Diff (percent)

Packed
6.90 MiB
5.48 MiB
-1.42 MiB
-20.61%

Unpacked
38.74 MiB
30.41 MiB
-8.33 MiB
-21.50%

Before
After
Diff
Diff (percent)

lib/tsserverlibrary.d.ts
570.95 KiB
865.00 B
-570.10 KiB
-99.85%

lib/tsserverlibrary.js
8.57 MiB
1012.00 B
-8.57 MiB
-99.99%

lib/typescript.d.ts
396.27 KiB
570.95 KiB
+174.68 KiB
+44.08%

lib/typescript.js
7.95 MiB
8.57 MiB
+637.53 KiB
+7.84%

As for our executables (and potentially an ESM API); that'll be handled by #51440 when I get to dealing with the long set of changes that are required to make that happen.

There is still more size work that can be done, specifically #51440.
However, I will note that the problem of package sizes is really not as bad as people think these days; every modern package manager uses hardlinks to a global cache, meaning that every install of TypeScript on a system will share the same backing files on disk. The "apparent" size may seem duplicative, but it's really all shared.
That and the install size seen on packagephobia is the unpacked size; the actual bits transferred from the registry are much, much smaller. Even gzip brings the tarball to about 6MB. tslite is smaller on that front at about 3MB, but overall most people only download each version of TypeScript once.
That combined with the hardlinking really means that we're taking about a few MB per system, paid once. One spends more network and disk space loading up Twitter or even GitHub via images and scripts that change often than the TS package.
I'm still going to try and make it smaller because I find it fun to do so, but it's a little moot IMO.

This matters when opening repo on online IDE where there is no cache. My home connection is ~2MB/s, so even in tarball TS still adds few seconds when I open a Stackblitz repro for Vite.

every modern package manager uses hardlinks to a global cache

Neither npm nor yarn hardlink to a global cache. (Unless Yarn is PnP mode.)

overall most people only download each version of TypeScript once

There are 2,800+ versions of TypeScript. The chance that different projects happen to use the same exact version is low.
Even for a single npm install, right now I'm looking at a project with 5 versions. (Why? jsii, postcss-loader, prettier-plugin-organize-imports, puppeteer-core, cosmiconfig-typescript-loader, plus the version for the project itself.)

This matters when opening a repo on an online IDE where there is no cache. My home connection is ~2MB/s, so even in tarball TS still adds few seconds when I open a Stackblitz repro for Vite.

That's certainly true. It's a shame that these systems do not cache their artifacts.

Neither npm nor yarn use a global cache. (Unless Yarn is PnP mode, which brings a number of issues.)

Yarn 3 supports hard linking (https://yarnpkg.com/configuration/yarnrc#nmMode). If you're still using Yarn v1, you're not going to get any new features at all.
I was wrong about npm; it has a global cache but it copies the files.

There are 2,800+ versions of TypeScript. The chance that two different projects happen to install the same exact version is very low.
Even for a single npm install which dedups as much as possible, right now I'm looking at a project with 5 versions. (Why? jsii, postcss-loader, prettier-plugin-organize-imports, puppeteer-core, cosmiconfig-typescript-loader, plus the version for the project itself.)

There should really only be one TS version in a project; if this is happening, then some package is over-restricting what version of TS it needs.

People shouldn’t have to override Typescript versions. The project I’m working on now has 70 dependencies and if they all required post-install customization npm would be pretty unusable.

People shouldn’t have to override Typescript versions. The project I’m working on now has 70 dependencies and if they all required post-install customization npm would be pretty unusable.

I'm referring specifically to doing this in npm:
"overrides": {
    "typescript@*": "$typescript"
},

Or in yarn:
"resolutions": {
    "typescript@*": "$typescript"
},

Or in pnpm:
"pnpm": {
    "overrides": {
        "typescript@*": "$typescript"
    },
}

I am not referring to any sort of post-install patching, but just asking the package manager to resolve to a single version.

The point is that an override only seems reasonable because other dependencies don’t have this problem. NPM repos are supposed to be low-effort installs and typescript should be no exception.

It's a shame that these systems do not cache their artifacts.

There should really only be one TS version in a project

npm; it has a global cache but it copies the files.

IDEs, package maintainers, and package managers should be aggressively deduplicating redundancies.
....
....
....
....
And TypeScript should be doing the same. (Right now it's something crazy like ~75% duplicate code.)

Yes, again, https://github.com/microsoft/TypeScript/issues/27891#issuecomment-1676580727 removed one more copy, and #51440 will remove even more. I'm not sure what else I can say, I was just originally attempting to explain that a large bulk of situations do not benefit from the effort to lower the page size.

I think it'd be useful for people to be a bit more specific about what they care about so we can tailor our efforts.
For time-over-wire, deduplication isn't a great savings, since each additional copy is a tiny increment (compressed checker.ts (2 MB) is 416k, compressed 4x checker.ts is 418k)
For space-on-disk, uh, I'm going to need some more details. It's not 1998 anymore. 40 MB is 0.04% of a terabyte. If the problem is that there are 35 copies of TS due to how a package manager behaves, going from 35 to even 10 is going to be a much bigger than anything we could plausibly do. That's a package manager problem, not a TypeScript problem, it's unrealistic to expect projects to put their effort into slimming down instead of having package managers duplicate less.
For bundling into other projects like web IDEs, treeshaking is going to be a big part of any successful strategy here. Identifying places where we can be more shakeable is a good thing.

For space-on-disk, uh, I'm going to need some more details.

I see where you're coming from, but npm is still the most commonly used package manager. The problem is npm, definitely, but who knows when this will change? Anything that reduces TS size definitely has impact on the ecosystem.
Same is true for the "time-over-wire" thing, shipping 1 MB less is probably not doing anything for one person, but if you multiply 1000 kb by 43 million downloads weekly, the picture looks totally different again.
As far as I can tell, the details you need are written down here: https://github.com/pi0/tslite#how

There are plenty of cases where cache isn't available and the size of the package matters – for over the network size, number of files that need to be written, and amount of JS that needs to be parsed at execution time.

Container builds. Installs in containers typically have no cache (would require volume mounting, etc), so installs are slower. The resulting container size also matters for a number of reasons, from execution time, to registry push time over slow networks, etc, etc. Ppl typically try to keep their container sizes to a minimum, so small packages help here.
CI builds. Similar to above. Often done in containers. Many CI systems have caching abilities, but they can be complicated to setup – and many don't. So often typescript is being installed from scratch each time, for every single build, just adding time to every single build.
Serverless environments. Environments like Lambda, Google Cloud Run, Cloudflare Workers, etc execute much better with smaller zipfiles/container sizes. Reducing dependencies in these environments is a known best practice. Large packages are frowned on. Some have limits on size.
Performance. The more files parsed, the more JS parsed, the slower a package is to start.

If the problem is that there are 35 copies of TS due to how a package manager behaves, going from 35 to even 10 is going to be a much bigger than anything we could plausibly do

35 to 10 is a 71% reduction.
The latest version (5.2.2) has tsc, tsserver, tsserverlibrary, and typescript which total 32MB and have 9MB of unique content.
Removing the duplicate code drops the package from 41MB to 18MB, a 56% reduction.
So.....actually, there is a lot that TS can do.

it's unrealistic to expect projects to put their effort into slimming down instead of having package managers duplicate less

The problem is a synthetic one introduced by TS's build process. The source code (excluding tests) is only 32MB.

there are 35 copies of TS due to how a package manager behaves, going from 35 to even 10 is going to be a much bigger than anything we could plausibly do

Tangential, but if you want to go that route @RyanCavanaugh , there's a four-year PR open for PNP, maybe could be get some eyeballs :)
https://github.com/microsoft/TypeScript/pull/35206

Totally agree! I wrote a small utility to extract the parameters of a function, and leveraged the TS compiler library for obvious reasons.
Works beautifully... but I have to include Typescript's 8 MB dependency, which effectively renders it useless.
The Typescript library needs to be tree-shakable! More to the point... why isn't it ALREADY tree-shakable??

My use-case is a web IDE
I want to include a typescript playground for a library I'm making so people can try it out easily.  Got here trying to figure out how to lower the typescript dependency size.


Performance metrics calculation issue

When the script core.tasks.model_monitoring.calculate_model_metrics runs, classification predictions are being saved but feature drift and other metrics are not being saved.
Internally it seems like there are no match in projects/entries between "current" and "reference" dataframes. This needs to be debugged intensely.

This has been resolved.


core-image-sato is not booting RPI4

Hi,
i am trying to build core-image-sato for RPI4 i have added all the required layers in bblayer and also i have added all necessary features and install packages, i am attaching the the installs that i have added in local.conf
EXTRA_IMAGE_FEATURES  ?= " debug-tweaks "
ENABLE_UART = "1"
CORE_IMAGE_EXTRA_INSTALL += " git ruby bsdtar pseudo os-release lsb-release cmake vim  sysstat numactl python3 apt"
DISTRO_FEATURES_append  = " python3-pip perf opengl"
EXTRA_IMAGE_FEATURES_append  +=  "src-pkgs package-management ssh-server-openssh stateless-rootfs "
IMAGE_INSTALL_append  = " glibc-utils localedef unicode-ucd "
IMAGE_FEATURES_append  = "tools-debug tools-sdk dev-pkgs"
CORE_IMAGE_EXTRA_INSTALL += " kernel-modules bash e2fsprogs mtools parted dosfstools mtd-utils-ubifs openssh"
DISTRO_FEATURES_append +=  " x11 "
MACHINE_FEATURES_append += "vc4graphics"
IMAGE_INSTALL += "glibc-staticdev"
IMAGE_INSTALL_append = "perf dbus libnss-mdns minicom rsync dbus dstat hostapd dhcpcd nasm ncurses-libncurses ncurses-tools ncurses-terminfo-base"
EXTRA_IMAGE_FEATURES += "staticdev-pkgs "
DISTRO ?= "exaleap-arm-linux"
EXTRA_IMAGE_FEATURES ?= " allow-empty-password allow-root-login bash-completion-pkgs dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs eclipse-debug empty-root-password hwcodecs nfs-client nfs-server package-management post-install-logging ptest-pkgs splash src-pkgs ssh-server-dropbear ssh-server-openssh staticdev-pkgs tools-debug tools-profile tools-sdk tools-testapps x11 x11-base x11-sato "
VIRTUAL-RUNTIME_init_manager += "systemd"
Oe-Raspberrypi4$ bitbake core-image-sato
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:02:45
Parsing of 2279 .bb files complete (0 cached, 2279 parsed). 3439 targets, 158 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "aarch64-oe-linux"
MACHINE              = "raspberrypi4-64"
DISTRO               = "exaleap-arm-linux"
DISTRO_VERSION       = "exaleap-arm-linux-r1.0.0"
TUNE_FEATURES        = "aarch64 cortexa72 crc crypto"
TARGET_FPU           = ""
meta                 = "master:982b7f98b8423236cc986346379b1bde3694f131"
meta-oe
meta-python
meta-networking
meta-multimedia
meta-perl            = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi     = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"
meta-pankaj          = ":"
Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:08
Sstate summary: Wanted 133 Found 126 Missed 7 Current 1200 (94% match, 99% complete)
NOTE: Executing Tasks
NOTE: Tasks Summary: Attempted 3932 tasks of which 3914 didn't need to be rerun and all succeeded.
I would like to mention i am not getting any error while buliding the image and i have successfully copied the image as well which is core-image-sato-raspberrypi4-64.wic.bz2  and i am able to see both the partitions as well.
Everything seems to be correct but i am not able to understand why the image is not booting, i am missing anything or adding something extra due to which this is happening  ??
Kindly suggest
Thanks!

Have you checked the serial debug console?


Update HCA DCP GDPR and IPA privacy notices

GDPR Privacy Notice for Human Cell Atlas Data Portal Public Website 7.12.22 4861-3196-5225 v.1.
IPA Privacy Notice for Human Cell Atlas Data Portal Public Website 7.12.22 4860-9008-7721 v.1.

@theathorn would you mind please confirming the contact email for the GDPR privacy notice (currently is<EMAIL_ADDRESS>- thank you!

Yes<EMAIL_ADDRESS>


Controller

Add some extra controller stuff.

[ ] if click on cross don't nav to the client.
[ ] If already loaded don't open up controller

New issue, identify correctly if the login is valid or not. If you fail the secure enclave sometimes it still navs to game with your username and all


add opt-in global error-handling (by default)

this gets redundant on the client:
  request
  .get('/querystring')
  .query('search=Manny')
  .query({ order: 'desc', range: '1..5' })
  .end(function(res){
    if (res.error) return something(res.error)
  });

ideally you opt in with something similar to:
request.on('error', function(err){

});

though this would be a bit of a hack since we have no .error(fn) to opt-into http errors in the first place. Arguably global handling is an anti-pattern but worth thinking about

This really needs to be part of the library.  It satisfies too many use cases not to.

Agreed.

Could someone share a workaround?

Status?

Anyone have a solution for this?

Important.

Example of quick and dirty workaround:
const end = superagent.Request.prototype.end;
superagent.Request.prototype.end = function (callback) {
  return end.call(this, (error, response) => {
    if (response.unauthorized) {
      // handle the error here, for example:
      // window.location = '/login'
    } else {
      callback(error, response);
    }
  });
};

Can anyone interested confirm whether or not https://github.com/camshaft/superagent-defaults allows a default .end callback and whether that facilitates any of these use cases? I think in general we are pointing to superagent-default for global stuff, but will still consider things here if a compelling case can be made.
@apsavin thank you for the workaround snippet.

I believe .end is not supported by superagent-defaults.


Why does ingress annotations have two equal name?

Do you want to request a feature or report a bug?
feature

What did you expect to see?
ingress.kubernetes.io/xxx and traefik.ingress.kubernetes.io/xxx
I think traefik should only support one form of annotations. This can confuse us user a lot, or it can waste our time on finding out if there are differences. Actually I believe they are the same https://github.com/containous/traefik/blob/c0563f1a395d53edbbf1030b2387435077eeb871/provider/kubernetes/annotations.go#L71
https://github.com/containous/traefik/blob/master/docs/configuration/backends/kubernetes.md
Especially in the documentation of kubernetes provider, both forms are mixed together which may  make it even worse.
What did you see instead?
ingress.kubernetes.io/xxx and traefik.ingress.kubernetes.io/xxx works equally the same.

In v1.5, we have a mix of annotations prefixes: http://docs.traefik.io/configuration/backends/kubernetes/#annotations
From the documentation in master and related to the experimental version (future 1.6):

traefik.ingress.kubernetes.io/ and ingress.kubernetes.io/ are supported prefixes.

http://docs.traefik.io/master/configuration/backends/kubernetes/
We have made this decision because currently there is no real naming convention for k8s annotations:

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/annotations.md
https://github.com/kubernetes/ingress-gce/blob/master/docs/annotations.md


Send IP to multiple e-mails

When I created this code, I couldn't implement a code that was able to send the e-mail to multiple addresses.

I have added the feature of multiple recievers in the code

Fixed in #4.


Dependency Injection

@dangershony I just have a few comments.

I realise that this hasn't been introduced by this PR but the spelling of th ememory pool differs from class to class. Sometimes it's mempool (lower case 'p') while it should always be memPool (upper case 'P'). I think it should be consistent.
in FullNode.cs, this.RegisterModule(new MempoolModule()); could be replaced by a call to get the concrete type of the MemPoolModule interface (dooesn't exist yet). It'll make testing even easier.
The MempoolModule (really should be MemPoolModule) is dependent on the FullNode and is also instantiated inside the FullNode. The problem here is that you need to make sure that when you register the module, all the elements that the module needs should be instantiated in the FullNode. This is prone to error so I would suggest to remove the dependancy on the FullNode by taking these types out of the FullNode class. I see you have written "temporary classes" there, so let's add a TODO there for reference.


Support DuckDuckGo lite

hey, thanks for creating this WebExt!
By looking at the DuckDuckGo patterns I wonder if the extension is supposed to already work on DuckDuckGo lite.
If not, I'd love if it could also support DuckDuckGo lite, its URL is https://lite.duckduckgo.com/lite/.
Would the extension blocking work also when DDG lite is used without javascript?
Thanks!

marked as todo
However, even if the lite version is supported, it will not work in Firefox due to content security policies. (Same reason why the html version is supported only in Chrome.)


[Footer] There is no icon for TikTok and Patreon

Environment: OS Windows 10, Google Chrome ver. 110.0.5481.178.
Reproducible: always
Build found: 26/03/2023
Steps to reproduce

Go to GreenCity
Scroll down to 'Footer'

Actual result
There aren't any icons for TikTok and Patreon according to the mock-up
Expected result
There are icons for TikTok and Patreon according to the mock-up
https://www.figma.com/file/KmaTQl8I31fnA3leNd9CoX/UBS-(УБС)?node-id=245%3A548&t=ViWfNhThN3Q8luko-0

TikTok and Patreon icons aren't displayed, the default social network icon is used

It should be for UBS (Pick Up part)


hi, i used Dynamics365Workflowtools ver <IP_ADDRESS> and Dynamics CRM ver 8.2 Onpremise

###problems to used funcion Update child records with optionset or Pick list
I have a global picklist with 4 entries with numbers from 100.000.000 to 100.000.04.
how include to value ?
CRM Version - onpremise  8.2- WorkflowTools version <IP_ADDRESS>
Plugin Trace:
[msdyncrmWorkflowTools: msdyncrmWorkflowTools.UpdateChildRecords]
[msdyncrmWorkflowTools (<IP_ADDRESS>): Update Child Records]
Load CRM Service from context --- OK
ObjectTypeCode=10070--ParentId=2ec087b6-efb9-e911-814e-00155d504935
RelationshipName=new_bscmedicionesporpuesto_BSCMedicion--_ParentFieldNameToUpdate=new_perspectiva
_ValueToSet="100000002"--_ChildFieldNameToUpdate=new_perspectiva
Error Message:
Unhandled Exception: Microsoft.Crm.CrmException: Unexpected exception from plug-in (Execute): msdyncrmWorkflowTools.UpdateChildRecords: System.InvalidCastException: Unable to cast object of type 'Microsoft.Xrm.Sdk.OptionSetValue' to type 'System.IConvertible'.
at Microsoft.Crm.Sandbox.SandboxCodeUnit.Execute(IExecutionContext context)
at Microsoft.Crm.Workflow.Services.ProxyCustomActivity.Execute(CodeActivityContext executionContext)
Thank You

Hi sansolar20,
sorry about that, I cannot give support anymore to onprem environments, and you have a very old version.
please try to debug the code, or try to share with me more details and screenshots, and maybe I can help you.
thanks!

ok, tanks
El dom., 27 oct. 2019 a las 12:38, Demian Adolfo Raschkovan (<
<EMAIL_ADDRESS>escribió:

Hi sansolar20,
sorry about that, I cannot give support anymore to onprem environments,
and you have a very old version.
please try to debug the code, or try to share with me more details and
screenshots, and maybe I can help you.
thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/demianrasko/Dynamics-365-Workflow-Tools/issues/153?email_source=notifications&email_token=AM7VBQRK6SC5DQOC2O3WPCDQQXGYNA5CNFSM4IPGY44KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECLE65A#issuecomment-546721652,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM7VBQT7HYRSU3UKBPBNYSTQQXGYNANCNFSM4IPGY44A
.

--
Sandra Solis Arias


ux: Undetermistic "required argument" error message

Running the same command multiple times, Cappa does not always show me the same required argument:
% python -m insiders pypi register
The following arguments are required: -d, --description
% python -m insiders pypi register
The following arguments are required: -n, --name
% python -m insiders pypi register
The following arguments are required: -u, --username
% python -m insiders pypi register
The following arguments are required: -n, --name
% python -m insiders pypi register
The following arguments are required: -n, --name
% python -m insiders pypi register
The following arguments are required: -d, --description

By the way, should it show all the required arguments at once?

non-determinism, easy to fix. just sorted the collection i'm iterating over

whether to show all required fields at once...yes? it seems like a good idea, but raises additional UX questions on the messaging.
I've currently got it outputting The following arguments are required: -a/--also-required, -r/--required, but i could imagine only outputting the long versions?

Nice!
In this particular case, I think showing both short and long options is good: the long option tells you what it does, the short option is easier to type.


add alpine base image

Simply adding an alpine based image using multi-step build.

Great idea! I am actually wondering if we should make this the default image since it is much smaller.
What do you think? :)

I can definitely do that if you want. The resulting image is indeed much smaller (so small it can run on a t3.nano along the nightscout instance ^^)
Want me to adapt the PR accordingly?

@Gfeuillen: go ahead an make your image the new default. i think this would be a great improvement :)

Closing this as stale.
The image size has been reduced with PR #136.


Gaussian - plotting a bell curve

Is it possible plot such a chart in c3?
I trying set of x-axis for digits value, but I can't.
I know that x-axis for 'timeseries' and 'category' is possible to set, but I don't know it is possible to digits value.
Sorry at this message here but in google c3 groups my question is unanswered.
My data:
x-axis: [3.01,6.48,9.95, ...]
y-gaussian: [0.00076635186860469,0.0015737752818841,0.002992197165313, ...]
example chart generating in Excell

Closing, this is not an issue and is inactive

But is it possible or not?


Support for querying scoped fields

The current implementation of Device::field_values_for is too limiting. The caller can only pass in a slice of field IDs to populate nvmlFieldValue_t::fieldId while all other struct members are set to zero, while nvmlDeviceGetFieldValues actually also uses nvmlFieldValue_t::scopeId as input when querying several fields such as NVLink remote IDs, NVLink ECC counters, or power draw and power limits.
I would like to contribute a function that allows passing in both fieldId and scopeId and was wondering whether that should replace Device::field_values_for or be a separate function, e.g. Device::scoped_field_values_for.

Thanks for the heads up, looks like scopeId was added after I initially created that wrapper 🙂. We should definitely take that into account.
What do you think about changing:
pub fn field_values_for(
    &self,
    id_slice: &[FieldId],
) -> Result<Vec<Result<FieldValueSample, NvmlError>>, NvmlError> {

to:
pub fn field_values_for(
    &self,
    requests_slice: &[FieldValueRequest],
) -> Result<Vec<Result<FieldValueSample, NvmlError>>, NvmlError> {

Where FieldValueRequest is:
/// Specify a field ID and an optional scope ID for requesting data samples
/// from a device.
///
/// Used in [`crate::struct_wrappers::device::FieldValueSample`] and
/// [`crate::device::Device::field_values_for()`].
#[derive(Debug, Clone, Eq, PartialEq, Hash)]
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct FieldValueRequest {
    /// Populate this newtype with the constants `nvml_wrapper::sys_exports::field_id::*`.
    pub id: FieldId,
    /// Populate this with a `scopeId` appropriate for the associated [`FieldId`].
    ///
    /// See NVIDIA's field ID constant docs (`NVML_FI_*`) to understand what scope
    /// IDs may be valid for which field IDs.
    pub scope_id: Option<ScopeId>,
}

impl FieldValueRequest {
    pub fn id(id: FieldId) -> Self {
        Self { id, scope_id: None }
    }

    pub fn id_with_scope(id: FieldId, scope_id: ScopeId) -> Self {
        Self {
            id,
            scope_id: Some(scope_id),
        }
    }
}

That makes sense. I have submitted PR #55 which changes field_values_for to accept an Iterator of FieldValueRequests. I have also changed FieldValueSample to contain the ScopeId as well to avoid ambiguities.


Silent Deletion of Message w/ Unrecognized Format from Queue

Describe the bug
If there is a message in a queue being consume by JustSaying that it cannot serialize it silently deletes the message from the queue. Even after turning on tracing you just see a "Didn't handle message . No serialiser setup" with no indication that it is deleting the message from the queue. Only after digging through the source was I able to figure out what was happening after hours of scratching my head. I was actually playing with SNS Subscription Filter Policies at the time which made this even more allusive as the first impression I got was that the messages were never making it to my queue in the first place.
Steps To reproduce
Publish a message to a queue that is being consume by JustSaying that wasn't a part of the JustSaying configuration.
Expected behaviour
Message would be skipped and the redrive policy of the queue would eventually take over. Since the default settings are to use dead letter queues I would have expected this to retry until it ended up there.
Actual behaviour
Message is silently deleted from queue.
System information:
v6.0.1

This is long-standing behaviour in here: https://github.com/justeat/JustSaying/blob/master/JustSaying/AwsTools/MessageHandling/MessageDispatcher.cs
            try
            {
                typedMessage = _serializationRegister.DeserializeMessage(message.Body);
            }
            catch (MessageFormatNotSupportedException ex)
            {
                _logger.LogTrace("Could not handle message with Id '{MessageId}' because a deserializer for the content is not configured. Message body: '{MessageBody}'.",
                    message.MessageId, message.Body);
                await DeleteMessageFromQueue(message.ReceiptHandle).ConfigureAwait(false);
                _onError(ex, message);
                return;
            }

Agree - this is dumb.

+1 for changing this behaviour. Just lost a few hours to this.

Maybe we can add something in for v7 in the options somewhere that specifies was the message dispatcher should do with such messages (throw vs. delete)?

@martincostello Maybe I am missing something but why would the framework ever manually "delete" a message rather than just let the SQS Redrive Policy handle this? My thought would be to just log the exception and remove await DeleteMessageFromQueue(message.ReceiptHandle).ConfigureAwait(false); and let SQS handle the rest.


Feature: Channel wrangler move bool channels

Change wrangler can't move bool and those channels pop to the top. This is undesired.
If left and right have different channel layout when building you can't fix this to look the same. (not sure why they are not exactly  mirrored)

CGMToolbox can change the order. Maybe peek how they do it?
cgm.core.tools.attrTools
I'll have a look at the code when I have time

@liudger sorry for the super late reply. I will check this ASAP. Thanks for the feedback


Add support for custom web / api staging urls for eigen

Makes it easier for non-cocoa devs to move to test Eigen support without deploying to staging or production:

got some legit build fails local

1 Error

:no_entry_sign:
No CHANGELOG changes made

2 Warnings

:warning:
Needs testing on a Phone if change is non-trivial

:warning:
Found unstubbbed networking requests

ARArtworkViewControllerBuyButtonSpec in test_buy_button__posts_order_if_artwork_has_no_edition_sets
ARCreateAccountViewControllerSpec in test_warning_view__displays_a_message
ARCreateAccountViewControllerSpec in test_warning_view__displays_a_message
AREmbeddedModelPreviewViewControllerSpec in test_iPhone_peek__shows_favorite_and_follow_buttons_for_logged_in_user
AREmbeddedModelPreviewViewControllerSpec in test_iPhone_peek__shows_favorite_and_follow_buttons_for_logged_in_user
AREmbeddedModelPreviewViewControllerSpec in test_iPhone_peek__passes_artwork_to_share_controller
ARFairViewControllerSpec in test_creates_an_NSUserActivity
ARGeneViewControllerSpec in test_creates_an_NSUserActivity
ARGeneViewControllerSpec in test_creates_an_NSUserActivity
ARTopMenuViewControllerSpec in test_navigation__favorites__logged_in__tab_behavior__already_selected__pops_to_root

  Generated by :no_entry_sign: danger

This fail is just danger - it's actually green - it would be fixed by master danger - but rugged makes that not working ATM.

Looks good 👍 I imagine it'd be nice to set more than one, then restart, but that's trickier (I know since I often have to change three things on eidolon's admin, but it is like a super nice-to-have).

That's going to let people shoot themselves in the foot too easily I'm afraid


Fs 2665 create flags linked to application sections

Jira Ticket https://digital.dclg.gov.uk/jira/browse/FS-2665
Description
Implemented dropdown with sub-sections in 'section to flag' (Flag page)
Verified Assessor email & timestamp is added to database (via user_id)

[ ] Unit tests and other appropriate tests added or updated
[ ] README and other documentation has been updated / added (if needed)
[ ] Commit messages are meaningful and follow good commit message guidelines (e.g. "FS-XXXX: Add margin to nav items preventing overlapping of logo")

How to test
Visit the flag page as lead assessor & notice the 'section to flag' section
Screenshots of UI changes (if applicable)

@RamuniN Assessor can also flag an application as well as Lead Assessors. Did you include this functionality for the Assessor role as well?

@RamuniN I will need to update the e2e tests for Assessment for this new dropdown.
Can you add this attribute data-qa="select_section_to_flag" to the dropdown so I can use this as the locator for the e2e tests please?

@RamuniN Assessor can also flag an application as well as Lead Assessors. Did you include this functionality for the Assessor role as well?

It's already implemented here (https://github.com/communitiesuk/funding-service-design-assessment/blob/97defd1d9f807657f0834e702d9118cd4519ef6c/app/assess/templates/assessor_tasklist.html#L47) to show flagging for ASSESSOR & LEAD_ASSESSOR only

@RamuniN I will need to update the e2e tests for Assessment for this new dropdown.
Can you add this attribute data-qa="select_section_to_flag" to the dropdown so I can use this as the locator for the e2e tests please?

Done!

@RamuniN I will need to update the e2e tests for Assessment for this new dropdown.
Can you add this attribute data-qa="select_section_to_flag" to the dropdown so I can use this as the locator for the e2e tests please?

closed by mistake! Re-opend now


Access to SVGP.inducing_variable gives object of a different type

Creating a SVGP object requires to passing in an inducing_variable object. Since there is no type hinting and no documentation for this passed-in argument, we've seen people passing in object of type tf.Tensor. When they do so, when they access the inducing_variable field from SVGP, they get an object of a different type `InducingPoints'.
This creates surprise for using the API of SVGP because people would expect the field SVGP.inducing_variable to point to the object passed in through the inducing_variable argument.
Also, when setting the prior of the inducing variables, people will create code:
model = SVGP(inducing_variable)
model.inducing_variable.Z.prior = ...

This is a bit awkward because you first construct the whole model object and then being able to set part of it.
My suggestion is to require SVGP.init to accept InducingPoints or some of its ancestor type, add type hinting, and add documentation (by the way, the current documentation for init does not follow the same format at other methods in the same class) to tell people how to create InducingPoints object.

I agree this is a bit awkward. On the other hand, most of the time we do use inducing points and it is very convenient for users not to always have to wrap the Z array/tensor in an InducingPoints class...

@yiwei-prowler I would suggest to leave the behaviour as is for now, I do think we could make the behaviour much clearer by improving the docstring - perhaps adding a type hint inducing_variable: Union[Tensor, InducingVariable]. It'd be great if you could contribute this directly as a pull request - happy to chat on the gpflow slack to hash out details and answer questions you may have in the process!

Adding the correct type hint is already covered by #1368.


Contact details

@vCipher Would it be possible to provide some contact details for yourself?  Do you have for example a twitter account?
If you could let me know the best email address to get you on as well, I will send an invite for you to join our Slack Team.

Of course. My email -<EMAIL_ADDRESS>My twitter - https://twitter.com/v_cipher

Thank you!


IBC update

Codecov Report

Merging #177 (3de6f00) into develop (aa87d50) will increase coverage by 9.63%.
The diff coverage is 22.47%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##           develop     #177      +/-   ##
===========================================
+ Coverage    42.27%   51.90%   +9.63%
===========================================
  Files           87       77      -10
  Lines        12822    13774     +952
===========================================
+ Hits          5421     7150    +1729
+ Misses        7401     6624     -777

Impacted Files
Coverage Δ

src/abci/mod.rs
0.00% <0.00%> (ø)

src/abci/node.rs
0.00% <0.00%> (ø)

src/abci/tendermint_client.rs
0.00% <0.00%> (ø)

src/coins/staking/mod.rs
53.95% <0.00%> (ø)

src/error.rs
100.00% <ø> (ø)

src/ibc/messages.rs
0.00% <0.00%> (ø)

src/ibc/query.rs
0.00% <0.00%> (ø)

src/ibc/router.rs
0.00% <0.00%> (ø)

src/ibc/service.rs
0.00% <0.00%> (ø)

src/ibc/transfer.rs
0.42% <0.00%> (+0.42%)
:arrow_up:

... and 13 more

... and 9 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Pulldown GPIO27 not working

I build the project but it was not working. The CPC starts, but the PicoROM did not.
After a while I realized that the signals on the diode OR gate were not getting through. The output to GPIO27 was always high. I could see this on the scope.
I than added a 2k2 pulldown resistor on the output of the OR gate and then it worked (!).
I do not understand why the pulldown you enabled on the Pico for GPIO27 is not working.
I tried 3 different Pico’s boards, but none of them work without the 2k2 pulldown resistor.
I tried this on a CPC464 and a CPC6128. The PicoROM on the CPC64 is working perfectly (with the 2k2 resistor). On the CPC6128 it works but is not stable. For example: If I use the |PDIR command it works, but when I use the |ROMS command, the CPC6128 restarts or shows garble.
Any idea’s what I did wrong?
p.s. I used the original Pico board without the WIFI option.

Regarding the pull-down resistors, it looks like I've tried to simplify my design too much. From what I've read, it seems that the pull-up/down resistors are only really for unconnected pins. I also use a pull-up on GPIO22, so maybe this should be an external resistor as well. I must have got lucky when testing with my CPC464.
Did you try any other resistor values? I think it's a good idea to add external resistor, but 2k2 seems a bit low. Does 4k7 or even 10k work?
Regarding the CPC6128, this might be related to the internal DOS ROM. I don't have a 6128 to test with. Can you with nothing in slot 7 in the config file?

Looking at the signal on GPIO22, I don’t think an external resistor is necessary. I tried it anyway (4k7), but it makes no difference on the CPC6128.
I also tried leaving slot 7 empty in the config file. This makes no difference. Even without the config file and only the CPC6128, BASIC and PicoROM ROM files the CPC6128 restarts when typing the |ROMS command. So is that hardware or software related, what do you think?
Regarding to GPIO27. I did try other resistor values, starting with 10k and then 4k7. But these did not work (signal still looked bad on the scope), but 2k2 did.
Might it be useful if I to try adding an OR gate using a 74LS32 instead of the diodes? See what that does?

Just te make sure I build an OR gate with the a 74LS32 instead of using the 3 diodes.
It works fine on the CPC464 but still the same  problem on the CPC6128. So it looks to me that this is software problem. The diode OR gate is fine, as long  as an external pulldown resistor is added.


HOTFIX: multi-thread Q conversations

HOTFIX
MyLife Avatar is not creating individual session threads for conversing with guests. Individuation might be more difficult because we were maintaining conversations at the avatar level, but I believe each factory is distinct? In any case, whether above @session, or below @factory, trigger the requirement to instigate a new thread with each session encounter.
Tested that otherwise system is maintaining session-level integrity (such as this.#registrationData)

is less damaging or ubiquitous than I thought, but the problem isn't with the avatars per se, it's with Q as being locked (like any other avatar would be safely) to a thread_id in the cosmos document; ergo, need to think about how to fix without injuring member-based avatar integrity... this might require the separation out of Q v. (member) Avatar as a class extension...

okay - plan is to fold in multiple tickets

[ ] in conversation, clean up botId (make ALWAYS id) and bot_id (make ALWAYS asst_*)


[dif] Codify API conventions for DIF libraries

This PR also includes a "template header" that we can decide to include or not. Either way, I will likely use it to make my conversion of existing DIFs go faster.
Also, I haven't written anything up regarding start() and end(). @lenary I would actually appreciate if you could suggest text for this, since I'm not entirely sure what your thoughts are on it.
This PR will be followed up by one or more PRs in which I bring all the DIFs into compliance with this codified guidance. I might file a bug to track each one, depending on how I decide to do it.
See https://docs.google.com/document/d/1J_gsJQj7I87Yz713f6PnpdLqsFaH1QO9duEo7ninCdc/edit#heading=h.kwfi4wpuqfsv for context.

@lenary regarding _start() and _end(), I know we had intended to include them in this PR, but I didn't get the impression there was a clear pattern from looking at existing examples. Since you proposed including them, I was hoping you could suggest signatures, since I feel like I'm missing something obvious.

@lenary regarding _start() and _end(), I know we had intended to include them in this PR, but I didn't get the impression there was a clear pattern from looking at existing examples. Since you proposed including them, I was hoping you could suggest signatures, since I feel like I'm missing something obvious.

So, looking at HMAC, and partially AES, we end up with a start function that looks something like this:

result_t dif_<ip>_start(dif_<ip>_t *handle, <transaction configuration params>);
Though in HMAC and AES both have per-mode start functions, in HMAC's case called dif_<ip>_mode_<mode>_start (because each mode takes a different set of params).

HMAC doesn't have an explicitly mentioned "finish transaction" function, but actually dif_hmac_digest_read does the same thing (with an out-param for reading back the final digest). AES has dif_aes_end which finishes an AES operation correctly (and is not per-mode), so I think we end with something like:

result_t dif_<ip>_end(dif_<ip>_t *handle, <transaction out-params>);
Or, if per-mode end functions are needed, we call them dif_<ip>_mode_<mode>_end, so each can have different out-params.

It might be worth stating explicitly that we don't think this kind of transactional peripheral will ever have an explicit dif_<ip>_config function, because that is explicitly only done per-transaction, not once-per-runtime. (Let's gloss over endianness details here, because we haven't established what we're doing about those here).

In Design Reviews today, @gkelly and I do think that we should codify how register locking should work. I know @alphan has had thoughts about this too: that we should add a Locked return code, which denotes the registers you tried to modify were locked.
I think in addition to that extra return code, we should have naming conventions for the two functions to lock some register state, and to check if register state is locked, and we should mandate that these have documentation cross-references to the functions that won't work if state is locked. Do you have suggestions for names there?

@lenary Ok, that sounds good. Here's my proposed names for transactional stuff:

Transaction Management
The following types and functions form a standard interface for transaction-oriented peripherals, in which a
client schedules an operation to be completed at some point in the future.

dif_<ip>_transaction_t is a struct representing runtime parameters for starting a hardware
transaction. It is only present when dif_<ip>_start() is defined. This type is always passed by value.
dif_<ip>_output_t is a struct describing how to output a completed transaction. Often, this will be a
type like uint8_t *.
result_t dif_<ip>_start(const dif_<ip>_t *handle, dif_<ip>_transaction_t transaction); starts a
transaction on a transaction-oriented peripheral. This function may be called multiple times, but
each call should be paired with a dif_<ip>_end() call.
result_t dif_<ip>_end(const dif_<ip>_t *handle, dif_<ip>_output_t out); completes a transaction started with
dif_<ip>_start(), writing its results to a location specified in out.

If a peripheral supports multiple transaction modes with incompatible parameter types, the above names
may be duplicated by inserting mode_<mode> after <ip>. For example,
result_t dif_<ip>_mode_<mode>_end(const dif_<ip>_t *handle, dif_<ip>_mode_<mode>_output_t out);

There is no requirement that _start() and _end() share the same set of <mode>s; for example, there
might be a single dif_<ip>_start() but many dif_<ip>_mode_<mode>_end()s.

I'd also add a note regarding configure().
For locking, I propose the following:

For lockout errors, mandate the name kDif<ip><operation>Locked. I think we should allow including it in
the "general" result enum, too, as kDif<ip>Locked.
Addresult_t dif_<ip>_lock(const dif_<ip>_t *handle); to the lifecycle functions, with a description like "Locks
a peripheral-specific set of functionality, preventing further modification until reset." Should we allow variants
like dif_<ip>_lock_<operation>() for peripherals that can be piecewise locked? Do we want dif_<ip>_lock_params_t?
The same for result_t dif_<ip>_is_locked(const dif_<ip>_t *handle, bool *is_locked);.

Thoughts? +@gkelly as well.

Alphan + Jon, thanks for proof-reading. =)

Re transactions: that looks good enough for now -- keep the dif_<ip>_transaction_t and dif_<ip>_output_t as optional as there are often more semantic names we can give those parameters. Maybe point out that using multiple <mode> functions is vastly preferred to putting a union anywhere near dif_<ip>_transaction_t.
Re locking: We certainly should prepare for peripherals that can be piecewise locked.


Cant build project  on linux

I just added tcod to my Cargo.toml file and build it... it doesn't seem to work

Hey @Sangsua! I'm sorry for the trouble!
Can you please show us the rest of the log (lines after 25)?
Also, tcod-sys requires some libraries to be installed:
https://github.com/tomassedovic/tcod-rs#building-on-linux
Please try installing them (sudo apt-get install gcc g++ make libsdl2-dev), that should help if you didn't do it already.
What is your Linux distro? The instructions are for Ubuntu, the actual command and package names would be different on other distros.

I'm using Manjaro, it doesn't seem to have libsdl2-dev :( . Here is the rest of the log.

Thanks! So the tcod-sys build script cannot find the SDL2 package. Looks like Arch and Manjaro bundle the header files with the libraries.
Try installing the sdl2 package.

pkg-config and sdl2 were the culprits. :) thanks for the help


Feature Request: Pause Progress

Hi,
I have some use-cases for when a task takes quite a bit of time and the progress bar gets to the end before the task is actually complete and before I have asked it to $Progress.finish().
Could we possibly pause it at say a certain percentage for such cases and then finish it upon completion of task?

You could use this.$Progress.set(num) perhaps?

That just begins the growth of the bar at the set percentage as opposed to doing quite the opposite - pausing the growth at a certain percentage.

in vue-progressbar.js add this function -
pause () {
this.$root.RADON_LOADING_BAR.percent = this.$root.RADON_LOADING_BAR.percent
clearInterval(this.state.timer)
},
and in the existing start() function, change the line -
this.$root.RADON_LOADING_BAR.percent = 0
to
this.$root.RADON_LOADING_BAR.percent = this.$root.RADON_LOADING_BAR.percent
Hopefully that helps.

Thanks for @ilongley 's pr

Many thanks for this. Any chance of updating the NPM package?

@kJamesy I just updated it.

Working perfectly, many thanks!


Added config parameters to font loading functions

This is in response to #12.
There is now an added ImFontConfig config parameters to all font loading functions, which serves as a "template" for the actual config (much like how imgui does it internally too). I've also exposed MergeFontAwesomeToLastFont so that it's easier to use a different configuration (and size) for both icon font & regular font.
Example usage:
auto& io = ImGui::GetIO();

ImFontConfig configIcons;
configIcons.GlyphMinAdvanceX = 18;
configIcons.GlyphMaxAdvanceX = 18;

io.FontDefault = HelloImGui::LoadFontTTF("fonts/DroidSans.ttf", 16);
HelloImGui::MergeFontAwesomeToLastFont(15, configIcons);

I have also removed the lambda's creating the config structures as well as the static variables intended to keep the config structures in memory as it doesn't appear to be necessary.

I have also removed the lambda's creating the config structures as well as the static variables intended to keep the config structures in memory as it doesn't appear to be necessary.

You are right, thanks for pointing this out! I now remember I had an issue with the glyph_range param of AddFontFromMemoryTTF, not with the config in itself.
Your PR looks good to me, and brings value!
Are you OK to merge?

Ah good point, I didn't see that one! I kept those arrays static however, so the PR should still be correct. If all looks okay to you, I'm ok to merge!


(Draft) Development plan for pvlib-python

A small group of maintainers and developers drafted this Development roadmap for the next several releases of pvlib.  Contributions to all areas of pvlib are always welcome.
We hope that the roadmap provides pvlib users with advance notice of several intended changes, and suggests priorities for pvlib developers.
Comments on the road map are welcome. Volunteers to take on development tasks are very welcome.

@cwhanse Very nice with a roadmap, I'm particularly interested in the weather resources mentioned. First I can mention that I'm working on pull requests for PVGIS hourly radiation and SoDa-Pro CAMS and McClear. Also, a reader for BSRN files has been added.
Now, I think it would be very valuable to add support for retrieving MERRA-2 data. The Roadmap lists the provider as SoDa-Pro however, SoDa-Pro does not make MERRA2 available for free (unlike CAMS & McClear which are freely available through SoDa-Pro). I would imagine that it would be possible to get MERRA2 for free directly from NASA?
Also, what would be the use case for adding access to the World Bank Global Solar Atlas?

@AdamRJensen I am not familiar with the MERRA2 dataset or its sources. @mikofski? I am confident there is interest in a reader for pvlib.
The World Bank solar data set hasn't been brought up before. It appears to be SolarGIS's data combined with a relatively simple PV output model, which also appears to be sourced from SolarGIS. One advantage is global coverage. I'm not opposed to a World Bank reader. But I suspect that the World Bank's data is of less interest to pvlib users than other irradiance data sources.

@cwhanse I do believe that you are right in that the World Bank Global Solar Atlas is compiled from SolarGIS data, however, the atlas only provides annual average values and not any time-serie data. This is why I question its usability for pvlib users and perhaps that it should be removed from the roadmap.

@mikofski your thoughts on the usefulness of the World Bank solar data? I think you had added it to the roadmap.

Sorry, tbh i'm not using world bank data. I think a coworker recommended it.

I'll downvote it's relevance. Let's put off any effort to add a reader for the World Bank data set.

@mikofski NSRDB is listed as incomplete in the roadmap, speficially "Individual site years (1991-2010) data" is missing.
@kanderso-nrel and I had a look and that data seems quite outdated and probably only available in one large zip file.
Are we still interesting in somehow adding this to pvlib or can it be removed from the roadmap?

Good points, I don't know what the best path is, or what others think. I think there's a lot of value in this data, and there's really no other alternative. I am strongly in favor of timeseries analysis over TMY, but you're right that it's starting to be old data (>10 years) and if it's in a zip file, no clear path to how we manage it, I don't think bundling is an option.
I agree, let's cross it off the list if everyone else agrees it's not worth it, or we can move to "won't do" and perhaps in the future we'll find somewhere the data is hosted and we can reconsider?

@mikofski Out of curiosity, what makes you say that it has a lot of value? I would imagine that NREL's current NSRDB PSM3 has better coverage and is more accurate, hence they have stopped servicing it and put it in a zip archive.

PSM3 tmy has consistently shown a high bias, not everywhere, but on average, at least for the projects I've worked on. I don't know if this extends to the 5 min time series data, but it seems likely.  On the other hand tmy3 has been consistently closer to the median of other collocated solar resources

@mikofski @kanderso-nrel I met up with Manajit from NREL (who's one of the people behind the NSRDB) yesterday and brought up this topic. He was quite clear in that NREL prefers pvlib not to provide data retrieval functions for the older datasets as PSM3 is significantly more accurate and the older versions are confusing users. Unless anyone objects I'll remove "Individual site years (1991-2010) data" from the roadmap. Do also note that PSM3 also supports the generation of TMYs.

I don't agree with removing the capability to access the older data, some people still use it for historical purposes or because a previous analysis is conditioned on that data. If NREL doesn't want people to use that data, they could remove it from their servers.

Perhaps my post was not clear. I certainly don't intend to remove any existing functionality. But I am suggesting not adding retrieval capabilities (a get function) for the "Individual site years (1991-2010) data" - hence removing the unticked box on the roadmap. The data is stored in one large zip file, so it isn't easily accessible anyways.

Thanks for the clarification - I should have looked at the roadmap first. Are you saying that we will not add a get function to retrieve the 'MTS3' data indicated here?

I'm fine with removing from the roadmap retrieval of the older timeseries data that was used to generate TMY2 and TMY3, but I disagree with the assertion that we should stop using this data, and I haven't seen any reliable proof that the PSM3 data sets are significantly better. However, I don't see logistically how we can store the old datasets.


"Error occured when calling imagethumbnails" message

Thumbnailing JPEGs failed with a
20:44:31 hyde Error occured when calling imagethumbnails
This line:
https://github.com/hyde/hyde/blob/7f415402cc3e007a746eb2b5bc102281fdb415bd/hyde/ext/plugins/images.py#L295
hyde converts the PIL image to RGBA, but that fails with Pillow after v3.7 because it was deprecated and then removed:
https://github.com/python-pillow/Pillow/commit/193c7561392fd12c3bd93bc232d9041c89bec4f6
with the advice to convert to RGB before saving. I think the solution for hyde is to not convert to RGBA on line 295 for JPEG files.
short diff attached tests and only converts non-JPEG to RGBA.
diff.txt
(Let me know if you'd rather I did a fork and PR, but its about two lines!)

(Let me know if you'd rather I did a fork and PR, but it's about two lines!)

Yes, please. Please note: Hyde has been unmaintained for quite sometime though. I still use it in a few of my projects and I know it's still used elsewhere.


Annotated function

Adding means to annotate functions to be executed by HPX

makes annotation string available in the debugger
integrates with VTune and APEX

I merged the branch to master this morning.
Am 03.02.2017 1:28 nachm. schrieb "Hartmut Kaiser"<EMAIL_ADDRESS>
:

@hkaiser commented on this pull request.
In hpx/runtime/actions/basic_action.hpp
https://github.com/STEllAR-GROUP/hpx/pull/2476:

@@ -807,6 +836,23 @@ namespace hpx { namespace serialization
#define HPX_DEFINE_GET_ACTION_NAME(action)
HPX_DEFINE_GET_ACTION_NAME_(action, action)
/**/
+#if defined(HPX_HAVE_ITTNOTIFY) && !defined(HPX_HAVE_APEX)

Right, I need to re-integrate the changes from the itt_notify branch to
here. Rebasing onto master will not help at this point.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/pull/2476, or mute the thread
https://github.com/notifications/unsubscribe-auth/AADRl6i8MIqq6ZPeIh_g0Wrl2WmHhkHDks5rYx1ogaJpZM4L0gxn
.

@sithhell your comments have been addressed


Hiding Files

Should be done in tandem with adding files to collection. Helps support batch processing
Files cannot be hidden. This may need to be a separate feature we build alongside files to Collections. (cc @nagem )

Will not implement - instead implementing file delete and cleanup


[FEATURE] Handle multisearch requests

Is your feature request related to a problem?
Currently, the plugin only handles requests of type SearchRequest. The plugin should also handle MultiSearchRequest objects.
What solution would you like?
Modify the action filter to handle MultiSearchRequests. Handle each SearchRequest in the MultiSearchRequest in the same way the plugin does now.

I recently complained about the lack of Multi-Search support for pipelines, and made the bold statement "We need to make sure everything supports Multi-Search or we should Deprecate it or rename it 'Dashboard Search'.".   Now, in finding this issue with the plugin I contributed to, I am "hoist on my own petard" ;-).   So let's make sure UBI supports Multi-Search!  cc @msfroh ;-)

[Search Triage] - The group has the opinion that the gaps (if any) in design with multi-seach should be discussed further in OpenSearch repo as well. @epugh @jainankitk to initiate the discussion with an initial draft.


Straight Maximum algorithm

/assign
Hey!
I want Like to contribute Straight Maximum algorithm Program.
It will find Maximum and Minimum element in one loop.
Time complexity-theta(n)
please assign me this issue.

/assign
Hey!
I want Like to contribute Straight Maximum algorithm Program.
It will find Maximum and Minimum element in one loop.
Time complexity-theta(n)
please assign me this issue.


Autoplacing of the dropdown menu in the Select

When the dropdown menu fails to place it automatically.

@MarikTar Try to use<EMAIL_ADDRESS>Changes:

Added Select dropdown auto-placement.
Added Autocomplete dropdown auto-placement.

Please test

@donskov, thanks, i tried it and can suggest the following:

placement : 'top' | 'bottom' | 'auto' = 'bottom' not all dropdown need apply automatically orientation for example:

bottom
auto

or in mobile version.
it also prevents that if someone uses this library will face the problem that the "placement" is no longer available.

on mobile i have next problem

if page have fixed "footer" happened next (can use z-index but this not good solution):

no footer
have footer

P.S. I do not know if it will be appropriate, but I would add an auto-flip of the arrow.

@MarikTar Published<EMAIL_ADDRESS>
Fixed dropdown left position.
Added props:

/**
 * Component dropdown start opened direction.
 */
placement: PropTypes.oneOf(['top', 'bottom']),
/**
 * If `true`, component will automatically calc possible dropdown opened direction.
 */
flip: PropTypes.bool,

Please try to use

Added auto-flip for the arrow

Added auto-flip for the arrow


Enhance NodePath property editing

Change Clear button to a menu
Add "Copy as Text" option, to copy the NodePath as text (accepts invalid paths too, so you can reference singletons or nodes from other scenes etc.)
Add "Edit" option, to edit the NodePath manually
Add "Show Node in Tree", which selects the target node (if available)

https://user-images.githubusercontent.com/2223172/227358453-60a6af56-b1fb-40e4-9470-32fc21046494.mp4
Closes #25289

I assume most people mainly need editing and clearing, so I'm wondering if we can spare the extra click so clearing a bunch of node paths doesn't take 4 times as long...

Edit could be replaced by a line edit in the node selection menu.
Copy as Text can be copied from that line edit, and we also have the "Copy Value" functionality on properties anyway.
Can't think of anything different for View in Tree, so maybe it could be a second button

Change Clear button to a menu

I'm not too sure about this but would it be possible to add them it to the menu that pops on right click and has "copy/paste value" instead of creating a new menu.

Add "Copy as Text" option, to copy the NodePath as text (accepts invalid paths too, so you can reference singletons or nodes from other scenes etc.)

It feels like "copy / paste Value" should work like that instead of creating another functionality for it

Add "Edit" option, to edit the NodePath manually

I think this should replace the clear button. But maybe this is just me as i mostly never use it and use the revert to default button.

Needs rebase. Then maybe @Calinou can review?

Rebased. I ended up doing some refactoring, but I kept the behavior for now.

I considered replacing the menu button with right-click context menu, but a button is better for discoverability.

I'd suggest supporting both if possible :slightly_smiling_face:

I could experiment with selecting single node, but either it would switch the inspector (so the node you were editing right now would disappear) or, if it's possible to preserve edited node, the inspector would show old node with another one selected in scene tree. Maybe the latter is fine, same happens when you are dragging a node.

Thanks!


cybertron: add example for cybertron embeddings

cybertron: add example for cybertron embeddings

Updated the .gitignore file to ignore the models generated in the
new example directory 'examples/cybertron-embedding-example/models/*'.
Added a new example 'cybertron-embedding.go' in
'examples/cybertron-embedding-example' directory. This example
demonstrates the usage of embeddings in the context of the
'cybertron' package.
Added the necessary go.mod and go.sum files for the new example.

The changes provide a practical example of how to use embeddings with
the 'cybertron' package. The update to .gitignore prevents the version
control system from tracking the unnecessary model files generated by
the new example.
Resolves #494
PR Checklist

[X] Read the Contributing documentation.
[X] Read the Code of conduct documentation.
[X] Name your Pull Request title clearly, concisely, and prefixed with the name of the primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
[X] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[X] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. Fixes #123).
[X] Describes the source of new concepts.
[X] References existing implementations as appropriate.
[X] Contains test coverage for new functions.
[ ] Passes all golangci-lint checks.

Note: this uses github.com/tmc/langchaingo v0.1.4-0.20240123022810-6f20ee5cf8df as the related changes haven't been released yet. Feel free to keep this open until v0.1.5 if you prefer.


fix(select): hightlight index

https://github.com/uber-web/baseui/issues/1998
Description
Fixed select highlight index
Scope

[x] Patch: Bug Fix

@chasestarr @gergelyke how do I fix "screener found visual regression" error in build? I don't have access to screener app to check build logs


Added patch to fix compilation with ncurses 6.3__2.13-3

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Summary

What does the PR accomplish, why was it needed?
Added patch to fix compliation with ncurses 6.3.
version: n 2.12-3
Test Methodology

Pipeline build id: xxxx

Looks good, two small suggestions removing empty lines.
Please fill out the summary with asked information, thanks!

Done


Plugin teies to create pwa manifest and not working

Hi everyone!
I'm trying set favicon. Here is my vite config file:
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import tsconfigPaths from "vite-tsconfig-paths";
import checker from "vite-plugin-checker";
import vitePluginFaviconsInject from "vite-plugin-favicons-inject";

export default defineConfig({
  build: {
    outDir: "./public",
  },
  server: { port: 8082 },
  plugins: [
    react(),
    tsconfigPaths(),
    checker({ typescript: true, stylelint: false }),
    vitePluginFaviconsInject("./src/favicon.svg"),
  ],
  css: {
    preprocessorOptions: {
      less: {
        ...
      },
    },
  },
});

Result:

And of course there is no favicon appears in the browser tab.
Looks like the plugin tries to create pwa manifest, but it's quite an overkill for my app. I need to set plain svg or ico favicon. Can anyone help me?

As mentioned here(https://github.com/JohnPremKumar/vite-plugin-favicons-inject#development-mode). The files will be generated only during production build. Refer the link for more information

As mentioned here(https://github.com/JohnPremKumar/vite-plugin-favicons-inject#development-mode). The files will be generated only during production build. Refer the link for more information

It works! Thank you very much!


Simplify path handling logic in dependency checker and devFS

Simplification will make it easier to port this to Windows.
DO NOT SUBMIT until engine is rolled to include https://github.com/flutter/engine/pull/3449.
Test are also failing until engine roll is included in this PR
/cc @johnmccutchan

LGTM

The roll two prior to this one, https://github.com/flutter/flutter/pull/8402, regressed some benchmarks.


Icons don't show up (VsCode 1.3.1) Fedora

After setting the right privileges and enabling icons
OS: Fedora 24
VsCode 1.3.1

This is my finding, with 1.3.1, too - Windows 10

Here too, Fedora 23

See #79

Hey guys, can you reinstall your VSCode and download 1.4.0 version of this extension? Don't worry as your extensions and configurations won't be lost. 😉

Still see no icons...

Works fine on Windows 10 (build 10586.494) with VS Code 1.3.1 & 1.4.0-insiders (2016-07-13T05:07:03.170Z).

@jsnjack have you make a clean install of vscode? Are you getting some error? Could you open the   Developer Tools and see if you have some message in your console?

I reinstalled it with dnf, then executed chown command, then F1 -> Enable icons. Vscode restarts and I'm getting no errors. My developer tools shows only:
[Extension Host] vscode-icons is active!

I guess you've used 1.4.0 version of the extension, haven't you? Just to discard things...

I'm on a Win10 preview build (14372). Removed & Reinstalled VSCode & added the extension; still have the same issue.
The dev console, too, reads: [Extension Host] vscode-icons is active!

Yes, I updated it from the vscode before reinstalling it. I don't see the way to say what exactly version it is, but it is the latest at the moment (which is 1.4.0, I guess)

@NeilAllen have you used the Enable Icons command?

That's Cracked it!
Icons Enable
Apologies if I've lead you on a wild goose-chase.
N

It works for me with the 1.4 version :+1:

@jsnjack it seems that @eladcandroid has managed to make it work in Fedora 24 with 1.4.0. In order to check this, you can go to the extension manager on the left tool bar and see which is the version you have installed.

I already checked it in the extension folder. I have 1.4.0 installed

@jsnjack try icons update command

@robertohuertasm Update command worked! Thank you!


do not default the internal registry hostname to anything

/assign @deads2k

/lgtm
This correctly reflects the state of the system as not having a registry so that consumers of this value can distinguish between "no registry exists" and "a registry exists" state.


Patch for auto-attaching relative images

Hello,
Thank you for your project! It's just what we were looking for.
We had a few markdown files with relative-path images like this:
![](./some-image.png)

Manually adding <!-- Attachment: ./some-image.png --> felt tedious so we wrote a patch, sharing it here:
From b62a8393b80acd0702f7fa0e3dddbc7bedf11f92 Mon Sep 17 00:00:00 2001
From: Sean <snip@localhost>
Date: Tue, 7 Jun 2022 12:22:37 -0700
Subject: [PATCH] feat: autoextract images

---
 main.go              |  6 ++++++
 pkg/mark/markdown.go | 12 ++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/main.go b/main.go
index 1b2707f..4863f67 100644
--- a/main.go
+++ b/main.go
@@ -37,6 +37,7 @@ type Flags struct {
 	Config         string `docopt:"--config"`
 	Ci             bool   `docopt:"--ci"`
 	Space          string `docopt:"--space"`
+	AttachmentsFromImg bool   `docopt:"--attachments-from-img"`
 }

 const (
@@ -71,6 +72,7 @@ Options:
   --drop-h1            Don't include H1 headings in Confluence output.
   --title-from-h1      Extract page title from a leading H1 heading. If no H1 heading
                         on a page then title must be set in a page metadata.
+  --attachments-from-img      Automatically add attachments for relative-path images.
   --dry-run            Resolve page and ancestry, show resulting HTML and exit.
   --compile-only       Show resulting HTML and don't update Confluence page content.
   --minor-edit         Don't send notifications while updating Confluence page.
@@ -224,6 +226,10 @@ func processFile(
 		)
 	}

+	if flags.AttachmentsFromImg {
+		meta.Attachments = append(meta.Attachments, mark.ExtractDocumentRelativeImages(markdown)...)
+	}
+
 	stdlib, err := stdlib.New(api)
 	if err != nil {
 		log.Fatal(err)
diff --git a/pkg/mark/markdown.go b/pkg/mark/markdown.go
index 06c2128..25a7608 100644
--- a/pkg/mark/markdown.go
+++ b/pkg/mark/markdown.go
@@ -159,3 +159,15 @@ func ExtractDocumentLeadingH1(markdown []byte) string {
 		return string(groups[1])
 	}
 }
+
+func ExtractDocumentRelativeImages(markdown []byte) []string {
+	img := regexp.MustCompile(`!\[[^\]]*\]\((\./[^\)]+)\)`)
+	groups := img.FindAllSubmatch(markdown, len(markdown))
+
+	images := make([]string, len(groups))
+	for i, group := range groups {
+		images[i] = string(group[1])
+	}
+
+	return images
+}
--
2.35.1

I avoided autoformatting to keep the patch clean, but the struct properties and doc text do not line up correctly. I also haven't updated the readme & co. Not sure if adding this feature would be scope creep, but it's here for anybody who wants it 🤠
Thanks!

Hi, thank you for the patch and your support on patreon.
We can also go with something like <!-- Attachment: ./img/* --> in such a case.

This would be a very helpful feature. @kovetskiy would you mind if I made a PR for this patch?

@neontty Were you planning to do the PR? We planned to upload Typedoc generated MDs to Confluence, so this would be quite helpful within that.


IPSec Option missing

I see that the pallete has the option for FastConnect but I don't see IPSec VPN option, though i see the list properties of DRG showing that.

@tariqalimkhan which version are you using because the fast connect has been removed from the palette given it was there by mistake.

Thanks for your reply. I am using 0.8.

In fact this is the palette I have

@tariqalimkhan Yes we currently have some miss match and the IPSec code was pulled from an earlier release because it was in complete. The intension was that DRG / FastConnect/IPSec all be released at the same time but this did not happen. We are looking at getting this resolved as soon as we can.

Added to the 0.12.0 release


Pip failed Using miniconda3 on Windows 10

Using:
conda env create -f environment.yaml
return:
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
Installing pip dependencies: | Ran pip subprocess with arguments:
['python.exe', '-m', 'pip', 'install', '-U', '-r', '\condaenv.v4isk7im.requirements.txt']
Pip subprocess output:
Requirement already satisfied: pillow==9.2.0 in c:\users\perro\miniconda3\envs\ldm\lib\site-packages (from -r \condaenv.v4isk7im.requirements.txt (line 10)) (9.2.0)
Obtaining clip from git+https://github.com/openai/CLIP.git@main#egg=clip (from -r \condaenv.v4isk7im.requirements.txt (line 16))
Updating \clip clone (to revision main)
Pip subprocess error:
ERROR: Command errored out with exit status 1: git reset --hard -q d50d76daa670286dd6cacf3bcd80b5e4823fc8e1 Check the logs for full command output.
failed
CondaEnvException: Pip failed
Any idea?

modified to this:
name: ldm
channels:

pytorch
defaults
dependencies:
python=3.8.5
pip=20.3
cudatoolkit=11.3
pytorch=1.11.0
torchvision=0.12.0
numpy=1.19.2
pip:

albumentations==0.4.3
diffusers
opencv-python==<IP_ADDRESS>
pudb==2019.2
invisible-watermark
imageio==2.9.0
imageio-ffmpeg==0.4.2
pytorch-lightning==1.4.2
omegaconf==2.1.1
test-tube>=0.7.5
streamlit>=0.73.1
einops==0.3.0
torch-fidelity==0.3.0
transformers==4.19.2
torchmetrics==0.6.0
kornia==0.6
taming-transformers
openai
-e .

launching dream.py returns:
import k_diffusion as K\r\nModuleNotFoundError: No module named 'k_diffusion'
Any idea?

The k_diffusion library is itself a git repository that is brought in by conda during the install process and saved under src. Sometimes an incomplete install results in a broken src directory. Try removing the src directory and all its contents. Then run `conda env update -f environmental.yaml'
@Neosettler , what changes did you need to make to environment.yaml?

started form scratch and it seems to work now. I'm guessing download and extract repo not the same as git clone repo.

Both methods should do exactly the same thing, but I haven't tested the download and extract method. Is this what you tried at first?


I have some questions.

So im developing two planes for Geofs. A 767 and a f-18c. I want to ask about what I need to do to add livery selector support for them. Another question I have for Kolos is if you are doing well, you haven't updated livery selector in a while. Those are my questions, i'll upload a new livery soon, and i'll see ya soon!

Hi,
Sorry for not updating for like a month. This is my final year at school and I didn't have freetime (thanks for the f16s btw :) ). To make the plane compatible, you only need to do is to make the texture files containing every painted part, there are ones where the plane is white, and only the logos are textured, that wouldn't work. Once you got to texturing, I can help you to make them userfriendly, and check the compatibility.
Happy new year, Kolos


Benchmark and Tests

Benchmark and Tests

Closing as moved to notion (https://www.notion.so/liqwid/Add-benchmarks-and-tests-d9dc58ae9c224b23aac1e9dd4effab09)


"<" in pug doesn't work

env
macOS 10.12.1 Beta
nodejs 6.8.1
vuejs 2.0.3
Steps to reproduce
init a test vue project with default options
vue init webpack test
cd test

edit src/components/Hello.vue
<template lang="pug">
div
  div(v-if!="0 < 0")
</template>

<script>
export default {
}
</script>

then run dev server
npm run dev

What is actually happening?
got error:

><EMAIL_ADDRESS>dev /Users/xiaoxiao/test
> node build/dev-server.js

Listening at http://localhost:8080

webpack: wait until bundle finished: /index.html
webpack built 65f1e5f2bb987f85bda4 in 2618ms
Hash: 65f1e5f2bb987f85bda4
Version: webpack 1.13.2
Time: 2618ms
 Asset    Size  Chunks       Chunk Names
app.js  867 kB       0       app

ERROR in ./src/components/Hello.vue
Module build failed: Error: Error parsing template:

< 0")
</template>

<script>
export default {
}
</script>

    at parseHTML (/Users/xiaoxiao/test/node_modules/vue-template-compiler/build.js:3434:13)
    at Object.parseComponent (/Users/xiaoxiao/test/node_modules/vue-template-compiler/build.js:5171:3)
    at module.exports (/Users/xiaoxiao/test/node_modules/vue-loader/lib/parser.js:15:21)
    at Object.module.exports (/Users/xiaoxiao/test/node_modules/vue-loader/lib/loader.js:145:15)
 @ ./~/babel-loader!./~/vue-loader/lib/selector.js?type=script&index=0!./src/App.vue 7:13-42
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  1.46 MB       0
webpack: bundle is now VALID.

description
Similar issue: https://github.com/vuejs/vue/issues/3731 . However, situations are not the same. Replace "<" with ">" won't trigger this error. It's not a bug of pug as the error occurs before pug was called. In fact, this error happens even if pug is not installed.
Thanks for your time to review this issue.

This is a problem with pug itself. Please refer to the other issues for some hints: https://github.com/vuejs/vue/issues?utf8=✓&q=is%3Aissue is%3Aclosed pug
or open an isuse on the pug repository

@posva As I mentioned:

It's not a bug of pug as the error occurs before pug was called. In fact, this error happens even if pug is not installed.

whioch version of vue-loader is installed?

@LinusBorg<EMAIL_ADDRESS>

This may be an issue related to https://github.com/vuejs/vue/blob/dev/src/compiler/parser/html-parser.js#L47 . Pug is not a xml-like templting engine, so it can contain anything like script tag and style tag. Without specific treat, "<" may break html-parser's parsing procedure.

I think this should have been fixed in 2.0.3:

Seems like it didn't