Question: Purging downloads does not remove temporary files (download.file + download.file.aria2)

Is this expected behavior? Shouldn't it supposed to remove pre-allocated files too?
To re-produce:
1-) Download a file named topkek.exe,
2-) Pause it (you can skip this step),
3-) Purge it
4-) Check download location, you'll see allocated topkek.exe and topkek.exe.aria2 files (topkek.exe is broken indeed)
Thank you for your time.

I think it's related with https://github.com/aria2/aria2/issues/728

Hello @gokaybiz,
It seems to be related to Aria2 as described in the issue that you linked.
There is nothing I can do on my side since I rely 100% on Aria2 API...


maybe a bug in recursive-rox?

Hi brother,
i love those components. Great work indeed.
Look at the pic, i see no actions when clicking it.
https://fishedee.github.io/antd-formily-boost/components/table/recursive-row

Cheers

and this as well
https://fishedee.github.io/antd-formily-boost/components/table/children-r

ow

Thanks,brother, I have fix this problem in 1.3.10


Specify size for load tests

I need to do a load test, where I already have a set of "real" files which I would like to mock
I thought this set of empty files would be perfect to do that, except they have a "small" fixed size
It would be awesome if we could specify a size so that the  file would be appended with dummy data
The issue with this solution is that it can work easily for text based files, but might be much more complex for binary file, and needs to be "custom tailored" for each types of file
Maybe there is a better solution for this feature?
Thank you

sorry. but i think that is out of scope for this project.
happy for you to use any code from this project in creating your own project


Toy dataset generation for examples and getting started

Link to example here: https://github.com/ericspod/RandomDataset/blob/master/examples/exetera_import.ipynb


[Bug]: Resource name leases can get orphaned

What happened?
@dsboulder ran into this why trying to apply CFOrg resources. Presumably there was an org that had the display name "development" at one time in the past, but it no longer existed. The lease for it remained, however, so a new org with that name could not be created.
He used kapp to declaratively apply the orgs so the output looks a little different than normal, but the error should be unrelated to that.
kapp deploy --app korifi-orgs -f - -y
Target cluster '<REDACTED>' (nodes: <REDACTED>, 3+)

Changes

Namespace  Name                Kind   Conds.  Age  Op      Op st.  Wait to    Rs  Ri
cf         cf-org-org1         CFOrg  -       -    create  -       reconcile  -   -
^          cf-org-development  CFOrg  -       -    create  -       reconcile  -   -
^          cf-org-org2         CFOrg  -       -    create  -       reconcile  -   -
^          cf-org-org3         CFOrg  -       -    create  -       reconcile  -   -

Op:      4 create, 0 delete, 0 update, 0 noop, 0 exists
Wait to: 4 reconcile, 0 delete, 0 noop

8:31:13PM: ---- applying 4 changes [0/4 done] ----
8:31:13PM: create cforg/cf-org-development (korifi.cloudfoundry.org/v1alpha1) namespace: cf

kapp: Error: Applying create cforg/cf-org-development (korifi.cloudfoundry.org/v1alpha1) namespace: cf:
  Creating resource cforg/cf-org-development (korifi.cloudfoundry.org/v1alpha1) namespace: cf:
    API server says: admission webhook "vcforg.korifi.cloudfoundry.org" denied the request: {"validationErrorType":"DuplicateNameError","message":"Organization 'development' already exists."} (reason: {"validationErrorType":"DuplicateNameError","message":"Organization 'development' already exists."})

What you expected to happen
I expected there not to be an orphaned lease.
Acceptance Criteria
GIVEN a resource with a given displayName not exist on the cluster
WHEN I try to create a resource with that displayName
THEN I see the creation succeeds and I do not see any DuplicateNameError errors claiming the resource exists
How to reproduce it (as minimally and precisely as possible)
Unclear how this happened. It's possible there is a race condition in the DuplicateValidator webhook or that updating the lease failed somehow during deletion.
Anything else we need to know?
If we pick up this bug we need to make sure that the fix isn't worse than the bug. Sometimes failures to update the lease are acceptable during deletion (such as when the lease does not exist) and we don't want to break uninstallation somehow.
Environment
Revision of codebase: 2286a62f2ebcb58e103d0a2efeed1c6d2beda0c4
Kubernetes version (use kubectl version): Unknown
Cloud provider or hardware configuration: Unknown
Others:

Hmmm, the DuplicateValidator seems to be quite thread safe, it is making use of the optimistic locking idiom. However, in order that validator to kick in and handle org delete and delete the lease, korifi controllers should have been running when the CFOrg has been being deleted. Can we confirm whether this has been the case?


Update demo gif in README

Feature request-
Update demo gif in README with the new changes.

Note:

Do mention if your are working under GSSoC'21.
If you want to work on an issue, you should check if it has already been assigned to anyone. If the issue is free you can comment /assign to get the issue assigned to you.
If you are raising a new issue and want to work on it then also you should comment /assign under the issue to get it auto assigned.
Please refrain from adding labels to your issue/pull-request on your own. It is the job of the Project Admin and the Mentors to review your issue/pull-request and add labels accordingly.
According to the level of the issue, respective time will be allotted under which the task needs to be completed/resolved by the assigned person. If the issue is not resolved within the given time, it will be assigned to the next person. In case of any discrepancies, the decision of the maintainer will be final.

level - 0: 2 days
level - 1: 3 days
level - 2: 4 days
level - 3: 5 days

/assign

Hey! I had a doubt. When I am signing up its showing an error. How do I continue making a gif.

Hey! I had a doubt. When I am signing up its showing an error. How do I continue making a gif.

Yes, check #780. I would suggest make the gif while running the website on your local server, then I think you would be able to sign in..

Ok will try

I tried recording the screen but the website is getting hanged alot which is creating a very long video including all steps and even the size is becoming very big. Can u suggest some alternative.

I tried recording the screen but the website is getting hanged alot which is creating a very long video including all steps and even the size is becoming very big. Can u suggest some alternative.

Video does get long sometimes don't worry, create the gif.
What is the size of the video?

It was exceeding around 20MB. I am trying once again. Will fix it by tomorrow.


Various updates to pull_request_labeler

Fix cli description of --prs
Make add and remove optional
Add ability to also add a comment about why the labels are changing
Add normalization of PR formats to org/repo#pr format

@jrafanie Please review.

I used these changes to blast out a label change and comment about it.

Oh I added that too... There's an Optim isst.die check that was added


Bump all versions in package.json up (and corresponding package-lock)

Bump the node package versions.
I tested npm start, npm run build and npm test.

@jotak do you know why the snapshot assertion in MetricsOptionsBar.test are failing?

I'm repushing adding the ts-jest library it was complaining about.

I ran npm install and npm test from this PR and it didn't fail for me.
Then I removed my node_modules and repeat the operation and it failed.
So it must be a change in how snapshots are generated with the new dependencies. I'm not sure which is the 'guilty' library, since enzyme-adapter-react-16 and enzyme didn't change, maybe the change comes from caret or tilde resolution? Or maybe it's a side-effect from another dependency.
To avoid that in the future maybe we should prefer tilde over caret most of the time, or even strict version?
Anyway @mtho11 can you delete the failing snapshot file to fix it? It's src/components/MetricsOptions/__tests__/__snapshots__/MetricsOptionsBar.test.tsx.snap

By the way, when running npm install locally it complained about the version of node-sass-chokidar, apparently 1.1.1 isn't valid anymore, should be bumped to 1.1.2

I guess this is waiting until after sprint 2. First thing sprint 3.

I updated the libs to latest versions.

Closed in favor of https://github.com/kiali/kiali-ui/pull/190


Unknown field 'imageEmbedding' in vector field list.

Please provide us with the following information:

This issue is for a: (mark with an x)
- [x ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce
Following the README to setup an environment.
Set azd env set USE_GPT4V true and run azd up:
AI region: swedencentral
No error messages
Goto the url given
switch to GP4_v in the developer settings
click on one of the given questions
Error: The app encountered an error processing your request.
If you are an administrator of the app, view the full error in the logs. See aka.ms/appservice-logs for more information.
Error type: <class 'azure.core.exceptions.HttpResponseError'>
Any log messages given by the failure

(InvalidRequestParameter) Unknown field 'imageEmbedding' in vector field list.
Code: InvalidRequestParameter
Message: Unknown field 'imageEmbedding' in vector field list.
Exception Details:	(UnknownField) Unknown field 'imageEmbedding' in vector field list.
Code: UnknownField
Message: Unknown field 'imageEmbedding' in vector field list.
Expected/desired behavior

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)
windows 11

azd version?

run azd version and copy paste here.
azd version 1.6.1 (commit eba2c978b5443fdb002c95add4011d9e63c2e76f)

Versions

Mention any other details that might be useful

Thanks! We'll be in touch soon.

Was this your first time running azd up? If you ran it previously before enabling GPT-4-V, you'd need to delete the index, so that it could be recreated with the imageEmbedding field.
Is it possible that you enabled the Integrated Vectorization feature? That is not compatible with GPT-4-V, so it would need to be set to false.

Hi @pamelafox,
We have the same problem. We had to activate the integrated vectorization function in order to successfully build the index with custom documents. Without the feature we are getting the following error:
´´´bash
openai.BadRequestError: Error code: 400 - {'error': {'message': "This model's maximum context length is 8192 tokens, however you requested 10515 tokens (10515 in your prompt; 0 for the completion). Please reduce your prompt; or completion length.", 'type': 'invalid_request_error', 'param': None, 'code': None}}
´´´
I see in your second point, that the feature is not compatible with gpt-4v. Anything else can we do to overcome this issues or do we have to wait for compatibility? :)
Best regards,
Mirco

