[Java] Add Recognizers dependencies in README

Related to XXXX
Description
The Java's README doesn't contain the content to install the Recognizers.
Specific Changes

Add Installation sub-bullet in the README
Define how to install core Recognizer's features
Define how to install numbers Recognizer's features
Define how to install numbers with units Recognizer's features
Define how to install datetime Recognizer's features
Define how to install choice Recognizer's features

Testing
We validated the changes rendering the document manually and comparing it with the C# README.
Before vs After

List of the current Recognizers

Already merged in MS


Screenshots of unit modals added to curric automate script

Description
Added optional screenshots of unit modals to the curriculum automation script.
Issue(s)
Fixes CUR-1058
How to test
Note this will take a while to run, as it's screenshotting every sequence/unit-modal

Clone the repo
Start the dev server npm run dev
./scripts/dev/curriculum/automate screenshot :foo --modals
./scripts/dev/curriculum/automate screenshot :bar --modals
./scripts/dev/curriculum/automate screenshot compare :foo :bar

Check the page launched from compare command.
Note: It doesn't currently render the unit options only the unit options overview page currently.

:tada: This PR is included in version 1.629.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


switch to new s3 bucket from BOSH team

These are public and will contain all blobs for SL eCPIs

This is now done


readme: add links to bundler plugins

vite → https://github.com/sodatea/vite-plugin-node-stdlib-browser
etc
related #14

There is already opened pull request for this: https://github.com/niksy/node-stdlib-browser/pull/17
If you wish to work on changes, please!


Fix Azure Integration Imports and Improve Flavor Registration Error Handling

Describe changes
The Azure artifact store flavor imported the service connector which required. the Azure library.
This is very problematic since it would lead to an error during flavor registration, which would mean that subsequent integrations would be missing, e.g., zenml model-deployer flavor list would return an empty list even if all deployer integration requirements were installed.
To prevent integration issues like this to affect other integrations in the future, I also wrapped the flavor registration logic in our flavor registry in a try-catch block.
Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[ ] If my change requires a change to docs, I have updated the documentation accordingly.
[ ] If I have added an integration, I have updated the integrations table and the corresponding website section.
[ ] I have added tests to cover my changes.

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Other (add details above)

fa9r prevented a review from schustmi now

I guess, I was a bit too late to press the comment button 😄 In any case, some thoughts that I wanted to share anyhow:
The changes look good to me as well. However, I am confused about the implications of this issue and am unsure if this is the ultimate solution.
When we initialize the store, we always try to register all the integration flavors. From what I understood, the Azure artifact store flavor itself imported constants from the connectors module which required the Azure library to be installed, thus it failed. However, this should not only just make the flavor registration fail but cause a store initialization error as well, meaning the first time you initialize the SQLZenStore it is gonna fail. The confusing part is: since this is the last step of the initialization process, you were able to keep using ZenML even though the main ZenStore has failed to migrate the flavors with an error during the initialization process.
It means, this was a relatively silent failure and these changes save other integrations but make the failing integration fail even more silently now. I think, we really need to implement some sort of testing mechanism to make sure this does not happen to our integrated flavors now.

also, #unblock-@schustmi 😄


Reduce cgo usage in pkg/bpf

Two more changes reducing cgo usage in pkg/bpf and its users:

Remove unnecessary cgo integration from pkg/bpf/map.go, akin to commit 0578b6db95dd917141eb462cb07cdbe80e9bb115
Provide wrapper constants for bpf map types and flags in order to confine cgo usage to within pkg/bpf/bpf.go. Users of the package will no longer need to import "C" to get the constants.

Thanks @tklauser!


border router implementation

Hi All,
I have seen thread cli example it is working fine. I want to implement thread network with my Native PC or hardware boards (cc2538). My question is:

Is Leader will do the functionality of border router, by adding special functionality(What would be the requirements) or separate Border router (Hardware) require?
Is there any specific hardware to implement Border router in openthread? if so let me know please.
can any one share the procedure and details for implementing thread network and send message between child, router and Leader.

Thanks,
Praveen

You can use wpantund to expose a Thread network via a standard IPv6 network interface on Unix-like operating systems.

Thanks @jwhui,
how i can implement on Hardware, what hardware (Border router) should i require and how can i do it. let me Know please.
Thanks,
Praveen

The wpantund wiki has installation instructions for Ubuntu and Mac OS X.


Fixes a short circuiting bug

If an observer returns a rejected promise, Promise.all will short circuit and return before the remaining observers have resolved.
Hopefully we can eventually swap this out for Promise.allSettled (see here) but for now we have to map over each promise and catch errors.


Auto backup scripts for databases

Right now all the backups are handled manually. Probably a good idea to automate this

For consideration - moving the SQLite data.db file into its own directory, instead of creating it in the root directory, would allow docker builds to create a persistent volume link to the directory, which would expose data.db to the host system, and prevent it from being wiped when the container is destroyed and/or rebuilt.
This would add some complications, in that to maintain backwards compatibility, we'd then need to check if there is an already existing data.db file in the root directory, and if so, move it to the new folder first before attempting to read/write to it.
The upshot is that having the DB in its own directory would keep things cleaner should you opt to save copies of the DB periodically to ward against corruption and/or as a staging step as part of automating backups elsewhere.

I'll probably add a database path option when I rewrite the configuration handling for #75. This would allow people to choose their own database folder.
I'll probably default it to ./data/data.db to keep it working good for the docker peeps but if left blank it'll assume  the database is in the root folder

fixed in e63930a


Add a notes option for each card in the Kanban board

Issue: Add Notes Button with Edit/Delete Functionality on Application Cards
Description
The absence of a dedicated "Notes" feature on application cards limits users' ability to add or modify specific details. Incorporating a "Notes" button that opens a modal with editable notes will enhance user flexibility and organization.
Proposed Solution
Introduce a "Notes" button/icon on each application card, providing users with a convenient way to access and edit application-specific notes. Clicking this button will open a modal where users can view, edit, or delete notes related to that application.
Expected Behavior

The "Notes" button should be clearly visible on each application card.
Clicking the "Notes" button will open a modal displaying existing notes (if any) and offering options to edit or delete them.
Users can add new notes or modify existing ones within the modal.
Changes made to the notes should be savable or discardable upon user action.

Benefits

Enhanced organization: Allows users to maintain and update specific details or reminders related to each application.
Improved user interaction: Provides a seamless way to manage and update application-specific notes directly from the card view.

Outcome/Result
Successful implementation will empower users with a dedicated "Notes" feature on each application card, enabling convenient management and updates of application-specific information.

We doing a scrollable multi-notes  type of thing or a single note?

I think multi notes would be an overkill ?

Lets prolly do one note for now


exchanged KBM constructor for default Tuning constructor

OK! Yeah I see why you need this change (no rawText on the unmapped KeyboardMapping) but this change isn’t quite right. The default KeyboardMapping constructor has note0 as 60 and frequency0 as 32*MIDI_FREQ_0 or whatever the constant is, so rather than having the second argument be “tunA69to(440)” it should be “tuneNoteTo( 60, 32 * MIDI_NOTE_0 )” (or close to that - sorry I’m on ipad not computer).
That should - in theory - make the test exact again so you can remove the Approx
And this would actually make a difference for synths which use the non-KBM constructor type (which I think sfizz does) in that if you load a short scale (say a scale with period 5) instead of note 60 being 251 you would have tuned note 60 way way down a couple of octaves.
Happy to merge with those changes though. Thanks for fixing the underlying problem!

Also the fact that we don’t have a test in the library that fails in this case means our test suite is incomplete. The real test is take one of the short scales from the library (I think we have some 5 and 6 note ones), apply them to the tuning without a mapping, and simply assert that midi note 60 is 32 * MIDI_FREQ_0 (which is 261.2). That should pass without your change; should fail with your change, and should pass once you have it correct. I can bang that test in this morning if you want or you can do it with this diff or I can do it after. Just lemme know!

Ah yeah, I forgot that this makes a difference when using scl as well. Thanks.
I just played around with the tests for an hour: It seems tuneNoteTo( 60, MIDI_0_FREQ * 32.0 ), does not produce an identical KBM as KeyboardMapping() does. When diffing them, the resulting differences are:
tuningPitch: 32 vs 32.00001
octaveDegrees: 12 vs 0
This apparently results in a lot of failed tests, due to slight differences, especially when not only replacing in Tuning(), but also Tuning(Scale), which should be done for consistency really. I am now unsure how to proceed:

fix all those tests manually with an Approx
somehow make both constructors generate identical classes.
leave as it was to begin with (everything I want to do can be done already, just use different constructor)

Note also that tuneNoteTo() generates a string, which then gets reparsed into the class members, which seems convoluted.

Yeah I am thinking the right answer is to have the kbm default constructor set the raw text to something reasonable rather than do the un parse
The reason I haven’t run into this is I keep a mapping and a state flag both in my synth so don’t use or stream the mapping string if you haven’t set one but that’s ugly state management and your solution is better indeed.
So let me look later today ok? I’ll push something up with a fix this weekend. For now maybe just whack your local copy so you can keep dev on odinngoing and then you can pull when I’ve got it?

