Image checksum tests failing for variant=release and x64 arch

This issue is spawned by additon of b2 variant=release build jobs to AppVeyor in #46 which revealed that test/image.cpp is failing on optimised x64 only builds:
Checksum error in bgr121_basic_red_x (crc=2009802095 !=<PHONE_NUMBER>)

Here is the build https://ci.appveyor.com/project/stefanseefeld/gil/build/1.0.182-develop
This issue does not occur on Travis (GCC 5.4.1 and clang 4.2.1).
I also was not able to reproduce it locally, on Ubuntu with GCC 5.4.0.
Failing checksum test cases
Modifying test/image.cpp to skip cases with missing CRC-s:
 // Create a checksum for the given view and compare it with the reference checksum. Throw exception if different
 void checksum_image_test::check_view_impl(const rgb8c_view_t& img_view, const string& name) {
+    if (_crc_map[name] == 0)
+    {
+        cerr << "no checksum, skipping " << name << endl;
+        return;
+    }
+
     boost::crc_32_type checksum_acumulator;
     checksum_acumulator.process_bytes(img_view.row_begin(0),img_view.size()*3);

allowed to iterate over the test cases in test/gil_reference_checksums.txt (remove failing entry, run the test, repeat until all remaining cases pass) and identify the failing ones:
bgr121_basic_red_x 7f6e24e7
bgr121_basic_white_x e4aaa1d3
bgr121_views_90cw 8565efd8
bgr121_views_flipped_ud 8f7f7d00

Question: what is special about these four that optimised test program binary is calculating different checksum?

So if I understand correctly,  the boost::crc_32_type.process_bytes() function above computes ("accumulates") different numbers depending on whether you compile a release or debug variant.
That sounds like a bug in either the checksum code (relying on undefined behaviour) or the compiler (producing incorrect code during optimization). Could you try to reduce the test case, i.e. make it independent of Boost.GIL, and then submit it to the Boost.CRC library ?
I'd even argue that we should (temporarily) disable those checks, once we know the bug isn't ours.

I'm also suspicious about the crc_32_type leaving slight chance for misbehaving img_view (or compiler tripping over it) here
boost::crc_32_type checksum_acumulator;
checksum_acumulator.process_bytes(img_view.row_begin(0),img_view.size()*3);

I'll try to reduce the case during the week.

How does the checksum accelerator work ? I assume it's iterating over some sequence (of bytes ?). So it ought to be possible to pre-process the data, such that the input to the process_bytes function doesn't have to be an image, but raw data, thereby removing the test's dependency on Boost.GIL.
That would result in a "minimal" test case (one only depending on Boost.CRC) that (presumably, hopefully) still fails when compiled in "release" mode. At that point we could hand it over to the Boost.CRC issue tracker and let them deal with the issue.

image_crc_minimal runs series of test cases with NxN images where N = {2, 3, 4, ..., N+1} each time performs 3 steps:

create empty NxN image
fill image with red

calculate CRC

draw blue line diagonal

calculate CRC

Bug: For VS2017 64-bit optimised build, the blue line step seems to truncate or damage the image in memory (see screenshot below).
Source of the program that runs this minimal 'fuzz' testing above:
D:\dev\boost-gil-workshop\crc (image-crc-bug-test)
λ cat image_crc_minimal.cpp
#define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE
#ifdef _MSC_VER
#pragma warning(disable:4244)
#pragma warning(disable:4503)
#pragma warning(disable:4714)
#pragma warning(disable:4996)
#endif
#include <filesystem>
#include <fstream>
#include <iostream>
#include <string>
#include <vector>
#include <boost/algorithm/hex.hpp>
#include <boost/crc.hpp>
#include <boost/gil/gil_all.hpp>
#include <boost/gil/extension/dynamic_image/dynamic_image_all.hpp>
#include <boost/mpl/vector.hpp>
using namespace std;
using namespace boost::gil;
namespace fs = std::experimental::filesystem;

struct image_test
{
    std::ostream& log_;
    image_test(std::ostream& os) : log_(os) {}

    void print_checksum(const rgb8c_view_t& img_view, const string& name)
    {
        boost::crc_32_type checksum_acumulator;
        checksum_acumulator.process_bytes(img_view.row_begin(0), img_view.size() * 3);
        cerr << "Checksum (" << name << "):\t\t" << std::hex << checksum_acumulator.checksum() << endl;
        log_ << "Checksum (" << name << "):\t\t" << std::hex << checksum_acumulator.checksum() << endl;
    }

    void print_view_hex(const rgb8c_view_t& img_view)
    {
        auto const raw_size = img_view.size() * 3;
        unsigned char const* raw_ptr = &img_view[0][0];
        std::vector<unsigned char> raw(raw_ptr, raw_ptr + raw_size);
        std::string out(raw_size * 2, char{0});
        boost::algorithm::hex(raw, out.begin());
        log_ << out << endl;
    }

    template <typename View>
    void check_view(const View& img_view, const string& name)
    {
        rgb8_image_t rgb_img(img_view.dimensions());
        copy_and_convert_pixels(img_view, view(rgb_img));
        print_checksum(const_view(rgb_img), name);
        print_view_hex(const_view(rgb_img));
    }

    template <typename Img>
    void basic_test(typename Img::point_t const& dims)
    {
        using view_value_t = typename Img::view_t::value_type;

        // make empty image
        Img img(dims);
        auto const& img_view = view(img);
        //check_view(img_view, "make"); // possibly random garbage

        // colors
        rgb8_pixel_t red8(255, 0, 0), green8(0, 255, 0), blue8(0, 0, 255), white8(255, 255, 255);
        view_value_t red, green, blue, white;
        color_convert(red8, red);
        color_convert(green8, green);
        color_convert(blue8, blue);
        color_convert(white8, white);

        // fill it with red
        fill(img_view.begin(), img_view.end(), red);
        check_view(img_view, "red  fill");

        // draw a blue line along the diagonal
        {
            auto loc = img_view.xy_at(0, img_view.height() - 1);
            for (int y = 0; y < img_view.height(); ++y)
            {
                *loc = blue;
                ++loc.x();
                loc.y()--;
            }
            check_view(img_view, "blue line");
        }
    }
};

#ifdef NDEBUG
auto const config_suffix = "opt";
#else
auto const config_suffix = "dbg";
#endif
#if defined(_WIN64) || defined(__x86_64__) || defined(__LLP64__) || (UINTPTR_MAX == 0xffffffffffffffffULL)
auto const arch_suffix = "x64";
#else
auto const arch_suffix = "x32";
#endif

int main()
{
    try
    {
        using bgr121_ref_t = const bit_aligned_pixel_reference<boost::uint8_t, boost::mpl::vector3_c<int, 1, 2, 1>, bgr_layout_t, true>;
        using bgr121_image_t = image<bgr121_ref_t, false>;
        using dims_t = bgr121_image_t::point_t;

        auto const this_path = fs::canonical(fs::path(__FILE__).parent_path());

        auto const max_dim = 8; // modify if you need
        for (int i = 2; i < max_dim + 1; i += 1)
        {
            auto const log_path = this_path / fs::path("test_");
            std::ostringstream os;
            os << log_path << i << "x" << i << "_" << arch_suffix << "_" << config_suffix << ".log";
            auto log = os.str();

            // if (i == 5) may randomly crash in opt, in gil::image<..>::deallocate

            // test
            std::ofstream ofs(log );
            std::cerr << log << std::endl;
            image_test test(ofs);
            dims_t dims(i, i);
            test.basic_test<bgr121_image_t>(dims);
        }
    }
    catch (std::runtime_error const& e)
    {
        std::cerr << e.what() << std::endl;
    }
    return 0;
}

Dobule-check comparing the calculated CRC and hex dump of the test image:

32-bit build is fine

D:\dev\boost-gil-workshop\crc (image-crc-bug-test)
λ for /L %i in (2, 1, 4) do diff -Nua test_%ix%i_x32_dbg.log test_%ix%i_x32_opt.log

diff -Nua test_2x2_x32_dbg.log test_2x2_x32_opt.log

diff -Nua test_3x3_x32_dbg.log test_3x3_x32_opt.log

diff -Nua test_4x4_x32_dbg.log test_4x4_x32_opt.log

64-bit reproduces the bug

D:\dev\boost-gil-workshop\crc (image-crc-bug-test)
λ for /L %i in (2, 1, 4) do diff -Nua test_%ix%i_x64_dbg.log test_%ix%i_x64_opt.log

diff -Nua test_2x2_x64_dbg.log test_2x2_x64_opt.log

diff -Nua test_3x3_x64_dbg.log test_3x3_x64_opt.log
--- test_3x3_x64_dbg.log        2018-03-22 17:31:24.330980200 +0100
+++ test_3x3_x64_opt.log        2018-03-22 16:16:02.111684000 +0100
@@ -1,4 +1,4 @@
 Checksum (red  fill):          23a6f403
 FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000
-Checksum (blue line):          2e4950b4
-FF0000FF00000000FFFF00000000FFFF00000000FFFF0000FF0000
+Checksum (blue line):          ff43598
+FF0000FF00000000FFFF0000FF0000FF00000000FFFF0000FF0000

diff -Nua test_4x4_x64_dbg.log test_4x4_x64_opt.log
--- test_4x4_x64_dbg.log        2018-03-22 17:31:24.357974200 +0100
+++ test_4x4_x64_opt.log        2018-03-22 16:16:02.138165400 +0100
@@ -1,4 +1,4 @@
 Checksum (red  fill):          b803c24c
 FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000
-Checksum (blue line):          7313468d
-FF0000FF0000FF00000000FFFF0000FF00000000FFFF0000FF00000000FFFF0000FF00000000FFFF0000FF0000FF0000
+Checksum (blue line):          8570c3bc
+FF00000000FFFF0000FF00000000FFFF0000FF0000FF0000FF00000000FFFF0000FF00000000FFFF0000FF0000FF0000

As you can see, the bug can be reproduced with image as small as 3x3:

I do not see clear reason to blame the boost::crc_32__type; I suspect bug in image_view<>::locator or image_view itself, of their specialisations.

Wow, excellent detective work, Dr. Watson ! :-)
What does the last screenshot above actually show ? What are the hex numbers between the lines starting with "Checksum" ? (There are two lines that differ !)
An interesting (though not necessarily important) question is whether this bug also exists on the master branch, as it doesn't seem to be related to the IO extension. (This would mean it's not a regression, and so we don't have to include it in this milestone. But then again, we are under no time pressure here, as the next Boost release to which we'd like to merge this is still half a year away...)

First, I had to update the small screenshot at the bottom.
@stefanseefeld

What are the hex numbers between the lines starting with "Checksum" ?

This is hex-encoded binary of test image