Ah, I was unprecise in my description. The error I describe in my comment is an upstream issue, which occurs at deployment of the envrionment with 'azd up', to be more precise at index building, when we had an additional custom pdf-document in the data folder. We overcame this issue by enabling the preview feature integrated vectorization function.
After activation the deployment runs smoothly, but now we are facing
Error: The app encountered an error processing your request.
If you are an administrator of the app, view the full error in the logs. See aka.ms/appservice-logs for more information.
Error type: <class 'azure.core.exceptions.HttpResponseError'>

if activating gpt-4 in the web UI and querying one of the default examples. The custom document is with 6.5M larger then the other example documents.

If you are using gpt-4-vision, you may be experiencing the issues I'm working on in this post: https://github.com/Azure-Samples/azure-search-openai-demo/pull/1355
We weren't doing chunking when vision was enabled, but I'm bringing back chunking.
You may be sending too much data to the model due to the text not being chunked. I can't tell from that error, you'll need to consult the logs for the full traceback:
https://github.com/Azure-Samples/azure-search-openai-demo/blob/main/docs/appservice.md

Integrated Vectorization

so its not possible to have
USE_FEATURE_INT_VECTORIZATION="true" && USE_GPT4V="true"
Then the option VISION - shall be greyed when "USE_FEATURE_INT_VECTORIZATION=true" in the expert settings  when its like this, shoulnd't?

Those features are not currently compatible, no. We have a note in the guide about that. I think we may also have a warning when you run prepdocs. It'd be a fairly large change to grey out in the settings, so not sure we'll go that far, but I think whether there's more we can do.

So basically you would need to
A) create a skillset that uses chunking on text which already exists. For vision another new stillest which only extract images to be indexed with vision model or
B) extracts images from document locally before uploading them to a dedicated. vision  storage where only images are sent an pure vision integrated vectorization is enabled


How to flash?

What have you flashed to the ESP32, is there a file and can you give guidance?
Kind Regards

Will do

Done

If you succussed please close the issue.

Thank you, sorry for the late reply


Rewrite towards future goal?

I have discussed some with Rob already and wanted to get others opinions on the matter of this library and being less tied to the framework and more pluggable. I also envision adopting a much more functional approach than the large number of classes that are currently being used for each aspect of the plugin. I hope to give approximately the same type and name of API calls but I believe some are subject to change as I don't think all the options are as necessary if we can just have a generic that we give an object. It is still up in the air and even if we go for the more dynamic functional approach we can always export the API over top of the more dynamic functional approach. Please offer up ideas and criticisms as you see fit and I will try to respond and converse as appropriate. Thanks. @EisenbergEffect @PWKad

@PWKad @gishmel
I think we will need to do some significant work here:

Split this library into two parts:

A "POJO" validation library that can work against any object and that has nothing to do with UI at all. (aurelia-validation)
An adapter that allows the templating engine to connect with the validation system for the purpose of displaying the errors, etc. (aurelia-templating-validation)

Remove all hacks or dependencies on internal or semi-private APIs. I'm not sure if many exist, but I had the impression there was some code in there that is a bit hackish.
Remove any Aurelia dependencies that aren't strictly necessary. This can be part of the splitting process. Ideally, the validation library itself would have no dependencies. A couple exceptions I can think of would be metadat and DI.

We need to try to do this ASAP in the event that we need to add new extensibility points to the templating library. Once we hit Beta 2, we are on lock down for new features, so we won't be able to do it until after v1 release if it doesn't get in by then.

Agreed I think that's what I was going to chime in with as well.  The first should be completely separated from the DOM so that it's more re-usable.
I think a few of the issues brought up by others are around the over-use of promises.

I very much like this idea and believe this is for the best. The library currently is difficult to reason about where it is doing certain functionality as it seemingly repetitive and needlessly large. I can create the aurelia-validation library and thats interesting I will look through the issues.

One must be dependency should also be aurelia-i18n, currently the library is reinventing the wheel around i18n, and it should simply use aurelia-i18n, at least that's what I think..

Yes, good point, any i18 functionality should come from our library for that purpose. It might be possible to create an "interface" so that different implementations can be plugged in.

I am confused what must be a dependency of aurelia-i18?

for translating the error messages

So you are stating that the adapter must utilize the aurelia-i18n library or plugin?

The validation library should/must support i18n for exposing error messages in the different languages, current version does that, but not in the best possible way and it doesn't use aurelia-i18n.

Is possible that the future plugin aurelia-templating-validation should depend on i18n for showing the messages in the correct lang.

Or its a pipeline such that aurelia-validation is the start of said pipe which feeds aurelia-i18n which then finally feeds into aurelia-templating-validation adapter. But sure it is possible to architect in many different ways so not sure which would be most desirable.

well, for the most desirable you should ask @EisenbergEffect or @PWKad :joy:

Is there a plan or anything?
I wanted to give aurelia-validation some refactoring love, but my time is limited and I certainly don't want to invest efforts into something that is going to be thrown away anyway.
aurelia-validation is currently doing lots of things in a so-so way, off the top of my head:

overuse of promises, poor async handling
the way threshold works for all validators is not good design
the way validation rules are defined is unintuitive and not as simple as it should be
there should be synchronous validation apis for the 90% of validations that actually are synchronous (open to discussion: should we even support async validations out of the box?)
the way messages are formatted and i18n is not great + it's something that should be shared across aurelia
the way paths are observed should be shared from aurelia. PathObserver belongs to aurelia-binding, not aurelia-validation
Does a Debouncer belong to this project? It seems to me there has to be another one somewhere in aurelia
The way the validation binding works has some (possibly hard) issues. Not sure how to fix this.
Should aurelia provide a ViewStrategy that is not bound to Bootstrap by default? I'm not using bootstrap and I'm using my own, but it seems to me that rather than Bootstrap a simple strategy that adds a class should be the built-in default.
and more...

Also, if we start thinking of creating an aurelia-free, functional, validation library, complemented by an aurelia adapter, than maybe we should re-use something existing. There are lots of validation functions already coded in the open-source world.

We don't want to throw things away. There's been a lot of work done. But, it does need some significant re-factoring and revisions. We want to gather some feedback and have some discussion here so we can see the extent that we need to go to and the nature of the changes. I've got some things that are critical from my perspective, but I know the community has some good feedback, so we want to hear that.

@EisenbergEffect sorry, I expressed myself poorly.
My point was: I know aurelia-validation is not going away; I want to be sure that if I contribute some work to make aurelia-validation better it will not be useless.

I think the library as far as the validation work is concerned is trivial to implement and the more important matter is how to connect this plugin with aurelia which is through the described aurelia-templating-validation. Also I don't follow when you state their are validation functions written in the open source world? Are you saying we should use an existent library? Cause from my vantage point we should just use javascript and its a matter of a few higher order functions working in concert to allow for extensible and robust behavior that is similar to the existent library but fewer options and more configurable. Thats just my opinion.

@gishmel I do not actually believe that we should use existing validation libraries but it was a comment referring to this from @EisenbergEffect:

Split this library into two parts:
A "POJO" validation library that can work against any object and that has nothing to do with UI at all. (aurelia-validation)
An adapter that allows the templating engine to connect with the validation system for the purpose of displaying the errors, etc. (aurelia-templating-validation)

If aurelia-validation is not actually tied to Aurelia directly, then I think we could reuse js code that already exists. We are not the first to tackle validation.
But then in my opinion even the splitted aurelia-validation is rather tied to Aurelia, for localization or to be able to react automatically to property changes.

No its not tied to the property changes that is the responsibility of the aurelia-templating-validation library to recall our plugin/library and we can give them the validation output back.

@gishmel makes sense, although the api needs to be well designed for it to work (consider <button enabled.bind="model.isValid">).
There is the i18n question left, then my initial point was: if the code is a generic, aurelia-independent, validation library, then maybe we should just use something that already exists.

Such as what library?

I am not sure, there are tons of JS validation libraries.
Of varying quality, with more or less dependencies, more or less tied to UI and a set of rules that can more or less easily be re-used.
There's a lot to look at: parsley.js, validator.js, verify.js, jQuery.validate, knockout.validation, chriso/validator and a ton more if you use Google I guess.

Yeah I did google and get those same libraries looked at a few. Still think we need nothing but a bit of ES6 and good discipline and we would have all their features and functionality with none of the overhead but thats once again my opinion. Which I have overly shared and look forward to seeing the overhaul plan at some point. Thanks for your time.

@gishmel Sorry I didn't chime in much earlier.
There is a lot of work to be done here to refactor the DOM manipulation out in to a pluggable fashion so that the aurelia-templating-validation can be created.  It sounds like you have some good ideas.  How can we turn those ideas in to some actionable items?
@EisenbergEffect listed a few starting points above, @jods4 listed some more detailed, and the issue I linked re-affirms that the main point should be to remove the templating portions ASAP.
I think a good starting point is to start a branch removing all DOM manipulation and use that as a basis for the refactor.  With those pieces removed perhaps the next step is to identify the current work flow that the validation library goes through to validate a property and then identify an improved workflow.  Then as we progress through the refactoring we can start to simplify and remove dead code.  My opinion on this is that I think there are some additional properties that exist currently we can probably reduce down.  Based on the feedback we've seen so far though the top priority should be getting the two pieces split-up so perhaps if we can decide on any changes in the workflow we can divvy the work up.
Thoughts?