Yeah we can do that! It is not an urgent matter though - I can do everything I want to with the main branch right now.
My intention was to contribute something at least, not to make it usable in the first place.

I have it fixed in my user area and turns out we have another edge case bug I need to fix anyway so all good. Should have an update this weekend! Will post here when I do.
Cool stuff. Looking forward to Odin getting this :)


Adds infrastructure for passing NLU results as attachment

Includes the following changes:

Adds metadata.json result from the compare command as an attachment to the build pipeline.
Publishes statistics.json from the compare command as a build artifact to a container called statistics for master branch builds.
When statistics.json is published from a master branch build, adds a nlu.devops.statistics tag to the build so it can be queried for later.
Queries for the previous N (specified by user) builds with the nlu.devops.statistics tag, downloads their artifact archive and unzips.
Merges the statistics.json artifact from previous builds with the statistics.json for the current build.
Adds the merged statistics.json as an attachment to the build pipeline.

nitpick: Add description, repository field and license field in each package.json (probably in another PR)

We won't be publishing these to NPM, I do see that we get warnings, but I'm not sure they are really needed. It's an implementation details that we're using NPM to install the dependencies to the node_modules folder for packaging in the .vsix. We can potentially fix this in a separate PR, but I'd actually rather figure out how to suppress the warning.

@in4margaret re: warnings for missing package.json fields. If we use npm i --silent directly on each package, the warnings are suppressed, but I'm not sure we want to do that (as there may be other warnings we're interested in, e.g., vulnerabilities)


Fixes to the Fresher service workers article

What's changed, or what was fixed?
In the Fresher service workers, by default article,

Removed an unnecessary trailing colon in some mentions of the Cache-Control header.
Added missing enclosing quotes when mentioning the 'imports' string value for the updateViaCache option.
Replaced "imported scripted" with "imported scripts".
Changed http:// to https:// in the semver example URL so it's consistent with the hash of contents example URL (since the point of those two examples is not HTTP vs HTTPS).
Removed an unnecessary '.

CC: @petele

:tada: This has been pushed live to https://developers.google.com/web/


Outputs are always the same.

I train it on my own data, then I find that any picture will get same result. Does anyone see this problem before?

hello, did you figure out what's the problem?

how did you figure it out? I met the same problem. I trained the kitti dataset. The outputs for different images are almost the same.

The error in my code is the dataloader using my own dataset is wrong. Maybe you can check the dataloader, especially the value of bounding box.


JENKINS-45099 special JSON characters are not consistently quoted

Special JSON characters such as [ and ] were not consistently quoted when writing to the output stream, resulting in invalid JSON.
This change uses commons-lang v3's org.apache.commons.lang3.StringEscapeUtils#escapeJson which ensures that all special JSON characters and control characters are encoded correctly.
PTAL @reviewbybees @jglick @vivek

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

LGTM

Would be great if this was as two commits to show the failing test on CI first and then show how this change fixes... because I'm not seeing the encoding issue in the test case
I would also expect tests covering Unicode escaping that escapeJson adds to the mix

@stephenc I added the extra tests you asked for.

ping @i386

@michaelneale I don't think this is a quick fix and probably a suckhole for my time.

@stephenc thanks for the review feedback. Ill find someone else to look at this.

@i386 right - does https://github.com/jenkinsci/blueocean-plugin/pull/1281 need to be undone on the blue side of things now or is that different?


[protobuf] Build error on x64-linux

Package<EMAIL_ADDRESS>Host Environment

Host: x64-linux
Compiler: GNU 10.2.1
vcpkg-tool version: 2024-02-05-9c1e418fc6264dffcab6ca47746a648c35c379b9
vcpkg-scripts version: 13bde2ff1 2024-02-17 (3 weeks ago)

To Reproduce
vcpkg install
Failure logs
CMake Warning at scripts/cmake/vcpkg_common_functions.cmake:3 (message):
  vcpkg_common_functions has been removed and all values are automatically
  provided in all portfile.cmake invocations.  Please remove
  `include(vcpkg_common_functions)`.
Call Stack (most recent call first):
  /home/javed/.cache/vcpkg/registries/git-trees/b72952ad592000a034a334b685b67899634da2de/portfile.cmake:1 (include)
  scripts/ports.cmake:170 (include)

-- Using cached protobuf-cpp-3.5.0.tar.gz.
-- Using cached protoc-3.5.0-win32.zip.
CMake Deprecation Warning at scripts/ports.cmake:100 (message):
  Deprecated form of vcpkg_extract_source_archive used:

      Please use the `vcpkg_extract_source_archive(<out-var> ARCHIVE <archive>)` form.
Call Stack (most recent call first):
  scripts/cmake/vcpkg_extract_source_archive.cmake:12 (z_vcpkg_deprecation_message)
  /home/javed/.cache/vcpkg/registries/git-trees/b72952ad592000a034a334b685b67899634da2de/portfile.cmake:20 (vcpkg_extract_source_archive)
  scripts/ports.cmake:170 (include)

-- Extracting source /home/javed/vc_pkg_test/vcpkg/downloads/protobuf-cpp-3.5.0.tar.gz
CMake Error at scripts/cmake/vcpkg_extract_archive.cmake:19 (message):
  /home/javed/vc_pkg_test/vcpkg/buildtrees/protobuf/src was an extraction
  target, but it already exists.
Call Stack (most recent call first):
  scripts/cmake/vcpkg_extract_source_archive.cmake:5 (vcpkg_extract_archive)
  scripts/cmake/vcpkg_extract_source_archive.cmake:25 (z_vcpkg_extract_source_archive_deprecated_mode)
  /home/javed/.cache/vcpkg/registries/git-trees/b72952ad592000a034a334b685b67899634da2de/portfile.cmake:20 (vcpkg_extract_source_archive)
  scripts/ports.cmake:170 (include)

Additional context
vcpkg.json
{
  "dependencies": [
    "protobuf"
  ],
  "overrides": [
    {
      "name": "protobuf",
      "version": "3.5.0"
    }
  ]
}

Protobuf 3.5.0 is from the end of 2017. Vcpkg changed a lot since then, so I wouldn't expect it to work without some legwork.

Yes, it is old. But I was hoping that since the port supports this version, it may work. Is this by design of vcpkg?

Vcpkg cannot guarantee that every combination of ports and scripts versions works. Either you use old baseline for everything and deal with dead links and errors caused by using newer compilers, or you use recent baseline but adapt the port for old version of the library.

@javedshakeel According to Osyotr's suggestion, you adjust protobuf‘s dependency to the old baseline and old dependency version. Can this port be used?

Closing it as resolved.


Add dependency and codeQL checks

Coverage remained the same at 88.889% when pulling da2c67420573686e0a8ec7fc744bed07dd30a449 on checks into 8aad8958e3e289abad05e410d2b2ec93cd768184 on main.


Maintenance: Update ISAR and apply BB 2.0 changes

Perfect. Just added one minor thing: explicitly set the branch for pycoral as bb 2.0 otherwise warns.

Perfect. Just added one minor thing: explicitly set the branch for pycoral as bb 2.0 otherwise warns.

Makes sense and looks good. Thanks


Could not load GDAL library

Hi there,
I get an error when trying to run the rails server with ffi-ogr:
/home/ronan/.rvm/gems/ruby-2.3.0/gems/ffi-ogr-0.1.0/lib/ffi-ogr.rb:324:in `rescue in module:FFIOGR': Could not load GDAL library (LoadError)
Would this be related to gdal removing ruby bindings?: https://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
Thanks,
Ronan

Hello,
I don't think this is related because the bindings removed use swig and
this one use ffi.
--
Nabil Servais
<EMAIL_ADDRESS>Le Mar 31 janv 2017, à 18:03, Rónán Duddy a écrit :

Hi there,

I get an error when trying to run the rails server with ffi-ogr:

/home/ronan/.rvm/gems/ruby-2.3.0/gems/ffi-ogr-0.1.0/lib/ffi-
ogr.rb:324:in `rescue in module:FFIOGR': Could not load GDAL library
(LoadError)
Would this be related to gdal removing ruby bindings?:
https://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
Thanks,

Ronan

— You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub[1], or mute the
thread[2].

Links:

https://github.com/scooterw/ffi-ogr/issues/16
https://github.com/notifications/unsubscribe-auth/AAwuoey1W3KgkUf8U79IOnx_FwtQbYX3ks5rX2lpgaJpZM4Ly5jz

I'll check it out my issue.. Cheers!


Howe to use EasyRandomParameters with RandomBeansExtension

How can i pass  or use EasyRandomParameters with RandomBeansExtension in  junit5
I Wanted to populate integer value between the range of 100 to 500 inside the field of one pojo  how can i configure it ?

@ExtendWith(RandomBeansExtension.class)
public class AuxmoneyRequestValidationTest {

    @Random
    SomePojo  somePojo; // Inside pojo i have one int filed for which i want to have value in the range of 100 to 500

}

Documentation  has example of manually using EasyRandomParameters   but not sure how to use it with RandomBeansExtension. Is this feature available in extension ?

Added Support in junit-extensions  to provide Randomization parameters
https://github.com/glytching/junit-extensions/pull/15


feat: remove python dependency for a build script