What does the last screenshot above actually show ?

Fill empty 3x3 RGB image with red

Checksum (red  fill):		23a6f403   <--- correct checksum
FF0000FF0000FF0000
FF0000FF0000FF0000
FF0000FF0000FF0000

Expected: draw blue diagonal

Checksum (blue line):		2e4950b4   <--- correct checksum
FF0000FF00000000FF
FF00000000FFFF0000
0000FFFF0000FF0000

Actual: draw blue diagonal

Checksum (blue line):		ff43598   <--- NOT correct checksum
FF0000FF00000000FF
FF0000FF0000FF0000
0000FFFF0000FF0000

Makes sense?

@stefanseefeld

An interesting (though not necessarily important) question is whether this bug also exists on the master branch, as it doesn't seem to be related to the IO extension.

There is no use of GIL IO used at all. I've just removed the confusing gil/extension/dynamic_image/dynamic_image_all.hpp. Here is full project https://github.com/mloskot/boost-gil-workshop/tree/image-crc-bug-test/crc

Unless you think you could fix the issue quickly

No idea really, it's still a cowboy shoot-out.
BTW, an interesting case is drawing blue line on blue fill: checksums match, but the x64 release crashes:

I suggest you add that test to GIL's test/ (or perhaps we should create a test/regressions/ subdirectory,
for such cases where we want to track bugs

This is a good idea, I will work out something.

Updated to Test variety of bit-aligned pixel configurations: bgr111, bgr121, bgr222, bgr232, bgr233 and the results are even more interesting.
The checksum is calculated for regular RGB8 view of the each of the five bit-aligned pixel image variations: bgr111, bgr121, bgr222, bgr232, bgr233.
On the screenshot, look how the checksum randomly changes (red marked):

ASSUMPTION:
Given plain red-coloured image, regardless of how many bits per colour in bit-aligned pixel (ie. bgr111, bgr121, bgr222, bgr232, bgr233), if viewed as regular RGB8, it should always be FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000 and the checksum should always match.
Now, let's forget about the case drawing blue diagonal and only look at the red-coloured images:

from test_3x3_x64_dbg.log (NOTICE: this is 64-bit debug build).

Checksum (bgr111: red  fill):	23a6f403   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000   OK
Checksum (bgr121: red  fill):	23a6f403   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000   OK
Checksum (bgr222: red  fill):	23a6f403   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000   OK
Checksum (bgr232: red  fill):	522cfc71   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000550000FF0000FF0000   BUG
Checksum (bgr233: red  fill):	1e81d049   <- rgb8
230000230000230000230000230000230000230000230000230000   BUG

and from test_3x3_x64_opt.log (NOTICE: this is 64-bit release build)

Checksum (bgr111: red  fill):	23a6f403   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000
Checksum (bgr121: red  fill):	23a6f403   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000
Checksum (bgr222: red  fill):	23a6f403   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000
Checksum (bgr232: red  fill):	522cfc71   <- rgb8
FF0000FF0000FF0000FF0000FF0000FF0000550000FF0000FF0000
Checksum (bgr233: red  fill):	1e81d049   <- rgb8
230000230000230000230000230000230000230000230000230000

An important observation is that both 64-bit builds, debug and release, reproduce the same erroneous result! So, it seems safe to assume the bug is NOT specific to optimised compilation for 64-bit, as I initially suspected.
I suspect, the bug is in bit_aligned_pixel_reference or collaborating parties.

Has the error only ever been observed with MSVC ? I'm trying to figure out whether it would be worth for me to have a look into it, on Linux (either gcc or clang).

I only reproduced this particular issue with MSVC.
But, enabling variant=release wtth GCC (see #50), leads to failures of gil/test/channel.cpp tests which I have not investigated yet.

Minimal Code:
#define _CRT_SECURE_NO_WARNINGS

#include <boost/gil/gil_all.hpp>
#include <boost/gil/extension/io/bmp_all.hpp>

using namespace boost::gil;

void draw_line()
{
    using ref_t = const bit_aligned_pixel_reference<boost::uint8_t, boost::mpl::vector3_c<int, 1, 2, 1>, bgr_layout_t, true>;
    using ptr_t = bit_aligned_pixel_iterator<ref_t>;
    using pixel_t =  std::iterator_traits<ptr_t>::value_type;

    using bgr121_image_t = image<ref_t, false>;

    bgr121_image_t img(100, 100);
    fill_pixels(view(img), pixel_t(0,0,1));

    auto loc = view(img).xy_at(0, view(img).height() - 1);
    for (int y = 0; y < view(img).height(); ++y)
    {
        *loc = pixel_t(1, 0, 0);
        ++loc.x();
        loc.y()--;
    }

    auto v = color_converted_view<rgb8_pixel_t>(view(img));
    write_view("img.bmp", v, bmp_tag());
}

int main()
{
    draw_line();
}

Debug:

Release:

@chhenning Thanks for this. I think it may confirm my assumption from https://github.com/boostorg/gil/issues/49#issuecomment-375383391 about bug around the locator.

Even more minimal..

#define _CRT_SECURE_NO_WARNINGS 1

#include <boost/gil/gil_all.hpp>
#include <boost/gil/extension/io/bmp_all.hpp>

using namespace boost::gil;

int main()
{
    using ref_t = const bit_aligned_pixel_reference<boost::uint8_t, boost::mpl::vector3_c<int, 1, 2, 1>, bgr_layout_t, true>;
    using ptr_t = bit_aligned_pixel_iterator<ref_t>;
    using pixel_t = std::iterator_traits<ptr_t>::value_type;

    using bgr121_image_t = image<ref_t, false>;

    //////////////////////
    // works
    //////////////////////
    {
        bgr121_image_t a(10, 10);
        fill_pixels(view(a), pixel_t(0, 0, 1));

        auto loc = view(a).xy_at(0, 0);
        for (int y = 0; y < view(a).height(); ++y)
        {
            *loc = pixel_t(1, 0, 0);

            ++loc.x();
            ++loc.y();
        }

        auto v = color_converted_view<rgb8_pixel_t>(view(a));
        write_view("a.bmp", v, bmp_tag());
    }

    //////////////////////
    // doesn't work
    //////////////////////
    {
        bgr121_image_t b(10, 10);
        fill_pixels(view(b), pixel_t(0, 0, 1));

        auto loc = view(b).xy_at(0, view(b).height() - 1);
        for (int y = 0; y < view(b).height(); ++y)
        {
            *loc = pixel_t(1, 0, 0);

            ++loc.x();
            --loc.y();
        }

        auto v = color_converted_view<rgb8_pixel_t>(view(b));
        write_view("b.bmp", v, bmp_tag());
    }
}

Running minimal_chhenning.cpp test
VS2017 x64 Release

clang 5.0 on Ubuntu 18.04 (optimised, with -fsanitizer=integer)
$ export UBSAN_OPTIONS=print_stacktrace=1
$ clang++-5.0 -std=c++11 -Wno-unused -g -fstrict-aliasing -fno-omit-frame-pointer -fsanitize=integer -I/mnt/d/boost.wsl -O2 minimal_chhenning.cpp
$ file ./a.out
./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
$ ./a.out

GCC 8 on Ubuntu 18.04 (optimised,  with -fsanitizer=undefined,  integer checks group not available for GCC)
$ export UBSAN_OPTIONS=print_stacktrace=1
g++-8 -g -std=c++11 -Wno-unused -fstrict-aliasing -fno-omit-frame-pointer -fsanitize=undefined -I/mnt/d/boost.wsl -O2 minimal_chhenning.cpp
$ file ./a.out
./a.out: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=4aeead00f767d589d784fa5fd2f2b6ac228b37f6, with debug_info, not stripped
./a.out

Conclusions

The issues are observable as:

The blue line drawn vertically instead of diagonally
The checksum test failure

The issues seem to be only reproducible with VS2017 x64 release/optimized build
The unsigned integer overflows reported by UBSan on Travis for the checksum test

boost/gil/extension/dynamic_image/../../channel_algorithm.hpp:344:64: runtime error: unsigned integer overflow:<PHONE_NUMBER> + 128 cannot be represented in type 'unsigned int'

seem to be false positives and seem unrelated to the issues discussed here.

@mloskot Do you think this is a compiler bug only with VS2017 x64? Should we try VC2015 or VS2017 x32?

@chhenning I don't want to speculate about a compiler bug, yet. I think it's more reasonable to rather look for eliminating evidence on what the issue is not caused by, than evidence proving actual cause of the problem.

Chould we try VC2015

I don't have VS2015.

or VS2017 x32?

AppVeyor covers it for both, release and debug configurations https://ci.appveyor.com/project/stefanseefeld/gil/build/1.0.397-develop

For the checksum test issue specifically, I think it may be a good idea to try different checksum than CRC. For example, refactor the test to calculate checksum based on MD5 or SHA1 or even something like GDAL simple 16-bit checksum. This could help to eliminate either issue in checksum calculation or image data access.


Adding moderators and community members

@jheretic I know we talked about a fix already in the works for the moderators, so thank you! I am definitely having trouble adding members as well.

Along with adding moderators, is there an easier way to find a moderator that then drop-down with no order in the Admin Settings > Communities? Seems like the trick is to keep typing the first letter of the name until you find the person you are looking for.

@jheretic Here’s my video journey trying to add an event, moderators, and members to the Open Reviewers community page.

I took a similar journey with Firefox and Safari.

One difference I noticed with Firefox, in the Admin settings, the names are not highlighted as you click the first letter of the first name so it was a little more difficult to find Sam's name.

I also went back through to try adding my name as the moderator and member – and nothing happens as far as I can tell including seeing email invites come through.

@murkatr Thank you so much for this super thorough video!! I'm sorry it's been frustrating to manage the communities. Just wanted to keep you posted that I'm working on this today and will let you know when you can test it on staging today!

@murkatr It took me a bit to track down the issue, but I think I found it. It's not quite fixed yet and I have to log off for today, but I'll aim to get it fixed tomorrow.

@rudietuesdays I'm not seeing communities to add the events to and I don't have Admin Settings access to create a community to test this on. Maybe @dasaderi can try?

Also, I made an example of a Community on our live site but now cannot delete it. I'm hoping this will be an option when the next updates are complete.

@rudietuesdays @murkatr I also don't have admin credentials on the dev site because I'm using your orcid sandbox account to test. :D

To clean up this issue: we CAN now add moderators and community members.
The deleting a community issue added to this thread is now a new issue here.


docs: update README

include option to set language

P.S. The change on line 109 is from my VSCode settings.

Looks good to me, I'll merge it

Looks good to me, I'll merge it


OpenXR: Requested OpenGL version does not meet the minimum version

Godot version
4.0.rc1
System information
win 11 , hp-reverb-g2
Issue description
When running a simplest VR app, this output is shown. I dont know if it is bad/good  , but as i dont know , if my app is running correct because of this output, i think its a kind of a bug :)
I use win 11, hp-reverb-g2 VR headset, wmr and steamvr set to use openxr
here the output:
--- Debugging process started ---
Godot Engine v4.0.rc.custom_build.630dd191c - https://godotengine.org
OpenXR: Running on OpenXR runtime:  SteamVR/OpenXR   0.1.0
OpenGL API 3.3.0 NVIDIA 522.06 - Compatibility - Using Device: NVIDIA Corporation - NVIDIA GeForce RTX 3080 Laptop GPU
OpenXR: Requested OpenGL version does not meet the minimum version this runtime supports.

