[FR] Generic custom fields

Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

Problem statement
When we receive certain stock items, we need to apply an internal barcode to them.  This barcode is part of a much larger system that we cannot alter/influence.  These barcodes are printed/created by the property team; we get a roll of them, apply them to devices, and then notify the property team what barcodes were applied to which devices.  We'd like to track that internal barcode in addition to the stock item serial number.  Additionally, it needs to be searchable.
Suggested solution
As a possible solution, there could just be an additional field added to the stock object called 'asset tag' lower level of effort required, but less flexibility.
Another possible solution would be allow users to define custom fields in each part (or in the admin panel, for the stock model in general), but that were unique to each instance of the stock.  Then we could not only define 'asset tags' but then also things like 'this device was purchased for (re: with the money from) blue customer, or our red customer` (something else we need to do for compliance reasons).
Describe alternatives you've considered
We've looked at using the Stock Item Notes, but this field is not indexed by search (understandably so), meaning that its difficult to reference stock items by the contents of that field.
Examples of other systems
We also use Netbox, and it handles this in a relatively elegant way; custom fields for each model (it's also Django based).
Do you want to develop this?

[ ] I want to develop this.

Also, if I totally missed where this is implemented, please let me know; happy to accept its a PEBKAC issue.

@mddeff why don't you associate the internal barcode with the stock item as a barcode? Maybe I am misunderstanding your request but it seems the function is already there.

So, unfortunately in our environment (datacenter with high compliance restrictions) we cant utilize the mobile app or barcode scanners hooked up to computers unless they've been specifically approved.  And getting them approved is a sisyphean task. (not something I expected one to divine from my initial FR)
That being said, the example I provided in the initial suggestion was just one use case.  We have other use cases where we need to associate arbitrary data to ever stock or part in inventree:

what contract was this purchased on (pre-determined list of choices)
has the device been sanitized, etc.  (boolean)
aforementioned asset tag (freeform text field)

I could have worded the original request better to better describe the other use cases; I'm happy to edit if preferred.

You could also add the values hand into the text field.
We provide additional meta fields to plugins / via the API - not sure if we should add more options @SchrodingersGat

This sounds like it is along the lines of my reasoning why all models should have metadata attached - these are a basis for adding custom fields: https://github.com/inventree/InvenTree/issues/4202
Making them available and editable in the GUI is another issue, of course..

When we receive certain stock items, we need to apply an internal barcode to them.

Maybe I'm missing something from the discussion here, but InvenTree already supports custom barcodes for stock items?

You could also add the values hand into the text field.

We looked at that, but unfortunately the text field is not indexed (not saying it should be); this means that we cant search inventree by contents of that field.

Maybe I'm missing something from the discussion here, but InvenTree already supports custom barcodes for stock items?

The issue we have with barcodes is that we dont have any way (at least, today) to connect a barcode scanner (or camera, or mobile device) to the same network that has our instance of inventree running on it.  When I try to type in the barcode manually (it's only 5-7 characters long), it assigns a long ID in the barcode field and I cant search by the text I had entered. I understand this is a unique aspect of our deployment that I dont expect inventree to handle (very much a corner case).
But barcode was only one example, the larger issue is that we're running into several fields that are specific to our environment that we need to track per stock item that we just dont have a way to do today.  This could be everything from:

internal team a stock item is associated with
who is registered on our internal property books as being the "responsible person"
additional serial number like unique identifiers that are not the serial number (express service code, first Ethernet MAC address, etc.)
Tracking number on the internal document we use to track stock movement

The example I referenced was Netbox, where they have per-model custom fields that can be defined in the admin page, and then utilized in the app.  Does that clarify the use case at all? (genuinely asking)

@mddeff the closest thing we currently offer "out of the box" is that the StockItem model has a "metadata" parameter which is a JSON object field which can contain any custom user data of arbitrary complexity. This can be accessed / edited via the API or the admin interface (currently not exposed via the web interface).
Does this perhaps go some way towards what you are looking for?

@SchrodingersGat , It does sound like its in the right direction; does any of that get parsed/indexed by the main site search?  I'm assuming to integrate it into the UI, somebody would have to write a plugin?  The target audience who would need to interface this isnt likely to have access to (or want to use) the admin interface.

@mddeff sounds like a plugin would be suitable here. The admin interface is certainly clunky and not designed for everyday use

Does any of that get parsed/indexed by the main site search?

Nope, metadata is not parsed by the search engine

I think a generic way to add (searchable) custom fields that can be set on a stock item would be beneficial.
In my usecase I have docks/pcs/etc, those have a trackable serial number, a service tag and more. This works well as I set the part as 'trackable' and enter the serial for each stock item. However I would also like to store the service tag and MAC address for each stock item (in a searchable manner).  Currently I have not found a way to do this.

Search engine is a bit misleading.  Adding anything there is not an easy feat without slowing the userinterface down.
If you only need asset managment I would suggest looking into netbox / snipe-it as this FR will take a while to develop and no dev has signed up to do it in the last 3 weeks. I use snipe-it for (IT) asset management at work and netbox for network infrastructure.

Yeah, I should not have used dock/pc as use-case, I thought it was a clear understandable example I just happened to run into today. It is not our main use.
We tried snipe-it before, but it did not work out for our use. Inventree fits our use much better (even with these limitations).

reacting because still important.

Not stale.

reacting because still important.

reacting because still important.


Update SRML Council: prevent excess votes/computation

Add assertion and associated tests to prevent a vote from voters that provide a list of votes with a length that exceeds the amount of candidates, since otherwise an attacker may be able to submit a very long list of votes that far exceeds the amount of candidates and waste more computation than a reasonable voting bond would cover. Added additional associated test that may be run with cargo test -p srml-council

Add assertion and associated tests so that amount of candidates must be greater than zero when calling set_approvals for a list of votes to be made by a voter

Update comment to refer to reporter instead of who (target of inactivity), since the origin is the reporter

Update comment to refer more specifically to how many vote indexes, since InactiveGracePeriod is measured in vote indexes

Update comment for ApprovalsOf since previously the comment was a duplicate of the comment for LastActiveOf's

Create variable to refer to retaining_seats to improve readability

Reference Notes: https://hackmd.io/nr6kPD2sR4urmljtvHs0CQ

i've pushed commit https://github.com/paritytech/substrate/pull/1162/commits/db7b90e7f688fe73963ad0953ed43cb69938ea5b to address relevant comment that arose in a different PR https://github.com/paritytech/substrate/pull/1185#discussion_r238141545


Update workflow, add pre-commit-hook, add end-to-end tests, add eslint, update data.json, update packages

@BurnySc2 This merge breaks my old build order links.
Conversely, build orders that I make on this merge #32 don't work on a local dev version of merge #31. I get "Error: incorrect header check"
Weirdly, the example BOs on the repository site do work on my local version of merge #31, but they break if I edit them on your host and then try to transfer them to my local version. In that case I get the incorrect header check error.
Any thoughts? How should I migrate my old links?
Here's a BO link from merge #31 where two SCVs are being built that breaks in the new pull.

This is resolved with the pako revert.

@jtsauls whoops, I've just seen these comments. I'm glad they got fixed too! I'm slowly implementing end-to-end tests so this shouldn't happen again.


parser: Allow parsing arbitrary functions

In Thanos we would like to start experimenting with custom functions that are currently not part of the PromQL spec. We would do this by adding an implementation for those functions to the Thanos engine and allow users to decide which engine they want to use on a per-query basis.
Since we use the PromQL parser from Prometheus, injecting functions in the global Functions variable would mean they also become available for the Prometheus engine. To avoid this side-effect, this commit exposes a Parser interface in which the supported functions can be injected as an option. If no functions are injected, the parser implementation will default to the functions defined in the global Functions variable.

While I appreciate your efforts, I cannot accept this pull request as we aim to maintain a consistent PromQL experience across the ecosystem. I would like to inquire about the types of functions that are not suitable for Prometheus upstream and whether they can be implemented (maybe even behind a feature flag).
(Additionally, some users have already been overriding the exposed Function.)

Thank you for the feedback. We wanted to experiment with the xrate/xincrease functions which have been discussed extensively in this issue: https://github.com/prometheus/prometheus/issues/3806.
There are several forks out there that already add support for these functions, but I don't think Prometheus has made a decision yet on whether they make sense in prometheus/prometheus.

In my opinion, we should move forward with implementing them in Prometheus behind a feature flag.  Since the design document has stalled, with Alin commenting last, this is definitely something worth implementing and discussing upstream.

Thanks for the feedback, and I am glad that Prometheus is willing to consider adding these functions under a feature flag.
I will close this PR now and we will try to get ourselves unblocked in the short term. Maybe it's worth starting a discussion on this topic during a dev summit?

It is possible to add fonctions at compile time. Some users do it already.
Functions is public for that reason. But you can't change per engine if you
have multiple engines running.
Le lun. 27 mars 2023, 15:44, Björn Rabenstein @.***> a
écrit :

Personally, I'm still not convinced adding xrate and friends to standard
PromQL is a net gain for the community.
However, coming from a very different angle, I am pretty convinced that we
need to offer some way of injecting non-standard functions or
aggregators into PromQL. This is mostly coming from the many discussions we
had about adding specific statistical functions. There are just so many of
them that we cannot simply add all, and it's really hard to make the call
which ones are generally useful enough to make them "built-ins". We had
discussed this at a dev-summit, and even contemplated adding some kind of
scripting interface (embedded Lua, Python, R? 🤯 ), but maybe it has to
be a simple way of adding functions at compile time. In any case, once
there is a way of "loading custom libraries of PromQL functions", it would
also be a way to offer something like xrate as a custom thing while still
clearly communicating that it is not a standard "built-in" function yet.
—
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/pull/12170#issuecomment-1485123136,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACHHJUPFSCKBGF62EI24RTW6GKTJANCNFSM6AAAAAAWDQ7G5M
.
You are receiving this because your review was requested.Message ID:
@.***>

Thanks for your contribution, we have decided during our bug scrub to enable this change.

Thank you, much appreciated !


Make logging depend on DEBUG setting instead of always being in debug mode.

Can you make it so that LOG_LEVEL can be set in the Helm chart and have that value trickle down to the container? That way other log levels can be set instead of just info and debug. Unsure if that DEBUG variable does anything else other than set the log level. It might not be needed, but if it does do something else maybe if DEBUG is set to true then it can override whatever value is set for LOG_LEVEL.

Done :)

Ah wait, missed something. I'll fix it real quick.

Done. It should be good to go now @pj-linebaugh


Improvements to test suite

Address various async issues in unit tests
Add a suite of unit tests for insert above/below/left/right functions

I've adopted a slightly different approach than I suggested in #130 in that I've modified saveFile() to accept an optional callback function (and then passed the test assertions in as callbacks) instead of firing an event. I think this is a nicer solution than chucking events around. I've also spotted some other similar async issues which might cause problems and guarded against those as well.
This hopefully fixes issue #130, but its a bit difficult to tell given the failures can't be reliably reproduced.

Awesome. I've restarted the build a few times now, and this seems to have sorted it 👍


Fix publishing configuration, closes #858

Description
This introduces some changes to our publishing configuration such that we release from main instead of release/* branches
I'm opening this as a WIP Draft PR because this relies on: https://github.com/MetaMask/action-publish-release/pull/46 and a release of it.
(that's been addressed now and this is fully ready)
I've created a script for prepack that can be skipped in CI via SKIP_PREPACK environment variable. this is because we don't want a new build in CI prior to publish, we just want to pick up the cache from the previous build. I still needed to cache node_modules and yarn.lock because yarn now complains about the state file and it'll halt you from running any yarn scripts if that's not in order (even if we're not using those files for the actual deployment). I'm also not happy about the early exit code I've added here. Ideally, I'd like to see if the version has incremented in the filter and then skip if it hasn't, but I don't believe that's possible

FIXED:

#858

Issue
Resolves #858

I've tested this all out in my fork and it's correctly skipping for regular pushes:

And releasing when appropriate (after a release PR is merged and pushed to main):


Bug!!! shopping-cart-java not working for maven

When running mvn lagom:runAll instead of 'sbt runAll' (after following the other necessary instructions in the readme) the project starts successfully but the curl commands do not work. That is when running any of the curl commands I get an error. The error is:
<!DOCTYPE html>

        ...

Action Not Found

            For request 'GET /shoppingcart/123'

                    These routes have been tried, in this order:

Hi @CianSteenkamp96 , thanks for reporting this.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] shopping-cart-java                                                 [pom]
[INFO] shopping-cart-api                                                  [jar]
[INFO] shopping-cart                                                      [jar]
[INFO] inventory-api                                                      [jar]
[INFO] inventory                                                          [jar]
[INFO]
[INFO] -------------------< com.example:shopping-cart-java >-------------------
[INFO] Building shopping-cart-java 1.0-SNAPSHOT                           [1/5]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- lagom-maven-plugin:1.5.1:runAll (default-cli) @ shopping-cart-java ---
[INFO] Starting Kafka
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
2019-05-24T07:45:04.124Z [info] akka.event.slf4j.Slf4jLogger [] - Slf4jLogger started
2019-05-24T07:45:06.312Z [warn] akka.actor.ActorSystemImpl [sourceThread=main, akkaSource=akka.actor.ActorSystemImpl(application), sourceActorSystem=application, akkaTimestamp=07:45:06.310UTC] - Detected that Hostname Verification is disabled globally (via ssl-config's akka.ssl-config.loose.disableHostnameVerification) for the Http extension! This is very dangerous and may expose you to man-in-the-middle attacks. If you are forced to interact with a server that is behaving such that you must disable this setting, please disable it for a given connection instead, by configuring a specific HttpsConnectionContext for use only for the trusted target that hostname verification would have blocked.
2019-05-24T07:45:07.546Z [info] com.lightbend.lagom.registry.impl.ServiceLocatorServer [] - Service locator can be reached at <IP_ADDRESS>
2019-05-24T07:45:07.546Z [info] com.lightbend.lagom.registry.impl.ServiceLocatorServer [] - Service gateway can be reached at <IP_ADDRESS>
[INFO] Service locator is running at http://<IP_ADDRESS>:9008
[INFO] Service gateway is running at http://<IP_ADDRESS>:9000
09:45:10.274 [info] play.core.server.AkkaHttpServer [] - Listening for HTTP on /<IP_ADDRESS>:49696
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/ignasi/git/projects/lightbend/lagom/lagom-samples/shopping-cart/shopping-cart-java/shopping-cart-api/src/main/resources
[INFO] Nothing to compile - all classes are up to date
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Nothing to compile - all classes are up to date
09:45:13.550 [info] akka.event.slf4j.Slf4jLogger [] - Slf4jLogger started
09:45:13.595 [info] akka.remote.Remoting [sourceThread=main, akkaSource=akka.remote.Remoting, sourceActorSystem=shopping-cart-application, akkaTimestamp=07:45:13.593UTC] - Starting remoting
09:45:13.789 [info] akka.remote.Remoting [sourceThread=main, akkaTimestamp=07:45:13.789UTC, akkaSource=akka.remote.Remoting, sourceActorSystem=shopping-cart-application] - Remoting started; listening on addresses :[akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613]
09:45:13.793 [info] akka.remote.Remoting [sourceThread=main, akkaTimestamp=07:45:13.792UTC, akkaSource=akka.remote.Remoting, sourceActorSystem=shopping-cart-application] - Remoting now listens on addresses: [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613]
09:45:13.819 [info] akka.cluster.Cluster(akka://shopping-cart-application) [sourceThread=main, akkaTimestamp=07:45:13.819UTC, akkaSource=akka.cluster.Cluster(akka://shopping-cart-application), sourceActorSystem=shopping-cart-application] - Cluster Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] - Starting up, Akka version [2.5.22] ...
09:45:13.945 [info] akka.cluster.Cluster(akka://shopping-cart-application) [sourceThread=main, akkaTimestamp=07:45:13.945UTC, akkaSource=akka.cluster.Cluster(akka://shopping-cart-application), sourceActorSystem=shopping-cart-application] - Cluster Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] - Registered cluster JMX MBean [akka:type=Cluster,port=58613]
09:45:13.946 [info] akka.cluster.Cluster(akka://shopping-cart-application) [sourceThread=main, akkaTimestamp=07:45:13.945UTC, akkaSource=akka.cluster.Cluster(akka://shopping-cart-application), sourceActorSystem=shopping-cart-application] - Cluster Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] - Started up successfully
09:45:13.973 [info] akka.cluster.Cluster(akka://shopping-cart-application) [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-2, akkaSource=akka.cluster.Cluster(akka://shopping-cart-application), sourceActorSystem=shopping-cart-application, akkaTimestamp=07:45:13.973UTC] - Cluster Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] - No seed-nodes configured, manual cluster join required, see https://doc.akka.io/docs/akka/current/cluster-usage.html#joining-to-seed-nodes
09:45:14.586 [info] play.api.db.DefaultDBApi [] - Database [default] initialized at jdbc:postgresql://localhost/shopping_cart
09:45:14.597 [info] application [] - Creating Pool for datasource 'default'
09:45:14.608 [info] com.zaxxer.hikari.HikariDataSource [] - HikariPool-1 - Starting...
09:45:14.622 [info] com.zaxxer.hikari.HikariDataSource [] - HikariPool-1 - Start completed.
09:45:14.634 [info] play.api.db.HikariCPConnectionPool [] - datasource [default] bound to JNDI as DefaultDS
09:45:15.405 [info] akka.cluster.Cluster(akka://shopping-cart-application) [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-5, akkaSource=akka.cluster.Cluster(akka://shopping-cart-application), sourceActorSystem=shopping-cart-application, akkaTimestamp=07:45:15.404UTC] - Cluster Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] - Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] is JOINING itself (with roles [dc-default]) and forming new cluster
09:45:15.413 [info] akka.cluster.Cluster(akka://shopping-cart-application) [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-5, akkaTimestamp=07:45:15.411UTC, akkaSource=akka.cluster.Cluster(akka://shopping-cart-application), sourceActorSystem=shopping-cart-application] - Cluster Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] - is the new leader among reachable nodes (more leaders may exist)
09:45:15.426 [info] akka.cluster.Cluster(akka://shopping-cart-application) [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-5, akkaSource=akka.cluster.Cluster(akka://shopping-cart-application), sourceActorSystem=shopping-cart-application, akkaTimestamp=07:45:15.425UTC] - Cluster Node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] - Leader is moving node [akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613] to [Up]
09:45:15.499 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-2, akkaTimestamp=07:45:15.499UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/system/sharding/ShoppingCartEntityCoordinator, sourceActorSystem=shopping-cart-application] - Singleton manager starting singleton actor [akka://shopping-cart-application/system/sharding/ShoppingCartEntityCoordinator/singleton]
09:45:15.513 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-2, akkaTimestamp=07:45:15.513UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/system/sharding/ShoppingCartEntityCoordinator, sourceActorSystem=shopping-cart-application] - ClusterSingletonManager state change [Start -> Oldest]
09:45:15.520 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-15, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/jdbcCreateTables-singleton, sourceActorSystem=shopping-cart-application, akkaTimestamp=07:45:15.520UTC] - Singleton manager starting singleton actor [akka://shopping-cart-application/user/jdbcCreateTables-singleton/singleton]
09:45:15.521 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-15, akkaTimestamp=07:45:15.520UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/jdbcCreateTables-singleton, sourceActorSystem=shopping-cart-application] - ClusterSingletonManager state change [Start -> Oldest]
09:45:15.549 [info] com.lightbend.lagom.internal.persistence.cluster.ClusterStartupTaskActor [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-15, akkaTimestamp=07:45:15.548UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/jdbcCreateTables-singleton/singleton/jdbcCreateTables, sourceActorSystem=shopping-cart-application] - Executing cluster start task jdbcCreateTables.
09:45:15.556 [info] akka.cluster.sharding.DDataShardCoordinator [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-18, akkaTimestamp=07:45:15.556UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/system/sharding/ShoppingCartEntityCoordinator/singleton/coordinator, sourceActorSystem=shopping-cart-application] - ShardCoordinator was moved to the active state State(Map(),Map(),Set(),Set(),false)
09:45:15.642 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-4, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/slickOffsetStorePrepare-singleton, sourceActorSystem=shopping-cart-application, akkaTimestamp=07:45:15.642UTC] - Singleton manager starting singleton actor [akka://shopping-cart-application/user/slickOffsetStorePrepare-singleton/singleton]
09:45:15.643 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-4, akkaTimestamp=07:45:15.642UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/slickOffsetStorePrepare-singleton, sourceActorSystem=shopping-cart-application] - ClusterSingletonManager state change [Start -> Oldest]
09:45:15.643 [info] com.lightbend.lagom.internal.persistence.cluster.ClusterStartupTaskActor [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-16, akkaTimestamp=07:45:15.642UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/slickOffsetStorePrepare-singleton/singleton/slickOffsetStorePrepare, sourceActorSystem=shopping-cart-application] - Executing cluster start task slickOffsetStorePrepare.
09:45:15.717 [info] com.lightbend.lagom.internal.persistence.cluster.ClusterStartupTaskActor [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-16, akkaTimestamp=07:45:15.716UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/slickOffsetStorePrepare-singleton/singleton/slickOffsetStorePrepare, sourceActorSystem=shopping-cart-application] - Cluster start task slickOffsetStorePrepare done.
09:45:15.737 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-17, akkaTimestamp=07:45:15.737UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/system/sharding/kafkaProducer-shopping-cartCoordinator, sourceActorSystem=shopping-cart-application] - Singleton manager starting singleton actor [akka://shopping-cart-application/system/sharding/kafkaProducer-shopping-cartCoordinator/singleton]
09:45:15.738 [info] akka.cluster.singleton.ClusterSingletonManager [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-17, akkaTimestamp=07:45:15.737UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/system/sharding/kafkaProducer-shopping-cartCoordinator, sourceActorSystem=shopping-cart-application] - ClusterSingletonManager state change [Start -> Oldest]
09:45:15.738 [info] akka.cluster.sharding.DDataShardCoordinator [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-17, akkaTimestamp=07:45:15.737UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/system/sharding/kafkaProducer-shopping-cartCoordinator/singleton/coordinator, sourceActorSystem=shopping-cart-application] - ShardCoordinator was moved to the active state State(Map(),Map(),Set(),Set(),false)
09:45:15.782 [info] com.lightbend.lagom.internal.persistence.cluster.ClusterStartupTaskActor [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-4, akkaTimestamp=07:45:15.782UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/jdbcCreateTables-singleton/singleton/jdbcCreateTables, sourceActorSystem=shopping-cart-application] - Cluster start task jdbcCreateTables done.
09:45:15.866 [info] play.api.http.EnabledFilters [] - Enabled Filters (see <https://www.playframework.com/documentation/latest/Filters>):

09:45:15.977 [info] play.api.Play [] - Application started (Dev) (no global state)
09:45:16.466 [info] akka.cluster.singleton.ClusterSingletonProxy [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-18, akkaTimestamp=07:45:16.466UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/jdbcCreateTables-singletonProxy, sourceActorSystem=shopping-cart-application] - Singleton identified at [akka://shopping-cart-application/user/jdbcCreateTables-singleton/singleton]
09:45:16.648 [info] akka.cluster.singleton.ClusterSingletonProxy [sourceThread=shopping-cart-application-akka.actor.default-dispatcher-15, akkaTimestamp=07:45:16.647UTC, akkaSource=akka.tcp://shopping-cart-application@<IP_ADDRESS>:58613/user/slickOffsetStorePrepare-singletonProxy, sourceActorSystem=shopping-cart-application] - Singleton identified at [akka://shopping-cart-application/user/slickOffsetStorePrepare-singleton/singleton]
09:45:18.203 [info] play.core.server.AkkaHttpServer [] - Listening for HTTP on /<IP_ADDRESS>:56768
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/ignasi/git/projects/lightbend/lagom/lagom-samples/shopping-cart/shopping-cart-java/shopping-cart-api/src/main/resources
[INFO] Nothing to compile - all classes are up to date
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/ignasi/git/projects/lightbend/lagom/lagom-samples/shopping-cart/shopping-cart-java/inventory-api/src/main/resources
[INFO] Nothing to compile - all classes are up to date
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Nothing to compile - all classes are up to date
09:45:20.321 [info] akka.event.slf4j.Slf4jLogger [] - Slf4jLogger started
09:45:21.221 [info] play.api.http.EnabledFilters [] - Enabled Filters (see <https://www.playframework.com/documentation/latest/Filters>):

09:45:21.268 [info] play.api.Play [] - Application started (Dev) (no global state)
[INFO] Service shopping-cart listening for HTTP on <IP_ADDRESS>:49696
[INFO] Service inventory listening for HTTP on <IP_ADDRESS>:56768
[INFO] (Services started, press enter to stop and go back to the console...)
09:45:22.029 [warn] org.apache.kafka.clients.NetworkClient [] - [Consumer clientId=inventory-1, groupId=inventory] Error while fetching metadata with correlation id 2 : {shopping-cart=LEADER_NOT_AVAILABLE}

Moreover, we are testing it against an OpenShift cluster each time code is merged. So it's known to work.
@CianSteenkamp96, please check your environment. There must be something locally.

@renatocaval Thank you for the quick response. Here is what is shown on my side when running mvn lagom:runAll
/shopping-cart/shopping-cart-java$ docker-compose up -d
shopping_cart_postgres is up-to-date
/shopping-cart/shopping-cart-java$ mvn lagom:runAll
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] shopping-cart-java                                                 [pom]
[INFO] shopping-cart-api                                                  [jar]
[INFO] shopping-cart                                                      [jar]
[INFO] inventory-api                                                      [jar]
[INFO] inventory                                                          [jar]
[INFO]
[INFO] -------------------< com.example:shopping-cart-java >-------------------
[INFO] Building shopping-cart-java 1.0-SNAPSHOT                           [1/5]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- lagom-maven-plugin:1.5.1:runAll (default-cli) @ shopping-cart-java ---
[INFO] Starting Kafka
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
2019-05-24T09:03:12.872Z [info] akka.event.slf4j.Slf4jLogger [] - Slf4jLogger started
2019-05-24T09:03:14.300Z [warn] akka.actor.ActorSystemImpl [sourceThread=main, akkaSource=akka.actor.ActorSystemImpl(application), sourceActorSystem=application, akkaTimestamp=09:03:14.299UTC] - Detected that Hostname Verification is disabled globally (via ssl-config's akka.ssl-config.loose.disableHostnameVerification) for the Http extension! This is very dangerous and may expose you to man-in-the-middle attacks. If you are forced to interact with a server that is behaving such that you must disable this setting, please disable it for a given connection instead, by configuring a specific HttpsConnectionContext for use only for the trusted target that hostname verification would have blocked.
2019-05-24T09:03:14.699Z [info] com.lightbend.lagom.registry.impl.ServiceLocatorServer [] - Service locator can be reached at <IP_ADDRESS>
2019-05-24T09:03:14.700Z [info] com.lightbend.lagom.registry.impl.ServiceLocatorServer [] - Service gateway can be reached at <IP_ADDRESS>
[INFO] Service locator is running at http://<IP_ADDRESS>:9008
[INFO] Service gateway is running at http://<IP_ADDRESS>:9000
[WARN] [05/24/2019 11:03:15.876] [main] [ManifestInfo(akka://shopping-cart-internal-dev-mode)] Detected possible incompatible versions on the classpath. Please note that a given Akka HTTP version MUST be the same across all modules of Akka HTTP that you are using, e.g. if you use [10.1.8] all other modules that are released together MUST be of the same version. Make sure you're using a compatible set of libraries. Possibly conflicting versions [10.1.8, 10.1.7] in libraries [akka-http-spray-json:10.1.8, akka-parsing:10.1.7, akka-http:10.1.8, akka-http-core:10.1.7]
11:03:16.228 [info] play.core.server.AkkaHttpServer [] - Listening for HTTP on /<IP_ADDRESS>:49696
[WARN] [05/24/2019 11:03:17.357] [main] [ManifestInfo(akka://inventory-internal-dev-mode)] Detected possible incompatible versions on the classpath. Please note that a given Akka HTTP version MUST be the same across all modules of Akka HTTP that you are using, e.g. if you use [10.1.8] all other modules that are released together MUST be of the same version. Make sure you're using a compatible set of libraries. Possibly conflicting versions [10.1.8, 10.1.7] in libraries [akka-http-spray-json:10.1.8, akka-parsing:10.1.7, akka-http:10.1.8, akka-http-core:10.1.7]
11:03:17.698 [info] play.core.server.AkkaHttpServer [] - Listening for HTTP on /<IP_ADDRESS>:56768
[INFO] Service shopping-cart listening for HTTP on <IP_ADDRESS>:49696
[INFO] Service inventory listening for HTTP on <IP_ADDRESS>:56768
[INFO] (Services started, press enter to stop and go back to the console...)

Any idea what can be missing on my side? I followed the readme exactly. As mentioned I only get the error once executing a curl command such as curl http://localhost:9000/shoppingcart/123.

If you prefer to continue this discussion via email here is my email address<EMAIL_ADDRESS>

Hi @CianSteenkamp96, the output you shared is suspiciously short (see the output I shared).
What versions of java and maven are you using?
$ java -version
openjdk version "1.8.0_202"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
ignasi at imslightbend in ~/git/personal/apache
$ mvn --version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)
Maven home: /usr/local/Cellar/maven/3.6.0/libexec
Java version: 1.8.0_202, vendor: AdoptOpenJdk, runtime: /Library/Java/JavaVirtualMachines/jdk8u202-b08_hotspot/Contents/Home/jre
Default locale: en_ES, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"

@CianSteenkamp96, better not to switch to email because others facing the same issue can learn how to solve it.

Moreover, we are testing it against an OpenShift cluster each time code is merged. So it's known to work.

@renatocaval the CI jobs in travis don't exercise the dev mode of the samples.

cian@cian:~$ java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
cian@cian:~$ mvn --version
Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 1.8.0_201, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_ZA, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-50-generic", arch: "amd64", family: "unix"

@CianSteenkamp96 I've updated the subject to better detail the issue.

@ignasi35 thank you. See my maven and java version above. It's the same. I agree, my output is much shorter than yours..

@CianSteenkamp96, better not to switch to email because others facing the same issue can learn how to solve it.

Sure thing.

@CianSteenkamp96 do you have some global maven plugin that may be interfering?
Do you have access to a pristine environment where you can retest?

@ignasi35 I do have a settings.xml file in my ~/.m2 folder which I added/created - after removing it, I still have the same problem when running mvn clean lagom:runAll. Also, in /etc/maven there is also a settings.xml file (as referred to in the link in your previous message) but I did not create this file nor did I change anything inside it and most of it is commented out. Even after removing this file, as well, I still have the same issue.
Also, I do not have access to a pristine environment.
Thanks for your support thus far.

@ignasi35 I also made sure that I don't have my local postgresql service running before starting the docker container.

@ignasi35 and @renatocaval I deleted and recloned the git repo. Everything seems to be working now. I apologize for wasting your time. Also, just for clarity, it works even with my settings.xml file in ~/.m2 and the default settings.xml file in /etc/maven. Thanks for the help. I don't know what changed from before since I am 99% sure I did not change anything after downloading/cloning the git initially.

I will let you know if I find what caused my error initially so others don't make the same mistake.


feat: Golang guest language bindings

WIP: Going to add support go Golang guest code and add the observe API functions into the Go SDK.

Closing in favor of https://github.com/dylibso/observe-sdk/pull/160, which is based on this PR.


Support running without the --hf-token parameter and using ~/.cache/huggingface/token instead

Sharing the model cache with Python's Huggingface Transformers including the ~/.cache/huggingface/token file would be nice, it makes it a bit easier to run, and in some cases is a bit more flexible to have a file with the secret instead of an environment variable.
Currently running without the --hf-token parameter it crashes:
root@a07c64fd168b:~# RUST_BACKTRACE=full /root/.cargo/bin/candle-vllm --port 8080 llama7b --repeat-last-n 4096
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/openai/pipelines/llama.rs:93:52
stack backtrace:
   0:     0x55d28053b680 - std::backtrace_rs::backtrace::libunwind::trace::hc74d68e4e9860fea
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55d28053b680 - std::backtrace_rs::backtrace::trace_unsynchronized::hf8e4c2f2a5bd29df
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55d28053b680 - std::sys_common::backtrace::_print_fmt::h4f6fe0d2839f79bc
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/sys_common/backtrace.rs:65:5
   3:     0x55d28053b680 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd19378c79598340a
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x55d28059415f - core::fmt::rt::Argument::fmt::h59bd005c578b819c
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/core/src/fmt/rt.rs:138:9
   5:     0x55d28059415f - core::fmt::write::hc6d0fea41b7d9e9f
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/core/src/fmt/mod.rs:1094:21
   6:     0x55d28057ac09 - std::io::Write::write_fmt::haa7b0f41639b47d7
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/io/mod.rs:1714:15
   7:     0x55d28053b485 - std::sys_common::backtrace::_print::h5d490a94ac60fe6f
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x55d28053b485 - std::sys_common::backtrace::print::hbaa9c19cd32d8c11
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x55d280562b41 - std::panicking::default_hook::{{closure}}::h8910079f61b67bae
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:269:22
  10:     0x55d2805627df - std::panicking::default_hook::h7edb9fd7f54e7e29
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:288:9
  11:     0x55d280562fe9 - std::panicking::rust_panic_with_hook::h21aae3dc3ef5bbce
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:705:13
  12:     0x55d28053b921 - std::panicking::begin_panic_handler::{{closure}}::ha72f1c35114340ed
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:595:13
  13:     0x55d28053b756 - std::sys_common::backtrace::__rust_end_short_backtrace::h4b9d50b70e928d76
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/sys_common/backtrace.rs:151:18
  14:     0x55d280562d12 - rust_begin_unwind
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:593:5
  15:     0x55d27fd42e73 - core::panicking::panic_fmt::h1f248589eaa015cb
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/core/src/panicking.rs:67:14
  16:     0x55d27fd42f03 - core::panicking::panic::ha7576b296f353a40
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/core/src/panicking.rs:117:5
  17:     0x55d27fe64d05 - <candle_vllm::openai::pipelines::llama::LlamaLoader as candle_vllm::openai::pipelines::ModelLoader>::download_model::h35852d7688395361
  18:     0x55d27fdd2772 - <tokio::task::local::RunUntil<T> as core::future::future::Future>::poll::h840672626d529183
  19:     0x55d27fdba6d5 - <core::pin::Pin<P> as core::future::future::Future>::poll::hada91331ad8af9c6
  20:     0x55d27fd6847e - tokio::runtime::scheduler::current_thread::Context::enter::hcadae44c6bd4a972
  21:     0x55d27fdba3fc - tokio::runtime::context::scoped::Scoped<T>::set::h8c46da17f5738f19
  22:     0x55d27fda2d8d - tokio::runtime::context::set_scheduler::h3ae1db3c76e6eddd
  23:     0x55d27fd68886 - tokio::runtime::scheduler::current_thread::CoreGuard::block_on::h9087bc7e3b6248ad
  24:     0x55d27fd5acdd - tokio::runtime::context::runtime::enter_runtime::h83b56f50d8f9f15a
  25:     0x55d27fdc1ca4 - tokio::runtime::runtime::Runtime::block_on::h1be1cae2d7092a47
  26:     0x55d27fdeda2f - candle_vllm::main::h75bc07d9ebcc7535
  27:     0x55d27fd9fcef - std::sys_common::backtrace::__rust_begin_short_backtrace::hf956e45bfe2dcf62
  28:     0x55d27fd9fd22 - std::rt::lang_start::{{closure}}::hf05d036a2c013dd7
  29:     0x55d280554d97 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h04bbe96bde0bc897
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/core/src/ops/function.rs:284:13
  30:     0x55d280554d97 - std::panicking::try::do_call::he78cea8c5c5e38dc
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:500:40
  31:     0x55d280554d97 - std::panicking::try::h90115c76987a2911
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:464:19
  32:     0x55d280554d97 - std::panic::catch_unwind::hf9383826be3f5d9b
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panic.rs:142:14
  33:     0x55d280554d97 - std::rt::lang_start_internal::{{closure}}::h9558c46bab60ed0d
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/rt.rs:148:48
  34:     0x55d280554d97 - std::panicking::try::do_call::hc9c637fb9cb529b5
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:500:40
  35:     0x55d280554d97 - std::panicking::try::hdc72401b46fd9b08
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panicking.rs:464:19
  36:     0x55d280554d97 - std::panic::catch_unwind::hedb40674d8218c74
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/panic.rs:142:14
  37:     0x55d280554d97 - std::rt::lang_start_internal::h4c2f75864f09731e
                               at /build/rustc-N04w3E/rustc-1.72.1+dfsg0ubuntu1~bpo0/library/std/src/rt.rs:148:20
  38:     0x55d27fdeda95 - main
  39:     0x7f6377001d90 - <unknown>
  40:     0x7f6377001e40 - __libc_start_main
  41:     0x55d27fd4ec65 - _start
  42:                0x0 - <unknown>

@ivanbaldo this seems like a great idea. I just pushed a commit which adds this feature. Could you try it?

Is inference running? It should not work as PagedAttention is not implemented and everything is in flux.

It will work while it is doing the prompt.

I didn't test inference yet, since I have some other unrelated work to do first.
But since you are very helpful I decided to help you as much as I can and I am mixing both tasks hehe.
I can quickly launch an EC2 server with an Nvidia A10 24G VRAM that I use to run Podman containers with the CDI interface to access the GPU and run inference on it.
Been using that to run benchmarks of inferencers.
In the near future I am planning to benchmark on 2xA100 80G VRAM each to run Llama-2 70b without quantization and Mixtral 8x7b.
If by chance this project works in that setup then I can add it to the benchmarks, I am planning to do presentations of this.
Thanks!!!

Sounds exciting. Do you have a rough timeline in mind?

I hope to finish the benchmarks the 19th of February, but hoping to start benchmarking on the 2xA100 next week.

All the benchmarks are in this branch of this fork https://github.com/ivanbaldo/llama-inference/tree/ibaldoall .

It didn't work, this is the error:
3766.0 error[E0425]: cannot find value `var` in this scope
3766.0   --> src/openai/pipelines/mod.rs:75:51
3766.0    |
3766.0 75 |         (Some(envvar), None) => try_api!(env::var(var)),
3766.0    |                                                   ^^^ not found in this scope
3766.0    |
3766.0 help: consider importing one of these items
3766.0    |
3766.0 1  + use crate::openai::pipelines::env::var;
3766.0    |
3766.0 1  + use std::env::var;
3766.0    |
3766.0
3766.0 error[E0433]: failed to resolve: use of undeclared crate or module `fs`
3766.0   --> src/openai/pipelines/mod.rs:76:40
3766.0    |
3766.0 76 |         (None, Some(path)) => try_api!(fs::read_to_string(path)),
3766.0    |                                        ^^ use of undeclared crate or module `fs`
3766.0    |
3766.0 help: consider importing one of these items
3766.0    |
3766.0 1  + use std::fs;
3766.0    |
3766.0 1  + use tokio::fs;
3766.0    |
3766.0
3766.0 warning: unused imports: `env`, `fs`
3766.0  --> src/openai/pipelines/llama.rs:1:11
3766.0   |
3766.0 1 | use std::{env, fs, iter::zip, path::PathBuf, sync::Arc};
3766.0   |           ^^^  ^^
3766.0   |
3766.0   = note: `#[warn(unused_imports)]` on by default
3766.0
3767.3 Some errors have detailed explanations: E0425, E0433.
3767.3 For more information about an error, try `rustc --explain E0425`.
3767.3 warning: `candle-vllm` (lib) generated 1 warning
3767.3 error: could not compile `candle-vllm` (lib) due to 2 previous errors; 1 warning emitted

I have pushed some changes since, could you try it again?

Now this:
error[E0061]: this function takes 2 arguments but 1 argument was supplied
   --> /root/.cargo/git/checkouts/candle-lora-e71fb47097131b72/7fed136/candle-lora-transformers/src/varbuilder_utils.rs:98:23
    |
98  |         let tensors = candle_core::pickle::PthTensors::new(path)?;
    |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^------ an argument of type `std::option::Option<&str>` is missing
    |
note: associated function defined here
   --> /root/.cargo/git/checkouts/candle-0c2b4fa9e5801351/b75e894/candle-core/src/pickle.rs:715:12
    |
715 |     pub fn new<P: AsRef<std::path::Path>>(path: P, key: Option<&str>) -> Result<Self> {
    |            ^^^
help: provide the argument
    |
98  |         let tensors = candle_core::pickle::PthTensors::new(path, /* std::option::Option<&str> */)?;
    |                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For more information about this error, try `rustc --explain E0061`.
