Will Legacy ever be stable?

The first release of Legacy, 1.9, was on April 9. Today, less than three months later, we're on Legacy 4.1, and plans for Legacy 5 have already been mentioned. Every major release so far has been a complete rewrite. Will Legacy ever become stable? It's hard to become invested in a project if it's being rewritten from the ground up literally every month.

I am currently experimenting with different way's people can use Legacy and the way they can customise it. The only part of Legacy 4 that was rewritten was the .btn classes (this time I used more advanced SASS) and it dropped the line count down from around 200 to 47 and the input classes are still being worked on.
I am still testing to see what is the best way to do things. Legacy 5 won't be out for at least 2 months, In this version I want to make sure everything is done how it should be. I want to introduce a stable framework but for now I am not sure what Legacy is headed, the most efficient way hasn't been found.

I am not sure whether I should put all the previous releases as Beta release and start again, 1.0 being released next and it being a fully stable version. I recently invested in a Macbook so when I travel I will be able to work on Legacy full time.
What do you think I should do?

@joexn take a look at Semantic Versioning. Perhaps start using that on version 5, so the next release would be 5.0.1 or something close to that. Many large open source projects are using it, and it's a very good system if you stick to it.

I will defiantly do that. The issue is with the previous releases, all are unusable as they contain so many issues. I am not sure if I should make them development versions and start again on 1.0.0 as I don't think Legacy is stable enough to be consider a web framework. What do you think @runofthemill?

The only part of Legacy 4 that was rewritten was the .btn classes

OK, I was under the impression each major version so far had been a complete rewrite. In that case, I agree with Jeremy that Legacy 4.0 probably should have been 3.4, and 4.1 should have been 3.5.

I am not sure whether I should put all the previous releases as Beta releases and start again, 1.0 being released next and it being a fully stable version.

I'm not really in favor of "rewriting history," so I'd say if you want to do this you should start over with a new name, new domain (:money_with_wings:), etc.
In addition, you should have beta releases to avoid stuff like the font issue with 4.0. 4.0 should have been released as 4.0b1 (or 4.0rc1) and 4.1 should have been 4.0b2, and eventually been released as an official version if no more issues were found.

+1 for semantic versioning. I recommend rescinding version 4 for now - change it to 4.0rc1 until you work out the kinks. That way you aren't trashing the history and can continue with what you have.

Furthermore - consider a concrete definition of features in version 4 so the features remain consistent throughout the release. You can branch for version 5 and merge on with the master branch release. That way your development branch can worked on while v4 remains stable.