desired_version  3.3.0
minApiVersionSupported  4.3.0
maxApiVersionSupported  4.6.0
OpenXR: Trying to initialize with OpenGL anyway...
openxr is init
--- Debugging process stopped ---

Steps to reproduce
simplest VR app with win 11 and hp-reverb-g2
Minimal reproduction project
above

Does your app run okay despite having this warning printed?
Cc @BastiaanOlij @dsnopek I guess we may need to be more lenient in the OpenXR initialization somewhere. As using a higher version than 3.3 should always be fine as every post 3.3 version is backwards compatible

It's not us setting the min/max values, we get those from the OpenXR runtime. In this case, the OpenXR runtime has reported to us that it'll only work with a minimum OpenGL version of 4.3.0 and a maximum version of 4.6.0:
minApiVersionSupported 4.3.0
maxApiVersionSupported 4.6.0

It just so happens that it usually works despite the fact that our OpenGL version (3.3.0) is outside that range. :-)
We could simply not report that? However, if we do ever encounter an OpenXR runtime that really has problems with the OpenGL version, it's min/max version would be good information to know. So, maybe we could only report that when using "verbose" output?

Indeed, we're just reporting it as the OpenXR driver specifies it. We have a number of drivers reporting they only work under Vulkan 1.0 for instance. Most XR runtimes report needing some version of OpenGL 4.x.
So far it doesn't seem to be much of a problem, we could maybe put it under a verbose print. I think it's handy for debugging purposes if we ever run into issues.

@clayjohn yes, the app is running.
i dont know if it belongs to that, but i still got this https://github.com/godotengine/godot/issues/72211 issue, which is very weird. Because sometimes e.g. a beta16 and lower versions work, but sometimes they got the same behaviour and also dont work ?

Ok, so from the feedback I have gotten, if the XR runtime reports its minimum version as 4.3.0 it expects us to run on OpenGL 4.3 or higher.
It's maximum version is more of a "it's tested up to this, use at your own risk" sort of deal.
So the fact that we're running a 3.x context is not guaranteed to work, I guess we've been lucky that it has.
@clayjohn whats holding us back from creating an OpenGL 4.x context if supported? We don't have to use any of the newer capabilities, but it does open up the option to using 4.x APIs from plugins etc.

Ok, so from the feedback I have gotten, if the XR runtime reports its minimum version as 4.3.0 it expects us to run on OpenGL 4.3 or higher. It's maximum version is more of a "it's tested up to this, use at your own risk" sort of deal.
So the fact that we're running a 3.x context is not guaranteed to work, I guess we've been lucky that it has.
@clayjohn whats holding us back from creating an OpenGL 4.x context if supported? We don't have to use any of the newer capabilities, but it does open up the option to using 4.x APIs from plugins etc.

Creating a newer context should be fine as long as it is supported. The only risk is that some drivers report support for higher versions than they actually support. So my preference would be to default to initializing to 3.3/ES 3.0 unless requested to initialize to a higher version.

I think we should leave the context alone and maybe changes these prints to verbose. It really is a diagnostics thing in case we ever run into trouble. So far this doesn't seem to have any real effect and I wager this is just a matter of XR Runtime developers playing it safe.

Welp, looks like I have a case where we do run into trouble. On linux, ALVR, pico 4, newish mesa (arch btw) I just get a black screen in the headset when using the compat renderer. The desktop view still appears ok though.
OpenXR: Running on OpenXR runtime:  SteamVR/OpenXR   2.6.2
OpenGL API 4.6 (Core Profile) Mesa 24.1.3-arch1.1 - Compatibility - Using Device: AMD - AMD Radeon RX 6800 XT (radeonsi, navi21, LLVM 18.1.8, DRM 3.57, 6.9.9-arch1-1)

OpenXR: Requested OpenGL version does not meet the minimum version this runtime supports.
- desired_version  3.3.0
- minApiVersionSupported  4.3.0
- maxApiVersionSupported  4.6.0
OpenXR: Trying to initialize with OpenGL anyway...
OpenXR: No viewport was marked with use_xr, there is no rendered output!```

I tried switching the driver to opengl_es but it couldn't start xr at all with that.

@DanielKinsman Are you using normal X11 or xwayland? I don't think Godot's OpenXR support will work through Wayland/xwayland, but I'm not sure.
Anyway, assuming you are using normal X11, can you try changing the requested OpenGL version in gl_manager_x11.cpp and see what happens?
You'd change this line:
				GLX_CONTEXT_MAJOR_VERSION_ARB, 3,

... to:
				GLX_CONTEXT_MAJOR_VERSION_ARB, 4,

If that fixes the issue, then we know it's a result of the OpenGL version thing.

I'm using wayland, it's been the default on most desktop distributions for a few years now. But I'm not using the experimental godot wayland stuff in 4.3 yet, this is just bog standard 4.2.
To test it I logged out and logged back in to an X11 session instead and got the same results.
I then branched off 4.2.2-stable and made these changes: https://github.com/DanielKinsman/godot/commit/c389e77dde211299b571378a725f2dcbc2d207ef
Using that on X11 this got rid of the version mismatch warning but still had the black screen in the headset. It gave this output on console:
Godot Engine v4.2.2.stable.custom_build.15073afe3 - https://godotengine.org
Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). Using: 0
OpenGL API 4.6 (Core Profile) Mesa 24.1.3-arch1.1 - Compatibility - Using Device: AMD - AMD Radeon RX 6800 XT (radeonsi, navi21, LL
VM 18.1.8, DRM 3.57, 6.9.9-arch1-1)

Running project: /home/daniel/scratch/glcompattest
Godot Engine v4.2.2.stable.custom_build.15073afe3 - https://godotengine.org
OpenXR: Running on OpenXR runtime:  SteamVR/OpenXR   2.6.2
Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). Using: 0
OpenGL API 4.6 (Core Profile) Mesa 24.1.3-arch1.1 - Compatibility - Using Device: AMD - AMD Radeon RX 6800 XT (radeonsi, navi21, LL
VM 18.1.8, DRM 3.57, 6.9.9-arch1-1)

ERROR: OpenXR: Unsupported toplevel path /user/eyes_ext
   at: is_top_level_path_supported (modules/openxr/openxr_api.cpp:200)
ERROR: OpenXR: Unsupported interaction profile /interaction_profiles/ext/eye_gaze_interaction
   at: is_interaction_profile_supported (modules/openxr/openxr_api.cpp:220)
OpenXR: No viewport was marked with use_xr, there is no rendered output!

So at a guess the opengl context version isn't at fault for the black screen, something else is.
On wayland it just plain crashed, giving this output:
Godot Engine v4.2.2.stable.custom_build.15073afe3 - https://godotengine.org
Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). Using: 0
OpenGL API 4.6 (Core Profile) Mesa 24.1.3-arch1.1 - Compatibility - Using Device: AMD - AMD Radeon RX 6800 XT (radeonsi, navi21, LL
VM 18.1.8, DRM 3.57, 6.9.9-arch1-1)

Running project: /home/daniel/scratch/glcompattest
Godot Engine v4.2.2.stable.custom_build.15073afe3 - https://godotengine.org
OpenXR: Running on OpenXR runtime:  SteamVR/OpenXR   2.6.2
Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). Using: 0
OpenGL API 4.6 (Core Profile) Mesa 24.1.3-arch1.1 - Compatibility - Using Device: AMD - AMD Radeon RX 6800 XT (radeonsi, navi21, LL
VM 18.1.8, DRM 3.57, 6.9.9-arch1-1)

ERROR: OpenXR: Unsupported toplevel path /user/eyes_ext
   at: is_top_level_path_supported (modules/openxr/openxr_api.cpp:200)
ERROR: OpenXR: Unsupported interaction profile /interaction_profiles/ext/eye_gaze_interaction
   at: is_interaction_profile_supported (modules/openxr/openxr_api.cpp:220)
OpenXR: No viewport was marked with use_xr, there is no rendered output!
OpenXR: No viewport was marked with use_xr, there is no rendered output!
ERROR: Caller thread can't call this function in this node (/root). Use call_deferred() or call_thread_group() instead.
   at: propagate_notification (scene/main/node.cpp:2249)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.2.2.stable.custom_build (15073afe3856abd2aa1622492fe50026c7d63dc1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x3cae0) [0x7ca5507ecae0] (??:0)
[2] /home/daniel/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x2450c8) [0x7ca5448450c8] (??:0)
[3] /home/daniel/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x1b6cba) [0x7ca5447b6cba] (??:0)
[4] /home/daniel/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x256d99) [0x7ca544856d99] (??:0)
[5] /usr/lib/libc.so.6(+0x92ded) [0x7ca550842ded] (??:0)
[6] /usr/lib/libc.so.6(+0x1160dc) [0x7ca5508c60dc] (??:0)
-- END OF BACKTRACE --
================================================================

I wouldn't be surprised if I got the same results on a quest 2 because ALVR is kind of middle manning us from the headset anyway.

@DanielKinsman Since we know your issue isn't related to the OpenGL version mismatch, we should probably move further debugging to a new issue.
However, the next to things I would try: (a) enable verbose output in your project and see if you get any more interesting errors, (b) check that you are setting get_viewport().use_xr = true in your project after initializing OpenXR (this is what this error is complaining about: OpenXR: No viewport was marked with use_xr, there is no rendered output!)

I did some more digging and spun it out here: https://github.com/godotengine/godot/issues/94455


Delayed methods with kwargs not working using ruby 3.0.0

I recently upgraded our rails app to 6.1 running on ruby 3.0.0. I have now several parts of my code failing when calling methods with keyword arguments (or named parameters) in conjunction with delay. I can reproduce the issue in the rails console:
def my_delayed_method(foo:, bar:) puts foo, bar end
=> :my_delayed_method

my_delayed_method(foo: 'foo', bar: 'bar')
foo
bar
=> nil

delay.my_delayed_method(foo: 'foo', bar: 'bar')
Traceback (most recent call last):
        2: from (irb):4:in `<main>'
        1: from (irb):1:in `my_delayed_method'
ArgumentError (wrong number of arguments (given 1, expected 0; required keywords: foo, bar))

I think this has something to do with the separation of args and kwargs introduced in ruby 2.7. Does delayed_job support ruby 3 and I am missing something? Or is this a compatibility issue?
Rails Version: 6.1.0
Ruby Version: 3.0.0
Delayed Job Version:
delayed_job_active_record (4.1.5)
delayed_job (4.1.9)

Also encountering this issue, a backtrace is provided. Looks like #1130 has some progress on this already
app/models/<removed>/image_methods.rb:35:in `update_images_and_upsert!': wrong number of arguments (given 1, expected 0) (ArgumentError)
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/performable_method.rb:26:in `perform'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/backend/base.rb:81:in `block in invoke_job'
    from vendor/bundle/ruby/3.0.0/gems/bugsnag-6.19.0/lib/bugsnag/integrations/delayed_job.rb:30:in `block (2 levels) in <class:Bugsnag>'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:79:in `block (2 levels) in add'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:61:in `block in initialize'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:79:in `block in add'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:66:in `execute'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:40:in `run_callbacks'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/backend/base.rb:78:in `invoke_job'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/worker.rb:230:in `block (2 levels) in run'
    from vendor/ruby-3.0.0/lib/ruby/3.0.0/timeout.rb:97:in `block in timeout'
    from vendor/ruby-3.0.0/lib/ruby/3.0.0/timeout.rb:107:in `timeout'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/worker.rb:230:in `block in run'
    from vendor/ruby-3.0.0/lib/ruby/3.0.0/benchmark.rb:308:in `realtime'
    [...]

Also encountering this issue, a backtrace is provided. Looks like #1130 has some progress on this already
app/models/<removed>/image_methods.rb:35:in `update_images_and_upsert!': wrong number of arguments (given 1, expected 0) (ArgumentError)
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/performable_method.rb:26:in `perform'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/backend/base.rb:81:in `block in invoke_job'
    from vendor/bundle/ruby/3.0.0/gems/bugsnag-6.19.0/lib/bugsnag/integrations/delayed_job.rb:30:in `block (2 levels) in <class:Bugsnag>'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:79:in `block (2 levels) in add'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:61:in `block in initialize'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:79:in `block in add'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:66:in `execute'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/lifecycle.rb:40:in `run_callbacks'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/backend/base.rb:78:in `invoke_job'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/worker.rb:230:in `block (2 levels) in run'
    from vendor/ruby-3.0.0/lib/ruby/3.0.0/timeout.rb:97:in `block in timeout'
    from vendor/ruby-3.0.0/lib/ruby/3.0.0/timeout.rb:107:in `timeout'
    from vendor/bundle/ruby/3.0.0/gems/delayed_job-4.1.9/lib/delayed/worker.rb:230:in `block in run'
    from vendor/ruby-3.0.0/lib/ruby/3.0.0/benchmark.rb:308:in `realtime'
    [...]

