Get current folder

First of all, this plugin is AWESOME
I was wondering if there is a way to get the "current folder" in the query
So instead of writting:
task from "1. Projects"

I could write:
task from current_folder

Maybe exposing like the current file path (and more contextual information) could help here

This will be possible via this.file.folder once I revamp how the 'FROM' statement works to accept arbitrary variables instead of just hard-coded tags/folders/what-not.

Just a bump.  I'd like to have the ability to use the DataView to produce summaries at the bottom of a document, and that seems to require the rework of the FROM statement to support this.file arguments.
My expected workflow where this applies:

Generate a "Meeting Notes" document from a pre-defined template
Take notes during a meeting, using QuickAdd plugin shortcuts to insert "Decisions" and "Actions" within the notes.
The Dataview blocks originally defined in the Template list the collected set of all "Decisions" and "Actions" in special sections at the end.

So a Template file kind of like this:
# {{title}}
## Attendees
- [ ]
## Notes

## Decisions
```dataview
TASKS FROM this.file WHERE decision!=Nil
```
## Actions
```dataview
TASKS FROM this.file WHERE assignee!=Nil SORT BY assignee ASC
```

As I take notes I have QuickAdd Capture macros that will insert decisions:
- [ ] [decision::] {{VALUE:Decision}}

And action items:
- [ ] [due::{{VDATE:due,YYYY-MM-DD}}] [assignee::{{VALUE:assignee}}] action:: {{VALUE:action}}

So I trigger creation of a new "Meeting Notes" file populated from the template, then fill in Attendees and start taking notes.  As I take notes, I trigger Capture macros for decisions and action items embedded in the notes body.  When I'm done, the end of the notes have a copy of the summarized decisions and action items as well.

You can cheat for now via a WHERE clause:
TASKS WHERE file.path = this.file.path AND decision

This has been a common enough approach and needs a mention in the docs. Do we plan to support this in the QL?

Yes, I'm still looking at dynamic sources for the QL.

Just bumping this, I'd also love this feature!

I think both. I wish I had the skills to pr this in so we could avoid the doc headache in the first place haha.

What's the status of this? Anything I could do to help?

In current version of dataview you can indeed use this.file.folder, so @nikodemus you should be able to do stuff like: WHERE file.folder = this.file.folder to limit to the current folder.
You can't use a FROM ... syntax, but the above works nicely in my experience.


S2U-31 <IP_ADDRESS> Assignments: Grades in the main view of assignments that have already been evaluated

https://sakaiproject.atlassian.net/browse/S2U-31
From @susowrc!

Thanks for the contribution guys! @susowrc and @jesusmmp


xDog support Drug Dosing

XDog will need to be able to export drug dosing before PDXNet-HCM-BCM can be fully exported and the custom loader retired.
####### ACCEPTANCE CRITERION #######

[x] Changes made to xDog and validated
[x] feature is fully test
[x] feature approved and pushed to Dev

Merging from Alexs_custom_retirment_plan_with_the_xdog on gitlabe

@zperova done

thank you @Afollet


How to use remark-react with hightlight.js

I'm trying to use HightlightJS with remark-react but I don't quite understand how to use the syntax:
import remark from 'remark';
import reactRenderer from 'remark-react';
import hljs from 'remark-highlight.js';

...

this.markdownProcessor = remark().use([reactRenderer, hljs]);

Any hint on how to use it?

It's not currently possible to use highlight.js: highlight.js produces a string of HTML content, and remark-react is expressly written to avoid such HTML escapes. If there was a highlighter that output an AST instead, then we could integrate it into remark-react - otherwise, highlight.js is not compatible with remark-react's security model.

Do you have an example of the AST structure you would need to implement the highlighting?

I was thinking about the same problem recently, for example, I’d like to support syntax highlighting in remark-vdom, remark-man too.
I did some digging into highlight.js, and I don’t think their per-language syntax files needs changing (for example, javascript, wouldn’t need changing). However, their core is tightly coupled with outputting HTML.
So, either someone needs to create a fork which supports other syntaxes (in the form of specifying a compiler), or highlight.js itself should be rewritten, but I’m not sure whether they’d want to.
I have a full plate, but I’ll try my hands on whether it’s feasible, but I’d suggest you’d raise an issue regarding decoupling on highlight.js’s repository.

I actually have a hacky but working AST-based re-implementation of highlight.js working now. It’s probably bug filled though, will have to add lots of tests (I believe there’s like 60 supported languages? Gah.) But do expect more to come soon! :smile:
@tmcw I’m writing it to expose HAST nodes, a unist and minimal HTML syntax tree. This means to get this working with react there needs to be a transformation between the two. I don’t expect it to be very hard, but I’m not experienced with react. could you help me there when the time comes?

Sure! Let me know when you get to the point of integration

Great! :ok_hand:

Done! https://github.com/wooorm/lowlight

FYI, here's a Node friendly highlighter that has been developed based on Prism: Illuminate.js. Prism deals with JSX better than Highlight.js.
It would be great if you could design the system so that it's possible to glue in Illuminate. Note that there's react-illuminate as well.

@bebraw just saw your comment, that looks nice too, although it doesn’t support many language, and it seems to be in beta?
@tmcw I think all the building blocks for syntax highlighting with remark-react are now here, there’s lowlight (or others), and there’s react-syntax-highlighter (which uses lowlight under the hood).
What remains is “component” support in remark-react, which I guess means that users of this remark plugin can specify that code is rendered as SyntaxHighlighter?
Again, I’m not very familiar with React though, so you probably have a better idea of how this should be handled :)

@wooorm It's a little limited at the moment, that's true. Given it's Prism based, it would be possible to add support to the missing languages if needed I think. I opened an issue so we get feedback from the author. Something Prism based would be a winner solution for me given how well it highlights.

Diversity is good! If you want prism, that’s fine and it should happen.
I think this issue will allow that, if we add support for components through something similar like the method I proposed above!

It would be nice to get this moving again. Can someone in the know explain what should happen code-wise? I could try to look into making the changes.

I don’t know the API of react, but you can use react-lowlight or react-syntax-highlighter, both based on lowlight, to do virtual (thus, safe), syntax highlighting. Then, wrap one of those components, and integrate with remarkReactComponents (see the readme of remark-react). I’m not entirely sure what API they use, and if you can access the lang of a code node though.
@tmcw, could you clarify whether this should work?

@wooorm Thanks. Esp. react-lowlight seems great. I think could be enough if I just replace the portion that does code now with that component. I'll give it a quick go and report back.

I gave it more thought. We probably should agree on a basic interface. Right now we have
remark().use(reactRenderer)

What if we did
remark().use(reactRenderer({
  code: codeRenderer // custom logic would go here
}))

The idea is that this type of hook system would allow you to replace h per node type. This would allow the maximum amount of customization without breaking backwards compatibility. Most importantly it would enable highlighting plugin.

I believe the current code already support something like that:
var remark = require('remark');
var toReact = require('remark-react');

remark().use(toReact, {
  remarkReactComponents: {
    'code': 'Lowlight'
  }
}))

Then, Lowlight is passed to React.createElement. But, aside from supporting string, maybe function should be supported in remark-react too? Or, create a wrapper component around Lowlight which supports the attributes given by remark-react and transforms them to support the attributes expected by react-lowlight.

Oh, yeah. Missed that. It would need a tiny adapter right there. :+1:

Maybe create remark-react-highlight? So people who use remark, react, and remark-react, need just remark().use(remarkReact).use(remarkReactHighlight)? That’d be my suggestion :)

I managed to set up highlighting to work with remark-react. Here's a quick demo.
@wooorm How would that remark().use(remarkReact).use(remarkReactHighlight) work? I would need to understand how to connect the plugins internally to patch remark-react behavior (literally that element definition). Alternatively we could do something like this:
{remark().use(reactRenderer, {
  remarkReactComponents: {
    code: RemarkLowlight({
      // list supported languages here, lowlight needs them
      js: jsLangugeDefinition
    })
  }
}).process(readme)}

Lowlight requires those language definitions. Instead of passing them explicitly we could hide the registration within the package itself and perhaps support optional registration that would override that default. I think the reasoning is that each language definition bloats the bundle so the decided to go with opt-in kind of system there.

Oh, you’re right, it wouldn’t work (currently) as a remark plug-in :/ I like your proposed idea; supporting an object mapping names to language definitions.
And, indeed, that’s the reason. Lowlight suggests against subscribing all languages when in the browser.

Awesome, been a bit quiet on this because of work-work but love the way this is shaping up.

I published the solution as remark-react-lowlight. You can see it in action at react-component-boilerplate.
It's probably safe to close this issue now.

Nice! Maybe add a link to the README here though?

@bebraw is there a way to use that component without having to specify the highlight js lang (relying on code fence blocks)? The example makes me think I'd have to specify it.

Ah, I see. If it's in the object passed to RemarkLowlight({}) it gets registered. Noticed that it will break down if the language specified in a code fence block isn't registered though.

@rgbkrk Yeah. It has to register the languages first. Can you open an issue about the breakage at my repo? Maybe the right way to solve that is to skip highlighting in that case and just give a warning instead.

Hey I'm attempting to get remark-react and syntax highlighting to cooperate, hoping someone who's run the gauntlet before can help :)
My naive implementation looks something like
Lowlight.registerLanguage('js', js);

const Pre = ({children}) => {
  return <Lowlight language={'js'} value={children[0].props.children[0]} />
}

Pre.propTypes = {
  className: React.PropTypes.string,
  children: React.PropTypes.node,
};
...
const remarkReactComponents = { pre: Pre };

Which would work if I only needed to highlight js,. so from here I wrote a little parser that grabs the language from a node and drops in on an attributes object.
node.attributes.className = ['hljs', `language-${lang}`];

Which never appears to be available on the props of my React nodes.
P.S. I'm using pre rather than code to prevent nested elements.

I think @bebraw got something working with https://github.com/bebraw/remark-react-lowlight.
@bebraw, does remark-react-lowlight support pre?

@bebraw, does remark-react-lowlight support pre?

I can't see anything pre specific at the code. Maybe "it just works"™. Worth a go.

Cool, I’ll whip up a PR to include this in the docs here!


translate to Chinese simplified

hi only po/zh-CN.pot is needed, can you resubmit with this file only?


[SDPA-2181] Upgrade Ripple storybook to v5

JIRA issue: https://digital-engagement.atlassian.net/browse/SDPA-
Changed