@gishmel @jods4 @nomack84 @EisenbergEffect
I've moved this discussion in to a task list on a separate issue since I don't have the ability to edit the first post to keep it here.  I've took all of the discussion points that I saw and could move over in to that issue.  I'm going to close this for now but I would invite all of you to please take a look at that list and make sure I didn't miss anything and it all looks good.
If so I'm going to start moving issues over to the new repository and opening issues for each of the tasks.  If anyone feels strongly about taking on some of the tasks just let me know which ones once we get them created.


Updating advanced boot configuration for Raspberry Pi

Change-type: patch
Connects-to: #816
Connects-to: #675
Connects-to: #296
Signed-off-by: Gareth Davies<EMAIL_ADDRESS>

I'm not sure if this PR actually addresses #675 ?

I'm not sure if this PR actually addresses #675 ?

Many thanks for the review, and I'll address those changes shortly. As for the issue, you are right and I had already raised this in an internal chat for further investigation as I wanted this PR to resolve that issue one way or another, so I linked it here for reference. So when I get some feedback I'll update this PR (or remove that connect-to if no longer relevant).

I also think #675 is covered by the content here which can be linked to.

@shaunmulligan would you be able to have a review of this please, particularly the UART section? There are quite a few changes so have previewed it here: https://resin-docs-preview.herokuapp.com/docs/reference/OS/advanced/

@balena-ci rebase

Thanks, let's get this in as clearly an improvement on existing content and can follow up if anything needs additional clarification.


Avoid sharing the cloned directory for distributed test

Currently, when running a distributed test, each container shares the directory where the git clone was done.
In this case, conflicts will occur if the test artifacts are outputted directly to the shared directory.
So, we should avoid sharing directory between containers.

Codecov Report

Merging #36 (f746afb) into master (89788ca) will decrease coverage by 0.94%.
The diff coverage is 84.31%.

@@            Coverage Diff             @@
##           master      #36      +/-   ##
==========================================
- Coverage   70.19%   69.25%   -0.95%
==========================================
  Files           3        5       +2
  Lines         812      901      +89
==========================================
+ Hits          570      624      +54
- Misses        174      199      +25
- Partials       68       78      +10


Users need to be notified when they go over their quotas

|    by ibc599

Need to notify users by email when they have used their disk quotas.
A possible solution is to have a cron job which run each day to check if any users have reached their limits. If so, email them.

Issue migrated from trac:54 at 2024-01-31 17:28:17 +1100

ibc599 changed owner from `` to rnb548

ibc599 changed priority from major to minor

ibc599 changed status from new to assigned

<EMAIL_ADDRESS>commented

Bureau has agreed to supply software used to do this on Ngamai.
Robin

<EMAIL_ADDRESS>changed owner from rnb548 to rmb548

<EMAIL_ADDRESS>removed milestone (was Future)

<EMAIL_ADDRESS>commented

Milestone Future deleted

<EMAIL_ADDRESS>commented

Being over quota can cause hard to diagnose problems when the .Xauthority file can't be created.
Can we create a login warning message?

<EMAIL_ADDRESS>commented

You could have something like this easily enough, just need a way for it to run on login:
# Print user quota
quota -s

if [ $? != 0 ]; then
    # Mail quota exceeded message
    quota -s | mail -s "Warning: Over disk quota on $HOSTNAME" $USER
fi


add ability to specify aspect with RavelloClient.get_application()

Today I finally had a compelling reason to add the ability to specify ;design or ;properties or ;deployment when getting an application.
Before pushing a commit and a pull request, I thought I'd run the syntax by you guys so you can decide if it fits your style. After we nail it down, I can add it to get_vm().
def get_application(self, app, aspect=None):
    """Return the application with ID *app*, or None if it does not exist.

    The *aspect* parameter can be used to return the application only with
    the specified aspect (e.g., design, deployment, properties).
    """
    if isinstance(app, dict): app = app['id']
    if aspect is not None:
        app = '{0};{1}'.format(app, aspect)
    return self.request('GET', '/applications/{0}'.format(app))

Okay I rethought my stated position of waiting for you to respond. Figured it would just be easier for you to see a full pull request. #16


A required class was missing while executing org.owasp:dependency-check-maven:1.4.5:check: org/joda/time/ReadableInstant

Using dependency-check-maven:1.4.5, when i launch mvn dependency-check:check i got an exception :
A required class was missing while executing org.owasp:dependency-check-maven:1.4.5:check: org/joda/time/ReadableInstant
Reporting Bugs/Errors
https://gist.github.com/asicfr/6384a069ab589294a349403cc27e9db7
Thx

Is there any chance you have an old copy of dependency-check-ant in the classpath?  Possibly even in the ant directory itself?

My test pom.
pom.txt