Yes, with #1130 it seems to work.

Yes, with #1130 it seems to work.

Waiting on this, as well!

@albus522 it looks like you're one of the primary caretakers of this gem. There are a couple of proposed PRs that would supposedly make DelayedJob compatible with Ruby 3. Any chance we can get your involvement to help move forward with at least one of the proposed solutions?

Hey @albus522! So sorry to bother you again. Any chance we could get your eyes on this?

Ruby 2.7 is EOL on March 31st and this is still broken which is a shame. It has been an obstacle in upgrading services to ruby 3x. There are a number of PRs addressing this issue, which can be leveraged but it would be nice to have an officially supported fix in.
https://endoflife.date/ruby

@exit-only I believe this repo is no longer maintained. Check out https://github.com/kreeti/kt-paperclip for a drop-in replacement that is being maintained.

Keyword arguments have a lot of hidden complexity to implement for a background task which is why background job libraries are opting not to support them. This is not a ruby 2.7 compatibility thing. It is a complex ongoing support thing.
I don't expect Delayed Job will be adding support for this.

ok good to know. thanks!

Well, this is a sad discovery during an upgrade process. I'd like to learn more about other the other bg job libraries that are having issues or the specific issues in delayed_job. Having a bg job library not support kwargs isn't stellar for developer experience.
Also, it seems Betterment's delayed gem has taken up the torch and supports kwargs for those who don't want to revert to positional args.
In any case, much gratitude to the delayed_job contribs, we've relied on this library for a long time. Thank you :)

It has never been fixed @brettchalupa


feat(pixels): add my new pixel

Checklist

[x ] I ran npm test locally and it passed without errors.

[ x] I only edited the _data/pixels.json file.

[ x] I entered the username in the pixels.json that I'm also using to create this pull request.
[ x] I acknowledge that all my contributions will be made under the project's license.

Hi @dkundel. Sorry I did not realize all these changes where saved. I was a little confused at first so I must have left these changes without realizing. Now I wanna know how I can fix this because I not sure where the original position of the pixel I changed was.


Add null: false to all timestamps.

Seems like the default null: false condition for timestamps was lost at some point. If you run migrations in master, the schema.rb file loses all of the NOT NULL statements for timestamp fields. Explicitly stating it in the migrations should help us avoid churn in the schema.rb in the future.

Thank you!
The changes to schema.rb are a bit concerning, but that's a delayed_job bug. In the end, delayed_job is fully responsible for managing its objects, so we shouldn't care too much about having the schema be one way or another.


Add GCC 8 support

closes https://github.com/bincrafters/community/issues/327

After to merger this version, we will have outdated packages on Bintray, the old ones that don't have fPIC option.


Adds missing cheese.

Forgot to mention that I had to add these files to build the app. I'm not sure if these resources are actually being used, so perhaps removing their references and the containing class is the better solution.

Thanks for that Pull request (I will remove the references, which is the
better solution).
Who moved the cheese?
On Thu, Aug 27, 2015 at 10:19 AM, troyjperales<EMAIL_ADDRESS>wrote:

Forgot to mention that I had to add these files to build the app. I'm not
sure if these resources are actually being used, so perhaps removing their
references and the containing class is the better solution.
You can view, comment on, or merge this pull request online at:
https://github.com/mwolfson/android-historian/pull/1
Commit Summary

Adds missing cheese.

File Changes

A app/src/main/res/drawable-nodpi/cheese_1.jpg
https://github.com/mwolfson/android-historian/pull/1/files#diff-0
(0)
A app/src/main/res/drawable-nodpi/cheese_2.jpg
https://github.com/mwolfson/android-historian/pull/1/files#diff-1
(0)
A app/src/main/res/drawable-nodpi/cheese_3.jpg
https://github.com/mwolfson/android-historian/pull/1/files#diff-2
(0)
A app/src/main/res/drawable-nodpi/cheese_4.jpg
https://github.com/mwolfson/android-historian/pull/1/files#diff-3
(0)
A app/src/main/res/drawable-nodpi/cheese_5.jpg
https://github.com/mwolfson/android-historian/pull/1/files#diff-4
(0)

Patch Links:

https://github.com/mwolfson/android-historian/pull/1.patch
https://github.com/mwolfson/android-historian/pull/1.diff

—
Reply to this email directly or view it on GitHub
https://github.com/mwolfson/android-historian/pull/1.

--

Mike Wolfson                                                      Phoenix,
AZ, USA

Sounds good.


Update README.md

From CEO Atlassian.  Updating based on latest information
Adds the following events or companies:

Atlassian

Checklist

[x] I have updated the event or company counts
[x] I have put the most recent relevant date in the "Last Update" column
[x] I have linked to the article about the change, not the company's website

Hi there! We recently re-worked the site to use yaml data files. We'd be happy to accept your PR once it's been reworked to use the right format.
Thanks!


{x:Static} does not work for internal members in the same assembly.

See AvaloniaUI/Avalonia#16929. According to @maxkatz6, {x:Static} should work on internal members if those members are in the same assembly. However, XamlX fails because it requires everything to be public:
https://github.com/kekekeks/XamlX/blob/7b8f6099a1c2240b9fa5bbf7a8a6954e99c4e556/src/XamlX/Ast/Intrinsics.cs#L116-L118

It should be a relatively simple fix + one unit test for anybody, who has time to take a look.
Once XamlX changes are merged, we can get it upstream in Avalonia.

This has been more complicated than expected. I've implemented the feature locally (for static fields so far) and I've come across two problems:

trying to test by adding another TestCase here:

https://github.com/kekekeks/XamlX/blob/master/tests/XamlParserTests/IntrinsicsTests.cs#L89-L108
I've modified IntrinsicsTestsClass to include an internal static field which results in this exception:
System.FieldAccessException : Attempt by method 'TestXaml.88acbed1e31b4312990250a1e2bea46b.Populate(System.IServiceProvider, XamlParserTests.IntrinsicsTestsClass)' to access field 'XamlParserTests.IntrinsicsTestsClass.StaticInternalField' failed.
I suspect the issue is the .NET runtime failing because the type is within the test assembly (eg. CecilTests) and not the generated XAML assembly (TestAsm). Is there a straightforward way to include a class in the generated assembly?

There's a plumbing problem to ensure we're not fetching internal members from an external assembly. However, the call site at Intrinsics appears to lack knowledge of what assembly the XAML file will be in.

I suspect the issue is the .NET runtime failing because the type is within the test assembly (eg. CecilTests) and not the generated XAML assembly (TestAsm).

For testing purposes, you can try to inject IgnoresAccessChecksTo attribute in the generated assembly.
We actually do that for Avalonia https://github.com/AvaloniaUI/Avalonia/blob/dccaea61a69280e7a91078ca089b9603f3fe6200/src/Markup/Avalonia.Markup.Xaml.Loader/AvaloniaXamlIlRuntimeCompiler.cs#L125
Ideally, it should only be limited by testing assemblies here.


[UPDATE] Moving Vimari to a new maintainer

Hi All,
I started Vimari because I wanted to build something both for myself and the community, and have really enjoyed working on this extension as well as seeing so many people contribute and be a part of the project.
As is so often the case with these projects, other commitments have caught up with me and I dont have the personal capacity to continue maintaining this project (the truth is I have not done much on this project for a while).  I am very humbled to see so many people care about this project, and continue to contribute in a number of ways.
I really want to see Vimari continue, and @danielcompton reached out to me recently offering to take over the project.  I have agreed to hand over the project to Daniel based on the following conditions:

Vimari should remain free and open source

The code should remain available on Github

All contributors over the years should be credited as developers of the software

I believe that this will be the best path for Vimari, and will enable to the project to continue with the strong community that has developed around it.
I will leave this issue up for 24 hours until I complete the transfer to provide a forum for any further comments.
Finally, I would like to personally thank everyone that has contributed to Vimari over the last few years.
Thanks!
Guy