Upgrade Ripple storybook to v5
Update stories
Configure storyshots
Update docker files

Known issues:

RplDivider story is not working, getStory is not a function - Not sure whats going on there
storybook-addon-vue-info isn't working, the panel is installed, it just doesn't display anything. I have removed this for now, we should look at the upcoming storybook-docs addon.

Screenshots

Hey @dylankelly For demoData and page templates, if they are not in used anymore, we need to remove them from this PR. Otherwise it will make confusion. We need to add the rework in another ticket.


create ci check to verify that new added versions exist

What is the motivation/use case for changing the behavior?
Once a new version is added or a change is made to the existing version there is no check to verify if the action truly exists.
Describe the solution you'd like
I think it would be interesting to perform a fetch to npm and verify that each version exists.
This could be made directly using a script or using some custom or pre-existing GH Action
Describe alternatives you've considered

create a full package.json, set the CI with a matrix to override the version and run an npm i

Additional context
UPDATE:
Currently we are not protected against adding or modifying packages versions that don't exist.
For example, if adding Angular 13 support and using the wrong version for @angular/cli, anyone using our action will see the action fail because the provided version does not exist.
With the suggested check we at least verify that the versions of the packages are valid.

Please elaborate. I don't understand the issue.

I added an update


Services: first build: abs added

{package} {version} {:snowflake:}
Destination channel: {Snowflake | defaults}
Links

{ticket_number}
Upstream repository
Upstream changelog/diff
Relevant dependency PRs:

...

Explanation of changes:

...

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_8dtjpu81ol/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:46: missing_description: The recipe is missing a description
clone/recipe/meta.yaml:45: documentation_specifies_language: Use the generic link, not a language specific one

===== ERRORS =====

clone/recipe/meta.yaml:17: pip_install_args: pip install should be run with --no-deps and --no-build-isolation.
clone/recipe/meta.yaml:37: missing_pip_check: For pypi packages, pip check should be present in the test commands
===== Final Report: =====
2 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_b66te8fbx_/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:39: documentation_specifies_language: Use the generic link, not a language specific one
clone/recipe/meta.yaml:15: avoid_noarch: noarch: python packages should be avoided
clone/recipe/meta.yaml:40: missing_description: The recipe is missing a description

===== ERRORS =====

clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
===== Final Report: =====
1 Error and 3 Warnings were found


makes the robot base frame coincident with the bottom of the frontier case

this is as discussed with @mcamurri  yesterday.
@mcamurri : I will  clean up the following branch to work properly with Frontier 12 and Frontier 14 logs and we can merge them at the same time:
https://github.com/ori-drs/frontier_logging/tree/feature/color-alphasense

@heuristicus does this PR require a modification on the Spot URDF for example?

Maybe - feel free to merge and I will fix things in the spot repo.


[Improvement-14201][UI] Improve the select component to support users to filter options.

Purpose of the pull request
This PR will close #14201 .

Brief change log

Verify this pull request

Manually verified the change by testing locally.

The test result is as follows:

Codecov Report

Merging #14202 (a6afba8) into dev (af7da06) will decrease coverage by 0.02%.
The diff coverage is n/a.

:exclamation: Current head a6afba8 differs from pull request most recent head b77a13a. Consider uploading reports for the commit b77a13a to get more accurate results

@@             Coverage Diff              @@
##                dev   #14202      +/-   ##
============================================
- Coverage     38.35%   38.33%   -0.02%
  Complexity     4467     4467
============================================
  Files          1229     1229
  Lines         42887    42809      -78
  Branches       4764     4744      -20
============================================
- Hits          16448    16410      -38
+ Misses        24612    24576      -36
+ Partials       1827     1823       -4

see 62 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Can't solve simple GP

I don't understand why this GP:
        x = cp.Variable(pos=True)
        y = cp.Variable(pos=True)
        cstrs = [10 <= x, x <= 20, y <= x, x * y == 7]
        prob = cp.Problem(cp.Maximize(y), cstrs)
        prob.solve(gp=True)

fails with:
...
  File "C:\...\lib\site-packages\cvxpy\reductions\solvers\solving_chain.py", line 101, in _reductions_for_problem_class
    raise DGPError("Problem does not follow DGP rules." + append)
cvxpy.error.DGPError: Problem does not follow DGP rules.The following constraints are not DGP:
var0 @ var1 == 7.0 , because the following subexpressions are not:

Setting bounds on y, using Minimize, or x * y <= 7 instead of x * y == 7 all fail for the same reason.
Isn't the whole point of GP to multiply variables?
BTW, the same program with gpkit runs fine.

I think it is an installation issue.

(Reopening issues)
I'm trying to run the GP example from the site:
        import cvxpy as cp

        # DGP requires Variables to be declared positive via `pos=True`.
        x = cp.Variable(pos=True)
        y = cp.Variable(pos=True)
        z = cp.Variable(pos=True)

        objective_fn = x * y * z
        constraints = [
            4 * x * y * z + 2 * x * z <= 10, x <= 2 * y, y <= 2 * x, z >= 1]
        problem = cp.Problem(cp.Maximize(objective_fn), constraints)
        problem.solve(gp=True)
        print("Optimal value: ", problem.value)
        print("x: ", x.value)
        print("y: ", y.value)
        print("z: ", z.value)

This fails with:
...
  File "C:\tools\miniconda3\envs\roomassignments\lib\site-packages\cvxpy\reductions\solvers\solving_chain.py", line 101, in _reductions_for_problem_class
    raise DGPError("Problem does not follow DGP rules." + append)
cvxpy.error.DGPError: Problem does not follow DGP rules.The following constraints are not DGP:
4.0 @ var0 @ var1 @ var2 + 2.0 @ var0 @ var2 <= 10.0 , because the following subexpressions are not:

My setup:
>conda list cv
# packages in environment at C:\tools\miniconda3\envs\roomassignments:
#
# Name                    Version                   Build  Channel
cvxopt                    1.2.7                    pypi_0    pypi
cvxpy                     1.1.17           py37h03978a9_1    conda-forge
cvxpy-base                1.1.17           py37h9386db6_1    conda-forge

Is there some other package or flag that I need to set or install?

This works for me with cvxpy 1.1.3.

Didn;t work for me with 1.1.13 either. ☹

I think you may have some sort of installation error.
Can you print the version of CVXPY in the Python script (add print(cp.__version__) as the second line of your script)?
This works locally on my machine (tested it on 1.1.13, 1.1.15, 1.1.17, ... ). I get the output
Optimal value:  2.0000000014446626
x:  1.0000000002665232
y:  1.9999999999185367
z:  1.0000000004965397

We also test many dgp problems in our unit tests.

The local tests from above were run using manylinux wheels from PyPi, and from conda-forge. Our unit tests are run on all major platforms, including Windows. The error you're seeing is quite strange. I don't know what it could be, other than an installation error.

You're right. Very strange.
When I now ran it isolated from other code it succeeds.
Something gets corrupted in my local function context.
Investigating.

Closing this for now. Sorry for the noise. It was a Heisenbug...


Add

Added delete in done section and customized scrollbar to fit the styling of the app.

Scrollbar customization is done in page.js and delete is done in index.js and task-action.js


Refactoring analysis: Analyse the usage of block numbers

Research where block numbers are used (who needs to access block numbers and why)

BlockId refactoring status and next steps

Some of core traits are already cleaned from BlockId, however there are still some methods that are related to BlockId or block number. The summary of use cases is in the sections to follow.
Reworking header function led to some call sequences that are far from being perfect, example.
Namely, in some modules there is a requirement to fetch header using block number, current PR works around this by calling header(hash(n)) combo.
In some cases expect_header(block_id) is called to hide the combo, (as expect_header was not reworked yet)
To solve this "problem" HeaderBackend trait could be extended with dedicated functions for fetching header by block
number:
-- header_for_number(NumberFor<Block>) -> Result<Option<Block::Header>>
-- expect_header_for_number(NumberFor<Block>) -> Result<Block::Header>
-- header(Block::Hash) -> Result<Option<Block::Header>>
-- expect_header(Block::Hash) -> Result<Block::Header>
New naming may also make finding all block-number usages and their refactorization easier. I would follow with this naming convention in needed for the rest of methods (e.g. block, block_status)
Implementation of _for_number methods could make use of new service which will move number-hash mapping out of DB.

Where the BlockId is currently used:
Still in client API:

trait Chain common block validation for consensus
-- block_status

trait BlockIdTo
-- to_hash
-- to_number

trait HeaderBackend:
-- status
-- expect_header
-- block_hash_from_id
-- block_number_from_id

trait BlockBackend
-- block
-- block_status

impl Client: Chain, BlockBackend, CallApiAt, HeaderBackend, BlockIdTo, BlockBuilderProvider
-- code_at
-- runtime_version_at
-- block_status

trait ExecutionExtensions
-- manager_and_extensions
-- extensions

In runtime_api() subsystem:
Refactoring here is probably doable, requires some adjustments in runtime-related macros. Question if we want to get rid of BlockId parameter to runtime functions. This maybe inconvenient in some cases. Maybe we should introduce dual functions (following _for_number approach) at the top-level runtime API.

trait GetRuntimeVersionAt
-- runtime_version

trait ApiExt
-- has_api
-- has_api_with
-- api_version

trait CallApiAt
-- runtime_version_at
-- state_at

WasmSubstitute
-- matches (operates on block number)
-- get

trait CallExecutor
-- prove_execution
-- contextual_call
-- call
-- runtime_version

trait LocalCallExecutor
-- check_override

Other usages

Benchmark::run (from - to)
-- measure_block
-- consumed_weight

impl PowBlockImport
-- check_inherents

trait PowAlgorithm
-- verify

DB
Something that we want to get rid of:
-- API: remove_from_db, read_header, read_db
-- HeaderBackend::status
-- internal implementation Backend::prune_block

InMem:
-- Blockchain::id (blockid -> hash)
-- HeaderBackend::status

AuraVerifier
-- check_inherents (runtime_api called)

BabeVerifier
-- check_inherents (runtime_api called)
-- check_and_report_equivocation

Beefy
-- expect_validator_set

BlockBuilderProvider
-- new_block
-- new_block_at

BasicAuthorship Proposer
-- impl uses BlockId

BlockRequestHandler
-- handle_request  / get_block_response

Network tests utils

PeerClient
-- has_state_at
Peer
-- generate_blocks_at
-- push_blocks_at
-- push_blocks_at_without_informing_sync
-- push_blocks_at_without_announcing
-- generate_tx_blocks_at