This is what will happen..
The Legacy 4.0 release will be deleted and so will the Legacy 4.1 release. They just are not stable.
Themes and Templates will be taken off the website temporarily until a fully stable version is released.
The whole legacy-core.sass idea will be scraped. There will be one file which will serve as the only SASS file, this way it is just easier for everyone (i don't know why I decided to go for multiple SASS files anyway). You will be able to edit all the variables in one file.
When Legacy is stable, it will be released as 4.0 - This will be once EVERYTHING is checked and working and STABLE.
Starting with 4.0 - Legacy will be using Semantic Versioning, something which will make life so much easier but 4.0 needs a lot of work to make it a full framework.
If you need proof that Legacy is no where near complete, check out legacy-framework.com and check the forms section... The inputs are laughable.
For the last time, Legacy will be fully checked, making sure every single class and element preforms as necessary CROSS BROWSER.
I am now going to delete everything from the master branch, and creating a 'dev' branch where Legacy 4.0 alpha will sit for now.
I am going to take two weeks, getting everything ready.. running extensive tests too.
I am also awaiting my new Macbook, my PC keeps crashing while working with GitHub.. While I wait for it to be delivered I am going to be writing out a full plan of where Legacy will be headed and what I want Legacy to become.
Addressing what you just said @georgejenkins - I will use the master branch as the latest stable branch and I'll make a 'dev' branch.. Something that was scraped before.

When you reverted latest to 3.4 you didn't put the source back.

What do you mean?


New TSConfig Management

Type of Issue
[ ] Bug Report
[ ] Feature Request
[x] discussion

Description
This discussion is created in order to permit a more global discussion about TSConfig management, customisation and refactoring, directly following https://github.com/dherges/ng-packagr/pull/790#discussion_r183844424.

current mechanism
required -> consumer -> override (see #786)
required
Was created in order to keep the "right" error message, that is to say the one from TSC, which, in my opinion, reflect the best the reason of the error (at least, better than a "your TSConfig doesn't respect the requirements of ng-packagr").
If we want a better error message, we'll need to write one for each case.
override
are options that will break the ng-packagr build entirely (without a readable error, as we could see with all the related issues which was really difficult to trace).
Why

writing a tsconfig could always break your build. TSC and NGC really have a better maturity (so, error messages) that ng-packagr on this for much cases
but ng-packagr always relies on some of this options in a really specific way, what leads to a set of mandatory options which will have to be overriden in order to hide some misleading erros

How
The identification of the options and their sorting out between a and b cases, was proof tested  during https://github.com/angular/devkit/pull/750 ...
Some other (futur) options
(see options 1 and 2 proposed in #790 (comment) as this is a response to it)
I personally don't think the overriding is a good long term solution, as it could mislead the user on the behaviour of ng-packagr. This would require some documentation at least (but doc is not fix :wink: ). I consider that this is a temporary solution, waiting for a better one. So, I disagree with the option 1. The option 2, at least, could be a better solution, but it relies again on documentation, and we can be sure that this will lead to misunderstandings.
All this question reflect the global approach of ng-packagr : wrapping a lot of tools instead of making just a new one.
Globally, there is some issues with the 3 ways tsconfig are generated and used, as it's misleading a lot of users when using a custom TSConfig (especially with imports / paths, like https://github.com/dherges/ng-packagr/issues/285#issuecomment-384101460, https://github.com/dherges/ng-packagr/issues/519#issuecomment-383418228 or https://github.com/dherges/ng-packagr/issues/791)
Following that, I personally see two other options, but this would need some more refactoring :

simply hide the TSConfig as well (as it could be misleading), and only permit specific options
a. by writing a new json schema
b. or by adding a new typescript options object to ng-package (and removing the withTsConfig method from the public api, as advanced users could always use providers)
forget about any tsconfig overriding, and entirely rethink error handling on tsc, ngc, etc ... by wrapping them, as angular-cli tend to do for some cases. I don't think this could be a good solution for ng-packagr (at it would be too much work to refactor and then maintain), but I prefer to put it here just in case :slightly_smiling_face:

I am not sure about the approaches, let me explain a bit further and put also some ideas on the table as well.
Replacing the option to provide a tsconfig file with providing a limited list of options is quite limiting in some cases as for instance myself, I use several options, baseUrl, types, paths, disableTypeScriptVersionCheck, preserveConstEnums, strictPropertyInitialization etc... And having to set these in 2 places. ie a tsconfig file and an ng-packagr config is less than ideal as it will increase maintainability and the risk of forgetting to add a propery in ng-packagr config. Setting these options in tsconfig is needed for the IDE to function/properly.
When you read a tsconfig file, using tsc or ngc it does more than just merging the options, it resolves the paths and some other things. In my case I highly depend on the fact that I am using my baseUrl for these resolutions and not what ng-packagr requires for the build.
Having to set a custom JSON schema of all the properties in tsc, ngc is not scalable as with every ts and ngc version there are new properties added in the compilerOptions and we are talking at least 80 different options for the moment.
My two cents in order to avoid issues for consumers that use a custom tsconfig would be the following;

Better error messages when one of the mandatory option is missing or set inappropriately. example when setting declaration: false or it's not specified.
Create a schematic to generate a tsconfig with the mandatory options, for users that want to have there own tsconfig.
Document that fact that users can extend the tsconfig with the default tsconfig that ng-packagr provides.

About the maintainability : the compiler-cli and ts api already defines the right typings and schemas, on which we could relie (https://github.com/angular/angular/blob/c8a1a14b87e5907458e8e87021e47f9796cb3257/packages/compiler-cli/src/perform_compile.ts#L104). I agree that this could lead to some more maintenance on this, but not as much as it would seems at first. Also, this could improve issues readability, as we would have a total control on the underlying tools configurations.
Even if I totally agree that this would have a big downside on IDE integration ... as a matter of fact, it is for now in most cases impossible to set a unique tsconfig for development environment (IDE etc ...) and ng-packagr in an angular-cli v6 mono-repository (/ multi-projects), as some options aren't used properly (for example, paths).
This is why I said that permitting to set a custom tsconfig.json file is missleading : it suppose that this tsconfig would be simply used by ng-packagr in the same way tsc and ngc does (as you said), and passed to the underlying tools without any modifications.
I don't see any option to do that, so, here is a little variation of what I proposed early, based on your feedback : we could separate the logics. Permitting to set a custom tsconfig for this kind of use cases, and add build options to ng-package config.
My feedbacks on your "two cents" :

this is exactly why I didn't override this parameters, as I said early : the underlying tools give adequate error messages, so hadding our own would just decrease the maintainability without adding anything ... for now :wink:
a big :+1: on this
:+1: again ... as what we are speaking about here would lead to an important refactoring, we should at least document the existing behaviour

I'm a bit overloaded with work for now, but I could start to do something about that in 2 weeks.

If you take into consideration a mono repo for example, that you mentioned. It is vital that the tsconfig is not part of static options. And you have a tsconfig with a custom baseUrl and paths to work. In fact I do have a starter kit for this which you can see here.
https://github.com/alan-agius4/ng-mono-repo-starter/blob/master/tsconfig.json
https://github.com/alan-agius4/ng-mono-repo-starter/blob/master/tsconfig.build.json
Having full control of a tsconfig, Outside of ng-packagr is essential for this, As i rely on the ngc to properly parse the paths etc and not ng-packagr. As I said early, you cannot simply get some options and merge them with tsconfig, as this simple won't work because when a tsconfig is parsed, it does much more than merging an object.
My point is, we should allow a full custom tsconfig, this is something quite important in my use cases. In case the user provides invalid configuration than we should warn them. By removing the functionality would have a huge impact.
Just a small not on my point 3, you mentioned this requires refactoring, but in  reality it doesn't it just needs to revert this https://github.com/dherges/ng-packagr/pull/786/files, and it will just work out of the box.

@alan-agius4  So, if I understand, you propose to reverte #786 because you think documentation + schematics would be enough, and that we can deal we the related issues in the meantime ? As it fix a lot of issues, doesn't introduce new ones, is consistent with the previous behaviour, was validate by @dherges who did this previous behaviour, and doesn't forbid a deeper refactoring (wich we are talking about here), I don't see why. Maybe @dherges could arbitrate here.
As, in your starter kit, tsconfig.build.json is used only by ng-packagr, I don't understand why a full custom tsconfig is so important in your use case. Could you please explain ? Talking about the tsconfig used outside of ng-packagr doesn't seems relevant in our case here. FYI, I'm, for my part, currently focusing on angular-cli v6 mono-repositories.
It seems to me that ng-packagr control entirely the resulting tsconfig which would be passed to the underlying tools before passing it, so, again, why could we not "simply get some options and merge them with tsconfig" ? This is exactly what is done is ng-packagr, even before #786 : https://github.com/noelmace/ng-packagr/blob/4e6c4f4bb21869c69f084560af3fa75531e4d07f/src/lib/ts/tsconfig.ts#L49

I think we are talking about a lot of unrelated things here, and that we should focus on :

the current behaviour and the possible fix on it
how we could enhance it in order to have better error handling and configuration (the purpose of this issue)

So, f I try to formalise what we talked about here :
first step : enhance the current behaviour

[ ] document the current tsconfig requirements of ng-packagr :heavy_check_mark:

[ ] keep #786, as a temporary solution VS create a schematic as an alternative :question: @dherges

Following https://github.com/angular/devkit/pull/750#issuecomment-383127935, I think @filipesilva could have his opinion on this.
In my opinion, #786 is better as it wouldn't require any additional tool and is entirely transparent for the user. Frankly speaking, @alan-agius4, I neither see exactly what you think is wrong with thi, as ng-packagr is still at an early stage, nor why we should stop fixing simple issues like #790 on it, waiting for an hypothetical refactoring.
second step : tsconfig management refactoring

[ ] refactor in order to have a unique, central starting point for all tsconfig, with transformations on it for specific behaviours (https://github.com/angular/devkit/pull/750#issuecomment-383319671) :question:
[ ] remove all the required / override behaviour on the custom tsconfig which was passed to ng-packagr and use it directly has a real override of the default tsconfig file, but only as an advanced / "know what you're doing" feature :question: this could respond to the "extend" problematic
[ ] add some simple build options in order to permit to customize the build in a much more simple way :question:

The final process would then be :
default tsconfig OR user override
--> ng-packagr (configurable) transformations
--> tsconfig passed to the underlying tools

@noelmace I am not against the fix per see.
But I am questioning if that fix or feature is needed in the first place. Ie: https://github.com/dherges/ng-packagr/pull/786/files, and https://github.com/noelmace/ng-packagr/blob/4e6c4f4bb21869c69f084560af3fa75531e4d07f/src/lib/ts/tsconfig.ts#L49
There are two things here, when you want to create a tsconfig, you must create a valid tsconfig, if you create a tsconfig which is not valid example without moduleResolution even without ng-packagr for instance ngc build would fail. Because it is imperative, when you create a tsconfig, you must create a valid one. For example, if I have an ng app project with angular cli I cannot simple create a tsconfig without the required properties and expect it to work. (There is a schematic which helps in creating this for you).
I do think the missing pieces here is documentation and a schematic. At the moment if you want to use the API and use a custom tsconfig, there are 2 ways, create a full valid tsconfig from scratch. extend the base ng-packagr tsconfig that is shipped with the library, and change whichever property you want to change.
For users, it might be confusing, if they are setting something in tsconfig, and it has no effect, because it is being overridden in code, while if you use the extend, you know that most likely it is because of that.  And mind you, what I am saying here, can be done now because it's already supported, no hypothetical refactoring required.

Ps: I just had a look at the angular schematic, and now I understand that the tsconfig cannot be extended as it's already extended by the main one.

Ok, I totally agree on that. The only difference in our two points of view seems then to be on the planning.
I did #786 (and then #790) in order to respond to https://github.com/angular/devkit/pull/750#issuecomment-383127935 and to fix some issues (for example, #285) quickly, following what was already in place.
I totally agree that all the required + override way is confusing (as https://github.com/dherges/ng-packagr/issues/519#issuecomment-384375281 show it, for example), but I think that we need quickly a solution for that.
Then, maybe we could settle on the two steps I proposed.
First, keep the present behaviour (not because I did #786, or I think it could be the right way in long term, but because I think it is a satisfying short term solution), then document all the requirements and, finally, update the schematics in devkit accordingly, for minor versions (without introducing any breaking change).
And then, as a second and final step, aiming at the next major version, refact all the build configuration (following, or not, the final process I proposed, as we have time to discuss that with the other contributors, mainly @dherges and @filipesilva), with the liberty to introduce breaking changes if needed.

https://github.com/angular/devkit/pull/794


Fixes 143: Remove null fields from api responses

There were three fields I could find that were returning null:

The bulk create error field, when there's no error.
~2. The bulk create repository field, when there is an error.~ leaving out because it's not causing a CI failure and it's not a simple fix
The distribution versions field after a successful creation, if no versions were specified.

I changed these to:

empty string
~2. empty object~
empty array

https://issues.redhat.com/browse/HMSCONTENT-143

Hi
Rebase please.
the ci.int.devshift check for this PR only failed on test_create_update_distro_version_is_unique, which is fixed by https://github.com/content-services/content-sources-backend/pull/85, so thats a good.

Because this contains openapi spec changes, we won't see the test pass in CI - the client generation is not dynamic. @swadeley can pull the openapi spec into our plugin ahead of merging this once we're confident in the content (above discussions about scope of nil values resolved).

this needs  a rebase.

/retest

failure looks unrelated: https://github.com/swaggo/swag/issues/1309


Tests for sway

Since sway is officially supported by this library, we should have tests that test it against a running sway binary.

On Arch Linux I use an old -git package, which includes the "add event_state_mask and symbols to binding info" commit, and it works well. Tonight I built a Void Linux package v2.0.1, and it crashes for me on the 'binding' event again. For now no idea what's happening. On i3 everything works well.

Strange... I'll try to take a closer look on Arch tonight.

Alright, there was a mess in virtual environments. After cleaning it up, I'm having some other difficulties with my code, but the binding event does not crash any longer. Sorry for my mistake.

When running under i3, i3ipc.Connection().get_tree() returns a single object representing the root container. When used under sway, get_tree() returns a linear list of all containers (root, workspaces, windows). Using i3ipc version 2.2.1-1 under Arch in both cases. No mention in the docs that get_tree() might behave differently under i3 and sway.

Never mind, it was an issue with a 3rd-party library, not i3ipc-python. Sorry.


Rewrite the entire notion of named overrides (breaking change)

:warning: Work in progress ⚠
This PR is very likely not yet ready for a full review. But, I wanted to push up the work in progress to get a sense of whether the direction of it is palatable, since I am introducing some relatively foundational changes that will definitely break some existing uses.
#380 outlines a bug related to the current implementation of named overrides. There is an underlying assumption that named override is more or less a "fork" of a parent configuration. The parent configuration, at the point the override is defined, is duplicated and then the changes in the override are applied. The resulting configuration is statically stored in a class instance variable and can be retrieved when it is requested with Configuration.get(:named_override). Unfortunately, this model is directly at odds with how configurations work at runtime. Imagine the following scenario:

Request is using the default config
At runtime we append on another script-src
At runtime we apply an override

Currently, the above scenario results in the appended script-src from not showing up. The reason is that, when we call the override, it applies the config that was generated when the override was defined. That config is simply a copy of the original default config with the overridden directives applied. So, the dynamic changes made to the default config are lost.
In order to fix this we, unfortunately, need to redefine the entire notion of an override. Most callers would assume that an override will override the "current configuration" at runtime. As a result, we can't statically computer the override at the point it is defined. Instead, we need to treat overrides more like how we treat named appends. We store the provided block for an override in a hash that maps the name to the Proc. Then, when the override is requested, we instance_eval the Proc with the current configuration for the request.
Also, during this PR it became evident that trying to cache the generated configs was incredibly complex and prone to error. This PR removes the caching and just computes the headers on demand for each request. We already hit this case a fair bit if one ever used per-request overrides anyway, since the cached values would get invalidated depending on which code path you went through on a given request. The computation overhead of making a header is relatively low and we don't expect it to be a concern. If there is a concern we could optimize the base case and only precompute the default config. But, if any changes are applied, then the precomputation is lost. As I'm typing this it sounds like that could be a nice win, since so few folks probably use dynamic policies. Thoughts?
fixes #380
All PRs:

[x] Has tests
[ ] Documentation updated

All the unit tests for GitHub pass with these changes. But, I did notice I had refactor a few one-off call sites (used for local scripts used to generate CSP values for static files) in a less than glamorous way:
Before:
SecureHeaders::CSP.make_header(
  SecureHeaders::Configuration.get(:static_file_policy).csp
)

After:
SecureHeaders::CSP.make_header(
  SecureHeaders::Configuration.send(:default_config).dup.override(:static_file_policy).csp
)

That is a pretty gross, but is admittedly a fringe usage of this whole library. So, we can either just accept that very few folks will want to do this OR we could add back in a method for fetching the default config. But, unlike the prior Configuration.get method, we could always return a dup of the policy. Thoughts?

So hiding .send(:default_config).dup.override(:static_file_policy) in #get? Sounds good to me.

So hiding .send(:default_config).dup.override(:static_file_policy) in #get? Sounds good to me.

I would just be hiding the .send(:default_config).dup bit such that thew new code would like like Configuration.get.override(:static_file_policy). That said..since the prior Configuration.get didn't dup, what is the lesser evil. Should we kill off Configuration.get and replace it with Configuration.default_dup or leave it and just change the behavior out from underneath people. I'm somewhat nervous to do that, as it might superficially "work", but come bite people in the but when the realize it is a dup.

Hmm I guess without any actual information on how people are using this it seems that obvious breakage would be better than surprising breakage. :+1: to Configuration.default_dup just to remove a send in our code.

Ok..I added a Configuration.dup in https://github.com/twitter/secureheaders/pull/383/commits/b82b56d6a6d4a78857be7217d06c0aa191f6df07. I chose dup as opposed to default_dup (or whatever) since, especially as of this PR, the Configuration class really does represent a single solitary configuration in addition to a bunch of "named overrides" and "named additions". There is only one configuration..so there probably isn't much need to to use the term "default" anymore. For example, Configuration.default is setting the single configuration to its default values. So, Configuration.dup felt natural for meaning "give me a dup of the config". Let me know if you think it too ambiguous.

I deployed this PR on a lab deployment of github.com and it looked good. The only change I had to make across the entire codebase was:
before:
SecureHeaders::Configuration.get(:static_file_policy).csp

after
SecureHeaders::Configuration.dup.override(:static_file_policy).csp

As was noted somewhere above, we use the above in a script to manually generate a static file policy that we copy/paste into our static 404, 500, etc files. It is a pretty obscure usage of the library and I don't expect just about anyone is directly operating on configurations like this. Besides the above, no other changes were needed to get our passing and a deployment operational. I'm guessing that means most consumer of the library won't need to change any code🤞.

Nice! Let's let this bake for a while in production. In the meantime, I'll cut a deprecation release for the upcoming API changes.

This passes CI on our side with flying colours! I'll canary tomorrow and let you know if I hit any weirdness.

I added a test and did a branch deploy of the PR I originally had deployed that unearthed https://github.com/twitter/secureheaders/issues/380. Everything seems to work correctly. I'll probably do another deploy to take a closer look/test at all endpoints that declare overrides later.

I'm going to merge this in to get moving on a new release with a proper alpha since it seems to work even if not yet fully in production.

Released in 6.0.0.alpha01


Update defaults.py

If the user has no HF_TOKEN defined it will raise an error. This fix ensures it does not happen

Dumb stuff while we are at it, gradio and selenium should be installed by default


Units are not included in output

It would make life simpler for users if the Units, Pascals (Pa) were included in the meta data. Otherwise the units need to be added manually by each user.
TIA

Hi, great to learn it's programmatically supported now.
Do you happen to know the link to the doc or an example, I had a look, but could not find it?

Added in release 2.3.0


[SMALLFIX] Check for INVALID_FLUSH_COUNTER before precondition

LGTM

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9973/
Test PASSed.


allow gravity workers to install into separate regions

Description

Quick and dirty gravity patch that allows worker nodes to join from a separate region in AWS.

Can you show how you tested this? Code looks reasonable.

https://github.com/gravitational/cloud/pull/740 - good luck following that though :)
Basically just built a multi-region test cluster in the dev account with those terraform changes I was working on and needed this tweak to get the scripted join to work.


Datalight Reliance (relFs) support

Hello,
While extracting VxWorks firmware the filesystem type happens to be relFs which currently binwalk is not able to extract. How can I add support to extract Datalight Reliance v2.00 Build 0451 filesystem?
Thanks.

Add a signature to https://github.com/ReFirmLabs/binwalk/blob/master/src/binwalk/magic/vxworks, documentation at https://github.com/ReFirmLabs/binwalk/wiki/Creating-Custom-Signatures


Login isn't secure

Right now, the only thing the login page does is set the username cookie. Any user can set the cookie to anything, go to server.com/chat and be logged in as any user they want.

What about an Authorization: Bearer header with email:pass in aes

Probably fixed in b9c5322e599e566f12a753a9c1225eb4179f3e23


Go to other apps and push buttons

Just like going to web pages pushing buttons according to criteria, perhaps add the ability to go to other apps on the Android system and push buttons on them too.

@jidanni sorry but i have no idea what you like to get here. Can you please add some more detail....


Fix fermion device

With this the FermionDevice is now usable for me again and I consider this PR ready for review. Please have a look.

This PR looks very good right now. However, I would like to merge it next week after we had time to review and push #44. This way we can make sure that the logic concerning the errors etc is existent for all devices.


Infinite recursion when inspecting an AST node with breakpoints

Inspecting an ast node that has breakpoints leads to an infinite recursion:

Reflectivity has internally a dedicated RFMessageNode  that when we print we get the error. This internally uses a RBLiteralValueNode  that holds to the breakpoint, and we end up sending storeOn:  to the breakpoint.

We end up in that path as we use a custom formatter that does not have the same check as RBSimplerFormatter.

Fixed the infinite recursion when printing by avoiding calling sourceText. Change in https://github.com/j-brant/RBFormatter/commit/19c531f1c8a2b5dda726b3e1b7d9ceca87476893


Problems when using grpc with newest abseil 20240116.0

In conda-forge, we build shared libraries for many reasons, and one of the consequences is that we have to rebuild things whenever a new version (resp. changed ABI) of a given library is released. These so-called migrations are usually routine, but still take a certain amount of effort, so there's a natural tendency to group them, especially when they all affect very similar packages that need to be migrated.
This is the case in particular for us w.r.t. abseil, protobuf & grpc. As such, I wanted to build grpc 1.61 against abseil 20240116.0, as in the past these abseil updates were not an issue. After misdiagnosing the first issue I ran into, I realize now that some fixes for the newest abseil only landed after 1.61, but I can deal with that (e.g. by backporting https://github.com/grpc/grpc/commit/bc044174401a0842b36b8682936fc93b5041cf88).
However, even with that fix, the compilation of the C++ helloworld example fails on linux. It passes on osx, which surprised me at first, but I suspect very much that it has something to do with
https://github.com/grpc/grpc/blob/239399212a33b3abe5e0762e2a4923d4334d2ebc/src/core/lib/gprpp/sync.h#L45-L61
resp.
https://github.com/grpc/grpc/blob/239399212a33b3abe5e0762e2a4923d4334d2ebc/include/grpc/support/port_platform.h#L29-L39
In other words, not using the abseil synchronization features works, but there are problems now also on linux when trying to use them. Not sure why that symbol would not be found, as all the respective grpc files correctly #include "absl/synchronization/mutex.h".
What version of gRPC and what language are you using?
1.61.0
What operating system (Linux, Windows,...) and version?
Linux
What runtime / compiler are you using (e.g. python version or version of gcc)
GCC 12
What did you do?
Compile grpc 1.61.0 with -DgRPC_ABSL_PROVIDER="package" and abseil 20240116.0, then try to compile https://github.com/grpc/grpc/tree/master/examples/cpp/helloworld
What did you expect to see?
Compilation passes
What did you see instead?
[7/18] Linking CXX executable greeter_client
FAILED: greeter_client
: && $PREFIX/bin/x86_64-conda-linux-gnu-c++ -fvisibility-inlines-hidden -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/libgrpc-1.61.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,--allow-shlib-undefined -Wl,-rpath,$PREFIX/lib -Wl,-rpath-link,$PREFIX/lib -L$PREFIX/lib CMakeFiles/greeter_client.dir/greeter_client.cc.o -o greeter_client  libhw_grpc_proto.a  $PREFIX/lib/libabsl_flags_parse.so.2401.0.0  $PREFIX/lib/libgrpc++_reflection.so.1.61.0  $PREFIX/lib/libgrpc++.so.1.61.0  $PREFIX/lib/libprotobuf.so.25.2.0  $PREFIX/lib/libgrpc.so.38.0.0  $PREFIX/lib/libaddress_sorting.so.38.0.0  $PREFIX/lib/libupb_json_lib.so.38.0.0  $PREFIX/lib/libupb_textformat_lib.so.38.0.0  $PREFIX/lib/libupb_message_lib.so.38.0.0  $PREFIX/lib/libupb_base_lib.so.38.0.0  $PREFIX/lib/libupb_mem_lib.so.38.0.0  $PREFIX/lib/libutf8_range_lib.so.38.0.0  $PREFIX/lib/libssl.so  $PREFIX/lib/libcrypto.so  $PREFIX/lib/libgpr.so.38.0.0  -ldl  -lm  -lrt  $PREFIX/lib/libabsl_random_distributions.so.2401.0.0  $PREFIX/lib/libabsl_random_seed_sequences.so.2401.0.0  $PREFIX/lib/libabsl_random_internal_pool_urbg.so.2401.0.0  $PREFIX/lib/libabsl_random_internal_randen.so.2401.0.0  $PREFIX/lib/libabsl_random_internal_randen_hwaes.so.2401.0.0  $PREFIX/lib/libabsl_random_internal_randen_hwaes_impl.so.2401.0.0  $PREFIX/lib/libabsl_random_internal_randen_slow.so.2401.0.0  $PREFIX/lib/libabsl_random_internal_platform.so.2401.0.0  $PREFIX/lib/libabsl_random_internal_seed_material.so.2401.0.0  $PREFIX/lib/libabsl_random_seed_gen_exception.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_check_op.so.2401.0.0  $PREFIX/lib/libabsl_leak_check.so.2401.0.0  $PREFIX/lib/libabsl_die_if_null.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_conditions.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_message.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_nullguard.so.2401.0.0  $PREFIX/lib/libabsl_examine_stack.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_format.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_proto.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_log_sink_set.so.2401.0.0  $PREFIX/lib/libabsl_log_sink.so.2401.0.0  $PREFIX/lib/libabsl_log_entry.so.2401.0.0  $PREFIX/lib/libabsl_log_initialize.so.2401.0.0  $PREFIX/lib/libabsl_log_globals.so.2401.0.0  $PREFIX/lib/libabsl_vlog_config_internal.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_fnmatch.so.2401.0.0  $PREFIX/lib/libabsl_log_internal_globals.so.2401.0.0  $PREFIX/lib/libabsl_statusor.so.2401.0.0  $PREFIX/lib/libabsl_status.so.2401.0.0  $PREFIX/lib/libabsl_strerror.so.2401.0.0  $PREFIX/lib/libabsl_flags_usage.so.2401.0.0  $PREFIX/lib/libabsl_flags_usage_internal.so.2401.0.0  $PREFIX/lib/libabsl_flags_internal.so.2401.0.0  $PREFIX/lib/libabsl_flags_marshalling.so.2401.0.0  $PREFIX/lib/libabsl_flags_reflection.so.2401.0.0  $PREFIX/lib/libabsl_flags_config.so.2401.0.0  $PREFIX/lib/libabsl_cord.so.2401.0.0  $PREFIX/lib/libabsl_cordz_info.so.2401.0.0  $PREFIX/lib/libabsl_cord_internal.so.2401.0.0  $PREFIX/lib/libabsl_cordz_functions.so.2401.0.0  $PREFIX/lib/libabsl_cordz_handle.so.2401.0.0  $PREFIX/lib/libabsl_crc_cord_state.so.2401.0.0  $PREFIX/lib/libabsl_crc32c.so.2401.0.0  $PREFIX/lib/libabsl_str_format_internal.so.2401.0.0  $PREFIX/lib/libabsl_crc_internal.so.2401.0.0  $PREFIX/lib/libabsl_crc_cpu_detect.so.2401.0.0  $PREFIX/lib/libabsl_raw_hash_set.so.2401.0.0  $PREFIX/lib/libabsl_hash.so.2401.0.0  $PREFIX/lib/libabsl_bad_variant_access.so.2401.0.0  $PREFIX/lib/libabsl_city.so.2401.0.0  $PREFIX/lib/libabsl_low_level_hash.so.2401.0.0  $PREFIX/lib/libabsl_hashtablez_sampler.so.2401.0.0  $PREFIX/lib/libabsl_exponential_biased.so.2401.0.0  $PREFIX/lib/libabsl_flags_private_handle_accessor.so.2401.0.0  $PREFIX/lib/libabsl_flags_commandlineflag.so.2401.0.0  $PREFIX/lib/libabsl_bad_optional_access.so.2401.0.0  $PREFIX/lib/libabsl_flags_commandlineflag_internal.so.2401.0.0  $PREFIX/lib/libabsl_flags_program_name.so.2401.0.0  $PREFIX/lib/libabsl_synchronization.so.2401.0.0  $PREFIX/lib/libabsl_graphcycles_internal.so.2401.0.0  $PREFIX/lib/libabsl_kernel_timeout_internal.so.2401.0.0  $PREFIX/lib/libabsl_time.so.2401.0.0  $PREFIX/lib/libabsl_civil_time.so.2401.0.0  $PREFIX/lib/libabsl_time_zone.so.2401.0.0  $PREFIX/lib/libabsl_stacktrace.so.2401.0.0  $PREFIX/lib/libabsl_symbolize.so.2401.0.0  $PREFIX/lib/libabsl_strings.so.2401.0.0  $PREFIX/lib/libabsl_strings_internal.so.2401.0.0  $PREFIX/lib/libabsl_string_view.so.2401.0.0  $PREFIX/lib/libabsl_int128.so.2401.0.0  $PREFIX/lib/libabsl_throw_delegate.so.2401.0.0  $PREFIX/lib/libabsl_malloc_internal.so.2401.0.0  $PREFIX/lib/libabsl_debugging_internal.so.2401.0.0  $PREFIX/lib/libabsl_demangle_internal.so.2401.0.0  $PREFIX/lib/libabsl_base.so.2401.0.0  -lpthread  $PREFIX/lib/libabsl_raw_logging_internal.so.2401.0.0  $PREFIX/lib/libabsl_log_severity.so.2401.0.0  $PREFIX/lib/$PREFIX/x86_64-conda-linux-gnu/bin/ld: libhw_grpc_proto.a(helloworld.grpc.pb.cc.o): in function `grpc::CompletionQueue::~CompletionQueue()':
helloworld.grpc.pb.cc:(.text._ZN4grpc15CompletionQueueD2Ev[_ZN4grpc15CompletionQueueD5Ev]+0x4d): undefined reference to `absl::lts_20240116::Mutex::Dtor()'
$PREFIX/x86_64-conda-linux-gnu/bin/ld: libhw_grpc_proto.a(helloworld.grpc.pb.cc.o): in function `grpc::ClientReader<helloworld::HelloReply>::~ClientReader()':
helloworld.grpc.pb.cc:(.text._ZN4grpc12ClientReaderIN10helloworld10HelloReplyEED2Ev[_ZN4grpc12ClientReaderIN10helloworld10HelloReplyEED5Ev]+0x6c): undefined reference to `absl::lts_20240116::Mutex::Dtor()'
$PREFIX/x86_64-conda-linux-gnu/bin/ld: libhw_grpc_proto.a(helloworld.grpc.pb.cc.o): in function `non-virtual thunk to grpc::ClientReader<helloworld::HelloReply>::~ClientReader()':
helloworld.grpc.pb.cc:(.text._ZN4grpc12ClientReaderIN10helloworld10HelloReplyEED2Ev[_ZN4grpc12ClientReaderIN10helloworld10HelloReplyEED5Ev]+0x10c): undefined reference to `absl::lts_20240116::Mutex::Dtor()'
$PREFIX/x86_64-conda-linux-gnu/bin/ld: libhw_grpc_proto.a(helloworld.grpc.pb.cc.o): in function `non-virtual thunk to grpc::ClientReaderWriter<helloworld::HelloRequest, helloworld::HelloReply>::~ClientReaderWriter()':
helloworld.grpc.pb.cc:(.text._ZN4grpc18ClientReaderWriterIN10helloworld12HelloRequestENS1_10HelloReplyEED2Ev[_ZN4grpc18ClientReaderWriterIN10helloworld12HelloRequestENS1_10HelloReplyEED5Ev]+0x7c): undefined reference to `absl::lts_20240116::Mutex::Dtor()'
$PREFIX/x86_64-conda-linux-gnu/bin/ld: libhw_grpc_proto.a(helloworld.grpc.pb.cc.o): in function `grpc::ClientReaderWriter<helloworld::HelloRequest, helloworld::HelloReply>::~ClientReaderWriter()':
helloworld.grpc.pb.cc:(.text._ZN4grpc18ClientReaderWriterIN10helloworld12HelloRequestENS1_10HelloReplyEED2Ev[_ZN4grpc18ClientReaderWriterIN10helloworld12HelloRequestENS1_10HelloReplyEED5Ev]+0x12c): undefined reference to `absl::lts_20240116::Mutex::Dtor()'
$PREFIX/x86_64-conda-linux-gnu/bin/ld: libhw_grpc_proto.a(helloworld.grpc.pb.cc.o):helloworld.grpc.pb.cc:(.text._ZN4grpc18ClientReaderWriterIN10helloworld12HelloRequestENS1_10HelloReplyEED2Ev[_ZN4grpc18ClientReaderWriterIN10helloworld12HelloRequestENS1_10HelloReplyEED5Ev]+0x1dc): more undefined references to `absl::lts_20240116::Mutex::Dtor()' follow
collect2: error: ld returned 1 exit status

Anything else we should know about your project / environment?
The same build recipe & test procedure passed with the previous abseil version.

It's worth noting that this problem only appears on linux, not on osx or windows.

Might be abseil-related after all, see https://github.com/abseil/abseil-cpp/commit/f3760b4d3b2773d1cb8e9ddda29dc9bce386d540 resp. this.
Does someone here know if we're explicitly falling under the case that the commit message rules out?

The Mutex destructor is needed only to clean up debug logging
and invariant checking synch events. These are not supposed
to be used in production, but the non-empty destructor has
costs for production builds.

CC @veblush @yashykt

Note that https://github.com/grpc/grpc/releases/tag/v1.61.1 was just released to address abseil #include issue.

If you think there is something that gRPC needs to address about undefined symbol errors, please let us know.

Note that https://github.com/grpc/grpc/releases/tag/v1.61.1 was just released to address abseil #include issue.

Yeah, I had backported that patch (to 1.61.0) already, otherwise things don't even build. Now on 1.61.1, the backport is obviously not necessary anymore.

If you think there is something that gRPC needs to address about undefined symbol errors, please let us know.

I cannot tell if the "fault" is on the side of abseil or grpc, but AFAICT, abseil hides a symbol that grpc needs, at least when building the helloworld c++ example (though I suspect the pattern there is very vanilla and the same problem would appear elsewhere).
Ideally I'd hope that the maintainers of grpc and abseil (cc @derekmauro) can figure out whose expectations were not correct and then fix it on either (or both) sides.

I briefly looked at this issue but I didn't spot anything in gRPC which can cause this kind of issue. I suspect it could be a compiler issue where it cannot handle force-inline well but I'd like to wait for Abseil-team's investigation.

I think at least one reason for the problem is that grpc does not seem to respect CPPFLAGS (while abseil does; this creates a divergence in whether the ABI-impacting -DNDEBUG is present or not), which should be used for both CC/CXX invocations (i.e. like adding it to both CFLAGS and CXXFLAGS).


Auto creation of ingress should not include bare domain, just *.domain

Describe the bug
Setting features.ingress.enabled=true creates two ingress routes/hosts automatically: mydomain.com and *.mydomain.com
This prevents the admin from using mydomain.com for anything else (e.g. the company website, or Stratos UI)
Workaround: Manually edit the ingress once it is created to remove the bare domain entries. This gets overwritten with each helm update and has to be repeated.
Expected behavior
Expect automatic setup of the *.domain.com wildcard for endpoints like uaa and api but not the basename (which is not required for CF.

With Helm 3, the workaround should be kept around: https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-strategic-merge-patches, it shouldn't happen. @troytop Has this behaviour been observed with Helm 3?

In any case, I opened PR #1213 to fix this.


[New Feature][Habana main] spec decode PR2 - Medusa, MLP, Eagle

Spec Decoder PR2 - enable Medusa, MLP
This PR is add on to https://github.com/HabanaAI/vllm-fork/pull/375
=> Do not merge until PR375 merged
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Adding or changing kernels
Each custom kernel needs a schema and one or more implementations to be registered with PyTorch.

Make sure custom ops are registered following PyTorch guidelines: Custom C++ and CUDA Operators and The Custom Operators Manual
Custom operations that return Tensors require meta-functions. Meta-functions should be implemented and registered in python so that dynamic dims can be handled automatically. See above documents for a description of meta-functions.
Use torch.libary.opcheck() to test the function registration and meta-function for any registered ops.  See tests/kernels for examples.
When changing the C++ signature of an existing op, the schema must be updated to reflect the changes.
If a new custom type is needed, see the following document: Custom Class Support in PT2.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

Using Medusa
llm = LLM(
        model="JackFram/llama-68m",
        speculative_model="abhigoyal/vllm-medusa-llama-68m-random",
        num_speculative_tokens=5,
        use_v2_block_manager=True,
    )

Using MLP
 llm = LLM(
        model="meta-llama/Llama-2-13b-chat-hf",
        speculative_model="ibm-fms/llama-13b-accelerator",
        # These are currently required for MLPSpeculator decoding
        use_v2_block_manager=True,
    )

Medusa, MLP and Eagle all are runnable.

Using eagle
    llm = LLM(
        model="JackFram/llama-68m",
        speculative_model="abhigoyal/vllm-eagle-llama-68m-random",
        num_speculative_tokens=5,
        # These are currently required for MLPSpeculator decoding
        use_v2_block_manager=True,
    )

@michalkuligowski , I have updated the medusa_worker.py and spec_decode/multi_step_worker.py. Now they are using a common platform switch in selector.py


Something went wrong (TypeError: t is not a function)

Issue Description
I was experimenting with this library (awesome by the way) and everything was working fine, but without apparently changing anything it stopped working and I can't find the root cause.
Maybe you could help me.
Steps to Reproduce
The issue happens with both Human.detect and Human.warmup.
This is the full log I get in chrome:
Platform browser has already been set. Overwriting the platform with [object Object].
cpu backend was already registered. Reusing existing backend factory.
webgl backend was already registered.
Environment

Module version? 1.3.5
Built-in demo or custom code?
Type of module used (e.g. js, esm, esm-nobundle)?
Browser or NodeJS and version (e.g. NodeJS 14.15 or Chrome 89)? Node v14.16.0, npm 7.8.0, Chrome 89.0.4389.114
OS and Hardware platform (e.g. Windows 10, Ubuntu Linux on x64, Android 10)? Windows 10
Packager (if any) (e.g, webpack, rollup, parcel, esbuild, etc.)?

Additional
I am running the code in Chrome while emulating an iPhone 6/7/8 Plus using the DevTools
Tensor flags:
{
    "IS_BROWSER": true,
    "IS_NODE": false,
    "DEBUG": false,
    "WEBGL_VERSION": 2,
    "HAS_WEBGL": true,
    "PROD": true,
    "CHECK_COMPUTATION_FOR_ERRORS": false,
    "WEBGL_PACK_DEPTHWISECONV": true,
    "TENSORLIKE_CHECK_SHAPE_CONSISTENCY": false,
    "IS_TEST": false,
    "WEBGL_MAX_TEXTURE_SIZE": 16384,
    "WEBGL_PACK": true,
    "WEBGL_FORCE_F16_TEXTURES": false,
    "WEBGL_RENDER_FLOAT32_CAPABLE": true,
    "WEBGL_RENDER_FLOAT32_ENABLED": true,
    "WEBGL_LAZILY_UNPACK": true,
    "WEBGL_PACK_IMAGE_OPERATIONS": true,
    "WEBGL_PACK_BINARY_OPERATIONS": true,
    "WEBGL_CPU_FORWARD": true
}

Full config (logged on console):
{
    "backend": "webgl",
    "wasmPath": "../assets/",
    "debug": true,
    "async": true,
    "profile": false,
    "deallocate": false,
    "scoped": false,
    "videoOptimized": false,
    "warmup": "face",
    "filter": {
        "enabled": false,
        "width": 0,
        "height": 0,
        "return": true,
        "brightness": 0,
        "contrast": 0,
        "sharpness": 0,
        "blur": 0,
        "saturation": 0,
        "hue": 0,
        "negative": false,
        "sepia": false,
        "vintage": false,
        "kodachrome": false,
        "technicolor": false,
        "polaroid": false,
        "pixelate": 0
    },
    "gesture": {
        "enabled": true
    },
    "face": {
        "enabled": true,
        "detector": {
            "modelPath": "../models/blazeface-back.json",
            "rotation": false,
            "maxFaces": 2,
            "skipFrames": 21,
            "skipInitial": false,
            "minConfidence": 0.2,
            "iouThreshold": 0.1,
            "scoreThreshold": 0.2,
            "return": false
        },
        "mesh": {
            "enabled": true,
            "modelPath": "../models/facemesh.json"
        },
        "iris": {
            "enabled": false,
            "modelPath": "../models/iris.json"
        },
        "description": {
            "enabled": true,
            "modelPath": "../models/faceres.json",
            "skipFrames": 31
        },
        "emotion": {
            "enabled": false,
            "minConfidence": 0.1,
            "skipFrames": 32,
            "modelPath": "../models/emotion.json"
        },
        "age": {
            "enabled": false,
            "modelPath": "../models/age.json",
            "skipFrames": 33
        },
        "gender": {
            "enabled": false,
            "minConfidence": 0.1,
            "modelPath": "../models/gender.json",
            "skipFrames": 34
        },
        "embedding": {
            "enabled": false,
            "modelPath": "../models/mobileface.json"
        }
    },
    "body": {
        "enabled": false,
        "modelPath": "../models/posenet.json",
        "maxDetections": 10,
        "scoreThreshold": 0.3,
        "nmsRadius": 20
    },
    "hand": {
        "enabled": false,
        "rotation": false,
        "skipFrames": 12,
        "skipInitial": false,
        "minConfidence": 0.1,
        "iouThreshold": 0.1,
        "scoreThreshold": 0.5,
        "maxHands": 1,
        "landmarks": true,
        "detector": {
            "modelPath": "../models/handdetect.json"
        },
        "skeleton": {
            "modelPath": "../models/handskeleton.json"
        }
    },
    "object": {
        "enabled": false,
        "modelPath": "../models/nanodet.json",
        "minConfidence": 0.2,
        "iouThreshold": 0.4,
        "maxResults": 10,
        "skipFrames": 41
    }
}

For installation or startup issues include your package.json
For usage issues, it is recommended to post your code as gist

I've tried with your config and it works fine on my system.
Error itself is not helpful as it comes from minified code:

Uncaught (in promise) TypeError: t is not a function
at somecode.js:23

However, this indicates that TFJS is being loaded twice

Platform browser has already been set. Overwriting the platform with [object Object].
cpu backend was already registered. Reusing existing backend factory.
webgl backend was already registered. Reusing existing backend factory.

Likely it's loaded once from your code and once the bundled version within Human - and that can cause conflict
Can you share full import statements from your code?
Also, can you describe your environment? Your code is TS so you must compile it and likely run through bundler?
Additionally, you can create non-minified version of Human to get a proper backtrace
Simply run npm run dev and it will run build in non-minified form. Once build is complete (1sec), just CTRL+C to stop web server (if you don't need it)
Once you want to go back to prod (minified) version of Human, simply run npm run build

I've tried with your config and it works fine on my system.

Yeah, I also tried it on codepen and it seems to work. I've never doubted it was a config input issue.

However, this indicates that TFJS is being loaded twice

I also have face-api.js in the same project. Maybe they are conflicting. I will try to remove it in order to isolate the library.

Can you share full import statements from your code?

This is how I am importing it:
import type { Config, Error, Result } from '@vladmandic/human';
import Human from '@vladmandic/human';

Also, can you describe your environment?
Your code is TS so you must compile it and likely run through bundler?

It is inside a StencilJS  project. The bundling is handled by its internals and I am not aware of what they are using now.

@vladmandic Apparently the other library was conflicting with this one. After removing it this works again, such a silly oversight. Thanks for your help.
I also had a comment related to how the config is provided.
I understand that right now if you want to change the path of the models you need to provide all of them separately even if all the models end up in the same folder (just in a different place). Could it be possible to change this path only once instead of having to change it for all the models?

I also have face-api.js in the same project. Maybe they are conflicting. I will try to remove it in order to isolate the library.

Original face-api.js is based on TFJS 1.7.0 and not updated since - that is a hard conflict with TFJS 3.3.0 used by Human
Before I started Human, I did a project to modernize face-api.js: https://github.com/vladmandic/face-api
I still maintain it, but it's pretty much surpassed in functionality by Human nowadays.

Could it be possible to change this path only once instead of having to change it for all the models?

That's a a good idea for an enhancement - I'll implement it.

My plan is to switch from the original face-api.js to Human, basically, because it is easier to set up, more performant, does more things, and is maintained.
I will report more setup/usability enhancements as I find them.
Again, thanks for your work. :)

you're welcome!
i've just added config option modelBasePath that is used as base path when constructing each individual modelPath.
if any specific modelPath is an absolute path, then modelBasePath will be ignored for that model.
new version 1.4 is published


Could not find a declaration file for module './presets/aura'

Downloaded the presets package and unzipped it.
import Aura from './presets/aura'

const app = createApp(App)
  .use(PrimeVue, {
    unstyled: true,
    pt: Aura,
  })
  .use(router)

Error:
Could not find a declaration file for module './presets/aura'
The styling works but I can not build my project.

As of v4.1.1, the new Tailwind styles have been rewritten using the preprocessor approach with @apply. This issue should be resolved with the new implementation.
New Website is live.


Re-implement input history #602

Added input history as a new add-on.
You can toggle it on/off from the web-config.
It's possible to set the length of the history string (in characters) and position it on the screen by setting the starting column and row.

This looks great!  Thank you @kiralydavid
I will test this out when I have some time.   Are you on the Discord?

A few minor adjustments I'd make, just for the sake of following the existing code patterns.

I understand the reasoning for doing it, but try to avoid changing the pattern on addon constructors.  Creating the Display addon should not require the Input History addon, even if it's disabled.
Instead, I would suggest adding a method on the addon so we only have to attach the two addons if they're enabled.  It should ultimately be optional.
Check the state of both Input History and Display in your available() method if the Display is not enabled.  See the Wii Extension addon available() for a means of doing this.

Code changes are looking good on my end. Nice turnaround!

@kiralydavid Looks great! We just had a push to our i2c peripherals, could you pull latest and resolve conflicts on your end? Should be pretty straight forward, @mikepparks did a great job on the i2c stuff.


⚠ Bofrost.gr has degraded performance

In 4fe116a, Bofrost.gr (https://www.bofrost.gr) experienced degraded performance:

HTTP code: 200
Response time: 3411 ms

Resolved: Bofrost.gr performance has improved in 848f2ca after 9 minutes.


Tapswap not working

Tapswap not working pro...

Same @Poryaei

The robot does not collect coins & when get /balance show Previous balance

Check again pls

Check again pls

need update or not ?

No

Update app.py

Is the tapswap bot working now?