Thanks Guy! Looking forward to getting a release out into the Mac App Store. My plan is to get this done before Catalina is released 🤞.


Define rule: At least one response code should be enabled

Created in wrong area. Should be in DDF-CORE-POC


Different color for comments

The color for comments is very similar to the color of the line numbers of changed lines.
The color of the lines number is controlled by the VCS (git) and can be dark grey, green for added lines and orange for changed lines.
When you have a block, that was changed (or added, sometimes, git marks lines as changed, even if they are new) it has a quite different sight as a new added comment or a unchanged comment.
You have to decide if you want to change it, but in my view, it would enhance the readability a bit more.
I really like this theme, because of its simplicity. Thank you

Could you post some screenshots? It could be that minimal-syntax and your ui theme are in conflict here.

Here are two example screenshots from assembly and php

The appearance of the line numbers doesn't change, when I change the UI theme (btw, it is One Light).
I took a look inside this theme and found this: https://github.com/burodepeper/minimal-syntax/blob/6bcf647c9ba43cd01cfcfac37661dec2ae7974d2/styles/editor.less#L120-L129
So it is by design so, that this theme uses the same color for comments as well as for changed lines. I would like to have another color for comments to not get confused, but this is completely up to you.
Decide how you want to have this, I only wanted to point this out and discuss about it

Now I did, I will customize it for myself.
Thanks for the support


9k Tickets / day

Hi, I'm new here and I have a question about the "Hall of Fame"
It shows that the best farmer gets 9k Tickets per day, but how is this possible with using only one account?

Hello,
By letting your PC connected on this farm all day long (24 hours obviously), you will earn 20 tickets every 780sec (13min) plus 20 extra tickets every hour.
So for a complete day we have : 2024+20((246060)/780)=2695 tickets
You're right maybe there's a problem that I didn't noticed.
He might be using multi-account, but I don't believe it can be possible. It can be explained by the fact that a bug is loading the farm two more times when the farm has loaded, instead of the special GitHub buttons.
Anyway, next update I will focus on stats to make it more reliable & more complete.
Thanks for your support.

hey, i'm new here, how exactly does this farm work? when i left it running i saw no changes to my tickets, and in the console i got these error messages im not sure its working, they are all only syntax errors :
(program):58 Syntax error @ "RewardsGG Farm"! ########################## JSHINT output: script: (W030) Expected an assignment or function call and instead saw an expression on line: 1 at character: 1 script: (W033) Missing semicolon on line: 1 at character: 5 script: (W030) Expected an assignment or function call and instead saw an expression on line: 1 at character: 6 script: (W033) Missing semicolon on line: 1 at character: 8 script: (W030) Expected an assignment or function call and instead saw an expression on line: 1 at character: 9 script: (W033) Missing semicolon on line: 1 at character: 16 script: (W030) Expected an assignment or function call and instead saw an expression on line: 2 at character: 1 script: (W033) Missing semicolon on line: 2 at character: 9 script: (W030) Expected an assignment or function call and instead saw an expression on line: 2 at character: 10 script: (W033) Missing semicolon on line: 2 at character: 14 script: (W030) Expected an assignment or function call and instead saw an expression on line: 2 at character: 15 script: (W033) Missing semicolon on line: 2 at character: 21 script: (W030) Expected an assignment or function call and instead saw an expression on line: 2 at character: 22 script: (W033) Missing semicolon on line: 2 at character: 30 script: (W030) Expected an assignment or function call and instead saw an expression on line: 2 at character: 31 script: (W033) Missing semicolon on line: 2 at character: 38 script: (W030) Expected an assignment or function call and instead saw an expression on line: 3 at character: 1 script: (W033) Missing semicolon on line: 3 at character: 5 script: (W030) Expected an assignment or function call and instead saw an expression on line: 3 at character: 6 script: (W033) Missing semicolon on line: 3 at character: 12 script: (W030) Expected an assignment or function call and instead saw an expression on line: 3 at character: 13 script: (W033) Missing semicolon on line: 3 at character: 33 script: (W030) Expected an assignment or function call and instead saw an expression on line: 4 at character: 1 script: (W033) Missing semicolon on line: 4 at character: 5 script: (W030) Expected an assignment or function call and instead saw an expression on line: 4 at character: 6 script: (W033) Missing semicolon on line: 4 at character: 16 script: (W030) Expected an assignment or function call and instead saw an expression on line: 5 at character: 1 script: (W033) Missing semicolon on line: 5 at character: 7 script: (W030) Expected an assignment or function call and instead saw an expression on line: 6 at character: 2 script: (W033) Missing semicolon on line: 6 at character: 7 script: (W030) Expected an assignment or function call and instead saw an expression on line: 6 at character: 8 script: (W033) Missing semicolon on line: 6 at character: 9 script: (W030) Expected an assignment or function call and instead saw an expression on line: 6 at character: 11 script: (W033) Missing semicolon on line: 6 at character: 15 script: (W030) Expected an assignment or function call and instead saw an expression on line: 6 at character: 16 script: (W033) Missing semicolon on line: 6 at character: 18 script: (W030) Expected an assignment or function call and instead saw an expression on line: 6 at character: 20 script: (W033) Missing semicolon on line: 6 at character: 24 script: (W030) Expected an assignment or function call and instead saw an expression on line: 6 at character: 25


GERONIMO-6844 - Migrate to Jakarta Namespace

Hi all,
don't know, what the future will be, but I did switch from Javax to Jakarta namespace (for EE10)  and updated the related spec versions. I don't know, what the plan for Geronimo provided spec jars will be, so for now, I switched to the API jars provided by the eclipse foundation.
Did switch to 4.0.0-SNAPSHOT to indicate namespace switch; would be neat to switch to Java 11 but that seems to be blocked by the Genesis parent, so likely there is the need for a Java 11 parent?
I also didn't run the sigtests / tcks yet, still fiddling around on how to set them up locally and don't know, what the general status for them looks like.
Changes between EE9 to EE10 are (at a first glance) pretty minor for these two

https://jakarta.ee/specifications/connectors/2.1/
https://jakarta.ee/specifications/transactions/2.0/

But any thoughts / ideas are welcome.

Genesis Parent: https://issues.apache.org/jira/browse/GERONIMO-6845

As mentionned in the ticket think we don't need GERONIMO-6845, however we need to validate we use jakarta artifact and complete the migration of spec jars before being able to merge the change.
Except the slf4j and this "move task" +1 from me once they are both done.

As mentionned in the ticket think we don't need GERONIMO-6845, however we need to validate we use jakarta artifact and complete the migration of spec jars before being able to merge the change.

I am fine with either using the java11 flava thing or apache-parent directly. Whatever the project wants to use.
Yup - there is an ongoing discussion on the list regarding the spec jars, if I remember correctly.


UI | Longer entity names are not shown on Explore All Activity Page

Affected module
Does it impact the UI, backend or Ingestion Framework?
UI
Describe the bug
A clear and concise description of what the bug is.
Longer entity names are not shown on Explore All Activity Page but instead show up as ... and a hover revels the entity name
To Reproduce

Have an entity with a really long name
Update entity metadata (maybe add a new column)
Run OM metadata ingestion and check for the Entity Activity on the Explore All Activity Page

Screenshots or steps to reproduce

Expected behavior
A clear and concise description of what you expected to happen.
Display the table name instead of ...
Version:

OS: [e.g. iOS]
Python version:
OpenMetadata version: [e.g. 0.8]: 0.11.5
OpenMetadata Ingestion package version: [e.g. openmetadata-ingestion[docker]==XYZ]

Additional context
Add any other context about the problem here.

Fixed in 0.12.0


Request relations

Is there an existing issue for this?

[X] I have searched the existing issues

What kind of idea is it?
New page on SuperOfficeDocs
Who is it for?
User (Learn), Administrator
Which area (SuperOffice entity) is this related to?
Request
Description
Upcoming feature

Feature re-prioritized in roadmap.

Closing this issue for now since the feature is not planned.


Bugfixes

Testsuite passed
No test results found.

That was an automated comment by Jenkins due to network issues preventing it from setting the test result as passed.


Flutter Package

Is there a Flutter pub package for this project?

Hi @Doetheman , there is not. I think the usage for Flutter projects is fairly straightforward, you can find an example here
If you think that there needs to be a package that makes the integration easier, feel free to put your suggestions here


Parsing very very tiny float.

Hello there....
I have an external API that executes some calculations and returns a result as a report. One of these results happened to be an amount that was a very very tiny one. 2.8865798640254e-15
My code that consumes the API parses this value to a Money object automatically by doing:
$money = $parser->parse((string)$amount, $currency);

I know that there is no actual currency that could represent a so tiny amount and it is practically zero (maybe in some bitcoins it have some value).
So the code above throws exception because the value is converted to a string in this form: 2.8865798640254e-15 and this does not pass the expression inside the DecimalParser. For now in order to stop getting exception I had to do a quick solution to round the number to 7 decimals and then pass it inside the parser and it feels kinda hackish.
As a better solution I could create something like a ExponentialParser and pass it inside an AggregateParser but before going into that I felt that I should ask if you believe that this should be handled by the DecimalParser and not by a different parser...
If yes maybe I could implement the changes on this PR.
For my case above I have added a test case to check it.

@gmponos I have some questions before coming to a solution.

What does that API return: a string with lots of fractional numbers or a really exponential floating point?
How is that number represented in PHP: a float or a string?
If it is a float, is it bigger than the constant PHP_FLOAT_MAX  (constant available since PHP 7.2)?

And maybe you can try this one in the meanwhile.
use Money\Number;
$money = $parser->parse((string)Number::fromNumber($amount), $currency);

Hello, basically most of the questions can be answered through the test case that I have added.
On the test case I just simulated the same thing as my App is doing but let's take it from the top and answer your questions just to be specific here:

It returns it as exponential.
it is represented as a float. check the test.
I guess not because PHP_FLOAT_MIN is 2.2250738585072e-308 and I just have e-15

I will give a try to the Number but never the less should this be inside the DecimalParser?

Any idea how this should be handled after all?

Closed in favour of #520.


Add the overlay permission information

If your current android application is targeting the android api level 23 or greater, displaying the error view will cause a crash in the application. The crash only shows that the system cannot display the view.

@JoelMarcey, PR updated, please let me know WDYT.

PR Open for fixing the Overlay ^^ #11316


feat: update the latest version when releasing formal version

What type of PR is this?
/kind feature
What this PR does / why we need it:
Update the latest version when releasing formal version.

Already tested in the fork repo, https://github.com/healthjyk/kusion/actions/runs/7335920393

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
10 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.04%) to 75.056%

Files with Coverage Reduction
New Missed Lines
%

