Feature request: execute statement and go to next step

Hi,
For the moment, in dbeaver, we can point the cursor in a query, execute it (for exemple with ctrl + enter shortcut). Which is cool.
But a feature that could be very useful to me is that once the SQL statement is finished (without error if possible), the cursor automatically goes at the beginning of the immediately following statement.
Example:

I put the cursor in the red statement, I execute it.
If it works, the cursor automatically jumps at the beginning of the blue statement.
Does it already exists? Or is it difficult to add?
Thanks in advance.

fyi: you can execute everything in sequence using execute script (alt-x)
this would execute the red statement and then the blue statement.
if the red statement errors you get a popup with the options retry, stop, ignore/continue

I'd probably rather see this as a "Move to next/prev statement", maybe Ctrl+Up/Down.  So if you want to step through several statements and execute them individually, you can Ctrl+Enter, Ctrl+Down, Ctrl+Enter, Ctrl+Down, etc.

Yes.
What I'm thinking about is a "step by step" execution, better than a script execution.

You can still do this by executing each statement in separate tabs - CTRL ALT X - if the statements do not depend on each other.
Otherwise, some other db managers combine the output of all executed commands in the Output window.

I think that adding a command like "move to the next/previous query" (with shortcuts like Ctrl+Down/Ctrl+Up) might be useful.
Just don't want to make yet another special execute command.

No problem. It makes the execution of consecutive queries easier.
Thanks.

Will be added in the next version (for now I set shortcuts ALT+Down and ALT+Up - because CTRL is reserved for text editor scrolling).


wp updates on challenge 3

adding challenge 3 informations

I have read the CLA Document and I hereby sign the CLA


Failed to load resource: the server responded with a status of 504 (Outdated Optimize Dep)

The error Failed to load resource: the server responded with a status of 504 (Outdated Optimize Dep) shows on first load. I looked at Vite's repo for potential issues, but didn't find any directly related issues, so I'm checking here first. Where do you think this error might be coming from @kentcdodds?
Steps to reproduce:

git clone https://github.com/epicweb-dev/epic-stack
code epic-stack
npm i
npm run setup
npm run dev
npm run test:e2e

Run all tests in Playwright and notice the Failed to load resource: the server responded with a status of 504 (Outdated Optimize Dep) error on almost every test. You can also quickly navigate pages to the same effect. Notice running the tests twice (or reloading the page) makes the issue go away.
 I'm not sure whether there's a way around this. I welcome any tips!

Adding all dependencies to optimizeDeps.include pre-bundles everything and the tests pass on first run and I don't see any perceivable delay in startup time.
But I'm not sure keeping track and adding dependencies manually to the array is something we want 🤔

Taking a second look at this.
Matching everything with:
optimizeDeps: {
	include: ['.*']
}

works, but might not address the real issue.
Trying to figure this out in bite-sized pieces.
This is what happens when Vite reloads:

Maybe there's a way to have Vite not respond with a 504 Gateway Timeout.

Actually './*' did not work.
But this did:
optimizeDeps: {
	include: [
		'@conform-to/react',
		'@conform-to/zod',
		'@epic-web/invariant',
		'@epic-web/client-hints',
		'@epic-web/client-hints/color-scheme',
		'@epic-web/client-hints/time-zone',
		'@epic-web/remember',
		'@epic-web/cachified',
		'@epic-web/totp',
		'@eslint/*',
		'@nasa-gcn/*',
		'@paralleldrive/cuid2',
		'@prisma/client',
		'@radix-ui/react-visually-hidden',
		'@radix-ui/react-slot',
		'@radix-ui/react-dropdown-menu',
		'@radix-ui/react-dialog',
		'@radix-ui/react-tooltip',
		'@radix-ui/react-checkbox',
		'@radix-ui/react-label',
		'@radix-ui/react-accordion',
		'@radix-ui/react-tabs',
		'@react-email/components',
		'@remix-run/node',
		'@sentry/remix',
		'@tanstack/*',
		'address',
		'bcryptjs',
		'better-sqlite3',
		'chalk',
		'class-variance-authority',
		'close-with-grace',
		'clsx',
		'cmdk',
		'compression',
		'cookie',
		'cross-env',
		'crypto-js',
		'date-fns',
		'dotenv',
		'embla-carousel-react',
		'execa',
		'express',
		'express-rate-limit',
		'get-port',
		'glob',
		'helmet',
		'input-otp',
		'intl-parse-accept-language',
		'isbot',
		'litefs-js',
		'litefs-js/remix.js',
		'lru-cache',
		'morgan',
		'next-themes',
		'prisma',
		'qrcode',
		'react',
		'react-day-picker',
		'react-dom',
		'react-hook-form',
		'react-resizable-panels',
		'remix-auth',
		'remix-auth-github',
		'remix-utils/honeypot/server',
		'remix-utils/honeypot/react',
		'remix-utils/safe-redirect',
		'remix-utils/client-only',
		'remix-utils/server-only',
		'set-cookie-parser',
		'sonner',
		'source-map-support',
		'spin-delay',
		'tailwind-merge',
		'tailwindcss',
		'tailwindcss-animate',
		'tailwindcss-radix',
		'vaul',
		'zod',
	],
},


Explorer item selector ends up choosing System if it can't find item

The extraction pipeline selection in view keeps getting set to System when you change other items and save as it can't find a the dynamic tagged item.

Working in 7.3


application 'app-one' died in status LOADING_SOURCE_CODE: systemjs-webpack-interop: rootDirectoryLevel (2) is greater than the number of directories (1) in the URL path http://localhost:8080/app.js

Data dump
Applications:
{
  "framework": "vue",
  "name": "app-one",
  "pathPrefix": "/",
  "sharedDeps": [],
  "useNativeModules": false,
  "url": "http://localhost:8080/app.js"
}

Import map:
{
  "imports": {
    "app-one": "http://localhost:8080/app.js"
  },
  "scopes": {}
}

Description
Hi,
I'm trying a POC with single-spa with vue2+typescript.
I've followed the instructions here: https://itnext.io/setup-a-micro-frontend-architecture-with-vue-and-single-spa-2c89528bf72f, and I'm getting the following error:
"application 'app-one' died in status LOADING_SOURCE_CODE: systemjs-webpack-interop: rootDirectoryLevel (2) is greater than the number of directories (1) in the URL path http://localhost:8080/app.js"
Appreciate any direction \ idea for why I'm getting this error.
Thanks

Hi @AharonKre, the error message you're seeing is caused by some things in the vue.config.js in the blog post you shared:
https://gist.github.com/mstrlaw/09e20406cb54bcd116ba8e9dc4c742f7#file-vue-config-js-L17
A couple weeks ago we released<EMAIL_ADDRESS>which changed a couple things and made that code not work. One way to fix your code would be to delete line 17 of the vue config (the one that sets output.filename) and then use http://localhost:8080/js/app.js as the URL to your microfrontend.
A simpler and more supported approach, though, would be just to use the single-spa CLI which will set you up with a functioning project in one command. To use the cli, run the following:
npm init single-spa

# if using yarn
yarn create single-spa

Thanks!!


Bot is no longer working?

I have been utilizing this bot previously, however this past couple days the bot stopped working at all. No response to commands, i tried to restart the bot, clear chat and no success...

I've noticed the same thing. I just deleted & stopped my chat with the bot & tried to restart it, but it's still not responding.

@pyatyispyatil Hello! Could you help us please🥺?

Anyone who wants can use my working instance of this bot: https://t.me/github_releases_notifier_robot

Anyone who wants can use my working instance of this bot: https://t.me/github_releases_notifier_robot

Thanx dude!

Anyone who wants can use my working instance of this bot: https://t.me/github_releases_notifier_robot

Thanks but it still not show any description or any link

Thanks but it still not show any description or any link

I didn't change anything in the bot's source code, I just ran the latest version of the code from the master branch of this repository. Since the original bot is not running, running my own instance was the only way to continue to follow the releases of the repositories I needed. I shared a link to my copy with you so that others can use this useful bot as usual.
If you want to fix existing bot issues, please ask the original developer of the bot. :) As soon as the developer makes new changes to the source code, I will immediately apply them to my bot instance.


pull request for e2e test at 12/31/2016 16:15:08

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Allow for skipping of db operations during installation

The installation of the db will only not happen if the value of M2SETUP_INSTALL_DB is set to false.  This is for backwards compat.

:+1:


haskellPackages.sym: disable tests

Description of changes
It builds fine but the hackage source is somehow missing tests/ListStats.hs. Project untouched in 6 years, I don't feel like bothering the author.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Seems reasonable, thanks!


ChatHuggingFace + HuggingFaceEndpoint does not properly implement max_new_tokens

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
from transformers import AutoTokenizer
from langchain_huggingface import ChatHuggingFace
from langchain_huggingface import HuggingFaceEndpoint

import requests

sample = requests.get(
    "https://raw.githubusercontent.com/huggingface/blog/main/langchain.md"
).text

tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-70B-Instruct")

def n_tokens(text):
    return len(tokenizer(text)["input_ids"])

print(f"The number of tokens in the sample is {n_tokens(sample)}")

llm_10 = HuggingFaceEndpoint(
    repo_id="meta-llama/Meta-Llama-3-70B-Instruct",
    max_new_tokens=10,
    cache=False,
    seed=123,
)
llm_4096 = HuggingFaceEndpoint(
    repo_id="meta-llama/Meta-Llama-3-70B-Instruct",
    max_new_tokens=4096,
    cache=False,
    seed=123,
)

messages = [
    (
        "system",
        "You are a smart AI that has to describe a given text in to at least 1000 characters.",
    ),
    ("user", f"Summarize the following text:\n\n{sample}\n"),
]

# native endpoint
response_10_native = llm_10.invoke(messages)
print(f"Native response 10: {n_tokens(response_10_native)} tokens")
response_4096_native = llm_4096.invoke(messages)
print(f"Native response 4096: {n_tokens(response_4096_native)} tokens")

