Detect the use of objects when constructed class is need for getters/setters and functions

🔍 Search Terms
class instance object
✅ Viability Checklist

[X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[X] This wouldn't change the runtime behavior of existing JavaScript code
[X] This could be implemented without emitting different JS based on the types of the expressions
[X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
[X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion
The commonality of objects and classes in TypeScript is very useful but this makes to it too easy to forget that the object instance doesn't have the class prototypes.
📃 Motivating Example
I had a
class foo {
    element: HTMLElement;
    get input() {return element as HTMLInputElement;
}.

const fx: foo = {element: bar}

but, of course, fx.input failed. Since it was in the browser the fail was silent.
It would be nice to detect that I am using an object rather than a class instance by tracking the fact that fx was created without using a constructor.
💻 Use Cases

What do you want to use this for?
What shortcomings exist with current approaches?
What workarounds are you using in the meantime?

Class instances and objects are very similar which makes such errors too easy and nonobvious. The work-around is DDT (Don't Do That) but the point of TypeScript is to assist in my avoiding such pitfalls.

I'm not sure what you're suggesting? The code you showed does produce errors, the object literal is required to have input.

You're right. I had forgotten that I (foolishly) put in as "as any" to work around the message.


Apple Silicone

Hello! We're successfully using unison in fairly high volume with a macOS M1 binary we've compiled.  This is a request to see if you can compile your rust project on an M1 and perhaps update the homebrew release.
If you don't want to, it would be nice to get a copy of the entire rust project so we can give it a go.
Big thanks :)

Hi,
I don't have access to M1 macOS to compile (even if I do, there might be security concerns) and it seems Github Actions doesn't support M1 either https://github.com/actions/virtual-environments/issues/2187
I'd suggest you compile the binaries and fork Hombrew formula repo with the your binary links https://github.com/autozimu/homebrew-formulas/blob/master/Formula/unison-fsmonitor.rb Your users can then use the forked repo to install M1 binaries.

@bkervaski Did you finally compiled it? May you share the formula with us? Same problem here.

I wrote one in node that’s cross platform, then we abandoned unison and built our own sync engine from scratch.  Took about 4 months but it’s awesome.

From: David Díaz Clavijo @.>
Sent: Sunday, June 5, 2022 3:25:48 PM
To: autozimu/unison-fsmonitor @.>
Cc: Bill Kervaski @.>; Mention @.>
Subject: Re: [autozimu/unison-fsmonitor] Apple Silicone (Issue #12)
@bkervaskihttps://github.com/bkervaski Did you finally compiled it? May you share the formula with us? Same problem here.
—
Reply to this email directly, view it on GitHubhttps://github.com/autozimu/unison-fsmonitor/issues/12#issuecomment-1146878004, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AADBO5EKJC27CELQBXYR2CTVNUEMZANCNFSM5LK7UWHA.
You are receiving this because you were mentioned.Message ID: @.***>

@autozimu could you please reopen this issue and just keep it open? At some point GitHub Actions will support M1 and then it'll be possible to make it work and it'd be nice to have this issue visible by then :)


Compilation with the intel version of the Macbook pro failed with the following message：No rule to make target extern/boost/lib/libboost_fiber.a', needed by bin/crosstabs'.  Stop.

Compilation with the intel version of the Macbook pro failed with the following message
[ 92%] Linking CXX static library ../../lib/libmotion.a
[ 92%] Built target motion
[ 92%] Building CXX object src/examples/tutorial/crosstabs/CMakeFiles/crosstabs.dir/crosstabs_main.cpp.o
[ 93%] Building CXX object src/examples/tutorial/crosstabs/CMakeFiles/crosstabs.dir/common/crosstabs.cpp.o
make[2]: *** No rule to make target extern/boost/lib/libboost_fiber.a', needed by bin/crosstabs'.  Stop.
make[1]: *** [src/examples/tutorial/crosstabs/CMakeFiles/crosstabs.dir/all] Error 2
make: *** [all] Error 2

Can you tell us more about your setup: compiler version, Boost already installed in the system? Please also give us the full build log.


support python2 unicode strings through six library

Thanks! Good timing as we are working on 0.7.0 right now. Can you sign our CLA please:
https://github.com/snowplow/snowplow/wiki/CLA

Signed! Happy to help.

Confirmed! Thanks so much


[FLINK-14735][scheduler] Improve scheduling of all-to-all partitions with ALL input constraint for legacy scheduler

What is the purpose of the change
Avoid explosion in the number of input checks when scheduling a downstream vertex in a all-to-all blocking shuffle.
This code is based on the discussion in FLINK-14735 and is a modified version of @zhuzhurk's original patch.
Brief change log

In the ExecutionGraph/ Execution, when scheduling downstream consumers, now collects all scheduling candidates in a set before checking their inputs and scheduling them. This avoid double checking of vertices.

Verifying this change

This adds a unit test to validate the performance fix

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: yes
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@zhuzhurk I addressed your suggestion in the latest commit.

Thanks for addressing the comments.
The change looks good to me.
+1 to merge it.

Thanks, will merge once the CI gives us green light...


Include additional Container[*].SecurityContext properties

tl;dr
runAsGroup - REQUIRED, if securityContext is supported. This compliments runAsUser
readOnlyRootFilesystem - REQUIRED, if securityContext is supported.
Including readOnlyRootFilesystem for the purposes of reserving the keyword.

cc @knative/trademark-committee

/hold there are some additional properties worth including

/hold cancel

Just curious, why didn't you make readOnlyRootFilesystem required?

I don't have strong opinions - I can change if the KTC feels that way
In contrast I felt like runAsGroup compliments runAsUser thus it has more utility and should be REQUIRED. Meaning if people are overriding UIDs they're probably also overriding GIDs

Given a choice I'd vote for making as many things as possible "REQUIRED to support" as that'll only help interop. But I'd be curious to know if other TMC members have a concern.

Gonna leave this one for a few days so @spencerdillard can get more info from CloudRun folks

/lgtm

Including readOnlyRootFilesystem for the purposes of reserving the keyword.

Any particular reason why only "reserving" this key word and not the other parts of a SecurityContext that are not yet supported, like "capabilities" or "allowPrivilegeEscalation" ? I don't see really why "readOnlyRootFilesystem" is 'special' here.
I'm not so deep in the conformance discussions but is "RECOMMENDED" the standard way to include reserved, potentially nowhere implemented keywords. Wouldn't "MAY" be a better fit as I would expect with "RECOMMENDED" that at least one current implementation would support it ?

bump @spencerdillard @omerbensaadon

/assign @spencerdillard @whaught

This needs to update the runtime contract as well to specify the group when runAsGroup is set and when readOnlyRootFilesystem is set: https://github.com/knative/specs/blob/main/specs/serving/runtime-contract.md#user and https://github.com/knative/specs/blob/main/specs/serving/runtime-contract.md#default-filesystems

Having had some time to think about this and discuss with others, it seems to me that runAsGroup should be required in order to avoid accidentally having some default group that is dangerous, so ok with that part. But the readOnlyFileSystem seems like it should be recommended, since it is a boolean. As long as it is clear that the default is false and it is rw, then making it required seems like an unnecessary burden. It should only be used when the user doesn't want the default value.
Open to other takes, of course.

@spencerdillard  someone will correct me if I'm wrong, but I think the "recommended" vs "required" here is about support for the field, not whether the user needs to specify a value.

True -- I do think I got a bit hyperfocused on the user experience there. Put another way, we are making it required that any implementation must support ROFS or will not be conformant. So, I agree that this is reasonable to require. Sorry for getting off track there ;-)
/lgtm

/lgtm

/approved

/hold cancel

@spencerdillard you'll need to /approve without the d

or any other @knative/trademark-committee members

/lgtm
however:

readOnlyRootFilesystem - RECOMMENDED, if securityContext is supported.

The tl;dr from the description does not fit the actual PR where support for readOnlyRootFileSystem is set to REQUIRED

I see readOnlyRootFilesystem as REQUIRED with Evan's changes that merged into my branch
see:
https://github.com/knative/specs/blob/15121935c0cf2acaee97a02f87d3a17843ae07ae/specs/serving/knative-api-specification-1.0.md#securitycontext

Yep, I updated the description of this PR and changed RECOMMENDED to REQUIRED.

/approve


[New game]: Throw 'n' Score

🎮 Game Request
Throw 'n' Score is a dice-rolling game where two players compete to reach a total score of 100 or more points. It will be implemented using HTML, CSS and Javascript.
Point down the features

Interactive gameplay that allows players to make decisions on each turn.
Randomized selection of the first player to add an element of unpredictability.
Clear display of each player's current and total scores.
Intuitive user interface for easy understanding and enjoyment.

Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @srujana-16 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @srujana-16 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Non functional requirements

this is the entire document but it's stops being relavent about halfway through, hope it helps
https://docs.google.com/document/d/1SuOa27x1DuvyzVlamRLafLlcnlFFegD1yFlK6jZ6Ylg/edit?usp=sharing

I asked for tips about defining requirements for Blazor. Here is what the reply was.
"
Blazor server side keeps the component state in-memory, so its impossible to guess about provisioning without knowing how much state your components will use and how many of them will be active on a page at a time.
Gun-to-my-head I'd probably say something like the following is how I would estimate the RAM needed...but its just a guess:
100mb + ((1mb + ( 3 * MedianComponentStateSize)) * NumberOfConcurrentUsers) = Ram Required
It would require more if you use scoped dependencies (such as for auth or caching) and the requirements for file uploading, memory cache, and web api calls will all be the same as normal if you use those features of ASP.NET Core MVC.
If you don't run out of RAM or run into concurrent connection issues, then I would guess the CPU requirements would be similar to ASP.NET Core MVC...maybe just slightly higher for the component render tree diffing that the components do.
"
Any other thoughts?

A slightly off topic question, but what's the provisioning for? VM for the hosting of the site after it gets out of development with a significant number of features?

@kuromukira I have very little experience with hosting. How I see it (and please correct me if I am wrong), we will go for a Docker container which will be placed on some server. We will have to configure the container (VM) to be of certain configuration. That's what I had in mind.
So we need to cover system requirement aspects such as:

What base requirements do we need for a .NET Core 3.x Server-Side Blazor website.
How do the requirements scale with every concurrent user?
What is the edge case and stable case in terms of concurrent users?

I see. Thank you for the details.


overlay color setting not loading from file at launch

Please check if your issue is not a duplicate by searching existing issues
Describe the bug
"Overlay Color" RuneliteConfig.backgroundOverlayColor setting does not load from settings.properties file at startup
To Reproduce
Steps to reproduce the behavior:

Launch the RuneLite client
Navigate to the RuneLite Configuration panel
Scroll down to the Overlay Settings section
Modify the Overlay Color value from the default #BA1A1A1A to the value #00000000
Verify in settings.properties file: runelite.overlayBackgroundColor=0
Close the RuneLite client
Launch the RuneLite client
Navigate to the RuneLite Configuration panel
Scroll down to the Overlay Settings section
note the Overlay Color value in the UI
note the  runelite.overlayBackgroundColor value in settings.properties file
close the RuneLite client
note the  runelite.overlayBackgroundColor value in settings.properties file

Expected behavior
5. (file) expect to see runelite.overlayBackgroundColor configured  0, actually see the configured 0 👍
10. (ui) expect to see Overlay Color set to #00000000, actually see the default #BA1A1A1A 👎
11. (file) expect to see runelite.overlayBackgroundColor configured  0, actually see the configured 0 👍
13. (file) expect to see runelite.overlayBackgroundColor configured  0, actually see the default #BA1A1A1A value rendered as an integer: -1172694502 👎
Environment (please complete the following information):

OS: [e.g. Windows, Ubuntu, macOS]
RuneLite version: <IP_ADDRESS>
Launcher version: 2.1.3

Additional context
This behavior does not occur for other items in the config group, such as Block Extra Mouse Buttons.  It also does not occur for the nearby color setting, Notification Flash Color.  Both of these configuration settings persist correctly in settings.properties and are loaded at launch.
example client startup logs:
2020-08-14 23:22:19 [RuneLite] INFO  net.runelite.client.RuneLite - RuneLite <IP_ADDRESS> (launcher version 2.1.3) starting up, args: none
2020-08-14 23:22:20 [Preloader] INFO  net.runelite.client.rs.ClientLoader - Using cached vanilla client
2020-08-14 23:22:20 [Preloader] INFO  net.runelite.client.rs.ClientLoader - Using cached patched client
2020-08-14 23:22:21 [Preloader] INFO  net.runelite.client.rs.ClientLoader - client-patch 683232803.225
2020-08-14 23:22:21 [RuneLite] INFO  n.r.client.account.SessionManager - No session file exists
2020-08-14 23:22:22 [RuneLite] INFO  n.r.c.plugins.kourendlibrary.Library - Library is now reset
2020-08-14 23:22:22 [RuneLite] INFO  n.r.c.e.ExternalPluginManager - Loading external plugin "resource-packs" version "1.2.0" commit "c6d543b0f9ced23c13fdf44162607df4f1d916a6"
2020-08-14 23:22:23 [RuneLite] INFO  n.r.client.discord.DiscordService - Initializing Discord RPC service.
2020-08-14 23:22:25 [RuneLite] INFO  net.runelite.client.RuneLite - Client initialization took 6126ms. Uptime: 10064ms
2020-08-14 23:22:25 [AWT-EventQueue-0] INFO  net.runelite.client.ui.ClientUI - Showing frame net.runelite.client.ui.ContainableFrame[frame0,876,433,809x534,layout=java.awt.BorderLayout,title=RuneLite,normal,defaultCloseOperation=DO_NOTHING_ON_CLOSE,rootPane=javax.swing.JRootPane[,0,0,809x534,layout=org.pushingpixels.substance.internal.ui.SubstanceRootPaneUI$SubstanceRootLayout,alignmentX=0.0,alignmentY=0.0,border=org.pushingpixels.substance.internal.utils.border.SubstancePaneBorder@1858082c,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
2020-08-14 23:22:26 [pool-3-thread-1] INFO  n.r.client.discord.DiscordService - Discord RPC service is ready with user osrs-nerd-guy.

I do not get this behavior. Changing the overlay background color to fully-transparent black (#00000000) and closing the client causes both the UI and properties file to maintain their expected values during subsequent client sessions. Are you logged in with the Account plugin?

Commenting here for future reference, this issue is caused by having "Allow overlay color to be changed" option enabled in the "Resource packs" plugin. It will override any setting you choose any time you restart the client.  Thanks to geheur on Discord for pointing this out.

I am closing this issue as a likely invalid one. If further information is found, we can revisit it.


Update to NET Core RTM

Fixes #362

Please merge this

Wonderful - much appreciated @Suchiman! :guitar:


Hot reload not work

In the debugging app using hot reload, if i add new formbuilderinput then i reload app using hot reload, it's not working properly. Please fix this, cause this is slow down the time for developer.
I'm sorry my English is bad.

I'm working on a solution for this as soon as possible, thanks for your patience.
Thanks for your contribution and sorry for the inconvenience.

Hi @ua4ever,
Kindly try out version 3 of the package on pub which solves this issue.


CupertinoTextField clearButtonMode

CupertinoTextField should request keyboard when clear button tapped
Steps to Reproduce
CupertinoTextField(
  clearButtonMode: OverlayVisibilityMode.editing,
  textInputAction: TextInputAction.search,
)

Target Platform: iOS
Target OS version: 13.2
Devices: iPhone 8
Logs
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel master, v1.10.15-pre.94, on Microsoft Windows [Version 10.0.18999.1], locale zh-CN)
[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[√] Chrome - develop for the web
[√] Android Studio (version 3.5)
[√] VS Code (version 1.39.1)
[√] Connected device (3 available)

See https://github.com/flutter/flutter/pull/42890#issuecomment-545135420


About memory growth

Crossposting this issue here, since it probably makes more sense in this repository:
There are several issues where people ask why the memory keeps growing when using the Dataloader:
https://github.com/openvla/openvla/issues/4
https://github.com/octo-models/octo/issues/16
i kind of want to reopen the question with one assumption that maybe someone can verify:
The restructuring of trajectories is done with tf's symbolic tensors. Since we randomly access samples of a trajectory (random sharding of tfds before accessing it) the data of a trajectory is not loaded sequentially. When loading data with history or future_window_size, the previous/next samples are also loaded due to the trajectory transform executing while accessing the sample.
Does TF cache these previous / next samples and reuses them once the corresponding sample is loaded?
Could that be why the memory is growing?
I've noticed that the memory keeps growing till a specific point, then goes slightly up and down, which is kind of annoying when loading many different cameras.
If that is the case, is there a way to disable this caching?
And will the speed drop, even if we use prefetching?

The Question was answered in the other repository, therefore closing this issue.


Backport "HBASE-25770 Http InfoServers should honor gzip encoding when requested (#3159)" to branch-2.3

Signed-off-by: Duo Zhang<EMAIL_ADDRESS>Signed-off-by: Josh Elser<EMAIL_ADDRESS>

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 24s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2.3 Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 54s
branch-2.3 passed

+1 :green_heart:
compile
3m 43s
branch-2.3 passed

+1 :green_heart:
checkstyle
1m 27s
branch-2.3 passed

+1 :green_heart:
spotbugs
2m 40s
branch-2.3 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 40s
the patch passed

+1 :green_heart:
compile
3m 42s
the patch passed

-0 :warning:
javac
0m 30s
hbase-http generated 1 new + 38 unchanged - 0 fixed = 39 total (was 38)

-0 :warning:
checkstyle
0m 13s
hbase-http: The patch generated 1 new + 7 unchanged - 0 fixed = 8 total (was 7)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
18m 49s
Patch does not cause any errors with Hadoop 2.10.0 or 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
2m 59s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 22s
The patch does not generate ASF License warnings.

52m 57s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3168

Optional Tests
dupname asflicense javac hadoopcheck xml compile spotbugs hbaseanti checkstyle

uname
Linux b3e587c83cfc 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / cc90e4fef4

Default Java
AdoptOpenJDK-1.8.0_282-b08

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/artifact/yetus-general-check/output/diff-compile-javac-hbase-http.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-http.txt

Max. process+thread count
86 (vs. ulimit of 12500)

modules
C: hbase-http hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 11s
Docker mode activated.

-0 :warning:
yetus
0m  8s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.3 Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 39s
branch-2.3 passed

+1 :green_heart:
compile
1m 30s
branch-2.3 passed

+1 :green_heart:
shadedjars
6m 33s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
branch-2.3 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 23s
the patch passed

+1 :green_heart:
compile
1m 33s
the patch passed

+1 :green_heart:
javac
1m 33s
the patch passed

+1 :green_heart:
shadedjars
6m 28s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 57s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 51s
hbase-http in the patch passed.

+1 :green_heart:
unit
188m 27s
hbase-server in the patch passed.

220m 17s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3168

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux c7c27a106476 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / cc90e4fef4

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/testReport/

Max. process+thread count
2615 (vs. ulimit of 12500)

modules
C: hbase-http hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 26s
Docker mode activated.

-0 :warning:
yetus
0m  8s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2.3 Compile Tests _

+0 :ok:
mvndep
0m 19s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 33s
branch-2.3 passed

+1 :green_heart:
compile
1m 27s
branch-2.3 passed

+1 :green_heart:
shadedjars
6m  2s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 58s
branch-2.3 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 59s
the patch passed

+1 :green_heart:
compile
1m 28s
the patch passed

+1 :green_heart:
javac
1m 28s
the patch passed

+1 :green_heart:
shadedjars
5m 56s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 54s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 14s
hbase-http in the patch passed.

+1 :green_heart:
unit
208m  7s
hbase-server in the patch passed.

239m  6s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3168

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux<PHONE_NUMBER>cd 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.3 / cc90e4fef4

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/testReport/

Max. process+thread count
2763 (vs. ulimit of 12500)

modules
C: hbase-http hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3168/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Fix Open Graph + Twitter Card metadata

Fixes #46
Changes

Fixes Open Graph metadata by using absolute URLs (required by spec[source])
Adds a Twitter card
Fixes site.url and site.baseurl to match Jekyll convention[source] (potentially breaking)
Added comments to _config.yml to document site.url and site.baseurl

How Has This Been Tested?
We updated site.url and site.baseurl, deployed the template to GitHub Pages, and verified results with https://metatags.io/
Mentions

@Korusuke
@LucasLobo

Types of changes

[x] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature and improvements (non-breaking change which adds/improves functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Code Refactoring (internal change which is not user facing)
[x] Documentation
[ ] Test, CI, or build

Checklist

[x] Coding style of this project is followed
[ ] Change in documentation is required
[x] Documentation has been updated accordingly
[ ] Unit tests have been added to cover code change

@LucasLobo unsure if GitHub notifies for mentions coming from edits, so sorry for the double ping if so. I just fixed the project and resume URL generation that would result from the site.url and site.baseurl changes we propose.

I can't try it out right now, but don't forget to test whether the linking is still working for all pages and sub-pages. That might be a problem due to the change in the _config.yml file.

As I understand it, as long as absolute URLs are generated as {{ '/relative/url' | absolute_url }}, they should be compatible with whatever changes happen with site.url and site.baseurl even if the config doesn't exactly match convention. I'm going to check existing code upstream and pending PRs to make sure nobody is doing stuff like {{ site.url }}/relative/url

Fully tested my changes with a development deployment of Jekyll, clicking on every link and checking the console to see if any 404 errors popped up.


Added ability to specify audio channels and sample rate

Added option to specify number of channels for audio extraction. Also added support for specifying sample rate as part of the "audio quality" parameter. Integers greater than 8000 will be interpreted as the sampling rate, thus 8000 is the minimal.

I'm still not sure what this option would be used for, and there has been no update since my inquiry well over a year ago. I must therefore sadly reject this PR. Feel free to comment and provide context for this PR and we will re-discuss it. Thanks!


Default sort order by schema:identifier in graph and legend according to dataset

https://gitlab.ldbar.ch/bafu/umweltdatenkiosk-planning/-/issues/119

@ptbrowne just ensure: the default sort order by identifier shall be the prefered & preselected one.
of course, afterwards a user is free to choose among all the existing possibilities.


Dockerfile and CUDA and CUDNN issues with GPU detected

Trying to build from a CI/CD I got the following
builderror.txt.zip
see zip attached
important parts
-- Found CUDNN: /usr/lib/x86_64-linux-gnu/libcudnn.so
-- Found cuDNN: v8.9.6  (include: /usr/include, library: /usr/lib/x86_64-linux-gnu/libcudnn.so)
CMake Warning at External/libtorch/share/cmake/Caffe2/public/cuda.cmake:214 (message):
  Failed to compute shorthash for libnvrtc.so
Call Stack (most recent call first):
  External/libtorch/share/cmake/Caffe2/Caffe2Config.cmake:92 (include)
  External/libtorch/share/cmake/Torch/TorchConfig.cmake:68 (find_package)
  CMakeLists.txt:78 (find_package)

-- Automatic GPU detection failed. Building for common architectures.
-- Autodetected CUDA architecture(s): 3.5;5.0;5.2;6.0;6.1;7.0;7.5;8.0;8.6;8.6+PTX
-- Added CUDA NVCC flags for: -gencode;arch=compute_35,code=sm_35;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_52,code=sm_52;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86;-gencode;arch=compute_86,code=compute_86
-- Found Torch: /app/External/libtorch/lib/libtorch.so
-- Package torch                      Yes, at /app/External/libtorch/include;/app/External/libtorch/include/torch/csrc/api/include
CMAKE_EXE_LINKER_FLAGS before: -Wl,--no-as-needed
TORCH_LIBRARIES: torch;torch_library;/app/External/libtorch/lib/libc10.so;/app/External/libtorch/lib/libkineto.a;/usr/local/cuda/lib64/stubs/libcuda.so;/usr/local/cuda/lib64/libnvrtc.so;/usr/local/cuda/lib64/libnvToolsExt.so;/usr/local/cuda/lib64/libcudart.so;/app/External/libtorch/lib/libc10_cuda.so
TORCH_CXX_FLAGS: -D_GLIBCXX_USE_CXX11_ABI=1
CMAKE_EXE_LINKER_FLAGS after: -Wl,--as-needed
CUDNN_LIBRARY_PATH: /usr/lib/x86_64-linux-gnu/libcudnn.so; CUDNN_INCLUDE_PATH: /usr/include
-- Obtained CUDA architectures automatically from installed GPUs
-- Automatic GPU detection failed. Building for Turing and Ampere as a best guess.
-- Targeting CUDA architectures: 75;86

-- SAIGA_CUDA_VERSION
-- Found CUDAToolkit: /usr/local/cuda/targets/x86_64-linux/include (found suitable version "11.8.89", minimum required is "10.2")
-- Enabled CUDA. Version: 11.8.89
-- Package CUDA::cudart               Yes, at /usr/local/cuda/targets/x86_64-linux/include
-- Package CUDA::nppif                Yes, at /usr/local/cuda/targets/x86_64-linux/include
-- Package CUDA::nppig                Yes, at /usr/local/cuda/targets/x86_64-linux/include
-- SAIGA_CUDA_FLAGS: -Xcompiler=-fopenmp;-Xcompiler=-march=native;-use_fast_math;--expt-relaxed-constexpr;-Xcudafe=--diag_suppress=esa_on_defaulted_function_ignored;-Xcudafe=--diag_suppress=field_without_dll_interface;-Xcudafe=--diag_suppress=base_class_has_different_dll_interface;-Xcudafe=--diag_suppress=dll_interface_conflict_none_assumed;-Xcudafe=--diag_suppress=dll_interface_conflict_dllexport_assumed
-- Using automatic CUDA Arch detection...
-- Automatic GPU detection failed. Building for common architectures.
-- Autodetected CUDA architecture(s): 3.5;5.0;5.2;6.0;6.1;7.0;7.5;8.0;8.6;8.6+PTX
-- SAIGA_CUDA_ARCH:
-- SAIGA_CUDA_ARCH_FLAGS: -gencode;arch=compute_35,code=sm_35;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_52,code=sm_52;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86;-gencode;arch=compute_86,code=compute_86
--
Compiler Flags:
-- SAIGA_CXX_FLAGS: -Wall;-Werror=return-type;-Wno-strict-aliasing;-Wno-sign-compare;-march=native;-fopenmp
-- SAIGA_PRIVATE_CXX_FLAGS: -fvisibility=hidden
-- SAIGA_LD_FLAGS: -fopenmp
-- CMAKE_CXX_FLAGS:
-- CMAKE_CXX_FLAGS_DEBUG: -g
-- CMAKE_CXX_FLAGS_RELWITHDEBINFO: -O2 -g -DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE: -O3 -DNDEBUG
--
CUDA Compiler Flags:
-- CMAKE_CUDA_FLAGS:
-- CMAKE_CUDA_FLAGS_DEBUG: -g
-- CMAKE_CUDA_FLAGS_RELWITHDEBINFO: -O2 -g -DNDEBUG
-- CMAKE_CUDA_FLAGS_RELEASE: -O3 -DNDEBUG

[ 17%] Built target signalhandler_unittest
[ 17%] Building CUDA object External/tiny-cuda-nn/CMakeFiles/tiny-cuda-nn.dir/src/common.cu.o
nvcc warning : The 'compute_35', 'compute_37', 'sm_35', and 'sm_37' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
nvcc fatal   : A single input file is required for a non-link phase when an outputfile is specified
make[2]: *** [External/tiny-cuda-nn/CMakeFiles/tiny-cuda-nn.dir/build.make:77: External/tiny-cuda-nn/CMakeFiles/tiny-cuda-nn.dir/src/common.cu.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2579: External/tiny-cuda-nn/CMakeFiles/tiny-cuda-nn.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

@michaldigimansai
Do you have anything you can suggest?

looks like there is no GPU available

It sort of relates to
https://stackoverflow.com/questions/59691207/docker-build-with-nvidia-runtime/61737404#61737404
Because the same thing happened on my machine, I will look into a kaniko based solution in kubernetes because this is the runtime environment.

Looks like docker in docker kaniko is required
https://gitlab.cvh-server.de/ckaufmann/gpu-cluster-images/-/blob/master/README.md#build-with-kaniko


Update tree is empty after restart

The tool recently stopped showing updates after a restart. Updates can be generated normally and without error messages, these are then also displayed in the update tree on the left. If the tool is closed and restarted, no more updates are displayed. In fact, such updates are apparently still in the database, because they can still be displayed in the WSUS console.
The problem occurs in both the current and previous versions of the software.

Please check if the option «Show locally-published Updates that are also visible in Wsus Console» in enable under Tools->Settings->Updates

Ohhh..... Thank you, that solved the problem. :-)


Question: Regarding unauth-guard

I have 2 questions for my learning. In your unauth-guard.ts

Why !authState return primitive boolean but when console.log(!authState) shows as object
Why console.log(unauthenticated); gets printed but console.log('there', x) cannot be printed.

Thanks.
 canActivate(route: ActivatedRouteSnapshot): Observable<boolean> {
    let y = this.getAuthState();
    console.log('buddy' ,y);

    return this.af.auth
      .take(1)
      .map(authState => !authState)
      .do(unauthenticated => {
        console.log(unauthenticated);
        /*if (!unauthenticated) {
          this.router.navigate(['/dashboard']);
        } */
      });
  }

  getAuthState() : Observable<any> {
    return this.af.auth
      .take(1)
      .map(authState => !authState)
      .do(x => {console.log('there', x)});
  }

console.log('there', x) will not print until you subscribe to the observable that is being returned by getAuthState():
let y = this.getAuthState();
y.subscribe(value => console.log('buddy', y));

Angular2 subscribes to the observable returned by canActivate() and uses the emitted value to determine if the route should be activated.


Bug running deployment on macOS

Just tested the framework on a macOS Monterey (12.3.1) using Python 3.7.9.
Training works just fine, but deployment crashes.
First time running can also be a bit slow, but that is likely due to macOS running some security checks.
Sudo is also required to run the software, likely due to keyboard library being used. The same was observed on Ubuntu.
Error prompt after running deployment:
Traceback (most recent call last):
  File "main.py", line 49, in <module>
    run(ret)
  File "/Users/X/workspace/super-ml-pets/src/deploy_agent.py", line 98, in run
    model = MaskablePPO.load(ret.infer_model, custom_objects=custom_objects)
  File "/Users/X/workspace/super-ml-pets/venv/lib/python3.7/site-packages/stable_baselines3/common/base_class.py", line 705, in load
    path, device=device, custom_objects=custom_objects, print_system_info=print_system_info
  File "/Users/X/workspace/super-ml-pets/venv/lib/python3.7/site-packages/stable_baselines3/common/save_util.py", line 435, in load_from_zip_file
    th_object = th.load(file_content, map_location=device)
  File "/Users/X/workspace/super-ml-pets/venv/lib/python3.7/site-packages/torch/serialization.py", line 713, in load
    return _legacy_load(opened_file, map_location, pickle_module, **pickle_load_args)
  File "/Users/X/workspace/super-ml-pets/venv/lib/python3.7/site-packages/torch/serialization.py", line 920, in _legacy_load
    magic_number = pickle_module.load(f, **pickle_load_args)
_pickle.UnpicklingError: invalid load key, '\x00'.

There was nothing wrong with deployment on macOS!
When downloading the model from releases, be sure to download a model that was trained in the same python version you are using or older. If model trained in 3.7, using Python >= 3.7. The latest released models were trained on Python 3.8, hence,  Python 3.7 might fail to load these.
Also, when downloading the models (.zip) files, they will be automatically unzipped (macOS aids). This is bad. You can disable this by going to the Safari Preferences and disable "Open safe files after downloading".
Also note that the screen resolution on the laptop did not match the expected 1920x1080. But using a different monitor it worked just fine :)


[Suggestion] Get Timeline of a Build

I was recently making some tests with Azure Pipeline with Pipeline Artifacts vs Build Artifacts. With that I needed to get the timeline of around 400 builds I triggered. I saw this functionality is missing. Basically it would call the following API method:
https://docs.microsoft.com/en-us/rest/api/azure/devops/build/timeline/get?view=azure-devops-rest-5.0
I could try to include it myself and make a PR, but I have some questions:

Should it be an extra command?
Should it be uncluded as a property with Get-VSTeamBuild?
Do I need to create an object with format files or just return the JSON object?

Sorry for the delay. Let me review the current code and get back to you.

@DarqueWarrior any news on my questions? I am aware that you are busy! :-)

I would call it Get-VSTeamBuildTimeline
I don't think it needs to be in the build object
You don't have to create an object but you should have format files.

@DarqueWarrior a quick side question: When is it appropriate to create objects for data returned?

I added the function and it seems to work basically, but there is a problem. it seems like that the planId and changeId parameters do not seem to have any effect on the API. But I am also not sure what they would do in certain scenarios.
If I give a "fake" id in one of those, the API returns the same results when leaving them out.
Also when you have a timeline the records are pretty much unsorted and they have a hierarchie, but are ordered in a flat list.
I have a public project, where you have an example:
https://dev.azure.com/razorspoint-test/Pipeline Artifacts vs Build Artifacts/_apis/build/builds/574/timeline?api-version=5.0
https://dev.azure.com/razorspoint-test/Pipeline Artifacts vs Build Artifacts/_build/results?buildId=574
I used this project to test the performance of build agents with "build artifacts" versus "pipeline artifacts". To get a better overview of the pipeline, I converted the flat timeline array into a tree of arrays (like in my following gist).
Would you like to have the option to return it as a tree? And if yes, should I define this as a nested function?

@DarqueWarrior do you have any idea about the problem in my previous post?

Hey @willsmythe can you help here?

@SebastianSchuetze Just leave the plan id out if you don't know what it's doing, and PR this.
Issue has been open for a while now :)

Also, make sure BuildID and ProjectID/Name are mandatory

This has been merged into master and will be out with the next release.


Segfault in libffi.so when using dask processes

I have already posted this to the dask github, however I am not sure if this is related to dask or umap.
The following script segfaults on an updated  Cent OS 7 machine in libffi.so
https://gist.github.com/goraj/ed099c80cd8233e9e8463b37384b2470
The crash triggers depending on what arguments I pass. Importing umap-learn is mandatory to reproduce however.
To reproduce uncomment line 31 and comment 34.
python version: 3.7.1.
dask version: 1.0.0
umap version: 0.3.7
It would be great if someone here can test to reproduce this issue.

@lmcinnes thank you.
To reproduce this issue:
./Miniconda3-latest-Linux-x86_64.sh -b -p ~/m3_centos7
source ~/m3_centos7/bin/activate;conda create -n projectname python=3.6
conda activate projectname
conda install dask distributed
pip install umap-learn
python ~/reproduce.py
output can be seen here: https://gist.github.com/goraj/4f38a803e4d9a02ba54e8b61183a81ea

@goraj Is this still a problem? If yes, does dask provide any more output than "Got killed" ?

@sleighsoft, I think this can be closed. I was unable to reproduce this issue on other machines.

Thank you for your timely reply. Great to hear :)


Remove IsReadOnly checks and add/update tests

@dougbu @rynowak Can you let me know if the direction here is the one as we discussed?
I added a test as per the issue https://github.com/aspnet/Home/issues/1631
I am planning to add more tests.

@kichalla this looks like it's going in the right direction. I'm not sure however that you've covered enough readonly cases. Basic thing to look for: Have lots of integration tests covering at least the same scenarios as the unit tests you removed. More generally:

Have tests using TryUpdateModelAsync() that succeed or fail with array models, enumerations, et cetera as they did before your test.
Have tests involving readonly properties of the types the changed model binders handle. Again they should succeed or fail as they did before your changes (though they might fail a bit later).

:watch:

:up: :date:

:watch:

:up: :date:
@dougbu I noticed that following tests do not have a test attribute because of which they have not been running. They fail when I enable them(happens in 1.0 version too). Both of the tests are almost the same (one tests with prefix and the other not). The model state is invalid in these tests as the data is in Unvalidated state.
https://github.com/aspnet/Mvc/blob/dev/test/Microsoft.AspNetCore.Mvc.IntegrationTests/TryUpdateModelIntegrationTest.cs#L359
https://github.com/aspnet/Mvc/blob/dev/test/Microsoft.AspNetCore.Mvc.IntegrationTests/TryUpdateModelIntegrationTest.cs#L821

The model state is invalid in these tests as the data is in Unvalidated state.

Great you caught the missing [Fact] attributes. Update the tests to match current expectations i.e. check for the Unvalidated data. And definitely enable them.

:watch: just for a couple of misplaced tests (revert all changes to FormCollectionModelBindingIntegrationTest -- PR doesn't affect FormCollection handling) and last test mentioned here.

:up: :date:

:shipit:


[backport] Update instance types in EKS worker template

https://github.com/rancher/rancher/issues/24035

Reproduced the issue with v2.3.0
Created a EKS cluster with t3a.medium  nodes. EKS cluster fails with the below error

Error creating stack with worker nodes template: error creating master: ValidationError: Parameter NodeInstanceType failed to satisfy constraint: Must be a valid EC2 instance type status code: 400, request id: bd485ba5-3496-4768-9f8c-344fd0de49a7
--


NameReg?

Why are you not using the Global Official Name Registry? Just Curious.

@rfikki I believe global NameReg still has some conflicting designs with WeiFund. I'm using a bytes32 namereg, I think they are using a string namereg. I could be wrong. But naturally, I'll integrate the global namereg when I can and when it makes sense to do so. Valid point none the less.

Hi Nick.
I am very interested in your project and want to make sure it succeeds. The global registry is in place now, and will be released as part of geth v1.3.0.
For now you can set these manually.
admin.setGlobalRegistrar("0x33990122638b9132ca29c723bdf037f1a891a70c")
admin.setHashReg("0x23bf622b5a65f6060d855fca401133ded3520620")
admin.setUrlHint("0x73ed5ef6c010727dfd2671dbb70faac19ec18626")
For mor info see: https://github.com/ethereum/go-ethereum/pull/1840/files#diff-591d794d5247448444354652052633ccR57


Docker - sass - "SassError: Can't find stylesheet to import" at build time

Description
Everything is ok in local environment, no issue with yarn start or yarn run build, no issue with dockerify devlopment but dockerify production give me an error:
Step 6/10 : RUN yarn run build
 ---> Running in 5658ba377242
yarn run v1.22.5
$ react-scripts build
Creating an optimized production build...
Failed to compile.
./src/index.scss
SassError: Can't find stylesheet to import.
41 │ @import "App/_App.scss";
   │         ^^^^^^^^^^^^^^^
   ╵
  /app/src/index.scss 41:9  root stylesheet

Environment
Docker Desktop on Windows
create-react-app: 4.0.0
node: 14.15.0
package.json
{
  "name": "print-frt",
  "homepage": "/print/r",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@fortawesome/fontawesome-free": "^5.13.1",
    "@reduxjs/toolkit": "^1.4.0",
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.3.2",
    "@testing-library/user-event": "^7.1.2",
    "bootstrap": "^4.5.0",
    "classnames": "^2.2.6",
    "formik": "^2.2.0",
    "jsog": "^1.0.7",
    "jwt-decode": "^2.2.0",
    "normalizr": "^3.6.0",
    "react": "^16.13.1",
    "react-bootstrap": "^1.2.0",
    "react-dom": "^16.13.1",
    "react-icons": "^3.11.0",
    "react-outside-click-handler": "^1.3.0",
    "react-redux": "^7.2.1",
    "react-router-dom": "^5.2.0",
    "react-scripts": "4.0.0",
    "react-select": "^3.1.0",
    "react-spinners": "^0.9.0",
    "redux": "^4.0.5",
    "sass": "^1.29.0",
    "yup": "^0.29.3"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

DockerFile.prod
FROM node:alpine
WORKDIR /app
COPY package.json /app
RUN yarn install
COPY . /app
RUN yarn run build

DockerFile.dev
FROM node:alpine
WORKDIR /app
COPY package.json /app
RUN yarn install
COPY . /app
CMD ["yarn", "start"]

To reproduce
From cra project

yarn add sass or yarn add node-sass
Add two .scss files with an @import
docker build . -tag prod

More information
I tried to set SASS_PATH but no more success.
Running yarn run build before dockerify and just copy build directory is working.
When building Deckerfile.dev, I have to set volumes
    volumes:       - ".:/app"       - "/app/node_modules"
to get it working otherwise, I have the same issue.
I'm not enough familiar with those technologies, but is this something in webpack to fix like into this github post?

Ok. I found the solution. It's a strange mistake in directory name which didn't stop compilation in local (whereas it should) but fail during dockerify in production context only.

Ok. I found the solution. It's a strange mistake in directory name which didn't stop compilation in local (whereas it should) but fail during dockerify in production context only.

@lambrosx77 Can you please share the solution? I'm getting the exact same error.

@DawoodShahat
I've had similar issue. In one scss file I had @import 'src/app/colors.module'; and in another one @import 'src/App/colors.module';. Windows machine ate both paths, since the filesystem was case-insensitive, but linux inside container couldn't get to the file.

Where can I find a solution to this error in build? I am having the same issue


error performing db migrations on AWS RDS postgres

Hi there ... when deploying genie from scratch and using an AWS RDS postgres db instance for genie an error is encountered caused by this line in the 3.2.0 migration script. This is caused as the RDS postgres master user isn't actually a super user and fails to alter certain (if not all) native extensions.
Steps to re-produce:

launch any flavor of RDS that supports postgres
setup sample config like this:

printf '
spring.profiles.active=prod
' > ./application.properties

printf '
spring.datasource.url=jdbc:postgresql://<rds_end_point>/genie
spring.datasource.username=genie
spring.datasource.password=<password>
' > ./application-prod.properties

java -jar path/to/geniejar

actual error when launched:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.internal.command.DbMigrate$FlywayMigrateSqlException:
Migration V3_2_0__Base_Version.sql failed
-----------------------------------------
SQL State  : 42501
Error Code : 0
Message    : ERROR: must be owner of extension plpgsql
Location   : db/migration/postgresql/V3_2_0__Base_Version.sql (/tmp/genie_test/file:/tmp/genie_test/genie.jar!/BOOT-INF/lib/genie-web-3.3.12.jar!/db/migration/postgresql/V3_2_0__Base_Version.sql)
Line       : 46
Statement  : COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'

Seeing as this is a simple fix and specific to AWS/postgres i'll leave it up to you guys to decide if its worthwhile to remove/alter the sql statement or just add documentation noting this breaks on AWS RDS postgres.
Thanks for the great project and work!

Hi @shinka81 thanks for the detailed report.
Someone else has brought this up recently too in the google group.
The problem now is if we change the V3_2_0__Base_Version.sql file in the repository and anyone who has already deployed tries to deploy a later version their deployment will fail due to the hash not matching between the files in the flyway schema_version table. However if this is breaking a lot of users we may have to do it.
We don't use Postgres internally so those scripts I've only really tested locally on my machine which has I guess the latest greatest postgres and I had admin rights.
What version of postgres are you using in RDS? We test in our integration tests on Travis using 9.6.
@mprimi and I will have a discussion next week about what we should do about this case

That's a valid reason to not change it.
What I can offer is a work around for others who are hitting this which is telling flyway to start its initial migration from the 3.3.0 sql script and run a modified 3.2.0 script (which just has that line omitted) prior to launching genie:
printf '
spring.profiles.active=prod
spring.flyway.baseline-version=3.3.0
' > ./application.properties

This way new users can keep taking future migrations and this won't break existing deployments changing the hash of the 1st migration on working non-AWS deployments.

Hi everyone, I also want to be a contributor for this great project. Can anyone help me in that ?

Hello @princejha95, thanks for your interest.
So far this project has been developed and maintained internally at Netflix, we don't have a formal process in place to accept external contributions. But we could potentially figure something out.
Is there any particular feature or change you'd like to see?

Hi Marco, thanks for your response. Actually i am a fresher in the IT
industry (1.2 yrs experience) and currently i am working in VMware. So
apart from my day to day work in the office, i also want to learn something
new. If this project is not available, then can you please suggest me some
good open source projects in Java on which i can work so that i keep my
updated with the good coding practice that are used by professionals ?
Thanks,
Prince
On Wed, Oct 30, 2019 at 3:19 AM Marco Primi<EMAIL_ADDRESS>wrote:

Hello @princejha95 https://github.com/princejha95, thanks for your
interest.
So far this project has been developed and maintained internally at
Netflix, we don't have a formal process in place to accept external
contributions. But we could potentially figure something out.
Is there any particular feature or change you'd like to see?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Netflix/genie/issues/767?email_source=notifications&email_token=ADGUN4AR5NG5D23W3TDQ5NDQRCVWVA5CNFSM4FJ3UQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECSGM3Q#issuecomment-547645038,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGUN4E3AS5GRIJGQSHIWKTQRCVWVANCNFSM4FJ3UQRQ
.


WIP: Potel sampling

Sampling using Potel
Fixes https://github.com/getsentry/sentry-python/issues/3318

Thank you for contributing to sentry-python! Please add tests to validate your changes, and lint your code using tox -e linters.
Running the test suite on your PR might require maintainer approval. The AWS Lambda tests additionally require a maintainer to add a special label, and they will fail until this label is added.

Closing in favor of: https://github.com/getsentry/sentry-python/pull/3501


Add support for builtin treesit using helix queries

This branch, currently experimental, adds evil-texobj-tree-sitter with the builtin treesit using texobject queries from helix. Although neovim has more complete queries, the builtin treesit cannot parse most of them. This still gets you most of the way there, but will only miss a few QOL stuff like not including brackets when selecting inside a function etc. The idea is to keep this open and dogfood it for a while and merge it in eventually.
(use-package evil-textobj-tree-sitter
  :straight (evil-textobj-tree-sitter
             :host github
             :repo "meain/evil-textobj-tree-sitter"
             :files (:defaults "queries" "treesit-queries")
             :branch "treesit")))

You can use this branch with straight like above. For more information refer https://github.com/meain/evil-textobj-tree-sitter/issues/76
TODOs

[ ] Update melpa with queries-dir
[ ] Update readme with mention about treesit and updated installation instructions
[ ] Mention about usage and state of helix grammars
[ ] Ensure we have enough tests for the treesit side

Hey @meain thanks for doing this, I can't wait for the built-in treesit support.
I was trying this branch with:
(use-package evil-textobj-tree-sitter
  :after (evil treesit)
  :straight (evil-textobj-tree-sitter
             :host github
             :repo "meain/evil-textobj-tree-sitter"
             :branch "treesit")
  :config
  ;; bind `function.outer`(entire function block) to `f` for use in things like `vaf`, `yaf`
  (define-key evil-outer-text-objects-map "f" (evil-textobj-tree-sitter-get-textobj "function.outer"))
  ;; bind `function.inner`(function block without name and args) to `f` for use in things like `vif`, `yif`
  (define-key evil-inner-text-objects-map "f" (evil-textobj-tree-sitter-get-textobj "function.inner"))
...

Then, in a go-ts-mode or rust-ts-mode buffer I run (thing-at-point 'function) or (thing-at-point 'loop) and I got this errors:
Debugger entered--Lisp error: (wrong-type-argument treesit-query-p nil)
  evil-textobj-tree-sitter--treesit-get-nodes(nil)
  evil-textobj-tree-sitter--get-nodes((function.outer) nil)
  evil-textobj-tree-sitter--get-within((function.outer) 1 nil)
  evil-textobj-tree-sitter--thing-at-point-bounds("function.outer")
  #f(compiled-function () #<bytecode 0x1bec2b3405c72eb8>)()
  bounds-of-thing-at-point(function)
  thing-at-point(function)
  eval-expression((thing-at-point 'function) nil nil 127)
  funcall-interactively(eval-expression (thing-at-point 'function) nil nil 127)
  command-execute(eval-expression)

Debugger entered--Lisp error: (wrong-type-argument treesit-query-p nil)
  evil-textobj-tree-sitter--treesit-get-nodes(nil)
  evil-textobj-tree-sitter--get-nodes((loop.outer) nil)
  evil-textobj-tree-sitter--get-within((loop.outer) 1 nil)
  evil-textobj-tree-sitter--thing-at-point-bounds("loop.outer")
  #f(compiled-function () #<bytecode -0x1487bd632c2abf5>)()
  bounds-of-thing-at-point(loop)
  thing-at-point(loop)
  eval-expression((thing-at-point 'loop) nil nil 127)
  funcall-interactively(eval-expression (thing-at-point 'loop) nil nil 127)
  command-execute(eval-expression)

(emacs-version)
GNU Emacs 30.0.50 (build 3, aarch64-apple-darwin22.4.0, NS appkit-2299.50 Version 13.3.1 (Build 22E261)) of 2023-05-09

@d1egoaz Thanks for trying it out. I had missed including :files (:defaults "queries" "treesit-queries") bit in the config. We need to explicit specify it to load the query directories as they are not elisp files. I've updated the original comment. You'll just have to update your :straight block to include the :files section like above.
PS: You might have to delete ~/.config/emacs/straight/build/evil-textobj-tree-sitter for straight to pick up the change and rebuild it.

If my cursor is in the if statement, (thing-at-point 'function) works as expected, however for 'conditional, or 'loop it returns nil

You were on the right track with "... but it isn't in<EMAIL_ADDRESS>The helix queries (which we use for treesit) are still in the early stages and does not provide loop or conditional textobjects.

If the cursor is in the x := 1, calling (thing-at-point 'function) also return nil.

Hmm, somehow I am not able to repro this. Where on this line is the cursor when you call the function?

Thanks!!

If the cursor is in the x := 1, calling (thing-at-point 'function) also return nil.

Hmm, somehow I am not able to repro this. Where on this line is the cursor when you call the function?

Ohh sorry, I meant to say (thing-at-point 'assignment))
Which I think the answer is the same as your previous answer.
Thanks!

I ran a couple tests on some julia code, and 'vaf' almost seemed to find the correct bounds but offset by ~10 each time.
my config was
(use-package evil-textobj-tree-sitter)
(define-key evil-outer-text-objects-map "f" (evil-textobj-tree-sitter-get-textobj "function.outer"))
(define-key evil-inner-text-objects-map "f" (evil-textobj-tree-sitter-get-textobj "function.inner"))

Thanks for all your work!

Also, i tried it on some elisp, and vaf, gave me this error,
evil-textobj-tree-sitter--elisp-tree-sitter-get-nodes: Wrong type argument: user-ptrp, nil

I notice combobulate has a more graceful error message here
treesit-node-on: No available parser for this buffer

In (defcustom evil-textobj-tree-sitter-major-mode-language-alist nil
can you add clojure please
i.e.
modes =  clojure-mode clojurec-mode clojurescript-mode clojure-ts-mode
lang = clojure

emacs-lisp-mode wouldn't hurt too.

in golang, vaf doesn't quite get the right bounds either

@jasonjckn vaf works for me 🤔
I wonder if you have an additional mode installed, might want to check with emacs -Q

@jasonjckn vaf works for me 🤔
I wonder if you have an additional minor/mode applied, might want to check with emacs -Q

I deleted everything in my config except doom itself, and i'm still able to reproduce :(
doom-config.zip

so it must be specific to doom's configuration of evil

That is my best guess too. Since I don't use doom I don't have much clue of what exactly might be going on unfortunately but I'll maybe dig in if I find some time.

@jasonjckn I was cleaning up a few things and the problem you had might not have been a doom thing. The package was doing some extra stuff to handle non ascii or multibye buffers which is not needed for treesit and that was messing up the locations. Feel free to give the new changes a shot.

Cask in this branch still lists tree-sitter as a dependency

The deps in Cask are just for development and CI and not really used anywhere else. I am keeping tree-sitter in there as we still support it. @p00f

Ah

When trying to get an inner/outer function/class/argument in rust, I'm getting the following error:

let*: Query pattern is malformed: "Invalid predicate", "eq?", "Currently Emacs only supports equal', match', and `pred' predicates"

This appears to be due this section at the bottom of treesit-queries/rust/textobjects.scm:
(; #[test]
 (attribute_item
   (attribute
     (identifier) @_test_attribute))
 ; allow other attributes like #[should_panic] and comments
 [
   (attribute_item)
   (line_comment)
 ]*
 ; the test function
 (function_item
   body: (_) @test.inner) @test.outer
 (#eq? @_test_attribute "test"))

@Stebalien thanks for bringing up the issue. I missed the fact that treesit implementation used #equal instead of #eq? which is used by tree-sitter. I've fixed in the latest commit.


[zh] Unsupervised learning

Awesome work @tigerneil!
Now, let's wait for another native speaker to review the translation.

OK👌


ix-key-value-list label doesn't get truncated if it's too long

What happened?
In ix-key-value-list if the label is too long, the line slips compare to other lines. It's not very nice, either the entire column should be larger then, or it should be dotted and a fixed width can be given.

What type of frontend frameware are you seeing the problem on?
Angular
Which version of iX do you use?
v2.0.3
Code to produce this issue.
<ix-key-value-list>
      <ix-key-value
        label="A really looooooooooong label"
        labelPosition="left"
        value="Value"
      ></ix-key-value>

      <ix-key-value
        label="Label"
        labelPosition="left"
        value="Value"
      ></ix-key-value>

      <ix-key-value
        label="Label"
        labelPosition="left"
        value="Value"
      ></ix-key-value>
    </ix-key-value-list>

We will enhance the component to allow configuration of the overflow behaviour (multi- vs oneline).

[IX-437]


Question about inference speed

Very good work, but I have a question about the inference speed of different machines, I got 43.22 tokens/s speed on A10, but only 51.4 tokens/s speed on A100, according to my understanding at least should Twice the difference Is there any reasonable explanation for this problem? thanks.

exllama is very optimized for consumer GPU architecture so hence enterprise GPUs might not perform or scale as well, im sure @turboderp has the details of why (fp16 math and what not) but thats probably the TLDR

The A100 should be a lot faster than the A10, yes. I just haven't optimized for it specifically, partly because it's kind of tricky to set up remote CUDA profiling on a cloud server. I've been meaning to get around to it, also to figure out some weird performance degradation that happened a while ago on the H100.
There has also been a CPU bottleneck at one point, which should have been more or less dealt with, but in my experience some of these GPU cloud instances have very slow CPU cores, so that could also be part of the explanation.

What model?

llama-13b and llama-30b

some weird performance degradation that happened a while ago on the H100.
Do you think FP8 TE utilization would drastically speed up inference even more?

There has also been a CPU bottleneck at one point, which should have been more or less dealt with, but in my experience some of these GPU cloud instances have very slow CPU cores, so that could also be part of the explanation.
Is the CPU load easy to distribute? Or will the slow CPU cores on cloud instances always be a bottleneck?

Thank you

The A100 should be a lot faster than the A10, yes. I just haven't optimized for it specifically, partly because it's kind of tricky to set up remote CUDA profiling on a cloud server. I've been meaning to get around to it, also to figure out some weird performance degradation that happened a while ago on the H100.A100应该比A10快很多，是的。我只是没有专门针对它进行优化，部分原因是在云服务器上设置远程 CUDA 分析有点棘手。我一直想解决这个问题，也想弄清楚不久前在H100上发生的一些奇怪的性能下降。
There has also been a CPU bottleneck at one point, which should have been more or less dealt with, but in my experience some of these GPU cloud instances have very slow CPU cores, so that could also be part of the explanation.在某一点上也存在 CPU 瓶颈，这应该或多或少地得到解决，但根据我的经验，其中一些 GPU 云实例的 CPU 内核非常慢，所以这也可能是解释的一部分。

The A100 should be a lot faster than the A10, yes. I just haven't optimized for it specifically, partly because it's kind of tricky to set up remote CUDA profiling on a cloud server. I've been meaning to get around to it, also to figure out some weird performance degradation that happened a while ago on the H100.
There has also been a CPU bottleneck at one point, which should have been more or less dealt with, but in my experience some of these GPU cloud instances have very slow CPU cores, so that could also be part of the explanation.

I had the similar problem even with a local physical machine.
My machine configuration is as follows：
CPU:Intel(R) Xeon(R) Platinum 8358P CPU @ 2.60GHz
NVIDIA A800-SXM4-80GB
when I run a llama-13b model. Speed: 52.25 tokens/second。
-- Inference, first pass.
** Time, Inference: 0.29 seconds
** Speed: 6675.12 tokens/second
-- Generating 128 tokens, 1920 token prompt...
** Speed: 44.69 tokens/second
-- Generating 128 tokens, 4 token prompt...
** Speed: 52.25 tokens/second
I also test on another machine with A6000 GPU, It get a better performance than A800.
Another machine configuration is as follows
CPU:Intel(R) Xeon(R) Gold 6326 CPU @ 2.90GHz
GPU:NVIDIA RTX A6000
the peformance for the llama-13b model is as follow:
-- Inference, first pass.
** Time, Inference: 0.59 seconds
** Speed: 3271.80 tokens/second
-- Generating 128 tokens, 1920 token prompt...
** Speed: 48.04 tokens/second
-- Generating 128 tokens, 4 token prompt...
** Speed: 62.40 tokens/second
Compare with A6000 GPU, On A800 GPU, the prompt speed is much better, but generate speed becomes slower.

Do you think FP8 TE utilization would drastically speed up inference even more?

The short answer is no. On prompt evaluation, sure, maybe on batches, but tensor cores don't work for matrix-vector multiplication, which is what you end up doing most of in text generation. There is (as far as I can tell) no way to utilize FP8 types outside of tensor fragments, except for some intrinsics that convert to and from other types.

Is the CPU load easy to distribute? Or will the slow CPU cores on cloud instances always be a bottleneck

Well, all the heavy lifting is done on the GPU. All you're doing on the CPU side is building a queue of CUDA operations, and the CUDA runtime will start working on the first item as soon as it's ready. So the only bar you have to meet is being able to define operations faster than the GPU can go through them. On average, even.
In principle, this should be possible on even a really slow embedded CPU. But Python is very slow. Operations that should take nanoseconds (like passing a pointer to a function or whatever) end up taking microseconds instead. And combined with GPTQ being very fast, and kernels often completing in just a few microseconds when the hidden state is small, the CPU can end up becoming a bottleneck after all.
It's all because of Python, though, so the solution is simple: do as much of the work as possible in the C++ extension. Ideally you'd define the whole forward pass in native code and just have a single call to the extension, per token. At that point, a 4090 strapped to a potato would perform about as well as a 4090 on a high-end motherboard with a 13900K.
ExLlama is still roughly shaped like the HF LlamaModel, and while a bunch of operations do get combined like this, there's still quite a bit of Python code that has to run over the forward pass. In my case, I end up with about 30% actual CPU utilization for a 7b model (you need a CUDA profiler to measure this), which means that as long as host code runs at least 30% as fast it does in my case, you won't be bottlenecked.
Now, I have a 12900K, and a Xeon Gold 6326 shouldn't be that much slower in single-threaded performance, but there may be more going on. I suspect the CUDA runtime running in a virtualized environment might behave differently, introducing extra synchronization events or something like that. Or maybe it's down to some load balancing mechanism getting tripped up? Idk. I'll have to do some profiling on a server like this, and it's a little tricky. Overall, though, the CPU doesn't have a whole lot of actual work to do here. So if there is a CPU bottleneck it's always going to be a solvable problem. Somehow.

The short answer is no.

That is odd. I might misunderstand your syatatememt but FP8 Transformer Engine (just like bfloat16 instead of float16) is "the" way to speed up H100 LLM inference latency 3x to 5x, that's what it's advertised for and what people have acutally seen
Regarding the slowness of Python: Before I dive into it, what do you expect how much faster would a pure C++ implementation be latency wise?
I really appreciate your detailed response

That is odd. I might misunderstand your syatatememt but FP8 Transformer Engine (just like bfloat16 instead of float16) is "the" way to speed up H100 LLM inference latency 3x to 5x, that's what it's advertised for and what people have acutally seen

Tensor cores help you with GEMM, not GEMV. The reason is that they work on fragments down to 4x4, so if one side of your matmul is a matrix with a height of 1, you just can't tile it with 4x4 fragments. You can pad your input and your output, but then you're doing way more work than you need to.
What this means for transformers is that anywhere you're relying on GEMM (training or long sequences) tensor cores will help greatly, but until NVIDIA comes up with some type of "vector core" to use in GEMV, you're not going to see any benefit when generating one token at a time.
Also, if they did, it's not clear that it would help since GEMV is much more easily memory-bound. I.e. it's not actually computing all those dot products that slows you down, it's reading the inputs from memory. As for that, having access to FP8 outside of fragments would open up some interesting possibilities, but it just doesn't look like it's possible right now.
And even if it were, you'd be looking at FP8 activations, not FP8 weights, since those are still much larger and much slower than GPTQ. I could imagine some alternative quantization format that relies on e3m4 precision, storing one 4-bit exponent for every group of weights rather than an FP16 scale, and then reconstructing FP8 weights trivially using bitfield operations. But that would be a whole thing on its own with a new quantizer etc. Without it you've just got an FP8 model which may be a lot smaller and faster than FP16, but still about twice the size of 4-bit GPTQ.

Regarding the slowness of Python: Before I dive into it, what do you expect how much faster would a pure C++ implementation be latency wise?

Anywhere from 0% to maybe 300% faster. It depends what you're comparing to. If you're not CPU-bound, it's because whatever host code you're running (Python, C++ or otherwise) is fast enough that it completes before the CUDA queue completes. There's no performance to gain in that case. It's why Python makes sense in the first place, even though it's a very slow interpreted language being used for ultra-high-performance compute tasks like ML.
If you're launching 100 CUDA kernels, and each kernel takes 100 ms to complete, it doesn't matter if it takes 10 ms for the CPU to queue up each kernel launch. By the time the first kernel is done, there are already 10 more kernels ready to go, and by the time those have completed the CPU will have finished all its work and is just sitting there in a busy loop waiting for the GPU. Optimizing on the CPU side makes no difference at all. But, if instead each kernel completed in 1 ms, then the CPU would become the bottleneck. The GPU would be idle 90% of the time waiting for its next assignment.
The thing about LLMs is that you end up running a lot of GPU operations over a forward pass. During training, or if you're running inference on a long sequence, those operations easily take long enough that the CPU can keep up, even if it's wasting 99.99% of its potential on Python. But once you're doing token-by-token inference the GPU operations get a lot smaller. Factor in GPTQ with its very efficient VRAM usage and suddenly Python becomes the bottleneck.
So, one of the things that makes ExLlama fast is that it tries to do enough of the host-side work in C++ where it's trivial to race ahead of the GPU. And once you do enough there's no further improvement to be made on the host. What I suspect is happening on the H100 with these Xeon servers is that, for one reason or another, the CUDA queue runs out from time to time which brings back the CPU bottleneck that should have been completely (!) eliminated otherwise. As for how much performance could be improved by addressing those issues, it's really hard to say without some in-depth profiling on those particular servers. And remote CUDA profiling is, as mentioned, kind of difficult.

Alright, I see, thank you very much!
Your explanations are very clear and conceise whilst being very detailed, I highly appreciate that.
Thank you for taking the time and effort, I learned a lot from yor comment.

@turboderp
I tested out a runpod config of a 4090 and an 6000 Ada. The problem is, that the 4090 config had a 13900k (which yielded similar performance to your benchmarks), but the 6000 Ada only has a Xeon(R) Gold 6348 CPU.
Performance on the Ada with the 3B openllama model: 128.06 tokens/second and 141.10 tokens/second.
(4090 performance: 167.22 | 221.41)
I wanted to ask you, is that because of the 6000 worse specs? Or is that purely because of the CPU? Would you suggest the 6000 Ada has the capabilities to run just as fast as the 4090 on the right CPU?
I would really like to test both GPUs on a powerful CPU but I can't at the moment. Just wanted to ask before I do the effort of lending a 6000 Ada from someone :)

Further figures:
3B orca:  (same model used before, idk why it's faster here)
164.12 / 169.92
136.24 / 136.72
127 / 137
(It fluctuates very much despite it's the only process running.)
Wizard-Vicuna-7B-Uncensored-GPTQ:  111.14 / 150.47
110 / 134
guanaco-33B-GPTQ:
30.7 / 40.35
30.73 / 40.38
guanaco-65B-GPTQ:
17.76 / 21.16
17.09 / 20.22

Would you suggest the 6000 Ada has the capabilities to run just as fast as the 4090 on the right CPU?

It's really hard to say. The A6000 Ada has anywhere from 75% to 95% of the VRAM bandwidth of the 4090, depending on where you're reading the specs. It's rated for slightly more FLOPs, but a much lower TDP.... so, yeah. I don't know.
(Most?) Xeon CPUs have pretty poor single-threaded performance, and I still suspect virtualization could have an effect on cloud servers, but there still shouldn't be much of a CPU bottleneck left. So again, not really sure.
4090 go brr, though, that much is certain. And consumer CPUs are just faster it seems. I hope to have some time soon to do more thorough tests across a range of (newer) GPUs and CPUs, to see how much I've managed to narrowly optimize for just my own hardware and what could maybe be done about it.

I see, I am also curious about the CPU bottleneck and might be able to run a test soon on local hardware without virtualization.
I just ran a 65B benchmark test on a dual 4090 (AMD EPYC 7282) runpod environment and saw 20.25 / 25.00 tps, which is considerably faster than the single 6000 Ada setup (I would argue the CPUs are kind of the same?), just for anyone who is curious.
Thank you very much for taking the time to evaluate :)

@turboderp you mentioned CPU bound computation on the cloud. I wonder is that what I am seeing.
I am running inference on a 30B model and wanting 35 tokens per second from benchmarks but am only seeing about 20 tokens / second.
It does vary quite a bit depending on the CPU
AMD EPYC 7513 32-Core Processor   ::   0.037 seconds per token
Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz  ::  0.042 seconds per token
AMD EPYC 7413 24-Core Processor ::  0.045 seconds per token

Hey @turboderp I have another question
I need a very high speed custom model. I will train it on movement prediction in a game engine and I would like to use the 3B pretrained model because of it's reasoning and retrain it all over
You said you think 500 tps is much doable, may I ask when will you consider optimizing exllama to make 500 tps possible? :)
Thank you very much

I'm currently focused on V2 which will have faster options for 3B, specifically with speculative sampling in mind. I'm undecided on how much more effort to devote to optimizing V1 given the fairly promising results for V2 so far.

I'm currently focused on V2 which will have faster options for 3B, specifically with speculative sampling in mind. I'm undecided on how much more effort to devote to optimizing V1 given the fairly promising results for V2 so far.

Oh cool!!! Do you very roughly know when you will release V2? :) I also wanted to implement speculative sampling like mentioned in some other comments, maybe I can work on that with the release of V2 or something if you didn't already implement it

I don't know. I still need to write a bunch of code, a lot of it is very experimental, and the experiments take a while to run. So it's really hard to set a timeline. I'd like to have something to show for it within a couple of weeks, but I don't know for sure.

That's great news! I am looking very forward to v2 :)

Hey @turboderp , I hope you are having a great time. I wanted to ask, what do you think, will v2 be faster on a dual 3090+SLI or dual 4090? We are looking to build a workstation and I'd love an estimate from you :)

Hey @turboderp I hope you are having a great time. I wanted to ask, what do you think, will v2 be faster on a dual 3090+SLI or dual 4090? I'd love an estimate from you :)

Probably dual 4090s will be faster. The direction I'm leaning now still uses reordering tricks that make tensor parallelism difficult, so the raw speed of the 4090 would make much more of a difference than inter-GPU bandwidth.

Ok great! I am thinking about upgrading in the next week, that's why
Just wanted to confirm with you, the 4090s will still be a rather safe bet, even after some months right?

I think so, yes. 3090s might be a better value, of course. Depending on the task at hand, they can give you like 80% of the performance at less than half the price. But then in other workloads it'll be more like a third of the performance. And certain features like FP8 just aren't supported at all on the 3090.
Personally I think I would have been happy enough with two 3090s, but it's not to the point that I regret buying the 4090. For what it's worth, I'm considering a third GPU, and if I do it'll probably end up being a 3090. Not for NVLink though, just for the price/utility ratio.

I see, thank you very much! 😊
Yes the 3090 is of amazing value, especially given that you already rock a 4090, that would be a great choice imho and you will have lots of VRAM :)

Even adding a 3090 to my slow little A4000s turned out to be an awesome choice, as it gave me about an extra 3 t/s on average!
Plus it freed up one of the A4000s so I can use it to load a second instance for testing 13B models, while the rest handle 70B.


Autocomplete Tags

Environment
NetBox version:2.4.6
Proposed Functionality
When assigning tags to equipment, it would be great if netbox "autocompleted" names to avoid duplicates variation of tags.
Use Case
User friendliness
Enables users to quickly find and select from a pre-populated list of values as they type, leveraging searching and filtering.
Database Changes
External Dependencies

Hi @snowie-swe
In my environment it does, but needs to type at least 3 symbols - v2.4.8 and v2.5.1.

Hi @snowie-swe
In my environment it does, but needs to type at least 3 symbols - v2.4.8 and v2.5.1.

Updated to 2.4.8 now and you are absolutely right :) working just fine now.


permissions on docker images depend on umask of the person doing the build

when envoy is being copied around the permissions it ends up with in the docker image
depend on the umask of the user, if the umask is restrictive, it doesn't get world executable and then fails to start
we shouldn't rely on personal setting when creating the images; all executables should be 755 (owned by root or sys)
ditto for debian
found by @diemtvu

cc @jwendell

Some more context: This happens when I run e2e_pilot test, from my local (after build docker and updateVersion, then run command like go test -v -timeout 20m ./tests/e2e/tests/pilot -hub=xxx -tag=yyy
I've tried to change umask for the envoy binary under ~/go/out/linux_amd64/release, (as well as ~go/out/linux_amd64/release/docker_scratch/proxy, just in case), but it doesn't change anything. Umask for envoy on container still missing executable for all.
k exec a-597d8fd574-jmc29 -n istio-test-app-mnx75 -c istio-proxy -- ls -l /usr/local/bin
-rwxr-x--- 8 root root 251144560 Mar 12 21:39 envoy
-rwxr-x--- 7 root root  19611888 Mar 12 21:39 pilot-agent

A quick fix for that one issue is to add
RUN chmod 755 /usr/local/bin/envoy
in the Dockerfile for proxy*
There is probably some way to fix it more globally / must be a docker faq


W-022118 TDTM exclude username case bug

Critical Changes
Changes
Issues Closed
New Metadata
Deleted Metadata

@Julian88Tex  Seems like this is working on local but failing on MetaCI. I'd suggest you add a "capture_page_screenshot" and "log_source" command  prior to the failed keyword to see if everything on MetaCI looks as it should be. Coz we cannot merge this until we get at least one successful run on MetaCI.

@Safiyab great will do. I'm guessing you're talking about the robots keyword Capture Page Screenshot?

@Safiyab @skristem it appears a reason Feature Test - Robot Unstable is failing is because it's running the qa_org flow rather than dev_org flow. QA flow has a different layout on trigger handler. Do you know if there is a primary reason why the qa_org flow is run vs. dev_org?

Yes we always use qa_org flow. It has additional metadata and layouts required for QA purposes and also for automation. If you need something that is not present in qa_org flow you might need to talk to RE team member to get it added.

@skristem Okay thanks good to know! I'll check with them about how I can modify a layout in the flow.

@davidmreed Hey, was wondering what would be the best way to determine why a field is missing on a layout based on the CCI flow. Specifically trying to figure out why Usernames_to_Exclude__c would be on the layout for Tigger Handler records on dev_org flow but not on qa_org flow. Thanks for any help pointing me in the right direction!

@skristem @Safiyab made several updates to the tests based on suggestions and it should be ready for another review thanks!

@Safiyab Thanks that makes sense... I put that in there since the Keyword will be added to NPSP.robot from another PR... I think it makes sense to make this branch merge into that one instead so I'll do that since it is dependent on it.

@skristem Thanks for the advice! Made those changes.
Unfortunately, I'm facing an issue where all the recent merges are showing as file changes in my PR. Going to be asking RelEng about how to prevent this in the future since it's the second time it's happened to me, but please let me know if my changes to that one .robot file look good. Thanks!


Adding gallery example with multiple sources

This PR contains a gallery example of a scenario with two sources  #51

Codecov Report
Patch coverage has no change and project coverage change: +0.01 :tada:

Comparison is base (e9b8004) 69.74% compared to head (07fe071) 69.75%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #52      +/-   ##
==========================================
+ Coverage   69.74%   69.75%   +0.01%
==========================================
  Files          27       27
  Lines        2036     2037       +1
==========================================
+ Hits         1420     1421       +1
  Misses        616      616

see 2 files with indirect coverage changes

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


Decode error while inferencing a batch of prompts

I'm trying to benchmark the performance of vLLM OPT. But I find that when I pass a relatively large batch of prompts to vLLM, it will raise decode error when the sequence length meets a threshold (which makes the problem look like an OOM).
A minimal reproduction for this issue:
from vllm import LLM, SamplingParams

def make_input(bs):
    return ["Hello!" for _ in range(bs)]

bs = 128
generate_length = 200

# Create a sampling params object.
sampling_params = SamplingParams(
    temperature=0.8,
    top_p=0.95,
    max_tokens=generate_length)

# Create an LLM.
llm = LLM(
    model="facebook/opt-125m",
    use_dummy_weights=True,
)
input = make_input(bs)
out = llm.generate(input, sampling_params)

When bs=128, the error happens in the 108-th token approximately. The error looks like
Traceback (most recent call last):
  File "vllm-none-problem-repro.py", line 21, in <module>
    out = llm.generate(input, sampling_params)
  File "/llm-bench/vllm-src/vllm/entrypoints/llm.py", line 127, in generate
    return self._run_engine(use_tqdm)
  File "/llm-bench/vllm-src/vllm/entrypoints/llm.py", line 147, in _run_engine
    step_outputs = self.llm_engine.step()
  File "/llm-bench/vllm-src/vllm/engine/llm_engine.py", line 246, in step
    self._decode_sequences(seq_groups)
  File "/llm-bench/vllm-src/vllm/engine/llm_engine.py", line 263, in _decode_sequences
    new_token, new_output_text = detokenize_incrementally(
  File "/llm-bench/vllm-src/vllm/transformers_utils/tokenizer.py", line 73, in detokenize_incrementally
    output_text = tokenizer.convert_tokens_to_string(output_tokens)
  File "/opt/conda/lib/python3.8/site-packages/transformers/tokenization_utils_fast.py", line 533, in convert_tokens_to_string
    return self.backend_tokenizer.decoder.decode(tokens)
TypeError: argument 'tokens': 'NoneType' object cannot be converted to 'PyString

If I use a smaller bs, the "threshold" will also increase (>108). For example, it's around 210 when bs=64. Seems that there is a limit for bs * length.

I found that the batch size is only indirectly the reason and it doesn't have anything to do with OOM or similar things. For example, if I just change the random seed to the following and keep the sequence length and batch size the same, then the bug doesn't happen anymore for this specific batch size, but it will happen for another larger one:
# Create an LLM.
llm = LLM(
    model="facebook/opt-125m",
    use_dummy_weights=True,
    seed=2,
)

This bug also doesn't happen for all models. I have observed it for LLaMA models and now also with this OPT model. The reason is that for these models there can be a mismatch between the config.vocab_size and the len(tokenizer). The model outputs a distribution over tokens in the range vocab_size, but only tokens in the range len(tokenizer) should actually be sampled. The remaining tokens are just padding and when sampling these tokens and decoding them, the result will be None instead of a string and so the exception will be thrown.
To fix this, if I change the config.vocab_size (which is 50272 for facebook/opt-125m) in the following line to 50265, i.e. len(tokenizer), then the bug doesn't happen anymore for any seed and batch size.
https://github.com/vllm-project/vllm/blob/58a072be15a4e36bee006d1c9a962e527819cf18/vllm/model_executor/models/opt.py#L276
For LLaMA & LLaMA-2, it seems like for some models on huggingface the vocab_size does correspond to the actual number of tokens that should be sampled while for some others it doesn't.
from transformers import AutoTokenizer, PretrainedConfig

print(len(AutoTokenizer.from_pretrained('meta-llama/Llama-2-13b-hf'))) # 32000
print(PretrainedConfig.from_pretrained('meta-llama/Llama-2-13b-hf').vocab_size) # 32000

print(len(AutoTokenizer.from_pretrained('NousResearch/Nous-Hermes-Llama2-13b'))) # 32001
print(PretrainedConfig.from_pretrained('NousResearch/Nous-Hermes-Llama2-13b').vocab_size) # 32032

So one could consider it a bug with the models, but it's something quite common. A fix in vLLM could be to obtain the number of tokens from the vocab.json or tokenizer.json file or by creating the tokenizer. I'm not sure what the right approach here is.

@tju01 Thank you! Now it looks like larger batch size and sequence length are just to increase the probability this error happens.

怎么替换？

@xxm1668 Modifying the vocab_size in ~/.cache/huggingface/hub/<model>/snapshots/<commit>/config.json would help.
Another solution would be modifying the vLLM. For example, if you are using opt model, you should modify vocab_size in __init__ function of OPTForCausalLM: self.sampler = Sampler(config.vocab_size)

thx

Would there be a fix to this bug?
We should essentially compare len(tokenizer.vocab) and config.vocab_size and pick the smaller value

I met the same problems. I cannot fix the problem by switching vocab_size because I am using CodeLLaMA, which use vocab_parallel_embedding and there is a assertion in it when loading weights. In order to use vocab parallel, it is also necessary for the model's vocab to be 2^n*k like.
Hard coding in LLaMAForCausalLM: self.sampler = Sampler(1111111) # for example  does solve the problem.
Simple way to fix this bug: Write another attribute whose value is len(tokenizer) (e.g., write tokenizer_vocab_size into model's config when initializing LLM) then use self.sampler = Sampler(config.tokenizer_vocab_size) instead.

Hope those information will help.

This is still an issue...

Hi all. Since this issue only exists a few models, so it would be better to add the warning log about this (#3500).

@simon-mo is there already a way to solve this problem without modifying the vLLM source code? I really would prefer not to have to maintain a fork of vLLM to use Nous-Hermes & other finetuned models...

@esmeetu any suggestion here to have a good default way to support fine-tuned model?

Looking into this
from transformers import AutoConfig, AutoTokenizer

config = AutoConfig.from_pretrained("NousResearch/Hermes-2-Pro-Mistral-7B")
tokenizer = AutoTokenizer.from_pretrained("NousResearch/Hermes-2-Pro-Mistral-7B")

print(config.vocab_size)  # >> 32032
print(len(tokenizer))         # >> 32002

So it seems like 30 tokens are missing from the tokenizer that are included in the model. Not sure how this is possible

I think the issue is that the vocab_size is expanded to be a nice multiple for the gpu during training. These tokens will generally not be sampled but cannot guarantee this
@simon-mo
I think an approach we could take is to expand the tokenizer to have more pad tokens in this scenario. This will allow

vocab_size to be a nice multiple for the gpus
gracefully handle a case where one of the "fake" tokens are predicted

Thoughts?

Had the same issue with TheBloke/Leo-Mistral-Hessianai-7B-Chat-GPTQ model from huggingface (a German model built on Llama-2). Vocab size: 32128, tokenizer len: 32002.

I took a look at how transformers deals with this problem. Their idea is simple: if we get a token id larger than the length of tokenizer length, the decode step just regard the token as an empty string.
Here is a demo:
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("facebook/opt-125m")
print(len(tokenizer)) # 50265
tokenizer.decode([340]) # a token id that exists, i.e. ' news'
tokenizer.decode([34000000]) # a token id that does not exist, returns empty string ''

@youkaichao I agree with the transformers solution. But now i can't reproduce this issue using large batch sizes. Could someone provide the reproduction code for this? cc @simon-mo @andersonbcdefg

That's not easy to reproduce, but it indeed can happen, especially when we sample for many steps, and sample out a token id that's out of the scope of the tokenizer. Basically an index-out-of-range problem.

@andersonbcdefg @Blubberblub Could you try this PR #3685?

Benchmarking Yi-34B-Chat with vllm. Encountered the same error. The decoder need to check whether the ids are inside vocab. (See image below, some ids below are missing.)

So @Toska12138 , How do you solve this problem in Yi-34B-Chat with vllm?

So @Toska12138 , How do you solve this problem in Yi-34B-Chat with vllm?

The naive way is to modify the tokenizer


Re-Designed the optIn

I thought about a new design for the optIn.
Current behaviour:

L.PM.initialize(); is called
Hooks are added to the Classes: L.Polyline.addInitHook(initPolyline);
L.PM.initialize({optIn: true); is called
Hooks are added second time to the Classes: L.Polyline.addInitHook(initPolyline); with optIn: ture

Then creating layer:

Layer created
First initHook is called
Set layer.pm = undefined
layer.pm is created if pmIgnore is not true
Second initHook is called
Set layer.pm = undefined
layer.pm is created if pmIgnore is false (because optIn = true)

With that behaviour the layer.pm object is created and in the second call the object is deleted if optIn is set (if pmIgnore is not false).
New design:

L.PM.initialize(); is called
Hooks are added to the Classes: L.Polyline.addInitHook(initPolyline);
L.PM.setOptIn(true); is called

Then creating layer:

Layer created
initHook is called
Set layer.pm = undefined
layer.pm is created if  L.PM.optIn is true and  pmIgnore is false OR pmIgnore is not true

With that behaviour the layer.pm object is only created if it is allowed and initHook is not called twice.
And the optIn can be disabled: L.PM.setOptIn(false)
Fix:
#517
And has also included function from PR #595

@codeofsumit tests added


[initPaymentSheet] Currency option on applePay > paymentSummaryItems

Describe the bug
Hi! So I'm using the Payment sheet, and I need the currency on apple pay sheet to be GBP, and not USD...can't find a field for that on the initPaymentSheet...I found on the presentApplePay, but I need on initPaymentSheet. Is this possible?
To Reproduce
This is my initPaymentSheet code:
const { error, paymentOption } = await initPaymentSheet({
        customerId: data.customer,
        setupIntentClientSecret: data.setupIntent,
        customFlow: true,
        merchantDisplayName: 'Merchant Name',
        applePay: {
          merchantCountryCode: 'GB',
          paymentSummaryItems: [
            {
              paymentType: 'Recurring',
              intervalUnit: 'year',
              intervalCount: 1,
              startDate:<PHONE_NUMBER>,
              label: 'Label',
              amount: '69.99',
            },
          ],
        },
        style: 'automatic',
        googlePay: { merchantCountryCode: 'GB', testEnv: true },
        returnURL: 'returnurl://returnurl',
      })

And this is what I see:

Expected behavior
Being able to change currency on initPaymentSheet > applePay

Hi! Can you try setting the currency with the Payment Intent on the server side? e.g. in node this would look like:
const myPaymentIntent = await stripe.paymentIntents.create({
      amount: <some amount>,
+    currency: 'gbp',
      <other params>
})

I'm having the same issue - the answer does not solve the problem.
In the original question, it uses setupIntentClientSecret, not paymentIntentClientSecret, and for setupIntent, it's impossible to set the currency.

this is being tracked in https://github.com/stripe/stripe-react-native/issues/1333