pkg/engine/operation/parser/parser.go
3
79.27%

pkg/cmd/apply/options.go
7
71.94%

Totals

Change from base Build<PHONE_NUMBER>:
0.04%

Covered Lines:
7712

Relevant Lines:
10275

💛  - Coveralls


sdrangel: 7.18.1 -> 7.19.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/f4exb/sdrangel/releases.
meta.description for sdrangel is: Software defined radio (SDR) software
meta.homepage for sdrangel is: https://github.com/f4exb/sdrangel
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 7.19.0 with grep in /nix/store/4p496qcagnvd0wpbgn2vfrpscq3j6kh4-sdrangel-7.19.0
found 7.19.0 in filename of file in /nix/store/4p496qcagnvd0wpbgn2vfrpscq3j6kh4-sdrangel-7.19.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
sdrangel

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/4p496qcagnvd0wpbgn2vfrpscq3j6kh4-sdrangel-7.19.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A sdrangel https://github.com/r-ryantm/nixpkgs/archive/08bfbc64debfb6784e6f80c326915dfc04ef7fa2.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/08bfbc64debfb6784e6f80c326915dfc04ef7fa2#sdrangel

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/4p496qcagnvd0wpbgn2vfrpscq3j6kh4-sdrangel-7.19.0
ls -la /nix/store/4p496qcagnvd0wpbgn2vfrpscq3j6kh4-sdrangel-7.19.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

sdrangel

Maintainer pings
cc @alkeryn @Tungsten842 for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/f4exb/sdrangel/releases.
meta.description for sdrangel is: Software defined radio (SDR) software
meta.homepage for sdrangel is: https://github.com/f4exb/sdrangel
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 7.19.1 with grep in /nix/store/ypyyx6g93b7qndg77y4ypkjdwagvqixa-sdrangel-7.19.1
found 7.19.1 in filename of file in /nix/store/ypyyx6g93b7qndg77y4ypkjdwagvqixa-sdrangel-7.19.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
sdrangel

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ypyyx6g93b7qndg77y4ypkjdwagvqixa-sdrangel-7.19.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A sdrangel https://github.com/r-ryantm/nixpkgs/archive/0f216d8d7167b2edaaab024b0e7fadba0ffd4395.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/0f216d8d7167b2edaaab024b0e7fadba0ffd4395#sdrangel

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ypyyx6g93b7qndg77y4ypkjdwagvqixa-sdrangel-7.19.1
ls -la /nix/store/ypyyx6g93b7qndg77y4ypkjdwagvqixa-sdrangel-7.19.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

sdrangel

Maintainer pings
cc @alkeryn @Tungsten842 for testing.

darwin x86 failure is expected https://hydra.nixos.org/build/253843216
aarch64 error seems like a ofborg error


Rename __underscore_modules (and parent elements)

Is your feature request related to a problem? Please describe.
I have noticed that it will be rather common to refer to the __underscore_modules that correspond to syntactic constructs like # headings and $$math$$ in configs for example:
[config]
import std:html hiding __document, __math, __heading
import pkgs:better_html

So, maybe we should rename these modules to just document and heading etc. to make it a bit easier to read for users.
(Note: this will cause a conflict with the math module but maybe we can rename that to something else, equation perhaps?)

I think it would be better to prefix tags with tag., such as tag.math, tag.bold etc. This would clearly show that transforms are tags and what aren't, would reduce the risk of someone seeing "Oh, there is something called bold, let's try that module", try the module and get a very troubling result (related to #208), and would not use up names that may be wanted for modules for words that can't be used in the document itself (like, if we claim math for the tag, we need to rename the math module, but for the user it seems strange that math is just a reserved name that can't be used by modules even though math can't be used as a keyword anywhere in the document itself). Additionally, I think [math] looks cleaner than [equation], so I think it should be as-is.

Comments from discussion: Maybe opt for a kebab-case naming convention throughout the entire language (with the exception of when we read env_which have to be on the form of list_ident).


Clean up token page when no data

closes #232
closes #209

I'm having a hard time testing this, cause something on main seems to blow up when I go to Tokens page --