# make sure the native responses are different lengths
assert len(response_10_native) < len(
    response_4096_native
), f"Native response 10 should be shorter than native response 4096, 10 `max_new_tokens`: {n_tokens(response_10_native)}, 4096 `max_new_tokens`: {n_tokens(response_4096_native)}"

# chat implementation from langchain_huggingface
chat_model_10 = ChatHuggingFace(llm=llm_10)
chat_model_4096 = ChatHuggingFace(llm=llm_4096)

# chat implementation for 10 tokens
response_10 = chat_model_10.invoke(messages)
print(f"Response 10: {n_tokens(response_10.content)} tokens")
actual_response_tokens_10 = response_10.response_metadata.get(
    "token_usage"
).completion_tokens

print(
    f"Actual response 10: {actual_response_tokens_10} tokens (always 100 for some reason!)"
)

# chat implementation for 4096 tokens
response_4096 = chat_model_4096.invoke(messages)
print(f"Response 4096: {n_tokens(response_4096.content)} tokens")
actual_response_tokens_4096 = response_4096.response_metadata.get(
    "token_usage"
).completion_tokens

print(
    f"Actual response 4096: {actual_response_tokens_4096} tokens (always 100 for some reason!)"
)

# assert that the responses are different lengths, which fails because the token usage is always 100
print("-" * 20)
print(f"Output for 10 tokens: {response_10.content}")
print("-" * 20)
print(f"Output for 4096 tokens: {response_4096.content}")
print("-" * 20)
assert len(response_10.content) < len(
    response_4096.content
), f"Response 10 should be shorter than response 4096, 10 `max_new_tokens`: {n_tokens(response_10.content)}, 4096 `max_new_tokens`: {n_tokens(response_4096.content)}"

This is the output from the script:
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
The number of tokens in the sample is 1809
Native response 10: 11 tokens
Native response 4096: 445 tokens
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
Special tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.
Response 10: 101 tokens
Actual response 10: 100 tokens (always 100 for some reason!)
Response 4096: 101 tokens
Actual response 4096: 100 tokens (always 100 for some reason!)

--------------------
Output for 10 tokens: The text announces the launch of a new partner package called `langchain_huggingface` in LangChain, jointly maintained by Hugging Face and LangChain. This package aims to bring the power of Hugging Face's latest developments into LangChain and keep it up-to-date. The package was created by the community, and by becoming a partner package, the time it takes to bring new features from Hugging Face's ecosystem to LangChain's users will be reduced.

The package integrates seamlessly with Lang
--------------------
Output for 4096 tokens: The text announces the launch of a new partner package called `langchain_huggingface` in LangChain, jointly maintained by Hugging Face and LangChain. This package aims to bring the power of Hugging Face's latest developments into LangChain and keep it up-to-date. The package was created by the community, and by becoming a partner package, the time it takes to bring new features from Hugging Face's ecosystem to LangChain's users will be reduced.

The package integrates seamlessly with Lang
--------------------

Error Message and Stack Trace (if applicable)
AssertionError: Response 10 should be shorter than response 4096, 10 max_new_tokens: 101, 4096 max_new_tokens: 101
Description
There seems to be an issues when using langchain_huggingface.llms.huggingface_endpoint.HuggingFaceEndpoint together with the langchain_huggingface.chat_models.huggingface.ChatHuggingFace implementation.
When just using the HuggingFaceEndpoint, the parameter max_new_tokens is properly implemented, while this does not work properly when wrapping inside ChatHuggingFace(llm=...). The latter implementation always returns a response of 100 tokens, and I am unable to get this to work properly after searching the docs + source code.
I have created a reproducible example using meta-llama/Meta-Llama-3-70B-Instruct (as this model is also supported for serverless).
System Info
System Information

OS:  Darwin
OS Version:  Darwin Kernel Version 23.5.0: Wed May  1 20:19:05 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8112
Python Version:  3.12.3 (main, Apr  9 2024, 08:09:14) [Clang 15.0.0 (clang-15<IP_ADDRESS>)]

Package Information

langchain_core: 0.2.10
langchain: 0.2.6
langchain_community: 0.2.5
langsmith: 0.1.82
langchain_anthropic: 0.1.15
langchain_aws: 0.1.7
langchain_huggingface: 0.0.3
langchain_openai: 0.1.9
langchain_text_splitters: 0.2.2
langchainhub: 0.1.20

Packages not installed (Not Necessarily a Problem)
The following packages were not found:

langgraph
langserve

Okay, you are comparing two different things. The Huggingface Inference Client returns the following object, which has an attribute of usage that is of type ChatCompletionOutputUsage.
The ChatCompletionOutputUsage has three types of token usage:

completion_tokens: This is the number of tokens required to complete the prompt. In your case, this is always fixed because you are calling the same prompt to complete. Try something else, and it should change.
prompt_tokens: The number of tokens in the prompt.
total_tokens: The sum of completion_tokens and prompt_tokens.

So, you are implicitly comparing the total_tokens through the n_tokens function with completion_tokens, which is incorrect. You should compare the total_tokens attribute to make the correct comparison.
P.S. I double-checked the LangChain code and ensured that ChatHuggingFace is returning the correct ChatCompletionOutputUsage without any modification.

I think you are misunderstanding the example code, the n_tokens() function is called on the output of the chain contents, thus the completion_tokens == n_tokens(output) - 1. The -1 one is the special end of sequence token (this is why the output says 101 tokens, not 100). The problem is that the ChatCompletionOutputUsage.output_tokens should always be less or equal to max_new_tokens, but this is 100 tokens regardless of the supplied max_new_tokens.

I'm having the same problem... Did you find a solution?

I'm having the same problem... Did you find a solution?

No I have not, this issue renders the entire Huggingface x Langchain implementation obsolete to me. I have been attempting to work around the issue using an OpenAI compatible web server through either LlamaCpp/Ollama.

I think this is a ChatHuggingFace bug.
You have to call bind on the chat object with the parameters you want changed before running invoke. They do not carry over from the HuggingFaceEndpoint object to the ChatHuggingFace object.
output_msg = chat_model.bind(max_tokens=8192, temperature=0.0).invoke(chat_sequence)

I'm also having the same problem, and the solution from @michael-newsrx doesn't work for me since the llm is invoked in create_history_aware_retriever and create_retrieval_chain to keep chat history and do RAG.
It works fine using HuggingFaceEndpoint as llm only, but if I pass the HuggingFaceEndpoint object to ChatHuggingFace as an llm argument, the response cuts off the output message. And I need ChatHuggingFace to keep track of chat conversations. Increasing max_new_tokens or using max_tokens as model_args parameter doesn't help.
Do we have an estimated timeline for when this bug will be fixed?
CC: @baskaryan , @hwchase17 , @efriis , @eyurtsev @ccurme , @nfcampos

I think this is a ChatHuggingFace bug.
You have to call bind on the chat object with the parameters you want changed before running invoke. They do not carry over from the HuggingFaceEndpoint object to the ChatHuggingFace object.
output_msg = chat_model.bind(max_tokens=8192, temperature=0.0).invoke(chat_sequence)

Appreciate the workaround!


[DO NOT MERGE] Move content to be served from /world

This commit moves all routes for worldwide content from /government/world to /world and sets up redirects.
Trello: https://trello.com/c/ig418ukz/186-move-worldwide-content-from-government-world-to-world

This looks good (test failures notwithstanding obvs :) )

Looks good to me 👍


Handle not showing with net 8.0.100-rc.2.23502.2

HasHandle property not working with .net 8.0.100-rc.2.23502.2.
#Steps to reproduce

Create a new .net maui project with .net 8.0.100-rc.2.23502.2.
Add a page and add BottomSheet to OnAppearing with HasHandle property true.
Run the app and, handle not showing up.
Please see the image for more details

#Update
still can't make to work with .net 7 also.
I clone the sample repo and working fine.
but even I cloned the @jfversluis repo in his youtube channel and run, still the handle is missing.
I'm using Visual studio 22 v17.7.5.
MauiApp1 - BottomSheet Test.zip
Please see the attached zipped project for more details.

Please make sure you follow the README instruction, more specifically the section about the Android theme.
Duplicate of #54


[BUG] Drive curves too punchy

Describe the bug
Drive Curves too Punchy: I would like a way for it the curve to be less punchy. So like less sensitive/slower at lower amounts of input and and faster at higher amount of inputs. Can we reduce acceleration (not speed, but speed up?) @slyafwalrus

Fixed in #19


Enduring Spell not giving 24 hrs to CL1 mage armor potion

Thanks for the mod, love it.
I have come across a recent problem, and wonder if this is just me.
For some reason the mythic ability Enduring Spells is not giving a Lvl 1 potion of mage armor 24 hrs. Drinking it whilst paused, it starts at 59 mins 59 seconds.
Toybox is the only mod running.
Need to restart the game without toybox to restate 24 hrs effect.
Steps to reproduce the behavior:

Start a new game, create a new character, normal difficulty is fine
After game starts, add a mythic level via toybox.
Level up Mythic level, choose Close to Heaven, pick Enduring Spells as mythic ability
Use toybox to add a Potion of Mage Armor
Pause the game, open inventory, drink the potion.

Expected behavior
Enduring spell should give 24 hr duration to Mage Armor. Instead it is showing 59mins 59secs.
Save Files
Manual_134_Test__enduring_spell_issue__mage_armor.zip
Version Info:

ToyBox Version: ToyBox for WotR Mod-8-1-4-9--1-1636529045
OS: Win 10
Game Version 1.1.1k

If you read the description, it extends the duration of effects that last longer than an hour.
 If you drink a potion, you are not casting the spell. The potion creator did that and you are just becoming the subject of the spell by drinking it.