I will other PR  later.
part of #132

The drawback of replacing python script by bash script is it will be working only on Linux computer (or MSYS2/MINGW64) I will really prefer a more universal way to do it by replacing those python script by C portable code built as native executable which can be executed on any computer.
To be discussed with @Baldanos

The script should work with WSL 2 (i need to test it) and it does work in macos.
We can also add Powershell if needed if the aim is to remove Python.
For cross-portability, I can provide Go, not C.

The script should work with WSL 2 (i need to test it) and it does work in macos. We can also add Powershell if needed if the aim is to remove Python.
For cross-portability, I can provide Go, not C.

I will prefer to avoid Go (which will add even more complexity/dependencies) the aim is to have something simple and multi platform at least to build the firmware.
At start we can live with bash/shell solution (it is always better than to have Python dependency for 2 scripts) to be discussed with @Baldanos

Nice idea, I had a quite similar approach in this branch here: https://github.com/Baldanos/hydrafw/tree/nopython
Replacing Python with Go or something else wouldn't make any improvement. However, as long as a fix is available and works on Windows and Linux, I think we should go for it

I prefer to avoid powershell specific windows stuff especially we can build it with MSYS2/MINGW64 like it is described in the https://github.com/hydrabus/hydrafw/wiki/how-to-build-flash-and-use-hydrafw-on-windows

Thanks for your contribution


How to I suggest new plugin to list?

I could not create a new one Pull Request then I create this Issue.
I create some plugins to CakePHP 3.
I want to add to this ist:
https://github.com/ribafs/cake-control-br
https://github.com/ribafs/twbs-cake-css
https://github.com/ribafs/cake-control
https://github.com/ribafs/control-default

I do not think those meet the standards yet.
They lack tests and coverage for example. Some are documented in non English.
Others are already in the list pretty much as current de-facto standard. It would need a good reason to add one of the same meaning here.

Thank you though for reaching out, and we can sure look into this again in the future.
Keep up the good work and let us know if you find any of those then useful for everyone else and not existing in the list yet in a similar way.


missing tags

it would be nice if you can tag your releases. it helps to rely on a specific snapshot of your lib.

You can fork it and add tags to your fork, with complete control over whether you even pull from upstream or not.  In any case the current state is pretty stable (no changes at all in over three years) and I generally add a branch or tag on these projects when I make backwards-incompatible changes.

if everything is stable why not simply add one tag 1.0.0 here?
forking everything just to add a custom tag doesn't sound like a best practice to me. git simple can't  clone a specific commit hash.
git clone --depth 1 --branch 0.28.1 https://github.com/shellspec/shellspec.git vendor/shellspec

vs
git clone https://github.com/bashup/dotenv.git vendor/dotenv
git -C vendor/dotenv reset --hard d71c9d786fe193f43f1cb57c6b4a152ebb01ba60


Fixes #1179 Deprecated SPDX license

Fixes #1179 Deprecated SPDX license (GFDL* and BSD-2-Clause-NetBSD)
Signed-off-by: Marc-Etienne Vargenau<EMAIL_ADDRESS>

Hi @vargenau, I made a bit of a change to this PR and regenerated the license list -- could you have a look through the result and confirm it is what you are expecting?
Thanks!

Thank you all for accepting and improving my patch.
I confirm it works as expected for me.
Can you also have a look at at pull request #1259 ? Thank you

Please check also pull request #1266 One more deprecated SPDX license: StandardML-NJ


Sidecar in VM fails to start due to "failed to warm certificate: failed to generate workload certificate: create certificate"

Bug description
I installed the Istio sidecar into a virtual machine, as specified in the documentation.
The virtual machine connected successfully for 1 day, and on the next day, the envoy log on the VM started filling up with the following errors:
2021-05-27T10:28:07.342344Z     warn    ca      ca request failed, starting attempt 1 in 91.589072ms
2021-05-27T10:28:07.434806Z     warn    ca      ca request failed, starting attempt 2 in 203.792343ms
2021-05-27T10:28:07.639557Z     warn    ca      ca request failed, starting attempt 3 in 364.729652ms
2021-05-27T10:28:08.005300Z     warn    ca      ca request failed, starting attempt 4 in 830.723933ms
2021-05-27T10:28:08.836493Z     warn    sds     failed to warm certificate: failed to generate workload certificate: create certificate: rpc error: code = Unavailable desc = connection closed

The VM was up and running the entire time, except that I periodically (for various tests) restarted the istio service on the VM using systemctl.
I don't know if this is relevant, but during this time period, the Kubernetes cluster running Istio was hibernated, and Istio was only restarted after the certificate in /etc/certs/cert-bundle.pem had already expired.
At this point restarting the istio service using systemctl on the VM did not fix the problem.
I was able to get the environment working only by manually deleting (as root) the /etc/certs/key.pem and /etc/certs/cert-chain.pem files. Once these files were deleted, the next time I restarted the istio service using systemctl everything connected correctly.
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ X] Security
[ ] Test and Release
[ X] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
The envoy process on the VM should successfully connect to the pilot-agent and retrieve certificates. If there is an existing cert-chain.pem  that is not valid, it should be ignored and the sidecar should behave as if this file did not exist.
Steps to reproduce the bug
Connect a virtual machine sidecar so that the virtual machine sidecar retrieves a certificate into /etc/certs/cert-chain.pem, and make Istio unavailable at the point in time when the sidecar certificate needs to be rotated, so that the sidecar certificate expires without being rotated.
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
$ istioctl version --remote
client version: 1.10.0
control plane version: 1.10.0
data plane version: 1.10.0 (7 proxies)

$ kubectl version --short
Client Version: v1.16.4
Server Version: v1.20.6

How was Istio installed?
As per the instructions in https://istio.io/latest/docs/setup/install/virtual-machine/ for a multi-network installation, with auto-registration  enabled.
Environment where the bug was observed (cloud vendor, OS, etc)
The Cloud Vendor is GCP, the Kubernetes cluster is a Gardener managed cluster.
The VM is a Debian VM running on GCP.
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

# dpkg --list istio-sidecar
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  istio-sidecar  1.10.0       amd64        Istio Sidecar

One more observation; I had to delete both the cert-chain.pem and key.pem files. It's not enough to just delete the cert-chain.pem - I think the code assumes that if a key.pem exists then there's a valid certificate, even if the cert-chain.pem file is gone.

currently if it meets a certificate exists but not valid we directly return an error. So we should check either the token or cert when rotating the cert

@liorokman this fix should resolve the issue

@williamaronli I am hitting this issue doing a v1.8.4 > v1.9.7 upgrade. Will #33813 get backported to 1.9?

it will be merged the the latest version of istio

I recently observed the same issue with latest builds where despite a valid istio-token being present on the VM, Istio would try to use the expired cert. I had to delete cert-chain.pem and key.pem for pilot-agent to refresh the certs.

In v1.15.x, I faced the same issue with v1.15.7 however downgrading to v1.15.6 resolved it.


"7" instead of "r"

Input code:
GUI r

Output code:
 Keyboard.press(KEY_LEFT_GUI);
 Keyboard.press("r");
 Keyboard.releaseAll();

Hi, when I compile this code, Windows runs GUI + 7 instead of GUI + r. (I have selected the correct keyboard)

Hi @hyWse, that's interesting, what is your keyboard locale and what did you selected ?

I have a german keyboard and i selected de_DE

That may be your hardware or your software..


examples/unmarked: fix markup

This layout was actually intentional. I was noting that the bullet list "belongs" to the line immediately above. Is this not acceptable markup syntax?

Poor description, sorry ;)
The change is based on the differing output markdown produces.
$ markdown ../examples/unmarked/marketing-requirements.md

User Interaction

The product will support English and German Languages

The product will count to a user-defined number sequentially

Compatibility Requirements

The product will be written in Python3

Functional Requirements

The product will greet the user as such:
* Hello!
    * (No Comma)
* World!

versus (this PR):
$ markdown ../examples/unmarked/marketing-requirements.md

User Interaction

The product will support English and German Languages

The product will count to a user-defined number sequentially

Compatibility Requirements

The product will be written in Python3

Functional Requirements

The product will greet the user as such:

Hello!

(No Comma)

World!

Environment:
$ markdown -v

This is Markdown, version 1.0.1.
Copyright 2004 John Gruber
http://daringfireball.net/projects/markdown/


8.0 beta support swift 3.0 ?

What is you question exactly?

Swift 3 support is still a work-in-progress: #608.

7.0.1 is the last version that is compatible with Xcode 7 / Swift 2.2. Moya 7.0.2 is compatible with Xcode 8 running Swift 2.3. #631

thank you

Does that answer your question, @12207480?

I found the 8.0-beta version is compatible with iOS  9.0 and Swift 3. but which version is compatible with iOS  8.0 and Swift 3 ?

@wangguangfeng unfortunately, the Swift 3 branch has dropped support for iOS 8. For the reasoning behind this, see #639


Support environment variables in the settings

Existing environment variables can be referenced by enclosing the name in percent characters (e.g. %PATH%).
Resurrects #9287 by @christapley.
Tests added and manually tested.
 Lets see how this works with layering. Can the defaults say (for example) TERM=windows-terminal, and then a profile say TERM=, to unset it? Or does setting it in a profile entirely replace the lower layer? If it's a per-variable layering, we could use that to vaguely do #11057.