@asicfs I just built the provided pom and did not receive the error: build-log.txt - this was with 3.3.9 and Java 8.  You can also see a travis-ci build showing a (successful build](https://travis-ci.org/jeremylong/DependencyCheck/builds/236869020#L3969) using Java 7.
What version of Maven and Java are you using? Can you think of anything else unique about your environment?

I use Apache Maven 3.3.9 and Java 1.8.0_131.

That is the same configuration used to create the above build-log.txt. Maybe clear your local m2 repo of anything joda-time related (~/.m2/repository/joda-time/joda-time)? I'm at a loss as I am unable to reproduce this issue.

Had the same issue. Deleting ~/.m2/repository/joda-time fixed this.

The only use of joda.time is in the OSS Index Analyzer. I have opened an issue (https://github.com/sonatype/ossindex-public/issues/8) to have them convert from joda.time to java.time.


Remove tailing whitespace from user-submitted tags

Adding a tag with a trailing space makes the tag impossible to delete (apologies for all the bad tags on penguin images).

Newbie bug

Fixed, deployed.


children calling $root's methods is not reactive

I wanted to build an i18n system that can update the entire app when you change the language.
So the idea was to have a root vm that holds the current language (actually a globalize object), a method to change the language and the translation method. The problem is, without inherit: true, child components don't get these methods in their scope. I didn't want to add inherit:true to every component, so I tried to write a mixin that defines these methods on every component I need, and then forwards them to the root vm.
Here's a simplified version of it: http://jsfiddle.net/nkovacs/gb0vg75a/
This works, except the children are not updated when you change the language.
I also looked at vue-i18n, which uses Vue.prototype to add a $t method to everything, but I think you'd run into the same issue if you tried to make it reactive like that.
I came up with a different solution that does work: http://jsfiddle.net/nkovacs/1zh3agxr/
Is that ok, or is there a better way to do it?

Wouldn't this be a perfect use case for $broadcast'ing an event at the $root that all View Models would listen and react to?

But how do you update the bindings?

Since a picture is worth a thousand words, here's what I would do:
http://jsfiddle.net/gb0vg75a/3/

Yeah, I though of using broadcast like that, but I didn't want to inject the globalize object into each vm.
I prefer my solution (http://jsfiddle.net/nkovacs/1zh3agxr/ or http://jsfiddle.net/nkovacs/1zh3agxr/2/ or http://jsfiddle.net/nkovacs/1zh3agxr/3/) because the private data (the translator object) is kept away from the vms.
The plugin/mixin essentially becomes a service that's injected into the vm (either automatically into all vms if it's a plugin or manually if it's a mixin), and it exports some functions (its public API essentially) while keeping the private data separated.

Note, the way you are using new Vue is not creating children View Models of the body tag Vue. See this fiddle where I added some logging to make that clear:
http://jsfiddle.net/1zh3agxr/4/
The best way to get parent child relationships like that working is to use the component system.

Oh, that's confusing. Thanks for pointing that out. But even if I fix that, it doesn't work: http://jsfiddle.net/nkovacs/gb0vg75a/5/
In the real app it's actually a dynamic component: http://jsfiddle.net/nkovacs/gb0vg75a/6/

Two problems. First, your data functions in the components should have been returning {} and were not. But the second and key problem is that in order to bind to translator you need to make sure that the Vue has it defined in its data. Otherwise, when Vue binds the t() calls, it will not see the reference to translator and therefore can't watch it – which causes them to not update when translator is created and updated later.
http://jsfiddle.net/gb0vg75a/8/

You're right, but I was using this.$add, and that works when it's on the same component, even though translator isn't defined on the root either, but it does not work on the children.

My understanding is that $set and $add deal with setting up data for components and directives that are compiled after they are executed – I don't think they effect anything already compiled in the DOM before that point.
Maybe @yyx990803 could shed some light on that subtlety?

This is another reason why you should prefer initializing the data properly. A working verison: http://jsfiddle.net/yyx990803/gb0vg75a/11/
Internally, calling $add on a vm causes all its watchers to be re-evaluated, because this is a new dependency that non of the existing watchers are aware of. This is essentially a forced dirty-check digest cycle like in Angular, and it only propagates to a child if a child has inherit: true (because normal components should derive parent data via props, which are also force-updated during the digest cycle).


Twitter started redirecting twitter.com to x.com

Twitter(X) started redirecting twitter.com to x.com. This makes this app not working, since this app works only in twitter.com, not in x.com.
Since IP of twitter.com(<IP_ADDRESS>) and x.com(<IP_ADDRESS>) seem to be different, I even tried to change hosts file, but it won't work. I think this need some action.

This has been fixed in the new version, please wait a while for it to be reflected.


KAFKA-8509; Add downgrade system test

This patch adds a basic downgrade system test. It verifies that producing and consuming continues to work before and after the downgrade.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Here's a link to a successful run: http://testing.confluent.io/confluent-kafka-branch-builder-system-test-results/?prefix=2019-11-21--001.1574306141--hachikuji--KAFKA-8509--7eee18a/

I'm changing this test case to use EndToEndTest instead of ProduceConsumeValidateTest. The advantage is that this allows me to assert committed offsets in the consumer, which makes the test case a stronger assertion about compatibility. I will push this change tomorrow.

Finally got a successful run: http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/2019-11-22--001.1574383225--hachikuji--KAFKA-8509--b6c4d3a/report.html.

Link to successful test run: http://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/2019-11-22--001.1574445019--hachikuji--KAFKA-8509--55ac75d/report.html


How to use more local parameters with a new CUDA device?

Description and motivation
@maljoras Thanks for answering all my questions.
As mentioned in previous issues, I am currently trying to develop a new device model for aihwkit.
The CPU version seems to be working now, and I am moving on to the CUDA version.
My device model requires 4 local (device-specific) variables to enable dtod variations.
In the CPU version, this is rather straightforward, I simply need to declare more matrices to store them:
 private:
  T **device_specific_Ndiscmax = nullptr;
  T **device_specific_Ndiscmin = nullptr;
  T **device_specific_ldet = nullptr;
  T **device_specific_A = nullptr;
However, In the CUDA version, this is not possible, as the device update function only supports 2 device-specific parameters, wrapped in par_2.
Proposed solution
I tried to trace this down the road, and found out that I need to override [this macro]
to cast params_2 differently.(https://github.com/IBM/aihwkit/blob/master/src/rpucuda/cuda/pwu_kernel.h#L236-L248)
#define RPU_FUNCTOR_LOAD_PARAMS                                                                    \
  {                                                                                \
    w = weights[idx];                                                                              \
    if (params != nullptr) {                                                                       \
      par_4 = reinterpret_cast(params)[idx];                                             \
    }                                                                                \
    if (params_2 != nullptr) {                                                                     \
      par_2 = reinterpret_cast(params_2)[idx];                                           \
    }                                                                                \
    if (use_par_1) {                                                                               \
      par_1 = params_1[idx];                                                                       \
    }                                                                                \
  }
Is this even possible without a significant change to the code structure?
If I do change par_2 to hold 4 float values, are there any other functions that I need to re-implement other than the operator() function inside each device?
Alternatives and other information
I could also try to swap out some part of par_4 to hold my parameters.
For this, I only need to overwrite the values defined in  PulsedRPUDeviceCudaBase::populateFrom(), which is easy to do in the HOST_COPY_BODY part of BUILD_PULSED_DEVICE_CONSTRUCTORS_CUDA.
The wmax and wmax inside par_4 was easy to understand.
But I wonder what is the function of scale_up and scale_down inside par_4.
Do they got transported from here and only control the step size for different directions?
If so I should be able to re-use the space for my stuff instead.
Thanks a lot for all the help in this!

The scale_down and scale_up parameters are the minimal update step sizes with device to device variations (see e.g. how it is used in case of the linear step device). If you do not use these in your update function you could indeed overwrite them. In this case, you need to provide an implementation of the Functor update_once. So you still use the w_max and w_min (keep it as is and use it in the update_once and just use the slots of the scale_up and scale_down) and par_2 for the other two. In this case you can re-use all the other update functionality (in particular you can use the Functor version, as done here). If you need more device-to-device parameters, all the function need to be adapted and it is more complicated.
Regarding the CPU version, make however sure that you can get/set the additional parameter with the get_device_parameters function. Otherwise checkpointing will not work properly.

Dear @maljoras
Upon implementing the CUDA version, I discovered a new function that is not defined in the CPU code:
The applyWeightUpdate function does not work with Persistent Weight.
As you suggested before in https://github.com/IBM/aihwkit/issues/379#issuecomment-1134839373_, I am using the w_persistent_ as my hidden weight that determines the real weight.
So, how does the applyWeightUpdate function works, and do I need to modify that according to my need?
Thanks a lot!
Zhenming

Dear @maljoras
Upon implementing the CUDA version, I discovered a new function that is not defined in the CPU code: The applyWeightUpdate function does not work with Persistent Weight.
As you suggested before in #379 (comment)_, I am using the w_persistent_ as my hidden weight that determines the real weight.
So, how does the applyWeightUpdate function works, and do I need to modify that according to my need?
Thanks a lot!
Zhenming

I see that applyWeightUpdate add dw_and_current_weight_out to weights, and then check whether weights is within bounds.
But what function does this serves? Isn't the update calculated by converting dw into pulse counts with learning rate and dw_min? And then apply the update cycle several times?
Why is there a shortcut that does not consider the device dynamics?
Is this for the FloatingPointDevice? But why is it in rpucuda_pulsed_device files?
Thanks for your time.
Zhenming

Hi @ZhenmingYu:
The applyWeightUpdate function is essentially not used currently (and not exposed to pytorch) and is only an experimental mechanism we experimented with from C++ to simulate (approximative) data-parallel training for the base device. However, since this cannot be naturally supported for most analog training devices, you can just ignore that function (or if you are worried that someone might call it, just override the function in your device and call RPU_NOT_IMPLEMENTED to always cause a runtime error when accidentally used). In fact, I should probably remove that function.


Introduce single-file bundles and optional polyfills

It is desirable to have bundles for every situation.
Right now, this lib lacks:

[ ] Single-file UMD (ES5)
[ ] Single-file IIFE (ES5, polyfills)
[ ] Node CommonJS (ES6+)

Not really needing this for now...

Time to revisit this


Previously, when you run "npm run dev" it showed something like:

  Previously, when you run "npm run dev" it showed something like:

Local: http://localhost:3000/
Network: http://192...__:3000/

Now, there is no Network address but:

Network: use --host to expose

How do you get it to work? And why remove such a feature?
Originally posted by @ibcoder001 in https://github.com/vitejs/vite/discussions/3396

It is a security risk to expose your files to your Network by default. As the hint you got in the log says, use the --host flag to expose the dev server to the network. In npm, you need to add an extra --, so it is:
npm run dev -- --host

Is it obvious to use npm run dev -- --host instead of npm run dev --host? I haven't used npm/node/javascript much yet, so this could be from inexperience.
But...
Shouldn't the message say to use the -- before the options?

Is there a way to make it less painful or am I a noob?

It is a quirk of npm at this point, both yarn and pnpm works without it. I suggest you switch to pnpm, the experience is better. This may also help: https://github.com/antfu/ni
About the message, I don't think we should add more info to the CLI output because for a lot of users won't be useful. I hope npm will change this at some point.

Seems like nothing much can be done.
ni looks fun, will try that.


The @container query doesn't work.

Hello friend, me again with another bug.
I've found that resin doesn't handle the @container at-rule. e.g:
const styles=css`
  color: red;
  @container (width > 300px) {
    color: blue;
  }
`

Thank you!

Thank you for reporting.
Actually I've not been using @container rule until now.
I'd like to investigate and fix it.

I've added the support for @container.
Please update your import to v0.1.8


Add remove done items

Added a button to clean up the to-dos that have been completed in the to-do list, enable it through the configuration, and remove the completed items after clicking.

@liaochuan, can you please fix the static checks that are failing.
On your local you can run pnpm run lint

@liaochuan, can you please fix the static checks that are failing. On your local you can run pnpm run lint

It's been dealt with


Avoid using a global static map.

It is better to use a "getter" function I believe according to the C++
coding guide.
The existence of the global static caused a weird startup issue in DXC (which includes SPIRV-Tools as
an external project).

looks like this change fails the spirv-tools-symbol-exports-SPIRV-Tools test only on Linux

Sorry for the disruption, I believe https://github.com/KhronosGroup/SPIRV-Tools/pull/2691 should solve the issues.

#2691 fixed the issue. Closing.

Thanks @kpet for your fast response and the fix :)


Android - Profile - Selected pronoun is not visible in the "Preferred Pronouns" field

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Launch the app
Log in with account you don't have last and first name setsup up.
Go to Settings - Profile
On Preferred Pronouns dropdown field select any.

Expected Result:
I expected to see the selected option in my profile.
Actual Result:
Selected the option in the "Preferred Pronouns" isn't visible in the field.
Workaround:
Unknown
Platform:
Where is this issue occurring?

Android

Version Number: 1.0.85-0
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/129267980-33d3fba4-83bf-46f7-8817-27743885b073.mp4

Expensify/Expensify Issue URL:
View all open jobs on Upwork

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

Triggered auto assignment to @ctkochan22 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Hi, I just investigated and found this
Apperantly, this is a react-native-picker-selects bug. And passing color style for Picker solves the issue.
I can open a PR

Triggered auto assignment to @jliexpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

Great find @kakajann! Feel free to submit a PR, and we'll get an Upwork job created for you ASAP.

Posted to Upworks - https://www.upwork.com/ab/applicants/1425989377062014976/job-details
@kakajann - feel free to apply there, and I'll hire you.

@jliexpensify Applied and opened a pr

@kakajann @roryabraham would you say this issue was caused by @kakajann 's PR https://github.com/Expensify/App/pull/3414? It looks related since that PR created the expensiPicker style, which is all that was changed in the PR that fixed this issue

Reopening for pending payment

@kakajann @roryabraham would you say this issue was caused by @kakajann 's PR #3414? It looks related since that PR created the expensiPicker style, which is all that was changed in the PR that fixed this issue

@Beamanator that's a good point

@kavimuru This should be fixed in v1.0.85-5+

https://github.com/Expensify/App/issues/4554#issuecomment-898792075 retest was a pass, closing.

@roryabraham and @Beamanator - apologies, I'm just a little confused: should I be paying @kakajann for this job? The previous comments indicate not, correct?

Okay, so reviewing what happened here:

@kakajann submitted PR: https://github.com/Expensify/App/pull/3414, which caused a regression.
@kakajann quickly volunteered to fix the regression.
I failed to notice that the regression was caused by https://github.com/Expensify/App/pull/3414, and agreed to create a new Upwork job and hire @kakajann to fix the regression. This was a mistake on my part.

However, since https://github.com/Expensify/App/pull/3414 caused the regression, it was already @kakajann's responsibility to fix the regression, so a second job should have never been created. Therefore, I don't think we should be out the second job.
This is a situation I have personally never been in with a contributor before, so as far as I know we don't have a precedent se here, but it seems fair to me. @kakajann please let us know if you disagree.

I don't mind to end the contract from upwork. I wasn't aware this issue is my regression.

Thanks for your understanding and for accepting this outcome @kakajann . Contract has been cancelled in Upwork.
Hope to work with you again soon!


Fix walk of status object when killing services

retest this please

Looks good.

The vpc 'vpc-359b035c' has dependencies and cannot be deleted.

That could be a service that wasn't removed and could be related to this PR. Please take a look.

retest this please

retest this please

add to whitelist


Finish GraphQL support to REDIS backend

The current GraphQL schema is fully supported by the simple backend. The redis backend isn't as complete. It would be nice to get it to support the entire schema before new queries are added to the API.

When I was working on the GraphQL support, I only used the simple backend. That effort resulted in some API changes that were never compiled for the REDIS backend. So I'm expanding this issue to:

Get the REDIS backend to compile at all (adjusting it to the minor API changes that have occurred.)
Support the full GraphQL API
Add unit tests
Add a matrix to the GitHub CI workflow so we build against both, simple and redis, backends.


Module settings and controls missing on Apache

Hi,
I've just noticed that the apache module config and server controls are missing at the top of the page .. Seems to be the case on a few other pages as well.

Yes, I already fixed it. Noticed it this evening.
Update the theme and force reload the cache.

Thanks a lot for reporting.


Fix label alias overrides

When the base image has the new name for a label and the Dockerfile has the old name, we must add the new name in as well in order to override the inherited value.
If we don't do this, built images will have names corresponding to their parents.

Test coverage goes down because the 'should probably have the same value' path is now only taken when the Dockerfile explicitly sets both old and new labels for an alias to different values, which isn't tested.

Good catch! Merging ...


Vue typescript support

This is a follow up for issue #64.  I'm opening a new one because typescript support is only support for @heroicons/react and not @heroicons/vue.  I feel it would be nice to add the type definition for @heroicons/vue

Hello @PhelixOchieng I see you closed this as completed.
Unfortunately it seems like i still doesn't have typescript support for @heroicons/vue in my project.
Do you have a solution?

Hope this one is noticed ASAP

I may have missed it in the docs, but how do we do it in practice?


fix(gh-backport.sh): add worktrees path

I ran into the following error when running the gh-backport.sh script:
fatal: not a git repository: /Users/vdice/go/src/github.com/fermyon/spin/.git/worktrees/backport-worktree

Adding worktrees to the work_tree path fixed it for me.  I have git version 2.39.3 (Apple Git-146)

I don't think this is right. Did you maybe manually remove your .git/backport-worktree at some point?

Actually that doesn't seem to trigger this error either :thinking:

Ok, hmmm, chalk it up to user error.  I'll look deeper on the next backport...


Not allowed characters in backup set name

I've had the same problem and solved it on my own. The problem for me was that I used : in the folder name for the backup.

Originally posted by @harun27 in https://github.com/JackGruber/joplin-plugin-backup/issues/13#issuecomment-936068612

Remove not allowed folder/filename characters in backup set name.

Closed, since no activity


Small negative power fixes

closes #439

Job VTB Documentation, step Sync Docs on 1873702 wanted to post the following:
View the site here
This comment will be updated on new commits.

Fix for that failure is in Shikhar s PR


[AKS] Error creating Azure cloud credential from UI: '"Tenant" is required'

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):
Try to create an Azure cloud credential using client ID, client secret, and subscription  ID.
Result:

Other details that may be helpful:
The UI should eventually support entering a tenantID, but even then it should be optional to maintain backwards compatibility.
The validation error happens because the dynamic schema marks the field "required". It should be marked as optional.

This was introduced in https://github.com/rancher/rancher/pull/32288 / https://github.com/rancher/machine/pull/133
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master 6395fbccd74315673de289d522992e28004fbb3c

Installation option (single install/HA):

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Machine type (cloud/VM/metal) and specifications (CPU/memory):
Kubernetes version (use kubectl version):

(paste the output here)

Docker version (use docker version):

(paste the output here)

user can create a CC without tenant ID, but won't be able to create an AKS v2 cluster using it. As such CC do not get listed in CC list while provisioning AKSv2 cluster.


README update with relationship to current Rust?

Thank you for creating coroutine-rs
I'm just learning, but it seems Rust has some form of either:
coroutines, semiroutines or generators, as was implemented to build async/await into Rust.
Generators Pull Request
Claim futures/await is build upon generators/coroutines
It would be really lovely if the README had some explanatory text discussing the currently use cases for this package.
Where it shines, where it might make sense to use Rust core features.
It's really very hard to figure out the should I use features from this Crate, or build in Rust features as a newcomer to the Rust world.

This crate was created before Rust's builtin async/await feature was announced. It would be a lot nicer to use the builtin async/await.


Add has_symlink public API function

Implement Tar.has_symlink as requested by @staticfloat
julia> using Tar, CodecZlib, Downloads

julia> Downloads.download("https://github.com/JuliaBinaryWrappers/P4est_jll.jl/releases/download/P4est-v2.8.1+2/P4est.v2.8.1.x86_64-w64-mingw32-mpi+microsoftmpi.tar.gz", "P4est.v2.8.1.x86_64-w64-mingw32-mpi+microsoftmpi.tar.gz")

julia> open(GzipDecompressorStream, "P4est.v2.8.1.x86_64-w64-mingw32-mpi+microsoftmpi.tar.gz") do io
           Tar.has_symlink(io)
       end
true

julia> Downloads.download("https://github.com/JuliaBinaryWrappers/iso_codes_jll.jl/releases/download/iso_codes-v4.15.0%2B0/iso_codes.v4.15.0.any.tar.gz", "iso_codes.v4.15.0.any.tar.gz")

julia> open(GzipDecompressorStream, "iso_codes.v4.15.0.any.tar.gz") do io
           Tar.has_symlink(io)
       end
true

julia> Tar.create("empty", "foo.tar")
"foo.tar"

julia> Tar.has_symlink("foo.tar")
false

xref: https://github.com/JuliaLang/Pkg.jl/issues/3643#issuecomment-1880111897

@nhz2 's implementation looks good as well:
https://gist.github.com/nhz2/2db880497293868178225a964c68fd99#file-find-symlinks-jl-L12-L19

This feels like it could be implemented externally since it's quite a simple application of Tar.list. In the calling code it would simply be this:
has_symlink = false
Tar.list(tarball) do hdr
    has_symlink |= hdr.type == :symlink
end

If anything, I'd be inclined to add a generic predicate checker like this:
Tar.check_any(predicate::Function, tarball::ArgRead)

That checks if any entry in the tarball satsifies a predicate; it could be specialized with a type::Symbol that would check if any of the entries in the tarball are of that type.

How would one write a function without getting into the non-public details of the header structure?
If islink worked, Tar.list(islink, mytar.tar) I would consider it
Also I don't get the need to |, or, the results together. What we actually need is short circuting. Once we found the first symlink, we're done.

The Header struct is public and documented and part of several APIs.

We could add short-circuiting as an optimization if we have a Tar.contains function, but I'd consider that an implementation detail.

How about we define Base.islink(h::Header) = h.type == :symlink?

Here is the API I am imagining.
julia> open(GzipDecompressorStream, "P4est.v2.8.1.x86_64-w64-mingw32-mpi+microsoftmpi.tar.gz") do io
           findfirst(islink, Tar.list(io)) != nothing
       end
true

julia> Tar.create(mkdir("empty"), "foo.tar")
"foo.tar"

julia> findfirst(islink, Tar.list("foo.tar")) != nothing
false

For the short-circuiting what I really want a lazy iterator over the headers rather than the eager Vector{Header} from Tar.list.

I've made a PR for the predicates on Header types: https://github.com/JuliaIO/Tar.jl/pull/169/files. Making an iterable object that does what iterate_headers does seems quite annoying. The alternative would be to use the callback interface and raise an exception to terminate early; ugly but would avoid needing an iterator.

Please also note that none of this is going to help the Pkg situation since I don't think we want to add faetures to Tar in a point release and a point release is what is where this issue is going to be fixed.


Obsoletion request: GO:0035553  oxidative single-stranded RNA demethylation and GO:0035552 'oxidative single-stranded DNA demethylation

The proposal has been made to obsolete    GO:0035553  oxidative single-stranded RNA demethylation
& replace by parent oxidative RNA demethylation

After review of the annotations, these 2 terms will be obsoleted because thy are redundant with the MFs
GO:0035515 oxidative RNA demethylase activity
GO:0035516 broad specificity oxidative DNA demethylase activity

Hi UCL has 4 annotations - I have revised 2 RNA ones, but there is no DNA parent oxidative DNA demethylation. Is this just going to DNA demethylation?

You're faster than I am  (not difficult) !! Suggestions will be coming soon... Colin and I are working on this.
Thanks, Pascale

Noting that as of today, GO:0035515 oxidative RNA demethylase activity &
GO:0035516 broad specificity oxidative DNA demethylase activity are still valid (not-obsoleted) terms


Suggestion: Split dictionary and core

I try SymSpell and it looks great. But one thinks I notice almost intermediately it bring dictionary file in my project (even if I do not use it). I understand it helps with a quick start but I strongly believe in real application most of the users make own. But even if not. I think it will be better to have NuGet package split to SymSpell.Core and SymSpell.Dic.En for example. For keeping compatibility SymSpell could be composed of these two packages (something like Microsoft.AspNetCore.App.

I have created an abstraction layer for several libraries doing word splitting for Python. All of the libs receive kind of word list. Some ship the wordlist with them, some (like this ones) don't. I think that having an own word list for each library is redundancy and a violation of DRY principle (it may be convenient for the devs not to depend on compatibility though, but it is still harmful).
I think we need a common spec for the dictionary files, because quite some software use them. So these wordlists could be installed and updated separately. So I won't have to bother "this lib requires a wordlist", "this lib bundles an own one".
I also wonder if there are any benchmark datasets for such a task. I mean not only speed benchmark, but one of quality of splitting. And maybe even classifying the errors the implementations cannot avoid.


Show native language titles as well?

Currently only the english titles are show. Can the native language titles (eg: chinese) be shown next to the english titles? Or have an option to toggle this (english/native/both)?

I will think about it. The issue is that:

Not every drama has a native title on dramacool website
The title does not conform to a specific structure, the title can sometimes contain only chinese or a combination of chinese and english, which makes it a bit of a pain to work with.
There is no way to identify if the title is in chinese, japanese, english etc. on their website.

I checked out the site and there is actually very little native language titles there. Oh well.


[newrelic-logging] kubelet upstream connection error

Bug description
#1207 broke the ability to communicate to the kubelet Use_Kubelet
Version of Helm and Kubernetes
❯ kubectl version
Client Version: v1.28.10
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.10-gke.1058000

❯ helm version
version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.17.5"}

Which chart?
nri-bundle 5.0.81
newrelic-logging 1.22.0
What happened?
I upgraded from nri-bundle 5.0.25 to nri-bundle 5.0.81 to mitigate the CVE that we were notified of.
We stopped recieving kubernetes metadata on our logs and started seeing a bunch of [error] [filter:kubernetes:kubernetes.0] kubelet upstream connection error messages from the newrelic logging pods.
What you expected to happen?
I expected fluentbit to continue to communicate with kubelet.
How to reproduce it?
Add Use_Kubelet         On to the fluentbit kubernetes filter.
Observe that the pods will no longer connect to the kubelet
Anything else we need to know?
I did notice that hostNetwork: true was removed in #1207. This means that fluentbit was no longer able to communicate with the kubelet.
I did find a promising solution here that could possibly be applied to this chart: https://github.com/aws-samples/amazon-cloudwatch-container-insights/issues/147
[FILTER]
    Name          kubernetes
    Match         kube.*
    Use_Kubelet   true
    Kubelet_Host  ${KUBELET_HOST}

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: fluent-bit
spec:
 template:
   spec:
     hostNetwork: false
     containers:
     - name: fluent-bit
        image: fluent/fluent-bit
        env:
        - name: KUBELET_HOST
           valueFrom:
             fieldRef:
               fieldPath: status.hostIP

Additionally, from what I understand, connecting to the kublet helps alleviate load on the main api as it does some caching and it can be a local call. Would it be a good idea to make this the default?

@Voziv we have reintroduced the ability to configure hostNetwork parameter through this PR: https://github.com/newrelic/helm-charts/pull/1462
Can you confirm if we are good to close this bug?

I'll try this out this week and report back

@Voziv i have validated the kubelet upstream connection error by enabling Use_Kubelet true to reproduce the issue and then noticed that adding hostNetwork: true caused those errors to disappear.
We consider this issue as addressed and resolving it now. Let us know if you need to reopen the issue


Language-management

When connected, do not display the "language picker"
When connected on arrival, go to the right language directly.
When connected on arrival on a wrong language, ask if redirect or modify profile language.

(cfr chat DLe-Mathias on 5/01/2020)

Has been already done (covered by other issues)


Add Bayo (v2.bayo.vn) website

The site is down

I seem that it is live.

Yeah, It's up now. I think we have a small issue with DNS.

Thanks :)
Can you resolve the conflict please?
We can not merge your PR.  😉

OK It's done now.

Thanks!!


2023 Roadmap

This issue describes zerocopy's near-term roadmap. Eventually, I'll split it into separate issues, task lists, or milestones, but I'll make sure that this issue can always be used to find all of those other things.
The themes for this roadmap are completeness, polish, and confidence. Historically, zerocopy has agglomerated features as required by individual users, but I've never had time to polish everything, fill out missing features, and generally turn zerocopy into a cohesive and easy-to-use whole. This roadmap aims to improve on all of those gaps.
Complete API
Currently, there are some operations that we know users want to perform that can't be supported by zerocopy, or can't be supported ergonomically. Some examples include:

Safely elide length or alignment checks when converting from byte sequences of known length or alignment
Convert &[[u8; size_of::<T>()]] to &[T]
Represent byte sequences which are guaranteed to be all zeroes and provide conversions to types which aren't necessarily FromBytes but which can be constructed from all zeroes
Support fallible conversions
Provide as many conversions as possible in a const context

Building block-based API & unsafe composition
Currently, we have a lot of support for combinations of operations. For example, if you want to convert a &mut [u8] to a &mut [T], and you want to check at runtime that your byte slice has the right size and alignment, you would do LayoutVerified::new_slice(bytes)?.into_mut_slice(). If you wanted to do the same, but first zero the bytes of the &mut [u8], you'd use the new_slice_zeroed constructor. Even though most of the logic is the same, there's an entirely different constructor.
We want to move towards a world in which there are small "building blocks" which can be combined to perform larger operations. So far, we intend to build:

A ByteArray<T> type, which is a stand-in for [u8; size_of::<T>()] until that latter type is usable in a generic context
An Align<T, A> type, which is a T whose alignment has been rounded up to that of A
A FromBytes::zero_and_get_bytes method which allows viewing the bytes of a T: FromBytes + !AsBytes by first zeroing the bytes in order to overwrite any padding
Various conversions which use the ByteArray, Unalign, and Align types to elide length and alignment checks. A few examples:

FromBytes methods

fn unaligned_ref_from_bytes(bytes: &ByteArray<Self>) -> &Unalign<Self> where Self: Sized
fn mut_from_bytes(bytes: &mut ByteArray<Self>) -> Option<&mut Self> where Self: AsBytes + Sized

AsBytes methods

fn as_byte_array(&self) -> &ByteArray<Self> where Self: Sized

Another added benefit of these building blocks is that it will make it easier to reason about the soundness of our implementations. Currently, some operations require complex safety arguments. If we were instead able to express these as the composition of smaller (still unsafe) operations on building blocks, we could make it easier to reason about the safety of the resulting computation.
For example, currently, the implementation of LayoutVerified::into_ref looks like this:
impl<'a, B, T> LayoutVerified<B, T>
where
    B: 'a + ByteSlice,
    T: FromBytes,
{
    /// Converts this `LayoutVerified` into a reference.
    ///
    /// `into_ref` consumes the `LayoutVerified`, and returns a reference to
    /// `T`.
    pub fn into_ref(self) -> &'a T {
        // SAFETY: This is sound because `B` is guaranteed to live for the
        // lifetime `'a`, meaning that a) the returned reference cannot outlive
        // the `B` from which `self` was constructed and, b) no mutable methods
        // on that `B` can be called during the lifetime of the returned
        // reference. See the documentation on `deref_helper` for what
        // invariants we are required to uphold.
        self.deref_helper()
    }
}

impl<B, T> LayoutVerified<B, T>
where
    B: ByteSlice,
    T: FromBytes,
{
    /// Creates an immutable reference to `T` with a specific lifetime.
    ///
    /// # Safety
    ///
    /// The type bounds on this method guarantee that it is safe to create an
    /// immutable reference to `T` from `self`. However, since the lifetime `'a`
    /// is not required to be shorter than the lifetime of the reference to
    /// `self`, the caller must guarantee that the lifetime `'a` is valid for
    /// this reference. In particular, the referent must exist for all of `'a`,
    /// and no mutable references to the same memory may be constructed during
    /// `'a`.
    unsafe fn deref_helper<'a>(&self) -> &'a T {
        &*self.0.as_ptr().cast::<T>()
    }
}

I'm pretty sure that this is sound, but I've always been a bit nervous about how complex the argument is. By contrast, we can simplify this using the building blocks we intend to introduce. In 2c67380f077a6b1b8682290849a9217bb502861f (this commit hasn't been merged, and may be deleted at some point), we change the above code to:

impl<'a, B, T> LayoutVerified<B, T>
where
    B: ByteSlice + Into<&'a [u8]>,
    T: FromBytes,
{
    /// Converts this `LayoutVerified` into a reference.
    ///
    /// `into_ref` consumes the `LayoutVerified`, and returns a reference to
    /// `T`.
    pub fn into_ref(self) -> &'a T {
        let bytes = self.0.into();
        // SAFETY: `LayoutVerified` upholds the invariant that `.0`'s length is
        // equal to `size_of::<T>()`. `size_of::<ByteArray<T>>() ==
        // size_of::<T>()`, so this call is sound.
        let byte_array = unsafe { ByteArray::from_slice_unchecked(bytes) };
        // SAFETY: `LayoutVerified` upholds the invariant that `.0` satisfies
        // `T`'s alignment requirement.
        unsafe { T::ref_from_bytes_unchecked(byte_array) }
    }
}

I find this implementation much easier to reason about. The safety invariants on ByteArray::from_slice_unchecked and FromBytes::ref_from_bytes_unchecked are straightforward, and it is much more obvious from reading those functions that the lifetimes are propagated correctly. (Note that this commit also adds a requirement to ByteSlice about what an Into<&'a [u8]> impl is required to return.)
Rename LayoutVerified to Ref (#68)
What is says on the tin. LayoutVerified is descriptive if you understand type theory and the concept of a "witness" (although we probably should have put "witness" in the name...), but it's a meaningless term for most users. We should rename it to Ref or similar - after all, it's just a reference with a few niceties.
Simplify ByteSlice's definition and make it un-sealed
Currently, ByteSlice has both a Deref<Target=[u8]> bound and an as_ptr(&self) -> *const u8 method. The latter is probably redundant given the former, and adds another method that we have to document safety invariants for. ByteSlice's safety invariants are somewhat subtle, so getting rid of as_ptr would be very nice.
It would also make it easier for others to implement ByteSlice for their own types. We've had users request this, but it's currently impossible because ByteSlice is sealed. In addition to blocking this use case, it also allows us to play a bit fast and loose with its precise safety invariants.  However, I think that its safety invariants are probably fairly reasonable to write down more precisely, in which case we ought to be able to un-seal it and unblock users who want to implement it for their own types.
Split ByteSlice so that split_at is in a different trait (#1)
Currently, ByteSlice has a split_at(self, mid: usize) -> (Self, Self) method analogous to the slice method of the same name. Our performance design requires this method to be very cheap, which precludes implementing ByteSlice for types like Vec, for which split_at would require allocation.
Instead, #1 tracks splitting ByteSlice into two traits so a type such as Vec can implement the base ByteSlice trait without needing to implement split_at. Most of the zerocopy API can operate on this simpler trait, while a few functions and methods would still require the ability to call split_at.
Improve documentation (https://github.com/google/zerocopy/issues/32)
Our documentation is currently spotty and often unhelpful to newcomers.

Hello, is there a plan to release a 1.0 version once this roadmap is complete?

There are no concrete plans to release a 1.0 version. Currently we're working on version 0.7 (our latest alpha release is 0.7.0-alpha.3), and I expect that a lot of the work on this roadmap will go into that release (although not necessarily all of it).

Does the 0.7 version of zerocopy support implementing AsBytes and FromBytes manually without using a custom derive? Requiring a custom derive makes optional integration more difficult, especially for libraries like bitflags where code is generated in end-user's crates.

Does the 0.7 version of zerocopy support implementing AsBytes and FromBytes manually without using a custom derive? Requiring a custom derive makes optional integration more difficult, especially for libraries like bitflags where code is generated in end-user's crates.

Yes, and so does 0.6.x. The only speedbump is the #[doc(hidden)] method, only_derive_is_allowed_to_implement_this_trait, which you can of course implement yourself. It's just meant to steer folks towards the custom derives.

Hey @qwandor and @KodrAus, just wanted to let you know that we just released 0.6.2, which includes all of the non-breaking changes from 0.7.0.

These users are extremely wary of taking external dependencies, and only take dependencies when they absolutely need to or when they have a high degree of trust in an external software artifact.

This describes me well. I considered multiple times using zerocopy and extending zerocopy.  But then the formation of the "safe transmute" working group in the rust-lang organization made it seem like it would be just better to wait until the most important functionality is in libstd and guaranteed by the language/lib spec more explicitly.
@joshlf made a PR for ring that shows how zerocopy benefits ring by reducing its unsafe code that's duplicative of zerocopy. And zerocopy has a higher bar for documenting and validating its correctness than my more informal approach in my own code. OTOH zerocopy is so large that I pretty much just have to take it on faith that y'all care so much about getting all the details right that I don't need to bother looking through it, because I can't (don't have time).
Ultimately, I think people just would rather have as much of the functinoality w.r.t. transmuting and casting in the standard library as possible. I think if this is seen as a prototype that helps that happen, more people will be eager to adopt it.

These users are extremely wary of taking external dependencies, and only take dependencies when they absolutely need to or when they have a high degree of trust in an external software artifact.

This describes me well. I considered multiple times using zerocopy and extending zerocopy.  But then the formation of the "safe transmute" working group in the rust-lang organization made it seem like it would be just better to wait until the most important functionality is in libstd and guaranteed by the language/lib spec more explicitly.
@joshlf made a PR for ring that shows how zerocopy benefits ring by reducing its unsafe code that's duplicative of zerocopy. And zerocopy has a higher bar for documenting and validating its correctness than my more informal approach in my own code. OTOH zerocopy is so large that I pretty much just have to take it on faith that y'all care so much about getting all the details right that I don't need to bother looking through it, because I can't (don't have time).
Ultimately, I think people just would rather have as much of the functinoality w.r.t. transmuting and casting in the standard library as possible. I think if this is seen as a prototype that helps that happen, more people will be eager to adopt it.

Just wanted to give you a heads up that we've added documentation that address a lot of this; if you get a chance to take a look, let me know if you have any feedback. ring is exactly the kind of consumer we're hoping to target with our policies - we hope to get to a point where crates like ring feel comfortable taking a dependency on zerocopy - so your feedback here has been really helpful, and it helped shape what we wrote in these PRs.
See #405, #485, and #484. These are available on main in README.md and POLICIES.md.

We're not using this issue as a tracking issue anymore.


chore: Documentation update

Update readme.md, add code of conduct, and contributing guidelines
This commit includes updates to the readme.md file to provide comprehensive information about the devFinder project. Additionally, it introduces the CODE_OF_CONDUCT.md and CONTRIBUTING.md files to establish guidelines for community conduct and contribution standards.

Updated readme.md with project information
Added CODE_OF_CONDUCT.md to set community standards
Created CONTRIBUTING.md to guide contributors

Addresses #12


openbabel3: Fix multiple output

Motivation for this change
Fix typo.
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 116396 at 999ba6b4 run on x86_64-linux 1

1 package marked as broken and skipped:

libsForQt512.kalzium

3 packages built successfully:

libsForQt5.kalzium (libsForQt515.kalzium ,plasma5Packages.kalzium)
libsForQt514.kalzium
openbabel (openbabel3)


does not support option: 'parallel'"

Hi, thanks for the exciting work! I am playing with your algorithm and I got the following error message, when I was running your demo with digits.data. Do you have a sense of what is going on here?

KeyError                                  Traceback (most recent call last)
/Users/Qihong/anaconda/envs/brainiak/lib/python3.6/site-packages/numba/targets/options.py in from_dict(self, dic)
17             try:
---> 18                 ctor = self.OPTIONS[k]
19             except KeyError:
KeyError: 'parallel'
During handling of the above exception, another exception occurred:
KeyError                                  Traceback (most recent call last)
 in ()
6 embedding = umap.UMAP(n_neighbors=5,
7                       min_dist=0.3,
----> 8                       metric='correlation').fit_transform(digits.data)
/Users/Qihong/Dropbox/github/umap/umap/umap_.py in fit_transform(self, X, y)
790             Embedding of the training data in low-dimensional space.
791         """
--> 792         self.fit(X)
793         return self.embedding_
/Users/Qihong/Dropbox/github/umap/umap/umap_.py in fit(self, X, y)
757
758         graph = fuzzy_simplicial_set(X, self.n_neighbors,
--> 759                                      self._metric, self.metric_kwds)
760
761         if self.n_edge_samples is None:
/Users/Qihong/anaconda/envs/brainiak/lib/python3.6/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
305                 argtypes.append(self.typeof_pyval(a))
306         try:
--> 307             return self.compile(tuple(argtypes))
308         except errors.TypingError as e:
309             # Intercept typing error that may be due to an argument
/Users/Qihong/anaconda/envs/brainiak/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, sig)
577
578                 self._cache_misses[sig] += 1
--> 579                 cres = self._compiler.compile(args, return_type)
580                 self.add_overload(cres)
581                 self._cache.save_overload(sig, cres)
/Users/Qihong/anaconda/envs/brainiak/lib/python3.6/site-packages/numba/dispatcher.py in compile(self, args, return_type)
70     def compile(self, args, return_type):
71         flags = compiler.Flags()
---> 72         self.targetdescr.options.parse_as_flags(flags, self.targetoptions)
73         flags = self._customize_flags(flags)
74
/Users/Qihong/anaconda/envs/brainiak/lib/python3.6/site-packages/numba/targets/options.py in parse_as_flags(cls, flags, options)
26     def parse_as_flags(cls, flags, options):
27         opt = cls()
---> 28         opt.from_dict(options)
29         opt.set_flags(flags)
30         return flags
/Users/Qihong/anaconda/envs/brainiak/lib/python3.6/site-packages/numba/targets/options.py in from_dict(self, dic)
19             except KeyError:
20                 fmt = "%r does not support option: '%s'"
---> 21                 raise KeyError(fmt % (self.class, k))
22             else:
23                 self.values[k] = ctor(v)
KeyError: "<class 'numba.targets.cpu.CPUTargetOptions'> does not support option: 'parallel'"

The current code targets a fairly new version of numba. You need numba version 0.34 or greater to have it work. In practice I am not sure the parallel pragma adds much performance, so an alternative is to simply remove it from the source in umap/umap_.py wherever it occurs.

Ah I see! Thanks a lot!

Looks resolved. Please create a new issue if problems persist.


versioned releases

The page is published to https://[user name].github.io/[repo name]/
There is no option to publish a versioned release
In this workflow, the versioned release is made possible by peaceiris/actions-gh-pages@v3 and inputs:
publish_dir: ./public
destination_dir: 1.0.0

Which would produces our coveted versioned site
https://[user name].github.io/[repo name]/1.0.0/

What is the tradeoffs between actions/deploy-pages@v4 and peaceiris/actions-gh-pages@v3 ??

Just to future proof. multiple language support
https://[user name].github.io/[repo name]/en/stable/

Just because actions/deploy-pages@v4 is an official action and does not know about peaceiris/actions-gh-pages@v3. I think it is ok to switch to the latter one (without breaking anything), PR is welcome.


Fix compile-time error on Windows

I have encountered this when cross-compiling my program which relies on go-git.
syscall.Stat_t it not defined on Windows platform, and hence go-git
won't compile on Windows. It's better to pass more generic output of FileInfo Sys()
(of type interface{}) to fillSystemInfo and handle type assertion
separately for each platform.

Codecov Report

Merging #251 into master will not impact coverage.

@@           Coverage Diff           @@
##           master     #251   +/-   ##
=======================================
  Coverage   75.92%   75.92%
=======================================
  Files         103      103
  Lines        6792     6792
=======================================
  Hits         5157     5157
  Misses       1074     1074
  Partials      561      561

Impacted Files
Coverage Δ

worktree_linux.go
100% <100%> (ø)
:white_check_mark:

worktree.go
46.4% <100%> (-0.35%)
:x:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fa35e5c...74228be. Read the comment docs.


Use checkout@v4 action in CI consistently

checkout@v3 triggers a warning: https://github.com/private-attribution/ipa/actions/runs/7777716103

the check failures look unrelated... let's try to rerun them. this should be straight forward!


Installed pkg-config contains the wrong include directory

Environment
Compiler:
MSVC 2019
C++ standard mode (e.g. 17, 20, 'latest'):
C++17
Target arch (e.g. x64):
x64
Describe the bug
The generated pkg-config .pc is the following:
$ cat toml++.pc
prefix=C:/src/tomlplusplus/build/install
libdir=${prefix}/lib
includedir=${prefix}/include

Name: toml++
Description: Header-only TOML config file parser and serializer for modern C++
Version: 1.1.0
Cflags:-I${includedir}/toml++

and it specifies that include directories are C:/src/tomlplusplus/build/install/toml++, meaning that a user should include toml++'s headers as:
#include <toml.h>

while according to the readme (https://github.com/marzer/tomlplusplus#-regular-flavour) the correct way of including them is:
#include <toml++/toml.h>

So I guess that we should drop the subdirs argument from https://github.com/marzer/tomlplusplus/blob/764e6dd032fe67b6434183c0510e36b820498de6/meson.build, that do you think @marzer @ximion ?
Additional information

@traversaro #include <toml++/toml.h> is indeed the canonical #include for the 'installed' version, since I can't rule out that users won't have other files called 'toml.h' on their include path - forcing the toml++/ prefix eliminates that possibility.
I haven't done much testing with that part of the build configuration; is #include <toml++/toml.h> what you need to do if the subdirs part is removed?

@traversaro Never mind my last question; I went to read the documentation of meson's pkg-config module and answered it for myself. The fix for this is up now.

Thanks!

Makes sense to me! Thanks for noticing!


Add option '2> /dev/null' to git describe

Git describe return the tag name which could contain the warning (ex: warning: tag 'v2.10' is really '17.05.0' here).
Adding option '2> /dev/null' which make sure no warning is added to tag name.

I had a look into this and preferred to handle the case at the root, in the run_command function.


Building an Android library out of a JVM project using GraalJS

Follow up from https://graalvm.slack.com/archives/CN9L59P61/p1634770859026100
A bit more background, I'm not using native image.
I've taken a look at Gluon maven plugin as suggested here, I'm not sure this is what I need.
I'm not trying to create an APK to run on Android, but a JAR for an existing Android app to consume.
I've tried to get the minimal reproducible steps, I was able to get the same stack trace by just trying to build a Context in a vanilla Android app.
MainActivity.kt:
override fun onCreate(savedInstanceState: Bundle?) {
  super.onCreate(savedInstanceState)

  Context
    .newBuilder(JS)
    .allowAllAccess(true)
    .allowExperimentalOptions(true)
    .option("js.experimental-foreign-object-prototype", "true")
    .build()
}

Producing
E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.demo, PID: 9622
    java.lang.NoSuchMethodError: No virtual method ensureClassInitialized(Ljava/lang/Class;)V in class Lsun/misc/Unsafe; or its super classes (declaration of 'sun.misc.Unsafe' appears in /apex/com.android.runtime/javalib/core-oj.jar)
        at com.oracle.truffle.api.library.LibraryFactory.ensureLibraryInitialized(LibraryFactory.java:384)
        at com.oracle.truffle.api.library.LibraryFactory.getUncached(LibraryFactory.java:364)
        at com.oracle.truffle.api.library.LibraryFactory.<init>(LibraryFactory.java:210)
        at com.oracle.truffle.api.interop.InteropLibraryGen.<init>(InteropLibraryGen.java:170)
        at com.oracle.truffle.api.interop.InteropLibraryGen.<clinit>(InteropLibraryGen.java:161)
        at java.lang.Class.classForName(Native Method)
        at java.lang.Class.forName(Class.java:454)
        at com.oracle.truffle.api.library.LibraryFactory.loadGeneratedClass(LibraryFactory.java:771)
        at com.oracle.truffle.api.library.LibraryFactory.resolveImpl(LibraryFactory.java:734)
        at com.oracle.truffle.api.library.LibraryFactory.resolve(LibraryFactory.java:727)
        at com.oracle.truffle.api.interop.InteropLibrary.<clinit>(InteropLibrary.java:2875)
        at com.oracle.truffle.api.interop.InteropLibrary.getFactory(InteropLibrary.java:2839)
        at com.oracle.truffle.polyglot.PolyglotValueDispatch.<clinit>(PolyglotValueDispatch.java:156)
        at com.oracle.truffle.polyglot.PolyglotValueDispatch.createHostNull(PolyglotValueDispatch.java:1604)
        at com.oracle.truffle.polyglot.PolyglotImpl.initialize(PolyglotImpl.java:143)
        at org.graalvm.polyglot.impl.AbstractPolyglotImpl.setConstructors(AbstractPolyglotImpl.java:233)
        at org.graalvm.polyglot.Engine$1.loadAndValidateProviders(Engine.java:821)
        at org.graalvm.polyglot.Engine$1.run(Engine.java:794)
        at org.graalvm.polyglot.Engine$1.run(Engine.java:768)
        at java.security.AccessController.doPrivileged(AccessController.java:43)
        at org.graalvm.polyglot.Engine.initEngineImpl(Engine.java:768)
        at org.graalvm.polyglot.Engine.access$000(Engine.java:109)
        at org.graalvm.polyglot.Engine$ImplHolder.<clinit>(Engine.java:133)
        at org.graalvm.polyglot.Engine$ImplHolder.access$100(Engine.java:132)
        at org.graalvm.polyglot.Engine.getImpl(Engine.java:320)
        at org.graalvm.polyglot.Engine$Builder.build(Engine.java:559)
        at org.graalvm.polyglot.Context$Builder.build(Context.java:1725)

Which suggests GraalJS can't be used on the Android VM
These are my dependencies in the Android app/JVM project if relevant
implementation("org.graalvm.js", "js", "21.2.0")
implementation("org.graalvm.js", "js-scriptengine", "21.2.0")
implementation("org.graalvm.sdk", "graal-sdk", "21.2.0")

@caoccao i 100% support your effort it sounds like i do able thing and is the right way to do it we need to be able to pollyfill the env thats it thats the missing keypart i have also some android expirence and also vm expirence but i am not as deep into the java core language implementation while i am familar with the v8 implementation on all platforms and chipsets.
but you need to be also aware of the core fact why this api's are missing they are missing because google does not want that you run a JIT on it.

So everything we do here that uses or enables JIT will only be deploy able via Enterprise Policys of Android or InSecure Apk app install which needs user interactions and so on

it will also never get published on the android store.

to get for example nodejs running on Android and Ios we do the following we fork it and then we replace v8 with the OS engine after that we build it as LIB without the JIT Features https://v8.dev/blog/jitless

https://github.com/nodejs-mobile/nodejs-mobile the project now got a community project you can look into it

@frank-dspeed Thank you for the info and suggestions.
Regarding JIT, the V8 in Javet is JIT enabled. So far, there's no user complaining it's blocked by Google Play or other app stores. Of course, most Javet Android users publish their apps in China where there's no Google Play.


Button font size not proper.

Button font size is to expected to be 6px. Currently it's 12px which is not readable.

PR #47 fixes this.