In the tabletop, the potion brewer can technically modify the spell stored within the potion using their own metamagic feats (like Extend Spell, though Pathfinder's version of Persistent Spell (which this game's Mythic ability emulates) does something entirely different compared to what it used to do in D&D 3.5). But for starters, that would only apply here if you were the one brewing the potion and you set it to caster level 2 or higher (so that it lasted longer than an hour).
For seconds, this video game doesn't really have any item creation mechanics implemented. Being able to brew potions and scribe scrolls is a complete and absolute waste of time that only exists because it gives caster the illusion of having cool treasure to hunt for since all the non-casters get showered with weapon and armor choices (there's literally only like three robes in the entire game... and they are each hideous. And one of them literally just gives you +1 on saves against Fear... It's... it's a problem. But outside the scope here). The crafting interface / code is flat-out not sophisticated enough to allow anything approaching the application of metamagic effects (or mythic ones) to item creation, and that's far outside the scope of ToyBox. You need to wait for another modder to port over the Kingmaker UnityModMenu version of tabletop-accurate item creation, which will be a separate mod not part of ToyBox.


file.lastModifiedDate is deprecated

We are currently using file.lastModified, but I cant find documentation related to this property. This fileModifed is also a little wonky when trying to compare equality.
We should remove it for the next version

Fixed in f8b6dff


Use title case in template section headers

I'm tagging with the docs team, as this question seems closest to their purview (and they're likeliest to have opinions based on the rest of the ecosystem). cc @rust-lang/docs

I'm not sure to see the usefulness of such a change...

