Spack built hipsycl

Thanks for your work on hipSYCL, it's a cool piece of tech.
I know that I added a version and relaxed the cuda dependency (to get support for sm_86).  So feel free to close this as a "unsupported won't fix"
Bug summary
When building hipsycl like so
-- linux-fedora36-icelake /<EMAIL_ADDRESS>--------------------------
mkk35ih<EMAIL_ADDRESS>build_type=RelWithDebInfo
sbcib6z<EMAIL_ADDRESS>context-impl=fcontext cxxstd=17 patches=3a83d90,5da7ad2,607b077 visibility=hidden
lfp6axt<EMAIL_ADDRESS>build_type=Release
qvk5idn<EMAIL_ADDRESS>fccm7i6<EMAIL_ADDRESS>build_type=Release cuda_arch=86 shlib_symbol_version=none targets=all version_suffix=none
jjcaf2v<EMAIL_ADDRESS>ye4v57h<EMAIL_ADDRESS>b56i4ik<EMAIL_ADDRESS>u3usofy<EMAIL_ADDRESS>hs3lddd<EMAIL_ADDRESS>aecj7br<EMAIL_ADDRESS>ywjagsr<EMAIL_ADDRESS>libs=shared,static
e36sjzq<EMAIL_ADDRESS>libs=shared,static
tintps7<EMAIL_ADDRESS>patches=0d38234
yooood2<EMAIL_ADDRESS>abi=none
7jyij43<EMAIL_ADDRESS>lersj4g<EMAIL_ADDRESS>vhb5zj2<EMAIL_ADDRESS>sbdnv2y<EMAIL_ADDRESS>uix4eqs<EMAIL_ADDRESS>g6hf4ff<EMAIL_ADDRESS>eya554n<EMAIL_ADDRESS>patches=b231fcc
thststo<EMAIL_ADDRESS>lu4g5vh<EMAIL_ADDRESS>z7osihu<EMAIL_ADDRESS>dbm4vk7<EMAIL_ADDRESS>25n4nep<EMAIL_ADDRESS>patches=0d98e93,4c24573,f2fd060
gcyaauz<EMAIL_ADDRESS>s4badjt<EMAIL_ADDRESS>wvlg4ot<EMAIL_ADDRESS>szkodxx<EMAIL_ADDRESS>t7kna33<EMAIL_ADDRESS>zip=pigz
dq7xrbl<EMAIL_ADDRESS>certs=mozilla
omzu5ni<EMAIL_ADDRESS>fhbx2ot<EMAIL_ADDRESS>
building with an unmodified cuda causes compilations errors
To Reproduce
I used the vadd.cc example
#include <cassert>
#include <iostream>

#include <CL/sycl.hpp>

using data_type = float;

std::vector<data_type> add(cl::sycl::queue& q,
                           const std::vector<data_type>& a,
                           const std::vector<data_type>& b)
{
  std::vector<data_type> c(a.size());

  assert(a.size() == b.size());
  cl::sycl::range<1> work_items{a.size()};

  {
    cl::sycl::buffer<data_type> buff_a(a.data(), a.size());
    cl::sycl::buffer<data_type> buff_b(b.data(), b.size());
    cl::sycl::buffer<data_type> buff_c(c.data(), c.size());

    q.submit([&](cl::sycl::handler& cgh){
      auto access_a = buff_a.get_access<cl::sycl::access::mode::read>(cgh);
      auto access_b = buff_b.get_access<cl::sycl::access::mode::read>(cgh);
      auto access_c = buff_c.get_access<cl::sycl::access::mode::write>(cgh);

      cgh.parallel_for<class vector_add>(work_items,
                                         [=] (cl::sycl::id<1> tid) {
        access_c[tid] = access_a[tid] + access_b[tid];
      });
    });
  }
  return c;
}

int main()
{
  cl::sycl::queue q;
  std::vector<data_type> a = {1.f, 2.f, 3.f, 4.f, 5.f};
  std::vector<data_type> b = {-1.f, 2.f, -3.f, 4.f, -5.f};
  auto result = add(q, a, b);

  std::cout << "Result: " << std::endl;
  for(const auto x: result)
    std::cout << x << std::endl;
}

And compiled it like so: syclcc ./vadd.cc -O2  --hipsycl-targets="cuda:sm_86" -o vadd
Expected behavior
No compilation errors.
Actual Behavior
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/CL/sycl.hpp:31:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/CL/../hipSYCL/sycl/sycl.hpp:50:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/hipSYCL/glue/persistent_runtime.hpp:31:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/memory:77:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/shared_ptr.h:53:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/shared_ptr_base.h:196:22: error: use of undeclared identifier 'noinline'; did you mean 'inline'?
      __attribute__((__noinline__))
                     ^
/usr/local/cuda/include/crt/host_defines.h:82:37: note: expanded from macro '__noinline__'
#define __noinline__ __attribute__((noinline))
                                    ^
In file included from ./vadd.cc:4:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/CL/sycl.hpp:31:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/CL/../hipSYCL/sycl/sycl.hpp:50:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/hipSYCL/glue/persistent_runtime.hpp:31:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/memory:77:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/shared_ptr.h:53:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/shared_ptr_base.h:196:22: error: type name does not allow function specifier to be specified
/usr/local/cuda/include/crt/host_defines.h:82:37: note: expanded from macro '__noinline__'
#define __noinline__ __attribute__((noinline))
                                    ^
In file included from ./vadd.cc:4:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/CL/sycl.hpp:31:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/CL/../hipSYCL/sycl/sycl.hpp:50:
In file included from /home/runderwood/git/contrib/spack/opt/spack/linux-fedora36-icelake/gcc-11.3.0/hipsycl-0.9.3-mkk35ihj2txiqzipb643rkkziksbys5v/bin/../include/hipSYCL/glue/persistent_runtime.hpp:31:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/memory:77:
In file included from /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/shared_ptr.h:53:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/shared_ptr_base.h:196:22: error: expected expression
/usr/local/cuda/include/crt/host_defines.h:82:46: note: expanded from macro '__noinline__'
#define __noinline__ __attribute__((noinline))

While CUDA/LLVM being busted isn't your fault.  There are a few issues that could be addressed by you and/or your team:

It seems like there are some constraints on building a working hipsycl not currently expressed in the package.py.  Namely this cuda version can't be used (unmodified) with this compiler version for hipsycl.
As far as I can tell, hipsycl 0.9.3 works in spack (with some minor caveats) and could be added to spack.
Some documentation for "tested" known good spack installs would be useful.

Describe your setup
See spack find above.
Optional additional diagnostic information
A 1 line fix to cuda's include/crt/host_defines.h seems to resolve this issue:
#if defined(__CUDACC__) || defined(__CUDA_ARCH__) || defined(__CUDA_LIBDEVICE__)