Currently the concrete profile's environment completely replaces the one specified in defaults.
So if you've got:
"defaults": {
  "environment": {
    "Foo": "Bar"
  }
},
"list": [
  {
    "name": "PowerShell",
    "environment": {
      "Baz": "Qux"
    }
  }
]

Your PowerShell profile will get Baz=Qux and your cmd profile will get Foo=Bar.

Some discussion notes: We're all happy with it being non-layering for now. Maybe in the future we can re-evaluate that, but this is much better than what we had before.

Just FYI I should be able to take a look at this tomorrow (Friday).

This is very subtle (and I am only testing as of >5 hours ago, so please ignore if changed), but you can resurrect inherited environment variables depending on sort order.
I don't know if I think this is an issue worth fixing, but it is fun!
"environment": {
    "Z_NEW_PATH": "%PATH%", // gets new path!
    "PATH": "A",
    "0_OLD_PATH": "%PATH%", // gets old path!
}

This is seemingly how Windows resolves environment variables - though the order as far as I can tell is the order they're inserted into the registry.
Starting off with a system environment variable FOO=Foo and setting up the registry with REG_EXPAND_SZ user variables 0_FOO=%FOO%, FOO=NewFoo and Z_FOO=%FOO%, as below:

Leads to them being resolved as 0_FOO=Foo, FOO=NewFoo and Z_FOO=NewFoo in a conhost window, as below:

Worth pointing out though that if you create the FOO user variable in the system properties window, it's set up as a REG_SZ variable - so it does get resolved first, leading to 0_FOO and Z_FOO both resolving to NewFoo.
I guess we could put in a pre-processing step that inserts variables with values not containing percent characters into the environment map first. It would require iterating over the values in the map twice though and would complicate the logic somewhat - your call.

Oh, no, I'm totally happy with how it works today! I legitimately found it interesting :smile:

So glad to find that it's possible to use variables in settings.json but it doesn't seem to work with boolean settings which expect and true/false value.

😞

So glad to find that it's possible to use variables in settings.json

Just to clarify: it is possible to set environment variables in settings.json for the spawned process to inherit. It is not generally possible to use environment variables in settings.json :)

@DHowett Oh, that sucks. Just when I thought that I had finally found a way to easily manage my settings.json in git. Thanks for the info.


Feature Request: Perform benchmark within admin UI

I was using better-sqlite3 for benchmark on multiple cloud VPS and dedicated provider. They have pretty straightforward script to do that. It would be wonderful to have this within pocketbase admin UI to perform test by insert X number of records individually, bulk then read it individually and bulk.

I think this will clutter the UI unnecessary and for now remains out of the scope.
For benchmarks you can check https://github.com/pocketbase/benchmarks.


Theory: Regression algorithms

Ordinary least squares (linear regression)
Neural net

He also suggested to say something about L1 regularization. Social Scientists often find it useful to have small, explainable models and L1 helps with this.

Javier also mentioned that overfitting / out-of-sample prediction / bias-variance trade-off is an important and difficult to understand topic.
As a reference, here's a course on data science that Javier teaches: https://adav-course-2022.netlify.app we could borrow visuals from him.


app.rb: has_stop_event_for_latest_run? definition removed, but one use remains

In commit 7cf51e3329647370efffcd315087e37776c3e178 there's still code using this reference, and from my running spec/actions/app_stop_spec.rb there's no test exercising the generate_stop_event? method with the dangling reference.

Hi @ericpromislow,
Nice catch; it looks like this should've been removed with its calls during that commit. This issue raised underlying logical cruft from the era where billing events existed.  Specifically,  the method that calls has_stop_event_for_latest_run?, generate_stop_event? wasn't used anywhere - so we plan on deleting it.  But we also noticed the generate_start_event? method IS being used (once), outside the billing events context.
At any rate - thanks for bringing it up, we'll be addressing it soon.
Ben Watts

The fix for this will be included in the next cf-release.


Module update