I think that typographic considerations like this are mainly tied to what variant of English we consider using as the "default". And remember that "titles" (like titles of CD's or something) are a different thing from "headlines". I think it's customary to use title casing with headlines in AmE, but sentence casing in BrE.

For what it's worth, I think that using sentence casing is easier for read, but that might be just the effect of my native language, where we don't use title casing at all.

Yes.  I know one never does this in French, not even in titles of films, books, etc., although newspapers can capitalize their own name, ala Le Monde.  I believe Spanish and Italian are similarly opposed too title case, albeit less stringently perhaps.
In English, I think house style determines casing, but normally section headings like these are sentence case.  And wikipedia opposes title case even in English.
I'd always argue against title case, even in titles, because less title case in the world saves humans effort, as sentence case contains more information by identifying proper nouns, meaning you can automatically convert from sentence case to title case rule sets, but not conversely.

So, talked about this at the docs meeting. Since this was just opened, "FCP" is a little... wrong, but just to record things:

[x] @GuillaumeGomez : 👎
[x] @steveklabnik: 👎
[x] @frewsxcv: 👎
[ ] @peschkaj: (out for a few weeks, not likely to vote)
[ ] @jonathandturner : (out for a few weeks, not likely to vote)
[ ] @kmcallister: (not officially on the team yet but want to include)

Unless everyone else really wants this change, and it seems it's controversial at best, I doubt we'll be accepting this.

@burdges's argument is especially compelling to me.


Uncatchable error

When i try lots of connections, sometimes appears this error:
error: CRAWLER Error Error: ESOCKETTIMEDOUT when fetching http://adomain.com/post/3427
How can I catch it? None of my try/catch seems to catch this error

Crawler will retry for you when retry times less than your configuration, after that an error will appear as the first argument of callback function, which means you have to handle the error by yourself, but not before that.

I have this same issue, some errors are not catchable -- SSL errors for example print an error before the callback and aren't passed.

I submitted a pull request which addresses this issue - https://github.com/bda-research/node-crawler/pull/368


Background
Trying to recover funds I lost back in January.   Rebuilt the Pi and recovered wallet from seed - All ok.
Tried reindexing - Nothing returned.
Followed advice to add btc to an empty wallet, create channel to a peer who I'd previously been connected to.  Still nothing.  Reboot and open wallet with longer reindex window.  Still nothing.
Connected to another Peer and Channel.  Still nothing.
Decided to remove funds...channels failed.  Luckily nothing great lost there.
Had a copy of the January funded wallet so stopped LND, deleted the previous wallet.db and replaced.
Restarted LND with long index_window, found funds (took 2 days)
But LND will not stay up long enough to send funds off-chain.
Your environment

version of lnd - Version: 0.5.1-beta
which operating system (uname -a on *Nix) - Linux BigAlsLNnode2 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
version of btcd, bitcoind, or other backend - 0.17.1 (I think) - V1.0 of Raspiblitz
any other relevant environment details

Steps to reproduce
Having fun and games here as LND won't stay up after trying to recover a corrupt HDD and lost funds.  Have rebuilt and perform a reindex to 250000 and found the majority of channels.  I think one connection has got seriously corrupted as it keeps sending LND to Shutdown.
Expected behaviour
Tell us what should happen
Actual behaviour
2019-03-01 18:31:06.893 [INF] LNWL: Opened wallet
2019-03-01 18:31:07.360 [INF] LTND: Primary chain is set to: bitcoin
2019-03-01 18:31:07.394 [INF] LNWL: Started listening for bitcoind block notifications via ZMQ on tcp://:28332
2019-03-01 18:31:07.394 [INF] LNWL: Started listening for bitcoind transaction notifications via ZMQ on tcp://:28333
2019-03-01 18:31:07.394 [INF] LTND: Initializing bitcoind backed fee estimator
2019-03-01 18:31:07.400 [DBG] LNWL: Using minimum fee rate of 253 sat/kw
2019-03-01 18:31:13.787 [INF] LNWL: The wallet has been unlocked without a time limit
2019-03-01 18:31:13.795 [INF] LTND: LightningWallet opened
2019-03-01 18:31:13.795 [DBG] LNWL: Birthday block has already been verified: height=544239, hash=0000000000000000000872a1504b98fc2e5d2f9ccf68e8374b87586594273b09
2019-03-01 18:31:13.876 [INF] HSWC: Restoring in-memory circuit state from disk
2019-03-01 18:31:13.910 [INF] HSWC: Payment circuits loaded: num_pending=0, num_open=0
2019-03-01 18:31:13.930 [INF] HSWC: Trimming open circuits for chan_id=564491:2199:1, start_htlc_id=0
2019-03-01 18:31:13.988 [INF] RPCS: RPC server listening on [::]:10009
2019-03-01 18:31:13.989 [INF] RPCS: gRPC proxy started at [::]:8080
2019-03-01 18:31:13.994 [INF] LTND: Waiting for chain backend to finish sync, start_height=565230
2019-03-01 18:31:14.542 [INF] LNWL: Started rescan from block<PHONE_NUMBER>000000002734b1d2de968c7631e80be32496215e45efc331e55698 (height 565227) for 285 addresses
2019-03-01 18:31:14.555 [INF] LNWL: Starting rescan from block<PHONE_NUMBER>000000002734b1d2de968c7631e80be32496215e45efc331e55698
2019-03-01 18:31:15.414 [DBG] LNWL: Filtering block 565228<PHONE_NUMBER>000000001ddd2d765979d0355620bcb14cf10a4c0881ef38a4b37e) with 3061 transactions
2019-03-01 18:31:17.464 [DBG] LNWL: Filtering block 565229<PHONE_NUMBER>000000002a84c8fe413306020dc90c17dabd44ce3c216485a921f4) with 2720 transactions
2019-03-01 18:31:19.120 [DBG] LNWL: Filtering block 565230<PHONE_NUMBER>000000002d43ea099d82e07992297b32f935c29a4b16025f610452) with 1351 transactions
2019-03-01 18:31:19.760 [INF] LNWL: Rescan finished at 565227<PHONE_NUMBER>000000002734b1d2de968c7631e80be32496215e45efc331e55698)
2019-03-01 18:31:19.800 [INF] LNWL: Catching up block hashes to height 565227, this might take a while
2019-03-01 18:31:19.822 [INF] LNWL: Done catching up block hashes
2019-03-01 18:31:19.822 [INF] LNWL: Finished rescan for 285 addresses (synced to block<PHONE_NUMBER>000000002734b1d2de968c7631e80be32496215e45efc331e55698, height 565227)
2019-03-01 18:31:20.805 [INF] LTND: Chain backend is fully synced (end_height=565230)!
2019-03-01 18:31:20.873 [INF] HSWC: Starting HTLC Switch
2019-03-01 18:31:20.873 [INF] NTFN: New block epoch subscription
2019-03-01 18:31:20.873 [INF] NTFN: New block epoch subscription
2019-03-01 18:31:20.944 [INF] NTFN: New block epoch subscription
2019-03-01 18:31:20.950 [INF] UTXN: Processing outputs from missed blocks. Starting with blockHeight=565227, to current blockHeight=565230
2019-03-01 18:31:20.951 [DBG] UTXN: Attempting to graduate outputs at height=565228
2019-03-01 18:31:20.951 [INF] UTXN: Attempting to graduate height=565228: num_kids=0, num_babies=0
2019-03-01 18:31:21.010 [DBG] UTXN: Attempting to graduate outputs at height=565229
2019-03-01 18:31:21.010 [INF] UTXN: Attempting to graduate height=565229: num_kids=0, num_babies=0
2019-03-01 18:31:21.077 [DBG] UTXN: Attempting to graduate outputs at height=565230
2019-03-01 18:31:21.077 [INF] UTXN: Attempting to graduate height=565230: num_kids=0, num_babies=0
2019-03-01 18:31:21.132 [INF] UTXN: UTXO Nursery is now fully synced
2019-03-01 18:31:21.237 [INF] CNCT: Creating ChannelArbitrators for 2 active channels
2019-03-01 18:31:21.237 [DBG] CNCT: New ChainEventSubscription(id=0) for ChannelPoint(337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1)
2019-03-01 18:31:21.237 [DBG] CNCT: New ChainEventSubscription(id=0) for ChannelPoint(c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1)
2019-03-01 18:31:21.238 [INF] NTFN: New block epoch subscription
2019-03-01 18:31:21.238 [INF] NTFN: New block epoch subscription
2019-03-01 18:31:21.238 [DBG] CNCT: Starting chain watcher for ChannelPoint(337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1)
2019-03-01 18:31:21.238 [DBG] NTFN: Using height hint 564491 retrieved from cache for 337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1
2019-03-01 18:31:21.239 [INF] NTFN: New spend subscription: spend_id=1, outpoint=337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1, height_hint=564491
2019-03-01 18:31:21.238 [DBG] CNCT: Starting chain watcher for ChannelPoint(c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1)
2019-03-01 18:31:21.240 [DBG] NTFN: Using height hint 564628 retrieved from cache for c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1
2019-03-01 18:31:21.240 [INF] NTFN: New spend subscription: spend_id=2, outpoint=c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1, height_hint=564628
2019-03-01 18:31:21.277 [INF] CNCT: Close observer for ChannelPoint(337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1) active
2019-03-01 18:31:21.310 [INF] CNCT: Close observer for ChannelPoint(c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1) active
2019-03-01 18:31:21.310 [DBG] CNCT: Starting ChannelArbitrator(337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1), htlc_set=(contractcourt.htlcSet) {
incomingHTLCs: (map[uint64]channeldb.HTLC) {
},
outgoingHTLCs: (map[uint64]channeldb.HTLC) {
}
}
2019-03-01 18:31:21.310 [INF] CNCT: ChannelArbitrator(337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1): starting state=StateDefault
2019-03-01 18:31:21.315 [DBG] CNCT: ChannelArbitrator(337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1): new block (height=565230) examining active HTLC's
2019-03-01 18:31:21.315 [DBG] CNCT: ChannelArbitrator(337060d93b2d6f6d6fc28152b16f8d62b6ea3aaf80d36fa7b6ca07f3540e91a5:1): checking chain actions at height=565230
2019-03-01 18:31:21.315 [DBG] CNCT: Starting ChannelArbitrator(c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1), htlc_set=(contractcourt.htlcSet) {
incomingHTLCs: (map[uint64]channeldb.HTLC) {
},
outgoingHTLCs: (map[uint64]channeldb.HTLC) {
}
}
2019-03-01 18:31:21.316 [INF] CNCT: ChannelArbitrator(c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1): starting state=StateDefault
2019-03-01 18:31:21.321 [DBG] CNCT: ChannelArbitrator(c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1): new block (height=565230) examining active HTLC's
2019-03-01 18:31:21.321 [DBG] CNCT: ChannelArbitrator(c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67:1): checking chain actions at height=565230
2019-03-01 18:31:21.322 [INF] DISC: Authenticated Gossiper is starting
2019-03-01 18:31:21.322 [INF] BRAR: Starting contract observer, watching for breaches.
2019-03-01 18:31:21.322 [INF] NTFN: New block epoch subscription
2019-03-01 18:31:21.327 [INF] CRTR: FilteredChainView starting
2019-03-01 18:31:21.329 [ERR] DISC: Unable to rebroadcast stale channels: unable to retrieve outgoing channels: Channel from self node has no policy
2019-03-01 18:31:22.323 [INF] CRTR: Filtering chain using 21917 channels active
2019-03-01 18:31:22.332 [INF] CRTR: Prune tip for Channel Graph: height=565227, hash=0000000000000000002734b1d2de968c7631e80be32496215e45efc331e55698
2019-03-01 18:31:22.337 [INF] CRTR: Syncing channel graph from height=565227 (hash=0000000000000000002734b1d2de968c7631e80be32496215e45efc331e55698) to height=565230 (hash=0000000000000000002d43ea099d82e07992297b32f935c29a4b16025f610452)
2019-03-01 18:31:23.321 [INF] CRTR: Block<PHONE_NUMBER>000000001ddd2d765979d0355620bcb14cf10a4c0881ef38a4b37e (height=565228) closed 0 channels
2019-03-01 18:31:24.466 [INF] CRTR: Block<PHONE_NUMBER>000000002a84c8fe413306020dc90c17dabd44ce3c216485a921f4 (height=565229) closed 1 channels
2019-03-01 18:31:25.510 [INF] CRTR: Block<PHONE_NUMBER>000000002d43ea099d82e07992297b32f935c29a4b16025f610452 (height=565230) closed 2 channels
2019-03-01 18:31:25.512 [INF] CRTR: Graph pruning complete: 3 channels were closed since height 565227
2019-03-01 18:31:25.621 [DBG] LNWL: Marked address bc1qtm9rkcrn2pq9vt2lptysgsjq46vylrahe82ak0 used
2019-03-01 18:31:25.673 [INF] NTFN: New block epoch subscription
2019-03-01 18:31:25.673 [INF] NTFN: New confirmation subscription: txid=c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67, numconfs=3
2019-03-01 18:31:25.674 [DBG] NTFN: Using height hint 564629 retrieved from cache for c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67
2019-03-01 18:31:25.674 [DBG] NTFN: Dispatching historical rescan for txid=c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67
2019-03-01 18:31:25.674 [INF] FNDG: Waiting for funding tx (c6d3a3d11ec92a0414aaea4cdd7ad67760ffe459eed7d9b2c4968b2f49ea9c67) to reach 3 confirmations
2019-03-01 18:31:25.733 [INF] CMGR: Server listening on [::]:9735
2019-03-01 18:31:25.734 [INF] SRVR: New inbound connection from <IP_ADDRESS>:58596
2019-03-01 18:31:25.734 [INF] SRVR: Finalizing connection to 030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f, inbound=true
2019-03-01 18:31:25.734 [DBG] PEER: Sending Init to <IP_ADDRESS>:58596
2019-03-01 18:31:25.735 [DBG] PEER: Received Init from <IP_ADDRESS>:58596
2019-03-01 18:31:25.735 [INF] SRVR: Pruning peer 030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f from persistent connections, number of open channels is now zero
2019-03-01 18:31:25.735 [DBG] PEER: Loaded 0 active channels from database with NodeKey(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f)
2019-03-01 18:31:25.735 [INF] SRVR: Negotiated chan series queries with 030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f
2019-03-01 18:31:25.735 [INF] DISC: Creating new gossipSyncer for peer=030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f
2019-03-01 18:31:25.736 [DBG] DISC: Starting gossipSyncer(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f)
2019-03-01 18:31:25.736 [DBG] DISC: gossipSyncer(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f): state=syncingChans
2019-03-01 18:31:25.737 [INF] DISC: gossipSyncer(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f): requesting new chans from height=564479 and<PHONE_NUMBER> blocks after
2019-03-01 18:31:25.738 [DBG] DISC: gossipSyncer(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f): state=waitingQueryRangeReply
2019-03-01 18:31:25.739 [DBG] PEER: Sending QueryChannelRange(chain_hash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, start_height=564479, num_blocks=4294402816) to <IP_ADDRESS>:58596
2019-03-01 18:31:25.769 [DBG] PEER: Received ChannelReestablish(next_local_height=166, remote_tail_height=165) from <IP_ADDRESS>:58596
2019-03-01 18:31:25.769 [DBG] PEER: Unable to find link(22bb5d26962a03ad2842f13d53ce304b11820707d20ce80a8149be7dc3858da0) to handle channel sync, attempting to resend last ChanSync message
2019-03-01 18:31:25.769 [DBG] PEER: Received QueryChannelRange(chain_hash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, start_height=565081, num_blocks=4294402214) from <IP_ADDRESS>:58596
2019-03-01 18:31:25.770 [ERR] PEER: resend failed: unable to fetch channel sync messages for peer <IP_ADDRESS>:58596: unable to find closed channel summary
2019-03-01 18:31:25.770 [INF] DISC: gossipSyncer(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f): filtering chan range: start_height=565081, num_blocks=4294402214
2019-03-01 18:31:25.770 [INF] DISC: gossipSyncer(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f): sending final chan range chunk, size=0
2019-03-01 18:31:25.770 [DBG] DISC: gossipSyncer(030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7ac19b141c14f): state=waitingQueryRangeReply
2019-03-01 18:31:25.770 [DBG] PEER: Sending ReplyChannelRange(complete=1, encoding=0, num_chans=0) to <IP_ADDRESS>:58596
2019-03-01 18:31:25.792 [INF] LTND: Shutdown complete2019-03-01 18:32:26.098 [INF] LTND: Version: 0.5.1-beta commit=, build=production, logging=default
2019-03-01 18:32:26.099 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-03-01 18:32:26.100 [INF] CHDB: Checking for schema update: latest_version=7, db_version=7
2019-03-01 18:32:26.105 [INF] RPCS: password gRPC proxy started at [::]:8080
2019-03-01 18:32:26.105 [INF] RPCS: password RPC server listening on [::]:10009
2019-03-01 18:32:26.105 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create a wallet, lncli unlock to unlock an existing wallet, or lncli changepassword to change the password of an existing wallet and unlock it.

This issue can be closed as I have rebuilt with latest LND and everything is working as expected.
Thanks.


Refactor the build

The build is now structure in the following way:

build.sbt keeps the project definitions.
BuildPlugin.scala keeps the logic.

This way, at a glance, contributors can see which modules the build defines.
This PR does not change the logic of the build. I'll open a new PR after this
one that will improve the scripted test setup, and add sbt-release-early via
a new version of sbt-houserules.
I hope this change makes the build more readable and easier to hack in the future.

To validate this pull request against other sbt modules, please visit this link.

@dwijnand Feedback addressed. I invited you to have another look. Before merge, I'll fixup the last commits together to make sure everything passes CI.

For some weird reason, GitHub does not show the latest commit and its CI status.

I said you can still do val moduleID = Keys.moduleID.value.

Sure, but then you're inconsistent. You use a wildcard import and then you use the prefix to disambiguate -- it's weird.
Also, this assumes you know what import sbt.Keys._ does import. We know, but most of users don't.

That's Scala for you, nothing to do with sbt per-se. You need to play with scala scopes and/or find other names.

Agreed, nobody said is sbt specific. But it's an important problem.
I'm not the only one that does it this way, see this comment by Li Haoyi: https://contributors.scala-lang.org/t/proposed-syntax-for--root-/1035/37?u=jvican.

