Add 3w data

There's a lot of work left to do on this pipeline, but I think it's at a place where more eyes would be helpful!  I've left TODOs everywhere that I can think of that could use some extra development.
The big issue I could use help with is setting up the structure for multiple countries - right now it's only pulling in IRQ.  I have the config parameters for two more countries, but am having trouble setting up operational_presence.py to include them in the way that the rest of the script is expecting.  I was planning to have a dict for each country within the operational_presence section of the config yaml and loop through them to populate self.data.  In testing that didn't work with the sources/metadata so I just went forward with one country to get rows added to the DB.

The 3W pipeline now has all three countries and is much simpler.  Still open to refactoring to break OperationalPresence into separate scrapers per country, but this is at least a starting point!


Update geostyler-style to version 8.1.0

This updates geostyler-style to the latest version. It also fixes the semantic-release setup.

:tada: This PR is included in version 5.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


v3: Add indentscope example to the migration guide

Problem
In version 2, using LazyVim, I could disable plugin mini.indentscope, and replace its highlighting of the current scope using indent-blankline.
Using stock lazyvim starter:
plugins/blankline.lua:
return {
  {
    "LazyVim/LazyVim",
    version = "6.4.0", -- before migrating to blankline v3
  },

  {
    "lukas-reineke/indent-blankline.nvim",
    version = "2.20.8",
    opts = {
      show_current_context = true,
      show_current_context_start = false,
    },
  },

  {
    "echasnovski/mini.indentscope",
    enabled = false,
  },
}

Using v3, having read :h indentblankline, I cannot figure out how to achieve this behaviour.
I added scope = { enabled = true }, to no avail.
Would it be possible to add a solution for this problem to the migration guide?
Also, I borrowed and changed some code from nvchad, adding [i and ]i motions:
  { -- adding "[i", "]i", replacing mini.indentscope
    "lukas-reineke/indent-blankline.nvim",
    opts = {
      show_current_context = true, -- now removed from lazyvim
      show_current_context_start = false, -- added myself
    },
    config = function(_, opts)
      local function current_context()
        return require("indent_blankline.utils").get_current_context(
          vim.g.indent_blankline_context_patterns,
          vim.g.indent_blankline_use_treesitter_scope
        )
      end
      local function add_go_to_indent_scope_key(context_callback, keymap, desc)
        vim.keymap.set({ "n", "x" }, keymap, function() -- nvchad
          local ok, move_to = context_callback()
          if ok then
            vim.api.nvim_win_set_cursor(vim.api.nvim_get_current_win(), { move_to, 0 })
            vim.cmd([[normal! _]])
          end
        end, { desc = desc })
      end

      require("ibl").setup(opts)
      add_go_to_indent_scope_key(function()
        local ok, node_start = current_context()
        return ok, node_start
      end, "[i", "Go to indent scope top")
      add_go_to_indent_scope_key(function()
        local ok, _, node_end = current_context()
        return ok, node_end
      end, "]i", "Go to indent scope bottom")
    end,
  },

Is this still possible in v3?
Expected behavior
Perhaps, the migration guide could be updated, describing a solution for the problem above.
Best regards!

Would it be possible to add a solution for this problem to the migration guide?

Scope should work out of the box, as long as you have treesitter working.
You can get the current scope with this
local bufnr = vim.api.nvim_get_current_buf()
local config = require("ibl.config").get_config(bufnr)
local scope = require("ibl.scope").get(bufnr, config)
if scope then
    print(scope:range())
end

Or use https://github.com/nvim-treesitter/nvim-treesitter-textobjects the scope text object there is the same.


[Suggestion]: Add field for type of exercise

While working on Ryot, I needed to classify each exercise into one of the following: Duration, DistanceAndDuration and RepsAndWeight. Here is the code I am using to classify each exercise for now.
However, I think there should be an additional type: RepsOnly. For example, Pushups, Pullups, Crunches and so on.
Would you be open to adding a new field type to the schema, which will be an enum with 4 variants? This should be not be very difficult since I already have 3 variants sorted out. WIll have to do the RepsOnly variant manually.

I am open to making a PR for this.

Hey @IgnisDa sounds reasonable! i'm thinking though instead of type as the field name category might be more fitting as a broader grouping
Happy for you to open a PR, glad the project has been useful to you

Closing this one out as it's looking stale feel free to re-open


[feature request] support for EV3

I expected to use Scrub to control EV3 on iPad since we can't use Scratch Link on it.
Scrub said "this extension is not supported" when I  tried to connect EV3.
I hope Scrub supports EV3 if the implementation needs too much effort.
Are there any huge differences to support EV3 or just implementing the specific protocol is tiring?
Anyway, this app is useful on iPad and I'm surprised to find this solution to connect lego products on iPad.

@utotch
Technically, Scrub and EV3 can communicate. I have implemented the feature in the following file:
https://github.com/bricklife/Scrub/blob/main/ScratchLink/Sources/ScratchLink/BTSession.swift
However, I cannot publish an app with this implementation in the App Store, because EV3 communicates with apps as an MFi device, so only the company that produces the MFi device (in this case, LEGO) can publish the app.