utils

impl BlockNumberOrHash
-- parse
pub fn check_block

Transaction pool:
As transaction verification is done via runtime calls, the API for submitting also uses BlockId.

trait ChainApi
-- validate_transaction
-- block_id_to_number
-- block_id_to_hash

trait TransactionPool
--submit_at
--submit_one
--submit_and_watch

impl Pool
--submit_at
--resubmit_at
--submit_one
--submit_and_watch
--prune_known
--prune
--prune_tags
--resolve_block_number
--verify
--verify_one

impl ValidatedPool
--resubmit_pruned
--fire_pruned
--clear_stale

impl FullChainApi

impl BasicPool

impl TestApi
fn validate_transaction(
fn block_id_to_number(
fn block_id_to_hash(

test::OffchainWorkers::submit_at

Where Block number is used
not completed yet

have_state_at(hash, number)
hash(n) usages

client/consensus/babe/src/lib.rs
1775 pub fn revert

client/db/src/lib.rs
fn prune_blocks:
1753 fn prune_displaced_branches

client/finality-grandpa/src/warp_proof.rs|100
WarpSyncProof::generate

client/finality-grandpa/src/environment.rs
1249 pub(crate) fn finalize_block

client/rpc/src/chain/mod.rs|83
ChainBackend::block_hash

client/finality-grandpa/src/import.rs|366
GrandpaBlockImport::make_authorities_changes

client/service/src/client/client.rs|1036
Client::block_status

client/network/sync/src/lib.rs|804
ChainSync::on_block_data  / AncestorSearch

primitives/blockchain/src/backend.rs|227
trait Backend::best_containing

primitives/blockchain/src/backend.rs|53
HeaderBackend::block_hash_from_id

What's the end goal here? to make everything block number? or hash?

What's the end goal here? to make everything block number? or hash?

Make as much as possible use hash, as hashes are unique.

4. To solve this "problem" HeaderBackend trait could be extended with dedicated functions for fetching header by block
number:
-- header_for_number(NumberFor<Block>) -> Result<Option<Block::Header>>
-- expect_header_for_number(NumberFor<Block>) -> Result<Block::Header>
-- header(Block::Hash) -> Result<Option<Block::Header>>
-- expect_header(Block::Hash) -> Result<Block::Header>
New naming may also make finding all block-number usages and their refactorization easier. I would follow with this naming convention in needed for the rest of methods (e.g. block, block_status)
Implementation of _for_number methods could make use of new service which will move number-hash mapping out of DB.

If this helps moving forward with this issue, it should be fine!

BlockId refactoring status and next steps (2)
Where the block number is actually used
Some usages may still be missing, but the list shall better then in previous comment:

header_metadata()

fn tree_route
...?

hash(n) usages

babe: pub fn revert
granpa: pub(crate) fn finalize_block
GrandpaBlockImport::make_authorities_changes
WarpSyncProof::generate
Backend::prune_blocks
ChainSync::on_block_data  / AncestorSearch
ForkBackend::expand_forks
Benchmark::run(from - to): fn run
conversion api: HeaderBackend::block_hash_from_id
conversion api: ChainBackend::block_hash

have_state_at(hash, number)

have_state_at definition: Backend::have_state_at
Backend::revert
fn Client::block_status

block_hash_from_id(BlockId)

fn prove_finality
Inspector::get_block
pub fn revert
pub async fn check_block
pub fn export_blocks
ExportStateCmd::run
BlockRequestHandler::get_block_response
BlockRequestHandler::handle_request
BeefyWorker::finalize
BeefyWorker::do_vote

Where the BlockId is currently used:
Still in client API:
Seems to be fine, just conversion functions.

trait BlockIdTo
-- to_hash
-- to_number

trait HeaderBackend:
-- block_hash_from_id
-- block_number_from_id
-- hash(number)

trait ExecutionExtensions
-- manager_and_extensions
-- extensions

trait IndexedBody
-- block_indexed_body(number)

Implementation

DB
Something that we may want to get rid of:
-- API: remove_from_db, read_header, read_db
-- internal implementation Backend::prune_block

InMem:
-- Blockchain::id (blockid -> hash)

Other usages

trait PowAlgorithm
-- verify

Network tests utils

PeerClient
-- has_state_at
Peer
-- generate_blocks_at
-- push_blocks_at
-- push_blocks_at_without_informing_sync
-- push_blocks_at_without_announcing
-- generate_tx_blocks_at

utils

impl BlockNumberOrHash
-- parse
pub fn check_block

Transaction pool:
As transaction verification is done via runtime calls, the API for submitting also uses BlockId. Since runtime API is reworked this should be easy doable.

trait ChainApi
-- validate_transaction
-- block_id_to_number
-- block_id_to_hash

trait TransactionPool
--submit_at
--submit_one
--submit_and_watch

impl Pool
--submit_at
--resubmit_at
--submit_one
--submit_and_watch
--prune_known
--prune
--prune_tags
--resolve_block_number
--verify
--verify_one

impl ValidatedPool
--resubmit_pruned
--fire_pruned
--clear_stale

impl FullChainApi

impl BasicPool

impl TestApi
fn validate_transaction(
fn block_id_to_number(
fn block_id_to_hash(

test::OffchainWorkers::submit_at


ValueError: The 'mediafile' attribute has no file associated with it

After uploading two files via Django rest framework upload form I get an important error. Mediafile list is broken (no changes after reload!):
ValueError at /rest/mediafiles/mediafile/
The 'mediafile' attribute has no file associated with it.

I can not reproduce this.

Maybe #1885 solves it.

Looks good with current master. Can't reproduce it any more.


'Who can post' setting with no edit access is displayed for split bill participants

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Click on 'FAB' icon
Click on 'Split bill' link
Enter amount > click on 'Next' button
Search user > select user B > click on 'Next' button > click on 'Split' button
Click on 'IOU preview component'
Verify a new chat is opened
Click on the chat header
Click on 'Settings' link
Observe that 'Who can post' setting without edit access is displayed
Switch to the  tab where user B is signed in
Open the sent message
Repeat steps 5 - 9

Expected Result:
'Who can post' setting should not be available for both participants since none of the participants can change the setting between 'All members' and 'Admins only'. This feature is available on workspace and admin can change the setting from 'All members' to 'Admins only'
Actual Result:
'Who can post' setting is available for both split bill participants
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.19-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/d17e7676-0c78-49e6-8456-497299dcf08d
https://github.com/Expensify/App/assets/43996225/e296e267-9559-4dea-8a2d-ebc4850b98b3
Expensify/Expensify Issue URL:
Issue reported by: @natnael-guchima
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1684956711277149
View all open jobs on GitHub

@Natnael-Guchima
If Who can post isn't actionable, does it matter?

'Who can post' setting should not be available for both participants since none of the participants can change the setting between 'All members' and 'Admins only'.

Technically, all members in the split can post, right?  I think the other option would be to just not show 'who can post' which wouldn't be consistent.
(I'm not trying to sound snarky, apologies if it comes across that way)

@mallenexpensify you didn't sound to be snarky😁. I think the flow after clicking on the IOU preview component seems to be changed on the latest release. I am not able to find the settings section with split money flow. I think the issue to remove 'all members' option would be irrelevant if the flow is removed.
https://github.com/Expensify/App/assets/57330233/797ac121-3a61-471a-a3b3-c7f62d3cf056

OK, thanks @Natnael-Guchima , gonna close then, comment if you (or anyone) disagrees.


[Features] Allow running with --features lua52

Hi @JohnnyMorganz, My code is currently use label feature of lua, however it is not enabled by default in release version.
Are there anyway for me to enable features like lua52 when running this action?
Thank you for your great Stylua and this github action.

The release version does have lua52 enabled.
What kind of error are you seeing?
You may be experiencing an issue similar to #402 where Luau syntax clashes with Lua 5.2 syntax. You can use cargo to build a binary with only lua52 enabled and that should work. Hopefully in the next major release we will have runtime configurable syntax selection

@JohnnyMorganz, sorry for not mentioning the error. I met this https://github.com/JohnnyMorganz/StyLua/issues/407.
I managed to use cargo-instal action to install stylua instea.

StyLua v2.0.0 now provides support for runtime syntax selection. You can configure this in either in the stylua.toml file, or on the command line with --syntax lua52.

thank you for this feature @JohnnyMorganz <3


fix wrong ex solution

change wording slightly: rather analyze some learner in mlr3/sklearn, pick a regression tree
correct result for gradient in LM with L2 loss (was transposed)
change question about applying gradient update from stating to explaining: our convention of numerator layout in calculus produces gradient update in form of row vector (after above correction), while vector to be updated is column vector --> will be super confusing w/o adding much value

 fix gradient exercise in regression


basho_bench tests directory seems to be ignored  [JIRA: TOOLS-100]

I have installed basho_bench the first time using RPM (previously i used it the source only). I was running into this issue:
$ basho_bench -d tests /etc/basho_bench/http.config
escript: exception error: no match of right hand side value {error,eacces}
  in function  basho_bench:test_dir/2 (src/basho_bench.erl, line 178)
  in call from basho_bench:main/1 (src/basho_bench.erl, line 47)
  in call from escript:run/2 (escript.erl, line 747)
  in call from escript:start/1 (escript.erl, line 277)
  in call from init:start_it/1
  in call from init:start_em/1

I was wondering what is going ton and after poking around I have seen https://github.com/basho/basho_bench/issues/56.
I have tried it with sudo.
[vagrant@localhost ~]$ sudo basho_bench -d tests /etc/basho_bench/http.config
16:45:47.105 [debug] Lager installed handler {lager_file_backend,
                            "/usr/lib64/basho_bench/lib/basho_bench-0.10.0/ebin/tests/20150408_164547/error.log"} into lager_event
16:45:47.105 [debug] Lager installed handler {lager_file_backend,
                            "/usr/lib64/basho_bench/lib/basho_bench-0.10.0/ebin/tests/20150408_164547/console.log"} into lager_event

I guess the following function prefixes the parameter that was passed in with -d with the CWD that is the "/usr/lib64/basho_bench/lib/basho_bench-0.10.0/ebin" in my case if the path is not a full path.
https://github.com/basho/basho_bench/blob/0.10.0/src/basho_bench.erl#L172
It would be nice to make it explicit that the path has to be absolute and relative paths will fail if the user has no access to the CWD of the basho_bench binary.
What do you guys think?

@l1x What do you think about https://github.com/basho/basho_bench/compare/bug/gh178?expand=1 ?

@slfritchie i guess I am trying to understand the intentions here. Currently the function behaves like this:

if you pass in an absolute path it takes it as it is
if you pass in a relative path it takes it and prefixes it with CWD (that is the ebin/ folder location on disk)

I guess the code should not silently do that or it should be called out. It seems this is a real issue (even though a low priority one) because I am not the first guy who ran into this.
What you are your thoughts?

The intent of the diff is to use pattern matching to create a more useful error message when something goes wrong: the path of the file with the I/O error is included in any badmatch error reporting.

I just merged #185 and will close this issue.  If there's a serious problem, or if there's a PR to alter the behavior further, please reopen.

Ummm, this GH issue was closed on May 19, 2015. Closing in JIRA.
[posted via JIRA by Scott Fritchie]


Feature request: self-signed certificates for upstreams

1. What version of Caddy are you running (caddy -version)?
0.9.5
2. What are you trying to do?
Proxy to backends over HTTPS that use long-lived self-signed certificates. This could be accomplished by:

passing the public-key (encoded as PEM) as part of the upstream config OR
base64 std-encode the SHA2-256 hash of the public key (encoded as DER) - see the "pin" section on sslabs for an example OR
use a custom TLS config with an artificial root CA specific to that Caddy instance

Option 2 would be very simple and very readable. All cases would profit from tooling (e.g. create self-signed certificate key-pair, depending on the implementation including pin or including CA key-pair and matching signature on the backend key-pair), ideally provided by Caddy itself.

Thanks for the feature request , @yawn  - help me understand a little better. Caddy can already proxy to upstreams that use a self-signed certificate (you just have to use insecure_skip_verify to make the connection insecure with purpose). What is the feature you're requesting, exactly?

The difference is: insecure_skip_verify will support HTTPS but does not verify it at all. The proposed change would in fact verify the upstreams key by:

doing a manual verify of the public key in the actual TLS connection
the same
using a custom CA trust chain containing only the certificate of a local group of Caddy servers that was used to sign the self-signed certificate

This is a pretty common pattern for securing origin traffic, see for example:

https://community.fastly.com/t/setting-up-self-signed-tls-in-fastly-and-my-origin/531 (approach 1) or
https://blog.cloudflare.com/universal-ssl-encryption-all-the-way-to-the-origin-for-free/  (approach 3)

nginx for example seems to call option 1 proxy_ssl_trusted_certificate.

What about just adding your CA to the system's trust store?

Mostly because maintaining your own CA is IMHO the least desirable approach. Super-easy would be putting the public-key (or it's pin) in. Creating self-signed, long-lived certificates is a very easy operation.

Well, when you self-sign a certificate, you're already doing so with some private key that you own; can you not tell the system that public key is trusted?

This might actually be technically possible (I'm not sure, I never checked). Theoretically there should not be a difference between a CA's public key and and endpoints public key (expect maybe for *keyUsage attributes but that should not matter) - ideally I'd prefer to have this data in the reverse proxy though since the trust I have for the certificates is something exclusive to this surrogate - origin relationship.
The difference between "maintain your own CA" and just creating self-signed certificates would be that in the former case I trust one entity (the CA) that in turn creates signatures on other keys (the origin servers). In the latter case I'd trust each origin key individually.

any news about this?
it would be really great to be able to set the upstream trusted CAs, either at the proxy level or the http level. using something like the existing tls load directive. this would be better that having a blanket insecure_skip_verify directive.

In order to solve this issue proxy directive would have to be extended.
Simillary to Go's crypto/x509 SSL_CERT_FILE and SSL_CERT_DIR I would propose to add something like to proxy directive:
proxy {
  ssl_cert_file /path/to/ca-list-bundle.pem
  ssl_cert_dir /path/to/ca-list-directory/
}

Which would add those CA certificates for backend to be checked against.
I would like to also have control over using or not of system provided certificates. Maybe it shall be configured on each proxy entry, like:
proxy {
  ssl_cert_file /path/to/ca-list-bundle.pem
  use_only_local_cert true
}

So no system provided CA would be used to validate the proxy.
Note: Setting Go's SSL_CERT_FILE and SSL_CERT_DIR works nicely for the whole Caddy running process, but in this case each proxy directive is expected to be configured separately.
What do you guys think about this approach?
Is this proposal covering enough that feature?
Do you have any tips where to start (I am just starting playing with Caddy code and generally Go)?
Are ssl_cert_file, ssl_cert_dir and use_only_local_cert good names?
Are there any other issues which would block this one?

@lukenowak I think what we could do is just call the option certificates and accept one or many arguments. Check the path to determine if it's a dir or file, and handle it as such.
If you were to add a only_local_certificates option, then you wouldn't need true as an argument because the existence of the option is enough to assume it's turned on.


Druid TOC (toc.textile) needs to be ported to markdown

Github will stop supporting textile soon

There's more to it than that, we also need to port both docs and Druid site to kramdown and switch to rouge for syntax highlighting. https://github.com/blog/2100-github-pages-now-faster-and-simpler-with-jekyll-3-0


Expose a larger number of design tokens in druid::theme

The current EventScope API allows me to override the variables listed in druid::theme to customize how my application looks. However, there are a large number of variables used implicitly in the default widgets that I can't override. Instead of being picked up from the Env, these variables appear as literals in the source code.
For example, the border radius for a Button is 4.0. It appears in druid/src/widget/button.rs, but I can't retrieve or override it because it's just a literal value.
Finding such variables and making them explicit in druid::theme will make styling a Druid application easier. There is precedent for this in the Design Systems communities, where these kinds of atomic base units are called design tokens. This article is a decent explainer, and this is a list of tokens used in the Salesforce design system.
Adopting this approach would reduce inconsistencies across the toolkit and makes design decisions more explicit. E.g, Button has a border radius of 4.0, but a TextBox has a border radius of 2.0. Both values appear as literals in the source code for those widgets. Exposing border radius values in druid::theme would've either prevented this inconsistency, or documented it as an explicit design decision.
This would also make it easy for custom widgets to fit in with the default set widget set.
It might not be an explicit goal of Druid, but this approach would also allow radical re-skinning of applications, with variable changes affecting both default, custom and community-built widgets.
I'm sure there are more ideas that Druid could pick up from the Design Systems community, but I can't think of anything at the moment. For now, setting up explicit design tokens would be a great start.

Cool, I think there's two separate related things here but they're both basically a matter of "haven't gotten to it yet":

there are definitely a bunch of fields that should be customizable that have not been; totally happy for PRs, here.
There has not been a lot of thought put into what is involved in making the theme system coherent: What keys should there be, what should their relationships be, what concepts should we express, etcetera. Raph and I were talking about this in relation to doing GSoC again this year; we were thinking that really diving deep into this would be a good project for somebody. GSoC or not, that is totally the case; this is really just an area that needs more thought and focus, and I'm happy to hear any thoughts or ideas. :)

Thanks for the issue and the links, it looks like a good starting place. 👍

I've been thinking a bit more about this, but I feel I need to work with the toolkit a bit more before patterns start to emerge. Meanwhile, I'll continue using this issue as a place to do a braindump of styling-related ideas, in case someone wants to pick this up at some point.
General architecture
I feel the current styling implementation is conceptually solid. Storing style information in Envs instead of directly on the widgets, and using a series of nesting Envs to override styles for specific parts of the subtree are both great ideas. They remind me of CSS-in-JS implementations. I'm not a fan of them on the Web, but I feel that those patterns make sense in native toolkits.
Syntax sugar
It would be great to have syntax-sugar for quickly wrapping widgets inside Envs, but I feel that's a discussion for later. I imagine it could look something like this:
let inverted_label_style = style!{
  "text-color" => Color::white(),
  "background-color" => Color::black()
};
let styled_label = Label::new("A styled label").style(inverted_label_style);

Syntax inspired by CSS and maplit.
Env should be a struct
There have been discussions around storing enabled/disabled states for widget subtrees inside Envs (see #143). If that's going to be the actual API, it would make sense for Env to be a plain old struct with a standard set of fields (such as style and enabled). The fields could be Rust types or custom types depending on the functionality they represent.
In light of this, it makes sense to have some kind of a Style type that contains the functionality that Env currently has. This type could be responsible for other styling-related tasks, such as loading styles from a file (which could just be CSS, or a restricted subset of CSS).
Complex value types
It looks like Env can store complex types like LinearGradient and Rect, but the current theme isn't using those. Button, for example, manually creates a LinearGradient in its paint() using the BUTTON_LIGHT and BUTTON_DARK values.
From what I understand, this could directly be stored on the Env as a LinearGradient. In general, we will eventually need to store more complex data types for styling (such as paths, shadows, or transitions).

I think we're generally on the same page:

syntax sugar: This looks like a reasonable thing to explore, and is totally just a "haven't gotten to it yet" thing. I like the syntax.

Env as struct: The motivation for env to be a map is that it allows an application to define a bunch of custom style keys or other fields that have initial values, but which are then over-ridden at various points in the tree.
One thing to note is that the current design of Env is incomplete. In particular, we imagine having an array of 'override slots' that sits in front of the map; this will have some fixed, small size (8/16) and when you override a key on an env, we use these slots first; only if the slots are full do we actually clone and modify the map. This will let us have the map be a shared pointer in the general case, and reduce cloning, and this optimization will also be impossible if Env is a struct.

Complex value types: Yes, I agree we should be doing this; it's either an oversight or else the API wasn't available originally.

The motivation for env to be a map is that it allows an application to define a bunch of custom style keys or other fields that have initial values, but which are then over-ridden at various points in the tree.

My concern with this is that Env might end up becoming a kind of stringly-typed dumping ground for everything that needs to be shared across the widget tree, with no way for the user of the library to know which keys they can expect to find on it.
A good design, IMHO, would define a standard set of fields that can be expected to always be present, and also allow one field that could contain arbitrary data. For example:
struct Env {
    style: SomeKeyValueStoreType,
    enabled: bool,
    user_data: SomeKeyValueStoreType,
    ...
}

However, I understand your concern @cmyr. Having this struct would result in a lot of cloning everywhere. I'm wondering if there's a way to have things both ways, but my Rust skills are not quite good enough to get there yet.

So I think that we fundamentally agree, and Env actually is our attempt to have it both ways, and was inspired by basically identical concerns to yours.
The contents of Env should be 100% known at all times; it will either be items that are declared and documented in druid, or it will be items that have been explicitly added by the framework user. In addition, Env has some interesting properties (enforced by the API) that make accidental surprises unlikely during use:

Env entries cannot be deleted; the built-in entries, as well as any entries added by the user at launch, are guaranteed to always be available and always be the correct type, because,
Env keys are typed, and it is a hard error to try and overwrite a key with a key of a different type. So for instance env.set(theme::TEXT_COLOR, Size(50.0, 20.0)) will crash.

The goal, is basically that Env should have all of the guarantees of a struct, but allow arbitrary new fields, and should existing fields to be overwritten at various points in the tree, assuming the new and old types are the same. For instance: It is intended that the user can add arbitrary items to their env; for instance if they are writing (say) a music notation editor, they might have a NOTE_COLOR key, which they overwrite at various places in their widget graph to change how notes are drawn.

I'll go through widgets and will move non-configurable parameters to theme as in commit ^^
cc @futurepaul

@Dmitry-Borodin thanks a lot for taking this up. I've been building an app where I want the buttons to have a more "flat" look than they have by default, and the lack of some of these configurable tokens was preventing me from building what I wanted.
Just a note on your commit: I feel it would make more sense to have a BORDER_RADIUS_LARGE and BORDER_RADIUS_SMALL instead of BUTTON_RADIUS and TEXTBOX_RADIUS. This kind of naming is what you usually see in design systems for the web.
More generic names for design tokens encourages reuse, which then makes it easier to override the look of multiple widgets by changing a small number of tokens. It also establishes a hierarchy of measures where the variables in the hierarchy can be configured such that they are mathematically related to each other.
For example, in my app I could could force the margins between widgets as well as the sizes of widgets to be whole number multiples of 4. This would result an implicit grid that all widgets would line up with, thus producing a UI that feels more balanced to look at.

@s3thi sorry I probably didn't get what do you mean. Currently widget takes some predefined values from theme by key, and the key for button starting with "button", because I may define it bigger or smaller than for textbox in my app.
This is the name for key, not for default value.
For example if I want textbox radius to be bigger than a button. If I would rename those keys to big and small, I would have to set value for BORDER_RADUIS_LARGE smaller, than for BORDER_RADUIS_SMALL, which is misleading.
I like the idea of adding "border" to the key name for clarification.

@Dmitry-Borodin I wasn't clear enough in my comment. Apologies.
I opened this issue because I felt it would be useful if Druid's styling system was inspired by the "design systems" concept that is popular in UX design right now.
When you build a design system for an app, you start with a basic set of values and measures called design tokens. This can include colors, font styles, font sizes, margins and paddings, opacities, shadows, etc. These common values are shared across all the widgets in the design system. For an example of what that looks like, see https://www.lightningdesignsystem.com/design-tokens/#category-radius
These design tokens are defined first, and the widgets are designed around them. That is, instead of building a TextBox, Button, and Slider first and then extracting common values for colors, border, etc. from them, you define the common values first and build your widgets around those common values. Of course, there will be cases when those common values won't make sense, but the idea is to keep the number of those exceptional cases as small as possible.
This approach lets you radically change the look and feel of your UI by changing a very small number of variables. You could make a design more compact by simply changing three or four padding values, or you could make a design more or less rounded by simply changing two or three radius values. This gives developers a lot of freedom to experiment with design without having to change too much code.
So, instead of extracting PROGRESS_BAR_RADIUS, TEXTBOX_BORDER_RADIUS, and BUTTON_BORDER_RADIUS from the code, we could define more generic values for border radius. We could call these values BORDER_RADIUS_SMALL, BORDER_RADIUS_MEDIUM, and BORDER_RADIUS_LARGE.
The value of BORDER_RADIUS_SMALL could be 2.0, BORDER_RADIUS_MEDIUM could be 4.0, and BORDER_RADIUS_LARGE could be 8.0. In the paint method of Button, ProgressBar, and TextBox, we could use one of those generic values instead of using specialized values for each widget.
Future widgets could be designed around those three values, and defining new values would be restricted to very special cases.
If a user of Druid decides they want a more angular design for their app, they could reset all of these values to 0.0. Just changing those three values would radically change the look of the entire app. This would make experimentation easier, and developers would find it easier to customize their applications.
I hope this made more sense than my previous comment.

I feel like Env is a more low-level abstraction. The current approach to store various theme parameters in there is the right decision; we can easily adjust how a particular widget looks. On top of Env, you can develop more high-level abstraction like a theme, which would change all env keys for widgets, e.g., you can create a struct with parameters as @s3thi suggested.
Something like this:
struct MyTheme {
    pub border_radius_small: f64,
    pub border_radius_medium: f64,
    pub border_radius_large: f64,
    ...
}

impl MyTheme {
    pub fn apply(&self, env: &mut Env) {
        env.set(theme::BUTTON_BORDER_RADIUS, self.border_radius_medium);
        env.set(theme::SCROLLBAR_RADIUS, self.border_radius_small);
        env.set(theme::PROGRESS_BAR_RADIUS, self.border_radius_small);
        env.set(theme::TEXTBOX_BORDER_RADIUS, self.border_radius_medium);
        ...
    }
}

What I don't like in current approach - it is how the library is rendering widgets, I like how flutter managed this, there I can make my buttons, text boxes, and other widgets look how I want. I would like to have control over how my widgets look, I would like to implement paint from scratch, but I don't want to reimplement all event handling and layout measurement and so on.

I definitely think there's lots of room for us to find new and better patterns for this stuff. At least with buttons, we've moved in this direction; you can use the Painter widget + on_click() to have a custom clickable widget, and you don't need to implement any fancy logic. More experimentation in these directions is definitely welcome!

Is there any progress in this discussion?
I think @s3thi's suggestion is good.

Complex value types
It looks like Env can store complex types like LinearGradient and Rect, but the current theme isn't using those. Button, for >example, manually creates a LinearGradient in its paint() using the BUTTON_LIGHT and BUTTON_DARK values.
From what I understand, this could directly be stored on the Env as a LinearGradient. In general, we will eventually need to >store more complex data types for styling (such as paths, shadows, or transitions).

I am currently working on a project of my own. When using the button, I want the button to be a solid color, the activated state is another solid color, and the disabled state is also another solid color. His suggestion, if implemented, should allow me to set the theme of the button in an elegant way.
My rust is not very good. Currently I want to implement my button theme. It can only be implemented locally through the clone repository, local reference, and modification of the local druid source code. Or is there a better way to achieve it?


Replace kuberay-cluster chart variants with a single yaml

Additionally, use the head for running jobs instead of spinning up a (head, worker) pair. I have not found Ray documentation recommending otherwise. Besides, the current worker is tiny in terms of CPU and we are not using the multi-GPU setup as far as I'm aware.
I tested the entire RAG application E2E on Autopilot. I also generated all permutations of ray cluster helm charts using terraform plan to made sure the image, resources, annotations, and node selectors match their prior values.

/gcbrun

/gcbrun


Calibration Reference Persistence

https://github.com/adafruit/Adafruit_CircuitPython_SCD30/blob/72c1ccb3c45d6d5cd005bc0bfd792d8e81fc99cd/adafruit_scd30.py#L225
This doesn't mention the calibration persisting on reset like other parameters such as: https://github.com/adafruit/Adafruit_CircuitPython_SCD30/blob/72c1ccb3c45d6d5cd005bc0bfd792d8e81fc99cd/adafruit_scd30.py#L203
I've set the forced recal reference before, and sometimes, but not always it'll reset to the default when I turn off & on the board I'm using. Other times, my recalibration reference persists. Is there sometimes I'm doing wrong or something I can do to ensure it persists? I use the sensor inside & it's a hassle to bring it back outside to recalibrate it.

I have the same issue - it sometimes persists and sometimes resets to 400.

Any updates on this?


[Event Request] Report 11511 - OnCopyPurchaseLineDiscounts

Please add a new integration event OnCopyPurchaseLineDiscounts in Report 11511.
local procedure CopyPurchaseLineDiscounts(FromItemNo: Code[20]; ToItemNo: Code[20])
    var
        PurchLineDiscount: Record "Purchase Line Discount";
+       IsHandled: Boolean;
    begin
        if not CopyPurchLineDisc then
            exit;

        PurchLineDiscount.SetRange("Item No.", FromItemNo);
        if PurchLineDiscount.FindSet then begin
            InitDialog(Text032);
            repeat
+               IsHandled := False;
+               OnCopyPurchaseLineDiscounts(PurchLineDiscount, FromItemNo, ToItemNo, IsHandled);
+               if not IsHandled then begin
                    PurchLineDiscount."Item No." := ToItemNo;
                    PurchLineDiscount.Insert;
                    PurchLineDiscount."Item No." := FromItemNo;
+               end;
                UpdateDialog;
            until PurchLineDiscount.Next = 0;
        end;
    end;

New integration event
[IntegrationEvent(false, false)]
local procedure OnCopyPurchaseLineDiscounts(var PurchLineDiscount: Record "Purchase Line Discount"; FromItemNo: Code[20]; ToItemNo: Code[20]; var IsHandled: Boolean);
begin
end;

This DACH feature have been replaced by W1 page 730 Copy Item due to better extensiblity for pages after multiple partner requests. Can you please convert to using this page instead. Old report 11511 is being deprecated.


Introduce the ability to kill competing transactions that hold exclusive lock during swap

This introduces wait_time_for_lock and kill_backends as new flags.
By default pgosc won't kill any backends if it cannot acquire an
AccessExclusiveLock to perform the swap. It will retry upto 3 times
and for the duration specified in wait_time_for_lock (default: 10s).
So, in total 30s. Configurable. If kill_backends/kill-backend
is set to true (supplied), then it will kill the backend on each try
it couldn't acquire the lock, upto 3 times before exiting. Though,
after killing the backends after 1st attempt should work.
Specs added. A bit messy for now. Refactor in the end
closes https://github.com/shayonj/pg-online-schema-change/issues/16

I have the approach described here - https://github.com/shayonj/pg-online-schema-change/pull/23#
Lmk if you anticipate any concerns, early stress tests came positive 🙌🏾


Introducing RFC 0017 Workload Conventions

Readable

I'm assuming the build failure is a flaky test, since it doesn't seem at all related to the change.

Draft source code is now public at https://github.com/vmware-tanzu/cartographer-conventions
This repo is largely a dump into OSS, there will be more work required to align with Cartographer-isms.

A more detailed design doc for conventions is available in the repo https://github.com/vmware-tanzu/cartographer-conventions/blob/main/docs/design.md

Propose moving into final comment period

squashed and rebased


Indentation of raw block

#test[
```typ
123123
123
```
]

becomes
#test[
  ```typ
  123123
  123
  ```
]

This doesn't affect output. Some user prefers first one but personally I like current behavior

single arg raw indent has been fixed now


TF-32 Tensor Cores not used

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 20.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: NA
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 2.6.0
Python version: 3.8
Bazel version (if compiling from source): NA
GCC/Compiler version (if compiling from source): NA
CUDA/cuDNN version: 11.1
GPU model and memory: RTX A6000, 48GB

Describe the current behavior
I'm training a fairly large convnet, and with long training times, one thing I've noticed is apparent lack of tensor core utilization. I have tried using float16, but my model greatly suffers from the reduced precision. However, since this is an Ampere GPU I expect to be able to use tensor cores in 32 bit as well. Using the tensorboard profiler, I see many of my kernels are tensor core eligible but none are actually using tensor cores.

All of my convolution layers have multiples of 8 for filters (32, 64, 128, etc.) so dimensions should not be affecting tensor cores. One other thing I though worth noting was lots of memory being taken up by NHWC->NCHW transpose layers. It's my understanding that tensor cores should operate entirely in NHWC, so my model should not be doing any computation in NCHW and yet it seems to be.

Describe the expected behavior
I expect Tensor Cores to be used for most convolution and matmul operations provided the multiple-of-8 condition is met. One thing I'm wondering: is it possible that the bug is actually in reporting tensor core usage rather than not using tensor cores in the first place? I.e. is tensorboard only looking for float16 tensor cores and not reporting tf-32 operations as using tensor cores when they actually are? That still doesn't explain the NCHW behavior though.
Standalone code to reproduce the issue
Working on producing an example. Colab is not an option due to lack of Ampere GPUs
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.
Here is my TensorBoard log file. This includes the profiler data as well as a model checkpoint for inspecting the architecture
20210902-145514.zip

@atyshka Could you please post this issue in Tensorboard repo ,you will get the right help there ?Thank you!

Hi,
Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.
The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.
Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.


ARROW-5884: [Java] Fix the get method of StructVector

When the data at the specified location is null, there is no need to call the method from super to set the reader
holder.isSet = isSet(index);
super.get(index, holder);

Codecov Report

Merging #4831 into master will increase coverage by 2.15%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #4831      +/-   ##
=========================================
+ Coverage   87.44%   89.6%   +2.15%
=========================================
  Files         997     662     -335
  Lines      139804   96427   -43377
  Branches     1418       0    -1418
=========================================
- Hits       122246   86399   -35847
+ Misses      17196   10028    -7168
+ Partials      362       0     -362

Impacted Files
Coverage Δ

cpp/src/arrow/json/converter.cc
90.53% <0%> (-1.78%)
:arrow_down:

cpp/src/arrow/json/chunked-builder.cc
79.91% <0%> (-1.68%)
:arrow_down:

cpp/src/arrow/io/readahead.cc
95.91% <0%> (-1.03%)
:arrow_down:

r/src/recordbatch.cpp

r/R/Table.R

js/src/util/fn.ts

go/arrow/array/bufferbuilder.go

r/src/symbols.cpp

rust/datafusion/src/execution/projection.rs

rust/datafusion/src/execution/filter.rs

... and 329 more

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 3f767ce...49148aa. Read the comment docs.

+1, LGTM


Lookup field problem

I have problem with inline searching in lookup field. It's not working as expected and it can't find any record. Found/proposed records doesn't match current search condition. In lookup search condition it must find whole number in primary field with SLT definition, but search results are bad.
I'm looking for solution that inline lookup field in grid can search over multiple fields in lookup view. We notice that it can be define only public view types. Is it possible to use other view types (lookup or other type) and search over multiple fields in lookup grid field? Do you plan to build some lookup search types (contains, startwith...)?
Thank you for this excellent component!

I am facing the same problem as @pajso.
Any means I can get the user input in the lookup search text field such that I can include those input text as the addition.Conditions ?
additions.Condition = '<condition attribute="productnumber" operator="begins-with" value="',userinputtext,'"/>';
The main objective is to include another searchable attribute ( productnumber) from the product apart from name.

I will try to include a third parameter 'userinput' to the JS callback in the next release.


How to re-render the Buttons component when createOrder() function changes

I'm creating a checkout with the PayPalButtons, and I found an interesting bug, that made me realize something... We don't re-render the button if one of its functions changes, meaning that I created the createOrder function on the page, and this function depended on the shipping address coming from the context. It's undefined at first, but as soon as it gets re-hydrated, it gets the correct object.
The issue is that the PayPalButtons component doesn't care about this change, it doesn't have anything on the useEffect dependencies saying that it should, like:
https://github.com/paypal/react-paypal-js/blob/ba915eb6a932f097e0b3b5302ee341a3a8166027/src/components/PayPalButtons.tsx#L70
And then what I had to do is create add:
        forceReRender={!!shippingAddress}

That makes the button re-render the function on re-hydration.
I think we should add the functions on the dependency there, and ask our users to use useCallback with some dependencies on their apps, it would solve this type of issue.

Hi @pedroapfilho, we added the forceReRender prop in this PR: https://github.com/paypal/react-paypal-js/pull/56. This was added to be conservative with our re-render strategy. Here's a storybook example showing how to use forceReRender when the amount changes: https://paypal.github.io/react-paypal-js/?path=/story/example-paypalbuttons--dynamic-amount

I think we should add the functions on the dependency there, and ask our users to use useCallback with some dependencies on their apps, it would solve this type of issue.

Unfortunately props that are functions do not play nice with the useEffect watch list: https://paypal.github.io/react-paypal-js/?path=/story/example-paypalbuttons--dynamic-amount. They are always considered "changed" even when the actual function is exactly the same. The forceReRender prop seems to provide a way for the developer to manage re-rendering so I don't see this as a blocker. I'm open to PRs if you find another way to manage this.

Hi @pedroapfilho, we added the forceReRender prop in this PR: https://github.com/paypal/react-paypal-js/pull/56. This was added to be conservative with our re-render strategy. Here's a storybook example showing how to use forceReRender when the amount changes: https://paypal.github.io/react-paypal-js/?path=/story/example-paypalbuttons--dynamic-amount

I think we should add the functions on the dependency there, and ask our users to use useCallback with some dependencies on their apps, it would solve this type of issue.

Unfortunately props that are functions do not play nice with the useEffect watch list: https://paypal.github.io/react-paypal-js/?path=/story/example-paypalbuttons--dynamic-amount. They are always considered "changed" even when the actual function is exactly the same. The forceReRender prop seems to provide a way for the developer to manage re-rendering so I don't see this as a blocker. I'm open to PRs if you find another way to manage this.

@gregjopa actually, that's why you could ask the developers to use useCallback in their functions, this is a common practice in other libraries.

@gregjopa actually, that's why you could ask the developers to use useCallback in their functions, this is a common practice in other libraries.

The useCallback hook is pretty cool. What do you think about using it with createOrder and forceReRender like so? It's using createOrder with a dynamic amount. I think the same could be applied to a dynamic shippingAddress.

export const DynamicAmount = () => {
    const [amount, setAmount] = useState(2);
    const [orderID, setOrderID] = useState(false);

    // use useCallback to only update the value of `createOrder` when the `amount` changes
    const createOrder = useCallback((data, actions) => {
        return actions.order
            .create({
                purchase_units: [
                    {
                        amount: {
                            value: amount,
                        },
                    },
                ],
            })
            .then((orderID) => {
                setOrderID(orderID);
                return orderID;
            });
    }, [amount]);

    function onChange({ target: { value } }) {
        setAmount(value);
        setOrderID(false);
    }

    return (
        <>
            <select onChange={onChange} name="amount" id="amount">
                <option value="2">$2.00</option>
                <option value="4">$4.00</option>
                <option value="6">$6.00</option>
            </select>

Order ID: {orderID ? orderID : "unknown"}

            { /* pass createOrder to forceReRender to trigger a re-render when it changes */ }
            <PayPalButtons createOrder={createOrder} forceReRender={createOrder} />
        </>
    );
};

I know there's the pain of the extra step of assigning the memoized createOrder to forceReRender but it seems like a fair compromise.

The useCallback hook is pretty cool. What do you think about using it with createOrder and forceReRender like so? It's using createOrder with a dynamic amount. I think the same could be applied to a dynamic shippingAddress.

export const DynamicAmount = () => {
    const [amount, setAmount] = useState(2);
    const [orderID, setOrderID] = useState(false);

    // use useCallback to only update the value of `createOrder` when the `amount` changes
    const createOrder = useCallback((data, actions) => {
        return actions.order
            .create({
                purchase_units: [
                    {
                        amount: {
                            value: amount,
                        },
                    },
                ],
            })
            .then((orderID) => {
                setOrderID(orderID);
                return orderID;
            });
    }, [amount]);

    function onChange({ target: { value } }) {
        setAmount(value);
        setOrderID(false);
    }

    return (
        <>
            <select onChange={onChange} name="amount" id="amount">
                <option value="2">$2.00</option>
                <option value="4">$4.00</option>
                <option value="6">$6.00</option>
            </select>

Order ID: {orderID ? orderID : "unknown"}

            { /* pass createOrder to forceReRender to trigger a re-render when it changes */ }
            <PayPalButtons createOrder={createOrder} forceReRender={createOrder} />
        </>
    );
};

I know there's the pain of the extra step of assigning the memoized createOrder to forceReRender but it seems like a fair compromise.

Sure is! Do we have docs/stories for this use case? It would be nice to have! I can add!

Sure is! Do we have docs/stories for this use case? It would be nice to have! I can add!

Do we have docs/stories for this use case? It would be nice to have! I can add!

@pedroapfilho that would be awesome! It would be great to update this "Dynamic Amounts" story to use useCallback like in the above code snippet: https://github.com/paypal/react-paypal-js/blob/main/src/stories/PayPalButtons.stories.js#L52. Would you be up for sending a PR for that?
It would be cool to add a new story for re-rendering when the shippingAddress changes as well.

Do we have docs/stories for this use case? It would be nice to have! I can add!

@pedroapfilho that would be awesome! It would be great to update this "Dynamic Amounts" story to use useCallback like in the above code snippet: https://github.com/paypal/react-paypal-js/blob/main/src/stories/PayPalButtons.stories.js#L52. Would you be up for sending a PR for that?
It would be cool to add a new story for re-rendering when the shippingAddress changes as well.

I'll create a PR for it this weekend! I have some other use-cases for that too! Like, what should we do when we depend on more than one value? Should how do we create a list of dependencies?

I'll create a PR for it this weekend! I have some other use-cases for that too! Like, what should we do when we depend on more than one value? Should how do we create a list of dependencies?

@gregjopa What if we make it accept an array of dependencies on the forceRerender? So we can pass a list of values there, and if any changes, we re-render it?

@gregjopa What if we make it accept an array of dependencies on the forceRerender? So we can pass a list of values there, and if any changes, we re-render it?

@gregjopa What if we make it accept an array of dependencies on the forceRerender? So we can pass a list of values there, and if any changes, we re-render it?

@pedroapfilho sure that’s a great idea. Would you be up for sending a PR for this?

Sure! Gonna cook it up this week!

Do we have docs/stories for this use case? It would be nice to have! I can add!

@pedroapfilho that would be awesome! It would be great to update this "Dynamic Amounts" story to use useCallback like in the above code snippet: https://github.com/paypal/react-paypal-js/blob/main/src/stories/PayPalButtons.stories.js#L52. Would you be up for sending a PR for that?
It would be cool to add a new story for re-rendering when the shippingAddress changes as well.

In the current example, changing the amount will produce the console error Failed to render <PayPalButtons /> component. Error: Component closed unless you wait a couple second after each change. I'm using Radio buttons to change the amount and get this quite a lot during normal use.

Is there a way to update the order without closing the form? In my case, I want to update the order when the user enters a discount code. But the problem is that if the user fills the form, then adds the discount code, because we updated the order, we need to close the form, so all the data that the user entered is lost and needs to fill the form again

use latest values (from state or props) in createOrder function without needing to force a re-render of the paypal buttons component (because that looks bad when it happens on every keystroke of a form input):
`
import {
type FC,
useEffect,
useRef,
} from 'react';
import { PayPalButtons } from '@paypal/react-paypal-js';
const CheckoutButton: FC<{
email: string;
address_line_1: string;
city: string;
country_code: string;
first_name: string;
last_name: string;
phone_number: string;
postal_code: string;
state: string;
address_line_2?: string | undefined;
}> = (values) => {
const {
cartState,
dispatchCartAction,
setSnackbarErrorMessage,
} = useGlobalStateContext();
const { mode } = usePalletModeContext();
const cartStateRef = useRef(cartState);
const valuesRef = useRef(values);
useEffect(
	() => {
		cartStateRef.current = cartState;
	},
	[cartState],
);

useEffect(
	() => {
		valuesRef.current = values;
	},
	[values],
);

return (
	<PayPalButtons
		createOrder={async (_data, _actions) => {
			return await asynchronousMutationThatReturnsTheOrderID({
				items: cartStateRef.current,
				shipping: valuesRef.current,
			});
		}}
		forceReRender={[mode]}
		onApprove={async (_data, actions) => {
			if (actions.order) {
				await actions.order.capture();
				dispatchCartAction({ type: 'empty' });
			}
		}}
		style={{
			color: mode === 'dark'
				? 'black'
				: undefined
		}}
	/>
);

};
`


Value not updating on time change

The model data doesn't update when the time is changed in the datepicker without the date also being changed.
To Reproduce

Select Date and Time with datepicker
Reopen datepicker and change the time only (keeping date the same)
Model value is not updated with new time / @update function not triggered

Expected behavior
Expect @update triggered by time changes and model value to be updated

Browser: Chrome
vue-datepicker v5.2.0
vue v3.3.2

It appears to be working as expected, please provide a reproduction link or which props you are using.


Running Sensu on Windows as a specific account

I have a need to run Sensu on Windows with a different account to the default LocalService/LocalSystem that it uses by default. This would require registering the service with some different Powershell that looks something like this:
$securePassword = convertto-securestring -String "password" -AsPlainText -Force
$credentialsObject = new-object -typename System.Management.Automation.PSCredential -argumentlist "username", $securePassword
New-Service -Name sensu-client -Credential $credentialsObject -BinaryPathName c:\\opt\\sensu\\bin\\sensu-client.exe -DisplayName 'Sensu Client' -StartupType Automatic

This doesn't strike me as something very idempotent if one were to change the account details after the service has already been registered.
Would it make sense to instead use one of the dsc_service or dsc_xservice types from the DSC module which should a) hide the scary Powershell and b) hopefully be a bit more idempotent w.r.t. the account credentials?

Hi @bodgit
We do expose the parameters, manage_user along with sensu_user and sensu_group. Would that work for you?

I notice on Windows that parameter doesn't do anything, there's just a notice(), however I'm not sure it would help anyway as you would still need to register the service with the user you wish to run Sensu as and also I need to run Sensu as a user that already exists in Active Directory. Being able to pass sensu_user at least means I can theoretically make the files owned by that same AD account although I was planning on tackling file ownership outside of this module as technically it can all still be owned by the local account, the AD account just needs permission to read/run the Sensu binaries.
The long story is I have a need to monitor some files/directories that are on SMB/CIFS shares with fairly restrictive permissions, and it's preferable to create a dedicated AD account for Sensu to run with that has read-only access to the shares rather than grant access to the LocalService/LocalSystem account (which I'm not even sure is possible).
What I've done so far is replace the exec with the following (currently untested):
      dsc_service { 'sensu-client':
        dsc_ensure      => present,
        dsc_name        => 'sensu-client',
        dsc_state       => $service_ensure,
        dsc_startuptype => $service_enable ? {
          true    => 'automatic',
          default => 'disabled',
        },
        dsc_credential  => { # This will become a class parameter, or maybe can reuse $sensu_user?
          'user'     => 'DOMAIN\user',
          'password' => 'password',
        },
        dsc_displayname => 'Sensu Client',
        dsc_path        => 'c:\\opt\\sensu\\bin\\sensu-client.exe',
        require         => File['C:/opt/sensu/bin/sensu-client.xml'],
        before          => Service['sensu-client'],
      }

In theory it's functionally equivalent to the exec but I'm not sure if it needs to supplant the regular service resource type or not.

I've created #823 which contains the changes I've made to get things working.


Update github workflows

olafurpg/setup got deprecated in https://github.com/olafurpg/setup-scala/releases/tag/v14

replaced by actions/setup-java@v3
enabled sbt caching

olafurpg/setup-gpg is no longer required since sbt-ci-release v1.5.5

I forgot to amend my last commit, will you squash them when merging ?


Support wagtail42

Hi
This PR updates the requirements to allow Wagtail 4.1 +
As the LTS is now 4.1 I have removed the compatibility checks for wagtail <4.1
If you would prefer to keep those in place I can alter the PR. Thanks

HI @nickmoreton , This LGTM. Thanks!

Thanks for this, just published this in version 4.1.0


Menu bar drop down shows up on secondary (left) monitor

I have a two monitor setup. Left monitor 22" is the secondary monitor. Right monitor 27" is the primary monitor and where I mostly use Atom.
When the window is in a certain position on the right monitor the drop down menu will be slammed to the very right edge of the left monitor. If I move Atom further from the left monitor the drop down menu will work just fine. If Atom is on the left screen entirely the drop down menu works fine. It seems that about 4" from the very left of the primary monitor the drop down menu works fine. No other applications are doing this. Ran it in safe mode with same results.
The edge of the task bar is the cutoff between the left and right monitors. The drop down menu's are cut off half way at the bottom, I'm pretty sure this is just due to the pressing of the print/screen button; the full menu displays.
Drop down menu showing up on left screen.

Drop down menu showing as it should when Atom is moved further to the right on the right monitor.

OS: Ubuntu 15.10
Desktop: Mate 1.10.2 (Also was happening on KDE Plasma5 same setup)
GPU: nvidia GeForce GTX 550 Ti
Driver: 352.63
Atom: 1.3.1
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>

Refs #8921, #3415.

50Wliu It's not the same issue.

I have found solution ! Lol.
You have to add two lines to the "screen" section of nvidia
Option         "nvidiaXineramaInfo" "False"
Option         "nvidiaXineramaInfoOverride" "False"

So, this is my screen section of nvidia:
Section "Screen"     Identifier     "nvidia"     Device         "nvidia"     Monitor        "Monitor0"     DefaultDepth    24     Option         "AllowEmptyInitialConfiguration"     Option         "nvidiaXineramaInfo" "False"     Option         "nvidiaXineramaInfoOverride" "False"     Option         "eDP-1" "Monitor0"     Option         "HDMI-0" "Monitor1"     Option         "BaseMosaic" "True"     Option         "MetaModes" "GPU-0.DFP-0: 1920x1200+0+0, GPU-0.DFP-0: 1920x1200+1920+0"     Option         "ConstrainCursor" "0"     Option         "nvidiaXineramaInfoOverride" "1920x1200+1920+0, 1920x1080+0+0+0+0"     Option         "TwinView"     Option         "Coolbits" "12"     SubSection     "Display"         Depth       24         Modes      "nvidia-auto-select"     EndSubSection EndSection

Changing those nvida options didn't work for me.


[SYSTEMML-1134] Remove unused enums from project

Unused enums should be removed from the project because they are misleading.
Here is a list of unused enums in the project:
org.apache.sysml.hops.Hop.ExtBuiltInOp
org.apache.sysml.parser.Expression.ExtBuiltinFunctionOp
org.apache.sysml.runtime.matrix.data.RuntimeDataFormat

All tests passed: https://sparktc.ibmcloud.com/jenkins/job/SystemML-OnDemand/222/

leave ExtBuiltinFunctionOp with TODO to investigate.

Restored Expression.ExtBuiltinFunctionOp and added a TODO to investigate


Foreign key constraint violation

Every so often, we see the following:
               Last_SQL_Error: Error 'Cannot add or update a child row: a foreign key constraint fails
(`tms`.`tm_text_unit`, CONSTRAINT `FK__TM_TEXT_UNIT__ASSET__ID` FOREIGN KEY (`asset_id`)
REFERENCES `asset` (`id`))' on  query. Default database: 'tms'. Query: 'insert into tm_text_unit
(created_date, asset_id, comment, content, content_md5, created_by_user_id, md5, name,
plural_form_id, plural_form_other, tm_id, word_count)  values ('2021-07-20 13:51:48.084', 357605,
null, '0 bytes', 'ca4a3b82feeaa8b9a19da4cc4f508199', 182, '0d3febfde3a39464da71d1fc71244986',
'LS_0_byte', null, null, 389, 2)'

in the log.
Any ideas as to what this may be? Not sure what is triggering it or how to repro it.

Actually, we figured it out... the replica of our main db was out of sync, causing this FK issue when things synced in an odd way. It was not really a mojito/spring framework issue, but a database configuration issue.


convert functions:tf2trt,tf2onnx,keras2onnx and unittest

Closes #

What has been done to verify that this works as intended?
run "python -m pytest tests/test_tensorflow_conversion.py"  in terminal
Why is this the best possible solution? Were any other approaches considered?
tf2onnx api is the core code in these functions:  a more convenient way to decouple the framework version and our functions
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
users are required to install tf2onnx api and should keep their gpu and cuda avalible for trt service
Does this change require updates to documentation?
no
Before submitting this PR, please make sure you have:

[yes ] run python -m pytest tests/ and confirmed all checks still pass.
[ yes] verified that any code or assets from external sources are properly credited.

Does the checking do not support trt environment or is there something wrong with my fork submit?

First, check Codacy report, there is some coding style problems with your PR. Fix them first.
Then, you can explore how to do a unitest on TRT conversion using GitHub action.


List of Destinations

[x] Create a list to store each destination
[ ] #31
[ ] Update markers when destination is removed
[ ] Update route when destination is removed
[x] (Optional) Update destination list when marker is moved
[x] Click save to store in database

We decided to not implement the removal of markers given the time constraints


Photos 18 problem?

Source information
Photos 18
Source language
Multi
Steps to reproduce
Well, Not working! Browsing mangas but bo thumbnail or chapters loading!
Expected behavior
Should be able to browse picture
Actual behavior
Errors found.
The image couldn't be loaded!
Mihon/Tachiyomi version
TachiYomisy
Android version
Android 13
Other details

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.15.3.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[ ] I have admitted that I am a clown by having checked this box, as I have not read these acknowledgements.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

fixed in #1477


Update ThankArb collection

What is it?
The following projects were added / updated in the most recent PR to oss-directory. They should be included in the Thank Arb collection
appcalipse
arbilearn-aliveevie
arbitrumhub
astralprotocol
astrodevs-labs
basket-swap-stylus-teeeeeo9
cartographer-syndicate
circuitscan
coindlabs
collabberry
cryptosmartnow
daomasons
decentralized-library-gifted-brain-lab
duel3
ecoland-world
elefria-labs
ethdailyhub
ethereum-attestation-service
framelib
givestation
glo-foundation
grantsscope
greenpill-dev-guild
hvax
hypercerts
ikigai-labs-xyz
inferer
lexdao
merkle-root-inc
moona-lisa
nounspace
pattern-tech
peacekeepers88
peeramid-labs
rankify-it
refi-starter
rndao
seroxdesign
sherlock-protocol
solide-project
songs-tools
stogramhq
theforus
thenamespace
togethercrew
tx-city
umbra-scopelift
vyperlang
web3-gpt
zktlabs

cc @rohitmalekar

Thanks @ccerv1, raised a PR to update the Thank Arb collection (the checks are successful).

Marking as complete!


SRS Problem Description confusion

After reading the SRS, I'm not entirely sure about the purpose of Kaplan. I understand that it finds a set of conformers for a molecule, but what makes one potential set of conformers a "better fit" than another? My best guess is that the "best fit" set of conformers are the conformers that are most likely to actually occur in nature. If this is correct, it should be explicitly stated, and I think the Problem Description section 5.1 is the place to do that.
It may also be that if I had all of the characteristics of the intended reader, I would have understood this even without it being explicitly mentioned, in which case it might not be necessary to add anything (though I still think it couldn't hurt).

I added a bit more explanation to the problem description 249c7d2


Crash with tweakaroo

It seems like there is an issue with tweakeroo when i place an escalator
crash-2021-01-19_13.52.22-client.txt

Hello, thank you for your crash report. I have tried running tweakeroo of the same version in Minecraft but I had no issues when placing down escalators. I wasn't able to reproduce your crash.
Would you mind sharing which tweakeroo settings you had enabled? I think I tried fast right click and fast block placing, both of which did not have issues.

Hello, thank you for your crash report. I have tried running tweakeroo of the same version in Minecraft but I had no issues when placing down escalators. I wasn't able to reproduce your crash.
Would you mind sharing which tweakeroo settings you had enabled? I think I tried fast right click and fast block placing, both of which did not have issues.

Yeah here you go. had to zip it. I have been placing some routes down to test and the mod looks AWESOME!
tweakeroo.zip

Yeah here you go. had to zip it. I have been placing some routes down to test and the mod looks AWESOME!
tweakeroo.zip

Fixed in version beta-2 of the mod. Take a look and let me know if the issue persists. Thanks!

Fixed in version beta-2 of the mod. Take a look and let me know if the issue persists. Thanks!


split repositories access

Hi @aslakhellesoy,
I've just pushed a few changes to master (f15cd9e4bade05602a3fa515e12886ae5ee5dfea...d552bc93333bdfa21ec605a370e7790308c8148f). I then tried to push these changes to the https://github.com/cucumber/gherkin-go split repository, but I don't have access to this yet:

ERROR: Permission to cucumber/gherkin-go.git denied to muhqu.
fatal: Could not read from remote repository.

Would you mind giving me push access the split repositories as well?

Sorry about that @muhqu. Done!


Add ability to use scenarios for question_options

Eg, I am running a question where I prompt the agent to take a list and condense it into a set of answer options that I use in the follow-on question. But I am not able to input them in the new question as scenarios, as that only works for the question text.
Consider this together with piping.

Can you give an example of the syntax you’d like to use here?
On Wed, May 29, 2024 at 5:37 PM Robin Yerkes Horton <
@.***> wrote:

Assigned #576 https://github.com/expectedparrot/edsl/issues/576 to
@johnjosephhorton https://github.com/johnjosephhorton.
—
Reply to this email directly, view it on GitHub
https://github.com/expectedparrot/edsl/issues/576#event-12977562518, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADDNMTNOGR7GUZ75FGMB23ZEZDATAVCNFSM6AAAAABIPXQT6CVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSHE3TONJWGI2TCOA
.
You are receiving this because you were assigned.Message ID:
@.***>

Eg the response to QuestionList is a list. I want to pipe that into the follow on question as a scenario of the question_options, not just a list that I input.


Form label does not display in Tina editor

Description
A form label is defined, but it does not show in the Tina editor at the top as it should. Here is a screenshot showing this:

This screenshot shows a blank white area above the label "Products."
Steps to reproduce
Here is the page code which includes the form options:
import { useLocalMarkdownForm } from 'next-tinacms-markdown';
import matter from 'gray-matter';
import ReactMarkdown from 'react-markdown';
import { Layout, ProductTiles } from '../components';

export default function ProductsPage(props) {
  const formOptions = {
    label: 'Products Page', // LABEL IS SET HERE
    fields: [
      {
        name: 'frontmatter.title',
        label: 'Title',
        component: 'text'
      },
      {
        name: 'markdownBody',
        label: 'Body',
        component: 'markdown'
      },
      {
        name: 'frontmatter.products',
        label: 'Products',
        component: 'group-list',
        itemProps: item => ({
          key: item.id,
          label: item.name
        }),
        defaultItem: () => ({
          name: 'New Product',
          price: 0,
          description: 'Description',
          images: []
        }),
        fields: [
          {
            name: 'name',
            label: 'Name',
            component: 'text'
          },
          {
            name: 'price',
            label: 'Price',
            component: 'number'
          },
          {
            name: 'description',
            label: 'Description',
            component: 'text'
          },
          {
            name: 'images',
            label: 'Images',
            component: 'group-list',
            fields: [
              {
                // name: 'image',
                label: 'Image',
                component: 'image',
                parse: filename => `/content/images/${filename}`,
                previewSrc: () =>
                  'https://www.outbrain.com/techblog/wp-content/uploads/2017/05/road-sign-361513_960_720.jpg',
                uploadDir: () => '/content/images/'
              }
            ]
          }
        ]
      }
    ]
  };

  const [data] = useLocalMarkdownForm(props.markdownFile, formOptions);

  return (
    <Layout title={data.frontmatter.title}>
      <ReactMarkdown>{data.markdownBody}</ReactMarkdown>
      <ProductTiles products={data.frontmatter.products} />
    </Layout>
  );
}

ProductsPage.getInitialProps = async () => {
  const markdownData = await import('../../content/pages/products.md');
  const data = matter(markdownData.default);

  return {
    markdownFile: {
      fileRelativePath: 'content/pages/products.md',
      frontmatter: data.data,
      markdownBody: data.content
    }
  };
};

Expected result
The title should show.
Actual result
No title shows.
Environment
Tinacms Package Versions

├─┬<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>

Tools

Tool
Version

browser
79.0.3945.130 (Official Build) (64-bit)

os
macOS Version 10.15.1 (Build 19B88)

node
12.14.1

npm
6.13.4

yarn
1.21.1

Hey @chaddjohnson thanks for reporting this issue.
When we set up form labels we thought single form pages would benefit from dropping the form label as the distinction between different forms wasn't needed. While that assumption may often hold true I can see there are cases where even single forms benefit from a label. I think a better solution would be to always render the label if provided and allow people to omit the label when it's not needed.


Fix/networking minor fixes

URLRequester live extension made public.

Live extension needs to be public so it can be used when initializing the NetworkClient.


Wrong ClusterRole permission

Hi!
Using this manifest, I have found permission problems on AKS.
Failed to list *v1beta1.Replica Set: replica sets.apps is forbidden: User "system:serviceaccount:kube-system:metricbeat" cannot list resource "replicasets" in API group "apps" at the cluster scopeStreaming new entries

It is easily solved by adding the resource replicasets in the apiGroups "apps". Line 330
- apiGroups: ["apps"]
  resources:
  - statefulsets
  - replicasets
  - deployments
  verbs: ["get", "list", "watch"]

I hope it'll help.

@tehKapa this issue doesn't look related to the ARM template in this repository, but to some kind of deployment onto AKS, perhaps using one of the following

https://github.com/elastic/helm-charts
https://github.com/elastic/cloud-on-k8s