I don't think the user cares where a key is defined, and would find it more user-friendly if the same syntax as the shell were used.

Well, I don't know if they care, but I believe they should care because the place where it's defined alters semantics of their code...
@dwijnand PR is updated with your last feedback. Thanks!

Is there anything I can do here to move this forward? I've replied to all your concerns/questions.

Commits have been squashed. It looks like GitHub is not catching up with the parent branch.

I'll rebase this whenever #438 is merged. The changes done by this PR start from https://github.com/sbt/zinc/pull/428/commits/ca17c4a56abb5a28bd887123901ad1bc52d06822.

@eed3si9n @dwijnand This PR has been updated. Can you have a look?

Only bug fixes (or improvements needed for bug fixes) goes into 1.0.x branch, so this PR imo should target 1.x.

@eed3si9n That has not been discussed between you and I at any point, and that does not correspond with other PRs that have been merged into the 1.0.x line.
This PR and the other one have been here for more than 25 days waiting for a review, and hasn't yet been reviewed since our last meeting three weeks ago... I've put so much time into rebasing the PRs and adapting it to other changes, that I'm not willing to do it again.

The 1.x vs 1.0.x convention was discussed here - https://github.com/sbt/sbt-contrib/blob/master/src/main/markdown/2017-08-16.md#general-release-cycle.
If there has been 1.0.x merges that are not for hot fixes, then likely they were mistakes.
As per the prioritization of PRs, the themes around each releases are discussed in sbt 1 meetings, and discussions in last few meetings have been wrapping things up for 1.0.4 and 1.1-RC. It's not uncommon to have PR sit on the queue for a while if they are not critical part of the milestone. For example https://github.com/sbt/sbt/pull/3621 has been sitting since Oct 8 (I think it's ready to merge, but hey).

This is not sbt, this is Zinc, and the Scala Center has proved more than several times its great involvement in this project. To the best of my knowledge, we both have an oral deal to drive the direction of this project, which is important because the Scala community needs our collaboration. That means that whatever it's applicable to sbt/sbt, it's not necessarily applicable here. As you said in numerous occasions, sbt != zinc.
From reading your message, it looks like you're the only one that chooses the priority of the PRs and I'm sorry to tell you but that's not how it works. Your actions have consequences in my work, and that's why it's good to discuss things before taking unilateral actions.
Your wish is also inconsistent, lots of things that are not bug fixes have been merged into the 1.0.x line, sorry.
I don't think I'm asking too much when I say that I want my work to be respected. If it's not reviewed on time and keeps being delayed, it's not my fault. I've been rebasing this thing and I've already given up on lots of design decisions just to make you happy. Same with the bincompat restrictions that you want and I don't.

And for those reading this discussion, here's where our disagreement started: https://github.com/sbt/zinc/pull/453.

You have to understand that we're working on a team, and if you want to make a change at the last minute and override all the work that other team members have put into Zinc, it's not nice. It means I need to stop the world, come here, and update all the stuff just because you think your PR has more priority than mine. And this wouldn't have happened if you had reviewed the PRs in due time (and ironically you ping me several times in less than one week to review your PR because it's blocking a release).
I've done many concessions in the past weeks to accommodate your likes and what not (including your controversial opinions on bincompat), and I see no effort from your side to respect the work and time I am investing in this project, sometimes on my free time.
If you considered this was a change required in 1.x, you should have said that one month ago, and discussed with me this rule (not take the decision unilaterally in some old sbt meeting minutes I didn't attend). Not doing so is wasting my time and our time. You can at least ping me in Gitter to notify me your plan to ship something in 1.x that overrides my changes.
Being in a team means agreeing to make things happen together, not taking unilateral actions and then asking others to catch up with them.
It's also important that you don't assume that the sbt release process is the same. If we're making this thing happen, and improving the incremental compiler for the whole community, then it's only reasonable we take different decisions (because the sbt team is not the only one in charge of this project).
I think support for Scala 2.13.x is important. But I'm only happy to merge your fix to support Scala 2.13.x if you are the one that rebases all my changes in 1.x (keeping git history) once your PR gets merged. As an author of these two PRs, I will obviously address more feedback if I get it, but I refuse to swallow the consequences of your poor management of this issue.
I know you're used to take decisions in sbt/sbt, but I hope you don't realistically hope to dictate how development of Zinc should be when more than one party is involved into it.
And I say this in the nicest of the tones. I'm just being honest and direct.

This is not sbt, this is Zinc, and the Scala Center has proved more than several times its great involvement in this project. To the best of my knowledge, we both have an spoken deal to drive the direction of this project, which is important because the Scala community needs our collaboration. That means that whatever it's applicable to sbt/sbt, it's not necessarily applicable here. As you said in numerous occasions, sbt != zinc and we're not Lightbend.

Agreed. And it's worth repeating that both Lightbend Tooling team and Scala community are grateful for Scala Center's contributions.

From reading your message, it looks like you're the only one that chooses the priority of the PRs and I'm sorry to tell you but that's not how it works. Your actions have consequences in my work, and that's why it's good to discuss things before taking unilateral actions.

I've seen this claim repeated a few times, but I see it in a different way. During the development leading up to sbt 1 we've held multiple planning meetings together to discuss the todo list on what goes into RC-x. After sbt 1.0, there's been sbt 1 meetings every week since August to coordinate what goes in, when, and who wants to work on them. We discuss Zinc task planning here too. So even though Lightbend is the owner of Zinc, and I'm the lead, the governance of sbt or Zinc has been relatively open.

Your wish is also inconsistent, lots of things that are not bug fixes have been merged into the 1.0.x line, sorry.

There's been three hot fix releases of Zinc thus far from 1.0.x branch: 1.0.1, 1.0.2, and 1.0.3.
As far as I know, all of the changes that went into them were for bug fixes that we shipped together with sbt 1.0.x hot fixes. If there has been any other PRs, then it had to be low/zero risk (like adding headers) or a mistake. Could you point to an example?

I don't think I'm asking too much when I say that I want my work to be respected. If it's not reviewed on time and keeps being delayed, it's not my fault. I've been rebasing this thing and I've already given up on lots of design decisions just to make you happy. Same with the bincompat restrictions that you want and I don't.

I don't think it's a matter of respect. If there's an objectively verifiable bug in the code (e.g. using the result of a method that sometimes returns null, causing NPE), I think the review process for a fix would be straightforward since the fix can also be verified. Refactoring starts to involve matters of taste, and it could take a while to converge choices/decisions. Given the 59 comments, it's been given enough attention.
I also understand that PR taking a long time is frustrating, and we should work towards improving that.

You have to understand that we're working on a team, and if you want to make a change at the last minute and override all the work that other team members have put into Zinc, it's not nice. It means I need to stop the world, come here, and update all the stuff just because you think your PR has more priority than mine. And this wouldn't have happened if you had reviewed my PRs in due time (and ironically you ping me several times in less than one week to review your PR because it's blocking a release).

Since there's been multiple conversations on Gitter etc around 1.0.x or sbt 1.0.x hot fixes, I was totally under the impression that you knew of the 1.x and 1.0.x distinction and were on board with the idea.

If the criteria or the process was somehow not clear, I think it was a miscommunication on my part. As I wrote in the previous comment too, "what goes into what release" is one of the things we discuss in the sbt 1 meetings. In other words, it's not decided unilaterally. If you can't attend it personally, you're welcome to send someone else, write in a email, or schedule chat with me afterwards.

I've done many concessions in the past weeks to accommodate your likes and what not (including your controversial opinions on bincompat), and I see no effort from your side to respect the work and time I am investing in this project, sometimes on my free time.

See https://github.com/sbt/zinc/pull/428#issuecomment-346507814. I acknowledge that long PR process can be frustrating, but I don't think it's a matter of respect. The PR was sent in on Oct 12, and within 24h @dwijnand has given lots of feedback. It dropped from our radar for a while when we couldn't bring it to consensus in time. Other PRs during this period were reviewed and merged when it was simple (like related https://github.com/sbt/zinc/pull/438).
Also note that 2 days ago I've asked Dale to come up with a pending list if he thinks there's any work remaining on this PR when you pinged me.