Hello. Thanks for the awesome package :)
I 've been playing around to get RemoteREPL.jl to work well with Pluto.
The problem with Pluto is that everytime there is a change/evaluation in the notebook it creates a new Module.
So the client must explicitly change the module where the commands should be evaluated and that's tedious.
I tried to think of a non-intrusive way to solve this, but I couldn't wrap my head around it.
Instead here is an example of how RemoteREPL.jl could be modified.
Right now I have a global const Channel that the server can asynchronously modify with the putmodule! command.
Pluto side
You can see a Pluto notebook on gist
Basically it steps on the PlutoLinks.jl / PlutoHooks.jl to schedule an update of the module of RemoteREPL (with putmodule!) every second.
(I think this could be more clever but it's just a minimal working example)
Test
Run Pluto notebook and from the REPL do:
julia> using RemoteREPL, Sockets

julia> connect_repl(27755)
REPL mode remote_repl initialized. Press > to enter and backspace to exit.
"Prompt(\"julia@localhost:27755> \",...)"

julia@localhost:27755> @__MODULE__ # module changes automatically
Main.var"workspace#517"

julia@localhost:27755> @__MODULE__ # module changes automatically
Main.var"workspace#518"

julia> @remote(anewvar)
1

The RemoteREPL now will always be on the last update of the Pluto notebook.
This is just a draft.
I myself am not very happy with the restriction to have only one global Channel,
but before I move on I would like to know what do you think.
So basically two questions:

Are you at all interested in any changes in this direction ?
If yes, do you have any preferences for the implementation ? I will be happy to take them into consideration.

use the on_client_connect hook in serve_repl to grab a handle to the ServerSideSession each time a client connects

I guess to do this we need to wrap all the serve_repl inside a Channel similar to this dummy code
mutable struct MySession
    @atomic name::String
end

function setsessionname!(ses::MySession, newname)
    @atomic ses.name = newname
end

function dummy_serve(on_client_connect=nothing)
    Channel{MySession}(1) do ch
        mysession = MySession("Main")
        if !isnothing(on_client_connect)
            on_client_connect(mysession)
            put!(ch, mysession)
        end
        i = 0
        while i < 5
            sleep(2.0)
            @info "evaluating commands in $(mysession.name)"
            i += 1
        end
    end
end

and then the server (Pluto) will call it like:
julia> ses = take!(dummy_serve(x -> setsessionname!(x, "module#1")));
[ Info: evaluating commands in module#1
[ Info: evaluating commands in module#1
[ Info: evaluating commands in module#1

julia> setsessionname!(ses, "module#2");
[ Info: evaluating commands in module#2
[ Info: evaluating commands in module#2

But then what happens in on_client_connect is irrelative to returning an instance of ServerSideSession, and we could return the session eitherway.
Also what about mutexing ?
returning an instance of ServerSideSession that can be modified at any time might lead to corruption.
So probably the modification of session.in_module should be somewhat inside an @atomic or similar., which in my opinion should be provided from RemoteREPL.jl. Something like the setsessionname! above.
If we would return a Channel{Module}(1) then this could be handled this transparently, together with the closing:

The only tricky thing is that there's no on_client_disconnect hook in RemoteREPL so the pluto-side hooks won't know when to be detached from the session, even after the session is disconnected.

Maybe we should add a field to ServerSideSession ... like custom_session::Any or something, which can be set by on_client_connect and just call close() on it as part of close(::ServerSideSession).

Now that I think about it, the serve_repl caller can just check the session.socket to see if it's still open. That should make it clear whether it can continue updating the module or not. What else would you use this custom_session::Any for ?

I guess to do this we need to wrap all the serve_repl inside a Channel similar to this dummy code

This is one way to provide the sessions back to the caller. But I don't particularly love firing off that independent Task in Channel{MySession}(1) do ch.  (Actually I wish that Channel constructor didn't exist in Base!  It hides the concurrency in a way which I think is particularly confusing :sweat_smile:)
I'd probably be inclined to have the user pass the channel instead. (Ugh, if only Julia had Go's select this would make all this stuff so much neater, and make clean cancellation much easier to do here.)

So probably the modification of session.in_module should be somewhat inside an @atomic or similar., which in my opinion should be provided from RemoteREPL.jl.

Yep this is a good point I think. "Unlikely" to cause a real problem, but data races are evil :-D
Actually a nicely appropriate way to fix this would be to communicate with ServerSideSession via the same message protocol that's used on the socket, but directly via request_chan in serve_repl_session rather than the socket. This is how it works from the client side and is async/thread safe... so why not the server side too?
I think this is the right way forward, it's just a little tricky because right now the code assumes that request_chan and response_chan are for a single remote client. So the response to the :in_module message will go to the remote client, not back to the pluto server. And that will break some assumptions in the protocol.  To fix this, we'd have to be able to open multiple connections to the ServerSideSession.  Which is doable and probably useful (multiple remote clients sharing a session - ipython can do this IIUC).
But if all that's too big of a rearrangement to contemplate, using an @atomic would probably be fine for now.

serve_repl caller can just check the session.socket to see if it's still open

This kind of polling generally leads to awkward code because it tends to look like
while true
    if !isopen(session.socket)
        break
    end
    do_something(session.socket)  # Is session.socket open here?
end

The awkwardness here is that session.socket can be closed asynchronously at any time so do_something() can fail. So I just try to avoid it where possible and use channels instead.

What else would you use this custom_session::Any for ?

Good question. Possibly it would be a place to stash any other session <--> pluto mappings you need?
But maybe that's not necessary and introduces extra coupling that we don't really need.
If the user can get hold of the ServerSideSession as it's generated in a nice async-safe way (via a channel I guess), and can communicate with those ServerSideSessions via the existing RemoteREPL message protocol, perhaps that covers everything?
In that case, they can wrap whatever logic they like around ServerSideSession, rather than having ServerSideSession wrap the logic inside itself. Seems like less coupling which is a good thing.

@c42f Sorry for the delay. I had some time and I built something on the lines that you've suggested. Since it's rather different implementation I close this PR and I point you to #55 !

Hey! It's been a while :) Could you remind me of the use case? Is this work for a RemoteREPL server in the Pluto notebook, and a client in a Julia REPL? So in your notebook you define x = 123, and then in the terminal you can remotely run x+x and get 246?

hey hey. yes, the current PR is https://github.com/JuliaWeb/RemoteREPL.jl/pull/55
We had to implement some further things but now it seems that some tests are failing.
I will look into that when I find some time.
The Pluto notebook looks like this https://gist.github.com/filchristou/80ab232ca1be67fb59de689913f41785
It's very simple: it basically sends the newest Module to the client every 1 second.
No changes are needed on the Pluto side.
But it would be convenient if you know of an event-based way of sending the newest Module upon a notebook change/evaluation, instead of polling it every a pre-defined time interval.


[firebase_dynamic_links] Keep obtaining same information from the first link resolved after installation

I open another issue similar to #692, which seems to be closed
Describe the bug
Handling dynamic link in WidgetsBindingObserver's didChangeAppLifecycleState method always handle initial used dynamic link address on iOS
To Reproduce
Steps to reproduce the behavior:

First, tap first dynamic link in memo app on iPhone(XS, iOS13.3) after initial installation
It works as expected
Then tap another link
Still obtaining informations from first link

Expected behavior
Second dynamic link tap must resolve different information from first one
Additional context
This is my implementation of handling and generating of dynamic link
//Link generation code
final DynamicLinkParameters parameters = DynamicLinkParameters(
    uriPrefix: "<MY-FIREBASE-DYNAMIC-LINK-PREFIX>",
    link: Uri.parse("<MY-FIREBASE-DYNAMIC-LINK-PREFIX>/product/${widget.id}")
  );
  final Uri dynamicUrl = (await parameters.buildShortLink()).shortUrl;
  print(dynamicUrl);
  Share.share(dynamicUrl.toString());
//Link resolve code
class CustomWidgetState extends State<CustomWidget> with WidgetsBindingObserver{
  Timer _timerLink;
  //...
  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addObserver(this);
  }
  @override
  void didChangeAppLifecycleState(AppLifecycleState state) async{
    if (state == AppLifecycleState.resumed){
      _timerLink = new Timer(const Duration(milliseconds: 850), () {
        retrieveDynamicLink(context);
      });
    }
  }
}
//...
void retrieveDynamicLink(BuildContext context) async {
  final PendingDynamicLinkData data = await FirebaseDynamicLinks.instance.getInitialLink();
  final Uri deepLink = data?.link;
    print(deepLink.pathSegments);
  }
}

This is result from flutter doctor command:
$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.12.13+hotfix.5, on Mac OS X 10.15.2 19C57, locale en-KR)
[!] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    ✗ Android license status unknown.
      Try re-installing or updating your Android SDK Manager.
      See https://developer.android.com/studio/#downloads or visit https://flutter.dev/setup/#android-setup for detailed instructions.
[✓] Xcode - develop for iOS and macOS (Xcode 11.3.1)
[✓] Android Studio (version 3.5)
[✓] VS Code (version 1.41.1)
[!] Connected device
    ! No devices available

! Doctor found issues in 2 categories.

My detailed flutter version is:
* stable 27321ebba v1.12.13+hotfix.5 cherry-picks (#46726)

And this is my flutter pubspec.yml except app's name , description, version
As you see in my podfile.lock, I'm using 0.5.0+9 version of firebase_dynamic_links
module:
  androidX: true
environment:
  sdk: ^2.4.0
  flutter: ^1.7.0

dependencies:
  flutter:
    sdk: flutter
  http: ^0.12.0+2
  share: ^0.6.3+5
  flutter_slidable: "^0.5.4"
  json_serializable: ^3.2.2
  firebase_core: ^0.4.0+9
  firebase_analytics: ^5.0.2
  graphql_flutter: ^2.1.1-beta.4
  cupertino_icons: ^0.1.2
  iamport_flutter: ^0.9.3
  intl: ^0.16.0
  provider: ^3.0.0+1
  carousel_slider: ^1.3.0
  flutter_kakao_login: "^0.5.0"
  flutter_secure_storage: ^3.3.1+1
  firebase_dynamic_links: ^0.5.0+9
  jaguar_jwt: ^2.1.6
  autocomplete_textfield: ^1.6.4
  native_widgets: ^1.3.5
  flutter_typeahead: ^1.7.0
  badges: ^1.1.0
  tuple: ^1.0.3
  firebase_messaging: ^5.1.6
  flutter_datetime_picker: ^1.2.8
  loadmore: ^1.0.4
  validators: ^2.0.0+1

dev_dependencies:
  pedantic: ^1.8.0

Finally, this is my Podfile.lock(checksum removed)
PODS:
  - connectivity (0.0.1):
    - Flutter
    - Reachability
  - Firebase/Analytics (6.15.0):
    - Firebase/Core
  - Firebase/Core (6.15.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 6.2.1)
  - Firebase/CoreOnly (6.15.0):
    - FirebaseCore (= 6.6.0)
  - Firebase/DynamicLinks (6.15.0):
    - Firebase/CoreOnly
    - FirebaseDynamicLinks (~> 4.0.6)
  - Firebase/Messaging (6.15.0):
    - Firebase/CoreOnly
    - FirebaseMessaging (~> 4.2.0)
  - firebase_analytics (0.0.1):
    - Firebase/Analytics (~> 6.0)
    - Firebase/Core
    - Flutter
  - firebase_core (0.0.1):
    - Firebase/Core
    - Flutter
  - firebase_dynamic_links (0.1.0):
    - Firebase/DynamicLinks
    - Flutter
  - firebase_messaging (0.0.1):
    - Firebase/Core
    - Firebase/Messaging
    - Flutter
  - FirebaseAnalytics (6.2.1):
    - FirebaseCore (~> 6.6)
    - FirebaseInstanceID (~> 4.3)
    - GoogleAppMeasurement (= 6.2.1)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (= 0.3.9011)
  - FirebaseAnalyticsInterop (1.5.0)
  - FirebaseCore (6.6.0):
    - FirebaseCoreDiagnostics (~> 1.2)
    - FirebaseCoreDiagnosticsInterop (~> 1.2)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/Logger (~> 6.5)
  - FirebaseCoreDiagnostics (1.2.0):
    - FirebaseCoreDiagnosticsInterop (~> 1.2)
    - GoogleDataTransportCCTSupport (~> 1.3)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/Logger (~> 6.5)
    - nanopb (~> 0.3.901)
  - FirebaseCoreDiagnosticsInterop (1.2.0)
  - FirebaseDynamicLinks (4.0.6):
    - FirebaseAnalyticsInterop (~> 1.3)
    - FirebaseCore (~> 6.2)
  - FirebaseInstallations (1.1.0):
    - FirebaseCore (~> 6.6)
    - GoogleUtilities/UserDefaults (~> 6.5)
    - PromisesObjC (~> 1.2)
  - FirebaseInstanceID (4.3.0):
    - FirebaseCore (~> 6.6)
    - FirebaseInstallations (~> 1.0)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/UserDefaults (~> 6.5)
  - FirebaseMessaging (4.2.0):
    - FirebaseAnalyticsInterop (~> 1.5)
    - FirebaseCore (~> 6.6)
    - FirebaseInstanceID (~> 4.3)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.5)
    - GoogleUtilities/Environment (~> 6.5)
    - GoogleUtilities/Reachability (~> 6.5)
    - GoogleUtilities/UserDefaults (~> 6.5)
    - Protobuf (>= 3.9.2, ~> 3.9)
  - Flutter (1.0.0)
  - flutter_kakao_login (0.0.8):
    - Flutter
    - KakaoOpenSDK (~> 1.17.2)
  - flutter_keyboard_visibility (0.7.0):
    - Flutter
  - flutter_secure_storage (3.3.1):
    - Flutter
  - flutter_webview_plugin (0.0.1):
    - Flutter
  - GoogleAppMeasurement (6.2.1):
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (= 0.3.9011)
  - GoogleDataTransport (3.3.0)
  - GoogleDataTransportCCTSupport (1.3.0):
    - GoogleDataTransport (~> 3.3)
    - nanopb (~> 0.3.901)
  - GoogleUtilities/AppDelegateSwizzler (6.5.0):
    - GoogleUtilities/Environment
    - GoogleUtilities/Logger
    - GoogleUtilities/Network
  - GoogleUtilities/Environment (6.5.0)
  - GoogleUtilities/Logger (6.5.0):
    - GoogleUtilities/Environment
  - GoogleUtilities/MethodSwizzler (6.5.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/Network (6.5.0):
    - GoogleUtilities/Logger
    - "GoogleUtilities/NSData+zlib"
    - GoogleUtilities/Reachability
  - "GoogleUtilities/NSData+zlib (6.5.0)"
  - GoogleUtilities/Reachability (6.5.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/UserDefaults (6.5.0):
    - GoogleUtilities/Logger
  - iamport_flutter (0.0.1):
    - Flutter
  - KakaoOpenSDK (1.17.2):
    - KakaoOpenSDK/KakaoCommon (= 1.17.2)
    - KakaoOpenSDK/KakaoLink (= 1.17.2)
    - KakaoOpenSDK/KakaoMessageTemplate (= 1.17.2)
    - KakaoOpenSDK/KakaoNavi (= 1.17.2)
    - KakaoOpenSDK/KakaoOpenSDK (= 1.17.2)
  - KakaoOpenSDK/KakaoCommon (1.17.2)
  - KakaoOpenSDK/KakaoLink (1.17.2):
    - KakaoOpenSDK/KakaoCommon
  - KakaoOpenSDK/KakaoMessageTemplate (1.17.2)
  - KakaoOpenSDK/KakaoNavi (1.17.2):
    - KakaoOpenSDK/KakaoCommon
  - KakaoOpenSDK/KakaoOpenSDK (1.17.2)
  - nanopb (0.3.9011):
    - nanopb/decode (= 0.3.9011)
    - nanopb/encode (= 0.3.9011)
  - nanopb/decode (0.3.9011)
  - nanopb/encode (0.3.9011)
  - path_provider (0.0.1):
    - Flutter
  - PromisesObjC (1.2.8)
  - Protobuf (3.11.2)
  - Reachability (3.2)
  - share (0.5.2):
    - Flutter
  - uni_links (0.0.1):
    - Flutter
  - url_launcher (0.0.1):
    - Flutter

DEPENDENCIES:
  - connectivity (from `.symlinks/plugins/connectivity/ios`)
  - firebase_analytics (from `.symlinks/plugins/firebase_analytics/ios`)
  - firebase_core (from `.symlinks/plugins/firebase_core/ios`)
  - firebase_dynamic_links (from `.symlinks/plugins/firebase_dynamic_links/ios`)
  - firebase_messaging (from `.symlinks/plugins/firebase_messaging/ios`)
  - Flutter (from `Flutter`)
  - flutter_kakao_login (from `.symlinks/plugins/flutter_kakao_login/ios`)
  - flutter_keyboard_visibility (from `.symlinks/plugins/flutter_keyboard_visibility/ios`)
  - flutter_secure_storage (from `.symlinks/plugins/flutter_secure_storage/ios`)
  - flutter_webview_plugin (from `.symlinks/plugins/flutter_webview_plugin/ios`)
  - iamport_flutter (from `.symlinks/plugins/iamport_flutter/ios`)
  - path_provider (from `.symlinks/plugins/path_provider/ios`)
  - share (from `.symlinks/plugins/share/ios`)
  - uni_links (from `.symlinks/plugins/uni_links/ios`)
  - url_launcher (from `.symlinks/plugins/url_launcher/ios`)

SPEC REPOS:
  trunk:
    - Firebase
    - FirebaseAnalytics
    - FirebaseAnalyticsInterop
    - FirebaseCore
    - FirebaseCoreDiagnostics
    - FirebaseCoreDiagnosticsInterop
    - FirebaseDynamicLinks
    - FirebaseInstallations
    - FirebaseInstanceID
    - FirebaseMessaging
    - GoogleAppMeasurement
    - GoogleDataTransport
    - GoogleDataTransportCCTSupport
    - GoogleUtilities
    - KakaoOpenSDK
    - nanopb
    - PromisesObjC
    - Protobuf
    - Reachability

EXTERNAL SOURCES:
  connectivity:
    :path: ".symlinks/plugins/connectivity/ios"
  firebase_analytics:
    :path: ".symlinks/plugins/firebase_analytics/ios"
  firebase_core:
    :path: ".symlinks/plugins/firebase_core/ios"
  firebase_dynamic_links:
    :path: ".symlinks/plugins/firebase_dynamic_links/ios"
  firebase_messaging:
    :path: ".symlinks/plugins/firebase_messaging/ios"
  Flutter:
    :path: Flutter
  flutter_kakao_login:
    :path: ".symlinks/plugins/flutter_kakao_login/ios"
  flutter_keyboard_visibility:
    :path: ".symlinks/plugins/flutter_keyboard_visibility/ios"
  flutter_secure_storage:
    :path: ".symlinks/plugins/flutter_secure_storage/ios"
  flutter_webview_plugin:
    :path: ".symlinks/plugins/flutter_webview_plugin/ios"
  iamport_flutter:
    :path: ".symlinks/plugins/iamport_flutter/ios"
  path_provider:
    :path: ".symlinks/plugins/path_provider/ios"
  share:
    :path: ".symlinks/plugins/share/ios"
  uni_links:
    :path: ".symlinks/plugins/uni_links/ios"
  url_launcher:
    :path: ".symlinks/plugins/url_launcher/ios"

SPEC CHECKSUMS:
  //Remove useless information...

PODFILE CHECKSUM: //Remove useless information...

COCOAPODS: 1.8.4

As far as I'm aware this was fixed a while back so I'm going to close in favour of trying the latest plugin versions now and that if it's still a problem then could you raise a new up to date GitHub issue (as this one is so out of date).


Use "main" as main branch, not "master"

I'm going to switch the main branch name from master to main. I'm opening this PR to notify anybody who collaborates and might need to pull down main locally.
If tests work correctly and pass, I'll merge, switch GitHub's branch settings, and delete master.

Codecov Report

Merging #250 (1834605) into master (07e7637) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #250   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            9         9
  Lines          227       227
  Branches        46        46
=========================================
  Hits           227       227

Continue to review full report at Codecov.

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


CommonJS version?

I included it in my project and it can't be built anymore:
Error [ERR_REQUIRE_ESM]: require() of ES Module<EMAIL_ADDRESS>from /.../src/commands/play.ts not supported.

Could you please support commonjs as well?

I don't plan on re-adding commonjs support.
Try importing this ESM module like this:
const {default: createVlc} = await import('@richienb/vlc');

Cool, I'll try!

No, I'm afraid it doesn't work:
export default async function (file: string) {
  try {
    const { default: createVlc } = await import("@richienb/vlc"); // <--- fails here
    const vlc = await createVlc();
  } catch (e) {
    console.log(e);
  }
}

Error:
Error [ERR_REQUIRE_ESM]: require() of ES Module<EMAIL_ADDRESS>from /.../src/commands/play.ts not supported.
Instead change the require of index.js in /.../src/commands/play.ts to a dynamic import() which is available in all CommonJS modules.
    at Object.require.extensions.<computed> [as .js] (/.../node_modules/ts-node/dist/index.js:842:20)
    at /.../src/commands/play.ts:30:88
    at async default_1 (/.../src/commands/play.ts:30:40)
    at async Object.handler (/.../src/app.ts:92:13) {
  code: 'ERR_REQUIRE_ESM'
}

Any ideas?

This might have something to do with your bundler. Check the compiled JavaScript.


atomic-reactor fails on Fedora 22 because of python-requests version

The version of python-requests that is in Fedora 22 is too new.
I built an rpm from my git checkout with tito build --test --builder mock --arg mock=fedora-22-x86_64 --rpm and then installed the resulting rpm. I get the following error:
# atomic-reactor create-build-image --reactor-tarball-path /usr/share/atomic-reactor/atomic-reactor.tar.gz /usr/share/atomic-reactor/images/dockerhost-builder/ buildroot
Traceback (most recent call last):
  File "/usr/bin/atomic-reactor", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 3011, in <module>
    parse_requirements(__requires__), Environment()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 626, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: requests>=2.2.1,<2.5.0

# rpm -q python-requests
python-requests-2.7.0-1.fc22.noarch

I brought this up with docker-py upstream and they said they want to pin version of dependent libs because they experienced breakage in past. Since I'm maintainer of docker-py in Fedora, I can patch it to accept any new version of python-requests.

Sounds good, thanks. :+1:

Can you open up bugzilla please?

There is no atomic-reactor component in Fedora bugzilla, what should I file this under?

https://bugzilla.redhat.com/enter_bug.cgi?component=python-docker-py&product=Fedora

https://bugzilla.redhat.com/show_bug.cgi?id=1251287

I left a comment on the bugzilla and also at https://github.com/projectatomic/atomic-reactor/issues/225#issuecomment-128618542 about what I believe is the correct solution.

atomic-reactor now works on F22, closing


Fix Comparing String example in JAVA

-Use new to force create distinct string object, so can have good example in compare
-Fix syntax error

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

It turns out there is already a section earlier in the guide that uses new to create a String object and explains the difference between that approach vs uses a string literal.
So this change is unnecessary at this point.
Happy Coding!

It turns out there is already a section earlier in the guide that uses new to create a String object and explains the difference between that approach vs uses a string literal.
So this change is unnecessary at this point.
Happy Coding!

Ya, there are examples explain earlier, but in the Comparing strings section, the first given example is not correct with the explanation below which i think may cause confusion
Original:

String str = "Hello world";
String str2 = "Hello world";

System.out.println(str == str2); // This prints false
System.out.println(str.equals(str2)); // This prints true

The first comparison is false because "==" looks at the references and they aren't the same.

But the actual output should print true for str == str2 :

String str = "Hello world";
String str2 = "Hello world";

System.out.println(str == str2); // This actually should prints true

So, the statement below is not correct

The first comparison is false because "==" looks at the references and they aren't the same.


Semantic Point Cloud's input for inserting into mesh

Hi can I check that for the Kimera Semantics, we just need Depth (from camera) and 2D semantic image and pose from some SLAM backend?
The input semantic image is the actual colored image and not the label matrix? And similarly there is no need to provide the confidence matrix for the semantic image?
We are assuming that the semantic module is very robust in such case?
Thank you

Hey @AnhTuDo1998,
I am neither a pro or the maintainer of this project, but let me share what I understood:
Here your input semantic image should contain the only the highest probability label, more precisely the color represented by the index of that label. In runtime the algorithm translated the color code to the label index, accepts every measurement as if that would be the ground truth label and aggregates label predicitons for every individual voxel with a measurement frequency. The corresponding snippet can be found here.
With this a label confidence matrix can be calculated and iteratively updated with latest measurements integrated into the measurement  frequency vector and multiplied with the previous likelihood.
Hope this could help and I was right with my understanding.
Bests,
David

Thanks @RozDavid just what I am looking for. Closing thread since question answered


Remove g+ links from contributors

What's changed, or what was fixed?

Remove G+ links from contributors templates
Remove G+ links from contributors.yaml

Target Live Date: ASAP

[X] I have run npm test locally and all tests pass.
[X] I have added the appropriate type-something label.
[X] I've staged the site and manually verified that my content displays correctly.

:+1:

:tada: This has been pushed live to https://developers.google.com/web/


Adding missing DLLogger requirement for the paper reproducibility example

Goals :soccer:

Adds the missing NVIDIA DLLogger requirement for the paper reproducibility demo

Wouldn't this be better as an optional dependency?

Wouldn't this be better as an optional dependency?

Isn't this requirements.txt file already optional? (like it'll only be installed if you go pip install -r examples/t4rec_paper_experiments/requirements.txt and isn't run as part of the main transformers4rec install).
It also doesn't look like dllogger is optional to run the scripts here : https://github.com/NVIDIA-Merlin/Transformers4Rec/blob/5b7e9be2d98e03c9c8808e79eff48ddf9e807ed6/examples/t4rec_paper_experiments/t4r_paper_repro/exp_outputs.py#L21-L23

Indeed @benfred. This requirement is only necessary to run the paper reproducibility example, that is why it is in a separate requirements.txt. To make this dependency optional, we would have to change the code to only log using DLLogger when it is installed.
P.s. For our internal experiments at NVIDIA, DLLogger is always required because it saves the final metrics in the expected format by AutoBench, our manager of distributed jobs. DLLogger it is an open-source project  and is also required by NVIDIA Deep Learning examples


When one of my docker container fail I get the alert as much time as my number of containers

here is my prometheus.yml
global:
  scrape_interval: 15s # By default, scrape targets every 15 seconds.
  evaluation_interval: 15s # By default, scrape targets every 15 seconds.
  external_labels:
    monitor: 'twitter-apps-monitor'

rule_files:
  - '/etc/prometheus/alert.rules'

scrape_configs:
    - job_name: 'streamapp'
      scrape_interval: 5s
      scrape_timeout: 10s
      target_groups:
        - targets: ['streamapp-container:3002']
          labels:
            job: 'streamapp'
    - job_name: 'dashboardapp'
      scrape_interval: 5s
      scrape_timeout: 10s
      target_groups:
        - targets: ['dashboardapp-container:3000']
          labels:
            job: 'dashboardapp'
    - job_name: 'analyzeapp'
      scrape_interval: 5s
      scrape_timeout: 10s
      target_groups:
        - targets: ['analyzeapp-container:3001']
          labels:
            job: 'analyzeapp'

All the containers are sinatra apps. I have setup '/metrics' routes on each service to have alertmanager behave correctly.
If I do not provide a '/metrics' route my sinatra app container then the container is detected has dead and the alert is sent immediately.
So ones the route is set, everything looks good but when I stop one container (let say dashboardapp). I get all 3 alerts in red and received 3 msg via slack. The 3 messages are saying that dashboardapp is down.
Am I doing things right?
I found it strange to have to provide a '/metrics' route and the fact that I received 3 times the same message is strange.
I am using cadvisor for the prometheus analytics.

Could you share your alert.rules?
"/metrics" is the standard endpoint for Prometheus to scrape metrics from
an instrumented job - could you explain what part of that seems strange to
you?
What do you mean, you are using cadvisor for "prometheus analytics", when
you say the scraped targets are all sinatra apps? Could it be that you
meant to scrape cAdvisor, but you are accidentally scraping the containers
directly (which would be correct if you instrumented them correctly with
Prometheus metrics)?
By the way, you don't need the "labels: job: '...'" sections in your
config, since the job label will default to what you set in the "job_name"
already, which has the same value in your config.
On Tue, Oct 27, 2015 at 10:22 PM, casertap<EMAIL_ADDRESS>wrote:

here is my prometheus.yml
scrape_configs:
- job_name: 'streamapp'
scrape_interval: 5s
scrape_timeout: 10s
target_groups:
- targets: ['streamapp-container:3002']
labels:
job: 'streamapp'
- job_name: 'dashboardapp'
scrape_interval: 5s
scrape_timeout: 10s
target_groups:
- targets: ['dashboardapp-container:3000']
labels:
job: 'dashboardapp'
- job_name: 'analyzeapp'
scrape_interval: 5s
scrape_timeout: 10s
target_groups:
- targets: ['analyzeapp-container:3001']
labels:
job: 'analyzeapp'
All the containers are sinatra apps. I have setup '/metrics' routes on
each service to have alertmanager behave correctly.
If I do not provide a '/metrics' route my container is detected has dead.
Everything looks ok but when I stop one container (let say dashboardapp).
I get all 3 alerts in red and received 3 msg via slack. The 3 messages are
saying that dashboardapp is down.
Am I doing things right?
I found it strange to have to provide a '/metrics' route and the fact that
I received 3 times the same message is strange.
—
Reply to this email directly or view it on GitHub
https://github.com/prometheus/alertmanager/issues/139.

I give you my alert.rules
### alert.rules ###

# Alert for any instance that is unreachable for >5 minutes.
ALERT streamapp
    IF up == 0
    FOR 10s
    SUMMARY "Instance {{$labels.instance}} down"
    DESCRIPTION "{{$labels.instance}} of job {{$labels.job}} has been down for more than 10s"

ALERT dashboardapp
    IF up == 0
    FOR 10s
    SUMMARY "Instance {{$labels.instance}} down"
    DESCRIPTION "{{$labels.instance}} of job {{$labels.job}} has been down for more than 10s"

ALERT analyzeapp
    IF up == 0
    FOR 10s
    SUMMARY "Instance {{$labels.instance}} down"
    DESCRIPTION "{{$labels.instance}} of job {{$labels.job}} has been down for more than 10s"

And here is my docker-compose (so you can better understand my architecture
datadb:
  image: busybox
  container_name: datadb
  volumes:
    - /data/db

mongo:
  image: mongo
  container_name: mongo
  volumes_from:
    - datadb
  ports:
    - 27017:27017

streamapp:
  build: streamapp/
  container_name: streamapp-container
  links:
    - mongo
  ports:
    - 3002:3002
  expose:
    - 3002
  env_file:
    - './.env'

dashboardapp:
  build: dashboardapp/
  container_name: dashboardapp-container
  links:
    - mongo
  ports:
    - 3000:3000
  expose:
    - 3000
  env_file:
    - './.env'

analyzeapp:
  build: analyzeapp/
  container_name: analyzeapp-container
  ports:
    - 3001:3001
  expose:
    - 3001
  links:
    - mongo
  env_file:
    - './.env'

cadvisor:
  image: google/cadvisor
  container_name: cadvisor
  ports:
    - "8080:8080"
  volumes:
    - "/:/rootfs:ro"
    - "/var/run:/var/run:rw"
    - "/sys:/sys:ro"
    - "/var/lib/docker/:/var/lib/docker:ro"

promalertmgr:
  build: promalertmgr/
  container_name: promalertmgr
  ports:
    - "9093:9093"
  expose:
    - "9093"
  command: "-config.file=/alertmanager.conf"
  env_file:
    - './.env'

prometheus:
  build: prometheus/
  container_name: prometheus
  links:
    - cadvisor
    - promalertmgr
    - streamapp
    - dashboardapp
    - analyzeapp
    - mongo
  ports:
    - "9090:9090"
  command: "-config.file=/etc/prometheus/prometheus.yml -alertmanager.url=http://<IP_ADDRESS>:9093"
  env_file:
    - './.env'

Prometheus works fine when I connect it to cadvisor:
scrape_configs:
    - job_name: 'cadvisor'
      scrape_interval: 5s
      scrape_timeout: 10s
      target_groups:
        - targets: ['cadvisor:8080']

But what I want is monitor my streamapp, dashboardapp, and analyzeapp container and receive an alert when one of them is down.
If I connect prometheus to cadvisor like I did and add the 3 rules above. Those rules stay green even if I stop the dashboard container.
If I add "/metrics" end point to my apps and connect prometheus to each app while I did in my first post. If I stop one container I get alerted. But the metric do not work because I did not connect cadvisor.
Thanks for your answer.
I hope to hear from you soon.

Ok so what I needed was something like this
ALERT streamapp
    IF absent(container_last_seen{name="streamapp-container"})
    SUMMARY "Instance {{$labels.instance}} down"
    DESCRIPTION "{{$labels.instance}} of job {{$labels.job}} has been down for more than 10s"

I only need to connect prometheus to cadvisor and than use a cadvisor metric to detect if the container is down.
It takes a lot of time to detect the app is down but still, it is working.
Thanks.

Now that I have updated the docker image it does not work anymore.
I need to do it like this:
ALERT wpprog
    IF absent(((time() - container_last_seen{name="wpprog"}) < 5)) FOR 15s
    SUMMARY "Instance is down"
    DESCRIPTION "You should do something"

This is working fine.

This seems to be resolved.

hi castertap
can u post the dockerfile for above prometheus version


Allow to automatically fetch binaries

Instead of building vega,wallet and data-node binaries locally, capsule could fetch them based on version number. This will significantly simplify the start up flow.

@karlem - can you confirm if this has been implemented in capsule?


Remote 'kernelCommandListener' as it really listens to notebooks

For #10152
Another step in the removal of the 'notebook' references in kernels. The KernelCommandListener class was really listening to commands on notebooks so I just moved it.

@DonJayamanne  did you have any more feedback?

Not sure why i didn't approve, sorry


[Question] ImportError:transformers.models.llama.modeling_llama

Describe the issue
This is my error message:
(llava) zdw@ai-gpu-server149:~/LLaVA$ python test.py
Traceback (most recent call last):
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/utils/import_utils.py", line 1364, in _get_module
    return importlib.import_module("." + module_name, self.__name__)
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/models/llama/modeling_llama.py", line 55, in <module>
    from flash_attn import flash_attn_func, flash_attn_varlen_func
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/flash_attn/__init__.py", line 3, in <module>
    from flash_attn.flash_attn_interface import (
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/flash_attn/flash_attn_interface.py", line 10, in <module>
    import flash_attn_2_cuda as flash_attn_cuda
ImportError: /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/flash_attn_2_cuda.cpython-310-x86_64-linux-gnu.so: undefined symbol: _ZN2at4_ops15sum_IntList_out4callERKNS_6TensorEN3c1016OptionalArrayRefIlEEbSt8optionalINS5_10ScalarTypeEERS2_

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/zdw/LLaVA/test.py", line 1, in <module>
    from llava.model.builder import load_pretrained_model
  File "/home/zdw/LLaVA/llava/__init__.py", line 1, in <module>
    from .model import LlavaLlamaForCausalLM
  File "/home/zdw/LLaVA/llava/model/__init__.py", line 2, in <module>
    from .language_model.llava_llama import LlavaLlamaForCausalLM, LlavaConfig
  File "/home/zdw/LLaVA/llava/model/language_model/llava_llama.py", line 21, in <module>
    from transformers import AutoConfig, AutoModelForCausalLM, \
  File "<frozen importlib._bootstrap>", line 1075, in _handle_fromlist
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/utils/import_utils.py", line 1355, in __getattr__
    value = getattr(module, name)
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/utils/import_utils.py", line 1354, in __getattr__
    module = self._get_module(self._class_to_module[name])
  File "/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/transformers/utils/import_utils.py", line 1366, in _get_module
    raise RuntimeError(
RuntimeError: Failed to import transformers.models.llama.modeling_llama because of the following error (look up to see its traceback):
/data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages/flash_attn_2_cuda.cpython-310-x86_64-linux-gnu.so: undefined symbol: _ZN2at4_ops15sum_IntList_out4callERKNS_6TensorEN3c1016OptionalArrayRefIlEEbSt8optionalINS5_10ScalarTypeEERS2_
(llava) zdw@ai-gpu-server149:~/LLaVA$

I tried installing but without any problems:
(llava) zdw@ai-gpu-server149:~/LLaVA$ pip install flash-attn --no-build-isolation --no-cache-dir
Looking in indexes: http://registry.xtrfr.cn/repository/pypi-test/simple/
Requirement already satisfied: flash-attn in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (2.5.6)
Requirement already satisfied: torch in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from flash-attn) (2.1.2)
Requirement already satisfied: einops in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from flash-attn) (0.6.1)
Requirement already satisfied: packaging in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from flash-attn) (24.0)
Requirement already satisfied: ninja in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from flash-attn) (<IP_ADDRESS>)
Requirement already satisfied: filelock in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (3.13.3)
Requirement already satisfied: typing-extensions in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (4.10.0)
Requirement already satisfied: sympy in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (1.12)
Requirement already satisfied: networkx in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (3.2.1)
Requirement already satisfied: jinja2 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (3.1.3)
Requirement already satisfied: fsspec in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (2024.3.1)
Requirement already satisfied: nvidia-cuda-nvrtc-cu12==12.1.105 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (12.1.105)
Requirement already satisfied: nvidia-cuda-runtime-cu12==12.1.105 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (12.1.105)
Requirement already satisfied: nvidia-cuda-cupti-cu12==12.1.105 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (12.1.105)
Requirement already satisfied: nvidia-cudnn-cu12==<IP_ADDRESS> in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (<IP_ADDRESS>)
Requirement already satisfied: nvidia-cublas-cu12==<IP_ADDRESS> in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (<IP_ADDRESS>)
Requirement already satisfied: nvidia-cufft-cu12==<IP_ADDRESS> in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (<IP_ADDRESS>)
Requirement already satisfied: nvidia-curand-cu12==<IP_ADDRESS> in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (<IP_ADDRESS>)
Requirement already satisfied: nvidia-cusolver-cu12==<IP_ADDRESS> in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (<IP_ADDRESS>)
Requirement already satisfied: nvidia-cusparse-cu12==<IP_ADDRESS> in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (<IP_ADDRESS>)
Requirement already satisfied: nvidia-nccl-cu12==2.18.1 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (2.18.1)
Requirement already satisfied: nvidia-nvtx-cu12==12.1.105 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (12.1.105)
Requirement already satisfied: triton==2.1.0 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from torch->flash-attn) (2.1.0)
Requirement already satisfied: nvidia-nvjitlink-cu12 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from nvidia-cusolver-cu12==<IP_ADDRESS>->torch->flash-attn) (12.4.99)
Requirement already satisfied: MarkupSafe>=2.0 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from jinja2->torch->flash-attn) (2.1.5)
Requirement already satisfied: mpmath>=0.19 in /data/share8/zdw/miniconda3/envs/llava/lib/python3.10/site-packages (from sympy->torch->flash-attn) (1.3.0)
(llava) zdw@ai-gpu-server149:~/LLaVA$