I'll have a looksie and see if I can spot the issue
(Side note, my screen goes black and I can't navigate anywhere when that happens, can we prevent that type of thing from happening somehow?)

mmm, I think it's related to the ~100 errors we see with npm exec tsc directly, which is known issue from vite port iirc? do we have something to track that anywhere?

Do our existing tsc commands in npm run lint even do anything anymore?

The problem is that npx run tsc isn't accurate because there is a tsconfig.json sitting inside of the renderer directory. I think this can be resolved by adding **.* to "include" in that json file, but yea running tsc directly will use the root tsconfig which isn't accurate.

The problem is that npx run tsc isn't accurate because there is a tsconfig.json sitting inside of the renderer directory. I think this can be resolved by adding *. to "include" in that json file, but yea running tsc directly will use the root tsconfig which isn't accurate.

I don't follow you. It isn't accurate how?  And the main and renderer tsconfigs look like they link back to the root one using "extends": "../../tsconfig.json".

oh yay, frustrating.

@nathanleclaire so I get the
MetaplexTokenData.tsx:29 Uncaught TypeError: Cannot read properties of undefined (reading 'toString')
    at DataPopover (MetaplexTokenData.tsx:29:29)
    at MetaplexTokenDataButton (MetaplexTokenData.tsx:214:16)

crash on the tokens page in origin/main at the moment - and not with this PR's branch (I get a totally different one now :(

Yea same when I tested, seems to be a problem on main.
Got distracted w/ the TS errors, but we should just wait until after 0.4.0 to chip away at those.

ok, made https://github.com/workbenchapp/solana-workbench/pull/247 for that

no this is holding up too many other things. merging.


Junit test results publish with multiple failure nodes

Description: There are JUnit result files which may have multiple failure and error nodes for a test case. TestResult publishing task was failing with testCaseNode.failure.attributes() is not a function for these result files.
Fix: Handled the case with multiple failure nodes and publishing the first node.
Testing: Manual

approved with comments

task version should be bumped up too?
Add the right test cases
Approved - as long as all comments are addressed

Task Version doesn't need to be bumped up. Test added for the new format.


FIX [doc] Typo in README.md

Ah, I have completely overlooked that the underscore is in .md file. I am sorry. If you resubmit PR, I will merge it. I cannot do it with this one as you already removed the repository.

No worries. I'm working on a new commit.


Neovide crashing on Windows.

I just installed Neovim 0.5 nightly and then suddenly neovide starts crashing (but when i run nvim or nvim-qt, nvim works.). I tried reinstalling but it didnt work.


Cpoolsunited is a collaboration of small stake pool operators, not a multi pool operation

https://www.cpoolsunited.com/
consists of several small stake pool operators that share some of the relays in order to curb the high price of the operation while doing minimal blocks.
The collaboration uses CPU profits to pay for the shared relays, the rest we are donating, so it's a non-profit pool
Shouldn't the pools in collaboration be listed as single pool operators?

here's a ticket for the issue, initially opened in eternl browser support discord

Shouldn't the pools in collaboration be listed as single pool operators?

Since the relay is a single point of failure for all operators who use it, imo no, they shouldn't.

Since the relay is a single point of failure for all operators who use it, imo no, they shouldn't.

some of us have custom relays, alongside shared relays, so that removes the "single point of failure"
Also this is hurting us, most people want single pool operators, now you are punishing small pools that would be dead months/years ago, if it weren't for relay sharing and colaboration.
There's also some multi pool operations that use different relays, from my understanding, we do not give information about multi pools so the user knows there's a single point of faulure, but that to inform the user that this user made multiple pools..

The rules for listing are clearly listed in the REaDME of the repo. Folks are free to add each other to relay via topology, if they end up registering pools with same relay - they would naturally end up with other pool clusters.

There's also some multi pool operations that use different relays, from my understanding, we do not give information about multi pools

Feel free to report any clusters missing (it's not purely based on relays, but also branding/owners/splitting/etc. The list is only as strong as community who reports missing cluster definitions.

folks are free to add each other to relay via topology
That doesn't fix the problem if the relay they use goes dark, best way is to have multiple relays registered and each connected to different topology, isn't it?

I understand what you are trying to explain, cpoolsunited was envisioned to help the small pool operation with relay, knowledge etc. sharing, but now IMO, it's hurting pool operators because the people think there's only one owner for all these pools.
Is there any possibility that we get the status of single pool operators? The pool i run, has bare metal relay, alongside collaboration relays, would that qualify it to go to single pool stack?
Wallets like eternl use this data, and this way, the end user gets the wrong information, based on that, he/she will make his/her decisions accordingly.
Either way, thank you for the information

Sorry, but the whole point of this repo is to simplify and not get into perceptions, I think adding special cases where folks share relays or branding/alliances-marketed-together will not only complicate flows, but also start into word-play negotiations, etc. If you want to split pools to be single pool operators, the considerations are as per README in root of the repo. Apologies if this is not as per your preference/perceptions , but hope you can see the background behind reasoning 🙏🏻

Although I don't necessarily agree fully, I understand completely.
The idea was to help small pool operators, but now, we are harming them, because they are labeled as multi-pool owners...
It is what it is, Thank you for taking your time and giving a detailed explanation :)

Since the relay is a single point of failure for all operators who use it, imo no, they shouldn't.

@rdlrt  could you, at least put my pool as a single pool operator, considering I do not share all the relays with the team, I have my own, 1 bare metal relay that's registered only to my pool.
Pool is |VENUS| Fresco pool
And i will tell the team, if they want to get the status of single pool operator, that they need to have at least 1 independent relay


Add streaming ASR with Emformer RNN-T

I have tested it and it works. Will upload a pretrained Emformer model later.
Note that the framework is quite general and it is easy to adapt to other kinds of stateless RNN-T models, not limited to Emformer RNN-T models.

Wow, Cool! Once you merge this PR, I will try to add streaming conformer model.

Here is a demo for this PR: https://www.youtube.com/watch?v=z7HgaZv5W0U


Not able to enter nix-shell for cardano-config or cardano-node

On the master branch:
[nix-shell:~/NewProjects/cardano-node]$ cabal -v v2-repl  cardano-config
Project settings changed, reconfiguring...
creating /home/chris/NewProjects/cardano-node/dist-newstyle
creating /home/chris/NewProjects/cardano-node/dist-newstyle/cache
/run/current-system/sw/bin/git --version
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'http://github.com/well-typed/canonical-json' /home/chris/NewProjects/cardano-node/dist-newstyle/src/canonical_-1f90751276f12f5a
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/canonical_-1f90751276f12f5a'...
warning: redirecting to https://github.com/well-typed/canonical-json/
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 130 (delta 0), reused 1 (delta 0), pack-reused 126
Receiving objects: 100% (130/130), 582.22 KiB | 1.32 MiB/s, done.
Resolving deltas: 100% (51/51), done.
/run/current-system/sw/bin/git checkout --detach --force ddfe3593b80b5ceb88842bb7a6f2268df75d2c2f --
HEAD is now at ddfe359 Switch the parsec parser from [Char] to ByteString
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/CodiePP/ekg-prometheus-adapter' /home/chris/NewProjects/cardano-node/dist-newstyle/src/ekg-prome_-90de1e9967920c0b
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/ekg-prome_-90de1e9967920c0b'...
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 84 (delta 3), reused 12 (delta 2), pack-reused 70
Unpacking objects: 100% (84/84), done.
/run/current-system/sw/bin/git checkout --detach --force 1a258b6df7d9807d4c4ff3e99722223d31a2c320 --
HEAD is now at 1a258b6 bump version number
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/cardano-base' /home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-b_-c97d51a3264adedf
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-b_-c97d51a3264adedf'...
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 947 (delta 6), reused 16 (delta 5), pack-reused 923
Receiving objects: 100% (947/947), 226.33 KiB | 460.00 KiB/s, done.
Resolving deltas: 100% (483/483), done.
/run/current-system/sw/bin/git checkout --detach --force 80deee31f8d9422b8e090e55b17e1a714153180b --
HEAD is now at 80deee3 Add `Serialise` instance for `WithOrigin`. (#63)
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/cardano-crypto' /home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-c_-613c120a593cd275
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-c_-613c120a593cd275'...
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 1430 (delta 1), reused 5 (delta 1), pack-reused 1422
Receiving objects: 100% (1430/1430), 452.56 KiB | 1.06 MiB/s, done.
Resolving deltas: 100% (607/607), done.
/run/current-system/sw/bin/git checkout --detach --force 4590efa638397e952a51a8994b5543e4ea3c1ecd --
HEAD is now at 4590efa Merge pull request #59 from erikd/erikd/stack-update
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/cardano-ledger' /home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-l_-eee106153f3e350d
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-l_-eee106153f3e350d'...
remote: Enumerating objects: 582, done.
remote: Counting objects: 100% (582/582), done.
remote: Compressing objects: 100% (221/221), done.
remote: Total 12803 (delta 321), reused 471 (delta 278), pack-reused 12221
Receiving objects: 100% (12803/12803), 3.65 MiB | 1.95 MiB/s, done.
Resolving deltas: 100% (7735/7735), done.
/run/current-system/sw/bin/git checkout --detach --force a773ba71eb9a6fb91dda2cdf6c41b2280f2acf7d --
HEAD is now at a773ba7 Merge #691
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/cardano-ledger-specs' /home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-l_-afc0f56298b7d554
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-l_-afc0f56298b7d554'...
remote: Enumerating objects: 556, done.
remote: Counting objects: 100% (556/556), done.
remote: Compressing objects: 100% (300/300), done.
remote: Total 17463 (delta 281), reused 442 (delta 246), pack-reused 16907
Receiving objects: 100% (17463/17463), 20.12 MiB | 2.02 MiB/s, done.
Resolving deltas: 100% (10315/10315), done.
/run/current-system/sw/bin/git checkout --detach --force f9f902091aec25d52dd3590980a9b2a8447bbcc5 --
HEAD is now at f9f90209 Merge pull request #1073 from input-output-hk/exec_spec/shelley/cbor-updates
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/cardano-prelude' /home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-p_-6616435bbe3d1976
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-p_-6616435bbe3d1976'...
remote: Enumerating objects: 112, done.
remote: Counting objects: 100% (112/112), done.
remote: Compressing objects: 100% (79/79), done.
remote: Total 1054 (delta 38), reused 71 (delta 11), pack-reused 942
Receiving objects: 100% (1054/1054), 262.01 KiB | 921.00 KiB/s, done.
Resolving deltas: 100% (454/454), done.
/run/current-system/sw/bin/git checkout --detach --force<PHONE_NUMBER>ddd10b76e50eae73f005efd2c7195c --
HEAD is now at 7099318 Merge #90
The package description file
/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-p_-6616435bbe3d1976/cardano-prelude.cabal
has warnings:
/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-p_-6616435bbe3d1976/cardano-prelude.cabal:91:3:
Unknown field: "exposed-modules"
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/cardano-shell' /home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-s_-40b8d61132c3cbd1
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-s_-40b8d61132c3cbd1'...
remote: Enumerating objects: 123, done.
remote: Counting objects: 100% (123/123), done.
remote: Compressing objects: 100% (82/82), done.
remote: Total 2160 (delta 57), reused 73 (delta 33), pack-reused 2037
Receiving objects: 100% (2160/2160), 2.36 MiB | 2.08 MiB/s, done.
Resolving deltas: 100% (1142/1142), done.
/run/current-system/sw/bin/git checkout --detach --force bc3563c952d9f3635e1c76749b86b0a24f7e4b83 --
HEAD is now at bc3563c Update CODEOWNERS (#357)
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/cardano-sl-x509' /home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-s_-c79e68d577f5acc3
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/cardano-s_-c79e68d577f5acc3'...
remote: Enumerating objects: 146, done.
remote: Total 146 (delta 0), reused 0 (delta 0), pack-reused 146
Receiving objects: 100% (146/146), 34.68 KiB | 366.00 KiB/s, done.
Resolving deltas: 100% (50/50), done.
/run/current-system/sw/bin/git checkout --detach --force 43a036c5bbe68ca2e9cbe611eab7982e2348fe49 --
HEAD is now at 43a036c Replace Universum with Cardano.Prelude
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/goblins' /home/chris/NewProjects/cardano-node/dist-newstyle/src/goblins-f4f7645a78b07334
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/goblins-f4f7645a78b07334'...
remote: Enumerating objects: 410, done.
remote: Counting objects: 100% (410/410), done.
remote: Compressing objects: 100% (181/181), done.
remote: Total 423 (delta 167), reused 395 (delta 153), pack-reused 13
Receiving objects: 100% (423/423), 119.14 KiB | 619.00 KiB/s, done.
Resolving deltas: 100% (167/167), done.
/run/current-system/sw/bin/git checkout --detach --force 26d35ad52fe9ade3391532dbfeb2f416f07650bc --
HEAD is now at 26d35ad Add SeedGoblin instance for `Maybe a`
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/iohk-monitoring-framework' /home/chris/NewProjects/cardano-node/dist-newstyle/src/iohk-moni_-c4029568d4836e27
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/iohk-moni_-c4029568d4836e27'...
remote: Enumerating objects: 134, done.
remote: Counting objects: 100% (134/134), done.
remote: Compressing objects: 100% (63/63), done.
remote: Total 7713 (delta 56), reused 98 (delta 44), pack-reused 7579
Receiving objects: 100% (7713/7713), 34.56 MiB | 1.97 MiB/s, done.
Resolving deltas: 100% (4430/4430), done.
/run/current-system/sw/bin/git checkout --detach --force 156391afaafca6b00d027fb9c03e1bd7a1f03003 --
HEAD is now at 156391a [#486][#492] Don't link STM timeout exceptions from the switchboard's thread (#493)
creating /home/chris/NewProjects/cardano-node/dist-newstyle/src
/run/current-system/sw/bin/git clone --no-checkout 'https://github.com/input-output-hk/ouroboros-network' /home/chris/NewProjects/cardano-node/dist-newstyle/src/ouroboros_-86f4da3e33dbe3ab
Cloning into '/home/chris/NewProjects/cardano-node/dist-newstyle/src/ouroboros_-86f4da3e33dbe3ab'...
remote: Enumerating objects: 419, done.
remote: Counting objects: 100% (419/419), done.
remote: Compressing objects: 100% (181/181), done.
remote: Total 35201 (delta 234), reused 335 (delta 198), pack-reused 34782
Receiving objects: 100% (35201/35201), 9.49 MiB | 1.76 MiB/s, done.
Resolving deltas: 100% (20978/20978), done.
/run/current-system/sw/bin/git checkout --detach --force cc5b89ae36da2c2584c3a633b8d75344e2e5e734 --
HEAD is now at cc5b89ae Merge #1373
this build was affected by the following (project) config files:
- /home/chris/NewProjects/cardano-node/cabal.project
Compiler settings changed, reconfiguring...
/nix/store/kb6vqx21y6q7shbasnz28cq2lmp4lzsr-ghc-shell-for-cardano-node-ghc-8.6.5/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in
/nix/store/kb6vqx21y6q7shbasnz28cq2lmp4lzsr-ghc-shell-for-cardano-node-ghc-8.6.5/bin
found ghc-pkg in
/nix/store/kb6vqx21y6q7shbasnz28cq2lmp4lzsr-ghc-shell-for-cardano-node-ghc-8.6.5/bin/ghc-pkg
/nix/store/kb6vqx21y6q7shbasnz28cq2lmp4lzsr-ghc-shell-for-cardano-node-ghc-8.6.5/bin/ghc-pkg --version
/nix/store/kb6vqx21y6q7shbasnz28cq2lmp4lzsr-ghc-shell-for-cardano-node-ghc-8.6.5/bin/ghc --supported-languages
/nix/store/kb6vqx21y6q7shbasnz28cq2lmp4lzsr-ghc-shell-for-cardano-node-ghc-8.6.5/bin/ghc --info
/nix/store/kb6vqx21y6q7shbasnz28cq2lmp4lzsr-ghc-shell-for-cardano-node-ghc-8.6.5/bin/ghc --print-global-package-db
Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
/home/chris/.nix-profile/bin/pkg-config --version
/home/chris/.nix-profile/bin/pkg-config --variable pc_path pkg-config
/home/chris/.nix-profile/bin/pkg-config --version
/home/chris/.nix-profile/bin/pkg-config --list-all
/home/chris/.nix-profile/bin/pkg-config --modversion
Failed to query pkg-config, Cabal will continue without solving for pkg-config
constraints: dieVerbatim: user error (CallStack (from HasCallStack):
die', called at ./Distribution/Simple/Program/Run.hs:155:7 in
Cabal-<IP_ADDRESS>-GbtYhBUBOSfN2j9buevYD:Distribution.Simple.Program.Run
getProgramInvocationOutput, called at ./Distribution/Simple/Program.hs:163:3
in Cabal-<IP_ADDRESS>-GbtYhBUBOSfN2j9buevYD:Distribution.Simple.Program
getProgramOutput, called at ./Distribution/Solver/Types/PkgConfigDb.hs:70:28
in main:Distribution.Solver.Types.PkgConfigDb
cabal: '/home/chris/.nix-profile/bin/pkg-config' exited with an error:
Must specify package names on the command line
)
Resolving dependencies...
CallStack (from HasCallStack):
  die', called at ./Distribution/Client/ProjectPlanning.hs:574:42 in main:Distribution.Client.ProjectPlanning
cabal: Could not resolve dependencies:
[__0] trying: cardano-sl-x509-3.0.0 (user goal)
[__1] unknown package: x509-validation (dependency of cardano-sl-x509)
[__1] fail (backjumping, conflict set: cardano-sl-x509, x509-validation)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: cardano-sl-x509 (2), x509-validation
(1)

Is this due to:
cabal: '/home/chris/.nix-profile/bin/pkg-config' exited with an error:
Must specify package names on the command line
)

perhaps?
Is there an alternative I should be using perhaps?

So can this be closed?

Just thought I'd give an update on this. It still seem to be an issue (with the latest master commit of f616c7d9a994764d3b09e241bc59c3dce95ced5f):
nix-shell
trace: Using IOHK default nixpkgs
trace: Using index-state: 2020-07-15T00:00:00Z for cardano-node-src
trace: Using index-state: 2020-07-15T00:00:00Z for cardano-node-src
trace: Using index-state: 2020-05-31T00:00:00Z for hoogle
trace: To make this a fixed-output derivation but not materialized, set `plan-sha256` to the output of /nix/store/ax206k8wgvl3mryz92k7ps445969j90c-calculateSha
trace: To materialize the output entirely, pass a writable path as the `materialized` argument and pass that path to /nix/store/4vq6zhwg0dkp9f15jgjcxyqsp62wbzm6-generateMaterialized

[nix-shell:~/NewProjects/cardano-node]$ cabal -v v2-repl  cardano-config
Project settings changed, reconfiguring...
creating /home/chris/NewProjects/cardano-node/dist-newstyle
creating /home/chris/NewProjects/cardano-node/dist-newstyle/cache
this build was affected by the following (project) config files:
- /home/chris/NewProjects/cardano-node/cabal.project
Compiler settings changed, reconfiguring...
/nix/store/1f1ig2msb19iq63vm22qrapz29mk7msn-ghc-shell-for-packages-ghc-8.6.5-env/bin/ghc --numeric-version
looking for tool ghc-pkg near compiler in
/nix/store/1f1ig2msb19iq63vm22qrapz29mk7msn-ghc-shell-for-packages-ghc-8.6.5-env/bin
found ghc-pkg in
/nix/store/1f1ig2msb19iq63vm22qrapz29mk7msn-ghc-shell-for-packages-ghc-8.6.5-env/bin/ghc-pkg
/nix/store/1f1ig2msb19iq63vm22qrapz29mk7msn-ghc-shell-for-packages-ghc-8.6.5-env/bin/ghc-pkg --version
/nix/store/1f1ig2msb19iq63vm22qrapz29mk7msn-ghc-shell-for-packages-ghc-8.6.5-env/bin/ghc --supported-languages
/nix/store/1f1ig2msb19iq63vm22qrapz29mk7msn-ghc-shell-for-packages-ghc-8.6.5-env/bin/ghc --info
/nix/store/1f1ig2msb19iq63vm22qrapz29mk7msn-ghc-shell-for-packages-ghc-8.6.5-env/bin/ghc --print-global-package-db
Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
/nix/store/9a405mh6qivk0b864d88b6hjl45rcxd6-pkg-config-0.29.2/bin/pkg-config --version
/nix/store/9a405mh6qivk0b864d88b6hjl45rcxd6-pkg-config-0.29.2/bin/pkg-config --variable pc_path pkg-config
/nix/store/9a405mh6qivk0b864d88b6hjl45rcxd6-pkg-config-0.29.2/bin/pkg-config --version
/nix/store/9a405mh6qivk0b864d88b6hjl45rcxd6-pkg-config-0.29.2/bin/pkg-config --list-all
/nix/store/9a405mh6qivk0b864d88b6hjl45rcxd6-pkg-config-0.29.2/bin/pkg-config --modversion nix-expr bdw-gc nix-store numa libsodium nix-main
Resolving dependencies...
CallStack (from HasCallStack):
  die', called at ./Distribution/Client/ProjectPlanning.hs:578:42 in main:Distribution.Client.ProjectPlanning
cabal: Could not resolve dependencies:
[__0] trying: cardano-api-1.18.0 (user goal)
[__1] next goal: serialise (dependency of cardano-api)
[__1] rejecting: serialise-<IP_ADDRESS>/installed-5VK... (package is broken)
[__1] fail (backjumping, conflict set: cardano-api, serialise)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: cardano-api (2), serialise (2)

@chrissound, the solution is as follows:

ensure an unmodified checkout
enter nix-shell
edit cabal.project to not contain any source-repository-package clauses -- this can be easily done by executing:

sed -ni '1,/--- 8< ---/ p' "$(git rev-parse --show-toplevel)"/cabal.project

cabal commands will now work.


Add options to disable KillMode from systemd

while POST_SHUTDOWN_DELAY is a thing, It would be nice to wait for the java + screen to actually exit and ensure the world was actually saved
and some people want their world saved more than anything. so I think it would be good to provide these settings at least as an option.

According to: https://www.freedesktop.org/software/systemd/man/systemd.kill.html

KillMode=none is "strongly recommended against". Also, it will not stop the server. And when the Linux server is rebooted it'll either get stuck indefinitely or the server crashes. I'm currently not sure which of these two scenarios it would cause. But neither of them is desirable.
SendSIGKILL=no doesn't disable "SIGKILL". It just disables the first "SIGTERM". Therefore it's counterproductive would just corrupt safe files.
And the exit to the run command will overwrite the exit code that java returns.


Json Miner should also work with Token-Authentication

Hello,
I have a Feed which requires Token Authentication in the Header:
curl -H "Authorization: Bearer " "https://api-url.com/api/v1/iocs?first_seen_since=2016-1-1"
As far as I know this is currently not possible?
Kind regards

Hi @idev,
you are right, this is not possible today. Two solutions:

develop an external extension subclassing minemeld.ft.json.SimpleJSON and override configure and _build_iterator methods to load a custom header from the config file and then use it in the request. Check PaloAltoNetworks/youtube-miner for an example of an external extension.
create a pull request to minemeld-core with the above logic

I have marked this as an enhancement.
Thanks,
luigi

Pull Request created in DEV Branch

PR approved, thanks !

Was there any updates on if this feature is now available ?


Even RtlGetVersion() is lied to

Despite having tested this in a standalone executable, in Windows Installer it seems we're still getting lied to:
Action start 1:14:18: VerSetVersionInfo.
MSI (c) (C8:80) [01:14:18:498]: Creating MSIHANDLE (1) of type 790542 for thread 3456
MSI (c) (C8:B8) [01:14:18:499]: Invoking remote custom action. DLL: C:\Users\heaths\AppData\Local\Temp\MSIB25C.tmp, Entrypoint: SetVersionInfo
MSI (c) (C8:1C) [01:14:18:500]: Cloaking enabled.
MSI (c) (C8:1C) [01:14:18:500]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (C8:1C) [01:14:18:500]: Connected to service for CA interface.
MSI (c) (C8!0C) [01:14:18:546]: PROPERTY CHANGE: Adding VER_WINDOWS_MAJOR property. Its value is '6'.
MSI (c) (C8!0C) [01:14:18:546]: PROPERTY CHANGE: Adding VER_WINDOWS_MINOR property. Its value is '0'.
MSI (c) (C8!0C) [01:14:18:546]: PROPERTY CHANGE: Adding VER_WINDOWS_BUILD property. Its value is '6000'.
MSI (c) (C8:B8) [01:14:18:547]: Closing MSIHANDLE (1) of type 790542 for thread 3456
Action ended 1:14:18: VerSetVersionInfo. Return value 1.

I suspect this is because msiexec.exe - both the client, service (with "/v"), and custom action host - is manifested as supporting Windows 8.1 even on Windows 11:
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
  <application>
    <!-- Windows BLUE -->
    <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
  </application>
</compatibility>

After additional testing, it appears it's not the manifest of msiexec.exe, to which I tried using it both as-is and with minor modifications to change the identity:
// main.cpp
#define _WIN32_WINNT 0x0603
#include <ntddk.h>
#include <iostream>

void main()
{
    RTL_OSVERSIONINFOW info = { sizeof(RTL_OSVERSIONINFOW) };
    auto status = RtlGetVersion(&info);
    if (status == STATUS_SUCCESS)
    {
        printf("%d.%d.%d\n", info.dwMajorVersion, info.dwMinorVersion, info.dwBuildNumber);
    }
}

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- manifest.xml -->
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <assemblyIdentity
        type="win32"
        name="main"
        version="<IP_ADDRESS>"
        processorArchitecture="amd64"
    />
    <description> Test </description>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel
                    level="asInvoker"
                    uiAccess="false"
                />
            </requestedPrivileges>
        </security>
    </trustInfo>
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <!-- Windows BLUE -->
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
        </application>
    </compatibility>
    <asmv3:application>
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
        </asmv3:windowsSettings>
    </asmv3:application>
</assembly>

cl main.cpp /I'C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\km' /D_AMD64_ /link 'C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\km\x64\ntoskrnl.lib' /MANIFEST:EMBED /MANIFESTINPUT:manifest.xml

This still outputs "10.0.22621".

@tydunkel what is VSSetup currently doing to detect Windows 10 and above, or is it? Even the newer helpers based on VerifyVersionInfo are deprecated as of Windows 10.

Presumably, custom bootstrappers like Burn could still call RtlGetVersion() and get the real value - manifested or not - but this would necessitate writing a custom bootstrapper just to appropriate version information.
Seems Burn, at least, is already doing this.
/cc @barnson


Adding LSTM for Stock Price Detection Model

I have worked on a similar project in the past and have observed that using LSTM can give better results than ARIMA for stock price detection. Please let me contribute to this as a part of GsSoc'24.

Please assign this to me so that I can start working on it.

@Niketkumardheeryan Please assign it to me so that I can start working on it.

I have experience with this. Please assign it to me.

@Niketkumardheeryan reminder

@Niketkumardheeryan Please assign it to me so that I can start working on it.

I have already submitted a pull request for one feature addition. Kindly merge that too. Also please assign level.


Can't store a simple string variable

Got this test code:
my $metals = 'iron';
$metals.to-file('metals.raku');

Yields No such method 'to-file' for invocant of type 'Str'
Not sure if I'm using this correctly or not. Originally, I was trying to save a hash, which threw the same error but for a hash.

Thanks for the report. I'll look into it.

Not sure if I'm using this correctly or not. Originally, I was trying to save a hash, which threw the same error but for a hash.

@sdondley you need to mix the FileStore in so that you can access the to-file method:
use Storable::Lite;
my $metals = 'iron' but FileStore;
$metals.to-file('metals.raku');

There you go.