If you considered this was a change required in 1.x, you should have said that one month ago, and discussed with me this rule (not take the decision unilaterally in some old sbt meeting minutes I didn't attend). Not doing so is wasting my time and our time. You can at least ping me in Gitter to notify me your plan to ship something in 1.x that overrides my changes.

You're right that either Dale or I should've spotted that this PR targets 1.0.x branch much sooner. This was an oversight on our part.

Being in a team means agreeing to make things happen together, not taking unilateral actions and then asking others to catch up with them.

Agreed. To be fair though, there were attendees from Scala Center in the initial meeting when we discussed the branching strategy, so from my point of view these decisions were made though discussion not by fiat.

It's also important that you don't assume that the sbt release process is the same. If we're making this thing happen, and improving the incremental compiler for the whole community, then it's only reasonable we take different decisions (because the sbt team is not the only one in charge of this project).

Yes. My goal for Zinc is to be a useful incremental compiler for any build tool, which might take different decisions in terms of incrementality, strictness on repeatability (Bazel / Pants comes to mind here) etc. The strategy sbt uses for its releases is SemVer, and it does carry over to Zinc in many ways, but I am hopeful that we can achieve these goals.

I think support for Scala 2.13.x is important. But I'm only happy to merge your fix to support Scala 2.13.x if you are the one that rebases all my changes in 1.x (keeping git history) once your PR gets merged. As an author of these two PRs, I will obviously address more feedback if I get it, but I refuse to swallow the consequences of your poor management of this issue.

If what's needed to ship Scala 2.13.x is hinging on time to git, both Dale and I are happy to take on the task. After merging 1.0.x into 1.x, hopefully it would be a straight merge.

If what's needed to ship Scala 2.13.x is hinging on time to git, both Dale and I are happy to take on the task. After merging 1.0.x into 1.x, hopefully it would be a straight merge.

See https://github.com/sbt/zinc/pull/456


Carousel Slide Details Update

The changeSlide function attempts to update the slide details (title and subtitle) for all slides, not just the active slide. This can make incorrect titles and subtitles being displayed on inactive slides, causing a poor user experience.
Please assign me this issue @apu52 sir.

Hi @vyanky1227  ,
I am closing this issue, raise a fresh issue using template to raise issue and explain your issue with all required details.
Regards
Project Mentor (GSSoC' 24)


Old Sidebar pan map on open

this is really useful if you want something to fit within the screen available. now it is gone and there is no documentation saying if there's an option to enable this or not.

@LucasFlicky there is no such option at the moment. feel free to implement it on top of the library though.


⚠ T:Riza Community Forum has degraded performance

In c2b2506, T:Riza Community Forum (https://community.triza.dev) experienced degraded performance:

HTTP code: 200
Response time: 3207 ms

Resolved: T:Riza Community Forum performance has improved in b2032ea.


Cannot access Storage Explorer subscription containers - password issue or account issue

This is the error message I received:
{
"message": ""Redirect Uri mismatch.  Expected (/favicon.ico) Actual (/). ""
}

@nfporter, when you do sign in, is it happening in your browser or in a small pop-up window?

Thank you, but this issue has been resolved.
Regards,
Nadene Porter
Data Engineer, Contractor
Mission Data, ASL
Email<EMAIL_ADDRESS>From: Matthew Rayermann @.>
Sent: Monday, March 28, 2022 1:17 PM
To: microsoft/AzureStorageExplorer @.>
Cc: Nadene Porter @.>; Mention @.>
Subject: [External] Re: [microsoft/AzureStorageExplorer] Cannot access Storage Explorer subscription containers - password issue or account issue (Issue #5547)
@nfporterhttps://secure-web.cisco.com/13Zs8613ZTeoztjhZTecnGadPia2qAtQOMDkPNUtlLaQCqKILGMsP92dksy-pk2FhF2lpJoAkZkvsVbJvRVlq3TXUk7VfZjqPEsNX_8_kafxb4iqPvtx6xvYiM2XB7C5lQNklK-gapQAdY72iV4SS2VszBKLgsLIv2xR1cURI7wKAnLzBsq5ztTmXnE0YsqRKQy-9TaRiV_yBOKzd7h6KqbeH6KfKB2XKXlxZMm-D8RgUccaYiKGaOIItA7ALTXNWxIPI5wfJMUpfiMKQRVUMAS0nLHJELhNvMVx3kohfpkgZbXHRYd5iiscFAXm5pOfWSl0_Qw5cfpRvwO4yMeiiBd9CKjJz3C4e2wFjnurvYBUBjt05qoA66XABZf2vS6epCdmTT3n4dVIukVycWsAj5qL7QAKrLf1LvVzWYbjYeEQcCH_cFR4FMIvRaK0oVgmaDhsJjGUh2BmSO9IDEQXzVA/https%3A%2F%2Fgithub.com%2Fnfporter, when you do sign in, is it happening in your browser or in a small pop-up window?
—
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1k05S0nyn0qJ92Ez_UyOH22pL9U2sVvhxc3L9OofydIJ16aR5z7Pe6pOlghgP0z_u1yHbUTeRFnIQ0Bz6YwnK2604Tp131WCKuSGR_19M86N47MGGqWdrt0bJsFzpTx_0O3QprXkdbRKNiPLkZQ5k25ZfNOUmvXaO4l8IS91MmqdDTyTL8M3glyr_SNouhHI0HnB94y0j5XbLQfi_hGwcioBr408Btf7DeDH1v2DEO1IdW7j293yQTMrRNfYOIQejf9fdUpH3k9RYrp_8Y5tGVe9lXU_12-0QRJa4zrq3ShstbThoxjOzmAQZb3BxtitwssbVeVv13xvsQNtMEgBH_1W8rfJTPwdQFpHSyCWaEnRu3yv0tCVSobj4YEX1ECMOzuzkTkTs6Ga8r_8KMJ9iTeC72jglarmGFNZhRDCmdHY8uxcVTtedb60uOFQnbQBXZD460FB3MmpwwxeePJTKQg/https%3A%2F%2Fgithub.com%2Fmicrosoft%2FAzureStorageExplorer%2Fissues%2F5547%23issuecomment-1080931062, or unsubscribehttps://secure-web.cisco.com/1e3i64_26qLyg8LezlWXXMfj21tfCHK43rQZcp7CZYeRJAQcRL_gONscc8x7gAw5vL7cAkLz_K-Bgi_ECbFu5xwljErpctknLN9IUSdB2pwlmv30R3jO0AWpL7YpqjxIsS61mQH8WJeP7RnHycGXba1bPYhOluTFZBkewrzDRJx6ySJ4-a_gPhx1lDVuszGM8OxBWt963Kdxw1SJk_7uBaJFf5Hjq1Ca_PcWGH07AVkALcwK5xz5cVOCpTrH-l_4ZzGIE0JTJW1_JEn37qIh5TeRhvHI3mkTDJzZZxIGZmldHke1TBwNsHRW7NqByBxWzwO0LWrSkfe1fWCT1NUAOaWVIc7wG90NnMAgwUABfe7-hyKi8TrGDs-aYc23iJpoF6E01Ig0b5mfRlybCdpiTiApztnG0lfEoax_bTrkPy67Qu6P8Ma4jG3a4I7PbsPmYnqQfmLmBKc0T33yFlj-KQA/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAYMFSLONSX73HEU5U4RZIRTVCHSRDANCNFSM5RPELNQA.
You are receiving this because you were mentioned.Message ID: @.***>

@nfporter ok sounds good. If you could take the time to leave a comment sharing how you resolved this that'd be great. Thanks.


chore(merge-back): 2.41.0

See CHANGELOG

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: c647fa772e086f37b17e5f83b00c85d5a9559700
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


cob_control: 0.8.11-1 in 'melodic/distribution.yaml' [bloom]

Increasing version of package(s) in repository cob_control to 0.8.11-1:

upstream repository: https://github.com/ipa320/cob_control.git
release repository: https://github.com/ipa320/cob_control-release.git
distro file: melodic/distribution.yaml
bloom version: 0.9.3
previous version for package: 0.8.10-1

cob_base_controller_utils

No changes

cob_base_velocity_smoother

No changes

cob_cartesian_controller

No changes

cob_collision_velocity_filter

No changes

cob_control

No changes

cob_control_mode_adapter

No changes

cob_control_msgs

No changes

cob_footprint_observer

No changes

cob_frame_tracker

No changes

cob_hardware_emulation

No changes

cob_mecanum_controller
* Merge pull request #238 <https://github.com/ipa320/cob_control/issues/238> from fmessmer/melodic/fix_mecanum
  [melodic] fix eigen in mecanum controller
* fix eigen
* Contributors: Felix Messmer, fmessmer

cob_model_identifier

No changes

cob_obstacle_distance

No changes

cob_omni_drive_controller

No changes

cob_trajectory_controller

No changes

cob_tricycle_controller

No changes

cob_twist_controller

No changes

Travis looks like it had problems; closing and re-opening to see if it will re-kick the job.


How to choose a graphql client： Amplify Graph client, or AppSyncClient，or Axios?

Note: If your question is regarding the AWS Amplify Console service, please log it in the
AWS Amplify Console repository

Which Category is your question related to?
graphql, appsync
Amplify CLI Version
7.6.26
What AWS Services are you utilizing?
AppSync
Provide additional details e.g. code snippets. Be sure to remove any sensitive data.
I can see there are 3 ways we can use graphql client. Is there a document for how to use which client in which case?
method1: Amplify Graph client
I can see the example from the document here:  https://docs.amplify.aws/lib/graphqlapi/authz/q/platform/js/#using-amplify-graphql-client
// Creating a post is restricted to IAM
const createdTodo = await API.graphql({
  query: queries.createTodo,
  variables: {input: todoDetails},
  authMode: 'AWS_IAM'
});

I think this is the easiest way to call graphql apis, and I am using this method from my nextjs SSR. But I do have a few question:

Can I also use this amplify graph client in a Amplify Lambda Function?
How can I get and set the API_KEY from AppSync? The document doesn't mention that. Now I am having a Server Error Error: No api-key configured error, when creating a public api (auth with API_KEY and @auth(rules: [{ allow: public }])).

method2: AppSyncClient
I can see the example from: https://docs.amplify.aws/lib/graphqlapi/authz/q/platform/js/#api-key
import AWSAppSyncClient, { AUTH_TYPE } from 'aws-appsync';
import awsconfig from './aws-exports';

const client = new AWSAppSyncClient({
  url: awsconfig.aws_appsync_graphqlEndpoint,
  region: awsconfig.aws_appsync_region,
  auth: {
    type: AUTH_TYPE.API_KEY,
    apiKey: awsconfig.aws_appsync_apiKey,
  },
});

Questions:

I can't get a aws_appsync_apiKey field from <MYPROJECT>/src/aws-exports.js. I don't have that in my local file, which has a  "WARNING: DO NOT EDIT" mark. In the file I do have a aws_appsync_authenticationType key as API_KEY.
Is it more recommended to use AWSAppSyncClient in an amplify function rather than await API.graphql...?

method3: Axios
I see the example here: https://docs.amplify.aws/lib/graphqlapi/graphql-from-nodejs/q/platform/js/#query
const graphqlData = await axios({
  url: process.env.API_<YOUR_API_NAME>_GRAPHQLAPIENDPOINTOUTPUT,
  method: 'post',
  headers: {
    'x-api-key': process.env.API_<YOUR_API_NAME>_GRAPHQLAPIKEYOUTPUT
  },
  data: {
    query: print(listTodos),
  }
});

I know this must be a lower level implementation for a query and I guess this is not recommended...

figured out the missing aws_appsync_apiKey problem: i changed the default authorization type, but didn't run amplify push

Amplify Graph client vs. AppSyncClient vs. Axios, any suggestions?

Hey @nxia416 :wave: apologies for the delay here!! Are you still experiencing this issue? We've recently updated our documentation for calling a GraphQL API from Lambda


Make a revision to support GHC 9.0.1

goldplate builds with cabal build --allow-newer.

[ ] Outdated upper bounds can be relaxed as follows:

     aeson-pretty         >= 0.8  && < 0.9,
     async                >= 2.2  && < 2.3,
     base                 >= 4.9  && < 5,
-    bytestring           >= 0.10 && < 0.11,
+    bytestring           >= 0.10 && < 0.12,
     Diff                 >= 0.3  && < 0.5,
     directory            >= 1.3  && < 1.4,
     filepath             >= 1.4  && < 1.5,
     Glob                 >= 0.10 && < 0.11,
-    optparse-applicative >= 0.14 && < 0.16,
+    optparse-applicative >= 0.14 && < 0.17,
     process              >= 1.6  && < 1.7,
     regex-pcre-builtin   >= <IP_ADDRESS> && < 0.96,
     text                 >= 1.2  && < 1.3,
-    time                 >= 1.8  && < 1.10,
+    time                 >= 1.8  && < 1.12,
     unordered-containers >= 0.2  && < 0.3

[ ] Regular build is currently blocked by https://github.com/audreyt/regex-pcre-builtin/issues/18.

See https://github.com/fugue/goldplate/pull/7.


[Bug] Garbage when run_cell is not identical to mask

VIC 5.1.0.rc1
gcc
Ubuntu
Image driver
Problem description:
-- When I set the run_cell variable in my parameter file to skip some of the cells in the domain (which still have mask == 1) VIC's indexing of the cells gets confused and I encounter a lot of Nans.
Proposed solution:
-- Need to modify vic_init.c and vic_force.c, when reading multi-dimensional slices from netcdf files, to loop over ncells_total instead of ncells_active, and insert a check on the value of locations[i].run when assigning variables from these files to internal 1-d arrays.

@dgergel - haven't you used this functionality? Have you seen similar behavior?

I have used that functionality but I think I've always altered the run_cell variable in the parameter file and the mask variable in the domain file in tandem, so I haven't seen this behavior. When I have altered run_cell and mask I have checked that those grid cells have identical behavior to domain-wide runs, and they do. But I have thought that we should be able to alter run_cell to do limited gridcell runs without having the mask match

I think I can have a fix ready by Friday...

but I understand if you don't want to include it in the release...

Full steam ahead @tbohn! Go ahead and pursue the fix if you can.

Status update: My earlier hypothesis as to the cause of the problem was wrong.  The logic inside get_scatter_nc_field_* appears to correctly account for run_cell via the filter_active_cells array.  This problem MAY be related to the OMP_NUM_THREADS issue and my unorthodox library setup (pointing to anaconda libraries).
However, although setting OMP_NUM_THREADS=1 fixed the earlier problem I had when run_cell was the same as mask, it does not prevent the current problem.
So far, I'm seeing that inside vic_image_run(), the cells are being looped over in a weird order (despite the loop being for (i = 0; i < local_domain.ncells_active; i++) {, the actual i values are not in order, presumably due to OpenMPI?).  It doesn't cause a problem when run_cell == mask.  But when they're not equal, it MIGHT be possible that different data structures are getting indexed in different orders.  I'm working on pinning this down.  If it turns out to be a clear bug in the logic (independent of my OpenMPI setup) then I'll try to fix it.
It could be possible that @dgergel didn't encounter any problems due to her run_cell == 1 for only one cell (ie, no possibility for order to be mixed up, since the set of active cells has no order to mix up).

Update: running on a different machine (still pointing to anaconda libraries) doesn't encounter the out-of-order cell order problem that I was seeing.  In both cases, OMP_NUM_THREADS=1.  So something else was clearly wrong with my first machine.  Tests are running on the new machine to determine whether run_cell works correctly.

At this point, as far as I can tell, run_cell does work correctly.  I have not yet figured out the causes of the errors that I encountered, but they only occur on certain machines and/or for certain parameter files.  For other parameter files on a different machine, setting run_cell to a subset of the mask does work correctly.  So, I think this issue can be closed.


[Bug] Your Bug Report Here Requesting changes to 'Get a Work Item' (get-work-item)

Describe the bug A clear and concise description of what the bug is.
The documentation is wrong for the list of approvaltems attributes.
The fields with name "attributeXxx" are wrong, there is no prefix 'attribute' for this fields, the correct names are "operation" / "name" / "value"
To Reproduce Steps to reproduce the behavior:
Just do a GET and you'll see that the json output is not the same as what is described in the documentation
Expected behavior A clear and concise description of what you expected to happen.
Have the documentation with name that are the expected ones

@patrice-adp can you share screenshots and a direct link to the API endpoint in question?

Screenshot of documentation on sailoint

Screenshot of call using postman collection

This issue has been resolved: https://developer.sailpoint.com/idn/api/v3/list-work-items


Added link to download Windows 10

Added the link to download latest version of Windows 10 ISO

@TusharChaturvedi Good link, thanks for adding it!


cannot find the paper

Cannot find the paper 《An Empirical Study of Vehicle Re-Identification on the AI City Challenge》
Could you please provide the download link?

Hi!
Please check 'paper.pdf' in the repo.


Unable specify aspect ratio by passing the prop(无法通过props属性指定组件拉伸时的宽高比例)

when lockAspectRatio props is set to true, the aspectRatio of   the stretch of the component is calculated based on the internal self -transmitted W and H from passing props，and unable to change from the outside of the component Even if you change the W and H of props.
当lockAspectRadio属性设置为ture时，组件拉伸的宽高比例是内部自行根据传入的w和h计算的，即使更改props属性的w和h，都不能从外部改变组件拉伸的宽高比。

when W an H change，ues v-if directive to recreat component。
Change the value of the lock-aspect-ratio asynchronously。 just see this issue。 https://github.com/mauricius/vue-draggable-resizable/issues/301


Removed duplicate app name - Raycast.

Raycast is already present in the list and both of them had same URL

Thank you!


Lsc move rdt

solves #16

Move IST lookup in parallel with Decode
Change RDT Commit => RDT Update
Move RDT Update to ren2/dispatch
For tag=ful_pc: Use decodeWIdth extra ports to FTQ. Only for IST. Delay the PCs for 1CC such that RDT can use them also

Found a bug


RootMail feature fails on the DKIM verification

The RootMail feature failed for me on the DKIM verification. When superwerker created the email subdomain it didn't configure the NS forwarding on the root domain. I added that in manually and the installation continued. Seems like a bug.

related to #313


Various improvements

Addresses #12
Addresses #15
In service of #16
Addresses #22 (I think?)
In service of #35
My only means of testing at this point is to make sure the pam_password-like auth flow as described in the README is still working, and that is working. So... "tests are passing".

i like it - please squash to clean.

Squashed

i think this is ready.    up to you if you want to wait for any more eyes before #'ing.

I'll wait for eyeballs before #'ing on this one.

#'d. Mergin.


Use development/production NODE_ENV

I get this warning on digitalmind.io (both Chrome and FF):

There are probably two problems:

the live site runs with development build, not production one (webpack -p)
as the warning says, the code shouldn't be minified when running in development mode

I use something like this to minify code only in production builds:
function getPlugins() {
    const plugins = [];

    if (process.env.NODE_ENV === "production") {
        plugins.push(new webpack.optimize.UglifyJsPlugin({
            minimize: true,
            output: {
                comments: false
            },
            compressor: {
                warnings: false
            }
        }));
    } else {
        // not related to this issue,
        // but quite useful, too :)
        plugins.push(new webpack.HotModuleReplacementPlugin());
    }

    return plugins;
}

module.exports = {
    …
    plugins: getPlugins(),
    …
}

Oh, this is awesome! To be honest, I don't entirely understand how webpack works yet, but I've added your code and the error is gone =)
Thank you very much for your help!


3.0.0-M2 Micrometer binders

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0.0-M2-Release-Notes#micrometer-binders

See https://github.com/openrewrite/rewrite-spring/pull/201
If package rename is all we want then this should do it:
type: specs.openrewrite.org/v1beta/recipe
name: org.openrewrite.java.spring.boot3.Micrometer_3_0
displayName: Micrometer compatible with Boot 3.x
description: Switch to Micrometer compatible with Boot 3.x
recipeList:
  - org.openrewrite.java.ChangePackage:
      oldPackageName: io.micrometer.core.instrument.binder
      newPackageName: io.micrometer.binder
      recursive: true

This recipe became obsolete with the decision in https://github.com/micrometer-metrics/micrometer/issues/3119

thanks @fabapp2


retry logic for only failed tests

What is your Test Scenario?
As we know we have --quarantine-mode to retry test cases run , however current way took long time execution which ran more than 2 or 3 times and  i'm looking best retry logic for only failed tests with number of times, For example if i wanted to run two times for only failed tests
What are you suggesting?
It would be great to implement retry logic and to have retry flag like 'testcafe chrome tests/test.js --retry 2'
What alternatives have you considered?

Additional context

Thank you for your inquiry. We already have a similar suggestion in our repository: https://github.com/DevExpress/testcafe/issues/3891. Please add 👍 to help us prioritize it, and use it to share your thoughts and track our progress in implementing this feature. I will close this issue as a duplicate for housekeeping purposes.


Modify StatsStorage::GetTableStats() to take a txn as a parameter instead creating a new one

As @poojanilangekar and @yingjunwu mentioned in previous emails, when visiting ColumnStatsCatalog, the stats storage use a concurrency::TransactionContext*  passed in as a parameter instead of creating a new one. This is a quick fix for that.

Coverage increased (+0.03%) to 77.195% when pulling 8248e68d5edd2177aa39acd99ac90343582dcbf9 on chenboy:cost_model_txn_fix into c21f80aa841b02f6ddcdf062bc49e5cca5b77a8a on cmu-db:master.

This PR was a result of investigating excess transaction in #1154

@poojanilangekar @yingjunwu
Hi guys,
Can you take a look at this PR, it seems like a quick fix(100 lines modified in total)
If nothing is wrong, please change the tag into "accept"
Thanks!

looks good to me. but I was wondering why the previous version creates so many transactions? The major update in this PR is to pass in transaction manager pointer. But I am not sure why it fixes the transaction creation bug.

build failed. please fix it.

Jenkins seems to be failing for all PR now. I think it’s caused by another issue in optimizer_rule_test. This PR builds on Travis so I think it should be good.

okay. I wonder whether you could answer the following question: looks good to me. but I was wondering why the previous version creates so many transactions? The major update in this PR is to pass in transaction manager pointer. But I am not sure why it fixes the transaction creation bug.

As @poojanilangekar  mentioned in an earlier email, the previous version would create (and commit) a txn in StatsStorage::GetTableStats() because it needs to access ColumnStatsCatalog. This function may be called multiple times in the optimizer so we may create multiple transactions. Now we pass in the current transaction and do not create a txn each time the function is called, so it could hopefully solve the issue. I'm not sure if this is the answer you're looking for.

okay the PR is ready to go.

@pervazea
Hi Pervaze, can you help merge in this PR? both @yingjunwu and @poojanilangekar has confirmed that it is ready to go!
Thanks!

@mengranwo I will give you permissions.

@chenboy Do you also want to change the begin txn here?
https://github.com/cmu-db/peloton/blob/master/src/optimizer/stats/stats_storage.cpp#L47

This function should only be called when the system initializes, so I think its fine here. But right now we do not initialize the singleton StatsStorage so it may cause the first query that requires stats to initialize StatsStorage, and thus create another txn. @poojanilangekar @yingjunwu are you currently blocked by this? If not, the cost model team will work on this in the near future, we can merge this PR first.


DRAFT: Elizabeth/databricks form

SUMMARY

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

This pr was broken into smaller ones.


Is the weight tensor reordered in the forward calculation?

Hi, you mentioned in your paper that the weight matrix or tensor will be reordered according to the permutations.
While  in the code sparelayer.py, the weight is multiplied by the mask directly
def forward(self, x):
      weight = torch.mul(self.weight, self.mask)
      return F.linear(x, self.weight, self.bias)

that is why?

When you get the permutation, you should reorder the weight tensor according to it, the input to that layer and the output of that layer also need to reorder at runtime according to the permutation.
The correct process should be
w = w[alpha, beta]
b = b[beta]

def forward(self, x):
	x = x[alpha]
	w = torch.mul(w, mask)
	y = F.linear(x, w, b)
	return y[beta^-1]

My code is used for fine-tuning, so instead of permuting the weight and input/output, I only permute the mask.
mask = mask[alpha^-1, beta^-1]

def forward(self, x):
	w = torch.mul(w, mask)
	return F.linear(x, w, b)

That is what you see, the permutation of the mask is implemented in the end of compress.py

Thank for your reply.
So I have to calculate the x = x[alpha] and y[beta^-1]  myself.
Can you explain how to get the permutations alpha and beta? ( I guess it's by the 'orders' returned from compress.py)
Acctually, I am trying to reproduce the experiments on LeNet5(MNIST). I noticed that the block-size in Figure4(a) is from 16 to 128. Can you tell me which layer you prunned with this figure as the weight tensor of the first two conv layers are the size of 1x6x5x5 and 6x16x5x5.
According to the code in compress.py, the X is reshaped by block_nums and block_sizes:
......
X = torch.abs(X).cuda()
dim_sizes = X.size()
num_dims = len(dim_sizes)
block_sizes = [bs if bs > 0 else ds for bs, ds in zip(block_sizes, dim_sizes)]  #eg 64x32x3x3
block_nums = [int((ds - 1) / bs) + 1 for bs, ds in zip(block_sizes, dim_sizes)]
...
block_sums = X.view(*tuple(itertools.chain.from_iterable((bn, bs) for bn, bs in zip(block_nums,
block_sizes))))
It seems that the block_size (set by the json file) should be a factor of the X's dim_size,
e.g.  when pruning alexnet,  the  block_size  for last layer is [40, 32, 0, 0].
the weight tensor is 1000x4690 then we have the block_nums=25x128
so the weight wensor(X) can be reshaped with 40x25x32x128.
So I am confused how it works for the Lenet5 under the block size of 16, 32, 64 and 128. Besides, the weight tensorf of the Liner layer in Lenet5 is 120x400, 84x120 and 10x84

So the block_size for each layer should be a factor of the X’s dim_size right?
or the block_sums will rasie error in the compress.py

......
X = torch.abs(X).cuda()
dim_sizes = X.size()
num_dims = len(dim_sizes)
block_sizes = [bs if bs > 0 else ds for bs, ds in zip(block_sizes, dim_sizes)]  #eg 64x32x3x3
block_nums = [int((ds - 1) / bs) + 1 for bs, ds in zip(block_sizes, dim_sizes)]
...
block_sums = X.view(*tuple(itertools.chain.from_iterable((bn, bs) for bn, bs in zip(block_nums,
block_sizes))))
And whta is the pruning ratio for the Lenet5?


Raspbian Jessie.  Installing new nodes issue (it's not there)

I am trying to install the weather underground node.  Following the directions on the Raspberry Pi page over at nodered.org.
sudo apt-get install npm
sudo npm install -g<EMAIL_ADDRESS>cd ~/.node-red
npm install node-red-node-weather-underground
node-red

I get a permissions error.  If I add sudo it installs correctly but the new node is not there when I start up node-red.  I am sparkly new to Node-Red and not sure if I am just missing something simple.  Someone throw me a bone?

I just threw a -g into the mix and rebooted.  GTG!


react-native-gesture-handler java.lang.boolean cannot be cast to java.lang.double

Please update react-native-gesture-handler as your project does not work with new versions of react-native-gesture-handler. Moreover, react-native 0.71.x only works with react-native-gesture-handler 2.9.0>. As a result, I need to remove your package or stay with the old react-native version.

@Bur0 I solved this issue. Please check pull request.

@Bur0 Can you review and merge pull request ?


[WIP] audio preprocessing script

A simple command line script for batch processing audio files to convert them to the correct format and sample rate for HEAR 2021 audio tasks

Implemented in #8


mkdir -p to make instructions work in any order (tiny change)

There's no need to error on failing to create ~/.ammonite if it already exists, such as for those who have already downloaded Ammonite.

Looks good, thanks!


Inquiries about chrX analysis plan

Hello, I would like to ask a question about the chrX analysis plan.
I am sorry that this question may be too basic, but I would like to know how we should interpret and apply the results of heterozygosity test.
I understood that the heterozygosity in X chromosome in males indicate possible errors, but I wonder how we should apply the results.
We may exclude all variants with at least one heterozygous subject or remove all subjects with any heterozygosity in X chromosome, but I do not think these processes would be proper.
Thus, I would like to ask how we could filter the data based on the heterozygosity test results.
I would appreciate it if someone could give me an answer.
Thank you.

Hi Jaehun,
The presence of heterozygosity on the X chromosome in males may indicate the existence of SNPs on the X chromosome that have homologous counterparts on autosomal chromosomes. In such cases, the SNP on the X chromosome might mistakenly be targeting its homologous SNP on the autosome, leading to observed heterozygosity in males.
During imputation, this misassignment can propagate, resulting in surrounding SNPs also exhibiting heterozygosity in males. If the rate of heterozygosity in males is particularly high, it calls into question the reliability of results from the array. To address this, it is advisable to identify and exclude SNPs with a high probability of homology, as well as all other SNPs with elevated heterozygosity rates in males, before re-performing the imputation and subsequent analysis.
Hope this help


useTranslator() returns an undefined function

Testing the following code in a component:
const {translate} = useTranslator(); // Translation object for translating
console.log("Testing translate:");
console.log(translate)

leads to the following output:
 LOG  Testing translate:
 LOG  undefined

And the translate() function does not work as a result

same with me

Same here

same here how to fix this?


Platformize core configuration subprojects

The following projects are moved to the core-configuration platform in this PR:

api-metadata
file-collections
model-core
model-groovy
base-services-groovy

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.


Update microsoft-lync-plugin caveat

According to this blog post, Microsoft Lync has been replaced by Skype for Business.

Thank you for the contribution. It was merged directly as e0510376fe94a5cc238b5e37afe628f6d1c8d04b to keep commit history cleaner. Your contribution is still credited to you.


Signalling Pathway Layout

Training set of signalling pathways (no particular order):

PI3-kinase signalling

'PIP3 Activates AKT Signaling' (Reactome)

TGF-beta signalling

'Signaling by BMP (Reactome)

Ras-Raf-Erk signalling

'RAF Activation' (Reactome)

Notch-Delta signalling

'Notch Signaling' (PathwayPID)

A couple of these sbgn files have unescaped double quotes for a few of the label values.  This causes the converter to break.

<label text="dephosphorylated "receiver" RAF/KSR1"/>
will not pass SAX validation

stale discussion --  moved to viewer component


codespell: enable tests

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 112949 at d999a09b run on x86_64-linux 1

6 packages built:

codespell (python38Packages.codespell)
python37Packages.aspell-python
python37Packages.codespell
python38Packages.aspell-python
python39Packages.aspell-python
python39Packages.codespell

Result of nixpkgs-review pr 112949 at d999a09b run on aarch64-linux 1

6 packages built:

codespell (python38Packages.codespell)
python37Packages.aspell-python
python37Packages.codespell
python38Packages.aspell-python
python39Packages.aspell-python
python39Packages.codespell

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 112949 run on x86_64-darwin 1

6 packages built:

codespell (python38Packages.codespell)
python37Packages.aspell-python
python37Packages.codespell
python38Packages.aspell-python
python39Packages.aspell-python
python39Packages.codespell