error: could not compile `candle-lora-transformers` (lib) due to previous error

Very interesting. That API change from candle must have come out just in time to break your compilation. I just pushed a fix to candle-lora, could you try it again? It should compile now.

Hi, sorry Eric, had a busy morning!
It compiles although there are some warnings that you may like to get a look to:
warning: unused variable: `src_dev`
   --> src/backend/cache.rs:317:23
    |
317 |         (Device::Cuda(src_dev), Device::Cpu) => {
    |                       ^^^^^^^ help: if this is intentional, prefix it with an underscore: `_src_dev`
    |
    = note: `#[warn(unused_variables)]` on by default

warning: unused variable: `num_seqs`
  --> src/backend/paged_attention.rs:26:9
   |
26 |     let num_seqs = query.shape().dims()[0];
   |         ^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_num_seqs`

warning: unused variable: `num_heads`
  --> src/backend/paged_attention.rs:27:9
   |
27 |     let num_heads = query.shape().dims()[1];
   |         ^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_num_heads`

warning: unused variable: `max_num_blocks_per_seq`
  --> src/backend/paged_attention.rs:29:9
   |
29 |     let max_num_blocks_per_seq = block_tables.shape().dims()[1];
   |         ^^^^^^^^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_max_num_blocks_per_seq`

warning: unused variable: `q_stride`
  --> src/backend/paged_attention.rs:30:9
   |
30 |     let q_stride = query.stride()[0];
   |         ^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_q_stride`

warning: unused variable: `kv_block_stride`
  --> src/backend/paged_attention.rs:31:9
   |
31 |     let kv_block_stride = key_cache.stride()[0];
   |         ^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_kv_block_stride`

warning: unused variable: `kv_head_stride`
  --> src/backend/paged_attention.rs:32:9
   |
32 |     let kv_head_stride = key_cache.stride()[1];
   |         ^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_kv_head_stride`

warning: unused variable: `value_cache`
  --> src/backend/paged_attention.rs:15:5
   |
15 |     value_cache: Tensor,      // [num_blocks, num_heads, head_size, block_size]
   |     ^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_value_cache`

warning: unused variable: `num_key_value_heads`
  --> src/backend/paged_attention.rs:16:5
   |
16 |     num_key_value_heads: i32, // [num_heads]
   |     ^^^^^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_num_key_value_heads`

warning: unused variable: `scale`
  --> src/backend/paged_attention.rs:17:5
   |
17 |     scale: f32,
   |     ^^^^^ help: if this is intentional, prefix it with an underscore: `_scale`

warning: unused variable: `context_lens`
  --> src/backend/paged_attention.rs:19:5
   |
19 |     context_lens: Tensor, // [num_seqs]
   |     ^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_context_lens`

warning: unused variable: `max_context_len`
  --> src/backend/paged_attention.rs:21:5
   |
21 |     max_context_len: usize,
   |     ^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_max_context_len`

warning: unused variable: `alibi_slopes`
  --> src/backend/paged_attention.rs:22:5
   |
22 |     alibi_slopes: Option<Tensor>,
   |     ^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_alibi_slopes`

warning: unused variable: `dtype`
  --> src/backend/paged_attention.rs:23:5
   |
23 |     dtype: DType,
   |     ^^^^^ help: if this is intentional, prefix it with an underscore: `_dtype`

warning: unused variable: `is_fp8_e5m2_kv_cache`
  --> src/backend/paged_attention.rs:24:5
   |
24 |     is_fp8_e5m2_kv_cache: bool,
   |     ^^^^^^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_is_fp8_e5m2_kv_cache`

warning: function `set_max_dynamic_shared_memory_size` is never used
 --> src/backend/paged_attention.rs:5:4
  |
5 | fn set_max_dynamic_shared_memory_size(_func: CudaFunction, _size: usize) {
  |    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: `candle-vllm` (lib) generated 16 warnings (run `cargo fix --lib -p candle-vllm` to apply 15 suggestions)

Great, this is as expected. Those warnings are due to the development state as I am waiting for coreylowman/cudarc#203, huggingface/candle#1467 and huggingface/candle#1412 to move forward.

Sorry but we should re-open the issue, since it doesn't seem to work (or maybe I am doing something wrong of course):
root@4be76ca848a1:/candle-vllm# /root/.cargo/bin/candle-vllm --port 8080 llama7b --repeat-last-n 4096
Error: APIError { data: "request error: https://huggingface.co/meta-llama/Llama-2-7b-chat-hf/resolve/main/tokenizer.json: status code 401" }

root@4be76ca848a1:/candle-vllm# cat ~/.cache/huggingface/token
hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Specifying the path works though:
root@4be76ca848a1:/candle-vllm# /root/.cargo/bin/candle-vllm --port 8080 --hf-token-path ~/.cache/huggingface/token llama7b --repeat-last-n 4096

Ok, this should be fixed now.

Strangely, it doesn't work still:
root@4be76ca848a1:/candle-vllm# /root/.cargo/bin/candle-vllm --port 8080 llama7b --repeat-last-n 4096
Error: APIError { data: "No such file or directory (os error 2)" }

It seems that it's sending to the kernel the following syscall which of course the kernel will not interpret, since the ~ is a shell feature:
openat(AT_FDCWD, "~/.cache/huggingface/token", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

BTW the ~/.cache directory can be placed somewhere else, so the XDG mechanism should be followed to locate that directory, maybe Rust has a small and simple to use crate to do that lookup correctly and compliant with the XDG specification, maybe this one https://crates.io/crates/dirs .

I just pushed a commit which may fix this, could you try it again?

Failed with:
warning: unused import: `candle_core::cuda_backend::cudarc::driver::sys as cudarc_sys`
 --> src/backend/paged_attention.rs:3:5
  |
3 | use candle_core::cuda_backend::cudarc::driver::sys as cudarc_sys;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error[E0277]: `std::option::Option<PathBuf>` doesn't implement `std::fmt::Display`
  --> src/openai/pipelines/mod.rs:79:13
   |
79 |             dirs::home_dir()
   |             ^^^^^^^^^^^^^^^^ `std::option::Option<PathBuf>` cannot be formatted with the default formatter
   |
   = help: the trait `std::fmt::Display` is not implemented for `std::option::Option<PathBuf>`
   = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
   = note: this error originates in the macro `$crate::__export::format_args` which comes from the expansion of the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
warning: `candle-vllm` (lib) generated 1 warning
error: could not compile `candle-vllm` (lib) due to previous error; 1 warning emitted

Ok, the most recent commit should fix that.

Unfortunately not yet:
warning: unused import: `candle_core::cuda_backend::cudarc::driver::sys as cudarc_sys`
 --> src/backend/paged_attention.rs:3:5
  |
3 | use candle_core::cuda_backend::cudarc::driver::sys as cudarc_sys;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error[E0308]: mismatched types
  --> src/openai/responses.rs:36:13
   |
36 |             Ok(v) => v,
   |             ^^^^^ expected `Option<PathBuf>`, found `Result<_, _>`
   |
  ::: src/openai/pipelines/mod.rs:79:22
   |
79 |             try_api!(dirs::home_dir())
   |             --------------------------
   |             |        |
   |             |        this expression has type `std::option::Option<PathBuf>`
   |             in this macro invocation
   |
   = note: expected enum `std::option::Option<PathBuf>`
              found enum `Result<_, _>`
   = note: this error originates in the macro `try_api` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
  --> src/openai/responses.rs:37:13
   |
37 |             Err(e) => {
   |             ^^^^^^ expected `Option<PathBuf>`, found `Result<_, _>`
   |
  ::: src/openai/pipelines/mod.rs:79:22
   |
79 |             try_api!(dirs::home_dir())
   |             --------------------------
   |             |        |
   |             |        this expression has type `std::option::Option<PathBuf>`
   |             in this macro invocation
   |
   = note: expected enum `std::option::Option<PathBuf>`
              found enum `Result<_, _>`
   = note: this error originates in the macro `try_api` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0308`.
warning: `candle-vllm` (lib) generated 1 warning
error: could not compile `candle-vllm` (lib) due to 2 previous errors; 1 warning emitted

Ah, my macro is not for Option. Mantually mapping in this push should fix it hopefully?

Nope, not yet, heheh:
error[E0599]: no method named `map_err` found for enum `std::option::Option` in the current scope
  --> src/openai/pipelines/mod.rs:79:30
   |
79 |             dirs::home_dir().map_err(APIError::from)?
   |                              ^^^^^^^ help: there is a method with a similar name: `map_or`

For more information about this error, try `rustc --explain E0599`.

Ok, this should fix it.

Ouch it seems that it needs to recompile some other stuff now, so it will take like 40m (candle-flash-attn takes ages here):
   Compiling candle-kernels v0.4.0 (https://github.com/huggingface/candle.git#e5eb9602)
   Compiling candle-flash-attn v0.4.0 (https://github.com/huggingface/candle.git#e5eb9602)
   Compiling candle-core v0.4.0 (https://github.com/huggingface/candle.git#e5eb9602)
   Compiling candle-examples v0.4.0 (https://github.com/huggingface/candle.git#e5eb9602)
   Compiling candle-nn v0.4.0 (https://github.com/huggingface/candle.git#e5eb9602)
   Compiling candle-lora v0.2.0 (https://github.com/EricLBuehler/candle-lora.git#232d8bda)
   Compiling candle-lora-macro v0.2.0 (https://github.com/EricLBuehler/candle-lora.git#232d8bda)
   Compiling candle-datasets v0.4.0 (https://github.com/huggingface/candle.git#e5eb9602)
   Compiling candle-sampling v0.2.0 (https://github.com/EricLBuehler/candle-sampling.git#b33fba39)
    Building [=======================> ] 508/516: candle-flash-attn(build), candle-core

I tried to do that before, but the actions runner has no CUDA GPU. If you have any ideas that would be great, but if I will spin up another A10 soon to build.

But there's no need to have a GPU just to build, my laptop doesn't have a GPU actually.

On one hand, these tests could be handy and can easily added by commiting this file:
https://github.com/huggingface/candle/blob/main/.github/workflows/rust-ci.yml
And then maybe a job could be added similar to this:
  test-build:
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
      - name: Install Rust Stable
        run: curl https://sh.rustup.rs -sSf | sh -s -- -y
      - uses: Swatinem/rust-cache@v2
      - run: apt-get update -y && apt-get install -y libssl-dev pkg-config
      - uses<EMAIL_ADDRESS>        id: cuda-toolkit
        with:
          cuda: '12.2.2'
      - run: echo "Installed cuda version is: ${{steps.cuda-toolkit.outputs.cuda}}"
      - run: echo "Cuda install location: ${{steps.cuda-toolkit.outputs.CUDA_PATH}}"
      - run: CUDA_COMPUTE_CAP=86 /root/.cargo/bin/cargo build --features cuda,cudnn,flash-attn,nccl

I decided to not use that for now as when I tried it I had some trouble with building CUDA in the actions.

Maybe we can downgrade clap to 4.5.0?
To be able to use Rust from Ubuntu 22.04 instead of installing it directly from the web and having more moving parts (a good thing about distributions is having some things stable for some time).
error: failed to compile `candle-vllm v0.1.0 (/candle-vllm)`, intermediate artifacts can be found at `/candle-vllm/target`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Caused by:
  package `clap v4.5.0` cannot be built because it requires rustc 1.74 or newer, while the currently active rustc version is 1.72.1
  Either upgrade to rustc 1.74 or newer, or use
  cargo update -p<EMAIL_ADDRESS>--precise ver
  where `ver` is the latest version of `clap` supporting rustc 1.72.1

Actually the 4.4.18 version of clap which supports Rust 1.70.0 according to this https://crates.io/crates/clap/4.4.18 .

If I'm not mistaken, we use 4.4.7 and candle uses 4.2.4. I cannot find 4.5.0 in candle or candle-vllm, so I don't think we use are specifying it? Could you try to downgrade on your machine?

Tried to downgrade already but couldn't.
Also removed Cargo.lock just in case but didn't work neither.
I don't know anything about Rust but my suspicion anyway, is that some dependency declares a hard dependency on that recent Clap and not candle-vllm directly...
Is there any method to diagnose this crates dependencies?

Yes, that is likely true. Are you running on a different machine, or did something change that is causing it to stop compiling now?

I always use containers and when encountering this problem I destroyed the container and started a new one, to avoid any pollution etc.
Don't worry about this, I will just RUN curl https://sh.rustup.rs -sSf | sh -s -- -y && ln -s /root/.cargo/bin/* /usr/local/bin .
Compiling, results in an hour...

Ok, sorry that it takes so long!

Now it compiled correctly and got the token from the huggingface cache, excellent!!!
Thanks!

Great!


after exec autoformat cmd, scroll becomes not smooth.is there something wrong?

I haven't experienced this before. Can you reproduce with all other plugins disabled?

thanks, it seem to be caused by indentLine plugin.


HTTPDecoder may crash if added to multiple channels, deliberately or not.

Expected behavior
Not to produce an EXC_BAD_ACCESS
Actual behavior
NIO-ELT-#0 (2): EXC_BAD_ACCESS (code=1, address=0x20)

#0	0x0000000102cbf49e in swift_unknownRetain ()
#1	0x0000000101f8574a in evacuateChannelHandlerContext(_:) at swift-nio.git-6334843834720069654/Sources/NIOHTTP1/HTTPDecoder.swift:698
#2	0x0000000101f83a72 in evacuateHTTPDecoder(_:) at swift-nio.git-6334843834720069654/Sources/NIOHTTP1/HTTPDecoder.swift:702
#3	0x0000000101f8385b in closure #1 in HTTPDecoder.decoderAdded(ctx:) at swift-nio.git-6334843834720069654/Sources/NIOHTTP1/HTTPDecoder.swift:291
#4	0x0000000101f83b11 in @objc closure #1 in HTTPDecoder.decoderAdded(ctx:) ()
#5	0x0000000102090792 in c_nio_http_parser_execute at swift-nio.git-6334843834720069654/Sources/CNIOHTTPParser/c_nio_http_parser.c:777
#6	0x0000000101f8a49d in closure #1 in closure #1 in HTTPDecoder.decodeHTTP(ctx:) at swift-nio.git-6334843834720069654/Sources/NIOHTTP1/HTTPDecoder.swift:487
#7	0x0000000101f94a97 in partial apply for closure #1 in closure #1 in HTTPDecoder.decodeHTTP(ctx:) ()
#8	0x0000000101f8a5a6 in thunk for @callee_guaranteed (@unowned UnsafePointer<Int8>) -> (@unowned Int, @error @owned Error) ()
#9	0x0000000101f94b5a in partial apply for thunk for @callee_guaranteed (@unowned UnsafePointer<Int8>) -> (@unowned Int, @error @owned Error) ()
#10	0x0000000102a184df in UnsafePointer.withMemoryRebound<A, B>(to:capacity:_:) ()
#11	0x0000000101f89dcd in closure #1 in HTTPDecoder.decodeHTTP(ctx:) at swift-nio.git-6334843834720069654/Sources/NIOHTTP1/HTTPDecoder.swift:486
#12	0x0000000101f94891 in partial apply for closure #1 in HTTPDecoder.decodeHTTP(ctx:) ()
#13	0x0000000101f8a6ae in thunk for @callee_guaranteed (@unowned UnsafeRawBufferPointer) -> (@unowned Int, @error @owned Error) ()
#14	0x0000000101f94952 in partial apply for thunk for @callee_guaranteed (@unowned UnsafeRawBufferPointer) -> (@unowned Int, @error @owned Error) ()
#15	0x00000001024db535 in ByteBuffer.withVeryUnsafeBytes<A>(_:) at swift-nio.git-6334843834720069654/Sources/NIO/ByteBuffer-core.swift:493
#16	0x0000000101f7c4a8 in HTTPDecoder.decodeHTTP(ctx:) at swift-nio.git-6334843834720069654/Sources/NIOHTTP1/HTTPDecoder.swift:481
#17	0x0000000101f7f1b3 in HTTPDecoder.channelRead(ctx:data:) at swift-nio.git-6334843834720069654/Sources/NIOHTTP1/HTTPDecoder.swift:595
#18	0x0000000101f8e0f9 in protocol witness for _ChannelInboundHandler.channelRead(ctx:data:) in conformance HTTPDecoder<A> ()
#19	0x0000000102519a5d in ChannelHandlerContext.invokeChannelRead(_:) at swift-nio.git-6334843834720069654/Sources/NIO/ChannelPipeline.swift:1284
#20	0x0000000102519b0f in ChannelHandlerContext.invokeChannelRead(_:) at swift-nio.git-6334843834720069654/Sources/NIO/ChannelPipeline.swift:1286
#21	0x0000000102521702 in ChannelHandlerContext.fireChannelRead(_:) at swift-nio.git-6334843834720069654/Sources/NIO/ChannelPipeline.swift:1097
#22	0x0000000102145b35 in OpenSSLHandler.doDecodeData(ctx:) at swift-nio-ssl.git--7338283827192981615/Sources/NIOOpenSSL/OpenSSLHandler.swift:259
#23	0x0000000102142cd7 in OpenSSLHandler.channelRead(ctx:data:) at swift-nio-ssl.git--7338283827192981615/Sources/NIOOpenSSL/OpenSSLHandler.swift:106
#24	0x00000001021472e9 in protocol witness for _ChannelInboundHandler.channelRead(ctx:data:) in conformance OpenSSLHandler ()
#25	0x0000000102519a5d in ChannelHandlerContext.invokeChannelRead(_:) at swift-nio.git-6334843834720069654/Sources/NIO/ChannelPipeline.swift:1284
#26	0x0000000102510d63 in ChannelPipeline.fireChannelRead0(_:) at swift-nio.git-6334843834720069654/Sources/NIO/ChannelPipeline.swift:808
#27	0x000000010260f0e5 in SocketChannel.readFromSocket() at swift-nio.git-6334843834720069654/Sources/NIO/SocketChannel.swift:144
#28	0x00000001024a178a in BaseSocketChannel.readable0() at swift-nio.git-6334843834720069654/Sources/NIO/BaseSocketChannel.swift:953
#29	0x00000001024a3766 in BaseSocketChannel.readable() at swift-nio.git-6334843834720069654/Sources/NIO/BaseSocketChannel.swift:937
#30	0x00000001024a6160 in protocol witness for SelectableChannel.readable() in conformance BaseSocketChannel<A> ()
#31	0x00000001025502e9 in SelectableEventLoop.handleEvent<A>(_:channel:) at swift-nio.git-6334843834720069654/Sources/NIO/EventLoop.swift:454
#32	0x0000000102551f4a in closure #1 in closure #1 in SelectableEventLoop.run() at swift-nio.git-6334843834720069654/Sources/NIO/EventLoop.swift:503
#33	0x0000000102560099 in partial apply for closure #1 in closure #1 in SelectableEventLoop.run() ()
#34	0x0000000102552089 in thunk for @callee_guaranteed (@guaranteed SelectorEvent<NIORegistration>) -> (@error @owned Error) ()
#35	0x0000000102560142 in partial apply for thunk for @callee_guaranteed (@guaranteed SelectorEvent<NIORegistration>) -> (@error @owned Error) ()
#36	0x00000001025ed23f in Selector.whenReady(strategy:_:) at swift-nio.git-6334843834720069654/Sources/NIO/Selector.swift:590
#37	0x0000000102551b32 in closure #1 in SelectableEventLoop.run() at swift-nio.git-6334843834720069654/Sources/NIO/EventLoop.swift:498
#38	0x0000000102551ca7 in partial apply for closure #1 in SelectableEventLoop.run() ()
#39	0x00000001024911a7 in thunk for @callee_guaranteed () -> (@error @owned Error) ()
#40	0x0000000102551d5f in thunk for @callee_guaranteed () -> (@error @owned Error)partial apply ()
#41	0x000000010254a269 in closure #1 in withAutoReleasePool<A>(_:) at swift-nio.git-6334843834720069654/Sources/NIO/EventLoop.swift:268
#42	0x000000010255fffa in partial apply for closure #1 in withAutoReleasePool<A>(_:) ()
#43	0x00000001033c0f3f in autoreleasepool<A>(invoking:) ()
#44	0x000000010254a14b in withAutoReleasePool<A>(_:) at swift-nio.git-6334843834720069654/Sources/NIO/EventLoop.swift:267
#45	0x0000000102550bd6 in SelectableEventLoop.run() at swift-nio.git-6334843834720069654/Sources/NIO/EventLoop.swift:497
#46	0x0000000102557303 in closure #1 in static MultiThreadedEventLoopGroup.setupThreadAndEventLoop(name:initializer:) at swift-nio.git-6334843834720069654/Sources/NIO/EventLoop.swift:687
#47	0x000000010255f5da in partial apply for closure #1 in static MultiThreadedEventLoopGroup.setupThreadAndEventLoop(name:initializer:) ()
#48	0x0000000102557cfc in thunk for @escaping @callee_guaranteed (@guaranteed Thread) -> () ()
#49	0x0000000102632489 in partial apply for thunk for @escaping @callee_guaranteed (@guaranteed Thread) -> () ()
#50	0x0000000102632e45 in closure #1 in static Thread.spawnAndRun(name:body:) at swift-nio.git-6334843834720069654/Sources/NIO/Thread.swift:105

Steps to reproduce
Buffer contents:
(lldb) po bufferSlice.readString(length: 166)
▿ Optional

some : "HTTP/1.1 101 Switching Protocols\r\nDate: Sat, 07 Jul 2018 14:07:41 GMT\r\nConnection: upgrade\r\nSec-WebSocket-Accept: KXCK+WbSaeoIR4K6RxA2LEFBiwQ=\r\nUpgrade: WebSocket\r\n\r\n"

Occurs when receiving a websocket upgrade response. Using vapor HTTP and WebSocket repos which uses HTTPResponseDecoder and WebSocketFrameDecoder channel handlers.
If possible, minimal yet complete reproducer code (or URL to code)
SwiftNIO version/commit hash
Swift NIO 1.8.0
Swift & OS version (output of swift --version && uname -a)
macOS Mojave, Xcode 10 beta 3, Swift 4.2

Can you run your code with Thread Sanitizer turned on and print the results? I’m inclined to believe there is a thread safety problem here.

Nothing apparent after turning on Thread Sanitizer or enabling zombie objects. I'm calling HTTPClient.websocket here: WebSocket+Client.swift which in turn calls HTTPClientProtocolUpgrader.swift

Sample SwiftPM project: https://github.com/carumusan/swift-nio-exc-error. Compiled with latest XCode beta and macOS mojave it errors on the upgrade response for me.

Cool, so I can reproduce this. Not 100% of the time, but if I run the binary a few times it definitely reproduces.
The crash is odd. It's coming in swift_unknownRetain called from evacuateChannelHandlerContext. Historically we've seen some crashes here that are to do with seeing excess data delivered to the HTTP parser, but this does not appear to be the issue here, not least because we've landed a number of patches to prevent this from happening.
Normally I'd assume this is because we're attempting to unwrap our pointer to the ChannelHandlerContext and its bad. However, the pointer itself is fine. The code is here:
https://github.com/apple/swift-nio/blob/bf1036687b5e6083a518607ad1991a05bd3e567f/Sources/NIOHTTP1/HTTPDecoder.swift#L697-L699
The value of OpaqueContext is 0x00006130000088d8, and that points to a perfectly reasonable looking parser data structure. On that parser we have a data field which should contain a pointer to our hidden ChannelHandlerContext. That pointer is set to 0x000060800000db20, which is basically identical to the value of ObjectIdentifier(ctx) from several stack frames up: 0x000060800000d220. There are a few bytes of offset there which I'm hard-pressed to explain for now, so I may want to try to revisit why that offset is bad, but it's not screamingly, obviously wrong. So for now let's assume that we're passing a valid pointer into takeUnretainedValue.
None of these are even close to the address that is actually causing the segfault: that's 0x173800040. Where is that coming from?
Well, here's the assembler corresponding to swift_unknownRetain:
    0x7fff5a4276a0 <+0>:  testq  %rdi, %rdi
    0x7fff5a4276a3 <+3>:  je     0x7fff5a4276dc            ; <+60>
    0x7fff5a4276a5 <+5>:  movabsq $-0x7fffffffffffffff, %rax ; imm = 0x8000000000000001
    0x7fff5a4276af <+15>: andq   %rdi, %rax
    0x7fff5a4276b2 <+18>: jne    0x7fff5a4276dc            ; <+60>
    0x7fff5a4276b4 <+20>: movq   0x35869655(%rip), %rax    ; swift_isaMask
    0x7fff5a4276bb <+27>: andq   (%rdi), %rax
->  0x7fff5a4276be <+30>: testb  $0x1, 0x20(%rax)
    0x7fff5a4276c2 <+34>: je     0x7fff5a4276ca            ; <+42>
    0x7fff5a4276c4 <+36>: testb  $0x2, 0x28(%rax)
    0x7fff5a4276c8 <+40>: jne    0x7fff5a4276cf            ; <+47>
    0x7fff5a4276ca <+42>: jmp    0x7fff5a43b2ea            ; symbol stub for: objc_retain
    0x7fff5a4276cf <+47>: pushq  %rbp
    0x7fff5a4276d0 <+48>: movq   %rsp, %rbp
    0x7fff5a4276d3 <+51>: callq  0x7fff5a3e88f0            ; swift_retain
    0x7fff5a4276d8 <+56>: movq   %rax, %rdi
    0x7fff5a4276db <+59>: popq   %rbp
    0x7fff5a4276dc <+60>: movq   %rdi, %rax
    0x7fff5a4276df <+63>: retq

If we look at rax we see that it is set to 0x173800020, which is 0x20 less than our fault address, so pretty clearly this attempt to deference the memory for testb is the problem here. So what is in rax? Well, rax was set two instructions earlier by doing a load of the swift_isaMask symbol, and then doing a bitwise and of the value at rdi with the swift_isaMask. What's the value of rdi according to my debugger? 0x000060800000db20, the pointer we're attempting to unwrap. The value at that memory address is 0x173800021 which, when we bitwise AND with the isaMask (0x00007ffffffffff) gives us 0x173800020, our bad address.
Let's investigate the possibility we have the wrong address, and that we should be using 0x000060800000d220. If we do a bitwise AND of the data at that address with the swift_isaMask we get 0x10299d630. Adding 20 and dereferencing that pointer does not fault, a good suggestion that somehow we've ended up with the wrong address here.
Running this a few times, it turns out that a great predictor of crashes is when HTTPDecoder.channelRead is passed a ctx whose ObjectIdentifier is different than the value of the pointer in .data. Whenever those are different we get a crash, whenever they're the same all is well.
So this suggests we have a memory scribbler. Tracking it down is going to be a bit fussy though, as the corruption is happening before we receive a byte of data.

Got it.

So this is a Vapor bug, but it isn't entirely obvious and we really need to add a fix on our end to make doing this a severe error (probably immediately close the channel, maybe just call it a fatal error).
What Vapor is doing is adding the same HTTPDecoder to multiple channels. The misbehaving function is here:
https://github.com/vapor/http/blob/8123ea00e9858b369cd168d0303d33e7d3804d19/Sources/HTTP/Responder/HTTPClientProtocolUpgrader.swift#L15-L41
The error here is that there are three ChannelHandlers created outside of the .channelInitializer closure, and passed into that closure by reference. This is not an obvious bug, but because of the way NIO handles HappyEyeballs, each call to ClientBootstrap.connect may initialise many channel objects, not just one, and will race them to see which connects first.
This bug manifests whenever the channel that most recently fired handlerAdded on the HTTPDecoder is not the one that actually connects first. In that situation, the ChannelHandlerContext we've stuffed on the http_parser object will be freed by the runtime (as we don't increment its refcount), but we won't notice, and we'll attempt to use it and blow up.
The HTTPDecoder is not safe to share across multiple Channels, but we can safely police this use, and so we should. Vapor should definitely land a patch, but we should similarly throw errors in this case.

The question is, @jw, is it worth us trying to police this? We'll need to add an EmbeddedAtomic<Bool> into our HTTPDecoder and use that to track the state. Is it worth it?

@Lukasa @weissi  in netty we require the user to use an annotation to explicitly mark a ChannelHandler as safe to be used multiple times. If this is not provided we fail when the user tries to insert it again. Maybe we should do something similar here ?

What kind of annotation do you have in mind, and how would we implement it? We could use a tag protocol I suppose, but that requires that something external to the handler police this, and I don't know how we could do that.

Just chatted with @weissi.
I'm going to split this into two issues that are more broadly focused than just HTTPDecoder.


TfLite Fill quantization support added

Quantization support added for #28438

@achowdhery Can you please review this PR? Thanks!

Nagging Reviewer @achowdhery: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 15 days with no activity and the awaiting review label has been applied.

@Dayananda-V Can you please resolve conflicts? Thanks!

@gbaned
conflicts resolved.

@Dayananda-V Could you please resolve conflicts? Thanks!

I'm going to go ahead and close this PR, because it seems to have stalled. If you're still interested in pursing this (and responding to my comments), please feel free to reopen!


Split CircleCI tests across multiple executors

Parallel test splitting would significantly improve CI speed. Unfortunately, the CircleCI CLI splits the job by test filename, but Rust unit tests are written in source files and run by test name. To get around this, I did the following hack a while ago:
#!/usr/bin/env bash

grep -A2 -r '\#\[test\]' src/proof/nova.rs | grep -oP '(?<=fn).*?(?=\()' > nova-tests.txt
grep 'recursion' nova-tests.txt > nova-recursion-tests.txt # recursion tests are slow
grep -v 'recursion' nova-tests.txt > nova-tests-tmp.txt
split -l 17 nova-tests-tmp.txt nova-tests --additional-suffix=.txt
rm nova-tests.txt nova-tests-tmp.txt
cat nova-recursion-tests.txt
cat nova-testsaa.txt
cat nova-testsab.txt
cat nova-testsac.txt
circleci tests glob "*.txt" | circleci tests split > tests-to-run
cat tests-to-run

while read name;
do
    cargo test "$name" --release -- --ignored
done <$(cat tests-to-run)

rm *.txt

echo "Tests complete"

This is perhaps sub-optimal, so it would be great to find another way to glob test names into files (cargo nextest list?), or even better to split tests by timing data.

Closed by #715 since we no longer use CircleCI


Consumer work with STD only

This is one of the nicest crates around error handling. After using error-chain and failure and similar ones not I am thinking of just using std only. This crate is close but is there a way clients of chainerr write a wrapper such that the dependency on chainerr can be removed easily if a better helper crate comes to existence?

Here is my recommendation:
https://haraldh.github.io/chainerror/tutorial13.html


Stable support

With these changes, it compiles on stable 1.1. The Send is a problem though.
See  #36

Can you determine whether or not RustBox is "Send" when the negative trait is removed?
You can force it to be not "Send" by adding a PhantomData marker for a type which is "Not Send"

What's cool with rust (and haskell (and cool languages)) is that you always have something to learn ^^

Did you have time to review the changes ?

Sorry for the delay, thanks for this @Yamakaky!


fix(docker): replace anonymous docker volume with env variable for encrypting secrets

Homarr

Thank you for your contribution. Please ensure that your pull request meets the following pull request:

[x] Builds without warnings or errors (pnpm buid, autofix with pnpm format:fix)
[x] Pull request targets dev branch
[x] Commits follow the conventional commits guideline
[x] No shorthand variable names are used (eg. x, y, i or any abbrevation)

THIS IS A BREAKING CHANGE!
Closes #1808

e2e is failing, please have a look


Disable link functionality on disabled btn-link

Future-proof disabling of clicks on disabled btn-link. Fixes #25639 ensuring consistency between btn-link <button>s and <a>s when disabled, which is disabled link functionality.

@andresgalante a.btn.disabled uses pointer-events:none (https://github.com/twbs/bootstrap/blob/f7a09893ee503ca02801d1197b4dd2687476be27/scss/_buttons.scss#L55). The styling may not be consistent with a.btn if text-decoration:none is used, since pointer-events deliberately prevents the link from being targeted


🗃 Multi File Script Support (scripts folder required)

This pull request allows for multiple scripts to be loaded at once with the introduction of a required scripts folder!

this is a broken pull request

I see you made a lot of changes. Feel free to create individual issues/pull requests. I am still actively monitoring the project, just not changing that much at the moment.

I see you made a lot of changes. Feel free to create individual issues/pull requests. I am still actively monitoring the project, just not changing that much at the moment.
I didn't do the committing correctly with specific branches for either of my pull requests on accident and as a result both pull requests are quite broken. I don't know how I would go about creating pull requests with specific commits, or how to go about this another way without having to create a whole new fork and manually add the additions I already made.

I see you made a lot of changes. Feel free to create individual issues/pull requests. I am still actively monitoring the project, just not changing that much at the moment.

I didn't do the committing correctly with specific branches for either of my pull requests on accident and as a result both pull requests are quite broken. I don't know how I would go about creating pull requests with specific commits, or how to go about this another way without having to create a whole new fork and manually add the additions I already made.

I'm not a Git expert myself, but an IDE like IntelliJ should have the possibility to cherry pick commits. So you make a new branch (without all the commits) starting from a base version without all the changes, and then cherry pick each commit into your branch, fixing possible merge conflicts as they arise.


Cannot read property 'id' of undefined + The above error occurred in the  component:

Hi Allen,
The bug
I want all these functionalities in single table searching in all fields + paging, it works fine for the first time, but after navigating to another page and searching for something generates error. for your reference have added code snippet and error,
Code Snippet
import paginationFactory, { PaginationProvider, PaginationListStandalone } from 'react-bootstrap-table2-paginator';
import ToolkitProvider, { Search } from 'react-bootstrap-table2-toolkit';
import { tableData } from '../../../data/blog/BlogPostData';

const columns = [
    {   dataField: 'id',        text: 'Id'      },
    {   dataField: 'category',  text: 'Category' },
    {   dataField: 'slug',      text: 'Slug'    },
    {   dataField: 'posts',     text: 'Posts'   },
    {   dataField: 'date_created',  text: 'Date Created'    },
    {   dataField: 'date_updated',  text: 'Date Updated'    },
];
const options = {
    custom: true,
    paginationSize: 4,
    pageStartIndex: 1,
    firstPageText: 'First',
    prePageText: 'Prev',
    nextPageText: 'Next',
    lastPageText: 'Last',
    nextPageTitle: 'First page',
    prePageTitle: 'Pre page',
    firstPageTitle: 'Next page',
    lastPageTitle: 'Last page',
    showTotal: true,
    totalSize: tableData.length
  };
const contentTable = ({ paginationProps, paginationTableProps }) => (

      <ToolkitProvider
        keyField="id"
        columns={ columns }
        data={ tableData}
        search
      >
        {
          toolkitprops => (

              <SearchBar { ...toolkitprops.searchProps } className="search-bar m-4" placeholder="Search Post" />

                  <BootstrapTable
                selectRow={ selectRow }
                bordered={ false }
                { ...toolkitprops.baseProps }
                { ...paginationTableProps }
              />

          )
        }
      </ToolkitProvider>
      <PaginationListStandalone { ...paginationProps } />

  );

const BlogPost= () => {
return (
        <Fragment>
           <PaginationProvider
             pagination={
                  paginationFactory(options)
              }
             >
              { contentTable }
           </PaginationProvider>
     </Fragment>
    )
};
export default BlogPost;

To Reproduce
Steps that generate errors:

Enter value in Search bar  ( It works fine )
Navigate to page 2..3...or X
Again enter value in Search bar ( It generate error with blank screen )
See error below show in my console.

Error Screenshots
If applicable, add screenshots to help explain your problem.

https://prnt.sc/1mt2mvr
https://prnt.sc/1mt2upq
https://prnt.sc/1mt9yhe

Hello, I had a similar issue and did a short investigation on it. I found the following
In the node_modules/react-bootstrap-table-next/lib/src/utils.js there is get function that accepts two parameters (target, field) as it is shown below
function get(target, field) {
  var directGet = target[field];
  if (directGet !== undefined && directGet !== null) {
    return directGet;
  }

  var pathArray = splitNested(field);
  var result = void 0;
  try {
    result = pathArray.reduce(function (curr, path) {
      return curr[path];
    }, target);
  } catch (e) {}
  return result;
}

The problem is that in some cases the target parameter is undefined and that throws that error.
So I wrapped the entire body function inside the try/catch block in order to catch the error as it is shown below
function get(target, field) {
  try {
  var directGet = target[field];
  if (directGet !== undefined && directGet !== null) {
    return directGet;
  }

  var pathArray = splitNested(field);
  var result = void 0;

    result = pathArray.reduce(function (curr, path) {
      return curr[path];
    }, target);
  } catch (e) {
    console.log('error',e)
  }
  return result;
}

I hope that this will be useful to you too. This is not a proper fix though. The developers of the library has to take a look at it :)

Thanks @myapos will check with that solution, between for the current project I have implemented https://react-table.tanstack.com/ package.

Had the same error related in the issue #1660. My solution was the same as @myapos, also made the pull request (#1662), but had no response and it hasn't been merged.

I made a PR too. I hope the developers will merge at least one of them. It is a simple fix.

@smchauhan @sandipthemes

Faced same issue and implemented my own pagination component
and here how I'm using it.

I am facing the same issue what is the solution

This just works great, thanks for this

Faced same issue and implemented my own pagination component
and here how I'm using it.

This just works great, thanks for this

In case you are using pagination that need to fetch new data from the api on page change you need to enable the "remote" prop and you need to handle onTableChange by yourself. documentation

Just pass - remote={{pagination: true } } in BootstrapTable. It will work


Fix circular dependency during Jets tests from importing constants from GarbageCollection

Description

Jets tests started failing when importing GC constant from BlobManager.cs, probably due to circular dependency when building their bundle.

Additional information can be found: Bug 2635
Stack of interest:
Uncaught ReferenceError: Cannot access 'gcTreeKey' before initialization
at Module.gcTreeKey (deltaScheduler.ts:33:48)
at ../../../packages/runtime/container-runtime/lib/summaryFormat.js (summaryFormat.ts:180:100)
at webpack_require (bootstrap:24:1)
at fn (hot module replacement:62:1)
at ../../../packages/runtime/container-runtime/lib/dataStoreContext.js (dataStore.ts:198:2)
at webpack_require (bootstrap:24:1)
at fn (hot module replacement:62:1)
at ../../../packages/runtime/container-runtime/lib/dataStores.js (dataStoreRegistry.ts:34:2)
at webpack_require (bootstrap:24:1)
at fn (hot module replacement:62:1)

FYI - This PR kind of does the same thing but I need to update it - https://github.com/microsoft/FluidFramework/pull/12282

FYI - This PR kind of does the same thing but I need to update it - #12282

Oh, if you want to take over, I can close it.


Lumina-FM: statusbar show folders/files

Lumina-FM's statusbar shows the number of folders and files combined as "Items: NNN". This minor change splits that.
New string example

No Selection: "Folders NN / Files NN"
Selection: "Selected Folders NN / Files NN"

Need to rebase


Add Export feature in Explorer nodes list.

Add Export list into dropdown.
can be export in csv format.

merged into Dev


[Workflow] Update durabletask-go version and add new continue-as-new test

Description
This PR pulls in the latest version of the durabletask-go dependency, which includes the following changes:

Adds support for combining the existing continue-as-new APIs with the new raise-event APIs. This is for supporting external event aggregation scenarios.
Automatically creates an instance ID for child-workflows if none is provided by the SDK (makes SDK authoring a bit simpler)
Minor logging improvements

Issue reference
This is primarily aligned with https://github.com/dapr/dapr/issues/6045 (the new raise-event API).
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Unit tests passing
[x] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

related to #6301


Update pandoc container

Purpose/implementation Section
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

What scientific question/module of analysis is your analysis addressing?
To update pandoc dependency to version <IP_ADDRESS> (it was v3.2). This version creates a bug with texlive version when generating tables in the reports. I also installed library(hdf5r) separately as there was a bug with it when running lsf-script.txt for the 02_run_SoupX.Rmd
What GitHub issue does your pull request address?
Closes #72.
Directions for reviewers
Tell potential reviewers what kind of feedback you are soliciting.
Which areas should receive a particularly close look?
Please run the following:

[x] Run ./run-container/run-test-packages.sh and confirm dependencies.
[ ] Run ./analyses/upstream-analysis/02_run_SoupX.Rmd and confirm tables show properly in the html and pdf reports. Use run-terminal.sh file for the container.
[ ] Repeat TASK#2, but use lsf-script.txt this time.

Reproducibility Checklist

[x] The dependencies required to run the code in this pull request have been added to the project Dockerfile.

Documentation Checklist

[x] This analysis module has a README and it is up to date.
[x] The analytical code is documented and contains comments.

Per our discussion with @sharonfreshour, I updated the README file with a better example on how to run a single file from bash terminal. See 89e38ab3f238416365a0ca7c85b1ce944b0da4c7


fix: update should trigger flush without included

This uses an intimate API (store.didSaveRecord) to capture the return of updates and schedule a flush of the changes.
The schedule is only because of our desire to batch these notifications with any generated from included records, if we don't care about the batching we can just call flushChanges straight up and it would affect only the primary data while a separate flush would occur for the changes from included.
I explored two other alternatives that achieve this, both have downsides.

flush within RecordData.didCommit. This only works if we use run.next or similar to defer the flush until after the changes are notified (notifications are generated based on the returned changedKeys generated by didCommit). It requires accessing the StoreWrapper._store to get the weak map key as well.

chaining the promise within the resolver given to the private store.scheduleSave method to perform the flush. This felt more brittle.

Regardless of approach taken here (including closing without merging) we should work to ensure this is possible via public API in EmberData.

Regardless of approach taken here (including closing without merging) we should work to ensure this is possible via public API in EmberData.

yep strong +1
also tests are red although interestingly only with FF on.  Seems a bit odd that custom model classes would affect batching like this.


Conflicting task names from different plugins

Resolve name conflicts in case several plugins export tasks with the same name.

Resolved by forcing plugin name prefacing the task name.


Add E2E tests for accordion and autoresize

WHAT?
Add E2E tests for accordion and the input text area autoresizing.
HOW?

Add corresponding classes for components used in the tests.
Add example apps used for each test in their own directory.
Uncomment code in the tests that are blocked due to existing bugs.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Upgrade near-sdk-4

Hi, was trying to help someone on discord who was doing something similar to this, and ended up making some changes to fix some issues. Here is a WIP moving toward a valid migration based on this branch https://github.com/austinabell/sputnik-dao-contract/commit/4e9b7a41833ab8a8e237d00b81820ac920557220. Unfortunately, I don't have time to completely finish in the near future, but I hope this helps move closer!
Feel free to ask any questions about the migration. Unfortunately, there are a few weird patterns inside sputnik that make the migration a little tricky, but I'll be happy to help however I can.

Thanks for the response @austinabell
This repo is not actively being maintained and I am interested in becoming lead maintainer of this repo. I am working with few communities that would like to get a lot more out of SputnikDao. Also I'm interested in improving the NEAR ecosystem for Rust Developers.
I stopped working on this pr due near-sdk-sim incompatibilities your changes resolved.
Technically, near-sdk-sim is deprecated in favour of near-runner-js. Though the Rust equivalent does not exist, I've been investing my time on improving this. Further changes I'll make to SputnikDao is replacing near-sdk-sim, enabling windows support, introducing ethereum-truffle-like suite tools, Rust dev STANDARDS as well as other things.
Passed tests - https://github.com/evergreen-trading-systems/sputnik-dao-contract/actions/runs/1196378175


Setting a custom httpsAgent on the generated AxiosInstance

Description
Hi,
I like the project very much and its working fine, however i'm now running into a small problem:
I'm using axios for my generated http client, but I can't seem to find a way to set a custom httpsAgent:
Example:
const result = await axios.post(
    `https://${url}/login`,
    body,
    {
      httpsAgent: new https.Agent({
        rejectUnauthorized: false
      })
    }
  )

I need this to import our rootca certificate since it's self-signed...
Is this even possible?

Hi @jordanshatford thx for the quick feedback. Does this mean it's currently not possible, but will be in the future? Just asking since I need to go live relatively soon haha :)

@kimzeevaarders it is currently not possible.

ah that's too bad thx for responding though 👍

In case this gets implemented please let know though, perhaps I can still switch over then 👍

hmmmm @jordanshatford @mrlubos I managed to set a httpsAgent on the axiosRequestConfig over an request interceptor. It seems to do the trick:
const requestInterceptor = OpenAPI.interceptors.request;

requestInterceptor.use((request) => {
    request.httpsAgent = new Agent({
        ca: process.env.OPENTEXT_NETWORK_ROOT_CA
    });

    return request;
});

Can you guys verify this is a good workaround or are there some caveats using this approach?

Hi @jordanshatford cool, thx for confirming. No i'd rather only set it when needed, so this is perfect for me!

Workaround successfull over interceptor

@kimzeevaarders if you're able to upgrade, the new Axios client is available now https://www.npmjs.com/package/@hey-api/client-axios
Docs: https://heyapi.vercel.app/openapi-ts/clients.html#axios
Would love your thoughts if you give it a try!


Topology modification with new version and time stamp

ver.sub, starting from 0.0
ver+1: newly added or updated topology
sub: using the latest sub_ver from the domain_topology

[#6bfb23eaf84ce8ff2f8c108a54fb998349bccd1d]
manager.py