test.py The content is as follows：
from llava.model.builder import load_pretrained_model
from llava.mm_utils import get_model_name_from_path
from llava.eval.run_llava import eval_model

model_path = "/home/zdw/Open-Sora/pre_training/llava-v1.6-34b"

tokenizer, model, image_processor, context_len = load_pretrained_model(
    model_path=model_path,
    model_base=None,
    model_name=get_model_name_from_path(model_path)
)

prompt = "What are the things I should be cautious about when I visit here?"
image_file = "https://llava-vl.github.io/static/images/view.jpg"

args = type('Args', (), {
    "model_path": model_path,
    "model_base": None,
    "model_name": get_model_name_from_path(model_path),
    "query": prompt,
    "conv_mode": None,
    "image_file": image_file,
    "sep": ",",
    "temperature": 0,
    "top_p": None,
    "num_beams": 1,
    "max_new_tokens": 512
})()

eval_model(args)

I have the same problem

I have a similar issue.
My error looks like this:
RuntimeError: Failed to import transformers.models.llama.modeling_llama because of the following error (look up to see its traceback): Failed to import transformers.generation.utils because of the following error (look up to see its traceback): cannot import name 'OutOfResources' from partially initialized module 'triton.runtime.autotuner' (most likely due to a circular import)
I tried reinstalling several times too. Does anyone have a solution?

I solved this by:
pip uninstall flash-attn
pip install flash-attn --no-build-isolation --no-cache-dir


Update gettingstarted.md

Added more details on Keyring/credential storage per OS.

Had a small question about \n, throws me off a little why that is the default value in the example but maybe I just don't understand the convention.

\n is treated the same as simply hitting return, which would create (or unlock) the keyring without a password.