[R-package] started adding routine registration in R package (fixes #1910)

Branched off of #2 , adding R_RegisterRoutines stuff.
Updated .Rbuildignore per https://github.com/ss3sim/ss3sim/wiki/Rbuildignore-syntax-explained
Generated the big registration block with this
IN_FILE = '/Users/jlamb/repos/LightGBM/include/LightGBM/lightgbm_R.h'
with open(IN_FILE, 'r') as f:
    txt = [
        line.strip() for line in f
    ]

# filter lines
txt = [
    line for line in txt
    if (
        not line.startswith('/')
        and not line.startswith('*')
        and not line.startswith('#')
    )
]

prefix = 'LIGHTGBM_C_EXPORT LGBM_SE '
functions = {}
current_function = None
for line in txt:
    if line.startswith(prefix):
        current_function = line.replace(prefix, '').replace('(', '')
        functions[current_function] = 0
        print(current_function)
    elif line.startswith('LGBM_SE'):
        functions[current_function] += 1
    elif line.startswith(');'):
        current_function = None
    else:
        raise RuntimeError(f"Encountered unknown line: '{line}'")

# create output like
# {"LGBM_BoosterSaveModelToString_R", (DL_FUNC) &LGBM_BoosterSaveModelToString_R, 6},
# {"LGBM_BoosterDumpModel_R", (DL_FUNC) &LGBM_BoosterDumpModel_R, 6}
longest_func_length = max([
    len(function_name)
    for function_name in functions.keys()
])
print(f"The longest function is {longest_func_length} characters")
for func_name, num_args in functions.items():
    out = '{"'
    out += func_name
    out += '"'
    out += " " * (longest_func_length - len(func_name))
    out += ', (DL_FUNC) &'
    out += func_name
    out += " " * (longest_func_length - len(func_name))
    out += ', '
    out += str(num_args)
    out += '},'
    print(out)

closing since I have a PR in the main repo with these changes


Duplicated failure of a lint

Steps to reproduce the bug with the above code
git clone git@github.com:bevyengine/bevy.git
cd bevy/crates/bevy_render
git checkout 1efdbb7e # for consistent output
cargo run --manifest-path=../../../cargo-semver-check/Cargo.toml -- semver-checks check-release

Actual Behaviour
   Compiling cargo-semver-checks v0.15.2 (/home/tonowak/zpp/cargo-semver-check)
    Finished dev [unoptimized + debuginfo] target(s) in 6.44s
     Running `/home/tonowak/zpp/cargo-semver-check/target/debug/cargo-semver-checks semver-checks check-release`
    Updating index
     Parsing bevy_render v0.9.0 (current)
     Parsing bevy_render v0.9.0 (baseline)
    Checking bevy_render v0.9.0 -> v0.9.0 (no change)
   Completed [ 119.804s] 33 checks; 28 passed, 5 failed, 0 unnecessary

--- failure constructible_struct_adds_field: externally-constructible struct adds field ---

Description:
A pub struct constructible with a struct literal has a new pub field. Existing struct literals must be updated to include the new field.
        ref: https://doc.rust-lang.org/reference/expressions/struct-expr.html
       impl: https://github.com/obi1kenobi/cargo-semver-check/tree/v0.15.2/src/queries/constructible_struct_adds_field.ron

Failed in:
  field Camera.order in crates/bevy_render/src/camera/camera.rs:90

--- failure inherent_method_missing: pub method removed or renamed ---

Description:
A publicly-visible method or associated fn is no longer available under its prior name. It may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-check/tree/v0.15.2/src/queries/inherent_method_missing.ron

Failed in:
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52
  Visibility::toggle, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:52

--- failure struct_missing: pub struct removed or renamed ---

Description:
A publicly-visible struct cannot be imported by its prior path. A `pub use` may have been removed, or the struct itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-check/tree/v0.15.2/src/queries/struct_missing.ron

Failed in:
  struct bevy_render::FrameCountPlugin, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/lib.rs:372
  struct bevy_render::view::visibility::Visibility, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:31
  struct bevy_render::view::visibility::Visibility, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:31
  struct bevy_render::view::visibility::Visibility, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:31
  struct bevy_render::view::visibility::Visibility, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:31
  struct bevy_render::prelude::Visibility, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/view/visibility/mod.rs:31

--- failure struct_pub_field_missing: pub struct's pub field removed or renamed ---

Description:
A publicly-visible struct has at least one public field that is no longer available under its prior name. It may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-check/tree/v0.15.2/src/queries/struct_pub_field_missing.ron

Failed in:
  field priority of struct Camera, previously in file /home/tonowak/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.9.0/src/camera/camera.rs:90

--- failure unit_struct_changed_kind: unit struct changed kind ---

Description:
A public unit struct has been changed to a normal (curly-braces) struct, which cannot be constructed using the same struct literal syntax.
        ref: https://github.com/rust-lang/cargo/pull/10871
       impl: https://github.com/obi1kenobi/cargo-semver-check/tree/v0.15.2/src/queries/unit_struct_changed_kind.ron

Failed in:
  struct RenderPlugin in crates/bevy_render/src/lib.rs:63
       Final [ 135.265s] semver requires new major version: 5 major and 0 minor checks failed

Expected Behaviour
The tool should only print once about the failure (or maybe zero times, if the issue is not present at all -- it needs to be checked).
Generated System Information
Software version
cargo-semver-checks 0.15.2 (bc3eb98-modified)
Operating system
Linux 6.1.4-arch1-1
Command-line
target/debug/cargo-semver-checks semver-checks --bugreport

cargo version
> cargo -V
cargo 1.66.0 (d65d197ad 2022-11-15)

Compile time information

Profile: debug
Target triple: x86_64-unknown-linux-gnu
Family: unix
OS: linux
Architecture: x86_64
Pointer width: 64
Endian: little
CPU features: fxsr,sse,sse2
Host: x86_64-unknown-linux-gnu

Build Configuration
No response
Additional Context
The same happens on bevy_ui, but with the lint struct_pub_field_missing. There is a high chance that it is the same issue. If it is not, a new issue needs to be created.
It might be related to https://github.com/obi1kenobi/cargo-semver-checks/issues/274, but I don't think so.

I think this might be related to re-exports of the same item, which end up checked independently because the query "says so."
The systematic solution for this requires support for exporting @tag values across @fold boundaries, to allow a query structure like:
{
  baseline {
    item {
      importable_path @fold {
        name @tag(name: "paths")
      }
    }
  }
  current {
    item {
      importable_path @fold @transform(op: "count") @filter(op: ">", value: ["$zero"]) {
        name @filter(op: "one_of", value: ["$paths"])
      }
    }
  }
}

In this query, the tagged paths value at the point of use is of type [String!]! because it is folded over before being used. Inside its own @fold scope, the tagged value is of type String! as normal.
This is not something Trustfall supports today.
In the meantime, we may be able to ship a workaround: if a lint query result includes span info, then only report each span once for each lint. Results that lack spans should always be reported.


The execution result of SmartContract.analyzeMethods() cannot display 'rows'

Example code:
export class Add extends SmartContract {
  @state(Field) num = State<Field>();

  init() {
    super.init();
    this.num.set(Field(1));
  }

  @method update() {
    const currentState = this.num.get();
    this.num.assertEquals(currentState); // precondition that links this.num.get() to the actual on-chain state
    const newState = currentState.add(2);
    this.num.set(newState);
  }
}

let result = Add.analyzeMethods();
console.log('Add analyze result: ', result);

Screenshot of the result:

Also, does ZkProgram have a method similar to analyzeMethods?

Thanks! I noticed this recently as well and it's already fixed in a PR: https://github.com/MinaProtocol/mina/pull/12123
ZkProgram currently only has digest() for the digest, but it would be very easy to add analyzeMethods()

done


docker-compose fails with postgres

Describe the bug
docker-compose for conductor with postgres fails with errors related to JedisConnectionException
Details
Conductor version:  3.13.5
Persistence implementation: Postgres
To Reproduce
Steps to reproduce the behavior:

Clone the conductor repository
Go to conductor/server/build.gradle
add this dependency : runtimeOnly 'com.netflix.conductor:conductor-postgres-persistence:3.13.5'
Go to conductor/docker and run command :  docker-compose -f docker-compose-postgres.yaml build
Run  docker-compose -f docker-compose-postgres.yaml up
See error

Screenshots

Link to PR : https://github.com/Netflix/conductor/pull/3590


Support safe read /path/to/secret:key

I want this to work:
$ safe read secret/handshake
--- # secret/handshake
knock: knock

$  safe read secret/handshake:knock
!! secret not found

Ideally, it works like this little spruce+jq pipeline:
$ safe read secret/handshake | spruce json | jq -r ".knock"
knock

Should that first try "handshake:knock" as a path, and get that, before failing back to "handshake" and its "path" key? Or is : a reserved character in all secret backends for vault?

On Oct 17, 2016, at 12:18 PM, James Hunt<EMAIL_ADDRESS>wrote:
I want this to work:
$ safe read secret/handshake
--- # secret/handshake
knock: knock
$  safe read secret/handshake:knock
!! secret not found
Ideally, it works like this little spruce+jq pipeline:
$ safe read secret/handshake | spruce json | jq -r ".knock"
knock
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/starkandwayne/safe/issues/49, or mute the thread https://github.com/notifications/unsubscribe-auth/AG2SUopHxrCrShOprqqEzA8IV2rs5tlGks5q05_DgaJpZM4KY0bi.

I don't know if : is usable in a Vault path, but Spruce doesn't handle them - per https://github.com/geofffranks/spruce/blob/master/op_vault.go#L141-L148, it would seem that a path like secret/<IP_ADDRESS>:3000/admin:password would be treated as a path of secret/<IP_ADDRESS> and an attribute name of 3000/admin:password.
I think we should mimic that behavior, and if that's not the behavior we want, we ought to update Spruce to behave accordingly.

If it makes you feel any better, scp uses this syntax and they pretty much threw in the towel on the problem. However, scp also appears to delimit by the last colon provided. Maybe thats the more logical way? I know you can technically make a yaml key with a colon in it, but... which is more likely to occur?

I'm good with that, as long as we update Spruce accordingly

:thumbs-up:

On Oct 17, 2016, at 3:03 PM, James Hunt<EMAIL_ADDRESS>wrote:
I'm good with that, as long as we update Spruce accordingly
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/starkandwayne/safe/issues/49#issuecomment-254301525, or mute the thread https://github.com/notifications/unsubscribe-auth/AG2SUpf1MPgvkpE6RDQ9MlSUew1oM7Ifks5q08Z1gaJpZM4KY0bi.

For posterity... this feature actually already exists in 0.23! Whoops... however, we'll be moving the secret:key separator to whatever the last colon in the string is, revamping the output for when it is found, and making a more sensible error for when it isn't found.

still no joy, even after #51 😞
safe read secret/handshake:knock
--- # secret/handshake:knock
knock

That's some YAML stuff right there.


Is there a plan of adding Flowbite typography as component?

Summary
Flowbite typography as component.
Motivation
Text element is very common and is one of the most used elements, I think it will be very helpful if we add it as component.

If you are talking about this typography, Flowbite-Svelte supports all of them.

Yep that's the one, sounds great then. Thanks


outdated brapi-resources.xml/json

I've tested the resources available in the current version of brapi-resources and found some that are not available at the time of this writing (James Hutton Institute, BMS, Cassava-test needs auth, etc). What should we do with them?
I can submit a PR removing those that are not working anymore. I also know some other resources, but I am not affiliated with them so I don't know if they want to appear here.

The Hutton one just needs updated. We'll get on it...

Closing this issue. Not a problem with the spec.
I believe BRAVA has created a good solution to this problem. Before now there was no incentive for groups to keep there implementations updated because the information was not being used anywhere except as developer reference documentation. Now there is an incentive to keep your implementation info updated so you can pass the automated BRAVA test suite.
That said, it is on my TODO list to make existing public BrAPI resources known and available to a wider audience. So I'll be looking to make the update process easier, and the list more publicly visible.


How to use luisy with databricks?

Within this question it is especially interesting to clearify how luisy can be used in combination with spark jobs.
E.g. when using spark jobs the write will also be done within the spark job directly.
Supporting SparkJobTasks would enpower lusiy when used on databricks but also on other spark backed settings (cloud or non cloud).

@MartinRoth: This is partially adressed in #26, can we close this?

@windisch yes we can close this.


Design: Addon Management

In order for the community to create and maintain addons, we need a shared interface for addon installation and overall lifecycle.
There are a number of considerations regarding packaging, runtime, security, dev tools, ops tools, use-case, and governance.
These concerns are separate from creating operators or other programs concerned with addon specifics such as #3. (ex: How do you install or maintain the coredns-operator?)
This google doc aims to list and weigh various approaches and trade-offs:
https://docs.google.com/document/d/1tpayzZ4teTKOXNUEsA2HK73eWzz9MhZOFTKYz_rRI_8

Anyone can view and comment
kubernetes-dev members can edit
kubernetes-dev members can change permissions
( reach out if you are not a member but desire edit access )

This should enable fair, open, async discussion across time-zones.
From this doc, one or more parties may create proposals(KEP's) which can compose or compete.
These new proposals may build on the existing KEP: https://github.com/kubernetes/enhancements/pull/746
Feel free to comment here and/or on the document.
/kind design
/priority important-soon
/sig cluster-lifecycle

/lifecycle frozen


Create page visual cleanup

[ ] Restrict width of all sections
[ ] Restrict width of all cards
[ ] Use distro card layout for all cards

The create page is now a modal!


Fix broken link to PBR example in README.md

could you do that PR on branch main instead of latest?

bors r+


Spelling corrector model

Closes:

Title : Spell Corrector made using Keras
Name: Garv Anand
Idenitfy yourself: GSSOC and SSOC Contributer

Describe the add-ons or changes you've made 📃
Made the complete model and also added heirarichal data format files of encoder and decoder
Type of change ☑

What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested? ⚙
It has been tested on the words and sentences we use in daily life
Checklist: ☑

[x] My code follows the Contributing Guidelines & Code of Conduct of this project.
[x] This PR does not contain plagiarized content.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] My changes generate no new warnings.

Screenshots 📷
Uploading Spell Corrector - Made with Clipchamp.mp4…
Note to reviewers 📄
I have uploaded the model files ,the model is working completely fine just a UI of text box and button is required of streamlit and the model should be imported to host it further or integrate in the current website

@Garvanand properly attach your issue with pr and integrate your model with Jarvis.


The method 'read' isn't defined for the type 'BuildContext'

Describe the bug
Following documentation guidelines read method should be available in context when importing the right package. Even if the package is imported, in my case import 'package:flutter_riverpod/flutter_riverpod.dart';, read method is not defined.
Riverpod version 1.0.0+dev3.
To Reproduce
import 'package:auto_route/auto_route.dart';
import 'package:my_app/auth/domain/post.dart';
import 'package:my_app/common/ui/providers/home_provider.dart';
import 'package:my_app/common/ui/router/app_router.gr.dart';
import 'package:flutter/material.dart';
import 'package:flutter/widgets.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart'; <--- correct import ---

class HomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Flutter Demo Home Page'),
      ),
      body: Center(
        child: FutureBuilder(
            future: context.read(homeProvider.notifier).getPosts(), <---- This is not working, no read method. ----
            builder: (BuildContext context, AsyncSnapshot snapshot) {
              if (snapshot.connectionState == ConnectionState.waiting) {
                return Center(child: CircularProgressIndicator());
              }
              return Consumer(builder: (BuildContext context, WidgetRef ref, _) {
                List<Post> _posts =
                    ref.watch(homeProvider.select((state) => state.posts));
                return Column(
                  mainAxisAlignment: MainAxisAlignment.center,
                  children: [
                    Expanded(
                      child: ListView.builder(
                          itemCount: _posts.length,
                          itemBuilder: (BuildContext context, int index) {
                            return Card(
                                child: ListTile(
                              title: Text(_posts[index].title),
                              onTap: () {
                                AutoRouter.of(context).push(TestRoute());
                              },
                            ));
                          }),
                    )
                  ],
                );
              });
            }),
      ),
    );
  }
}

Expected behavior
When importing the right package context should have read method.

On 0.14.0+3 is working fine.

See the changelog, it was removed.

Here? https://github.com/rrousselGit/river_pod/blob/master/packages/flutter_riverpod/CHANGELOG.md


Video is missing on the Japanese subtitle GSoC project

https://ccextractor.org/public/gsoc/japanese/
There used to be a YT video embedded, but this is no longer visible on the new layout.
It seems to be totally gone from the markdown too.
The original video URL was https://www.youtube.com/watch?v=7QhwgrOrnyE, and should be re-added.

Fixed by @Techno-Disaster in fa6c94041008f5725635bc8ab7cdc9b96c714a60


SOFT FORK: Today, BitClout joins the environmental movement.

I am proud to announce that the dev community has committed to moving to
a zero-waste consensus mechanism, and that it is taking a major step in
that direction with a new update.
Cryptocurrencies have gotten a lot of heat recently for being harmful to
the environment.
This is due in large part to "proof of work," a consensus mechanism that
burns CPU power to secure the network.
BitClout has relied on proof of work to get off the ground, but since
launching the dev community has already invested in consensus mechanisms
that allow BitClout to operate on orders of magnitude less power than
most existing proof of work cryptocurrencies.
Now, in a show of solidarity with the environmental movement, and to
take the first big step toward a zero-waste consensus mechanism,
BitClout is deploying a new update that reduces its power consumption by
a full order of magnitude.
BitClout is reducing the block reward, and thus the amount of
environmental waste its consensus mechanism incurs, by a factor of ten.
This was a difficult change to make, and it took the input of several
major node operators to deploy it safely.
We understand that miners in particular may not like this change;
however, there is now consensus around the decision to push the limits
of the BitClout chain toward conservation rather than allowing the
depletion of what are ultimately finite environmental resources.
There is still more work to do to move to a zero-waste consensus
mechanism without compromising on decentralization (e.g. full proof of
stake).
But the dev community is committed to getting there sooner rather than
later, and we hope this change shows just how committed we are.

Is there any plan to have the actual community start to vote on some of these huge decisions?
Or perhaps at least discuss it before force-pushing to main?

is this really about the energy usage? with 2TH of network hashrate has no effect what so ever on the environment. not sure when mining will stop but would have been nice to get a heads up.

@iPaulPro I've very sorry this feels like it was sprung on you all. That was not the intent, and it's meant to be a positive change that will significantly increase how seriously BitClout is taken by the broader crypto ecosystem in light of all of the controversy over environmental-friendliness. It does also significantly decrease BitClout's footprint, which is a good thing both for energy usage but also for the cost of running the network.
In the future, changes like these will be submitted as CIPs (Clout Improvement Proposals) similar to BIPs in Bitcoin. The only reason we did not go through that process for this change is because we have not yet set up that repository. That said, it will be set up shortly, and it will allow the devs to get a lot more input before merging changes like this.

@diamondhands0 how can we as a community help put CIPs in place? whats left to be done right now? If anything needs reviewing happy to contribute as I am keen to help and get this right.

Have you given any thought to MEV - miner extractable value.
Seems like miners could extract a lot of value by re-ordering or front-running creator coin transactions.

Just to toss my two cents into the mix:
First and foremost, I think it's important to mention that this is a great move in the right direction. Over the past four years, we've seen countless examples of proof-of-work consensus mechanisms failing to scale and be effective for daily use -- cause them to be slow, and extremely expensive. Projects like Ethereum, which have been greatly impacted by such failures, are now quickly converting to a cheaper and faster consensus model: Proof of Stake.
For these reasons, I'm unsure why the development team would use proof-of-work in the first place. The model is old, proven to lack scaling capability, is very slow, and requires a ton of electricity. For a social media blockchain, these aspects are vital. It much be fast, cheap for users, and easy to secure due to the number of transactions used, and the fact that they're by users not always making monetary transactions -- unlike most chains. Although BitClout works just fine with proof of work as of now -- the current blockchain won't scale, will be way too expensive for users, and overall wouldn't allow BitClout to expand to mass adoption. For this, a move to proof of stake (as the comments in the PR hint to) would be extremely ideal.
Now as for the PR itself, I'm unsure why this exists. Although the mindset of moving to a energy-minimal, fast, and cheap blockchain is great, this short-term solution is quite horrible and doesn't make much sense. While the intentions are good, shrinking the block reward makes mining less profitable, therefore making the network less secure due to lack-of-incentives. I think the idea here is good, but this for sure isn't the solution. If we're sticking with this solution, though, a larger change such as proof of stake needs to be in the pipeline ASAP.
As for CIP's, I think this is a great idea, and a vital one. While the chain is already decentralized, and the community could easily revert this change through the use of running 51% of nodes, I think having a move formal method of improvements with community consensus would make a ton of sense.

For this, a move to proof of stake (as the comments in the PR hint to) would be extremely ideal.

Agree very much @HPaulson and I would welcome some clarity about timescales about this, especially considering current Bitclout ownership and impact on CIP influence/decisions.
And like you im looking forward to CIP process going live soon.

@tijno Agreed. Time scaling is very important. Another thing is like to be very very clear about, however, is this: The core dev team doesn't matter. They don't own BitClout, and don't want to.
I see way too much of the community acting as if they have the final say on these decisions -- they don't, and that's a great thing!
CIP's will be a good organization method, but just keep in mind that the protocol is in the hands of the community, not the dev team.

The core dev team doesn't matter. They don't own BitClout, and don't want to.

In theory you are right - anyone can now take the code and restart the chain at any point in time.
In practice right now though they do decide & implement key changes quickly like we have seen. I am not sure anyone else forking at this point would get traction - theres only about 2k passionate users, and 99% of those will stick with bitclout.
Not bashing it though as any project from inception to opensource will go through a handover phase like this, where the rains have to be handed over carefully and slowly.

CIPs ... which of course didn't occur

I would love to see it soon, but if any further major changes are in the pipeline for the next 2 weeks - it may make sense to hold off with formally adopting the process until there is a point of stability. Eg - if I had to choose between major exchange listing or CIP - id be happy to hold off on CIP for a few weeks.

Wouldn't lowering the mining incentive this quickly put the network at risk for a 51% attack due to so many simply pointing their rigs at another blockchain?

This is excellent news! With the climate crisis at the top of the agenda for most countries and the widely publicised environmental impact of cryptocurrency, this would have been a major blocker for many people to join the network.
Younger generations of creators are the most aware of the climate crisis. To get mass adoption this should be something to shout about otherwise the network growth will stall as the climate crisis worsens and awareness of it increases.

@tijno Of course yes. In practice the devs do most of the changes at their discretion, however in reality the community does control the entire protocol -- and I think it's very vital that we approach these changes with this mindset.

@MateosDev This is the worry -- yes. As incentives lower, the network becomes less secure, which is of course very dangerous

I fully support the move to POS, though I am concerned at the lack of opportunity for community consensus on this.
With that said, this move is part of quite an aggressive supply reduction overall very early in BitClout's lifetime - before the majority of coins have had time to distribute naturally via the incentives provided. Fair distribution of coins is critical to reaching an ethical consensus in POS decentralization. I trust that the greatest holders of BitClout are content to yield the power they inherit as a result of this unilateral decision that is taking place without community involvement, or I fear a rift may start to form in the trust we have all built with each other.
I continue to trust the hands at work here. The work and vision I see here is truly inspired and noble. But I implore the decision-makers behind BitClout to please consider the foundation of the future that they are crafting. Full decentralized trustlessness of BitClout has not yet been achieved, as evidenced by the fact that unilateral decisions can still be made - many of us have cast ourselves 'all in' on BitClout on the trust that has been built by the developers of the project over time. Please take care not to fracture our fragile community. Until development is truly decentralized, our trust is in you.

so well put @JRedinger

Fair distribution of coins is critical to reaching an ethical consensus in POS decentralization.

distribution is essential. staking (and thus voting) power should probably not rest with a few beneficiaries.
we cant predict what will happen but we know the signs that show we remain on track.
on track to achieve the vision that got us all so excited .
the team have earned a level of trust with me that todate they have delivered on everything they said they would.
despite all the "scam" outcries on twitter and socials.
one by one their objections got addressed until there were none left.
exchange listing / offramp is the remaining item on the "first 100 days in office" list i think.
i cant see the whole puzzle yet, but hope this was a key piece.
and i hope the miners/pool operators that invested huge amount of time and money to get ready for mining did so in the knowledge that this change was maybe looming.
cant wait to see what next week brings.

This is all very frustrating, so I want the record to reflect that I am strongly against moving away from proof of work, especially when it's done in this manner.
If this upcoming proof of consensus change is merged without first being reviewed and approved by the actual community here on GitHub, I don't think it would be unreasonable for us to consider a community-controlled hard fork.

This is all very frustrating, so I want the record to reflect that I am strongly against moving away from proof of work, especially when it's done in this manner.
If this upcoming proof of consensus change is merged without first being reviewed and approved by the actual community here on GitHub, I don't think it would be unreasonable for us to consider a community-controlled hard fork.

i think a community-controlled hard fork is a little bit far fetched and definitely not needed and in fact could set back this amazing new innovation. pos is great and i support it. im just disappointed in the fact that no heads up was given. but with that being said i think let us give it a chance to blossom in terms of distribution of the premine. depending on how that goes could turn out to be a great move for all. only time will tell.

I just feel for korbin who i think worked 20 hour days for weeks to get his pool launched. Im sure he did well out of it but also invested lots to get it build & tested.
Then to be told 2 weeks after it gone up in smoke ...
I hope he had knowledge of this or will be made good.
Miners can just switch to the next coin. Probably back to ETH for now.

This is all very frustrating, so I want the record to reflect that I am strongly against moving away from proof of work, especially when it's done in this manner.
If this upcoming proof of consensus change is merged without first being reviewed and approved by the actual community here on GitHub, I don't think it would be unreasonable for us to consider a community-controlled hard fork.

Proof of stake is a much, MUCH better consensus model. There's no reason not to support it -- unless you're just trying to capitalize on the community through mining.
Something as large as POS would likely be a CIP. If not, we always have the ability to hardfork, however keep in mind pos would be a good change, so no reason to do so. We should tread lightly in all changes though, as I said prior.

This is all very frustrating, so I want the record to reflect that I am strongly against moving away from proof of work, especially when it's done in this manner.
If this upcoming proof of consensus change is merged without first being reviewed and approved by the actual community here on GitHub, I don't think it would be unreasonable for us to consider a community-controlled hard fork.

I totally agree. With mining now 10 times less profitable and POS not implemented (and no solid plans on that), seems like BitClout is not going to stay in the current state for long. I do support POS models, but again, this all came out of the blue, as it seems.

Mining isn't necessarily bad for the environment... my house has solar panels, so the electricity used is about as clean as we can get at the moment. It is really strange to see this just sprung on the community with no input or real time to evaluate it.

@paulmp-git I think the environmental factor is less of the issue at hand -- and more of a PR thing for BitClout. A LARGE majority of BTC is mined with clean energy, yet its still looked at as negative for the environment.
The larger factor at hand, in my opinion, is the speed & scalability of the network. POW isn't scalable. It's slow, expensive, and just lacks the ability to grow -- just take a look at eth gas fees over time. I think PoS is vital, just maybe not for the reasons they described... no matter how we get there, it's the end goal that matters

Proof of stake is a much, MUCH better consensus model. There's no reason not to support it -- unless you're just trying to capitalize on the community through mining.
Something as large as POS would likely be a CIP. If not, we always have the ability to hardfork, however keep in mind pos would be a good change, so no reason to do so. We should tread lightly in all changes though, as I said prior.

I have never done any mining at all, actually. My reason for being against POS it is that it reduces the decentralization of the network, particularly on a network that just underwent a two month pre-mine.
I'm totally open to being proven wrong. I just don't buy the "environmental impact" arguments against crypto mining. It's all a misguided attempt at marketing and mass appeal, I think.

@connerdouglass Yup -- I 110% agree that the environmental reason is all PR. However, mining is definitely an old consensus model that can be replaced.
As far as decentralization:
It Doesn't compromise on security what-so-ever -- in fact, it does the opposite. The premine of BitClout is not entirely owned by the development team. Wallets held include large seed investors, a fund to pay for exchanges, and much more. The investor wallets, however, are the important ones. These wallets contain BitClout which the core team has access to, but are not allowed to control/stake without discretion of the investor. This means that the team would need 51% of the supply (roughly 5.5m coins) Yk stake and centralize the network. With 6m already purchased by the community, this would be extremely challenging.

@HPaulson That's all fair, but just because it's "old" does not mean mining should be replaced. I prefer to think of mining as "tried and true". Lots of new things are worse than the old things!

@HPaulson you know this as a fact, or you are speculating ?
ive not heard this explanation before as the reason for limiting supply ?

@tijno I know this as a fact. Not sure how much I'm allowed to say further on the subject

maybe dont say anything more in that case

MEV - miner extractable value is excellent and wish it were considered.
I feel terrible for the people who purchased expensive new equipment just to mine Bitclout.
POS has moral issues. First off, it lends to less decentralization. Secondly, often, the rich get richer and those with smaller stakes stay that way for the most part, despite their contributions. It emphasized money, not community (which is the underlying value of a "social" blockchain.) Projects primarily intended to be used for dApps like games and social features really need to consider everyone, not just the largest stakeholders. In this sense, I think dPOS (ie hive/steem) is a little "better" in as far as at least smaller stakers can "vote" on which nodes get the blocks. And that incentivizes nodes to compete for the approval of who they represent by providing value in return.
Just throwing my opinion in here.

This was a difficult change to make, and it took the input of several
major node operators to deploy it safely.

@diamondhands0 I'm very interested to hear about these "major nodes". Who are these operators?
You often speak about the "dev community". Who makes up this community?
Looking forward to your response.

Re: 6 million coins being adequate distribution for PoStake, I’m only familiar with ETH but they require 32 ETH to participate, is this because the number of stakeholders should be kept low for technical / sync reasons?
I guess I’m close to re-hashing (lol) the whole debate on Staking vs Working, but I just want to jump on the bandwagon that sees this coin as very obviously not evenly distributed. Maybe non-investor normies hold the majority of coins, but if PoS has a minimum threshold, you can cut off the long tail of those accounts as they’re ineligible to secure the network.

Ok @diamondhands0 I and others do expect an elaboration on this topic ASAP. So please prepare that with the team and release it to the community. It would be wise to do this soon than later. It is not that this was the wrong decision necessarily but there needs to be more explanation and respect.... and an apology would also be appropriate.

The Environmental angle is a flimsy argument. Changes like this deserve well reasoned argument, not hand wavey PR.
I think the goal of moving to proof of stake is valid. But the smoke and mirrors here feels dishonest.

The Environmental angle is a flimsy argument. Changes like this deserve well reasoned argument, not hand wavey PR.
I think the goal of moving to proof of stake is valid. But the smoke and mirrors here feels dishonest.

It does feel like PR a la Elon influence on BTC. Of course we should always welcome power use optimizations and in most cases, not perpetually rely on PoW (that was never going to happen here). I expected a transition to Proof of Stake at some point so that part is no surprise and I welcome it. But this soft fork explanation does not fly as the entire story.

Hey everyone. First off, I am again very sorry that this change was rushed through. Again, that was not the intent-- we are just, frankly, in a mad dash to a major announcement next week and trying to get all of our ducks in a row before then. On the bright side, I am happy to say that, after next week, it will be much harder to make changes this quickly and this unilateraly (I can't say more without giving away the announcement). This is also why the CIPs change is not only beneficial, but actually needed. And @maebeam will launch it shortly-- there is a private repo, she's just doing a lot right now.
I've also had the opportunity to read through all of the Discord channels and this entire thread, making notes as I go through to remember everything. I don't always do this, but I want you all to know that I did that in this case because I think it's really important to address everyone's opinion here.
First, who did we talk to about this change? Just to be very clear, we talked to Korbin at length about the change well in advance of making it, we talked to a couple of the top names on bithunt.com (don't want to drag them into this), and we notified @lobovkin (though I do wish we could have given him more time to discuss it than we did). We should have talked to you all as well, and going forward the CIPs repo will be the mechanism for this. But, again, because we are currently in a mad dash, we had to cut things a little short this time. Again, in the future it will be much more difficult to push changes this quickly but I do want to emphasize that even in this case there was consensus around this decision being a good one among the people we talked to.
Now, why is this change important? There are other reasons than just the environment:

All of us hold BitClout. We are all aligned by the fact that we all own the same asset. Mining is fundamentally inflationary. It prints BitClout, which then must be dumped in order to cover the miner's costs. And miners don't dump because they're bad people, they dump because it's the only way to operate: If you earn 1 BitClout, but your cost to earn it was .95 BitClout, then you must dump .95 BitClout to cover that cost. At current prices, the emission rate would have resulted in ~$20M+ USD being dumped every year, which would have had a very negative effect on the ecosystem. And who would even benefit from that? Yes, the miners would get .05 BitClout for every 1 BitClout they mined, but the other .95 would basically go toward wasting energy and hardware. Put another way, every .05 you take away from mining gives .95 back to existing BitClout holders (that would otherwise have been spent on wasting electricity). It's a hard thing for people to understand this, which is why I didn't go into it in my main announcement, but this is how it works.
Many now understand the negative effects of proof of work. In my opinion, the fact that the environment is damaged by this activity is sufficient to make it worthwhile to get rid of. But even if you don't care about that, it is still the case that we're getting to a point where major public figures and funds can't be associated with something that doesn't have a serious plan to move away from it. We started with proof of work because it is, in my opinion, the best way to launch a truly decentralized platform in a bottom-up fashion. But at some point, not moving away from it is going to hurt BitClout's adoption and its narrative in a way that is totally avoidable. We have the power to take a very aggressive stance against proof of work now that the platform is fully open and sufficiently decentralized, and I truly believe it is the best thing for the platform to do that, even if you don't care about the environment.

Lastly, I want to make a few one-off points about things I came across in case people are concerned about them:

On MEV and 51% attacks: BitClout is resistant to these attacks at present due to the "trusted block producer" setup. I'm not going to go into it here, as this deserves a post on its own, but you can trace the --trusted_block_producer flag and read the comments if you're curious about how it works.
There is some chatter about how people who purchased mining equipment are hurt by this change. That is not true because they can trivially pivot their equipment to another blockchain and make money that way. Unless someone actually spent time writing a mining pool, like Korbin or @lobovkin, all of their investment should be very easy to repurpose if they want.
On the genesis block: Everyone in the genesis block purchased coins from the bonding curve, same as any user purchases BitClout today (before the Deflation Bomb). All BitClout in existence came from either: 1) a legitimate purchase from the bonding curve with Bitcoin as it's defined in supply.go and described by @tijno in one of his posts, 2) mining, or 3) the 2M BitClout founder reward, which is part of the genesis block. The reason the genesis block is huge is because there was a hard fork that compressed all the purchases/balances between ~November 2020 until ~March 2021. This is one of the things I most regret about our launch because it has caused a lot of confusion, but I'm setting the record straight here that no BitClout was given away for free outside of the 2M, and none of the other holders in the Genesis block got coins outside of the bonding curve.

I know the above will not address all concerns, but I do hope it helps shed some light on things. I won't be able to respond to everything, but if it's important I hope you all understand that I'll put the time in, and give me the benefit of the doubt if I don't.
Lastly, I do want to say that, although I am disappointed in myself for not being more thoughtful about how we deployed this change, I am absolutely and unbelievably thrilled that I am part of a community that cares as deeply about this project as you all do right now. The fact that so many people are this invested in the platform is a very positive thing, and as someone who's been working on the project for over two years now, with over one year of it totally alone, it moves me in a very profound way.
Thank you all again for being a part of this, for encouraging us to be better, and please know that we are 100% committed to improving all the time, together.

Thanks for posting this thorough update. Will a summary be posted on bitclout ?

Thank you all again for being a part of this, for encouraging us to be better, and please know that we are 100% committed to improving all the time, together.

Thank you for spotlighting the issue.  Hopefully, all bold moves like this will be announced and discussed more widely (and posted to the BitClout, not only GitHub)

@diamondhands0 Thanks for this thoughtful response. I do think it's great that there is a passionate community forming and as a founder myself, I completely understand and appreciate how hectic things must be and how much effort it has taken to build something like this. I think you should be extremely proud that what you've built has reached the point where the community is stepping up and wanting more of a say, and I know you are working hard to hand over the reigns as soon as possible.
I think in general most people will agree that a move to POS is the right move from a technical perspective. However, I think there definitely has been a misunderstanding over the genesis block and the pre-mine. It would be valuable to share that information more broadly so that people are clear that the 6M tokens in the genesis block were purchased in the exact same was as the 6M tokens in the following blocks. I know I've had multiple discussions in the Discord community explaining this but still very few people are aware of what actually happened. I think if more people knew this it would help resolve concerns about moving to POS since the assumption by many people is that BitClout is not well distributed enough.
The last thing I'll say is that it's easy point out mistakes from the sidelines, but we should all remember how much blood, sweat, and tears must have gone into building this protocol. Imagine working for years building something with no indication that it's going to work at all and then launching it to the world and having it blow up so quickly (in addition to dealing with all kinds of controversy). It's impossible to do things perfectly, but I'm impressed by how the founding devs have reacted and handled everything so far and am very excited to see the dev community grow to include anyone and everyone capable and interested in contributing.

On MEV and 51% attacks: BitClout is resistant to these attacks at present due to the "trusted block producer" setup. I'm not going to go into it here, as this deserves a post on its own, but you can trace the --trusted_block_producer flag and read the comments if you're curious about how it works.

This certainly does deserve a post on its own! I'm very interested to hear if there are plans to decentralize mining.

Thanks @diamondhands0 for the thoughts and updates. Appreciate you and the tireless work you and team are putting in to bring this to fruition.

This entire idea that PoS is more efficient and that Pow is bad is ridiculous and is a narrative that plays to those who already have coins.  Miners seek out the cheapest power rates they can possibly get.  That means they go to areas that have excess power because of supply and demand metrics and the influence on price.  Miners seek renewable energy sources because it's good for their bottom line.
Miners who mine coins they like, normally do so because it is cheaper for them to acquire coins via mining than by buying outright.  Of course there are those who will dump, but assuming that 100% of the mining emission would be dumped is ludicrous.  100k coins a year at the old emission with maybe even a high 75 percent of them being dumped is only 75k coins to be absorbed by an ecosystem that already has 11 million in circulation.  Do the math, that is 0.006% of the circulating supply.  That's really going to hurt the Bitclout value metrics.    Current valuation is 2.2 billion at the same $200 coin price point used for the 20 million in emissions.  That's less than 1% of the market cap.  If that hurts you, you are destined to fail anyways.  The points given to rationalize this are retarded.
I don't know any miner that mines a coin where they are only taking 5% in profit for every coin they mine.  That is suicide for a miner.  All the reasons and numbers to attempt to justify the action are just made up to sustain the narrative even though it isn't backed by any real metrics and are numbers just shot from the hip.
There is more to this story.  Much more. The plebes are being fed a load because there is no real logic to the argument as laid out above.

Well, first thanks for the answer.
But I have a kinda offtopic question.
Can you clarify about the swap identity request also here that allows admins to change any username/public key to another one? And looks like that means get all control, balances, steal usernames, and so on.
Am I right?
That's really much power. Will you give this possibility to people or remove it from the node?

All of us hold BitClout. We are all aligned by the fact that we all own the same asset.

@diamondhands0  if you wanted  #me to believe that our incentives are aligned you would have sent the company Bitcoin to a burn address.

I listen for things. I pay attention for things. I try to be very careful with my trust, like many of us, like you I'm sure, we've experienced the pain of trusting the wrong people in crypto.
@diamondhands0, I trust you.
Please take adequate time to consider as many angles as you can for the POS foundation you are implementing. This is your opportunity to encode the balance of influence and incentive that will serve as the permanent foundation for your vision for this platform. As much as possible, please ensure that the interests of everyone you are trying to help through your creation is well cared for permanently as a fundamental feature of the consensus and governance protocols you and the rest of the team have designed and chose to implement here.
Thank you so much for all your hard work. I'm with you.

Waking up and entering clubhouse with strange discussion was...strange; now, after reading this thread I at least understand part of the reason why other people are not happy. Besides having BS in IT/BM , my knowledge of blockchain  and crypto are just starting. I didn't participate in mining, so the change didn't impact me directly, but as a BitClout enthusiast, who devotes almost 24/7  to the platform, i would be more happy, if any decisions would be properly discussed by community, before implementing.

This entire idea that PoS is more efficient and that Pow is bad is ridiculous and is a narrative that plays to those who already have coins. Miners seek out the cheapest power rates they can possibly get. That means they go to areas that have excess power because of supply and demand metrics and the influence on price. Miners seek renewable energy sources because it's good for their bottom line.

Seeking excess power and renewable energy is a lie and impossible for anyone mining as individual or even in GPU pools. It is only possible for large companies that can cut a deal with the local grid. These are typically ASIC mining companies.
Most of the individual miners and pools you are talking about will anyway evaporate in 2 months even if PoW wasn't changed - when all the FPGA folks enter the game. When they do, there will be nothing left for us regulars to mine and at some point they'll also get outgamed by ASIC folks.
In the end, mining will simply be done by large ASIC mining companies. On the other hand, as long as you have minimum stake, you can start earning rewards. Even that isn't often needed - most exchanges allow you to start staking and earning rewards even if you don't meet the minimum threshold. In my opinion, for small folks like me, it is better if it becomes PoS, as I can indeed earn money even if I don't meet the minimum threshold, thanks to crypto exchanges that will pool money for validation nodes.
Side note on ETH: ETH does have a profitable mining rate today - and that's mostly because of the gas fee. Even Mr. Buterin agrees long term PoS is the way to go and believes for the chain's long term sustenance, these astronomical gas fees are NOT good.

Miners who mine coins they like, normally do so because it is cheaper for them to acquire coins via mining than by buying outright. Of course there are those who will dump, but assuming that 100% of the mining emission would be dumped is ludicrous. 100k coins a year at the old emission with maybe even a high 75 percent of them being dumped is only 75k coins to be absorbed by an ecosystem that already has 11 million in circulation. Do the math, that is 0.006% of the circulating supply. That's really going to hurt the Bitclout value metrics. (roll eyes) Current valuation is 2.2 billion at the same $200 coin price point used for the 20 million in emissions. That's less than 1% of the market cap. If that hurts you, you are destined to fail anyways. The points given to rationalize this are retarded.

^ This is again - going to go away for GPU miners like you and me. We can't compete on economies of scale that FPGA and ASIC miners will bring to the table. Why aren't they in today? There is cost of development - and the lead time is all we got before we become unprofitable.

I don't know any miner that mines a coin where they are only taking 5% in profit for every coin they mine. That is suicide for a miner. All the reasons and numbers to attempt to justify the action are just made up to sustain the narrative even though it isn't backed by any real metrics and are numbers just shot from the hip.
There is more to this story. Much more. The plebes are being fed a load because there is no real logic to the argument as laid out above.

I am 100% with you that the change should have been explained better and communicated in a more orderly fashion. But from what you are championing, it looks like you are not standing for the plebs like you and me, but instead for the large ASIC and FPGA mining companies.

Прокидатися і входити в клуб з дивною дискусією було ... дивним; тепер, прочитавши цю тему, я принаймні розумію частину причини, через яку інші люди не задоволені. Окрім того, що я маю ступінь бакалавра в галузі ІТ / BM, мої знання про блокчейн та криптовалюту тільки починаються. Я не брав участі в майнінгу, тому зміна не вплинуло на мене безпосередньо, але як ентузіаст BitClout, який присвячує платформу майже цілодобово та без вихідних, я був би більш щасливим, якщо б якісь рішення були належним чином обговорені спільнотою, перед впровадженням.

completely agree

Yikes


File download

Is there a way to download files over http with hound? I poked around but didn't see any support for it.

This is driver dependent, and we do not have any clean way to do it for now.
PhantomJS does not seem to support this yet.
In what context do you need to download a file?
It could be easier to guide you towards a solution or workaround if we have the whole picture.

@tuvistavie Thanks for getting back to me. I was hoping to log into a website and download a file, I was able to use an http client and do a direct post to login and then use the session cookie to get the file. I still think it would be cool if hound supported this, but I get it's tricky being driver dependent.


Roadmap

Hey,
I think it would be very useful to have some list of things that we would like to see in stu(tter).
Let me begin with my wishlist:

Rename project to stu
Consistent error reporting
Multiline repl
Data structures support - sets, hash tables, lists
Modules support
Standard library for strings manipulation, i/o etc.

We definitely need this and is a great start; @pbu88 asked me about a roadmap awhile back.
I'd like to add to your nice list:

Factor out all functionality into a libstu, for easier embedding in other projects
Make a perl extension to drive the stu interpreter
Move to autotools, and test on more systems
Use your mentioned features to build OO functionality
Nice exceptions
Implement a step debugger

Oh and I'd like to do some coverage/profiling with gprof to see where the bottlenecks are.


[Transform] Add op to apply im2col patterns and update the workgroup count region

Required for implementing a pipeline for implicit gemm on GPU backends. Im2col converts a convolution to a gather on the input and a gemm. This collapses the image dimensions of the output for 2D convolutions and thus the workgroup count compute region needs to be updated to match the new iteration ranges for the main compute op.
Depends on https://reviews.llvm.org/D144678

I am not really sure whats going on here. These seems to breaking layering to make this work..... I dont think you need this

Essentially when applying im2col inside a dispatch, this introduces a collapse on the image (H & W) dimensions of the output of the convolution. Those reshapes are expected to be bubbled to the edges of the kernel and merged with the hal.interface.binding.subspan ops, however tiling to workgroups happens based on the collapsed shape, not the original convolution shape and thus the workgroup count compute region needs to be updated accordingly. This might not be the right place for this op then and am open to suggestions.

I am not really sure whats going on here. These seems to breaking layering to make this work..... I dont think you need this

Essentially when applying im2col inside a dispatch, this introduces a collapse on the image (H & W) dimensions of the output of the convolution. Those reshapes are expected to be bubbled to the edges of the kernel and merged with the hal.interface.binding.subspan ops, however tiling to workgroups happens based on the collapsed shape, not the original convolution shape and thus the workgroup count compute region needs to be updated accordingly. This might not be the right place for this op then and am open to suggestions.

I would expect for implicit gemm you would tile and distribute on convolution first and then apply im2col on a tiled convolution. Doing im2col first seems like an unnecessary complication.

Essentially when applying im2col inside a dispatch, this introduces a collapse on the image (H & W) dimensions of the output of the convolution. Those reshapes are expected to be bubbled to the edges of the kernel and merged with the hal.interface.binding.subspan ops, however tiling to workgroups happens based on the collapsed shape, not the original convolution shape and thus the workgroup count compute region needs to be updated accordingly. This might not be the right place for this op then and am open to suggestions.

I would expect for implicit gemm you would tile and distribute on convolution first and then apply im2col on a tiled convolution. Doing im2col first seems like an unnecessary complication.

There was a discussion about this before: https://discord.com/channels/689900678990135345/689932666505920596/1080196907797860373
Essentially we end up with those reshapes inside the scf.forall for implicit gemm and it causes problems for bufferization.

Essentially when applying im2col inside a dispatch, this introduces a collapse on the image (H & W) dimensions of the output of the convolution. Those reshapes are expected to be bubbled to the edges of the kernel and merged with the hal.interface.binding.subspan ops, however tiling to workgroups happens based on the collapsed shape, not the original convolution shape and thus the workgroup count compute region needs to be updated accordingly. This might not be the right place for this op then and am open to suggestions.

I would expect for implicit gemm you would tile and distribute on convolution first and then apply im2col on a tiled convolution. Doing im2col first seems like an unnecessary complication.

There was a discussion about this before: discord.com/channels/689900678990135345/689932666505920596/1080196907797860373
Essentially we end up with those reshapes inside the scf.forall for implicit gemm and it causes problems for bufferization.

I remember now... It would probably be good to look into that more... In any case you do need the extra buffer here to do the im2col... what is being tried here seems extremely fragile and I am not sure this can be supported long term (I have a long standing TODO to fix the workgroup count region generation)

There was a discussion about this before: discord.com/channels/689900678990135345/689932666505920596/1080196907797860373
Essentially we end up with those reshapes inside the scf.forall for implicit gemm and it causes problems for bufferization.

I remember now... It would probably be good to look into that more... In any case you do need the extra buffer here to do the im2col... what is being tried here seems extremely fragile and I am not sure this can be supported long term (I have a long standing TODO to fix the workgroup count region generation)

Ok so are you suggesting going back to applying im2col before the first level of distribution then?

There was a discussion about this before: discord.com/channels/689900678990135345/689932666505920596/1080196907797860373
Essentially we end up with those reshapes inside the scf.forall for implicit gemm and it causes problems for bufferization.

I remember now... It would probably be good to look into that more... In any case you do need the extra buffer here to do the im2col... what is being tried here seems extremely fragile and I am not sure this can be supported long term (I have a long standing TODO to fix the workgroup count region generation)

Ok so are you suggesting going back to applying im2col before the first level of distribution then?

Ill review this, but this seems very fragile... I am more suggesting not going down this path.

There was a discussion about this before: discord.com/channels/689900678990135345/689932666505920596/1080196907797860373
Essentially we end up with those reshapes inside the scf.forall for implicit gemm and it causes problems for bufferization.

I remember now... It would probably be good to look into that more... In any case you do need the extra buffer here to do the im2col... what is being tried here seems extremely fragile and I am not sure this can be supported long term (I have a long standing TODO to fix the workgroup count region generation)

Ok so are you suggesting going back to applying im2col before the first level of distribution then?

Ill review this, but this seems very fragile... I am more suggesting not going down this path.

Is this something we need to discuss more in depth. Doing the conversion after tile and distribute is going to bring more challenges.

There was a discussion about this before: discord.com/channels/689900678990135345/689932666505920596/1080196907797860373
Essentially we end up with those reshapes inside the scf.forall for implicit gemm and it causes problems for bufferization.

I remember now... It would probably be good to look into that more... In any case you do need the extra buffer here to do the im2col... what is being tried here seems extremely fragile and I am not sure this can be supported long term (I have a long standing TODO to fix the workgroup count region generation)

Ok so are you suggesting going back to applying im2col before the first level of distribution then?

Ill review this, but this seems very fragile... I am more suggesting not going down this path.

Is this something we need to discuss more in depth. Doing the conversion after tile and distribute is going to bring more challenges.

Happy to discuss. I am not sure I can say more than doing im2col before distribution (and therefore having to change the number of workgroups) goes against what implicit gemm is (which is im2col at tile level). It seems strictly more involved to do im2col and then do tile + fuse + distribute. This seems like a fragile WAR to the bufferization issue (which I understand reshapes mess things up).

Happy to discuss. I am not sure I can say more than doing im2col before distribution (and therefore having to change the number of workgroups) goes against what implicit gemm is (which is im2col at tile level). It seems strictly more involved to do im2col and then do tile + fuse + distribute. This seems like a fragile WAR to the bufferization issue (which I understand reshapes mess things up).

There are more reasons why it is simpler to do im2col before as it allows us to get back to the matmul code generation earlier and it makes it allows us to have a more unified code gen flow.

It seems strictly more involved to do im2col and then do tile + fuse + distribute

I think besides the problem with number of groups it is strictly simpler to do the im2col before.
The assumption in the calculation of the number of workgroups is something we want to solve right? Wouldn't that make this problem go away?
Obviously it could be done in a different order but this will make the work more difficult and we get less sharing with the matmul codegen which is a big downside to me.

Happy to discuss. I am not sure I can say more than doing im2col before distribution (and therefore having to change the number of workgroups) goes against what implicit gemm is (which is im2col at tile level). It seems strictly more involved to do im2col and then do tile + fuse + distribute.

Setting up a discussion offline to decide on a way forward sounds like a good idea. I don't want to be pushing for fragility, although this group count adjustment is the only difference from distributing before im2col and in my experience it made the later codegen steps much simpler and closer to the matmul "happy path."

Happy to discuss. I am not sure I can say more than doing im2col before distribution (and therefore having to change the number of workgroups) goes against what implicit gemm is (which is im2col at tile level). It seems strictly more involved to do im2col and then do tile + fuse + distribute. This seems like a fragile WAR to the bufferization issue (which I understand reshapes mess things up).

There are more reasons why it is simpler to do im2col before as it allows us to get back to the matmul code generation earlier and it makes it allows us to have a more unified code gen flow.

It seems strictly more involved to do im2col and then do tile + fuse + distribute

I think besides the problem with number of groups it is strictly simpler to do the im2col before.

I am not sure why that is the case... it might be simpler with the current codegeneration stack, but implicit gemm is tile conv + im2col on tile. Here this is being reversed... irrespective of details, that seems inverted to me.

The assumption in the calculation of the number of workgroups is something we want to solve right? Wouldn't that make this problem go away?

There is no assumption here. When the dispatch was created there was some representation of the number of workgroups computed based on the operation that is tiled and distributed. For implicit gemm that still doesnt change... Doing im2col and using fusion so that you do im2col of the tile to get to implicit gemm is strictly harder (and inverted). Irrespective of the fragility of the number of workgroups, doing im2col on the whole tensor and then doing tile + fuse does not seem like the right approach....

Obviously it could be done in a different order but this will make the work more difficult and we get less sharing with the matmul codegen which is a big downside to me.

Dont see how the sharing is reduced? After tile and distribute of the conv. you can do im2col and get a matmul. So then its matmul codegen.....

Given what I am reading here, should this be a graph-level transform instead ?

Given what I am reading here, should this be a graph-level transform instead ?

If we do that then we rely on fusion to get to implicit gemm. Also the graph-level transform of this already exists as transform.structured.convert_conv2d_to_img2col where this is strictly for applying the pattern within a dispatch and needing to update the workgroup counts based on the new shape of the computation. There was a discussion offline and the conclusion was that this is fine as a workaround until some work to improve workgroup count computation comes in.

Given what I am reading here, should this be a graph-level transform instead ?

If we do that then we rely on fusion to get to implicit gemm.

Still wont address the issue. You will basically end up with the gemm + im2col in a dispatch like you have here.

Does squash and merge let me edit the commit message before pushing it? I haven't done this on GitHub before.

Yes it does


Error downloading OmniSharp packages for VSCode server (WSL2) while connected to a VPN

Issue Description
I'm unable to download OmniSharp package for VSCode server (WSL2) while connected to a corporate VPN.
I can download the package using wget, though.
I can also download the package for regular (Windows) VSCode without any issues.
Steps to Reproduce
Expected Behavior
Download omnisharp-linux-x64-1.35.3.zip correctly and all the subsequent packages, successfully completing Omnisharp extension installation.
Actual Behavior
Downloading package OmniSharp for Linux (x64) failed at stage: downloadPackage with error code 407
Logs
OmniSharp log
Starting OmniSharp server at 7/8/2020, 1:43:47 PM
    Target: /home/ed/xxxxxxxx
[ERROR] Error: spawn /home/ed/.vscode-server/extensions/ms-dotnettools.csharp-1.22.1/.omnisharp/1.35.3/run ENOENT

C# log
Installing C# dependencies...
Platform: linux, x86_64, name=ubuntu, version=18.04
Downloading package 'OmniSharp for Linux (x64)' Failed to download from https://download.visualstudio.microsoft.com/download/pr/62ed767d-0d83-467d-bed5-723895f59443/f580747abff6bbcae4c67ad0aedb31ad/omnisharp-linux-x64-1.35.3.zip. Error code '407')
Retrying from 'https://roslynomnisharp.blob.core.windows.net/releases/1.35.3/omnisharp-linux-x64-1.35.3.zip' Failed to download from https://roslynomnisharp.blob.core.windows.net/releases/1.35.3/omnisharp-linux-x64-1.35.3.zip. Error code '407')
Failed at stage: downloadPackage
407
Environment information
VSCode version: 1.46.1
C# Extension: 1.22.1
Mono Information
        OmniSharp using built-in mono
Dotnet Information
.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7
Runtime Environment:
OS Name:     ubuntu
OS Version:  18.04
OS Platform: Linux
RID:         ubuntu.18.04-x64
Base Path:   /usr/share/dotnet/sdk/3.1.201/
Host (useful for support):
Version: 3.1.3
Commit:  4a9f85e9f8
.NET Core SDKs installed:
3.1.201 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension
Author
Version

csharp
ms-dotnettools
1.22.1

Known workaround
Open VSCode server in WSL2 without being connected to any VPN to have all the packages installed.

I'm experiencing this same issue even when not connected to my VPN.

It turned out to be a proxy issue.
Solved by adding this settings to WSL setup (as recommended in https://github.com/OmniSharp/omnisharp-vscode/issues/579):
{
    "http.proxyStrictSSL": false,
    "http.proxy": "<proxy_address>:<port>"
}


RenderStart Signature

Could you please add the "RenderStart" signature to the repo?

this signature which refer to a vfunc is not usable for external cheats

this signature which refer to a vfunc is not usable for external cheats

This. I don't see any point for adding function signatures to this repo.


Fixed loadDatabase callback

This PR fixes an issue, with which the user-defined callback would be called with the contents of the database in the argument which marks an error.

@techfort Could you please merge this in & push a release asap? The bug that this handles is a bit of a blocker and I wan too avoid referencing my branch in my project. Thanks!

Oops, looks like 1.3.14 deals with this, thanks you!

Phew,  more than one release per day would sound crazy :-D
On Thu 25 Feb 2016 16:48 Arek Sredzki<EMAIL_ADDRESS>wrote:

Closed #353 https://github.com/techfort/LokiJS/pull/353.
—
Reply to this email directly or view it on GitHub
https://github.com/techfort/LokiJS/pull/353#event-565923731.

Ah sorry I saw several issues related to this issue (including this pr) and tried to commit a change to stabilize this :) I had a typo though so seems it blew up again.
Thanks for pointing this out, I had to remind myself how this works.  Adapter interface is subject to changes for 2.0 versions so this hopefully maintains 1.3.x compatibility.


Python2.7

Can we support Python2.7?

Sure. Please open an issue to track this

Sure I'll see what's not working on python 2.7


Dynamically adding product version and patch level to log4j. file or console

Description:
It is useful to have an easy way to find out the exact level of the codebase that running in every environment which will dynamically state the product version with its patch level either in log file or carbon console.

We are closing this as this feature is no longer required.


Remove sg rules for access to EC2 from EKS

The security groups have been removed in govuk-aws terraform and no longer exist.

Sorry for the breakage!


chore: update tsconfig.json

:tada: This PR is included in version 6.3.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add log line anchor for action logs

Close #24593
Some behavior:

If log step line in hash exists, expand the step and scroll to the log line.
If step exists but line not exists, the step will be expanded.
If step not exists, stays on the job's page.

Some Notes:

Changed mounted to async because need to await for first loadJob so currentJobStepsStates can be initialized and used in hashChangeListener .

Demo:
https://github.com/go-gitea/gitea/assets/17645053/669111f5-3f06-489c-af86-ef03fe3692f3

Found a bug:

CTRL-F5 on repo page
Click Actions
Open a step
Click line number

Page will unexpectedly reload. I think you need a e.preventDefault() on the links to prevent such navigation. Interestingly, it does not happen all the time.

I found scroll-margin-top working pretty well, and no need to use scrollIntoView after setting this. I set scroll-margin-top to 95px, which is about 5px below the fixed headers.
And changed href to not use absolute path. Updated demo in the description.

And changed href to not use absolute path. Updated demo in the description. Ready for review again.

Should that fix https://github.com/go-gitea/gitea/pull/25532#issuecomment-1611841418?

#25532 (comment)

Yes


Query parameter type appears as string

I'm not sure why the parentCategory parameter is showing up as having type string:
/api/categories:
  get:
    summary: List categories.
    description: >
      Retrieve the list of top level categories.
      If you specify a parent category, this endpoint will
      instead return the list of its children.
    parameters:
      - in: query
        name: parentCategory
        description: The ID of the parent category whose children should be retrieved (optional).
        required: false
        schema:
          type: integer
          example: 568
    responses:
      '200':
       description: A list of categories.
       content:
         text/plain:
           schema:
             type: string
             example: OK
       '500':
         description: Something went wrong.

And here is the resulting HTML:

Thank you so much!

I'm not sure but looks like you have OpenAPI 2.0 spec.
In OpenAPI 2.0 type of non-body parameter should be defined at the parameter level, not in the schema (schema should be defined only for body parameters):
/api/categories:
  get:
    summary: List categories.
    description: >
      Retrieve the list of top level categories.
      If you specify a parent category, this endpoint will
      instead return the list of its children.
    parameters:
      - in: query
        name: parentCategory
        description: The ID of the parent category whose children should be retrieved (optional).
        required: false
        type: integer # <-- directly here
        example: 568
    responses:
      '200':
       description: A list of categories.
       content:
         text/plain:
           schema:
             type: string
             example: OK
       '500':
         description: Something went wrong.

That is correct, great catch! I added an issue to the swagger-jsdoc repo. Thanks!
https://github.com/Surnet/swagger-jsdoc/issues/138

swagger-jsdoc by default adds "swagger": "2.0" instead of "openapi": "3.0.0". Maybe redoc could interpret the two in the same way?

Those are two completely different versions of spec (with really different structure). So ReDoc can't interpret them in the same way. ReDoc actually converts 2.0 to 3.0 internally.
Closing the issue.

I actually realized that after writing the comment. Sorry for the silly question!


Set caseSensitive to false for SqlToRelConverter#convertIdentifier

Issue:
hive (default)> CREATE TABLE IF NOT EXISTS u_jiefli.tableU (struct_col struct<colA:int>);
OK
Time taken: 0.072 seconds
hive (default)> CREATE VIEW IF NOT EXISTS u_jiefli.viewC AS SELECT * FROM u_jiefli.tableU;
OK
Time taken: 0.487 seconds
hive (default)> CREATE VIEW IF NOT EXISTS u_jiefli.viewD AS SELECT struct_col.colA FROM u_jiefli.viewC;
OK

If we try to translate u_jiefli.viewD in Coral, it would throw the exception:
Exception in thread "main" java.lang.AssertionError: Type 'RecordType(INTEGER colA)' has no field 'cola'
        at org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:177)
        at org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3731)
        at org.apache.calcite.sql2rel.SqlToRelConverter.access$2200(SqlToRelConverter.java:217)

Because SqlIdentifier struct_col.colA would be converted struct_col.cola during expansion in SqlValidatorImpl and cause the exception.
For our use case in Coral, we need to set the case to be insensitive for convertIdentifier to ensure that cola could also be retrieved in RecordType(INTEGER colA).
Tested on the affected production views, will run Coral integration test before adopting this modification in Coral.

@ljfgem  Sorry for the late response, eventually I found something interesting and I think the change in this PR could be saved. Instead, the "fix" could come from Coral itself.
Back to the problem itself, I tried to reproduce the issue in Coral unit test but failed to. Problem there is, the inner rowType is already RecordType(INTEGER cola) in RexNode coming out of the line RexNode e = e0.left; inside org.apache.calcite.sql2rel.SqlToRelConverter#convertIdentifier(org.apache.calcite.sql2rel.SqlToRelConverter.Blackboard, org.apache.calcite.sql.SqlIdentifier)  and the identifier itself after expansion is also cola, so they matched.  On the other hand from our internal GRID system I am also able to reproduce the issue from your script, and I do find the inner rowType is RecordType(INTEGER colA).  Then I was trying to figure out what's the difference. In short it could be attributed to the com.linkedin.coral.hive.hive2rel.HiveTable#getRowType within Coral code, that delegate the responsibility of casing-preservation down to the Hive Deserializer. We end up with different types of deserializer in unit test versus GRID test and that's why we saw different inner row type.
A longer version:
Part of SqlValidation process's responsibility is to resolve/validate the table metadata (e.g. rowType) by consulting the catalog system. We could trace it down through
org.apache.calcite.sql.validate.SqlValidatorImpl#validateSelect
org.apache.calcite.sql.validate.SqlValidatorImpl#validateFrom,
org.apache.calcite.sql.validate.SqlValidatorImpl#validateQuery to
org.apache.calcite.sql.validate.AbstractNamespace#validate
which contains recursive call that I am not going to expand here. The outcome of this process creates object of Namespace that the SqlToRelConverter will query later.  The TableNameSpace that carries metadata from catalog system which essentially feed the information into Blackboard objected that is being used to lookup in line 3720 of SqlToRelConverter already carry the rowType with RecordType(INTEGER colA) in the inner level. The RowType within TableNameSpace comes from org.apache.calcite.sql.validate.EmptyScope#resolve_#159 where the HiveTable calls getRowType that delegates to com.linkedin.coral.hive.hive2rel.HiveTable#getRowType.
From there you could find the call getColumns is relying on Deserializer's ObjectInspector to determine column type recursively.