changes to
#if (defined(__CUDACC__) || defined(__CUDA_ARCH__) || defined(__CUDA_LIBDEVICE__)) && ! defined(__clang__)
```

**Additional context**

Hi, thanks for the feedback. The spack package was built by a third-party and is currently not officially maintained by us, though we are happy to provide guidance to package maintainers.
So, issues related to the spack package itself are probably best asked in the spack repository (or provide a PR there).
Is there anything we can do in the hipSYCL repository itself to address some of these issues?

Thanks for you help.  I'll open a separate issues with the Spack folks.
I also wanted you and your team to be aware of the possible issues with GCC-12, Clang 15, and Cuda 11.7.   I think the documentation on these pages could be improved with respect to the CUDA backend:

https://github.com/illuhad/hipSYCL/blob/develop/doc/installing.md
https://github.com/illuhad/hipSYCL/blob/develop/doc/install-cuda.md

Specifically, it doesn't seem to be true that hipSYCL works with LLVM 13+ and CUDA 10+ in all cases.  Specifically It seems that there is a requirement the on GCC if libstdc++ is used by clang.  Adding the GCC version requirements for CUDA and documenting a few "known working" or "works for us" configurations to the installation pages could help people get started.

Thanks for the heads up.

Specifically, it doesn't seem to be true that hipSYCL works with LLVM 13+ and CUDA 10+ in all cases.

Usually, it works. When very recent versions of CUDA or libstdc++ are involved, it can rarely happen that upstream LLVM does not yet have support for those.
This information tends to be outdated fairly quickly though. For your issue, see e.g. https://github.com/llvm/llvm-project/issues/57544 so the issue is already solved upstream.
I'm not sure that if we create a list just because of such rare exceptions, it might create the impression that the number of working combinations are more restrictive than they actually are in practice. Plus, as I said, they might be outdated very quickly even within the same LLVM major version.


View repo failed

Description
build from main branch,https://github.com/go-gitea/gitea/commit/a12a5f3652c339b17b187ff424a480631a3c1e1e
An error occurred:

GetRecentlyPushedBranches, Error 1267 (HY000): Illegal mix of collations (utf8mb4_0900_ai_ci,IMPLICIT) and (utf8mb4_general_ci,IMPLICIT) for operation '='

Gitea Version
1.20.0+rc0-353-ga12a5f365
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
./gitea web
Database
MySQL

Oh, woohoo.
I start to hate MySQL.

It's not really related to MySQL, but it's Gitea's fatal.
In history, Gitea allows users to customize everything, including the MySQL's charset (but not other database's ....)
Then, incorrect charset causes this problem.

temporary solution: run ./gitea convertcommand

We need to have a fixed charset and collation for all supported databases.

I think if we can automate the convert operation after the migration


MambaSCD eval is NAN

Training Dataset: SECOND
Environment:

Python: 3.12.3
torch: 2.2.2+cu118

the first thing was GT_CD is no correct, but i found GT_CD data is not used to calculate eval score. my evaluation result is here

The GT_CD that i set unchanged is 0 and changed is 1。and now i set GT_CD unchanged to 0 and changed to 255, it works fine!

thanks for your help!


Zone scope definition not resolved correctly in PrimePlotter

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug
Incorrect face zonelets displayed in Example.
Following scope definition for zones is not resolving to the intended faces:
for zone in part.get_face_zones():
    print(model.get_zone_name(zone))
    scope = prime.ScopeDefinition(
        model,
        evaluation_type=prime.ScopeEvaluationType.ZONES,
        zone_expression=model.get_zone_name(zone),
    )
    display = PrimePlotter()
    display.add_scope(model, scope)
    display.show()

📝 Steps to reproduce
Run the linked example case until the final display code section quoted.
💻 Which operating system are you using?
Windows
📀 Which ANSYS version are you using?
24.2.0
🐍 Which Python version are you using?
3.10
📦 Installed packages
Running CI/CD.

Summary of issues noted:

00_lucid_file_IO.py - showing incorrect surfaces from zones
03_lucid_pipe_tee.py - not showing poly mesh in final image
05_pcb_stacker.py - not showing surface mesh on second plane display
08_lucid_generic_f1_rear_wing.py - not showing poly mesh in final image

Closed by #851  and #861


WebDAV won't connect on Windows 10

Might be relevant https://www.thexyz.com/account/knowledgebase/170/Error-0x80070043-The-network-name-cannot-be-found.html.

Fixed in #16.


How to log access token?

I need to log my access token, how do I remove obfuscate on it?
Tried this didn't work:
logbook.obfuscate.parameters=[]

An empty array is what we take as an indicator to fall back to the default.

I think the problem is that I'm writing my logs in DB using custom Writer, so that's why logbook properties don't work for me anymore or at least don't apply for logs in DB...

Obfuscation/Filtering is independent of your writer. The logbook properties like logbook.obfuscate.parameters should still apply.

Is your access token a query parameter or a header?

I guess this is right way to do it:
@Bean
    public BodyFilter bodyFilter() {
        Set<String> properties = new HashSet<>();
        properties.add("refresh_token");
        return BodyFilters.replaceJsonStringProperty(properties, "XXX");
    }

This will obfuscate. I thought you wanted to disable it?

Actually I wanted exactly this, to obfuscate refresh and save access token. Ty for help :)

In that case your code is correct.


discussion on improvement for milestone4

[Chris Gao]:

[x] add more description in the READme

[ paolocodina]:

[x] -filter, make the plots clearer, just add introduction in READme file [Anu]
[x] -change the font and the shape of the 'Load Data Frame' button [weilin]
[x] Adding a small section to display the author's name would be beneficial. [weilin]

[Sophia Zhao]

[x] -terms like 'apparent temperature' and 'sum of shortwave radiation' might be confusing., we can change [Anu]
[x] (add a link on dashboard to READme file) [Anu]

[John]
-no more, already finished 3/5
[Joel]

[x]  -Invert cards to be green background and white text font [weilin]
[x]  -Clearer about terms like "apparent temp" etc. Fix axis titles. [Anu]
[x]  -Style for reload button [Weilin]
[x]  -Remove "Date" from x-axis [Katherine]
[x] - Make font in parenthesis smaller [weilin]
[x] - Why is the date popup not close to the widget  [weilin]
[x]  -Select only most important temperatures (finish in READme) [Anu]
[x] - Link to repo, names, at the bottom of the sidebar  [Anu]

[Milestone 4]

[x] Reflection [Katherine]
[x] Use a binary format for loading data faster [oak]
[x] Have no redundant filtering/mutating of the data in the app [oak]
[x] Create a processed data file that is loaded in the app instead (stored in data/processed). [oak]
[x] Have no excessively slow computation that could be easily sped up, e.g. no row-wise use of apply unless well justified and optimized.[oak]
[x] Use caching for at least one function [oak]
[x] Set a favicon and tab title [weilin]
[x] Update the GIF animation. Use the same path as before and overwrite your previous GIF with a new once that reflects the final stage of your app. [Katherine]
[x] Update any screenshots and descriptions in your README that are outdated. [Anu]
[x] Including installation instructions that allow for the teaching team to download and run your app in a reproducible environment (Docker not needed). -finished
[x] The same for the description and topics in the "About" section of your GitHub repo (add topic like 'calendar' under 'about') [Anu]
[x] Assess whether it is necessary to have the Altair/Plotly toolbars that show up on hover. If not, remove them (especially if you have many charts). A good reason for keeping them would be if it is important to e.g. download the charts. -keep the tool bars

we finished all feedbacks, issue should be closed. Thanks everyone.


Develop zerocopy

This update leverages the new FD protocol in XLink to avoid unecessary copying, allowing for a zerocopy runtime on localhost.
This is allowed by the new memory class, SharedMemory, which instread of containing the data itself, like VectorMemory, it only holds the FD and the mapping.

Branch is ready for merge

There is a missing fd at the end of this line


cannot chat in Chinese language

Bug Report
Description
Bug Summary:
choose model llama2, chat in Chinese, such as "你好".
response:
Ollama: unexpected EOF
Uh-oh! There was an issue connecting to Ollama.
may be json parsing error with chinese.
Environment
docker ollama and docker open-webui
Logs and Screenshots
Screenshots (if applicable):

@xayjin ensure you have the latest version of the Docker image, v0.1.110 was pushed last night with a fix for this issue.

@justinh-rahb v0.1.110 is all right. thanks very much.


Safari Issue

In safari, File is still getting loaded and even duration is coming as infinity if preload is set to auto and 1 is preload is set to metadata. Please address the issue

Got the same issue...


[site request] Israel National News

Checklist

[X] I'm reporting a new site support request
[X] I've verified that I'm running yt-dlp version 2022.05.18 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that none of provided URLs violate any copyrights or contain any DRM to the best of my knowledge
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and am willing to share it if required

Region
No response
Example URLs
https://www.israelnationalnews.com/news/354520
https://www.israelnationalnews.com/news/354518
Description
I am a new user of yt-dlp, combined with mpc-be. So far it works pretty well, but now I bumped into a problem were embedded YT videos are not detected (?).
Verbose log
Microsoft Windows [Version 10.0.19044.1706]
(c) Microsoft Corporation. Alle rechten voorbehouden.

C:\WINDOWS\system32>"C:\Users\a\Desktop\MPC-BE\yt-dlp.exe" -vU https://www.israelnationalnews.com/news/354520
[debug] Command-line config: ['-vU', 'https://www.israelnationalnews.com/news/354520']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.05.18 [b14d523] (win_exe)
[debug] Python version 3.7.9 (CPython 32bit) - Windows-10-10.0.19041-SP0
[debug] Checking exe version: ffprobe -bsfs
[debug] Checking exe version: avprobe -bsfs
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: avconv -bsfs
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.14.1, brotli-1.0.9, certifi-2021.10.08, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
Latest version: 2022.05.18, Current version: 2022.05.18
yt-dlp is up to date (2022.05.18)
[debug] [generic] Extracting URL: https://www.israelnationalnews.com/news/354520
[generic] 354520: Requesting header
WARNING: [generic] Falling back on generic information extractor.
[generic] 354520: Downloading webpage
[generic] 354520: Extracting information
[debug] Looking for video embeds
ERROR: Unsupported URL: https://www.israelnationalnews.com/news/354520
Traceback (most recent call last):
  File "yt_dlp\YoutubeDL.py", line 1395, in wrapper
  File "yt_dlp\YoutubeDL.py", line 1465, in __extract_info
  File "yt_dlp\extractor\common.py", line 642, in extract
  File "yt_dlp\extractor\generic.py", line 4031, in _real_extract
yt_dlp.utils.UnsupportedError: Unsupported URL: https://www.israelnationalnews.com/news/354520

C:\WINDOWS\system32>

This site doesn't appear to directly embed Youtube, rather it calls its own API to get the youtube video id and then creates the embed. A specific site extractor would probably be needed.
relevant api call: https://www.israelnationalnews.com/Generic/NewAPI/Item?type=0&Item=354520

Ah, I see. But I think adding an extractor just for this website (not really big or important) is perhaps overkill. :-)
Thanks for your quick reply.

it's a mess.
as far I can tell, there are text to speech mp3 on the page:

that uses
https://vd.trinitymedia.ai/text2speech/israelnationalnews.com/a3f2a2f8ee1dfccf45c9be9bd036abce0c003074325db956942409d0209d3ede_en-US-JennyNeural_neural/audio.mp3
it isn't exists on the page, and needs js-rendering.

there are plain youtube players wrapped with some style..

they are wrapped within noembed:
https://noembed.com/embed?url=https://www.youtube.com/watch?v=jA84wQhVvg8

and there are also videos hosted on the local cdn of the website.
that also just exists on the DOM (requires js rendering),
you can just download normally from the video source element

I wish yt-dlp would enable https://github.com/puppeteer/puppeteer
I have phantomjs (https://github.com/eladkarako/yt-dlp_kit) but it's super old and very buggy.

It is very unlikely you will need js for an extractor for this site. we do not need to be rendering anything. just grab details from relevant HTML pages/API responses.
The text to speech might be an embed too, which details for are prob returned in a similar api response. It may require an additional extractor for that embed site. But I don't think that is something we are wanting to extract anyways.

Ah, I see. But I think adding an extractor just for this website (not really big or important) is perhaps overkill. :-)

There's already over 900 extractors. And most are for sites you won't even have heard of ;)

Any website that does not fall under https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#is-the-website-primarily-used-for-piracy is acceptable for a site-request - irrespective of popularity. If possible, we will try to improve generic extractor to handle the website, but if that is not feasible, it is a valid candidate for a new extractor.
Ofc, each developer may prioritize the requests based on the site's popularity, it's complexity, or for any other reason. The truth is, there simply isn't enough devs to ever be able to complete all the site requests. It only acts as a way to let contributors know that there is interest in the site.
I mark issues like this one, where we have already determined that the extraction process is relatively easy, with good-first-issue label in hopes that potential new contributors can use these as a good starting point.


UNMET PEER DEPENDENCY error

Thanks for contributing to react-virtualized!
Here is a short checklist of additional things to keep in mind before submitting:

Please make sure your pull request description makes it very clear what you're trying to accomplish. If it's a bug fix, please also provide a failing test case (if possible). In either case, please add additional unit test coverage for your changes. :)
Run tests locally (npm test) to ensure that your change did not break linting or functionality.
Be sure you have notifications setup so that you'll see my code review responses. (I may ask you to make some adjustments before merging.)

│├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>|| ^15.0.0

Current coverage is 98.29% (diff: 100%)

Merging #495 into master will not change coverage

@@             master       #495   diff @@
==========================================
  Files            61         61
  Lines          4389       4389
  Methods         925        925
  Messages          0          0
  Branches        333        333
==========================================
  Hits           4314       4314
  Misses           75         75
  Partials          0          0

Powered by Codecov. Last update 32454e0...d16fdb4

Would it be safe to assume any major version will be compatible? "react": "^0.14.0 || ^15"

Hmm...this change set has nothing to do with the unmet peer dependency issue (mentioned here). It just narrows down the range of supported 15.x versions of React, something I don't want to do without a very strong reason.
In case there's confusion, the current peer dependency version range will match against react version 15.3.2 (if that's the one you prefer to use).
For a visual explanation of what this change would do, go here, select "react" as the package, and then compare ^0.14.0 || ^15.0.0 to ^0.14.0 || ^15.3.2. You'll see how much more permissive 15.0.0 is than this change.
Anyway, thanks for the contribution but I can't merge it without causing problems for others who may be using versions in between 15.0.0 and 15.3.2.


rocminfo detects GPU, but clinfo doesn't

clinfo does not detect my GPU:
Number of platforms                               1
  Platform Name                                   AMD Accelerated Parallel Processing
  Platform Vendor                                 Advanced Micro Devices, Inc.
  Platform Version                                OpenCL 2.1 AMD-APP.dbg (3452.0)
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_icd cl_amd_event_callback
  Platform Extensions function suffix             AMD
  Platform Host timer resolution                  1ns

  Platform Name                                   AMD Accelerated Parallel Processing
Number of devices                                 0

NULL platform behavior
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  No platform
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   No platform
  clCreateContext(NULL, ...) [default]            No platform
  clCreateContext(NULL, ...) [other]
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  No devices found in platform

but the weird thing is, rocminfo does detect it!
ROCk module is loaded
=====================
HSA System Attributes
=====================
Runtime Version:         1.1
System Timestamp Freq.:  1000.000000MHz
Sig. Max Wait Duration:<PHONE_NUMBER>3709551615 (0xFFFFFFFFFFFFFFFF) (timestamp count)
Machine Model:           LARGE
System Endianness:       LITTLE

==========
HSA Agents
==========
*******
Agent 1
*******
  Name:                    AMD Ryzen 7 5800 8-Core Processor
  Uuid:                    CPU-XX
  Marketing Name:          AMD Ryzen 7 5800 8-Core Processor
  Vendor Name:             CPU
(skipped)
*******
Agent 2
*******
  Name:                    gfx803
  Uuid:                    GPU-XX
  Marketing Name:          AMD Radeon RX 580 Series
  Vendor Name:             AMD
  Feature:                 KERNEL_DISPATCH
  Profile:                 BASE_PROFILE
  Float Round Mode:        NEAR
  Max Queue Number:        128(0x80)
  Queue Min Size:          64(0x40)
  Queue Max Size:          131072(0x20000)
  Queue Type:              MULTI
  Node:                    1
  Device Type:             GPU
  Cache Info:
    L1:                      16(0x10) KB
  Chip ID:                 26591(0x67df)
  Cacheline Size:          64(0x40)
  Max Clock Freq. (MHz):   1411
  BDFID:                   1280
  Internal Node ID:        1
  Compute Unit:            36
  SIMDs per CU:            4
  Shader Engines:          4
  Shader Arrs. per Eng.:   1
  WatchPts on Addr. Ranges:4
  Features:                KERNEL_DISPATCH
  Fast F16 Operation:      TRUE
  Wavefront Size:          64(0x40)
  Workgroup Max Size:      1024(0x400)
  Workgroup Max Size per Dimension:
    x                        1024(0x400)
    y                        1024(0x400)
    z                        1024(0x400)
  Max Waves Per CU:        40(0x28)
  Max Work-item Per CU:    2560(0xa00)
  Grid Max Size:<PHONE_NUMBER>(0xffffffff)
  Grid Max Size per Dimension:
    x<PHONE_NUMBER>(0xffffffff)
    y<PHONE_NUMBER>(0xffffffff)
    z<PHONE_NUMBER>(0xffffffff)
  Max fbarriers/Workgrp:   32
  Pool Info:
    Pool 1
      Segment:                 GLOBAL; FLAGS: COARSE GRAINED
      Size:                    4194304(0x400000) KB
      Allocatable:             TRUE
      Alloc Granule:           4KB
      Alloc Alignment:         4KB
      Accessible by all:       FALSE
    Pool 2
      Segment:                 GROUP
      Size:                    64(0x40) KB
      Allocatable:             FALSE
      Alloc Granule:           0KB
      Alloc Alignment:         0KB
      Accessible by all:       FALSE
  ISA Info:
    ISA 1
      Name:                    amdgcn-amd-amdhsa--gfx803
      Machine Models:          HSA_MACHINE_MODEL_LARGE
      Profiles:                HSA_PROFILE_BASE
      Default Rounding Mode:   NEAR
      Default Rounding Mode:   NEAR
      Fast f16:                TRUE
      Workgroup Max Size:      1024(0x400)
      Workgroup Max Size per Dimension:
        x                        1024(0x400)
        y                        1024(0x400)
        z                        1024(0x400)
      Grid Max Size:<PHONE_NUMBER>(0xffffffff)
      Grid Max Size per Dimension:
        x<PHONE_NUMBER>(0xffffffff)
        y<PHONE_NUMBER>(0xffffffff)
        z<PHONE_NUMBER>(0xffffffff)
      FBarrier Max Size:       32
*** Done ***

(clinfo also does not detect my CPU, is that normal?)

Okay, I reinstalled ROCm using another package based on the .deb files and everything works again. Sorry for the noise!

@ColonelPhantom
Here is the solution for OpenCL with gfx803.
https://github.com/RadeonOpenCompute/ROCm/issues/1659#issuecomment-1219670138

I have the same issue on gentoo and would be happy if you remember the solution or at least the files you replaced? I emerge 5.3.3-r1 and 5.4.3. Here are the relevant info files:
clinfo.txt
lspci.txt
rocminfo.txt
rocm-smi.txt

Do you have
ROC_ENABLE_PRE_VEGA=1
in your environment?
Am 28.02.2023 um 07:30 schrieb Stefan Harjes:

I have the same issue on gentoo and would be happy if you remember the
solution or at least the files you replaced? I emerge 5.3.3-r1 and
5.4.3. Here are the relevant info files:
clinfo.txt
https://github.com/RadeonOpenCompute/ROCm/files/10847177/clinfo.txt
lspci.txt
https://github.com/RadeonOpenCompute/ROCm/files/10847178/lspci.txt
rocminfo.txt
https://github.com/RadeonOpenCompute/ROCm/files/10847179/rocminfo.txt
rocm-smi.txt
https://github.com/RadeonOpenCompute/ROCm/files/10847180/rocm-smi.txt
—
Reply to this email directly, view it on GitHub
https://github.com/RadeonOpenCompute/ROCm/issues/1810#issuecomment-1447657093,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIJI5JNKGYKW3YB6D2KZWVLWZWLRPANCNFSM6AAAAAAQRSKCUY.
You are receiving this because you are subscribed to this
thread.Message ID:
@.***>

--
Dr.-Ing. Martin Rose
Ingenieurbüro Dr.-Ing. Martin Rose
Sommerhofenstr. 148
71067 Sindelfingen
Germany
Tel.: +49 (0)7031 4923040

yep, at least it is set as a env variable


net/mail: ParseAddress should support UTF-8 (RFC 6532)

I'm using go v1.5.3, and parsing emails found in the wild (from senders like Linkedin and Gmail).
They expect to be able to include UTF-8 in email headers without q-encoding, but this is not currently supported by mail.ParseAddress.
There are two possible solutions:

We can update the parsing functions to allow only valid UTF-8 as defined by RFC 6532,
OR, we can allow arbitrary 8-byte strings, and allow the caller to decide whether it cares about the encoding of the returned string.

My experience from working on the mail gem for ruby would suggest that the second approach is the most pragmatic — often times email is badly formed, and it's really useful to be able to provide a "best-effort" parsing of badly formed email headers. However it seems like the go project tends a little bit more towards correctness, in which case the first approach may sit better in the standard library, and people who want the fuzzy behaviour can do it themselves.

/cc @dsymonds @alexcesaro

RFC 6532 is really an extension of RFC 5322, which we claim to support, so it seems fine to permit the extensions that RFC 6532 defines. I'm not keen on net/mail going out of its way to parse broken mail messages; it just makes it harder to use for the non-broken cases.

Ok, sounds good. I'll take a stab at updating the parser to accept UTF-8 multibyte-characters too. (I'm happy for serialization to continue using q-encoding for such names).

I agree. I don't think the stdlib should handle broken input. Fixing broken emails should be the role of third-party packages.

I've submitted a CL https://go-review.googlesource.com/19687, would appreciate any feedback you have.


chore(func): bump latest func to 1.8.1

This release contains the fix for https://github.com/knative/func/security/advisories/GHSA-5336-2g3f-9g3m
/kind chore
Signed-off-by: Lance Ball<EMAIL_ADDRESS>

Ping @dsimansk @rhuss

Bumped to the latest 1.8.2 @dsimansk @rhuss ptal

/approve
/lgtm


Add the flye assembler

The flye assembler will be used for assembly of demultiplexed genomes.

Using the flye assembler installed as conda environment on saga:
flye -v
2.9-b1768

Guppy demultiplexing was disabled., that needs to be added in such a way that the pipeline can skip qcat for demultiplexing. see issue #22


[fix] filename could contain illegal char

Issue: #6
Previous code used global_key or external_id as filename, but according to LabelBox documentation, they could contain illegal characters for a filename, e.g. a POSIX path separator /, which leads to an unexpected file path when used as a filename.
Improvement as follows:

offer an option to specify which key (among global_key, external_id and id) in data_row to use as filename.
when filename_key is not specified, try different options as previous code did, but also check for illegal characters.
default behavior (when filename_key is not give) is mostly not changed.

@IgorSusmelj Thanks, sorry for the late reply!


Revert "Revert "Update hello-world.mdx""

Reverts josep-the-great/nextjs-blog-theme#5

👷 Deploy Preview for resilient-rabanadas-125ad7 processing.

Name
Link

🔨 Latest commit
810647bc67d1bbcb37df70d82b19928f3bf7f48a

🔍 Latest deploy log
https://app.netlify.com/sites/resilient-rabanadas-125ad7/deploys/641d14bd43764c0008cda41b


Tech Docs review of stable_diffusion/image_to_image.ipynb

This PR generally improves the text in the notebook. The following have been added:

Extra links to improve usability.
A "Next steps" section to guide the user to other notebooks.
The summary table

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Visualize URDF and MJCF files

We have already provided an implementation where users are able to upload URDF and MJCF files on the backend. We should support this behavior on the frontend, and, when a user clicks on a listing, we should be able to visualize the URDFs that are available for that listing.

[ ] Implement frontend flow for uploading URDF and MJCF files
[ ] Automatically generate a snapshot of the robot model as a PNG which can be shown in the preview window
[ ] When a user visits a listing, they should be able to interact with the URDF

This depends a bit on #222


Make most emojis full-width

The table that we refer to in CodepointWidthDetector.cpp to determine
whether or not a codepoint should be rendered as Wide vs Narrow was
based off EastAsianWidth[1].  If a codepoint wasn't included in this
table, they're considered Narrow. Many emojis aren't specified in the
EAW list, so this PR supplements our table with emoji codepoints from
emoji-data[2] in order to render most, if not all, emojis as full-width.
There are certain codepoints I've added to the comments (in case we want
to add them officially to the table in the future) that Microsoft
decided to give an emoji presentation even if it's specified as
Narrow/Ambiguous in the EAW list and are not specified in the Unicode
emoji list. These include all of the Mahjong Tiles block, different
direction pencils (✎✐), different pointing index fingers (☜, ☞) among
others. I have no idea if I've captured all of them, as I don't know of
an easy way to detect which are Microsoft specific emojis.
Validation Steps Performed
I have looked at so many emojis that I dream emoji.
These screenshots aren't encompassing all emoji but I've tried to grab
a couple from all across the codepoint ranges:
Before:

After:

[1] http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt
[2] https://www.unicode.org/Public/13.0.0/ucd/emoji/emoji-data.txt
Closes #900

@msftbot make sure @miniksa signs off on this

I'm not an expert on this, but I've followed a few other discussions on this subject, and my understanding was that it was vital that we exactly follow whatever standard everyone else uses for determining character width. Applications like editors need to be able to predicate exactly how much of a line of text they can fit on the screen before it wraps. They can't do that if the standard says a character should be narrow, but we're rendering it as wide.
I don't know exactly what the standards are that we should be following, so maybe everything in this PR is good, but the mention of "Microsoft specific emojis" makes it sound like we're making up own rules for some characters, and I suspect that's going to cause problems.

I'm not an expert on this, but I've followed a few other discussions on this subject, and my understanding was that it was vital that we exactly follow whatever standard everyone else uses for determining character width. Applications like editors need to be able to predicate exactly how much of a line of text they can fit on the screen before it wraps. They can't do that if the standard says a character should be narrow, but we're rendering it as wide.
I don't know exactly what the standards are that we should be following, so maybe everything in this PR is good, but the mention of "Microsoft specific emojis" makes it sound like we're making up own rules for some characters, and I suspect that's going to cause problems.

I agree with James here. If Microsoft are the only one emojifying a particular Unicode codepoint, we should just center that glyph inside the 1 cell that it's supposed to be taking up.

That's fair, I was unsure about putting the Microsoft specific emojis in, because if I didn't, the lower_right_pencil u270e emoji that was noticed to be tiny in #900 would stay tiny since it isn't in the standard.

That's fair, I was unsure about putting the Microsoft specific emojis in, because if I didn't, the lower_right_pencil u270e emoji that was noticed to be tiny in #900 would stay tiny since it isn't in the standard.

Yeah that's why I said maybe we make it an experimental toggle that is off by default. So purists can have what Unicode dictates and Microsoft fanboys can have their full width pencils.

Yeah that's why I said maybe we make it an experimental toggle that is off by default. So purists can have what Unicode dictates and Microsoft fanboys can have their full width pencils.

I am deeply concerned with us plugging a configuration option into this global singleton function (since right now we don't have a good place to store state fo codepoint width detection, and we need conpty to agree on the widths with terminal, and there's no good way to communicate that state down to conpty)

I'll leave the MS codepoints I've found in the comments so we can come back to implement them as we wish in the future then?

Yeah that's why I said maybe we make it an experimental toggle that is off by default. So purists can have what Unicode dictates and Microsoft fanboys can have their full width pencils.

I am deeply concerned with us plugging a configuration option into this global singleton function (since right now we don't have a good place to store state fo codepoint width detection, and we need conpty to agree on the widths with terminal, and there's no good way to communicate that state down to conpty)

Oof. OK. Yeah you're right.

I'll leave the MS codepoints I've found in the comments so we can come back to implement them as we wish in the future then?

Yeah that's probably best.

James is right, but right now the best thing we have is "vague consensus of various wcwidth implementations" and we're only making things slightly more inconsistent by adding another one. I'm not happy that we have to do this, but I think that applications are going to have a rough time regardless since the landscape here is so bad. wcwidth operates on a wchar_t, and there's no practical way to handle things like the emoji variation selector or other composing characters.
Unfortunately, emoji are just one place where column-counting breaks down for applications. ☹

When I type a ☢ emoji and backspace it in Ubuntu 18.04 I need to Ctrl-L to make it disappear. This does not happen on cmd. Should I open a separate issue for this?

Nope. We fixed this with #5934 :smile: we got some of the widths wrong


Update Koin dependency

I updated the dependency by creating a function that creates a SingleInstanceFactory
the BeanDefinition's Definition I created it manually by following the newInstance function
In the module functions I replaced the Pair return with the new KoinDefinition class

Great job! I had actually opened an issue on the Koin project for this, so thank you
Nice to see you again! Are you using this Clean Architecture template in your own projects? If so, how is it going and, if any, what changes would you make?

@ESchouten
I'm still using this template in my project and I'm having a good time with it.
I am still using graphql-kotlin. A few versions ago the module for Ktor was added. Instead I changed the generation method, the one before I found it too "complicated" and confusing, at the moment I opted to manually create classes for queries, mutations and types. However I was looking for a better way since this method adds a lot of boilerplate. (I was thinking of automatically generating the class?)
I noticed that the orm exposed has not been updated for quite a while. I wanted to see about trying to change it with Jooq or some other library. In the future why not implement another database: edge-db, surreal-db... however for these implementations i would wait until i have client libraries for java
In the future I wanted to try to modify the structure of this project to make it a modular monolith. Use this project as the core for different modules, e.g. user module, employee module... However, this would be a long work that would take lots of time as there are so many variables to be considered
Unfortunately these are just ideas at the moment as the university is taking me a lot of time

@Francynox Sounds good! Out of curiosity, is there a reason why you use the Graphql endpoints instead of the OpenAPI rest ones? For me this prevented me from writing a lot of boilerplate, which are the GQL queries, I am able to just call the REST endpoints with the generated SDK.
Generating classes sounds hard and tricky, it's basically the reason why this project is still on KGraphql. Creating classes in runtime is very tricky, and generating the code, which needs to be kept up to date, does not sound ideal to me either...
Regarding Exposed, I agree. Ideally I want a database library/ORM that is able to create migration files based on the tables. Not sure what to choose. As for now, Exposed satisfies all my other needs.
I have been thinking about separating the code into modules for each domain as well. When creating this project I had to choose whether I wanted to create hard boundaries/modules by domain or by layer. I chose for the latter in order to force the developer to correctly separate the library code/adapters from the business model. I wonder if we could easily/automatically define (sub)modules within these layers


PDF TO WORD DOCS

hello can i convert pdf file to text document

Yes, please have a look at the conversion types available. They include both PDF and txt.


[BUG] CodeCov Not Working

What happened?
Hey @DilumAluthge ,
Thanks for helping @cncastillo and co here for KomaMRI get set-up over here on JuliaHealth! Carlos and I were speaking however and it seems that their CodeCov no longer works properly. Both the codecov.yml file and ci.yml look perfectly fine to me. I also checked the CodeCov permissions here and all access permissions are granted to the GitHub app.
It is quite curious as all my normal debugging has failed for this and I am a bit stumped. Is there some setting in JuliaHealth that I am not aware of that might be breaking CodeCov here?
Thanks!
~ tcp :deciduous_tree:
Environment
On the latest response from a webhook to CodeCov, we see this:

{"detail":"You do not have permission to perform this action."}

Hey @DilumAluthge, I'll let @cncastillo and @beorostica comment more here but with KomaMRI's set-up, currently, it uses a webhook to send out a codecov request. Carlos was saying this was previously working fine when they were not within JuliaHealth so it seems like something may have gone wrong in the transition over to here.
It seems like whenever a PR is made or updated, a request gets sent via the webhook but this permission error keeps popping up.

Thanks @DilumAluthge!
Just to complement this answer, the codecov is being sent correctly to https://app.codecov.io/gh/JuliaHealth/KomaMRI.jl, but the bot that creates the reports (like the one below) stopped working.

The PRs look good to me, so accepted them. @beorostica could you look at them?

Let's try this: I'm going to:

Remove the GitHub app from this repo
Delete the webhook
Reinstall the GitHub app on this repo

Let's see if that does anything.

Okay, I got the Codecov comment to be posted in https://github.com/JuliaHealth/KomaMRI.jl/pull/343

Okay and the Codecov commit statuses have now been created on https://github.com/JuliaHealth/KomaMRI.jl/pull/343

So out of curiosity, what went wrong here @DilumAluthge ? Could you track down where things broke exactly? Or did you just reset all of CodeCov for the repository?

Thanks @DilumAluthge and @TheCedarPrince for all your time :pray:. I wouldn´t have been able to fix it alone.
What a weird bug. I read in other places that the turn-it-on-and-off approach also worked for them. We will just double-check that everything works today (@beorostica), and I will close this issue :smile:.


[Docs] example code for stringMatching not passing

Do you want to request a feature or report a bug?
Bug. I think it's a bug in a code example in the documentation
https://facebook.github.io/jest/docs/expect.html#expectstringmatchingregexp
What is the current behavior?
The test fails:
● randomCoolNames only returns cool names

    You must provide an array to arrayContaining, not '[object Object]'.

If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.
https://repl.it/F8eM/7
What is the expected behavior?
For the test to pass
Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

Yes, this is a bug in docs. Would you mind fixing that and send a PR? It should go like that:
  expect(randomCoolNames()).toEqual(
    expect.arrayContaining([
      expect.stringMatching(coolRegex)
    ])
  );

Sure, but it'll be my first PR, so pls bear with me.

Will do, tnx :)

Ok, so I

cloned the jest repo on my machine
checked out a new branch and called it: docbug_stringMatching
added and committed the fix to this branch
signed the CLA
(assumed running the tests was not necessary for a doc change)

should I now push the branch back to the jest repo?

yup, you can now send a pull request against master branch

I am confused, I am reading that I should have forked it first, and cloned it from the fork.
The CONTRIBUTING.md also says:
Fork the repo and create your branch from master
and then
git clone https://github.com/facebook/jest
should that not be:
git clone https://github.com/<my_user_name>/jest ?

Oh, that's right.


Lots of changes added

Given the known errors with youtube-dl, I changed it to yt-dlp.
I also added a lot of information so people know why their videos do not appear in their galleries.
That's because the Termux:API app must be installed first in order to use the termux-api package.
After downloading the video with several new flags in a new configuration file, the program now tries to scan the directory if the Termux:API app is installed so the device recognizes the new files downloaded.
I also added new colors and made the code a little prettier

love it


WIP: Greece & prior week spare time work

Codecov Report

Merging #7 (040c5df) into main (66a160e) will decrease coverage by 45.99%.
The diff coverage is 38.16%.

@@             Coverage Diff             @@
##             main       #7       +/-   ##
===========================================
- Coverage   94.63%   48.63%   -46.00%
===========================================
  Files           3        6        +3
  Lines         149      477      +328
===========================================
+ Hits          141      232       +91
- Misses          8      245      +237

Impacted Files
Coverage Δ

src/firebasil/auth/auth.py
0.00% <0.00%> (ø)

src/firebasil/auth/types.py
0.00% <0.00%> (ø)

src/firebasil/sse/sse_client.py
88.04% <88.04%> (ø)

src/firebasil/rtdb.py
96.62% <95.65%> (+2.21%)
:arrow_up:

src/firebasil/exceptions.py
100.00% <100.00%> (ø)

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 66a160e...040c5df. Read the comment docs.


Duplo 13405 Terraform provider - duplocloud batch job definitions with revisions do not delete correctly

Overview
Bug fix for Terraform gets timed out while destroying batch job resources
Summary of changes
Terraform Job Deletion time out issue fixed
This PR does the following:

When a change is made to the batch job that requires recreation, terraform  deletes all the revisions of the job and then recreate it.

Testing performed

[ ] Using unit tests
[ ] Manually, on my local system
[ ✓] Manually, on a remote test system

Describe any breaking changes

...

Task linked: DUPLO-13405 Terraform provider - duplocloud batch job definitions with revisions do not delete correctly


fix lookup of backup objects in the cluster

With #1031 changes there is an error when looking up Backups with using a ListParam.  This changes how we filter for volumeSnapshot method backups.
2024-11-04T18:05:45.955686Z ERROR reconciling object:reconcile:reconcile:cleanup_old_volume_snapshots: controller::cloudnativepg::retention::snapshots:63: Failed to list backups in namespace barely-permissive-deer: ApiError: field label not supported: spec.method: BadRequest (ErrorResponse { status: "Failure", message: "field label not supported: spec.method", reason: "BadRequest", code: 400 }) object.ref=CoreDB.v1alpha1.coredb.io/barely-permissive-deer.barely-permissive-deer object.reason=object updated trace_id=00000000000000000000000000000000 instance=barely-permissive-deer namespace=barely-permissive-deer retention_days=40

What's the bug preventing the API filter from working?
Code change looks good to me for in-memory workaround, I'm just curious why it broke…

Great question.  The spec.method field is not a field that ListParams supports to look up objects with.  I knew this, but did it anyway and never thought about it until I saw the error.
The ListParams method only supports looking up valid labels from the metadata, not actual fields inside the API object.


Fix for osx and free bsd

I did not mean for the the previous commits to be included in this new pull request. I'll close this pull request and will re-open one with only the relevant commit.


experiment group is problematic

get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
	experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:94:  ERROR - Failed to connect to MongoEngine DB:
	experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:95:  ERROR - Traceback (most recent call last):
  File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py", line 90, in getconn
    password=cls.DBCONFIG["password"])
  File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 164, in connect
    return get_connection(alias)
  File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 126, in get_connection
    raise ConnectionError("Cannot connect to database %s :\n%s" % (alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.

CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:125:  DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read preference.

appears to be caused by the pymongo compatibility issue when upgrading to 3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8 before we thoroughly address this issue. I’m modifying the requirements again.

On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:94:  ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:95:  ERROR - Traceback (most recent call last):
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py", line 90, in getconn
password=cls.DBCONFIG["password"])
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 164, in connect
return get_connection(alias)
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" % (alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:125:  DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read preference.
—
Reply to this email directly or view it on GitHub https://github.com/cloudmesh/cloudmesh/issues/206.

please lets use 2.8 can you gues all update the requirements file from the various packages

On Apr 16, 2015, at 3:17 PM, Fugang Wang<EMAIL_ADDRESS>wrote:
appears to be caused by the pymongo compatibility issue when upgrading to 3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8 before we thoroughly address this issue. I’m modifying the requirements again.

On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:94: ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:95: ERROR - Traceback (most recent call last):
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py", line 90, in getconn
password=cls.DBCONFIG["password"])
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 164, in connect
return get_connection(alias)
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" % (alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:125: DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read preference.
—
Reply to this email directly or view it on GitHub <https://github.com/cloudmesh/cloudmesh/issues/206 https://github.com/cloudmesh/cloudmesh/issues/206>.

—
Reply to this email directly or view it on GitHub https://github.com/cloudmesh/cloudmesh/issues/206#issuecomment-93819025.

I made the change on dev2.0 and merge it to master also.
I also made the same modification on the cloudmesh_base requirements.txt.

On Apr 16, 2015, at 3:17 PM<EMAIL_ADDRESS>wrote:
appears to be caused by the pymongo compatibility issue when upgrading to 3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8 before we thoroughly address this issue. I’m modifying the requirements again.

On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:94:  ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:95:  ERROR - Traceback (most recent call last):
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py", line 90, in getconn
password=cls.DBCONFIG["password"])
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 164, in connect
return get_connection(alias)
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" % (alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:125:  DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read preference.
—
Reply to this email directly or view it on GitHub https://github.com/cloudmesh/cloudmesh/issues/206.

FYI. The issue:
https://github.com/MongoEngine/mongoengine/issues/935
On Thu, Apr 16, 2015 at 3:21 PM<EMAIL_ADDRESS><
<EMAIL_ADDRESS>wrote:

I made the change on dev2.0 and merge it to master also.
I also made the same modification on the cloudmesh_base requirements.txt.
On Apr 16, 2015, at 3:17 PM<EMAIL_ADDRESS>wrote:
appears to be caused by the pymongo compatibility issue when upgrading to
3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8 before we
thoroughly address this issue. I’m modifying the requirements again.
On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:94:  ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:95:  ERROR - Traceback (most recent call last):
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py", line 90, in getconn
password=cls.DBCONFIG["password"])
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 164, in connect
return get_connection(alias)
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" % (alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:125:  DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read preference.
—
Reply to this email directly or view it on GitHub
https://github.com/cloudmesh/cloudmesh/issues/206.

For those who might have installed cloudmesh while we did not have pymongo version fixed to 2.8, in case they saw the problem, they should uninstall the installed pymongo first and then reinstall from our specified requirements.txt.

On Apr 16, 2015, at 3:22 PM, Fugang Wang<EMAIL_ADDRESS>wrote:
FYI. The issue:
https://github.com/MongoEngine/mongoengine/issues/935 https://github.com/MongoEngine/mongoengine/issues/935
On Thu, Apr 16, 2015 at 3:21 PM<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I made the change on dev2.0 and merge it to master also.
I also made the same modification on the cloudmesh_base requirements.txt.

On Apr 16, 2015, at 3:17 PM<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
appears to be caused by the pymongo compatibility issue when upgrading to 3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8 before we thoroughly address this issue. I’m modifying the requirements again.

On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:94:  ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:95:  ERROR - Traceback (most recent call last):
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py", line 90, in getconn
password=cls.DBCONFIG["password"])
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 164, in connect
return get_connection(alias)
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" % (alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:125:  DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read preference.
—
Reply to this email directly or view it on GitHub https://github.com/cloudmesh/cloudmesh/issues/206.

can you work out the final soultion, i will than also do a pypi update when you are done, than work on an announcement for the class just incase someone got stuck inbetween.
explain this is not our problem but an incompatibility in a packag ethat we use that was introcuded last week.

On Apr 16, 2015, at 3:25 PM, Fugang Wang<EMAIL_ADDRESS>wrote:
For those who might have installed cloudmesh while we did not have pymongo version fixed to 2.8, in case they saw the problem, they should uninstall the installed pymongo first and then reinstall from our specified requirements.txt.

On Apr 16, 2015, at 3:22 PM, Fugang Wang<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
FYI. The issue:
https://github.com/MongoEngine/mongoengine/issues/935 https://github.com/MongoEngine/mongoengine/issues/935<https://github.com/MongoEngine/mongoengine/issues/935 https://github.com/MongoEngine/mongoengine/issues/935>
On Thu, Apr 16, 2015 at 3:21 PM<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I made the change on dev2.0 and merge it to master also.
I also made the same modification on the cloudmesh_base requirements.txt.

On Apr 16, 2015, at 3:17 PM<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
appears to be caused by the pymongo compatibility issue when upgrading to 3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8 before we thoroughly address this issue. I’m modifying the requirements again.

On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS>mailto:notifications<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:94: ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:95: ERROR - Traceback (most recent call last):
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py", line 90, in getconn
password=cls.DBCONFIG["password"])
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 164, in connect
return get_connection(alias)
File "/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py", line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" % (alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc... site:125: DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read preference.
—
Reply to this email directly or view it on GitHub <https://github.com/cloudmesh/cloudmesh/issues/206 https://github.com/cloudmesh/cloudmesh/issues/206>.

—
Reply to this email directly or view it on GitHub https://github.com/cloudmesh/cloudmesh/issues/206#issuecomment-93820468.

Well, in any case, this should ensure the right version of pymongo is being
used:
In cloudmesh git directory, when virtualenv is active:
git pull;
pip uninstall pymongo;
pip install -r requirements.txt
On Thu, Apr 16, 2015 at 3:29 PM, Gregor von Laszewski <
<EMAIL_ADDRESS>wrote:

can you work out the final soultion, i will than also do a pypi update
when you are done, than work on an announcement for the class just incase
someone got stuck inbetween.
explain this is not our problem but an incompatibility in a packag ethat
we use that was introcuded last week.

On Apr 16, 2015, at 3:25 PM, Fugang Wang<EMAIL_ADDRESS>wrote:
For those who might have installed cloudmesh while we did not have
pymongo version fixed to 2.8, in case they saw the problem, they should
uninstall the installed pymongo first and then reinstall from our specified
requirements.txt.

On Apr 16, 2015, at 3:22 PM, Fugang Wang<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
FYI. The issue:
https://github.com/MongoEngine/mongoengine/issues/935 <
https://github.com/MongoEngine/mongoengine/issues/935><
https://github.com/MongoEngine/mongoengine/issues/935 <
https://github.com/MongoEngine/mongoengine/issues/935>>
On Thu, Apr 16, 2015 at 3:21 PM<EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS>wrote:
I made the change on dev2.0 and merge it to master also.
I also made the same modification on the cloudmesh_base
requirements.txt.

On Apr 16, 2015, at 3:17 PM<EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS>wrote:
appears to be caused by the pymongo compatibility issue when
upgrading to 3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8
before we thoroughly address this issue. I’m modifying the requirements
again.

On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS>mailto:notifications<EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc...
site:94: ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc...
site:95: ERROR - Traceback (most recent call last):
File
"/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py",
line 90, in getconn
password=cls.DBCONFIG["password"])
File
"/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py",
line 164, in connect
return get_connection(alias)
File
"/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py",
line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" %
(alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc...
site:125: DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read
preference.
—
Reply to this email directly or view it on GitHub <
https://github.com/cloudmesh/cloudmesh/issues/206 <
https://github.com/cloudmesh/cloudmesh/issues/206>>.

—
Reply to this email directly or view it on GitHub <
https://github.com/cloudmesh/cloudmesh/issues/206#issuecomment-93820468>.

—
Reply to this email directly or view it on GitHub
https://github.com/cloudmesh/cloudmesh/issues/206#issuecomment-93821161.

Alternatively, even if pymongo 3.0 is installed, a
pip install pymongo==2.8
would force downgrade the version.
These are all for those who had started the installation. For new users who
check out the new code and do a fresh install, the latest code already
restricted the pymongo version to 2.8.
On Thu, Apr 16, 2015 at 3:43 PM, Fugang Wang<EMAIL_ADDRESS>wrote:

Well, in any case, this should ensure the right version of pymongo is
being used:
In cloudmesh git directory, when virtualenv is active:
git pull;
pip uninstall pymongo;
pip install -r requirements.txt
On Thu, Apr 16, 2015 at 3:29 PM, Gregor von Laszewski <
<EMAIL_ADDRESS>wrote:

can you work out the final soultion, i will than also do a pypi update
when you are done, than work on an announcement for the class just incase
someone got stuck inbetween.
explain this is not our problem but an incompatibility in a packag ethat
we use that was introcuded last week.

On Apr 16, 2015, at 3:25 PM, Fugang Wang<EMAIL_ADDRESS>wrote:
For those who might have installed cloudmesh while we did not have
pymongo version fixed to 2.8, in case they saw the problem, they should
uninstall the installed pymongo first and then reinstall from our specified
requirements.txt.

On Apr 16, 2015, at 3:22 PM, Fugang Wang<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
FYI. The issue:
https://github.com/MongoEngine/mongoengine/issues/935 <
https://github.com/MongoEngine/mongoengine/issues/935><
https://github.com/MongoEngine/mongoengine/issues/935 <
https://github.com/MongoEngine/mongoengine/issues/935>>
On Thu, Apr 16, 2015 at 3:21 PM<EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS>wrote:
I made the change on dev2.0 and merge it to master also.
I also made the same modification on the cloudmesh_base
requirements.txt.

On Apr 16, 2015, at 3:17 PM<EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS><EMAIL_ADDRESS><mailto:
<EMAIL_ADDRESS>wrote:
appears to be caused by the pymongo compatibility issue when
upgrading to 3.0.
I’m using 2.8 and I don’t see the error.
So, maybe at this point we again revert back to use pymongo 2.8
before we thoroughly address this issue. I’m modifying the requirements
again.

On Apr 16, 2015, at 3:09 PM, Hyungro Lee<EMAIL_ADDRESS>mailto:notifications<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
get_mongo_db("experiment", DBConnFactory.TYPE_MONGOENGINE) fails.
The test command throws errors::
cm> group list
Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc...
site:94: ERROR - Failed to connect to MongoEngine DB:
experiment
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc...
site:95: ERROR - Traceback (most recent call last):
File
"/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.py",
line 90, in getconn
password=cls.DBCONFIG["password"])
File
"/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py",
line 164, in connect
return get_connection(alias)
File
"/home/ubuntu/virtualenv/ENV/local/lib/python2.7/site-packages/mongoengine/connection.py",
line 126, in get_connection
raise ConnectionError("Cannot connect to database %s :\n%s" %
(alias, e))
ConnectionError: Cannot connect to database experiment :
False is not a read preference.
CM /cloudmesh-2.3.0-py2.7.egg/cloudmesh/config/cm_config.pyc...
site:125: DEBUG - connection failed to experiment
ERROR: Cannot connect to database experiment : False is not a read
preference.
—
Reply to this email directly or view it on GitHub <
https://github.com/cloudmesh/cloudmesh/issues/206 <
https://github.com/cloudmesh/cloudmesh/issues/206>>.

—
Reply to this email directly or view it on GitHub <
https://github.com/cloudmesh/cloudmesh/issues/206#issuecomment-93820468>.

—
Reply to this email directly or view it on GitHub
https://github.com/cloudmesh/cloudmesh/issues/206#issuecomment-93821161
.


Add description of fast-forward attack to SECURITY.md

@JustinCappos I'd like to add a description of the fast-forward attack to the security page, and then reference it from the specification.  Have I generalized and given a clear description of the fast-forward attack?

Also updated the specification to include the fast-forward attack, and some that were missing.

@JustinCappos
I think you might have missed this notification.


fix(ci): update tmux in test workflow

ubuntu-latest is ubuntu-24.04, see https://github.com/actions/runner-images?tab=readme-ov-file#available-images.
ubuntu24.04 has tmux version 3.4-1build1.
Don't know what the best option is

"upgrading" the tmux version
another image, for example ubuntu-22.04
matrix of ubuntu-20.04, ubuntu-22.04, ubuntu-24.04/ubuntu-latest
building tmux from source, don't think this is a good idea just adding it to complete the list

Update from what tmux version to which version? In my mind 3.4 is recent enough to cover a majority of functionality

Update from 3.2a-4ubuntu0.2 to 3.4-1build1 since 3.2a no longer exists in the latest package repository and thus fails to install.


Some cleanup on Karma config

Condensed a bunch of explicit configuration paths down to a few patterns (it was done the verbose way at first because of the need to include all the bower components, and those don't always play by nice rules).
This should allow any new additions to show up in the testing area right away as well.

This is pretty much deprecated now with the recent changes. closing.


⚠ Bofrost.be has degraded performance

In df91b1f, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 802 ms

Resolved: Bofrost.be performance has improved in 3cecacf after 7 minutes.


fix approvals limitation

@JonasFranzDEV  fix bug on https://github.com/go-gitea/gitea/pull/5350#issuecomment-446174156

Codecov Report

Merging #5521 into master will increase coverage by <.01%.
The diff coverage is 20%.

@@            Coverage Diff             @@
##           master    #5521      +/-   ##
==========================================
+ Coverage   37.58%   37.59%   +<.01%
==========================================
  Files         318      318
  Lines       46928    46930       +2
==========================================
+ Hits        17638    17642       +4
+ Misses      26778    26777       -1
+ Partials     2512     2511       -1

Impacted Files
Coverage Δ

models/branches.go
43.33% <0%> (ø)
:arrow_up:

routers/repo/issue.go
37.3% <25%> (+0.02%)
:arrow_up:

modules/process/manager.go
81.15% <0%> (+4.34%)
:arrow_up:

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 9681c83...c17fcd1. Read the comment docs.


Having trouble creating a new project

Rasa version:2.2.2
Rasa SDK version : 2.2.0
Python version: 3.8.0
Operating system :windows
Issue: AttributeError: module 'tensorflow.python.keras.utils.tf_utils' has no attribute 'smart_cond'

Thanks for the issue, @yennycheung will get back to you about it soon!
You may find help in the docs and the forum, too 🤗

what version of tensorflow do you have installed?

what version of tensorflow do you have installed? this sounds like #7634 which is due to using too low a tensorflow version

I have the latest tensorflow(2.4.0) version, but the error is still showing when i try to create a new project .

In that case it might be too high a version - the required version is listed here https://github.com/RasaHQ/rasa/blob/b555a5d49bb4d5787fa9e18aa8bc1783cb62a1a2/pyproject.toml#L114
so up to 2.3. It  might be something else, but worth trying.

Have the same error,
Rasa Version     : 2.2.2
Rasa SDK Version : 2.2.0
Rasa X Version   : None
Python Version   : 3.6.5
Operating System : Linux-5.8.0-34-generic-x86_64-with-debian-bullseye-sid
Tensorflow-GPU:2.4.0
Why I install tf2.4 because tf2.3 can not run with cuda on my 3060ti, so i have to install the latest version

Closing as TensorFlow 2.4 is currently not supported.

Closing as TensorFlow 2.4 is currently not supported.


Stop loading carousel images not in view as of yet.

Dear community,
I am attempting to integrate this plugin along with OwlCarousel2. But, I seem to be getting images loaded that are not yet in view. For example, if you view the pen I have put together here; you will see that in the carousel below: images 1-4 are in view (if viewed on a device with a width greater than 1000px, or 1-3 if 600px-999px or 2 if less than 600). Now, looking in the network panel of my 1364px wide chrome browser, I can see that images 1-5 are loaded when scrolled into view then little while after image 6 is also loaded strangely, even though I have not scrolled the carousel at all.
Is there a way to get lazysizes to only load whats in view rather than these further two images?

@vishy93
This is a feature not a bug. lazysizes will load first only all images that are in view, than after a while will preload all images that are very near the view and after onload will preload image that are a little bit whiter out of view.
This is the normal behavior, which is good for your users, so that they are able to see all images more instantly, without waiting.
You can however change this behavior using expand, expFactor and hFac. Although I wouldn't change them.

aFarkas, I understand, but if used in carousels or such, wouldn't it be a waste of loading if user does not interact with the the carousel?

It would be always a waste if the user doesn't scroll to the image. But if you have performance concerns, there are none, because lazysizes sorts and queue the downloads accordingly.
You have to choose wether the user loads 2-4 images more (but later) and sees an image immediately or does not preload images and has to wait.

aFarkas, ahh okay thats fair enough

I'll start saying the lazysizes is just plain awesome, like, really awesome, so thank you for having created it.
Having said that, the "problem" here is not about perf, because queues and stuff, but about being able to not load 20 images in a 20 slide carousel without a reason. Think bandwidth usage and the likes.
Does this make sense or am I missing something here?

njy I understand, I guess aFarkas does have a point with regards to usability and not making users wait. Maybe a happy medium would be limit how far out of view it will load them, so in my case instead of loading like images 5 and 6, it would load image 5 only.

@vishy93 yeah absolutely, I did'n mean to not load next/prev slides at all :-)
In my opinion the logic for carousels should be exactly the same as the usual lazysizes logic for off-screen images: load the ones on screen first, the near ones second.
I'll try to make an example: let's say I have a page with 1 opening image, 1 opening carousel and other 19 images, 1 of them being just below the fold. Also, the carousel has 20 images in total, the first being immediately visible.
So 20 images in the carousel + 20 images "alone".
Now, lazysizes is smart enough to load immediately the first "alone" image, then the one "alone" below the fold, then stops and waits for scrolls (good) but at the same time it starts loading all the 20 images from the carousel (if I got it right, otherwise sorry for the misunderstanding on my side).
As you see there's a difference in how images are treated (alone or in a carousel) and - unless obviously there's a hard technical problem to solve - it would be nice to have the same behaviour.
To avoid users waiting I was thinking if it may be possible to load immediately the first image in the carousel, queue the second (and maybe the last in case of a looping carousel?) and delay the others for when the users change slides.
Does it make sense?

njy makes sense.

@aFarkas you stated

You can however change this behavior using expand, expFactor and hFac

However, I currently have:
    window.lazySizesConfig.expand = -2;
    window.lazySizesConfig.expFactor = 0.01;
    window.lazySizesConfig.hFac = -0.4;

but too great a hFac would break the loading in mobile I believe. Is there a way to dynamically set this depending on screen size?

Yes of course but hFac should be a positive value.

@aFarkas yeah I changed expand to be 0. What would you recommend for ideal settings.


[BUG] Unbind resets nested batch sizes

td = TensorDict({"a": TensorDict({"b": torch.zeros(2,3)}, [2,3])},[2])
td["a"].batch_size # torch.Size([2, 3])
tds = td.unbind(0)
tds[0]["a"].batch_size # torch.Size([]) should be torch.Size([3])

I think this is a problem stemming from the fact that apply disregards the nested batch sizes if you want I can look into it, just let me know


Add 'async' to the List of Reserved Keyword

One of the projects I work on maintains a list of keywords (for escaping purposes), and while looking through it, I noticed that a big one (async) was missing from the reference.
So, I thought I'd open a quick PR to add it!
But after looking through the issues and finding #242, it turns out there's actually a few missing...
Figured I'd still open this, but if you'd prefer to close it and wait until a more comprehensive PR can fix all the missing keywords, it'd be no skin off my back! : v)

As for the placement, looking through the grammar rules, it looks like async is only reserved in certain contexts.
For instance, it's valid to use async as an identifier.

Merged in 8f7c1b73.


Serialization/Performance

So to start, I was digging through the code, and our issue mainly stems from the fact that we need to decode the main response, to get the RPC ID for handling the callback
I was playing with this jsonparser package earlier today with something else, then I realised we might be able to use it here.
I did a simple benchmark, and the performance just to get the ID is much faster

My idea:
We can use the jsonparser, to get the id, and then we use a struct like:
type RPCRawResponse struct {
	ID       string
	Data    []byte
	Decoded *RPCResponse
}

This "response" can be passed down the channels and such to the end function and only decoded once.
On top of this, we can build a top level "QueryResolver" which uses a generic, and is an opt-in function/struct, which handles context, decoding, checking for errors etc
This will take the byte version and pull information out in small pieces, we can also decode once to the final desired output struct from this, rather than Unmarshal -> get id -> Marshal -> Unmarshal -> check for errors and potentially more...
How do we feel about this?
I hacked together a crappy version of this "QueryResolver" setup in my project already, but i didn't optimise or care much for code quality as i was just playing, but it's semi elegant to use

The only issue I have with this approach is generics. I personally like the generic approach and previously had my own fork of the driver that used generics, but I'm not sure it is really the best idea for backwards compatibility. The question of what Go version to use has was raised to Tobie a few hours ago in #17, but I would imagine he'll want the driver to be as compatible as possible to allow for easier adoption in existing projects. If he okays using newer Go versions, I think it generics should 100% be used.
I've also been working on a solution to this the past couple of days and have my own solution to the issue pretty much finished. I chose to switch everything over to []byte arrays and mimic Mongo since that was brought up in #18. I also just used the native json package but unmarshalled to json.RawMessage. I'm not too sure of the performance implications of using json.RawMessage, but from a few quick searches it seemed to be relatively okay. I'm not sure if the performance would be any better or worse than what you have it you converted it away from generics.

Yeah i agree, I think there's a way to do it though, I see in some packages, something like this:

So maybe there's a way we can only expose this generic resolver, for go 18+
I hacked together my solution after posting this, I'm going to make a WIP PR, we'll see how people are feeling

Oh nice, I had no idea build flags like that existed. We should 100% have generics then and just offer other functions for older versions of Go. If you get the generic part to a good state, I would be happy to adjust some of the code I have for the older Go functions.

Yeah i was doing some digging into them now, I never thought much of it in the past, but seems simple anyway!
https://stackoverflow.com/a/38439941/15727015
So we could use your api for < go 18 and anyone >= 18 would have the option to also use the generic version :D

json.RawMessage is quite a bit more performant than unmarshalling to a *any, but way less than using jsonparser for just getting the id.
I think the Decoded field is not really necessary though, and we should probably hide the implementation details from the users

So to start, I was digging through the code, and our issue mainly stems from the fact that we need to decode the main response, to get the RPC ID for handling the callback
I was playing with this jsonparser package earlier today with something else, then I realised we might be able to use it here.
I did a simple benchmark, and the performance just to get the ID is much faster
My idea:
We can use the jsonparser, to get the id, and then we use a struct like:
type RPCRawResponse struct {
	ID       string
	Data    []byte
	Decoded *RPCResponse
}

This "response" can be passed down the channels and such to the end function and only decoded once.
On top of this, we can build a top level "QueryResolver" which uses a generic, and is an opt-in function/struct, which handles context, decoding, checking for errors etc This will take the byte version and pull information out in small pieces, we can also decode once to the final desired output struct from this, rather than Unmarshal -> get id -> Marshal -> Unmarshal -> check for errors and potentially more...
How do we feel about this? I hacked together a crappy version of this "QueryResolver" setup in my project already, but i didn't optimise or care much for code quality as i was just playing, but it's semi elegant to use

Im interested in your solution where you use db.Query[T] to get the results, can you please share your solution? Thank

So to start, I was digging through the code, and our issue mainly stems from the fact that we need to decode the main response, to get the RPC ID for handling the callback
I was playing with this jsonparser package earlier today with something else, then I realised we might be able to use it here.
I did a simple benchmark, and the performance just to get the ID is much faster
My idea:
We can use the jsonparser, to get the id, and then we use a struct like:
type RPCRawResponse struct {
	ID       string
	Data    []byte
	Decoded *RPCResponse
}

This "response" can be passed down the channels and such to the end function and only decoded once.
On top of this, we can build a top level "QueryResolver" which uses a generic, and is an opt-in function/struct, which handles context, decoding, checking for errors etc This will take the byte version and pull information out in small pieces, we can also decode once to the final desired output struct from this, rather than Unmarshal -> get id -> Marshal -> Unmarshal -> check for errors and potentially more...
How do we feel about this? I hacked together a crappy version of this "QueryResolver" setup in my project already, but i didn't optimise or care much for code quality as i was just playing, but it's semi elegant to use

Im interested in your solution where you use db.Query[T] to get the results, can you please share your solution? Thank

In the end I made it into my own lib based on the original: https://github.com/iDevelopThings/surrealdb.go.unofficial
Been a while since i touched surreal stuff, but it should still be fine to use ^^

@iDevelopThings Nice! Thank you. Have you tested performance?


Turning off suggestions

Hello , I am struggling with this issue for a long time

I don't understand how to not show that black colored box of text suggesting me what that function does even if want to search in the internet I don't  know what it's name is please help me with this also is there any way to find out what extension is showing suggestions

@WilliamAntonRohm  Sir I will be waiting for your reply

@ShivaKumar-Jadipalli -- Shivakumar, thank you for your feedback.  Are you following a particular https://learn.microsoft.com article?  Meanwhile, please consider these resources:

Ask a question or find an answer on the Microsoft Q&A page for Visual Studio.
Check the Visual Studio MSDN Forum.
Stack Overflow
Reddit

@WilliamAntonRohm  Sir thank you for helping me for most of my silly questions , I have many questions still remaining even though I have purchased visual studio developer tools course from linkedin , The question that I have posted I have researched it in many websites including  stackoverflow , chatgpt , bing copilot .. etc but still I didn't find what causing this issue

As you can see it is not even letting me type my code properly , I am sorry if I am taking much of your time but help me with this one issue and I will ask my remaining questions in microsoft Q&A .
Again thanks for your help to the newbies

https://learn.microsoft.com/en-us/answers/questions/1412708/how-to-stop-showing-function-details
thanks anna for helping me


Does elli support content-type is "application/json" for POST method?

Hi, For Post method, the payload is json format, just like:
{
   "UserId":"5",
   "Token":"b4f61c3e465847d481433d6c3ba086fb",
   "MacList":[
      {
         "Mac":"98:7B:F3:5A:61:70"
      }
   ]
}

So does elli support content-type is "application/json" for POST method?

Elli supports any content type and just gives you the body as a big binary.
If you want it to automatically be decoded, you can use a middleware to do it for you. There's one already for encoding the response (https://github.com/sthadka/elli_json) Maybe you can enhance it with a preprocess pass.


portable-ruby 3.3.5

Created by brew bump

Created with brew bump-formula-pr.

[x] resource blocks have been checked for updates.

Patch is safe to remove now.
It seems 3.3.5 has a change that throws deprecation for require "ostruct" so this might require some work in Homebrew/brew to support. Unfortunately it seems this falsely triggers for require "json" too as json indirectly depends on ostruct.

Might just hack some code to globally disable those warnings in Homebrew/brew tbh. They're useful on paper but they have caused unfixable problems given we cannot be building native extensions on the fly like upstream expect.

Will check on CI tomorrow but I think it might just be a case of replacing --disable-gems with Gem.discover_gems_on_require = false

Hmm looks like there's another 3.3.5 bug here:
Non-executables were installed to "/opt/homebrew/opt/portable-ruby/bin".
The offending files are:
  /opt/homebrew/opt/portable-ruby/bin/ri.lock
  /opt/homebrew/opt/portable-ruby/bin/bundler.lock
  /opt/homebrew/opt/portable-ruby/bin/rdoc.lock
  /opt/homebrew/opt/portable-ruby/bin/rdbg.lock
  /opt/homebrew/opt/portable-ruby/bin/bundle.lock
  /opt/homebrew/opt/portable-ruby/bin/syntax_suggest.lock
  /opt/homebrew/opt/portable-ruby/bin/erb.lock
  /opt/homebrew/opt/portable-ruby/bin/irb.lock
  /opt/homebrew/opt/portable-ruby/bin/bootsnap.lock

https://bugs.ruby-lang.org/issues/20721

Let's backport so we can get this shipped. I can take a crack at it in a bit.

Basically patched in the majority of 3.3.6 at this point but it is what it is.

Somehow pulled a masterclass and new Intel image on the newer hardware is now over 2x faster and is now nearly as fast as arm64.

@Bo98 nice work!


Atom crashes when drive connectivity is lost. Data loss without warning!

This is a very simple problem to produce and so far is 100% reproducible.,, it is also very, very annoying.
Steps to create:

Open a project file from a removable or network drive.
Modify the file
Remove/disconnect drive <-- yes, we all know this is bad/dumb, and it happens (sometimes our fault, sometimes not)
Save file (or at least try to)
Wait a few minutes (go make a sandwich), and voila! your stable data in RAM is now gone! in a brilliant flash of white! as it is announced that the text editor has stopped working... le sigh.

Expected behavior:
You try to save to a non-existent directory.
Atom realizes this is not going to work
Atom sends an error message: "The drive/directory you are attempting to save to is not available. Please save to a different location."
Atom does not crash, and your words, code, or ASCII art is still happily vibrating in active RAM.
Observed behavior:
You try to save to a non-existent directory.
No indication that drive/directory is unavailable.
Blue "changes" dot does not disappear.
Atom says nothing. <-- the crux of the issue!
A few minutes later, the window blanks to white and a windows message stating "The editor has crashed" appears. You have three choices, none will recover your data.
You feel sad.
The white screen of sadness:

Some system information:
Text Editor Atom v1.58.0
OS Name	Microsoft Windows 10 Pro for Workstations
Version	10.0.19042 Build 19042
OS Manufacturer	Microsoft Corporation
System Manufacturer	Dell Inc.
System Model	Precision 7820 Tower
System Type	x64-based PC
Processor	Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 2195 Mhz, 10 Core(s), 20 Logical Processor(s)
BIOS Version/Date	Dell Inc. 2.15.0, 9/29/2021
SMBIOS Version	3.2
Installed Physical Memory (RAM)	96.0 GB
Total Physical Memory	94.7 GB
Available Physical Memory	83.7 GB
Total Virtual Memory	183 GB
Available Virtual Memory	167 GB

Maybe this console.log should be changed? https://github.com/atom/atom/blob/10f7d454edb3d61e3c85f6be1c58122b656c295f/src/main-process/file-recovery-service.js#L30-L34
I'm not sure why this function doesn't show anything
https://github.com/atom/atom/blob/10f7d454edb3d61e3c85f6be1c58122b656c295f/src/main-process/file-recovery-service.js#L68
Could you ctrl+shift+i and see if anything happens when the file doesn't save correctly?


Account creation give error while noobaa-db pod running node is power down

Environment info

ODF 4.9 and 4.10
Platform: OCP 4.9.31

Actual behavior

account create fails with in-appropriate message when noobaa-db pod is in Init state

error: "this.begin() must be called before sending queries on this transaction'

Expected behavior

account create fails should give Appropriate message when noobaa-db pod is in Init state. like:

Cannot connect to noobaa-db pod

@nishant16 please share ODF must gather

@nishant16 , Noobaa team is awaiting on your update for 2 weeks
@madhuthorat FYI/A

@romayalon Please find the attached noobaa logs:
noobaa-logs.tar.gz
@rkomandu For this thread I used my personal mail id so I miss the notification. In the future as notified by you will use workspace mail id

@romayalon
During Account creation ,if noobaa-db pod is in terminating state and before getting the noobaa-db pod up, User create accounts, It gives us:
connection closed fcall://fcall(6i06tzc) reqid 449477@fcall://fcall(6i06tzc)

but it should also give Appropriate message  in this case

@madhuthorat FYI since Nishanth has left

@liranmauda , Any update here ?

@jackyalbo any update here ?

@rkomandu what is the bug exactly? Is this an error message from noobaa CLI?
What are the steps to reproduce?

@liranmauda , it is like doing an Error injection.. for example you could try this on a system (not sure if Minikube will be able to create this)..
If you have  a running noobaa-db pod and kill that noobaa-db and in our env it takes about 5-6 min to get into Running state from Init state. So try to create an account when the pod is in Init state and the message is posted above of what we had observed in earlier ODF releases

Hi @rkomandu
I'm trying to reproduce what you have seen.
Prerequisite:
Based on the instructions here - the steps of ‘Build images’ and ‘Deploy noobaa’.
Steps:

use the watch to see all 5 pods running (and observe the changes that we will do).
watch kubectrl get pods
create a new account:
nb account create <account-name>
kill noobaa-db-pg pod (by changing the number of replicas to 0)
kubectl edit statefulsets.apps noobaa-db-pg
under spec replicas change from 1 to 0 and save.
Wait until the noobaa-db-pg is terminated.
create a new account:
nb account create <account-name>

Actual behavior:

@rkomandu, what would you expect?

@shirady see the expected behavior section in the description

It is also relevant for the case that there is no db and we use nb db-dump.
Prerequisite:
Based on the instructions here - the steps of ‘Build images’ and ‘Deploy noobaa’.
Steps:

Use the watch to see all 5 pods running (and observe the changes that we will do).
watch kubectl get pods
Kill noobaa-db-pg pod (by changing the number of replicas to 0)
kubectl edit statefulsets.apps noobaa-db-pg
under spec replicas change from 1 to 0 and save.
Wait until the noobaa-db-pg is terminated.
Run: nb db-dump

Actual behavior:
Exiting without explaining to the user that the cause was that we could not connect to the db pod.

Expected behavior:
As suggested - print a message "cannot connect to noobaa-db pod.".


Simplify living entity stack methods

Thanks for this PR, however it seems to be quite far behind and inactive for almost a year. If you wish to keep it going please open a new PR targetting 1.17. Thanks for understanding.