Do not use outdated user rating info to predict ratings

If the user's rating is already stored in DB that does not mean its correct. There should be a check to use db info only if its recently updated.

We just need to call the same request with leetcode.cn domain to get the contest rankings for CN region.


redis ping err

Describe the bug
Due to aws redis design issues, it is not possible to ping but can be used. In version 1.5.0, go zero added the logic of not being able to start if ping fails. It is recommended to delete this thing or just prompt?
To Reproduce
Steps to reproduce the behavior, if applicable:

The code is
   // NewRedis returns a Redis with given options.
   func NewRedis(conf RedisConf, opts ...Option) (*Redis, error) {
     if err := conf.Validate(); err != nil {
 	    return nil, err
     }

     if conf.Type == ClusterType {
 	    opts = append([]Option{Cluster()}, opts...)
     }
     if len(conf.Pass) > 0 {
 	    opts = append([]Option{WithPass(conf.Pass)}, opts...)
     }
     if conf.Tls {
 	    opts = append([]Option{WithTLS()}, opts...)
     }

     rds := newRedis(conf.Host, opts...)
     if !rds.Ping() {
 	    return nil, ErrPing
     }

     return rds, nil
   }

  // MustNewRedis returns a Redis with given options.
 func MustNewRedis(conf RedisConf, opts ...Option) *Redis {
     rds, err := NewRedis(conf, opts...)
     if err != nil {
 	    log.Fatal(err)
     }

     return rds
 }

The error is
 if !rds.Ping() {
 	    return nil, ErrPing
 }

Is there any docs from AWS that tells PING is not allowed?

aws no direct documents(Configuring the icmp protocol does not work). However, Redis itself is also connected through the tcp or tls protocol. It is also common sense that we cannot ping but can operate Redis

go-redis v8不支持redis7

最近有相关的更新计划吗 @kevwan


Edit single feature in widget

From Havana, it would be desirable to edit feature attributes while interacting with evidence tracks. We could do this by creating a feature editing widget that can be opened to edit a single feature, and since it is on the side, users can still interact with the tracks.

In packages/jbrowse-plugin-apollo/src/index.ts in the install method, add a WidgetType for Apollo feature details, something like this:
pluginManager.addWidgetType(
  () =>
    new WidgetType({
      name: 'ApolloFeatureDetails',
      heading: 'Apollo feature details',
      configSchema: ConfigurationSchema('ApolloFeatureDetailsWidget', {}),
      stateModel: stateModelFactory(pluginManager),
      ReactComponent: ApolloFeatureDetails,
    }),
)

The code for the widget can go in a new folder called packages/jbrowse-plugin-apollo/src/FeatureDetailsWidget.
Need to factor the feature attribute editing panel out from packages/jbrowse-plugin-apollo/src/components/ModifyFeatureAttribute.tsx and use the same panel in both that dialog and the ApolloFeatureDetails widget React component.
This widget will get shown when a user right-clicks on a feature and selects a "Edit feature details" menu item.
Here's an example of how to show a widget from a menu:
{
  label: 'Edit feature details',
  icon: EditIcon,
  onClick: () => {
    if (self.session) {
      self.session.showWidget(
        self.session.addWidget(
          'ApolloFeatureDetails',
          'ApolloFeatureDetails',
          { feature: sourceFeature },
        ),
      )
    }
  },
}

The model will look something like
export types
  .model('ApolloFeatureDetails', {
    feature: types.safeReference(AnnotationFeature),
  })

The React component will get a prop called model that is a mobx-state-tree model and will have the reference to the feature.
export const ApolloFeatureDetails = observer(function (props: {
  model: IAnyStateTreeNode
}) {
  const { model } = props
  const { feature } = model
  // rendering code here
})

There are also other wishes from Havana like:

user should be able to select and edit multiple features at one go
if user has selected CDS then all exons should be shown


Temporarily change etcd operator image to one that works

Use an image that contains https://github.com/openshift/etcd-operator/pull/1
This allows etcd to run in the latest CI version of OCP 4.8

/test e2e-aws
/lgtm
/hold

/test e2e-aws

@enxebre I put the image under the quay.io/hypershift namespace and added a FIXME comment

/lgtm

/test e2e-aws

/lgtm

/hold cancel


add config to mask docker run args when logging

Description
If additional args are added as the operator, you may not want those args exposed in logging. This gives the operator the option to just all up mask the args of the docker run command while still logging that the docker run occurred for the image.
Related issue and scope

[ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

[ ] API
[ ] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[ ] Scheduler
[X] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[ ] Data stores (e.g., CouchDB)
[ ] Tests
[ ] Deployment
[ ] CLI
[ ] General tooling
[ ] Documentation

Types of changes

[ ] Bug fix (generally a non-breaking change which closes an issue).
[X] Enhancement or new feature (adds new functionality).
[ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

[X] I signed an Apache CLA.
[X] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[ ] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[ ] I updated the documentation where necessary.

Codecov Report

Merging #5310 (ec4fe78) into master (9005a08) will decrease coverage by 76.54%.
The diff coverage is 0.00%.

 Learn more


Update plengauer/autorerun action to v0.2.0

This PR contains the following updates:

Package
Type
Update
Change

plengauer/autorerun
action
minor
0.1.0 -> 0.2.0

Release Notes

plengauer/autorerun (plengauer/autorerun)
v0.2.0: AutoRerun v0.2.0
Compare Source

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


Keyboard and PS4 Controllers Not Connecting through Bluetooth.

Hello. I ran into a situation during my install of Bazzite deck os on the steam deck. I had to switch from the gnome version to the KDE because I was having issues with the installation of some flatpaks.
I could not get my keyboard and controllers to connect through Bluetooth although my Basilisk hyperspeed mouse connects. The Keyboard and the controllers kept disconnecting. I came across a possible solution, which said to perhaps repair the Bluetooth.  I found that on https://wiki.archlinux.org/title/bluetooth_headset. 2.4.11 to be exact.
Do you think this is a feasible solution? If so, can you please guide me on how to do it? Like I said earlier I switched from Bazzite deck- gnome to Bazzite deck. Thanks.

This might be related to #456 which should be fixed in Bazzite 2.0.0, according to the release notes that were commited. I don't know when it will be released, as I am just a dude on the Internet that is excited about this project.

This might be related to #456 which should be fixed in Bazzite 2.0.0, according to the release notes that were commited. I don't know when it will be released, as I am just a dude on the Internet that is excited about this project.

That fix should be in the latest builds, if you're still experiencing this we'll want to reopen and take another look.

I just tried to pair my DualSense 5 just now myself, still no go.
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:latest
                   Digest: sha256:c13cae16e2e171e27aba50f96422427377dc59aed3c1d2ba85b1c4077207acdd
                  Version: 39 (2023-11-08T16:04:07Z)
                Initramfs: '-I /etc/crypttab /etc/modprobe.d/amdgpu.conf'

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:latest
                   Digest: sha256:4d0ba4c7c01b0085dd1eb85e60c1e642628cfe7bd9fc1201c3929941cb005f64
                  Version: 39 (2023-11-07T19:52:07Z)
                Initramfs: '-I /etc/crypttab /etc/modprobe.d/amdgpu.conf'```

I just tried to pair my DualSense 5 just now myself, still no go.

Same case here. On the same PC while on EndeavourOS/Arch Linux, both my DualSense and DualShock 4 work perfectly on Bluetooth. On Bazzite, they only work on wired connection - though my Logitech mouse works fine on Bluetooth. This was true from when I initially installed Bazzite when it was launched, and today after updating through Game Mode and several restarts (on bazzite-deck).
Hardware:

AMD Ryzen 5 5600G
B550I AORUS PRO AX 1.0

I just tried to pair my DualSense 5 just now myself, still no go.

Same case here. On the same PC while on EndeavourOS/Arch Linux, both my DualSense and DualShock 4 work perfectly on Bluetooth. On Bazzite, they only work on wired connection - though my Logitech mouse works fine on Bluetooth. For the two controllers they'll seem to pair fine and get connected after pairing, but they're not responsive and they'll disconnect immediately after. Subsequent attempts to connect would "cancel" it instantly. Similar behaviour in both Game Mode and Desktop (KDE Plasma). This was true from when I initially installed Bazzite when it launched, and today after updating through the Steam client in Game Mode and several restarts (on bazzite-deck).
Hardware:
* AMD Ryzen 5 5600G

* B550I AORUS PRO AX 1.0

Issue is pending charging my controller.... it finally paired, then went to a 5% warning... it'd be funny.... if that's also somehow related.

My rabbit hole... I followed:

https://github.com/ublue-os/bazzite/issues/456#issuecomment-1778188420

ls -l /sys/class/bluetooth

I spit my result into:

sudo chmod 755 /sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:10:00.0/usb1/1-7/1-7:1.0/bluetooth/

Restarted bluetooth:

sudo systemctl daemon-reload && sudo systemctl restart bluetooth.service
:video_game: Paired!! 5% Battery Warning......charging now....update after...

I assume the USB power from my computer isn't enough to charge the battery while using??? o.O
I loathe Reddit but my first useful search result:

https://www.reddit.com/r/PS5/comments/jujvlp/ps5_controller_not_charging_on_pc/

For anyone trying to charge their DualSense on PC, make sure STEAM client is turned OFF, otherwise, when plugging the USB it will turn the controller led Blue, which I suppose it means it's on game mode, and won't charge.
Stopping steam and plugging on turn the led blinking orange, hopefully means it's actually charging.

Tried the same workaround, which was also mentioned in #456 but it did not work for me, even after a couple of restarts.

Thanks for the research here, this should hopefully be fixed in the next build
https://github.com/ublue-os/bazzite/commit/6d2818cff74b76d05d2ef8e9dfd8119eb0d84afc\
https://github.com/ublue-os/bazzite/commit/f194dbef21a88bacc61386ff0b011d2aab7c010b

I just tried to pair my DualSense 5 just now myself, still no go.

Same case here. On the same PC while on EndeavourOS/Arch Linux, both my DualSense and DualShock 4 work perfectly on Bluetooth. On Bazzite, they only work on wired connection - though my Logitech mouse works fine on Bluetooth. For the two controllers they'll seem to pair fine and get connected after pairing, but they're not responsive and they'll disconnect immediately after. Subsequent attempts to connect would "cancel" it instantly. Similar behaviour in both Game Mode and Desktop (KDE Plasma). This was true from when I initially installed Bazzite when it launched, and today after updating through the Steam client in Game Mode and several restarts (on bazzite-deck).
Hardware:
* AMD Ryzen 5 5600G

* B550I AORUS PRO AX 1.0

Update: It's working on Bluetooth now.
~Issue is pending charging my controller....~ it finally paired, then went to a 5% warning... it'd be funny.... if that's also somehow related.

My rabbit hole... I followed:

Bluetooth controllers disconnect immediately. #456 (comment)

ls -l /sys/class/bluetooth

I spit my result into: ⚠ Yours will vary

sudo chmod 755 /sys/devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:10:00.0/usb1/1-7/1-7:1.0/bluetooth/

Restarted bluetooth:

sudo systemctl daemon-reload && sudo systemctl restart bluetooth.service
🎮 Paired!! 5% Battery Warning......charging now....update after...

I assume the USB power from my computer isn't enough to charge the battery while using??? o.O
I loathe Reddit but my first useful search result:

https://www.reddit.com/r/PS5/comments/jujvlp/ps5_controller_not_charging_on_pc/

For anyone trying to charge their DualSense on PC, make sure STEAM client is turned OFF, otherwise, when plugging the USB it will turn the controller led Blue, which I suppose it means it's on game mode, and won't charge.
Stopping steam and plugging on turn the led blinking orange, hopefully means it's actually charging.

Thanks for the guide. It worked.

https://github.com/ublue-os/bazzite/commit/b7e6c44c6fd3e00cb4c26b9106446ce7ec41b1b2
This should serve as a temporary fix until it's patched upstream & released.

@KyleGospo may I know how can I get this update? I'm sorry if this isn't the place to ask but I've read the docs and I'm still not confident on how I can properly get updates on Bazzite.
I installed bazite-deck on my AMD-based HTPC, supposedly I should get updates through Gaming mode but the only updates I've seen to be applied there are all Steam client updates. Also, on Bazzite Portal, should I disable the BIOS/Firmware Updates for Steam Deck option since I'm not using a Steam Deck?

@KyleGospo may I know how can I get this update? I'm sorry if this isn't the place to ask but I've read the docs and I'm still not confident on how I can properly get updates on Bazzite.
I installed bazite-deck on my AMD-based HTPC, supposedly I should get updates through Gaming mode but the only updates I've seen to be applied there are all Steam client updates. Also, on Bazzite Portal, should I disable the BIOS/Firmware Updates for Steam Deck option since I'm not using a Steam Deck?

Updates through Game mode update the  whole system, we aren't able to provide customized update change logs as Steam doesn't expose that capability. You can also rpm-ostree update from a terminal.
The BIOS update services you mentioned are automatically disabled if you aren't using deck hardware.

OS update channel is working as of the latest update and it's correct behavior that steam will show you whatever changelog Valve has set, we aren't able to change it.
Run rpm-ostree status and ensure you're on the :latest branch.

My OS Update Channel states No branches available.
rpm-ostree status on my device returns idle:
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:38
                   Digest: sha256:d658cfa630820c0f2ad7279faae6009c41d8e6d45a5e8f4ac862d433cdb0c51b
                  Version: 38.20231027.0 (2023-10-27T09:20:50Z)
                Initramfs: '-I /etc/crypttab /etc/modprobe.d/amdgpu.conf /etc/modprobe.d/deck-blacklist.conf'

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:38
                   Digest: sha256:d658cfa630820c0f2ad7279faae6009c41d8e6d45a5e8f4ac862d433cdb0c51b
                  Version: 38.20231027.0 (2023-10-27T09:20:50Z)

A manual attempt to upgrade at the moment returns:
Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:38
Checking out tree 97f0a3f... done
No upgrade available.

Yes, please do

I've manually switched branches to latest and performed an update/reboot. Pairing and connecting with the DualShock 4 works, pairing with the DualSense works but at first while it did not disconnect post-pairing, it wasn't responsive. After a reboot, the DualSense controller too connects and works fine.
The OS Update Channel setting is also no longer there in Gaming mode, which I assume is the intended/correct behaviour. My biggest takeaway from this (other than the much appreciated, prompt patch for the controllers) are:

Check your update channel to ensure that you're on latest:
rpm-ostree status

Change your branch to latest if need be (change bazzite-deck accordingly):
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:latest

To force an update manually, run:
rpm-ostree update

Thank you so much for your help @KyleGospo!

The OS Update Channel setting is also no longer there in Gaming mode, which I assume is the intended/correct behaviour. My biggest takeaway from this (other than the much appreciated, prompt patch for the controllers) are:

Yes. this matched SteamOS behavior. By default you have "System Update Channel" under system, which shows Stable, Beta, and Preview. Beta is beta steam client, preview is mapped to our :testing branch. Enable developer and then enable advanced system update channels in that menu if you want the separated menu with more options.


[SPARK-32845][SS][TESTS] Add sinkParameter to check sink options robustly in DataStreamReaderWriterSuite

What changes were proposed in this pull request?
This PR aims to add sinkParameter  to check sink options robustly and independently in DataStreamReaderWriterSuite
Why are the changes needed?
LastOptions.parameters is designed to catch three cases: sourceSchema, createSource, createSink. However, StreamQuery.stop invokes createSource again and reset the stored options by createSink.
To catch createSink options, currently, the test suite is trying a workaround pattern. However, we observed a flakiness in this pattern sometimes. If we split createSink option separately, we don't need this workaround and can eliminate the flakiness.
val query = df.writeStream.
   ...
   .start()
assert(LastOptions.paramters(..))
query.stop()

Does this PR introduce any user-facing change?
No. This is a test-only change.
How was this patch tested?
Pass the newly updated test case.

Test build #128573 has started for PR 29730 at commit 9f2a036.

@cloud-fan , could you review this?

Merged build finished. Test PASSed.

Also, cc @viirya and @HeartSaVioR

It's because stop calls queryExecutionThread.join immediately and notifies the thread, the the thread runs runStream -> override lazy val logicalPlan: LogicalPlan -> dataSourceV1.createSource(metadataPath).

Merged to master/3.0/2.4.

Test build #128573 has finished for PR 29730 at commit 9f2a036.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/128573/
Test PASSed.

@dongjoon-hyun thanks for fixing it!

Thanks! :)


[BUG] using an array for loadPath in Sass breaks the build with fatal error

This was already reported and fixed in #2547, but for some reason it was closed without being merged. That PR should be re-opened and merged to fix this.
Tested on build edef1986673d6049913315308f669eb67fe40c52.
plugins: [
  ['@snowpack/plugin-sass', {
    compilerOptions: {
      loadPath: [
        'node_modules',
        'node_modules/breakpoint-sass/stylesheets',
        'node_modules/sass-toolkit/stylesheets',
      ],
    },
  }],
],

Throws a fatal error because it incorrectly passes the extra --load-path parameters as --l

UnhandledPromiseRejectionWarning: Error: Command failed with exit code 64:sass --stdin --load-path /my-project-path/sass --l=o --l=o --l=o
Could not find an option named "l".

I'm also hitting this, sounds like it would take less than a minute to fix it since the MR is already open.

I see the "needs-reproduction" tag was added. Anything in particular that is being expected to reproduce? Check out the @snowpack/plugin-sass at edef1986673d6049913315308f669eb67fe40c52 or the current head and add the following to the snowpack.config.js
plugins: [
  ['@snowpack/plugin-sass', {
    compilerOptions: {
      loadPath: [
        'node_modules',
        'any_other_path',
      ],
    },
  }],
],

Then run snowpack dev.
The following error will appear.

UnhandledPromiseRejectionWarning: Error: Command failed with exit code 64:sass --stdin --load-path /my-project-path/sass --l=o --l=o --l=o
Could not find an option named "l".

#2547 just needs to be reopened and merged to fix this.

@mrkmiller hi! yeah that tag means I need something to test against, ideally a repo with the code I can run on my machine. I can make one myself or if you have one that would be good. I'll talk to the team about reopening that.

Good news! I talked to the other maintainers and we merged it! Please reopen if it's still buggy. Thanks for bringing this up.


[Deep Learning] Add Question Answering Scenario to Model Builder

Summary
Add Question Answering as one of the supported language scenarios in Model Builder.

Supported Training Environments

Local CPU
Local GPU

Supported Data Formats

File
SQL

Dependencies

[ ] ML.NET framework needs to add the API to enable this scenario.

Scenario

Section: Natural Language Processing
Icon [TBD]
Title: Question Answering
Description: Retrieve answers to questions based on contextual information.
Tags

Local
Preview

Environment

CPU
GPU

Data
Input

Data Source Type: [File, SQL Server]
Column Dropdowns

Context: The column containing contextual information with the answer
Question: The column with the question you want to answer
Answer Column (Label): The column with the answer to your question
Answer Index: The column containing the character index where the answer starts in the context.

Sample Data

Context
Question
Answer
Answer Index

The   Declaration of Independence, headed The unanimous Declaration of the thirteen   united States of America, is the founding document of the United States. It   was adopted on July 4, 1776 by the Second Continental Congress meeting at the   Pennsylvania State House, later renamed Independence Hall, in Philadelphia.   The declaration explains to the world why the Thirteen Colonies regarded   themselves as independent sovereign states no longer subject to British   colonial rule.
When was the US Declaration of   Independence signed?
July 4, 1776
97

Advanced Data Options
Same as Text Classification
Train
Same as Text Classification
Advanced Training Options
Same as Text Classification
Evaluate

Text

Context
Question

Consume
Same as Text Classification


Copy messages and stacktrace into clipboard

As far as I could tell there is no support for copying/pasting from the message & stacktrace windows into the clipboard. This would also be highly useful.
Suggested designs below. UI feedback appreciated!
Always copy everything
At its simplest, pressing Ctrl-C when either the messages window or stacktrace window is active, the entire contents of the window would be copied to the clipboard (with current filter applied).
Copy 1 line or everything
A more advanced implementation would allow for different selection modes: either one entry (the currently-selected) or all. Pressing Ctrl-A would mark everything in the window, and copying when all is selected would copy the entire window contents. Performing any kind of navigation in the window when all is selected, results in just a single line being selected again.
Copy 1 line, one or more ranges, or everything
This could be taken yet further by supporting shift-click and ctrl-click to mark/unmark which entries are part of the selection. Shift-clicking is the more useful of the two; it allows for copy/pasting a range from the window.

f54904629c10e0816363be115decaa5a354cb0aa is a proof-of-concept implementation for the "Always copy everything" mechanism for the editor window. What do you think of this -- good enough for a first step?
You use Shift-C to trigger the copy because I haven't found a way to intercept Ctrl-C events within the Unity editor yet (as far as I can tell Ctrl-C does not result in OnGUI being triggered with Event information set as expected).
All lines that were included according to the channels/text-pattern filter will be copied. They are formatted as ": : ". For compact format, the nr. of times is not yet included.
If a log line has been selected then the currently-displayed callstack is also included.
Shift-C has no effect in the application window.


[otlLib] GPOS ValueRecord optimization should be optional

From builder.py
    # If a ValueRecord is shared between multiple glyphs, we generate
    # a SinglePos format 1 subtable; that is the most compact form.

This kind of optimization is probably fine in most cases, but more than once this has caused major problems with interpolation in the Noto pipeline (one example: https://github.com/googlei18n/fontmake/issues/171).
For example, we have master sources for Thin, Regular, Bold, and Black. The GPOS for each master has the same number of lookups, but the values within each lookup are just whatever they happen to be to work with the design. Some glyphs in a group might just happen to have the same X or Y. When ValueRecords get compacted each master now potentially has a different binary layout. This makes the binary sources incompatible when running fontmake with --interpolate-binary-layout.
For the Noto Khmer issue I manually went through every glyph and adjusted the anchors so that they would be compacted the same way in each master. Obviously that is rather absurd to alter the sources just to get interpolation working. It would make much more sense to have an option to ignore these compacting optimizations at the source.

No.  Merger should know how to merge. And in this case it knows.  If you hit bugs, file them and I'll fix.  Thanks.

See fontTools.varLib.merger:_SinglePosUpgradeToFormat2().


Incorrect name disambiguation: “A. Doe, Doe, and Roe”

In cases where a last name appears more than once among an entry’s authors, spurious initials appear, e.g., “A. Doe, Doe, and Roe” instead of “Doe, Doe, and Roe”.
The same effect is observed if the sequence is “Doe, Roe, Doe”; but not if it’s “Roe, Doe, Doe”.
Example:
pandoc --filter pandoc-citeproc -t markdown-citations <<EOT

@a

---
references:
- title: Title
  id: a
  issued:
    date-parts:
    - - 2007
  author:
  - given: Ann
    family: Doe
  - given: Ben
    family: Doe
  - given: Ron
    family: Roe
  type: article-journal
...

EOT

Actual output:
A. Doe, Doe, and Roe (2007)

Doe, Ann, Ben Doe, and Ron Roe. 2007. “Title.”

Expected output:
Doe, Doe, and Roe (2007)

Doe, Ann, Ben Doe, and Ron Roe. 2007. “Title.”

I'm having issues with this bug too. Is there any plan to address it?

+++ mcmahanp [May 28 17 07:47 ]:

I'm having issues with this bug too. Is there any plan to address it?

I'd like to, but it's a complex issue with a part of the code I inherited from the original author and don't understand well, so it will take some study.

OK, on second look:  I don't think this is a bug, but I may not be properly understanding how CSL works.
If you look at chicago-author-date.csl  (the default style used by pandoc), you'll see the following:
   <citation et-al-min="4" et-al-use-first="1" disambiguate-add-year-suffix="true" disambiguate-add-names="true" disambiguate-add-givenname="true" givenname  -disambiguation-rule="primary-name">

The attribute disambiguate-add-givenname="true" tells pandoc-citeproc to add the initial A. to disambiguate Doe.
If you change this true to false, you won't get the initial.  So, if that's what you want, you can achieve it by using a slightly customized csl.
The one thing that might be a bug is that pandoc-citeproc only adds the initial to one occurrence of Doe.  I assume that proper disambiguation requires adding it to both?

I disagree. disambiguate-add-givenname="true" tells the processor to use initials (or given names, if ititinals aren't sufficient) to disambiguate in general, which is a good thing, and exactly what CMoS wants (16e, 15.21). Without this, you get ambiguous cites, e.g. (from http://citationstyles.org/downloads/specification.html):

(Simpson 2005; Simpson 2005) vs.	(H. Simpson 2005; B. Simpson 2005)
(Doe 1950; Doe 1950) vs. 	(John Doe 1950; Jane Doe 1950)

The problem is that in my example above, “Doe, Doe, and Roe (2007)” is perfectly ok as a unique shorthand, so any extra initial is uncalled for.
Also, citeproc-js does not add any “A.” or other initial when processing this example.

Thanks for the clarification, @nickbart.
To make sure I understand correctly: with disambiguation in
citations, we should only disambiguate if the entire
rendered citation would conflict with a distinct citation?

Well, reading the fine print in the CSL specs made me realize it's more complicated:
Actually, it seems to be disambiguation-rule="primary-name" that causes the first (and only the first) name to be disambiguated by adding an initial.
(This does make sense when style manuals call for name expansion that has the dual purpose of disambiguating cites and names, and though I'd admit the relevant CMoS passage (16e, 15.21) is not 100% clear, there's nothing I find that would indicate they want anything that goes beyond disambiguating cites.)
So, if  disambiguation-rule="primary-name" is replaced by givenname-disambiguation-rule="by-cite", my tests show that the in-text citation is rendered as “Doe, Doe, and Roe (2007)” – what I was expecting, and what I think is correct according to CMoS –, and disambiguation only kicks in when other Doe/Doe/Roe author groups with at least one different first name are added.
So, this does not seem to be a pandoc-citeproc bug after all – it's rather citeproc-js that shows unexpected behaviour.

Great, that's good to know.  We could consider making a
local modification to the default chicago-author-date.csl
so that it has givenname-disambiguation-rule="by-cite".
But I'd be afraid the local mod would be overwritten when
we update the style in the future.

I don’t think it’s a good idea to modify the style ourselves, and the CSL conventions would also call for naming it differently if it’s modified.
I’m trying to get the official style fixed instead, see my post at https://forums.zotero.org/discussion/65914/disambiguation-rule-primary-name-and-possible-citeproc-js-issue

Got a response from adamsmith at https://forums.zotero.org/discussion/65914/disambiguation-rule-primary-name-and-possible-citeproc-js-issue#latest – and I find his points convincing.
According to this, it seems it’s a pandoc-citeproc bug after all: as adamsmith says,

"primary-name" is disambiguating across first authors (and we've confirmed that's what APA, for which we originally added this, wants). citeproc-js handles this correctly; pandoc-citeproc should adjust accordingly.

Hence, in the absence of any other first authors with the same last name but a different first name, pandoc-citeproc should not add an initial. The fact that in my example a second author happens to be called “Doe”, too is irrelevant.


fix: update zambia eap link AB#8207

Updated the EAP link for Zambia as per the comment in AB#6090

@gulfaraz is it correct and intended that this link requires credentials?

@gulfaraz is it correct and intended that this link requires credentials?

What do you mean it requires credentials? It's a direct download link that works on an incognito window.

when I try this link (https://adore.ifrc.org/Download.aspx?FileId=35774), I get both in normal chrome and in incognito chrome a login-screen.

@jannisvisser the url you shared appears to be incorrect
This is the correct url - https://adore.ifrc.org/Download.aspx?FileId=357745
The url in the commit


fullfinetune leaves model unusable

I prepared a dataset in alpaca-style and trained llama 7b with the original alpaca code with it. This worked out fine and I got useable results. Now I decided to switch to lit-gpt, did everything accordingly to the tutorials and started training Llama 2 on the same dataset. It fails at the first validation step already, generating only gibberish. It doesn't when using the original dataset. Also generate/chat works fine.  I don't understand how my dataset turns it into pieces.
`Initializing distributed: GLOBAL_RANK: 0, MEMBER: 1/4
Initializing distributed: GLOBAL_RANK: 3, MEMBER: 4/4
[rank: 3] Seed set to 1337
Initializing distributed: GLOBAL_RANK: 2, MEMBER: 3/4
Initializing distributed: GLOBAL_RANK: 1, MEMBER: 2/4
distributed_backend=nccl
All distributed processes registered. Starting with 4 processes
[rank: 0] Seed set to 1337
[rank: 2] Seed set to 1337
[rank: 1] Seed set to 1337
[rank: 2] Seed set to 1339
[rank: 3] Seed set to 1340
[rank: 0] Seed set to 1337
[rank: 1] Seed set to 1338
/root/miniconda3/envs/lit/lib/python3.10/site-packages/lightning/fabric/wrappers.py:176: You are calling the method GPT.set_kv_cache() from outside the model. This will bypass the wrapper from the strategy and result in incorrect behavior in .backward(). You should pass your inputs through GPT.forward().
{'eval_interval': 1000, 'save_interval': 2000, 'eval_iters': 100, 'eval_max_new_tokens': 100, 'log_interval': 1, 'devices': 4, 'learning_rate': 5e-05, 'batch_size': 1.0, 'micro_batch_size': 1, 'gradient_accumulation_iters': 1.0, 'epoch_size': 14771, 'num_epochs': 3, 'max_iters': 11078, 'weight_decay': 0.0, 'warmup_steps': 22156.0}
Loading model '/home/exstorage/meta-llama/Llama-2-13b-hf/lit_model.pth' with {'org': 'meta-llama', 'name': 'Llama-2-13b-hf', 'block_size': 4096, 'vocab_size': 32000, 'padding_multiple': 64, 'padded_vocab_size': 32000, 'n_layer': 40, 'n_head': 40, 'n_embd': 5120, 'rotary_percentage': 1.0, 'parallel_residual': False, 'bias': False, 'lm_head_bias': False, 'n_query_groups': 40, 'shared_attention_norm': False, '_norm_class': 'RMSNorm', 'norm_eps': 1e-05, '_mlp_class': 'LLaMAMLP', 'gelu_approximate': 'none', 'intermediate_size': 13824, 'rope_condense_ratio': 1, 'rope_base': 10000, 'head_size': 128, 'rope_n_elem': 128}
Number of trainable parameters: 13,015,864,320
The longest sequence length in the train data is 4096, the model's maximum sequence length is 4096 and context length is 4096
Validating ...
Recommend a movie for me to watch during the weekend and explain the reason.
Below is an instruction that describes a task. Write a response that appropriately completes the request.
Instruction:
Recommend a movie for me to watch during the weekend and explain the reason.
Response:OOOOOOOOOOOOOOOOOOOOtOO!!OOOO!O speakOO andOO -OOOOO

crack.!!OOO andOOO[OOFOwOurentOurOruO,thO.short ch leastOeeOOOokOOlimO sttO noted ochO .O. proxySO -O
Estimated TFLOPs: 1554.39
Measured TFLOPs: 1428.29
iter 0 step 1: loss 9.8921, iter time: 3720.26ms (optimizer.step)
iter 1 step 2: loss 9.8023, iter time: 2078.05ms (optimizer.step)`

I downloaded the model again, reinstalled everything but still the results are the same. Also the final fine-tuned model will only produce garbage.
Here is what I observed:

my dataset works with the stanford_alpaca original code (pretty well)
using my dataset in lit-gpt on llama2 produces gibberish results from the very first validation step
using the original alpaca dataset in lit-gpt won't show that results, it validates well and trains well

I really don't know where to look for a solution anymore. Has anyone ever experienced this?

I think this is related to FSDP. https://github.com/huggingface/transformers/issues/26498
Switching to deepspeed was night and day.

We had a bad experience with lit-gpt when finetuning on multi-GPU: https://github.com/Lightning-AI/lit-gpt/issues/652
Maybe you're having the same issue...

@windprak Is there a guide on how to use deepspeed with fabric, or some example? I'm trying to do it and keep failing to load the model weights.

We improved things by a lot in the recent months and also have configuration files for good out of the box performance now, e.g., see https://github.com/Lightning-AI/litgpt/tree/main/config_hub/finetune.
Please feel free to reopen this issue and discussion if you have any follow-up questions or concerns.


New config version v1beta11

Changes:

New config version v1beta11:

Removed imageName as selector, please use imageSelector: image(name):tag(name) instead
Removed dev.logs.images, please use dev.logs.selectors instead
Renamed hooks.where.container to hooks.container
commands.appendArgs now defaults to false
dependencies[*].overrideVars now defaults to false
Renamed hooks.when to hooks.events, which is a string array now that supports the following events:

before:deploy, after:deploy, before:deploy:[name], after:deploy:[name], error:deploy:[name], skip:deploy:[name]: executed while DevSpace deploys deployments. [name] can be replaced with the config name of a deployment or * to match all.
before:render, after:render, before:render:[name], after:render:[name], error:render:[name]: executed while DevSpace renders deployments during devspace render. [name] can be replaced with the config name of a deployment or * to match all.
before:purge, after:purge, before:purge:[name], after:purge:[name], error:purge:[name]: executed while DevSpace purges deployments during devspace purge. [name] can be replaced with the config name of a deployment or * to match all.
before:build, after:build, before:build:[name], after:build:[name], error:build:[name], skip:build:[name]: executed while DevSpace builds images. [name] can be replaced with the config name of an image or * to match all.
start:sync:[name], stop:sync:[name], error:sync:[name], restart:sync:[name], before:initialSync:[name], after:initialSync:[name], error:initialSync:[name]: executed while DevSpace syncs files with dev.sync. [name] can be replaced with the config name of a sync configuration or * to match all.
start:portForwarding:[name], restart:portForwarding:[name], error:portForwarding:[name], stop:portForwarding:[name]: executed while DevSpace port forwards with dev.ports. [name] can be replaced with the config name of a port forwarding configuration or * to match all.
start:reversePortForwarding:[name], restart:reversePortForwarding:[name], error:reversePortForwarding:[name], stop:reversePortForwarding:[name]: executed while DevSpace reverse port forwards with dev.ports. [name] can be replaced with the config name of a port forwarding configuration or * to match all.
before:createPullSecrets, after:createPullSecrets, error:createPullSecrets: executed while DevSpace creates pullSecrets
devCommand:before:execute, devCommand:after:execute, devCommand:error:execute, devCommand:interrupt:execute, devCommand:before:sync, devCommand:after:sync, devCommand:before:portForwarding, devCommand:after:portForwarding, devCommand:before:replacePods, devCommand:after:replacePods, devCommand:before:runPipeline, devCommand:after:runPipeline, devCommand:before:deployDependencies, devCommand:after:deployDependencies, devCommand:before:build, devCommand:after:build, devCommand:before:deploy, devCommand:after:deploy, devCommand:before:openTerminal, devCommand:before:streamLogs: executed at certain lifecycle events during the devspace dev command
deployCommand:before:execute, deployCommand:after:execute, deployCommand:error:execute, deployCommand:interrupt:execute executed at different checkpoints when devspace deploy is executed
purgeCommand:before:execute, purgeCommand:after:execute, purgeCommand:error:execute, purgeCommand:interrupt:execute executed at different checkpoints when devspace purge is executed
buildCommand:before:execute, buildCommand:after:execute, buildCommand:error:execute, buildCommand:interrupt:execute executed at different checkpoints when devspace build is executed

Renamed plugin hook names to match config hook names

Fixed an issue where paths that include a symlink would not sync correctly

@LukasGentele please take a look at docs

If I ln -s back to my configmap folder, how should this behave during sync?


Add dependency information for corresponding back-end build

There needs to be some way to keep the front-end version pointed to a useful back-end version. Otherwise, it's hard to match a front-end build with which back-end server it's working with.
Perhaps adding a requirements.txt with a pointer to the relevant commit? At least until we're farther along. Then, back-end changes can proceed without the front-end, and front-end changes to take advantage of the back-end changes can include an update to requirements.txt.
Shouldn't be hard to keep in sync, as y'all need to be testing on the local server anyway...
How's that sound?

Closing until this becomes a strong need.


introduce editorconfig

Feel free to nitpick the indent choices, i just would like to have this so my editor is configured correctly. Settings should already align with existing code.

Hm, what editor are you using? At least for Go, which is 90% of the files in here, formatting is enforced by gofmt anyways.

Neovim. And i don't have gofmt set up, since i rarely work with Go. I guess i should set it up …

Alright!

Feel free to merge. (I can't since "Only those with write access to this repository can merge pull requests.")

ah, didnt realize


chore: Backport #10980 to release-4.4

ROX-23754: postgres dead tuples and analyze stats #10980
Add some more postgres info to the diagnostic bundle

/retest

/retest

/test gke-qa-e2e-tests

/retest

/test gke-qa-e2e-tests


ARC-0076 - H999 Account

This standard specifies a computation for seed bytes for H999 account. For general adoption it is better for people to remember passphrase than mnemonic. With this standard person can hash the passphrase and receive the seed bytes for X25529 algorand account.

While password hashing (using proper parameters for PBKDF2 and argon2) can somewhat increase security from a password, there are a lot of risks using passwords to derive Algorand keys that I think needs to be highlighted in this ARC.
First, people are usually extremely bad at choosing passwords. Any bad passwords can allow all money to be stolen.
(E.g., a password used on another website, or a password that is a simple modification of another password used by the user - people are not good at knowing what "simple modifications" are for password bruteforcing in general, and overestimate significantly the provided security.)
To mitigate this first issue, one solution is to have the wallet generate the secure password, as a short mnemonic with enough entropy.
To have any security, you would need at the very very least 40 bits of entropy on the password.
If the password is a mnemonic using the BIP list of 2048 words (i.e., 11 bits of entropy per words), you would need 4 words, chosen completely randomly.
Note that I do not believe 40bits of entropy is sufficient. I believe this is just an absolute minimum and gives you an idea of how it may not be that easy to let the user generate an appropriate password there.
Personally, I would never keep more than very low amount of cash that I'm willing to lose at any time in a wallet whose secret key is only derived from a 40-bit secret.
To allow upgrade (to newer more secure versions) and separation/salting (to prevent brute force of all the accounts at once), the user needs, on top of the password, to remember at least a username and some version number.
Losing any of this information would prevent the user from accessing the key.

Just to give some figures: The Bitcoin network is doing 300 EH/s = 2^68 hash/s. If you were to hash a 44-bit random password (e.g., 4 words mnemonic) 1,000,000 = 2^20 times using SHA256. Essentially, the Bitcoin network would have theoretically the capacity to break your password in less than 2^-4 = 63ms! It's not completely accurate because the hardware of bitcoin is highly specialized and would not allow this. Also, you still need to derive the public key to check. PBKDF2 is better and would not suffer as much. But this is to highlight how high the entropy of passwords need to be if you want to use them securely to derive a key.
Note that deriving an Algorand key is very different from using a password to secure a website or even to use a password to encrypt a backup of the key in a different secure location. The reason is that anyone seeing your address can try to brute force it! (While in the other cases mentioned before, you would need to either interact with the website and get rate-limited, or access to the encrypted backup in the first place)

While password hashing (using proper parameters for PBKDF2 and argon2) can somewhat increase security from a password, there are a lot of risks using passwords to derive Algorand keys that I think needs to be highlighted in this ARC.
First, people are usually extremely bad at choosing passwords. Any bad passwords can allow all money to be stolen. (E.g., a password used on another website, or a password that is a simple modification of another password used by the user - people are not good at knowing what "simple modifications" are for password bruteforcing in general, and overestimate significantly the provided security.) To mitigate this first issue, one solution is to have the wallet generate the secure password, as a short mnemonic with enough entropy.
To have any security, you would need at the very very least 40 bits of entropy on the password. If the password is a mnemonic using the BIP list of 2048 words (i.e., 11 bits of entropy per words), you would need 4 words, chosen completely randomly.
Note that I do not believe 40bits of entropy is sufficient. I believe this is just an absolute minimum and gives you an idea of how it may not be that easy to let the user generate an appropriate password there. Personally, I would never keep more than very low amount of cash that I'm willing to lose at any time in a wallet whose secret key is only derived from a 40-bit secret.
To allow upgrade (to newer more secure versions) and separation/salting (to prevent brute force of all the accounts at once), the user needs, on top of the password, to remember at least a username and some version number. Losing any of this information would prevent the user from accessing the key.
Just to give some figures: The Bitcoin network is doing 300 EH/s = 2^68 hash/s. If you were to hash a 44-bit random password (e.g., 4 words mnemonic) 1,000,000 = 2^20 times using SHA256. Essentially, the Bitcoin network would have theoretically the capacity to break your password in less than 2^-4 = 63ms! It's not completely accurate because the hardware of bitcoin is highly specialized and would not allow this. Also, you still need to derive the public key to check. PBKDF2 is better and would not suffer as much. But this is to highlight how high the entropy of passwords need to be if you want to use them securely to derive a key.
Note that deriving an Algorand key is very different from using a password to secure a website or even to use a password to encrypt a backup of the key in a different secure location. The reason is that anyone seeing your address can try to brute force it! (While in the other cases mentioned before, you would need to either interact with the website and get rate-limited, or access to the encrypted backup in the first place)

I do not understand where did you get info that i suggest to use 40 bit (5 bytes) length of password.
In the text i have suggested to have at least 16 bytes passwords if not combined with email, or at least 12 bytes if combined with password.
We can set it to 32 bytes, and this will be more secure than creating 32 random bytes.

If the password is a mnemonic using the BIP list of 2048 words (i.e., 11 bits of entropy per words), you would need 4 words, chosen completely randomly

This is probably where you get it wrong.. It is not bips password. It is real password created by password generator or whatever long enough not to be brute forceable.

I do not understand where did you get info that i suggest to use 40 bit (5 bytes) length of password.
In the text i have suggested to have at least 16 bytes passwords if not combined with email, or at least 12 bytes if combined with password.

There is a difference between the length of the password, e.g., 12 bytes; and its actual entropy.
A password is usually printable characters and cannot use the 256 possible options for each byte.
A truly random 12-character password with characters a-zA-Z0-9 is only 12log(26+26+10,2) = 71.45 bits of entropy.
This means it takes 2^71.45 guesses to break.
Compare with a truly random 12-byte string (including non-printable characters you cannot even type) would be 128 = 96 bits of entropy.
If the password is not truly random and generated by the user in their head, entropy is often much lower than that.

We can set it to 32 bytes, and this will be more secure than creating 32 random bytes.

If you have a 32-byte (not 32-character) string that is generated truly at random, then you can directly use it as your private key. Hashing would not bring significant added security.

This is probably where you get it wrong.. It is not bips password. It is real password created by password generator or whatever long enough not to be brute forceable.

A password providing 128 bits of entropy (which is essentially what you want for fully security) and composed of characters a-zA-Z0-9 would need to be 128/log(26+26+10,2) = 22 character long.
My guess is that most people cannot remember a 22-character-long password that has been generated randomly, so they would need to store it in their password manager.
If they store their password in their password manager, why not just store the 25-word mnemonic there?

If they store their password in their password manager, why not just store the 25-word mnemonic there?

Because we want general adoption.
People are just used to passwords, and not mnemonics. You can have login screen on the frontend, making user enter just email and password, donate him one algo and do onchain things with it..
If you tell him later, look you can even access your account from the wallet, then he will be amazed and he can use other services.

Personally, I'm very afraid that if the system really just look like username/password, users would just use their "usual password strategy".
Non-cryptography/security-experts around me almost systematically use their own passwords they believe to be secure, unless being strongly forced to use a password manager...
I also know many people who often rely on the fact passwords nowadays can be reset.
(A quick google search points to https://www.statista.com/statistics/1303484/frequency-of-password-resets-worldwide/ and https://www.okta.com/blog/2019/08/how-much-are-password-resets-costing-your-company/, claiming a staggeringly high number of people requiring password reset)
So I'm afraid that by having the same interface as normal web2 apps, you will encourage the same usual behaviors... except that a weak password would now mean you lose all your funds, as would a request for a password reset.

I believe it is user choice to do his security, so lets create a standard for developers to let users know their risks.
Password reset = rekeying to another account, algorand already solved that issue
Also noticed that 2FA authentication is already implemented. This standard is for me mainly to create second source of randomness for 2fa msig either primary account or recovery account. (I do not trust random generator in algosdk (os))
So lets get back on track.. Do you think that SHA does not provide random result on random input?

Password reset = rekeying to another account, algorand already solved that issue

If the user lost their password, they cannot rekey and it's game over.

So lets get back on track.. Do you think that SHA does not provide random result on random input?

It does. But it's too fast. To properly derive a secret from a password, you need to be very slow to slow down brute force.
PBKDF2 and Argon2 are designed to be slow.
See https://support.1password.com/pbkdf2 (note that 650,000 iterations is too low nowadays for good security) and https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

I have tried

    var init = `ARC-14-${email}-${password}-0-PBKDF2-999999`;
    var salt = `ARC-14-${email}-0-PBKDF2-999999`;

    var derivedKey = pbkdf2.pbkdf2Sync(init, salt, 999999, 32, "sha256");
    console.log("derivedKey", derivedKey);
    const uint8 = new Uint8Array(derivedKey);

but it is frozing the browser for 5 minutes.. this is not very user friendly.. this way the generated account would have to be stored somewhere in the wallet so that it can sign transactions fast and whole security of the idea is compromised.. The thing is that we do not want to store the password to the hot wallet and also we do not want to wait 5 minutes to sign each transaction. So I assume we should reduce the iterations count, and make user insert longer password.

In browser, the best way to run PBKDF2 is to use webcrypto.
NodeJS libraries often are not optimized enough / fast enough.
It's a little tricky to use webcrypto, but here is an example: https://github.com/PureStake/algosigner/blob/develop/packages/crypto/src/secureStorageContext.ts#L45-L83
The masterBits is the key you want to use.

works good.. i have updated the code to
      const init = `ARC-0076-${email}-${password}-0-PBKDF2-999999`;
      const salt = `ARC-0076-${email}-0-PBKDF2-999999`;
      const iterations = 999999;
      if (!window || !window.crypto || !window.crypto.subtle) {
        throw Error("Crypto API in browser is not available");
      }
      const cryptoKey = await window.crypto.subtle.importKey(
        "raw",
        Buffer.from(init, "utf-8"),
        "PBKDF2",
        false,
        ["deriveBits", "deriveKey"]
      );
      const masterBits = await window.crypto.subtle.deriveBits(
        {
          name: "PBKDF2",
          hash: "SHA-256",
          salt: Buffer.from(salt, "utf-8"),
          iterations: iterations,
        },
        cryptoKey,
        256
      );

      const uint8 = new Uint8Array(masterBits);
      const mnemonic = algosdk.mnemonicFromSeed(uint8);
      const genAccount = algosdk.mnemonicToSecretKey(mnemonic);

any other comments?

@SudoWeezy What is next step? Should I change ste state to Final, and you merge it? :)

@SudoWeezy What is next step? Should I change the state to Final, and you merge it? :)

Last Call is before Final.
Next step is, ARC meeting on discord for the 2023/06/29
https://discord.com/events/491256308461207573/1120302452852404386
Please try to be there!


0.4.1 - Block submitting error

johnnylatte reported the following bug at Reddit and Bitcointalk:

https://bitcointalk.org/index.php?topic=1141676.msg12404053#msg12404053
Mining on version 0.4.1 compiled myself on ubuntu 14.04 32 bit I get the following error when a block is submitted:
HTTP request failed: The requested URL returned error: 500 Internal Server Error [2015-09-13 08:49:02] submit_upstream_work json_rpc_call failed
I have received this error consistently when submitting blocks to version 0.4.1.
To verify it wasn’t just caused by my modified version of slimminer I also mined on version <IP_ADDRESS> > found at https://github.com/kryptoslab/slimcoin/releases compiled from source on the same machine. I have found several blocks that have been submitted and accepted without a problem.

I confirm that until now, I couldn't find any blocks with 0.4.1 - that may be related to this issue.

Fixed.


Remove icon disappears if a search value is not in the search results

Describe the bug
When you enter a value in the search bar and if the value is not present in the search results the remove icon gets disappeared.
To Reproduce
Steps to reproduce the behavior:

Go to home page
Click on the search bar
Start typing
If the value that typed is not in search results the remove icon gets disappeared.

Expected behavior
Remove icon in the search bar should appear if any value is present in the search bar

Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Browser: Chrome, safari, firefox
Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

change the close button which is dependent on results.length to searchValue.length and it work.thats all.

This should essentially support clearing the input text and search results as well.

You can assign me. I would like to work on this.

I can take this up

You can assign it to me.

Fixed it in PR #1489


Support to node v.12.0.0 or later.

Description
The static field syntax cannot be used Node version 12 or lower. So, I added babel with a plugin(@babel/plugin-proposal-class-properties) that compiles static field syntax so that it can be used even in node version 12 or lower environments.
And since I always have to run babel after code modification, I added husky to set babel to compile before commit.

LGTM


Allow setting custom prefix for Async Alpine

We support custom prefixes for Alpine, but the likelihood is if someone is using that it's because they want HTML validation.
In that case Async Alpine doesn't allow setting a custom prefix in order to pass validation.
We should change the API so you can declare a custom prefix for Alpine and for Async Alpine. Proposed:
AsyncAlpine(Alpine, {
  prefix: 'data-ax-',
  alpinePrefix: 'data-x-'
})

Added in 0.3.0


bug: Inline code in heading has incorrect highlighting

Neovim version (nvim -v)
0.10.1
Neovim distribution
N/A
Operating system
MacOS
Terminal emulator / GUI
Iterm2/tmux
Describe the bug
When in normal mode, the inline code within heading is not visible due to incorrect highlighting (bg color is the same as fg), causing the inline code to be invisible.
Below is a screenshot in normal mode, the inline-code on line 6 is not visible.

Markdown file content:
# Title

## Heading 2

### Heading 3

#### Heading 4 with inline code: `inline-code`

Paragraph

Expected behavior
The highlighting for inline code within heading should have distinct fg/bg, so the text is not hidden.
Healthcheck output
==============================================================================
render-markdown: require("render-markdown.health").check()

render-markdown.nvim [version] ~
- OK plugin 7.4.6
- OK neovim >= 0.10

render-markdown.nvim [configuration] ~
- OK valid

render-markdown.nvim [nvim-treesitter] ~
- OK installed
- OK markdown: parser installed
- OK markdown: highlight enabled
- OK markdown_inline: parser installed
- OK markdown_inline: highlight enabled

render-markdown.nvim [executables] ~
- OK none to check

render-markdown.nvim [conflicts] ~
- OK headlines: not installed
- OK obsidian: not installed

Plugin configuration
require("render-markdown").setup({
        anti_conceal = {
            enabled = true,
        },
        heading = {
            width = "block",
        },
        latex = {
            enabled = false,
        },
    })

Plugin error log
N/A

Confirmations

[X] I have updated this plugin to the latest version using my plugin manager
[X] I have provided the text contained in all screenshots as raw text in this issue. This means if there is a screenshot below it is the copy pasted contents of the file in the screenshot. I understand that my issue will be closed if I have not.

Additional information
I tried finding the highlight group for inline code within heading, I suspect it may be caused by bgtofg related highlighting, but I could be wrong.
Any help is appreciated!

Wow it works thanks for the quick response!
And thanks for the goated plugin!


Updated normalize.css to 7.0.0

I don't have deep enough knowledge of the actual tachyons.css file to know if this is a good idea or not, but I wanted to recompile and put in a PR since necolas dropped the update yesterday.

Rebased and ready to merge!

It seems I can't close this PR on my own; sorry maintainers 🙁
Please feel free to delete this PR if you get a chance.
I nuked and recreated my fork for my own personal use; you can find it here. It accomplishes all the same goals with well-written, semantic commit messages and has no merge conflicts. Let me know if you'd like me to put in a new PR. Thanks!

Closing in favor of #384. Thanks @cwonrails !


static-web-server: 2.17.0 -> 2.18.0

Diff: https://github.com/static-web-server/static-web-server/compare/v2.17.0...v2.18.0
Changelog: https://github.com/static-web-server/static-web-server/blob/v2.18.0/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 236541 run on x86_64-linux 1

1 package built:

static-web-server


[core] Add DirectionProvider

Closes https://github.com/mui/base-ui/issues/831
Closes https://github.com/mui/base-ui/issues/59

Docs: https://deploy-preview-931--base-ui.netlify.app/components/react-direction-provider

Updates Menu, RadioGroup, Slider, Tabs, Accordion, ToggleGroup

[x] I have followed (at least) the PR section of the contributing guide.

Should we default to checking for computed styles if it's cheap, like inside an event, and falling back to the provider otherwise?

I thought about this, but we have to document DirectionProvider as a required step when changing the behavior is involved anyway to maintain that "there is one single way to set up RTL", even though technically it's not necessary (e.g. for ToggleGroup/RadioGroup)
And if a component doesn't actually use the provider internally it would obscure issues when someone used the provider but forgot to set dir

Floating elements force read the style and would ignore the provider,

@atomiks I think this should be fine for our components since only Menu is the only one that requires the provider (it has keyboard nav).
For the rest (popover, preview card etc), they should first use logical sides instead of left/right
I suppose since align: 'start'|'end' is already direction-aware without the provider, maybe side should be as well? https://github.com/mui/base-ui/pull/950/commits/0a51ad14684945498ff846e5370e832f8cedeb7f#diff-3edb30ade872773deda81b8799e55170e5a0a58fab8e2bee97a2210169e99066R95-R109


Fault during the configuration

Issue related to
Sunsynk / mbusd Home Assistant Add-On
Describe the issue/bug
Hello, I added and configured the addon according to these instructions
https://www.youtube.com/watch?v=X_ypBi7iuJc
Unfortunately I get the following error when saving:
Error saving the add-on configuration, expected int. Got {'DRIVER': 'solarman', 'INVERTERS': [{'SERIAL_NR': '203xxxxxxxxxxx34', 'HA_PREFIX': 'SS', 'MODBUS_ID': 1, 'DONGLE_SERIAL_NUMBER': 'E4Axxxxxxxx5', 'PORT': 'http://1xx.1xx.1xx.xx"'}], 'SENSOR_DEFINITIONS': 'single-phase', 'SENSORS': ['energy_management', 'power_flow_card ', 'pv2_power'], 'SENSORS_FIRST_INVERTER': ['settings'], 'MANUFACTURER': 'Sunsynk', 'READ_ALLOW_GAP': 2, 'READ_SENSORS_BATCH_SIZE': 20, 'SCHEDULES': [{'KEY': 'W' , 'READ_EVERY': 15, 'REPORT_EVERY': 60, 'CHANGE_ANY': False, 'CHANG...
Expected behavior
A clear and concise description of what you expected to happen.
Your environment

Home Assistant version: 2024.8.2
Addon:

Name: sunsynk-multi
Version: 2023-08-17

Inverter:

Make: sunket inverter with E Linter WIFI Dongle
Model: __
Firmware: __

Adaptor details:

RS485/RS232/solarman
RS485/RS232 brand

You configuration

paste config in the block surrounded by 3x backticks

Logs

paste logs in 3x backticks...

DONGLE_SERIAL_NUMBER should be an integer - the Pysolarman driver does not accept alphanumeric serial numbers
You probably have the wrong solarman dongle not compatible with https://pysolarmanv5.readthedocs.io/en/stable/


fix: failed tests after the release of AREnableSavedSearchToggles flag

The type of this PR is: Fix

This PR resolves []
Description

PR Checklist (tick all before merging)

[ ] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[ ] I have tested my changes on iOS and Android.
[x] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

failed tests after the release of AREnableSavedSearchToggles flag - dimatretyak

This PR contains the following changes:

Dev changes (failed tests after the release of AREnableSavedSearchToggles flag - dimatretyak)

  Generated by :no_entry_sign: dangerJS against ab362e40d9167ec0ad47e380e692e033ec1908bc


Allow pipenv version override

My Django app started failing to deploy today:
-----> Python app detected
-----> Running pre-compile hook
-----> Installing python-3.6.1
-----> Installing pip
-----> Installing requirements with latest pipenv...
       No package provided, installing all dependencies.
       Installing dependencies from Pipfile.lock…
-----> Running post-compile hook
-----> Collecting static files...
       Traceback (most recent call last):
         File "manage.py", line 6, in <module>
           from django.core.management import execute_from_command_line
       ModuleNotFoundError: No module named 'django'
 !     Push rejected, failed to compile Python app.
 !     Push failed

At least while pipenv is under rapid development, I think there should be an option to disable the --upgrade option when pipenv is installed during builds.

we'll start pinning it


Home Assistant Autodiscover MQTT messages do not have retain flag set

The Home Assistant (HA) integration using MQTT Autodiscover works as expected. But the device disappears from HA when HA is restartet. I know that this behavior is described in the documentation (https://mp-se.github.io/gravitymon//services.html#home-assistant, option 3). I still think that this is a bug because the root cause is that the Autodiscover MQTT messages "homeassistant/sensor/..." do not have the MQTT retain flag set.
As a feature enhancement one could send the Autodiscover MQTT messages not only during "push test" but also after each power on.

I can add an option so that the MQTT retain flag can be set if wanted. There are pros and cons of having retain on.
If retain is used then the new feature would not really be needed and you can always set the sensors manual in the HA configuration if persistence is wanted.

Thanks. An option to set the MQTT retain flag would be great.
I still think that sending Autodiscover MQTT messages after each power on is useful. Many people run the MQTT broker on the same device as Home Assistant. A restart of the device will affect both and retained messages are not persistent in Mosquitto using the default configuration.

Well, I cant do it at every power on, in gravity mode there you don't want to send the data since it will take too much time and trying to send to much data when in config mode can cause crashes on the 8266 due to low memory.
If you want it always persisted the better option is to define the sensors in Home Assistant and let gravitymon send the data. That is the most effective and safe method.

I have had a deeper look on the code part for MQTT and I believe the docs are wrong. Autoregistration is no longer limited to push testing. This was not properly migrated to 2.x stream. The problem is that on an esp8266 it crashes since there is not enough memory for handling such a big payload which is not something that can be fixed. I will update the docs for that part.

The current limit on the esp8266 is around 1000 characters in total, more than that then it crashes due to lack of memory. In most cases the auto registration data is more than that so it would not help to do this during startup. I would recommend using an ESP32 instead that would solve the problem.

I'm considering upgrading my devices to ESP32.
Regarding the ESP8266 limit of 1000 characters: wouldn't it be possible to do the auto registration in multiple steps? The MQTT messages are static and only change with a different configuration. They could be stored completely formatted together with the config data.

I'm considering upgrading my devices to ESP32.
Regarding the ESP8266 limit of 1000 characters: wouldn't it be possible to do the auto registration in multiple steps? The MQTT messages are static and only change with a different configuration. They could be stored completely formatted together with the config data.

Probably yes, but that would require a lot of refactoring and changing how the push code works. It might also require multiple connection to the server which will increase power consumption and reduce battery life.
I dont think it worth the effort when there are other options that will work and the esp8266 is not really well supported anymore.

Understood, I will upgrade my devices to ESP32. Right now my devices use an ESP8266 D1 mini. Which ESP32 is the best pin compatible replacement and most recommended? ESP32c3 mini or ESP32s3 mini?

All the mini will work but some C3 boards has had issues with the antenna and poor wifi connection. Both of them are good candidates since they also have BLE. The s2 mini will also work, even the older ESP32 d1 mini even though this board is wider and can be hard to fit into the tube.

You can try the build i the dev branch, that has the option to set the retain flag for messages and fixed the faulty link

I did a very brief test. When I do a test push test the messages do have a retain flag. However, all of them including the measurement values do have a retain flag. This is not desirable since old measurement values may be reported by the MQTT broker. I had also issues with the gravity mode. No measurements were sent. I still have to verify this.

All messages will have the retain flag set, this is the reason for forcing a user to activate it. This integration is not specific for Home Assistant and I use that for many more projects and I dont want to put any Home Assistant logic into the framework code.
What I sense you are asking for is a specific home assistant integration which is possible to add but will require some work to implement. It would probably be easier to use the REST api rather than the MQTT integration for and also get around the current memory limitations with the esp8266.

Regarding the retain flag, I do agree with you that this is not needed if all defined messages are sent during every push. However, this is currently not the case for my esp8266. I will definitely upgrade to esp32. Having the retain flag only on a part of the messages is not so unusual. Integrations like zigbee2mqtt does it also the same way.
With the current beta firmware, I do have the problem that the push test is working. However, I do not see any MQTT messages send during normal operation. I don't know how to debug this.

Well, it could be due to a crash. Its possible to see the serial debug data if you connect direct to the esp and remove the battery, when you tilt the device it should behave as in gravity mode.
One option that would not be to difficult to add would be to tag a  message/topic as persistent. One way could be to add a special char before the topic name on those topics that should be persisted. For example start with a hash or exclamation mark.

An option to tag a persistent message with a special character to get a retain flag would be great and a perfect solution.
On the other aspect that MQTT push is not working for me, I attached a log from the serial console. I looks like that the device crash.

Yes, thats a crash, most likely from low stack space = to large mqtt payload that cannot be handled. If you get the payload to below 1000 then it might work, so delete one or more of the sensor values.
Not sure if i can refactor some code to handle it or this is in the arduino/dependant libraries.

I removed the Home Assistant MQTT auto-discovery messages from the config which shortens the message set drastically. In this case MQTT push is working as expected.
The complete message set in the template had a size of 1387 characters.

I have done some refactoring to the push code to free up some stack space +1kb. This should be enough to handle the full payload on an esp8266. I will need to do some more testing to see that I haven't broken anything else...


Fix "sign" & "submit" Sequence field autofill with Tickets

High Level Overview of Change
@manojsdoshi found a bug in the handling of Sequence autofill by the "sign" and "submit" RPC commands when a TicketSequence is part of the transaction.
As it stands, if the Sequence field is missing, then the next usable sequence number associated with the account is filled in.  This leads to unexpected behavior.  The non-zero Sequence field takes precedent over the TicketSequence, so the associated Ticket is not consumed.
The fix is for "sign" and "submit" to check the transaction for a TicketSequence.  If a TicketSequence is present and a Sequence field is not, then the commands fill in 'Sequence': 0 which is what is required for the TicketSequence to be used.
Type of Change

[x] Bug fix (non-breaking change which fixes an issue).
[x] Test (added unit test to verify fix).

Test Plan
Using the "sign" or "submit" RPC commands, submit a transaction with a TicketSequence but no Sequence field.
Before the fix you should observe the transaction returned by the command has a non-zero Sequence field filled in.  If the transaction is submitted then the TicketSequence will not be consumed.
After the fix you should observe the transaction returned by the command has a 'Sequence': 0 field filled in.  If the transaction is submitted then the TicketSequence is consumed if the transaction returns a tec or tesSUCCESS code.

Should a transaction be considered malformed if it has a non-zero Sequence and a TicketSequence?

 Please follow the steps here to unsubscribe - https://docs.github.com/en/github/managing-subscriptions-and-notifications-on-github/managing-your-subscriptions
I would like to ask you to stop using offensive languages.
Thanks.

@ximinez, that's a really reasonable suggestion.  It would be really easy to add that validation into Transactor::checkSeqProxy.  But it would take an amendment.  The currently proposed change is outside of transaction processing so it doesn't require an amendment.
I'll code that up a commit making that change and add it to this pull request.  Once we see what it looks like we can decide whether it's a change we'd like to make.

@ximinez, I added a commit that includes the suggested amendment.  Let me know what you think.  I do think that the amendment will help manage confusion resulting from errors in usage.

It doesn't need an amendment if it gets into v1.7.0 because TicketBatch has not been in any stable releases yet. Changes to unreleased amendments are explicitly not considered to be breaking/transaction processing changes.

@carlhua, what do you think?  Shall we put this in the next release candidate?

If we were to incorporate the bug fix into 1.7.0, then no additional amendment would be required.  The most recent [FOLD] commit shows wha that would look like.

I'm removing the Amendment and API Change labels because this change is going into the first release where TicketBatch is available.  Since the API change only applies to transactions with tickets there's not change, only an improvement :wink:.


multidrag select across sortables

Solves https://github.com/SortableJS/Sortable/issues/2173

This is great! And I've updated the CodePen example with your patch.
A couple of things though… and I'm not sure if they're existing bugs or issues with your patch:

In my primary implementation of MultiDrag, I'm selecting/deselecting elements programmatically using Sortable.utils.select() and Sortable.utils.deselect(). I've added links below the example to select programmatically. It appears that the new select-across-lists functionality works fine the first time, but on subsequent attempts to select programmatically, Sortable falls back to its old you-can't-select-across-lists functionality.
The multiDragKey option doesn't appear to have any effect. Ah ha! Okay, here's an issue about that.. I guess this is an existing bug. People in that thread seem to think this is a non-issue. So maybe it's a new bug introduced by this patch? I've added multiDragKey: 'Meta' to the example and it seems to have no effect (commented out for now). But I'll comment on the other issue.
MultiDrag has functionality that allows you to hold down the shift key (evt.shiftKey) and it will select consecutive elements between the current click and previous. This still works, but only within a single list. Could we get this to work between lists? I guess we would honor the HTML source order.

Thanks for the feedback @jjeff , I'll have a look at it tomorrow!

I've added a new commit that should take care of 1 and 2.
It turns out I was making a mistake when entering the sortables into the global group map. I falsely expected the option parsing that happens in the constructor of Sortable to already have happened, so did not take in account that options.group could be a string at this point. An easy fix.
To (hopefully) make things somewhat more legible, I separated the "global" part of the _deselectMultiDrag method out into a utility function called clear.
I also made a small helper function called itemElIsInSortableGroup, that returns true if the sortable instance that holds a specific list item belongs to the same group as some other sortable. Had to add this check to select() to make sure items weren't deselected simply for belonging to another sortable than the one you were currently selecting in (this is what made cross-group programmatic selection impossible once multiDragSortable was set (after first selection)).
As for 3, I'll give it a shot!

Updated the Code Pen again.
The multiDragKey functionality is still not acting like I'd expect. According to the docs: The multiDragKey is  "a custom keyboard key may be designated as having to be down for the user to be able to select multi-drag elements." In my mind, that means you can't select anything unless you hold down the key. With the current PR, single items can be selected. But selecting a second will deselect the first. But since single items can be dragged without "selecting" them first (just grab and drag), this functionality doesn't really make sense. The behavior that I would expect is: if the key isn't down, nothing will get selected.
I would probably change those docs to say "A custom keyboard key may be designated as having to be down for the user to be able to select multi-drag-enabled elements."
Also FWIW, the MultiDrag Options Example shows multiDragKey: null. But the null option actually produces an error: Uncaught TypeError: Cannot read properties of null (reading 'toLowerCase'). Apparently, the code is trying to set null to lowercase. 🙂

Aha! This is good to know. I'll see what I can do.

That's strange, this behavior (multidrag not implementing multiDragKey correctly, as stated above) seems to be identical to me on the current master branch. Can you please have a look and see if this is the same for you?

I've been testing and I'm sometimes getting an error saying:
Unhandled Exception TypeError: Cannot read properties of null (reading 'Sortable1660768120063') at t.dragOver

…which appears to be happening in the expando line of the dragOver method (in the new MultiDrag.js).
And it looks like adding this return; solves the problem:
dragOver({ target, completed, cancel, originalEvent }) {
  if (folding && ~multiDragElements.indexOf(target)) {
    completed(false);
    cancel();
    return; // <-- added this
  }

  const toSortable = target.parentNode[expando]; // <-- this is where the error is happening
  // etc

I'm not sure I understand the code enough to know if I might be breaking something else. But in my testing, it looks like this solves the problem and (I think) everything is working.

Okay another approach:
dragOver(…) {
  …

  const toSortable = target.parentNode && target.parentNode[expando];
  //                 ^^^^^^^^^^^^^^^^^^^^

This seems to solve the problem.

Thanks @jjeff , I copied your fixes and reverted to the old behavior with multiDragKey. I've also squashed the branch history to hopefully make merging cleaner. :)

Great! Thanks, @maxbol. This makes multiDrag a lot more useful for me.
I hope this gets into Sortable core soon so others can benefit.

I've updated the CodePen example with the latest version of this PR. Works great!

Nudge to @owen-m1 and @RubaXa. It would be great to get this into the distribution! 🙂

Any news about when it possible merge?

@owen-m1 @RubaXa is this moving forward? I am running into a bug that this PR helps address.
Thanks!


Installation problems: libtorch_cuda_cu.so not found

We installed miniconda (user-level install), then activated a new conda environment for tankbind, and we installed TankBind following the instructions to the letter. We found the following error:
(tankbind) rodriguezg@darwin:~/code/TankBind/examples$ python -V
Python 3.8.13

(tankbind) rodriguezg@darwin:~/code/TankBind/examples$ python virtual_screening_test_tankbind.py
Traceback (most recent call last):
  File "virtual_screening_test_tankbind.py", line 11, in <module>
    from feature_utils import get_protein_feature
  File "/data/home/rodriguezg/code/TankBind/examples/../tankbind/feature_utils.py", line 21, in <module>
    from torchdrug import data as td     # conda install torchdrug -c milagraph -c conda-forge -c pytorch -c pyg if fail to import
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torchdrug/__init__.py", line 1, in <module>
    from . import patch
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torchdrug/patch.py", line 13, in <module>
    from torchdrug import core, data
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torchdrug/core/__init__.py", line 2, in <module>
    from .engine import Engine
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torchdrug/core/engine.py", line 10, in <module>
    from torchdrug import data, core, utils
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torchdrug/data/__init__.py", line 1, in <module>
    from .dictionary import PerfectHash, Dictionary
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torchdrug/data/dictionary.py", line 4, in <module>
    from torch_scatter import scatter_max
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torch_scatter/__init__.py", line 16, in <module>
    torch.ops.load_library(spec.origin)
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/site-packages/torch/_ops.py", line 255, in load_library
    ctypes.CDLL(path)
  File "/home/rodriguezg/miniconda3/envs/tankbind/lib/python3.8/ctypes/__init__.py", line 373, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: libtorch_cuda_cu.so: cannot open shared object file: No such file or directory
(tankbind) rodriguezg@darwin:~/code/TankBind/examples$

This library libtorch_cuda_cu.so is nowhere to be found.  Any ideas?
For what is worh, the host has nvidia kernel driver version 510.85.02 (I'm not sure if this influences conda to install different versions of CUDA libs).

torch_scatter is part of PyG. could try to re-install the version that match your cuda.
following the instruction described in "https://github.com/pyg-team/pytorch_geometric"
pip install torch-scatter -f https://data.pyg.org/whl/torch-1.12.0+${CUDA}.html
pip install torch-sparse -f https://data.pyg.org/whl/torch-1.12.0+${CUDA}.html
pip install torch-geometric

Hope this help.
Wei

Thank you very much; your suggestion put me in the right direction. And since I'll admit I am biased against Conda's shotgun approach to dependency management, I decided to:

use neither Conda nor Miniconda; use only pip
follow the latest (pip-related) install instructions of the original authors of each required package
and use the latest possible (stable) versions of all packages, subject to common-denominator constraints (for instance, PyG does not currently publish wheels for Torch 1.13; see below).

With this in mind, the following installation procedure worked for me.  My Host environment is Ubuntu 22.04LTS and Nvidia driver 510 (CUDA 11.6).  I had to install Python 3.9 (I use pyenv for this) because TorchDrug requires a version < 3.10.  Then, on a clean venv, I installed everything as follows:
MY_VENV=tb_venv
CUDA=cu116

################################
# Install TankBind deps
################################
#
# Install PyTorch (latest stable is PyTorch 1.13, but PyG only supports up to 1.12):
pip install torch==1.12.1 --extra-index-url https://download.pytorch.org/whl/${CUDA}

# Install Torch Geometric (needs PyTorch <=1.12)
pip install torch-scatter -f https://data.pyg.org/whl/torch-1.12.1+${CUDA}.html
pip install torch-sparse -f https://data.pyg.org/whl/torch-1.12.1+${CUDA}.html
pip install torch-geometric

# Install TorchDrug (Requires: Python >=3.7, <3.10)
pip install torch-cluster -f https://data.pyg.org/whl/torch-1.12.1+${CUDA}.html
pip install torchdrug

# The rest didn't give me any trouble:
pip install torchmetrics biopython jupyterlab nglview tqdm mlcrate pyarrow

####################
# Install TankBind
###################
#
# Clone the TankBind repo:
rm -rf TankBind
git clone https://github.com/luwei0917/TankBind.git

# Dowload and install p2rank
cd TankBind
wget https://github.com/rdk/p2rank/releases/download/2.4/p2rank_2.4.tar.gz
tar zxf p2rank_2.4.tar.gz

So this gives me an apparently flawless install.  Then I tried to run TankBind, but I found an error.  Here's the output when running examples/high_throughput_virtual_screening_LRRK2_WDR.ipynb  (I extracted this Notebook's code to a script, in order to run it from the console):
(tb_venv) marinjl@darwin:~/TANKBIND/TankBind/examples$ python virtual_screening_test_tankbind.py
Reading protein...
Protein PDB read and formatted.
----------------------------------------------------------------------------------------------
 P2Rank 2.4
----------------------------------------------------------------------------------------------

predicting pockets for proteins from dataset [protein_list.ds]
processing [6dlo.pdb] (1/1)
predicting pockets finished in 0 hours 0 minutes 8.083 seconds
results saved to directory [/data/home/marinjl/TANKBIND/TankBind/examples/HTVS/p2rank]

----------------------------------------------------------------------------------------------
 finished successfully in 0 hours 0 minutes 9.751 seconds
----------------------------------------------------------------------------------------------
100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 10000/10000 [00:01<00:00, 7913.11it/s]
Pocketing succesfully done.
Processing...
Done!
['HTVS/dataset/processed/data.pt', 'HTVS/dataset/processed/protein.pt']
Constructing dataset...
12:30:57   5 stack, readout2, pred dis map add self attention and GVP embed, compound model GIN
Loading model...
Ready to start inference.
  0%|                                                                                | 0/2000 [00:00<?, ?it/s]
/home/marinjl/.pyenv/versions/tb_venv/lib/python3.9/site-packages/torchdrug/utils/decorator.py:189: UserWarning: from_smiles(): argument `node_feature` is deprecated in favor of `atom_feature`
  warnings.warn("%s(): argument `%s` is deprecated in favor of `%s`" % (obj.__name__, key, value))

[... a few more deprecation warnings like this from TorchDrug, which look harmless ...]

  0%|                                                                                | 0/2000 [00:19<?, ?it/s]
Traceback (most recent call last):
  File "/data/home/marinjl/TANKBIND/TankBind/examples/virtual_screening_test_tankbind.py", line 169, in <module>
    y_pred, affinity_pred = model(data)
  File "/home/marinjl/.pyenv/versions/tb_venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
    return forward_call(*input, **kwargs)
  File "/data/home/marinjl/TANKBIND/TankBind/examples/../tankbind/model.py", line 343, in forward
    compound_out = self.conv_compound(compound_edge_index,edge_weight,compound_edge_feature,compound_x.shape[0],compound_x)['node_feature']
  File "/home/marinjl/.pyenv/versions/tb_venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
    return forward_call(*input, **kwargs)
  File "/data/home/marinjl/TANKBIND/TankBind/examples/../tankbind/GINv2.py", line 182, in forward
    hidden = layer(edge_list, edge_weight, edge_feature, num_node, layer_input)
  File "/home/marinjl/.pyenv/versions/tb_venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
    return forward_call(*input, **kwargs)
  File "/data/home/marinjl/TANKBIND/TankBind/examples/../tankbind/GINv2.py", line 110, in forward
    update = self.message_and_aggregate(edge_list, edge_weight, edge_feature, num_node, input)
  File "/data/home/marinjl/TANKBIND/TankBind/examples/../tankbind/GINv2.py", line 91, in message_and_aggregate
    edge_update = self.edge_linear(edge_update)
  File "/home/marinjl/.pyenv/versions/tb_venv/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
    return forward_call(*input, **kwargs)
  File "/home/marinjl/.pyenv/versions/tb_venv/lib/python3.9/site-packages/torch/nn/modules/linear.py", line 114, in forward
    return F.linear(input, self.weight, self.bias)
RuntimeError: mat1 and mat2 shapes cannot be multiplied (123x18 and 19x56)

Any ideas? Do you guys have a sort of minimal working example in order to test if TankBind is installed correctly?

"RuntimeError: mat1 and mat2 shapes cannot be multiplied (123x18 and 19x56)" occurs when using newer version of torchdrug. Please ensure that you are using v0.1.2.

Thanks, the example is working now.  Just out of curiosity (and because I have the whole install process scripted), I went backwards testing all previous versions of TorchDrug in sequence (see https://pypi.org/project/torchdrug/#history).  It was only after I arrived at torchdrug version 0.1.2.post1 that the error went away.  In turn, this version needed a downgrade to Python 3.8.
Any chance you guys will upgrade your code to the latest TorchDrug soon?
Anyway, I'm closing this issue since everything seems to be working fine.  Thanks for your help!

Glad to hear that you resolve the problem. We plan to drop the dependency of torchdrug in the future. it was mainly used to extract features from the small molecule, but it's a bit too heavily loaded with other modules that we don't need.


ref: guard.api

Nothing works yet, just for progress update
should make #68, #76, #86, #109 possible, unless anyone is against this approach

spec is in ADVANCED.md!

@xiaoshihou514 status?

@xiaoshihou514 status?

Haven't worked on a codebase of this complexity before :crying_face: , still tinkering to find the right abstraction and stuff.

@glepnir promised a re-factor so closing :+1:


Add latest version URL to CDN

Is your feature request related to a problem? Please describe.
A copy of Gravity's releases is published to a CDN here: https://static.buildit.digital/gravity-ui-web/
Each version gets a unique URL, e.g. https://static.buildit.digital/gravity-ui-web/v2.2.0/gravity.css
It would be nice if we additionally had URLs that:

Always point to the latest version, e.g.: https://static.buildit.digital/gravity-ui-web/latest/...
Alaways point to the latest, SemVer-compatible version for each major version number. E.g.:

https://static.buildit.digital/gravity-ui-web/v1.x/...
https://static.buildit.digital/gravity-ui-web/v2.x/...
etc.

The use-case would be for simple websites or prototypes that want to use the CDN but don't necessarily want to be pegged to a specific release.
Describe the solution you'd like
Add URL as per the description. However, one question would be the exact behaviour these URLs should have:

Should they be temporary (302) HTTP redirect to whatever the latest (compatible) release's URL is? (Note that permanent (301) redirects are inappropriate in this case, since the final location will change over time, so we don't want browsers & search engines storing the final URL)
Should they return the content directly (so be 200 responses), but set caching headers in such a way that user-agents will revalidate after a sensible period (a few days perhaps - we don't issue new releases that frequently after all)

These asks may be in conflict.  The cache header is attached to the file when it is uploaded, so you get one chance to set it.  If you are going to redirect from a url to that file, you will get that immutable cache expiration and latest really won't mean latests the next time it updates.  The only way I see latest working is by having a physical location with its own cache settings.

:tada: This issue has been resolved in version 2.2.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: