Interpreter: bug in the initialization of an instance variable

The interpreter does not correctly initialise an instance variable with a default value from a class property
The following code:
module Test
  module Config
    class_property param : Int32? = 0
  end

  class Foo
    def initialize(@v = Config.param)
      p! @v
    end
  end
end

Test::Foo.new

with crystal run, produces
$ crystal run test.cr
@v # => 0

with crystal i, produces
$ crystal i test.cr
Crystal interpreter 1.6.2 (2022-11-04).
EXPERIMENTAL SOFTWARE: if you find a bug, please consider opening an issue in
https://github.com/crystal-lang/crystal/issues/new/
@v # => nil

Thanks!
Reduced:
module Config
  @@param : Int32? = 0

  def self.param
    @@param
  end
end

p Config.param

It has nothing to do with instance variable initialization. It seems class parameter default values aren't set.

I don't know why that's failing, but something else is going on. If I run this program through the interpreter in master:
p 1

I get this:
Crystal interpreter 1.7.0-dev [63618ff56] (2022-11-20).
EXPERIMENTAL SOFTWARE: if you find a bug, please consider opening an issue in
https://github.com/crystal-lang/crystal/issues/new/
1
Invalid memory access (signal 11) at address 0x24
[0x104f90694] *Exception::CallStack::print_backtrace:Nil +104 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x104f67790] ~procProc(Int32, Pointer(LibC::SiginfoT), Pointer(Void), Nil)@src/signal.cr:127 +320 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x1c6a6c4e4] _sigtramp +56 in /usr/lib/system/libsystem_platform.dylib
[0x105d799e0] *Crystal::Repl::Interpreter#interpret<Crystal::ASTNode+, Crystal::Type+>:Crystal::Repl::Value +464004 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x105d07d70] *Crystal::Repl::Interpreter#interpret<Crystal::ASTNode+, Hash(String, Crystal::MetaVar)>:Crystal::Repl::Value +1852 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x1062347e0] *Crystal::Repl#interpret<Crystal::Call>:Crystal::Repl::Value +112 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x10623474c] *Crystal::Repl#interpret_exit:Crystal::Repl::Value +44 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x106234950] *Crystal::Repl#run_file<String, Array(String)>:Crystal::Repl::Value +184 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x10618c3d8] *Crystal::Command#repl:(Crystal::Repl::Value | Nil) +1060 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x106187f40] *Crystal::Command#run:(Bool | Crystal::Repl::Value | Nil) +952 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x106187a28] *Crystal::Command::run<Array(String)>:(Bool | Crystal::Repl::Value | Nil) +28 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x1061879e0] *Crystal::Command::run:(Bool | Crystal::Repl::Value | Nil) +36 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x104f41590] __crystal_main +2300 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x10510233c] *Crystal::main_user_code<Int32, Pointer(Pointer(UInt8))>:Nil +12 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x1051022a4] *Crystal::main<Int32, Pointer(Pointer(UInt8))>:Int32 +60 in /Users/aryborenszweig/Projects/crystal/.build/crystal
[0x104f4a644] main +12 in /Users/aryborenszweig/Projects/crystal/.build/crystal

So something between 1.6.2 and master maybe broke the interpreter. I won't have time to fix this, sorry!

Ok, no problem, as it works on compiled app !

Fixed by #12635


Random forest parallelization

@daraghk , thank you very much for your contribution to Smartcore! The code looks good, the only thing that is left are clippy warnings and better test coverage. Once you have closed all pending checks we can merge this PR to development

@VolodymyrOrlov happy to contribute! I've fixed the code coverage issue but the linting errors are unrelated to any code I touched - you can see the same issues in the other random forest pr which is open at  the moment.

Codecov Report

Merging #137 (e9da303) into development (b4a807e) will increase coverage by 0.00%.
The diff coverage is 85.96%.

@@             Coverage Diff              @@
##           development     #137   +/-   ##
============================================
  Coverage        83.40%   83.41%
============================================
  Files               78       79    +1
  Lines             8377     8453   +76
============================================
+ Hits              6987     7051   +64
- Misses            1390     1402   +12

Impacted Files
Coverage Δ

src/linalg/ndarray_bindings.rs
83.18% <ø> (ø)

src/math/num.rs
84.09% <ø> (ø)

src/ensemble/random_forest_regressor.rs
73.10% <84.09%> (+2.51%)
:arrow_up:

src/ensemble/random_forest_classifier.rs
75.12% <86.56%> (+4.09%)
:arrow_up:

src/dataset/digits.rs
92.85% <100.00%> (+0.54%)
:arrow_up:

src/svm/svc.rs
89.45% <0.00%> (-0.31%)
:arrow_down:

src/linear/lasso_optimizer.rs
94.11% <0.00%> (ø)

src/lib.rs
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

I think that we could do parallelization with a feature flag that is disabled for WASM targets

I know but we have no bandwidth to follow up on all these features, creating a feature for one case can be only an increase in complexity with very few benefits. We need to prioritise or allocate more time or have somebody that carries on the task of extending parallelization to more algorithms.


Allow metadata for write_deltalake

Description

Add Name, Description, and Configuration arguments to write_new_datalake in python and python-rust bindings
Add round trip metadata writing test
Suppress write clippy "too many arguments" (Default max seems to be 7, function has 8).

Related Issue(s)
Should resolve #576
Documentation

looks like python linter is also complaining about too many arguments.

Not sure why the lambda_checkpoint_build failed, doesn't seem to be related to changes made here. LMK if I need to change anything else here, but doesn't seem to be required so I'll be leaving it as-is for now.

And don't worry about the checkpoint build, we've seen it be flaky recently and it doesn't seem like it could be related to these changes.

Thank you @PadenZach!


bump okhttp3 from 4.9.3 to 4.10.0

I would like to ask you to upgrade okhttp3 because they have resolved a kotlin CVE in https://github.com/square/okhttp/pull/7225 which is the part of the 4.10.0 release.

I'll try to get to this today.

PR: https://github.com/IBM/java-sdk-core/pull/181


fix: update first emoji index on mount

Details
Update the first emoji index on mount
Fixed Issues
$ https://github.com/Expensify/App/issues/30083
PROPOSAL: https://github.com/Expensify/App/issues/30083#issuecomment-1772872371
Tests

Open ND and log in with any account
Go to any chat and tap emoji button to open EmojiPicker
Tap search input and type any characters(for example 'he')
Press arrow down key several times and try to highlight first row emojis by pressing arrow down or arrow left keys
Verify that the first row emojis are highlighted

[x] Verify that no errors appear in the JS console

Offline tests

Open ND and log in with any account
Go to any chat and tap emoji button to open EmojiPicker
Tap search input and type any characters(for example 'he')
Press arrow down key several times and try to highlight first row emojis by pressing arrow down or arrow left keys
Verify that the first row emojis are highlighted

QA Steps
Note: Not testable on mobile native platforms because there are no arrow keys

Open ND and log in with any account
Go to any chat and tap emoji button to open EmojiPicker
Tap search input and type any characters(for example 'he')
Press arrow down key several times and try to highlight first row emojis by pressing arrow down or arrow left keys
Verify that the first row emojis are highlighted

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/126839717/20835542-f9d4-4786-97dd-04c6667d6257

Android: mWeb Chrome
https://github.com/Expensify/App/assets/126839717/8a15e697-77b2-4122-8989-70abf10d93c0

iOS: Native
https://github.com/Expensify/App/assets/126839717/37bcd6ef-9f36-4522-a469-03d50df1cb4a

iOS: mWeb Safari
https://github.com/Expensify/App/assets/126839717/2caaa4d8-1319-497b-a98a-2edfca68f474

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/126839717/d704f308-4e23-4777-8d85-0e7fcd7af29f

MacOS: Desktop
https://github.com/Expensify/App/assets/126839717/809a7153-7878-46ef-96d2-126b82c209c3

🚀 Cherry-picked to staging by https://github.com/francoisl in version: 1.3.87-11 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

Confirmed fix on staging web

🚀 Deployed to production by https://github.com/francoisl in version: 1.3.87-12 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


bug: no hot reloading on changes in components

The site doesn't automatically reload anymore on changes made in components, you have to manually click refresh.
I think this behaviour might be related to #71

After testing a bunch of previous versions and seeing if the problem was there then I think I tracked down the piece of code causing this issue.
If I comment out
// Make a universal Route
  server.get('/:type/:id', (req, res) => {
    renderAndCache(req, res, '/page', {
      id: req.params.id,
      type: `${req.params.type}Pages`
    })
  })

The problem goes away and you see changes made in components again.
The errors in #71 also go away, so these two definitely seem connected.
Now to find a solution to this problem, maybe nextJS update?


[docs]  How to dynamically modify the "window[0].theme" in tauri.config.json?

How to dynamically modify the "window[0].theme" in tauri.config.json? I only see the "change" and "get" methods.

This is not implemented yet, see https://github.com/tauri-apps/tauri/issues/5279.

You can close and re-open the windows like i showed here: https://github.com/tauri-apps/tauri/issues/5279#issuecomment-1263643559 - rust equivalent: https://docs.rs/tauri/latest/tauri/window/struct.WindowBuilder.html#method.theme

Is it possible to configure in the setup phase in Rust?

Yes, scroll all the way to the top of the WindowBuilder doc page i sent. It uses the .setup hook there. Normally you'd remove the window config from tauri.conf.json if you use these apis, but there's now also a method to get a WindowBuilder from the config: https://docs.rs/tauri/latest/tauri/window/struct.WindowBuilder.html#method.from_config. Combining both these things you'd end up with something like this:
tauri::Builder::default()
  .setup(|app| {
    let window = tauri::WindowBuilder::from_config(&app, app.config().tauri.windows.get(0).unwrap().clone())
      .theme(Some(tauri::Theme::Dark))
      .build()?;
    Ok(())
  });

Doing this in JavaScript will be tricky since you need an existing window to run any js code.


feat: add some object operators to expr

Following this discussion https://github.com/tailcallhq/tailcall/discussions/928
I think it might be worth adding a toPairs operator https://ramdajs.com/docs/#toPairs in expr.
Refer to #933 for more context
Technical Requirements

We need at least the following expr path toPairs values keys
Write unit tests and integration tests.

/bounty 150$

/attempt #1265

@ologbonowiwi I've added a schema for the path operator and am now working on tests and implementation (in src/lambda/relation.rs).
Tests should be located in the src/blueprint/operators/expr.rs and tests/execution/test-expr-relation.md files, correct?
https://github.com/tailcallhq/tailcall/compare/main...oleksandr-shvets:tailcall:feat/add-object-operators-to-expr

Is this still relevant @tusharmath?

Closing since https://github.com/tailcallhq/tailcall/issues/1609


Blockly.FieldAngle.ROUND = 1 rounds to the nearest even number

It would make more sense to me to round to the nearest integer...

Actually this doesn't make sense given the code, nevertheless I can't pick odd angles, hmm...

moving to google/blockly


Paramiko no seen by spyder

What steps will reproduce the problem?

Using Mininconda and setted my own environment, I can see Paramiko 2.7.2 installed but when I start spyder, a box appears with Paramiko missing dependency

Hi @CLiNTPELiX It is possible that the environment in which you installed Paramiko isn't the same in which you are running spyder. Can you let me know which was your method of installation?

Closing due to lack of response.


Windows testing workflow hangs

I've debugged this to happen using windows-latest where both the client and server hang on the handshake call. Where in the handshake this occurs has yet to be determined. More testing requires access to a windows machine.

In the meantime, TCP support is working on windows: https://github.com/joe-at-startupmedia/golang-ipc/actions/runs/9154995517/job/25166681176


Need animationstart event

The requirement is to mark the group where the latest marker is located, so an additional marker is required to be displayed outside of Leaflet.markercluster. Considering the visual effect, you need to hide this extra marker before the animation starts and display it again after the animation ends. So need an animationstart event

I'm interested in this as well.
I have mouseover's on my markers, and I want to disable hovering while cluster animations occur.
Why: Because markers flying around automatically (the clustering animation) move under the mouse cursor and unexpectedly/abruptly changing the hover state for the user.


How to reduce drift?

Hi rsasaki, thanks for this project.
I have been using this localization with nav2 stack (slicing the 3rd dimension to 0) and I have faced some issues.

When using NDT or GICP, system suffers from loss of localization.
While using NDT_OMP, mostly good but drifts in translation after running for a while (I found a drift of 1 m in about 30 mins)
I could not use GICP_OMP because of the following error:
./kdtree/include/pcl/kdtree/impl/kdtree_flann.hpp:237: int pcl::KdTreeFLANN<PointT, Dist>::nearestKSearch(const PointT&, unsigned int, pcl::Indices&, std::vector<float>&) const [with PointT = pcl::PointXYZI; Dist = flann::L2_Simple<float>; pcl::Indices = std::vector<int>]: Assertionpoint_representation_->isValid (point) && "Invalid (NaN, Inf) point coordinates given to nearestKSearch!"' failed. `

I have checked that both the initial map and received clouds are being filtered before registration but I don't know why it still throws this error.
Here is my setup and config:

Ubuntu 22.04
ROS2 humble
Indoor environment
Config

/**:
  ros__parameters:
        registration_method: "NDT_OMP"
        score_threshold: 2.0
        ndt_resolution: 0.01
        ndt_step_size: 0.01
        ndt_num_threads: 4
        transform_epsilon: 0.001
        voxel_leaf_size: 0.6
        scan_max_range: 50.0
        scan_min_range: 1.0
        scan_period: 0.1
        use_pcd_map: true
        map_path: "/home/map.pcd"
        set_initial_pose: true
        initial_pose_x: 0.0
        initial_pose_y: 0.0
        initial_pose_z: 0.0
        initial_pose_qx: 0.0
        initial_pose_qy: 0.0
        initial_pose_qz: 0.0
        initial_pose_qw: 0.0
        use_odom: true
        use_imu: true
        enable_debug: true
        global_frame_id: map
        odom_frame_id: odom
        base_frame_id: base_link

I have seen from #20 that ndt_resolution should be kept with in 0.5 ~ 1.0 but for me that just makes localization to be lost, plus it also has high cpu usage.
I would appreciate any hint you might give to solve this problem. Thanks!

Sorry. GICP_OMP is under-verified. It's possible that NDT and GICP are not processing fast enough. I will provide advice regarding NDT_OMP.
The recommended parameters are as follows, and if the CPU usage is high with these settings, I feel this package might not run well on that PC.
/**:
  ros__parameters:
        registration_method: "NDT_OMP"
        score_threshold: 2.0
        ndt_resolution: 1.0 # 0.5 ~ 1.0
        ndt_step_size: 0.1
        ndt_num_threads: 4
        transform_epsilon: 0.1
        voxel_leaf_size: 0.5 # 0.1 ~ 0.5
        scan_max_range: 50.0
        scan_min_range: 1.0
        scan_period: 0.1
        use_pcd_map: true
        map_path: "/home/map.pcd"
        set_initial_pose: true
        initial_pose_x: 0.0
        initial_pose_y: 0.0
        initial_pose_z: 0.0
        initial_pose_qx: 0.0
        initial_pose_qy: 0.0
        initial_pose_qz: 0.0
        initial_pose_qw: 0.0
        use_odom: true
        use_imu: true
        enable_debug: true
        global_frame_id: map
        odom_frame_id: odom
        base_frame_id: base_link

Thanks for your response. Can we use GPU accelerators with this package to reduce CPU load?

It has not been implemented yet. You might want to consider adding the following: https://github.com/koide3/fast_gicp


RealtekALC887-VD by InsanelyDeepak

Layout_ID 11 = 3 ports supported (Pink, Green, Blue, CodecAddress:
2, Disable Auto-Switch : you have to manually switch between Speakers
and Headphones) AC97 Front Panel Headphone Support
Layout_ID 12 = 3/4 ports supported (Pink, Green, Black, Orange,
CodecAddress: 2)
Layout_ID 13 = 5/6 ports supported (Pink, Green, Black, Blue,
Orange, CodecAddress: 2
Layout_ID 14 = 3/4 ports supported (Pink, Green, Blue, Orange,
CodecAddress: 0)
Layout_ID 15 = 5/6 ports supported (Pink, Green, Blue, Orange,
CodecAddress: 0)

@vandroiy2013 I guess this is safe to merge?

@vit9696 Why not... Let's try this layouts on applelife. They have some problems with this codec..

Yes this is fool proof , cuz i was noob to use git , now add it and new codecs are coming ALC662 and A665

Thanks

if you have some tips plz provid me
Thank you Guys


⚠ Bofrost.de has degraded performance

In dfbc5b6, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 2011 ms

Resolved: Bofrost.de performance has improved in 80d0efa after 18 minutes.


Link docs for theme editor

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
In the theme editor on the right side panel,  add short text:

Customize the app with a MUI theme. Read more about this in the docs.

@prakhargupta1 , is it available/triaged to take up ? I am willing to work on this ? a

Taking this up


Does Dragonfly support pulling singularity container images from the Harbor?

Question
Does dfdaemon support pulling singularity images from harbor using oras URI?
Example:

singularity pull mytest.sif oras://<IP_ADDRESS>:65001/:

More details about singularity image pull : https://sylabs.io/guides/3.2/user-guide/cli/singularity_pull.html

+1
I noticed that in order to get this to go through the tunneling, I had to specify the proxy in front of the singularity command:
HTTPS_PROXY=<IP_ADDRESS>:65002 HTTP_PROXY=<IP_ADDRESS>:65002 singularity pull oras://registry.com/project/image:tag
However, this does not utilize "dfget" even though I list the registry name underneath the "proxies" section as a regx.

Supports.


Hydration

Add hydration stats.
Closes issue #54

Summary by CodeRabbit

New Features

Introduced DailyHydration data class for tracking daily hydration statistics.

Bug Fixes

Fixed VCR decorator syntax in multiple test files.

Tests

Added comprehensive tests for new DailyHydration functionality.

Chores

Updated version to 0.4.47 for new release.

Documentation

Added configuration settings for yaml-language-server.

Refactor

Removed unused BASE_PATH constant.

@coderabbitai suggest changes to the README

@coderabbitai review

@coderabbitai review

@coderabbitai full review


Improve 404 error webpage

The 404 webpage need to be improved:

We could do this in the same style of this change:
https://github.com/codalab/codalab-competitions/pull/3042

Fixed by #815


Information about messages sent.(FEATURE REQUEST)

Is your feature request related to a problem? Please describe
No.
Users need to know who sen't a content (video, photo, etc..) and the basic information (who saw it, who recieved it).
Describe the solution you'd like
Add optional prop with this purpose.
Additional context
Like in What'sApp and Facebook.

In that btn menu you would add an "info" option, or "information", the name doesn't matter.

If there are only 2 users in the rooms, who sent the message and who received it is obvious.
If there are 3+ users in the room, the username is displayed on each message to know who sent it.
If you want to add more options in the menu showcased in your screenshot, you can use the messageActions prop coupled with the messageActionHandler event to create and manage your own options.
I just fixed an issue so you can get the message data when calling messageActionHandler: https://github.com/antoine92190/vue-advanced-chat/commit/60b872ad7a55d1edb2db36509869305ad9cc2ff6
Would that help with your issue?


discard more cron jobs than 10 if sent fast

perl -MNet::MQTT::Simple=loppen.christiania.org -e '
publish "/config/v1/9999999/clear_cron" => "";
publish "/config/v1/9999999/set_cron" => "minute=00&hour=&day_of_month=24&month=9&day_of_week=&command=open";
publish "/config/v1/9999999/set_cron" => "minute=02&hour=&day_of_month=24&month=9&day_of_week=&command=close";
publish "/config/v1/9999999/set_cron" => "minute=10&hour=&day_of_month=24&month=9&day_of_week=&command=open";
publish "/config/v1/9999999/set_cron" => "minute=12&hour=&day_of_month=24&month=9&day_of_week=&command=close";
publish "/config/v1/9999999/set_cron" => "minute=20&hour=&day_of_month=24&month=9&day_of_week=&command=open";
publish "/config/v1/9999999/set_cron" => "minute=22&hour=&day_of_month=24&month=9&day_of_week=&command=close";
'
perl -MNet::MQTT::Simple=loppen.christiania.org -e '
publish "/config/v1/9999999/set_cron" => "minute=30&hour=&day_of_month=24&month=9&day_of_week=&command=open";
publish "/config/v1/9999999/set_cron" => "minute=32&hour=&day_of_month=24&month=9&day_of_week=&command=close";
publish "/config/v1/9999999/set_cron" => "minute=40&hour=&day_of_month=24&month=9&day_of_week=&command=open";
publish "/config/v1/9999999/set_cron" => "minute=42&hour=&day_of_month=24&month=9&day_of_week=&command=close";
publish "/config/v1/9999999/set_cron" => "minute=50&hour=&day_of_month=24&month=9&day_of_week=&command=open";
publish "/config/v1/9999999/set_cron" => "minute=52&hour=&day_of_month=24&month=9&day_of_week=&command=close";
'

mqtt rpc dispatcher should start stuff in timers

fixed in d70ec9482bfec7aeb26bab50c7bfb2a051f8e648


WIP: Various Bug Fixes

[x] #2—Default to quad view
[x] #11—visualization module should be namespaced
[ ] #10—Add cascading delete to the UI
[ ] #7—Painting resets the 3D view

@floryst I'm going to try to pick off some bugs from your list. We can merge whenever you feel like there's enough.

Sounds good to me! I'll do some bug hunting to see what else I can find.

@floryst Can you spot check the last commit? I think I've got most of the namespacing done but would be good to know what I missed.

@floryst After all the fixups for namespacing the visualization module, most things generally appear to be functioning. Is there specific functionality I should test?

So long as things are working, I'm good to merge this. We can fix things up later.


offer a consolidated yearly invoice for sponsors

Some sponsors prefer to deal with one yearly invoice instead of 12 separated invoices.
We should offer a yearly consolidated invoice.

To make this happen:
API
We should rely on the Invoice query. As of today, all the information is parsed from the invoice slug. It's not a good practice because there's no graphql validations on these params, so something we can do is to add new params that are used instead of the slug if provided:

dateFrom
dateTo
collective
fromCollective

The good thing about doing so is that the API would work in the exact same way for monthly, yearly or biannual invoices.
Frontend
We need to specify where the links to the yearly invoices should appear. I propose that we add tabs on the invoices popup to choose between monthly and yearly:

Invoices
The only thing needed in the invoices project is to add the new API requests and routes.

I'm working on this.

Hi @pietgeursen, thanks for taking care of this issue! Just add a comment here or ping me on Slack if I can be of any help :slightly_smiling_face:

@Betree
Invoice slugs and date ranges
At the moment there as an invoice "slug."
It's a string that looks something like: 201710.brusselstogether-host.xdamman.
Unfortunately the slug encoding can't represent date ranges.
Implications for Invoices
The invoice slug is used to generate the invoice filename and reference field.
The invoice also has a Date field that used the invoice.date.
Implications for the API + Invoices server
The api exposes a slug field on an invoice. That field is used by the frontend to generate links to the Invoice server.
Then the Invoice server uses those slugs to hit the graphql api to generate a specific invoice.
Options
Make a new slug format and upgrade all the code to use that new encoding. Don't be back compatible with the old format.
We could use something like:<PHONE_NUMBER>10.brusselstogether-host.xdamman
:-1: Breaking change to the api.
:-1: We still have invoice slugs.
Make a new slug format (like the one above) but only use it when getting invoices with a date range.
We could keep the current Invoice route the same for old slug types and add a new one for invoices with a date range.
:-1: Then we have two encodings. All parts of the code need to be able to parse both sorts of encoding because graphql consumers expect an invoice to have a slug field.
:-1:  The graphql Invoice endpoint needs to be able to handle two different slug encodings + {dateFrom, dateTo, collective, fromCollective}
:-1: Code is harder to maintain.
:+1: Could be made back compatible
Completely remove the invoice slug from the code...
:-1:  Breaking change to the api.
:+1: Will be most maintainable solution.
Questions
What should the Date field be on the invoice when a date range is used?
What should the reference field + filename be when using date ranges?
Which of the three options (if any) should we go with?
PS: I'm happy to jump on a quick call if that's faster + easier.
cc @mixmix who's been working with me on this today.

That's a good thing to raise this up. I've been maintaining this legacy slug for backward compatibility but now that we've migrated invoices to their own service and that I have a better understanding of it, I'm confident that we should re-think that part instead of hacking it.
I don't like the fact that we use a slug because it breaks really easily and it's not extensible. For example I quickly patched it to use . instead of - because collectives like my-collective had broken invoices links<PHONE_NUMBER>10-brusselstogether-host-xdamman).
So I'd be in favor of Completely remove the invoice slug from the code..., maybe we can progressively deprecate the endpoints using slugs so that the breaking change doesn't result in any error for users.

What should the Date field be on the invoice when a date range is used?

I'd deprecate the year/month/date fields to instead use startDate and endDate.

What should the reference field + filename be when using date ranges?

For transactions (no change): transaction-{uuid}.pdf
For all other invoices: ${host}_${fromCollective}_${startDate}-${endDate}.pdf
(feel free to propose better alternatives)

maybe we can progressively deprecate the endpoints using slugs so that the breaking change doesn't result in any error for users.

What would this look like? I don't have enough context about the system. Is this something that can be done in the course of a day by deploying the right repos in the right order? Or are there other systems relying on this api that need time to adapt to a deprecated api?

What should the Date ~field~ be on the invoice when a date range is used?

I'd deprecate the year/month/date fields to instead use startDate and endDate.

Just to be clear, I'm talking about the pdf / html of the invoice. It has a date. But should it display the date range now? Any guidance on how you want that to look?

No other systems rely on this. Invoices are not a critical service so it's not a big deal if we aren't reverse compatible, however it's good if we can avoid broken links if frontend / invoices services are not updated at the same time.
The way to do that would be:
API

Add a deprecationReason on the old API fields (example)
Add the new fields

Invoices

Create the new endpoints (eg. server.get('/:collectiveSlug/:host/monthly'))
Add a comment on old endpoints to mark them as deprecated

Frontend
Change to the new endpoints, old endpoints should still work.

Once everything is deployed and tested, make another PR to remove all the deprecated fields and endpoints.
Migrating like that can sometimes be painless but again, if you hit too much walls while doing so then a breaking migration is acceptable for this service.

Just to be clear, I'm talking about the pdf / html of the invoice. It has a date. But should it display the date range now? Any guidance on how you want that to look?

Yes it should.

Invoice type transaction: year/month/day (no change)
Invoice type monthly: year/month (no change)
Invoice type yearly: year
Custom range: year/month/day - year/month/day

Dates should be formatted with the FormattedDate component so we can easily localize them later.
So I guess the new endpoint should be something like:
/:collectiveSlug/:host/:type(monthly|yearly|custom-date-range)

Hi @pietgeursen, have you started to work on that one? I need to make some modifications to invoices but I'd prefer to do it once you're done to avoid conflicts.

yes @pietgeursen has done 16+ hours of work on this - it's touching several repos. We (hi I'm from the same coop as Piet and paired for a couple of hours on this) need to catch up about where this issue is at, what standard you want this work to, and probably the size of it (time / money)

Ok I'll wait until we merge it then. In the same time I'm available on Slack if you need anything.

Hey @Betree,
I had a productive day on this today. I'm out of energy for now but I'm really close to being done.
I'll have something for you to review in 24 hours I think.
I've got 3 WIP PR's that you can check if you like.
https://github.com/opencollective/opencollective-frontend/pull/1618
https://github.com/opencollective/opencollective-api/pull/1849
https://github.com/opencollective/opencollective-invoices/pull/30

@pietgeursen I gave them a quick look and it seems really good, the code is clear. Thanks for adding tests too. Please tell me when it's ready for review :slightly_smiling_face:

@Betree Ok, I think they're ready. :smile:

Hi @pietgeursen! I'll review it today. In the same time I've updated the bounty amount for this task, my first evaluation for the complexity was really bad in regard of all the refactors needed.

You really did a great job on this one @pietgeursen. The code is clean, tested and you took the extra-step of refactoring the GraphQL queries properly so that it will be easier to maintain in the future. It was a pleasure to review it!
I'll merge everything on Monday.
:trophy: You can claim the bounty by submitting an expense to https://opencollective.com/engineering !

<3 <3 <3
I'm planning to have a go at an issue soon.
Would be great to do a reflection on how the bounty process went for everyone. We can do this public/ private, and in text/ a call
On Apr 6 2019, at 6:39 am, Benjamin Piouffle<EMAIL_ADDRESS>wrote:

You really did a great job on this one @pietgeursen (https://github.com/pietgeursen). The code is clean, tested and you took the extra-step of refactoring the GraphQL queries properly so that it will be easier to maintain in the future. It was a pleasure to review it!
I'll merge everything on Monday.
🏆 You can claim the bounty by submitting an expense to https://opencollective.com/engineering !
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/opencollective/opencollective/issues/1783#issuecomment-480361432), or mute the thread (https://github.com/notifications/unsubscribe-auth/ACitnltOTRF26Hzc1sBOV97flVLt7GTDks5vd4pogaJpZM4bc9z8).

@mixmix We should! We're learning on the process and are eager to improve the experience. I'm sure @alannallama and @znarf will be happy to join too.

@Betree this can be closed, right?

Yep, it's live and working fine. Thanks again to Piet!


Lectures: Allow comma-separated keyphrases for automatic slide removal during unit processing

Follow-up of https://github.com/ls1intum/Artemis/pull/7060
Checklist
General

[x] I tested all changes and their related features with all corresponding user types on a test server.
[x] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Server

[x] Important: I implemented the changes with a very good performance and prevented too many (unnecessary) database calls.
[x] I followed the coding and design guidelines.
[x] I added multiple integration tests (Spring) related to the features (with a high test coverage).
[x] I documented the Java code using JavaDoc style.

Client

[x] Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data.
[x] I followed the coding and design guidelines.
[x] Following the theming guidelines, I specified colors only in the theming variable files and checked that the changes look consistent in both the light and the dark theme.
[x] I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
[x] I documented the TypeScript code using JSDoc style.
[x] I added multiple screenshots/screencasts of my UI changes.
[x] I translated all newly inserted strings into English and German.

Motivation and Context
Fix issue: #7039 / https://github.com/ls1intum/Artemis/issues/7039#issuecomment-1688489883
Description

Merge both input text fields into one.
Send the comma-separated list with the DTO
Check the input value in LectureUnitProcessingService and remove slides.

Steps for Testing
Prerequisites:

1 Instructor

Log in to Artemis
Edit or create a new lecture
Select Automatic unit processing
Upload a prepared slide deck
Click Process units
Type in the list of comma-separated key phrases
Submit

Review Progress

Performance Review

[ ] I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance
[ ] I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance

Code Review

[ ] Code Review 1
[ ] Code Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

Screenshots

The remove solution slides feature is currently seemingly duplicated on purpose. In the future, these slides should not just get removed, but hidden. Instructors should have the ability to re-add them again at a later point. I'd suggest for now to just leave this solution slide functionality like it is and only add the manual keyboard to the slide-removal feature.

@Strohgelaender What is duplicated? https://github.com/ls1intum/Artemis/pull/7060 was implemented and merged, but I got feedback to change the input to a comma-separated list.

only add the manual keyboard to the slide-removal feature

You mean implement just the comma-separated list? That was the intention :)

@terlan98 It is throwing here https://github.com/ls1intum/Artemis/blob/feb6b757bddf04269bb84feed763f5a7e04efc69/src/main/java/de/tum/in/www1/artemis/service/LectureUnitProcessingService.java#L191
I does not call my code, but I will see what I can do

When the keyphrase is a word that is contained in every slide, such as a word from the footer (see below), the generated unit PDFs are corrupted:

My guess is that the result has 0 pages,


Query: Create-subscription RPC and Notification handling at netconf server

Hi,
One query related to having RPC subscription for create-subscription in application and sending notifications for another session overlap, causing drop of notifications at Netconf client as message RPC Ok is not received yet, and further no notification is received further for Netconf client.  Any suugestions, how can we handle such situations.
Logs from netopeer server:
Create subscription from Session 1 from Client 1.

 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 2 priority 5 for 1 subscribers published.
 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 2 priority 5 succeeded.

 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 2 priority 0 for 1 subscribers published.
 netopeer2-server[1735]: EV LISTEN: "/notifications:create-subscription" "rpc" ID 2 priority 0 processing (remaining 1 subscribers).
 netopeer2-server[1735]: EV LISTEN: "/notifications:create-subscription" "rpc" ID 2 priority 0 success (remaining 0 subscribers).
 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 2 priority 0 succeeded.

Create subscription from Session 2 from Client 1

 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 3 priority 5 for 1 subscribers published.
 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 3 priority 5 succeeded.

 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 3 priority 0 for 1 subscribers published.
 netopeer2-server[1735]: EV LISTEN: "/notifications:create-subscription" "rpc" ID 3 priority 0 processing (remaining 1 subscribers).

 Notification was sent from application in context of session 1 from Client 1

 netopeer2-server[1735]: EV LISTEN: "ietf-hardware" "notif" ID 1 processing.
 netopeer2-server[1735]: EV LISTEN: "ietf-hardware" "notif" ID 1 priority 0 success (remaining 0 subscribers).

 Create subscription from Session 3 from Client 1

 netopeer2-server[1735]: EV LISTEN: "/notifications:create-subscription" "rpc" ID 3 priority 0 success (remaining 0 subscribers).
 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 3 priority 0 succeeded.

 Create subscription from Session 4 from Client 1

 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 4 priority 5 for 1 subscribers published.
 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 4 priority 5 succeeded.

 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 4 priority 0 for 1 subscribers published.
 netopeer2-server[1735]: EV LISTEN: "/notifications:create-subscription" "rpc" ID 4 priority 0 processing (remaining 1 subscribers).
 netopeer2-server[1735]: EV LISTEN: "/notifications:create-subscription" "rpc" ID 4 priority 0 success (remaining 0 subscribers).
 netopeer2-server[1735]: EV ORIGIN: "/notifications:create-subscription" "rpc" ID 4 priority 0 succeeded.

We checked and code seemed to be simialr, still pasting the snippet, in case you can help pointing out if there is something wrong here.
Client Code:
=============
int ncClient::startNotifMon(std::string hostId, nc_session* session, const char* stream, const char* filter)
{
...
/* create requests */
rpc = nc_rpc_subscribe(stream, filter, NULL, NULL, NC_PARAMTYPE_CONST);
...
int ret = rpc_send_recv_reply(hostId, session, rpc);
nc_rpc_free(rpc);
if (ret == FAILURE)
return FAILURE;

ret = nc_recv_notif_dispatch(session, &ncClient::lnc2_notifClb);
if (ret)
{
_error << hostId << ", session[" << nc_session_get_id(session) << "], msg: failed to create notif thread."<<std::endl;
return FAILURE;
}

return ret;
}

int ncClient::rpc_send_recv_reply(std::string hostId, nc_session* sess, struct nc_rpc* rpc)
{

...
msgtype = nc_send_rpc(sess, rpc, NCCLIENT_TIMEOUT, &msgid);
...
recv_reply:
msgtype = nc_recv_reply(sess, rpc, msgid, NCCLIENT_TIMEOUT,
LYD_OPT_DESTRUCT | LYD_OPT_NOSIBLINGS, &reply);
if (msgtype == NC_MSG_ERROR)
{
_error << hostId << ", session[" << sess_id << "], msg: failed to receive a reply for rpc[ " << rpc_type << "]."<<std::en
dl;
return FAILURE;       ==> As we get NC_MSG_ERROR for nc_recv_reply
}
else if (msgtype == NC_MSG_WOULDBLOCK)
{
_error << hostId << ", session[" << sess_id << "], msg: timeout for receiving\
a reply expired for rpc[ "
<< nc_rpc_get_type(rpc) << "]."<<std::endl;
return FAILURE;
}
else if (msgtype == NC_MSG_NOTIF)
{
/* read-action */
goto recv_reply;            ==> in case of msgtype is NOTIF it is trying to receive reply again
}

...

}

Libnetconf Code:
================
API NC_MSG_TYPE
nc_recv_reply(struct nc_session *session, struct nc_rpc *rpc, uint64_t msgid, int timeout, int parseroptions, struct nc_reply **r
eply)
{
...
msgtype = get_msg(session, timeout, msgid, &xml);
...
return msgtype;
}

static NC_MSG_TYPE
get_msg(struct nc_session *session, int timeout, uint64_t msgid, struct lyxml_elem **msg)
{
...
/* we read notif, want a rpc-reply */
if (msgid && (msgtype == NC_MSG_NOTIF)) {
if (!session->opts.client.ntf_tid) {
ERR("Session %u: received a  but session is not subscribed.", session->id);
lyxml_free(session->ctx, xml);
return NC_MSG_ERROR;   ==> this is causing out client code to fail and not to retry for recv_reply
}
...
}
Thanks!

That is not what netopeer2-cli does. Looking at it, you would write your code like this
int ncClient::startNotifMon(std::string hostId, nc_session* session, const char* stream, const char* filter)
{
...
    /* create requests */
    rpc = nc_rpc_subscribe(stream, filter, NULL, NULL, NC_PARAMTYPE_CONST);
...
    ret = nc_recv_notif_dispatch(session, &ncClient::lnc2_notifClb);
    if (ret)
    {
        _error << hostId << ", session[" << nc_session_get_id(session) << "], msg: failed to create notif thread."<<std::endl;
        return FAILURE;
    }

    int ret = rpc_send_recv_reply(hostId, session, rpc);
    nc_rpc_free(rpc);

    return ret;

}

with some changes to avoid memory leaks. There is the short span of time when you subscribe but are not receiving notifications yet and when a notification arrives then, you get the error.


Accessing stats using time range in kubelet does not work

Cadvisor API support querying stats between a Start and a Stop timestamp. That interface does not work via the kubelet. Is there anything special about the way cadvisor is setup when run inside kubelet?
cc @vmarmol

We don't have the right version of cAdvisor included :) will send a PR now to update it.

This issue is still not-fixed on HEAD.


Feature: CPI Events API

Adds emit_cpi to allow programs to store logs in CPI data, the same way Metaplex's compressed NFTs do.
Closes #2408

Unfortunately I cannot move the _emit_cpi_data and emit_cpi macro into the lang/attribute crate because attribute crate is a proc_macro crate, and emit_cpi is a declarative macro, which are incompatible exports. ie attribute can only export proc_macro macros 🙃

Rewrote emit_cpi as a proc_macro that takes a tuple (AccountInfo, <dyn anchor_lang::Event>)

FWIW I've attempted to write up an explanation of CPI Events here, along with additional tests: https://github.com/ngundotra/srfc-event-indexing

@acheroncrypto absolutely, looking forward to seeing your changes.
Let me know if you want to delegate some work back to me on improving this.

Here is the summary for usage with my last changes:
Instruction
pub fn my_instruction(ctx: Context<MyInstruction>) -> Result<()> {
-    emit_cpi!(
-        ctx.accounts.program.to_account_info(),
-        ctx.accounts.event_authority.clone(),
-        *ctx.bumps.get("event_authority").unwrap(),
-        MyEvent { data: 5 }
-    );
+    emit_cpi!(MyEvent { data: 5 });
    Ok(())
}

Accounts
+#[event_cpi]
#[derive(Accounts)]
-pub struct MyInstruction<'info> {
-    /// CHECK: this account is needed to guarantee that your program is the one doing the logging
-    #[account(seeds=[b"__event_authority"], bump)]
-    pub event_authority: AccountInfo<'info>,
-    pub program: Program<'info, crate::program::MyProgramName>,
+pub struct MyInstruction {}

Client
-await program.methods
-.myInstruction()
-.accounts({
-  eventAuthority: anchor.web3.PublicKey.findProgramAddressSync(
-    [Buffer.from("__event_authority")],
-    program.programId
-  )[0],
-  program: program.programId,
-})
-.rpc();
+await program.methods.myInstruction().rpc();

Last changes:

Anyone was able to invoke the event handler before 87652d2. We're now validating the event authority signed the transaction and is correct key in the event handler instruction, added a test case for this so that only the program itself can invoke the event handler.
Removed the #[account(address = crate::ID)] check from the main instruction because we're invoking with crate::ID as the program id and it will fail if the program wasn't passed in.
Renamed the no-cpi-eventsfeature to event-cpi and made the feature opt-in instead of opt-out.

@ngundotra let me know what you think.

This works great! The emit_cpi!{} macro just works, and the #[event_cpi] attr is great.
I think we need 2 changes to the JS sdk tho.

We need a method like program.cpiEvents.parseTransaction() and gives a list of events from a transaction
Probably the eventAuthority address derivation on program.addresses.eventAuthority (and probably export IDL similarly like program.addresses.idl) - probably can be done in another PR

What do you think?

I think we need 2 changes to the JS sdk tho.

We need a method like program.cpiEvents.parseTransaction() and gives a list of events from a transaction
Probably the eventAuthority address derivation on program.addresses.eventAuthority (and probably export IDL similarly like program.addresses.idl) - probably can be done in another PR

What do you think?

Yeah client side needs improvement and I think both of those can be made in a separate PR.
One potential issue here is that we are deriving the key each time the event handler is called to validate the authority(on top of deriving it on the main instruction) but the authority key and bump does not change and can be hard coded inside the program. The solution would most likely be a similar macro to declare_id! which kind of sucks. I'll come back to this if it causes noticable difference in compute units.
I've added and updated the documentation and looking to merge this soon if it looks good to you as well.

Awesome, that sounds like a plan.
Thanks for updating documentation, your changes look great to me. I tested externally by importing in another standalone repo, and it works like a charm.
🚢  it


Add basic features to portfolio website

I included a basic banner and navigation bar to the website template. I also added in a projects and about section. There is a bit of styling, but it's mostly solid colors and centering.

I really like your commit messages!


Create-Plugin: Transform known ES modules in jest config

What this PR does / why we need it:
The previous PR that addressed issues with loading es modules by transforming all modules in node_modules introduced an issue where SWC will error if a package contains code the typescript compiler doesn't appreciate.
One example of this is reassignment of a class (something we do in grafana/data).
I'm not sure if there's a better way to solve this but I'm now leaning towards maintaining a list of packages as a solution mentioned in #111.
Which issue(s) this PR fixes:

Fixes #111
Special notes for your reviewer:

📦 Published PR as canary version: Canary Versions

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

@jackw This causes some issues, maybe something missing in the migration script?

Error: Cannot find module './jest/utils'

Require stack:

- /drone/src/.config/jest.config.js

https://drone.grafana.net/grafana/clock-panel/35/1/5
https://github.com/grafana/clock-panel/pull/110

Thanks for the heads up @tolzhabayev I'll get it fixed! 🙏


Multiple frames from video

Does it work with multiple frames?
I tried reading sequential frames froma folder, converting to base64 and appending but I get an error when using chat_model.chat(inputs). Is this supported?
test_video.txt

hi, this is a very good try. it is capable of inputting multiple images. But of course, it wasn't trained on video scenarios, which leads to the fact that he may not be very good. You can have a try.
please refer to this link
https://huggingface.co/openbmb/MiniCPM-Llama3-V-2_5/discussions/2


Rda as data format

Like you, I often use R's binary Rda format for storing data.  The benefit is that it's compact and you get out exactly what you put in.  The latter is not necessarily the case with CSV files.  For example, a factor is indistinguishable from a character vector in CSV and you lose extra information in factors such as the contrast coding.  However, Rda has one important draw-back for the current purpose: it's not necessarily future-proof.  The format has historically changed and when that happens it's really annoying for users because they have to install older versions of R to read the data.  CSV and similar formats (I prefer tab-separated values) will of course always be readable, not just with R but also with a wide range of other programs like Excel et al.

Agreed. I got into trouble with Hadley Wickham for wanting to store text files as data in a package. I have had the exact problem you describe, and for my own data---I couldn't read it any more after a few years. I will back off to simple text data as you suggest.

However, stan precomputed data will have to remain in Rda format, it is too large to be stored any other way. I may also compress it in future. But this is OK because I will provide code for regenerating this data in my vignettes.

There are efforts to develop a robust cross-platform format but that is in early stages and I think limited to data.frames.  So that's not really a solution.

Another consideration: not everyone is using R and I think that research data should be readable for everyone not just for R hackers.  Most of us may be using Julia a couple of years down the line and all those Rda files may be a huge annoyance then.  Of course someone may write a Julia package for reading Rda but R's data types do not map to Julia's 1-to-1 so this will not work without problems.


newbie first: i specify 7.2 but dashboard shows 7.1

In a completely fresh install win10, I specify php 7.2, but the dashboard says 7.1. Then when I SSH into the vm it says 7.2. What am i missing here?

Not quite sure; if you install Drupal and go into the Drupal site's site report section, what version of PHP does it indicate there? Is there a chance you're running two copies of Drupal VM? Any other customizations in your config.yml file besides php_version: "7.2"?


Instagram hack

Can anyone help me to hack

https://www.instagram.com/aoyon07?igshid=OGQ5ZDc2ODk2ZA==
Please I Need This Userpaasword he literally disturbing my girlfriend

#128


New properties on ApiTradeHistoryDTO > OpeningOrderIds,  RealisedPnlCurrency, RealisedPnl

Check that these are generated correctly when they make it into the metadata

"Autoresolved" by #101


Changing autoplay from false to true after mount does not start to play

Description
I know its described in the docs, that the autoplay prop only affects the component on mount. In a full declarative way this is kind of unexpected and I had to read about it in the docs after I thought my code has a bug.
I wonder, is there a technical reason the prop can't be changed after the component has been mounted? Its already issuing a play command when the source is changed and autoplay===true. I know the name of the prop is autoplay and for my proposal the property better named playing.
The more declarative behaviour would probably no more then 3 lines of code, unless I am missing something?
componentDidUpdate(prevProps) {
  if (this.props.source.nm !== prevProps.source.nm && this.props.autoPlay) {
    this.play();
  }
  if (this.props.autoPlay != prevProps.autoPlay) {
    this.props.autoPlay ? this.play() : this.stop();
  }
 }

Steps to Reproduce
const [playing, setPlaying] = useState(false)

const onStartClick = useCallback(() {
  setPlaying(true)
}, [])

<LottieView ... autoplay={playing} />

Changing the playing var does not start to play the animation.
Expected behavior: [What you expected to happen]
Expected to animation to play.
Actual behavior: [What actually happened]
The animation was not played.

I'm running into this same issue but with a hook component. idk what is causing it either. I console.log the useState and uppon clicking it, it is turning true but the animation won't start playing

I'm running into this same issue but with a hook component. idk what is causing it either. I console.log the useState and uppon clicking it, it is turning true but the animation won't start playing

Any Solution i am having similar issue ?

Try changing the speed of LottieView using the setTimeout function.


Megafont update movement tutorial

Reworked existing parts of tutorial
Added jump test and conclusion sections to the tutorial
Vision test now requires you to move your view in a full 360 degree circle.
Added setting to vision test script so the amount of rotation needed to pass the test is settable in the inspector now
Fixed a bug where the player controls were still using the old input system so they wouldn't disable in the tutorial
Fixed bug where jump button didn't always work. This bug was caused by me when I updated PlayerMovement.cs to use Unity's new input system, rather than the old legacy input system.

This has merge conflicts.

Awesome job!
One thing is the new input system has more latency than the old one (like a frame or something including in builds), so I don't think we should use it for player movement. But it's being used to disable player input, so I think it'll be easiest to deal with as part of my inventory refactoring task, since in that I added a combined way to disable a bunch of things like opening the inventory.


Proposal: include metadata hash into signed payload

Currently the Signer needs trusted authority to verify correctness of metadata used. We could make this trustless if we ~require~ allow (edit 1: Signer should not be allowed to sign transactions with trivial blank metadata hash then) every transaction to include metadata hash into signed payload - this way the chain will be constantly verifying metadata validity instead of a trusted party.
This bears very little additional costs, deprecates lots of complex and confusing logic in Signer and makes automated generation of updates possible. Metadata portal might be reduced to a simple untrusted page with generator script since any attack on it will lead to Signer's DoS which is desired behavior.

This is about creating a signed extension that passes the metadata hash as additional signed data to the signature creation.
The signed extension should be fairly simple to implement, the problem for now is how to get the metadata hash in an efficient way.

We could match metadata to block mentioned in mortality for mortal transactions. Not for immortal ones though. Are immortal ones important?

In general I like the idea; this would also probably superseed the transaction_version field.

Not really, a runtime upgrade, aka changing metadata doesn't mean the transaction version changed.

What worries me, though, is how is it going to work "at margins" for transactions around the runtime upgrade enacted: will we invalidate the whole transaction pool immediately on each minor runtime upgrade? Will we have a grace period around this, accepting both? Would we allow issuing transactions for not-yet-accepted runtime in the pool (probably waiting for the relevant upgrade to be enacted)?

We are already rejecting all transaction from a previous runtime version. CheckSpecVersion is doing that.

The real question is how to have the signer verify the metadata hash trustlessly? It needs to run a light client? But I am not sure if it is possible for air gapped wallet?
We also needs to commit metadata hash to onchain state, which sounds like a complicated task to me.

The real question is how to have the signer verify the metadata hash trustlessly? It needs to run a light client? But I am not sure if it is possible for air gapped wallet?

The point of this being that the signer doesn't need to be able to verify the metadata at all. It will build the tx, based on the metadata that the user provided. The signature will then include the metadata hash, similar as we do it for spec_version. The runtime will then also add the metadata hash and if that uses a different hash, the signature verification will fail.

We also needs to commit metadata hash to onchain state, which sounds like a complicated task to me. You will want to do it with on_runtime_upgrade instead of a separate tx, so you will need to build a runtime, get metadata hash, and embed it into the runtime.

We could just include the metadata hash as part of the build process. Build the runtime once, get the metadata, generate the hash, build the runtime again and include the hash.

I'm kinda inclined to make this happen on the runtime and give a push to the ecosystem (Polkadot and Kusama included) to catch up. I think this will instigate more novel ways to distribute the metadata as well. Seems like a solvable problem, just stuck in a stalemate.

Is there any progress on this?
It looks like this will greatly enhance UX for everybody including developers and users. I'm currently working on implementation for HydraDX and Basilsik and we would love to see more widespread use of Parity signer so users can seamlessly use it between the parachains.

Niklas also suggested that such hashes could be a part of eg polkadot changelog or whatever if we wanted, so that people could compare and see at a high level what's changed shape between updates

Yeah, my point is that it's not shown by the CHANGELOG in polkadot whether a pallet had breaking changes because the pallets are not following semver versioning and then metadata hash per pallet could help with that.
It would help us to detect breaking changes in tools such as staking-miner-v2 and help others as well I reckon. Not sure how others deal with it but there are also subwasm which can be used but would much more user-friendly to have a list of the breaking changes in the CHANGELOG.

I still imagine that we put metadata into a merkle tree. We would need to find out which information we want to have part of this tree or if we just dump the entire metadata there. The root of this tree can be used to put into the wasm file as "metadata-root". This metadata root will then later be used to ensure that the online wallet has shown the correct data to the user, before giving the info to the offline signer as the offline signer would include the metadata root in the tx. Then the runtime can just reject extrinsics that use some unknown metadata root.
When the online wallet signes create some extrinsic, it would need to have some kind of "recorder" running that records all the accesses to the metadata tree. This recording is then used as proof and send to the offline signer. The offline signer would use this proof to decode the extrinsic data and show it to the user. The root of this proof is the metadata root that is then included in the extrinsic.
All of this requires some experimentation and work with some wallets to find out what metadata info they need, if we can build such a proof.  Would the proof be small enough to always send the proof to the offline signer? (This would for example remove the requirement to scan the entire metadata from the offline signer, but only worth is if the transmission speed is fast enough to do it always) How would be merkelize the metadata?

We need to pass whole metadata to offline signer for this to make sense.

I don't see any reason why we need to pass the entire metadata, when you want to only be able to decode this one transaction. You would check that the small part of the metadata is correct, by using the "metadata storage proof". You get all the data from the online device, but you include the "metadata root" in the extrinsic and that makes it secure, as the chain will reject the transaction if this root doesn't match.

where memory limitations do not allow storage of many metadata instances simultaneously

Which is even more an argument for not needing to send the entire metadata.

But then if you do any checks of this kind in hot device, you could have your metadata tampered with.
I think the solution could be if there is a unified protocol for extraction of metadata subset required for decoding that could be repeated by both hot device and chain nodes; we would not need to reference to tree root in this case, but we would have a proof that hot device did its job honestly. Can we pre-define all branches of this structure ahead of time? I doubt it, considering at least that we have batch calls that make metadata addressing quite arbitrary.
This could save us a lot of headache actually.
But any protocol that relies on honesty of hot device in metadata chopping without actually checking it would break security.

But then if you do any checks of this kind in hot device, you could have your metadata tampered with.

I did not spoke about any checks on the hot device. All the things I said above are secure and would ensure that the cold device used the correct metadata to decode the extrinsic. As otherwise the chain would reject the extrinsic if this didn't contained the correct metadata root (which declares the metadata and its content). This is basically the same as you secure the storage of each block.

Can we pre-define all branches of this structure ahead of time? I doubt it, considering at least that we have batch calls that make metadata addressing quite arbitrary.

We don't need to pre-define the branches. The hot device would record the branches it use to send these to the cold device.

But any protocol that relies on honesty of hot device in metadata chopping without actually checking it would break security.

This doesn't rely on the hot device to be honest. The metadata tree would be pre-defined by the metadata root and the chain knows this root. Meaning if the hot device would omit something, the root wouldn't match. Just read into storage proofs and how they work, as this is exactly the same mechanism here.

Ok, then I probably mistunderstood, this sounds good. Any ETA on this? This is really important question that would influence Kampela release time.

This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/faq-ledger-apps-a-safe-generic-app-design/3150/6

I wanted to write a quick update on a conversation that happened on matrix (in Kampela's channel: #Kampela:matrix.zymologia.fi) and say that there's some momentum to start experimenting and implementing this. It would be great to get a technical contact on each wallet/signing team (@jacogr, Nova, Talisman, Polkadot Vault team) to jump in here on this thread so that any development can be coordinated and this migration can be done quickly.

This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/the-ledger-app-debate-united-we-stand-divided-we-fall/3177/8

I still imagine that we put metadata into a merkle tree. We would need to find out which information we want to have part of this tree or if we just dump the entire metadata there. The root of this tree can be used to put into the wasm file as "metadata-root". This metadata root will then later be used to ensure that the online wallet has shown the correct data to the user, before giving the info to the offline signer as the offline signer would include the metadata root in the tx. Then the runtime can just reject extrinsics that use some unknown metadata root.

@jsdw Have you seen this?
The first step we need is to figure out the proper format for merklizing the metadata. Just to start the discussion, how about computing the metadata root hash based on this following key-value mapping
pallet_index ++ "C" ++ call_index => call metadata
We'd also want the merkle trie to contain some relevant subset of the type registry.
Any thoughts? Is this being discussed anywhere else?

@rphmeier  https://polkadot.polkassembly.io/post/1830 - yes it is, we'll submit an actionable proposal soon.
The trick is to trim the trie properly to avoid messy things like batch_call collecting whole metadata and future-proof the whole thing from inflating too much. Merkle is actually not the only promising solution, we plan to dig into it soon.

@Slesarew Excellent! I will take a look over it
May I suggest opening an RFC at https://github.com/polkadot-fellows/RFCs with the proposal when ready?

I have already started on some format. Basically I'm thinking about using some kind of binary tree where we keep the key outside of the trie. Basically we would collect all the leaf nodes in some BTreeMap with Key => Node. Then we would collect these into a binary tree. The tree would be automatically balanced in this case. The hash of the leaf node is the H(Key, Data).
The data of the leaf node then depends on what we are encoding. Aka more high level types or more low level types. We will need some kind of compression. A call that for example only is composed of u32, u32, u32 should be compressed into one leaf node. Basically we should check if a type id is reused somewhere and if not, we can merge it into the type. Fundamental types are always suited to be merged as they can be represent using an u8/enum.
The root node should probably be ExtrinsicMetadata plus the hashes of the childs. The extrinsic metadata is the basic information that we will always require. So, it should make sense to put it into the root.
Stuff like docs should be optional. By optional I mean they are in their own leaf node, so that certain implementations can fetch it and others can leave it out (like ledger).
These are some rough ideas that we can look into. Especially we need to find out how the proof size scales.

We may also save space by using other kinds of cryptographic accumulators (e.g. RSA accumulators). Merkle tries are not the most space efficient accumulators, but are typically used in blockchain settings only because of the ease of update. Since the metadata accumulator needs to only be produced ahead of time (when producing the new runtime blob), we should be able to avoid doing any merkle trie traversals in the signing hardware.
I assume this is what @Slesarew meant by

Merkle is actually not the only promising solution, we plan to dig into it soon.

Some more details on

The trick is to trim the trie properly to avoid messy things like batch_call
would be interesting too. I suppose to avoid duplicating type-encoding information across many calls?

Yes, I meant accumulators. Something like this gives some general idea.

I suppose to avoid duplicating type-encoding information across many calls?

That is really not the trickiest part; batch_call encodes all calls as its enum variants; to fit into Ledger, we'll have to trim enums within calls. I don't see why we would run into any serious problems here, but it would have to be done carefully. There are many other calls with quite large variant sets, not as large of course, but still not fitting well in small spaces.

That is really not the trickiest part; batch_call encodes all calls as its enum variants; to fit into Ledger, we'll have to trim enums within calls.

I don't get the problem. The argument to batch_call is basically the same information that you find in the ExtrinsicMetadata that I linked above. And for sure we don't want to put the entire Call enum into one blob, more like the outer enum with all its variants and the sub calls being in one blob. But each variant of the sub call (aka pallet call) are linking to a different blob that contains these information. So, for batch_call it will look like this:
[Call(.., Utility(ID(1), ..), ..), ID(0)], [Batch_All(Vec(ID(0)), ID(1)]

The type with ID(0) is the outer enum and the type with ID(1) is the batch_all variant. Stuff like Vec should be made a primitive type as well. This should safe us quite some space/indirection.

We may also save space by using other kinds of cryptographic accumulators (e.g. RSA accumulators). Merkle tries are not the most space efficient accumulators

Yeah that sounds reasonable. In the end the accumulator should not be that important? And we can just see what gives the best results for us.

In the end the accumulator should not be that important?

It probably is, if we are talking about highly memory-constrained devices such as the Nano S. We could chew through that much memory pretty quickly, unless the implementation does a streaming traverse and discards the path.
Though RSA accumulators could easily require more memory, and bilinear accumulators require some trusted setup.

I expressed myself badly. By "should not be that important" I meant for now where we first need to figure out the data structures to express the metadata in small pieces. The type of accumulator should then be almost "data structure agnostic" and just also needs to be chosen based on some criteria like small memory usage etc.

The root node should probably be ExtrinsicMetadata plus the hashes of the childs.

Just a small thing; given that the payload that needs signing is call_data + signed_extra_params + additional_params, should the metadata for the extra/additional stuff (https://github.com/paritytech/frame-metadata/blob/80ca5c2170928035e2adec9d2942a719086130fa/frame-metadata/src/v14.rs#L113) also be a part of the thing that's hashed to ensure tip/mortality etc align?

That is already part of the ExtrinsicMetadata, so it will be included.

This conversation is continuing on the milestone level in the project created for it: Milestone 1.1: Publish refined requirements for protocol #1
Worth noting that the timeline view is provisional as there are unknowns which will be addressed as the project progresses. You can check it out here.


not omitting bot token

Summary
invoking jsk py _bot.http.token covers the token, but invoking it as jsk py await _ctx.send(_bot.http.token) does not
Reproduction steps
doing jsk py await _ctx.send(_bot.http.token)
Expected results
Covering the token in both ways
Actual results
It didnt the cover in jsk py await _ctx.send(_bot.http.token)
Checklist

[ ] I have updated discord.py and jishaku to the latest available versions and have confirmed that this issue is still present
[x] I have searched the open issues for duplicates
[ ] I have shown the entire traceback, if possible
[ ] I have removed my token from display, if visible

System information
Jishaku v1.18.2, discord.py 1.3.2, Python 3.8.2 (default, Mar 10 2020, 03:00:36) [GCC 7.4.0] on linux

This isn't a bug. Let's discuss why.
I have a set of rules that I follow while designing and developing Jishaku.
While some of these are documented or enforced by circumstance (e.g., 'all code must comply by the pylint/flake8 rules or have commented exceptions in the code, else the CI will fail and the publish process for a new version will fail'), most of the rules I set either by word of mouth or just personally retain as part of my development or design principles.
One of these unspoken design principles is the reason why this behavior isn't a bug. I'll write it out in plain English for reference later, but for now, I'm going to try and see if you can derive what the rule is from a set of examples regarding the design of the REPL components that back AsyncCodeExecutor, and by extension, jsk py and jsk pyi.
A REPL with a little more
Jishaku's design motive is to be a Discord-based frontend for evaluating and executing code.
It takes a lot of inspiration from how the standard Python REPL works - the one you get when you just run python, but simple Python evaluation isn't all Jishaku offers within its environment.
Let's go over some features Jishaku adds, starting from "least obviously magic" to "most obviously magic" (a sort of increasing nonstandardness). I'll also include how it differs from what you'd expect with standard Python, for reference.
Returned values are sent back to Discord
When you execute a block of code that contains a return, the value returned is sent to Discord as a message.

The value is interpreted and sent in whatever format is deemed most appropriate. For instance, discord.Embed instances get sent as actual embeds, discord.File instances get uploaded, etc.
This is the "most standard" behavior, because typically all eval or REPL command implementations have some variant of this kind of behavior. Some even have automatic await, but Jishaku doesn't.
What Would Python Do (WWPD)?
Either:

nothing  (return value ignored)
SyntaxError: 'return' outside function

Bare expressions at the end of the top-level scope are sent back to Discord
When you execute a block of code that includes a bare expression at the end that isn't in control flow (such as for, while, if, etc), the value of the expression is sent back to Discord as a message.

This follows the same display procedures as returning. It is sometimes referred to as an "implicit return" in old documentation, but this isn't always how it's implemented, as we will soon find out.
What Would Python Do (WWPD)?

nothing  (expression would be evaluated but nothing else would happen, for basic operations the bytecode may optimize it out - see "Statement seems to have no effect" pointless-statement (W0104) from the pylint documentation)

Yielded values are sent back to Discord
When you execute a block of code that includes yield statements, the yielded values are sent back to Discord as messages.

This is similar to the "implicit return", except it doesn't halt execution. This allows data to be sent back easily during longer evals, or in situations where states may have to be read at different times (such as wanting to check the attribute of an object before and after a given function call).
The message is even sent back to the evaluation context from the yield, allowing it to be inspected or edited.

What Would Python Do (WWPD)?
Depends on the exact context, but typically:

SyntaxError: 'yield' outside function
TypeError: object async_generator can't be used in 'await' expression

Yielding and returning values can be mixed.
When you execute a block of code that includes both 'yield' and 'return', they both work and function as expected.

While you may not see this as weird, this is actually nonstandard because it is usually not allowed for yield and return (with a value) to both be in an async generator (although it is OK for normal generators to have them).
To deal with this, Jishaku automatically packs out return x into the two separate statements when yields are present:
yield x
return

This allows returning of values to not require the cognitive overhead of checking whether it already contains a yield, as Jishaku makes the transformation for you.
What Would Python Do (WWPD)?

SyntaxError: 'return' with value in async generator

Import expressions
When a name is suffixed with an exclamation mark (!), the name is treated as a module and is implicitly imported for direct usage.

The module name to be imported can even be a submodule:

This is the most 'nonstandard' feature because it's effectively an in-Python extension of standard syntax. It allows what is usually a tedious procedure to write longform to be done quickly and effectively in-line, with nothing more than the acknowledgement of what needs to be imported.
What Would Python Do (WWPD)?

SyntaxError: invalid syntax

So what's the rule?
If you haven't yet figured out what the rule is, now's your chance to stop and reflect on the features I've highlighted above. I've formatted them very specifically, so try to pick out the pattern.
Here's an image to act as a scroll buffer while you think.

The answer, as you might expect, lies in the What Would Python Do (WWPD)? section.
Do you notice how for each of these changes, the way Python traditionally reacts is either by doing nothing or raising an exception? Or, in terms more fitting to this context, no feature modifies existing behavior as to subvert the developer's expectations?
This is the fiber that makes up one of the primary design philosophies that underpins Jishaku as an REPL. In plain English, it goes something like this:

When evaluating code, the intention of the developer is to be maintained; no amount of magic or extensibility should cause the effect of a given block of code to become unpredictable, or to have its behavior be in direct conflict with what is written.

Jishaku is a toolset designed to be used for legitimate, serious development and debugging. There may be legitimate times where a developer does, truly, wish to send their token to chat for whatever reason.
The reason the [token omitted] clause exists in the first place is to protect situations where developers unfamiliar with the logistics of the "implicit return" may, for instance, return the contents of their config file or the attributes of a class without realizing it. I consider this substitution acceptable because the implicit return is already augmented behavior - it doesn't happen in most other debug cogs.
However, outside of such cases, the intention is clear. In accordance with the above philosophy, when you write await _ctx.send(_bot.http.token), I assume you mean it. Jishaku isn't doing anything wrong - it is merely doing exactly what you are asking it to do.
The solution for this problem is thus clear: if you don't want your token to be sent to chat, don't run code that sends your token to chat.
The power of the interpreter is unwieldy. One who wields Jishaku holds the same power as whatever user it is running under (which in some cases, can even mean root access - depending on how the host is set up).
Perhaps in the future I should have Jishaku warn you more aggressively about this during usage, but for now, I think referring to the sudo lecture is most appropriate:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.


Finding batch by ID causes exception: Class __PHP_Incomplete_Class has no unserializer

Laravel Version: 9.7.0
PHP Version: 8.1.4
Database Driver & Version: Microsoft SQL Server PHP Driver 5.10

Description:
When calling Bus::findBatch to find a batch by ID, after upgrading to Laravel 9 and PHP 8.1 (previously Laravel 8 and PHP 7.4), I now get Class __PHP_Incomplete_Class has no unserializer when calling unserialize() on the DatabaseBatchRepository class.
Steps To Reproduce:

Create a batch
Attempt to retrieve the batch by ID using Bus::findBatch()

have you tried running ‘composer update’? I had the same issue and updating dependencies fixed it

Think you'll need to update your dependencies indeed to pull in laravel/serializable-closure.

I believe I have the necessary updated dependencies though. I'm running laravel/framework v9.7.0, which includes the laravel/serializable-closure package.
I can confirm this by running composer show laravel/serializable-closure and it tells me I have v1.1.1 installed. I can also confirm the serializable-closure package is installed in my app's vendor directory.
Is there some other dependency that I need to update? Thanks!

Heya, thanks for reporting.
We'll need more info and/or code to debug this further. Can you please create a repository with the command below, commit the code that reproduces the issue as separate commits on the main/master branch and share the repository here? Please make sure that you have the latest version of the Laravel installer in order to run this command. Please also make sure you have both Git & the GitHub CLI tool properly set up.
laravel new bug-report --github="--public"

Please do not amend and create a separate commit with your custom changes. After you've posted the repository, we'll try to reproduce the issue.
Thanks!

Hi Dries! So, in attempting to reproduce this in a separate repository, I actually found the root cause. When upgrading an app that has batches in the job_batches table, they have references to Illuminate\Queue\SerializableClosure in the options field in the database. This class doesn't exist in L9, and any new batches have references to the new Laravel\SerializableClosure.
Is there any way this can be aliased for backwards compatibility, or will it just be mandatory to flush the batches table when upgrading to Laravel 9?

We'll try to check into making this a bit smoother. Unfortunately we cannot give a time frame for this right now. For now, it's best that you clear this table before migrating.

Understood, thanks for following up! At this point, I just want to make sure if it's a breaking change, it makes it into docs / upgrade guide so it doesn't surprise anyone else.

Hi there, since this is an edge case really and we only have gotten one report for this we're going to close this one now. Thanks for reporting this but right now we don't feel it's wanted to dedicate a lot of time to this. We would accept a note to the upgrade guide though so people know to process all of their batches before upgrading. Thanks

@driesvints Faced the same issue.

We're currently not going to invest time into solving this sorry. Please clear your batches before upgrading.
If you can, a PR is appreciated.


Episemata: CUD

Create:

Client: add episema (horizontal, vertical) line to a neume (when neumified, combine contiguous episemata).
Server: add <episema> tag to the MEI document

Update (Type):

Client: toggle for horizontal or vertical episema
Server: update <episema> tag in the MEI document

Delete:

Client: remove episema glyph from the drawing surface
Server: remove <episema> tag in the MEI document

Mostly implemented but still needs work. Refer to #145 and #146.


Add replace (strings.Replace) template function

There is a situation that you need to change a template in a way that (db XODB{{ goparamlist .Fields true }}) to be ({{ goparamlist .Fields true }}) but since the goparamlist by default prefix a comma when it returns and there is no other way to ignore that except having a replace function and keeping goparamlist unchanged ex. ({{ (replace (goparamlist .Fields true) ,  1) }})

I don't believe this is needed, at least not for use with goparamlist. The way you would use this in custom templates is to pass ignored names in the goparamlist call: {{ goparamlist myFields true "field1" "field2" }}

I don't want to ignore names, I just want to remove that comma prefix, here is the example for postgres.index.go.tmpl original is func Foo(db XODB, p1 T) my requirement is (s *T1) Foo(p1 T2)

I changed goparamlist to have a addPrefix option. You should be able to use this now, in the following way:
{{ goparamlist myFields false true }}

Thanks


fix: Add reference to faCheckCircle on checkout-payment component

This is a fix for issue #350 - Error thrown when pressing Accept button in Checkout Component
The error is due to a missing reference to the icon that is supposed to be shown.
Here is a GIF demonstrating the fix:

Thank you for your contribution


fix: only rely on DGEFP for qualiopi certification

In addition to more frequent dataset update on recherche-entreprise side, this PR made a change in Organisme de Formation section.
We now only rely on DGEFP response to determine if an organisme is Qualiopi as recherche entreprise can be outdated.
This mean we loose the ability to have "certifié qualiopi" in the section title, but this seem like a fair trade off.
We will still have outdated data in summary and in the search engine so this will not entirely solve the issue, but it will improve it.

Btw after the daily data update, the data will have at worst a 24 hours lag.

And this is much better, congrats !


[ADAP-557] [Regression] run-operation with run_query macro does not commit changes

Is this a regression in a recent version of dbt-redshift?

[X] I believe this is a regression in dbt-redshift functionality
[X] I have searched the existing issues, and I could not find an existing issue for this regression

Current Behavior
When running run-operation command with the macro run_query that updates rows in the DWH, the changes are not being committed and the data is not getting updated although the run-operation ran successfully.
(This is happening with insert queries as well).
The macro I am running using run-operation is:
{% macro update_sent_alerts(alert_ids, sent_at, table_name) %}
    {% if alert_ids %}
        {% set update_sent_alerts_query %}
            UPDATE {{ ref(table_name) }} set suppression_status = 'sent', sent_at = {{ "'{}'".format(sent_at) }}, alert_sent = TRUE
            WHERE alert_id IN {{ elementary.strings_list_to_tuple(alert_ids) }} and suppression_status = 'pending' and
                {{ elementary.edr_cast_as_timestamp('detected_at') }} >= {{ get_alerts_time_limit() }}
        {% endset %}
        {% do run_query(update_sent_alerts_query) %}
    {% endif %}
{% endmacro %}

I tested it with other macros that uses run_query with a simple update / insert query, and the result is the same.
Expected/Previous Behavior
Before using dbt-redshift 1.5.0, the run-operation command was updating the data successfully at the DWH.
Steps To Reproduce

Create a macro that uses run_query with a query that inserts / updates data.
Run dbt run-operation with the macro using dbt redshift 1.5.0 and above.
Check the data at the DWH and see that it was not updated.

Relevant log output
No response
Environment
- OS: macOS Monterey 12.4
- Python: 3.9.13
- dbt-core (working version): 1.5.0
- dbt-redshift (working version): 1.5.1
- dbt-core (regression version): 1.4.6
- dbt-redshift (regression version): 1.4.0

Additional Context
No response

Thanks for finding and reporting another regression @IDoneShaveIt 🙏
I was able to reproduce the error you are reporting with the simple example below:
Reprex
models/my_model.sql
{{ config(materialized="table") }}

select 1 as id, 'pending' as status

macros/test_update.sql
{% macro update_some_model(alert_ids, sent_at, table_name) %}
      {% set update_query %}
          UPDATE {{ ref(my_model) }} set status = 'sent'
      {% endset %}
      {% do run_query(update_query) %}
{% endmacro %}

dbt run

You can examine it like this with dbt-core >= 1.5:
dbt show --inline "select * from {{ ref('my_model') }}"

Then run the macro:
dbt run-operation update_some_model --args '{}'

See that it didn't update:
dbt show --inline "select * from {{ ref('my_model') }}"

Log output
Here's my log output from logs/dbt.log with the timestamps, etc stripped out:
Acquiring new redshift connection 'macro_update_some_model'
Using redshift connection "macro_update_some_model"
On macro_update_some_model: BEGIN
Opening a new connection, currently in state init
Redshift adapter: Connecting to redshift with username/password based auth...
SQL status: SUCCESS in 1.0 seconds
On macro_update_some_model: COMMIT
Using redshift connection "macro_update_some_model"
On macro_update_some_model: COMMIT
SQL status: SUCCESS in 0.0 seconds
Using redshift connection "macro_update_some_model"
On macro_update_some_model: UPDATE "test_database"."dbt_dbeatty"."my_model" set status = 'sent'
SQL status: SUCCESS in 5.0 seconds
On macro_update_some_model: Close
Command `dbt run-operation` succeeded at 07:20:25.234958 after 5.93 seconds
Connection 'macro_update_some_model' was properly closed.
Flushing usage events

If I replace get_custom_schema_names with a hard-coded list of schemas, then the operation runs as expected.

This is surprising that dbt-redshift 1.7.7 is behaving differently depending if get_custom_schema_names() is a hard-coded list or not.
How is it behaving when it is hard-coded? And how it is behaving when it is not hard-coded?
Is there a version of dbt-redshift that is working how you expect?
Bonus: could you provide a simplified version of your get_custom_schema_names() macro?


New terminal in editor area will not open in an empty pane

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.66.0
OS Version: OpenSUSE Tumbleweed - up to date as of 31st March 2022

Steps to Reproduce:

Assign a command to create a new terminal in the editor area (workbench.action.createTerminalEditor) - I have mine set to be alt + enter.
Setup the editor to have at least one empty workspace, no files open and one with a file open.
Click the workspace without any files open (showing just the VSCode logo)
Press the key combination to create a new editor terminal set in (1)
Note that the terminal is in fact opened in the area with the file open rather than the one that was clicked on.

Given that it is the area with the VSCode logo that has focus, I would have expected the terminal to open there.

Can reproduce both with terminal editor keybinding and ctrl+n as well:

Since it affects new file as well I think this is not a terminal problem as well.

@Tyriar at least the first thing you show where a terminal opens in the wrong group seems a terminal issue to me, are you sure you are not passing in a group id when this command runs?
The second issue can be explained: the side group is locked (you can tell by the lock icon), so "New file" will not target the locked group.

Oh, you started with a locked group, so it has nothing to do with "New File"...

Oh right, forgot about locked groups 🤦

@bpasero this may be by design actually, there are 2 things going on here which I'm not 100% on what the designed behavior is:

Closing the last editor in the group does not unlock the group, causing the "problem"
Opening a terminal editor when the locked group is focused does not open it in the locked group

Sorry for the dribble of information - I'm finding out loads from your comments. There is a Workbench > Editor: Auto Lock Groups option which has the terminalEditor enabled by default - not the others. That explains the second last point form @Tyriar - unchecking it allows it to work as expected.

@Tyriar the command can control this, if you actually pass the group id of the active group from the command you can "force" it to open even in a locked group. Maybe terminals should do that because this feature was mainly build for terminals.
As for the behaviour of preserving the lock when you close the editor, I recall we had a design discussion around this and decided it was good behaviour as long as the group is a side group and not the primary group that cannot be locked anyway.

Was there a change made to address this? I cannot reproduce the issue - for either a keybinding associated with creating a terminal editor or the new file
https://user-images.githubusercontent.com/29464607/167216534-83800621-2668-48ea-b940-ffd2878ab386.mov

As far as I'm aware, there was no change. My viewport had been locked, which I didn't even know was a thing, which caused the issue. Can probably be closed off.

Great, so you can no longer repro the issue either then @AllanJard ?

I can - but only by locking the viewport. It was effectively a misunderstanding of a feature on my part.

Can I verify anything here? Or should the milestone be removed?