I think the right fix is not to change the case sensitivity in Calcite which I believe will make it hard for us to converge with upstream. Our problem here is the type resolution from catalog: For Hive, column name should be case insensitive (maybe all in lowercase regardless of which deserializer is being used). So the getColumns call should be modified. wdyt ? Happy to discuss further on this.

@autumnust Thank you so much for your detailed explaining.
When I tried to debug for getColumns, I found the issue couldn't be reproduced with coral-tools on production using the latest version of coral (2.0.8), but it appeared on coral 1.0.74 (current version used by Trino).
Therefore, a PR between 1.0.74 and 2.0.8 somehow fixed the issue 😂 But I can't recall it now. Let me do some investigations.
Anyway, I think we can close this PR since the issue could be resolved once Trino team deploy the latest version of coral-trino.


Asset Integrations: LUMEN Unstable

What is the purpose of the change

To make LUMEN of LumenX unstable (unable to Deposit and Withdraw) because the chain has been killed.

See the LumenX is now killed: https://github.com/cosmos/chain-registry/blob/8f2f39b28966f0913fa36c3d66a114ebbb53dca9/lumenx/chain.json#L4
Brief Changelog

add isUnstable: true to lumen in ibc-assets.ts

Testing and Verifying
This change has been tested locally by rebuilding the website and verified content and links are expected

🐻


[NavigationMenu] Use NavigationMenuIndicator instead of after

Description
https://www.radix-vue.com/components/navigation-menu.html#indicator

It will be used for content arrow anyway.


Activities. can not distinguish between edit and uploaded file

Steps to reproduce

edit a file
check the activity
activity shows added

Expected behavior

activity shows edited

Actual behavior

activity shows added
moss added New file.odt to Maurice Moss

Needs moving the event creation from eventsmiddleware to decomposedfs as described here: https://github.com/owncloud/ocis/issues/9481


ESP32C3 BLE Command Questions

Environment

Development Kit: ESP32-C3-M1
IDF version: v3.4 (master branch)

Question
There are read/write characteristic commands for BLE GATT client, but I only find set characteristic command for server.
Any command for server to read characteristic?
Thank you.

@leungngok At present, ESP-AT master has implemented AT+BLEGATTCRD command on the server side. If you still need these functions, please test and develop based on ESP-AT master


Bitrate parameters (vsibr, vsbr) don't work.

These parameters result in the SDP being munged, adding fmtp parameters for the VP8 codec. But if the codec used isn't VP8 (it's currently VP9 by default), this doesn't do anything.

vsbr is added as b=AS, that works due to being added to the media section but vsibr is added to the codec section and in this case for VP8 and is not carried over.
Thanks for filing!


Changing the Depth parameter in UI often does not lead to using that value when the

Expected Behavior
Changing the depth from 3 to 6 should allow the user to potentially request more models/etc. to be sent back to the UI if the directory tree is deeper than 3.
Actual Behavior
Monitoring the backend of the CS API with added debug statements, I keep seeing "3" being sent on a fresh browser, even though I am change the values.
I then verified this was a front end issue with F12 tools, looking at the outgoing websocket request.
Steps to Reproduce
Place a model or other object five levels deep from the root.
Install a fresh browser or profile. [The reason to use a fresh browser or profile is that these values used to stick in the browser, and I have on stuck at "20" on Edge, and I cannot reduce it, lol. Incognito mode might work, haven't tested it.]
Start up SwarmUI.
Open SwarmUI url in browser.
Open F12 tools.
Navigate to the tab for that object type.
The default depth will be 3.
Search for the object.
Object is not found.
Set depth to 6.
Either click tab's refresh button or search for the object using the edit field.
Object is still not found.
Using F12 developer tools debugger, examine outgoing request, see that the change in the UI is not sent down to the API. (see attached picture) in the Other section.
Debug Logs
N/A

Other

And yes, all four of the ListModels requests had "3".

fixed by https://github.com/mcmonkeyprojects/SwarmUI/commit/f82d49ff8b0fe42118f3def382d0dd1f66864ce3
Was a misapplied translate code resetting the html elems and losing the change event. Very annoyingly subtle bug (no error messages about it just a thing doesn't run)