bug: cursor off by 1 in headings with inline setting

Neovim version (nvim -v)
NVIM v0.11.0-dev-973+gb7e8966715
Neovim distribution
N/A
Operating system
Arch
Terminal emulator / GUI
Kitty
Describe the bug
I'm using the inline settings for heading and, as it can be seen in the GIF, the cursor in normal mode is 1 column to the right when hovering over the heading icon.

Expected behavior
Have the cursor 1 column to the left so that the cursor doesn't "jump" when moving from a line with a heading to a line without one.
Healthcheck output
render-markdown:                     require("render-markdown.health").check()

render-markdown.nvim [version] ~
- OK plugin 7.3.11
- OK neovim >= 0.10

render-markdown.nvim [configuration] ~
- OK valid

render-markdown.nvim [nvim-treesitter] ~
- OK installed
- OK markdown: parser installed
- OK markdown: highlight enabled
- OK markdown_inline: parser installed
- OK markdown_inline: highlight enabled
- OK latex: parser installed

render-markdown.nvim [executables] ~
- WARNING latex2text: not installed
  - ADVICE:
    - Disable LaTeX support to avoid this warning by setting { latex = { enabled = false } }

render-markdown.nvim [conflicts] ~
- OK headlines: not installed
- OK obsidian: not installed

Plugin configuration
require('render-markdown').setup({
    enabled = true,
    file_types = { 'markdown', 'chatgpt', 'chatgpt-input' },
    render_modes = true,
    win_options = {
        conceallevel = { rendered = 2 },
        concealcursor = { rendered = 'nc' },
    },
    anti_conceal = {
        -- Preserve glyphs in normal mode but make them "anti_conceal" in insert mode to
        -- replicate concealcursor behaviour
        ignore = {
            bullet = { 'n' },
            callout = { 'n' },
            check_icon = { 'n' },
            check_scope = { 'n' },
            code_language = { 'n' },
            dash = { 'n' },
            head_icon = { 'n' },
            link = { 'n' },
            quote = { 'n' },
            table_border = { 'n' },
        },
    },
    dash = {
        width = 80,
    },
    heading = {
        sign = false,
        icons = { '󰪥', '󰺕', '', '', '', '' },
        position = 'inline',
    },
    bullet = {
        icons = { '', '•', '', '-', '-' },
    },
    checkbox = {
        unchecked = { icon = '' },
        checked = { icon = '', scope_highlight =<EMAIL_ADDRESS>},
        custom = {
            doing = {
                raw = '[_]',
                rendered = '󰄮',
                highlight = 'RenderMarkdownDoing',
            },
            wontdo = {
                raw = '[~]',
                rendered = '󰅗',
                highlight = 'RenderMarkdownWontdo',
            },
        },
    },
    code = {
        sign = false,
        width = 'block',
        border = 'thick',
        min_width = 80,
        highlight_language = 'LineNr',
        language_name = false,
    },
    quote = { icon = '▐' },
    pipe_table = { cell = 'raw' },
    link = {
        wiki = { icon = '󱗖 ', highlight = 'RenderMarkdownWikiLink' },
    },
})

Plugin error log
-

Confirmations

[X] I have updated this plugin to the latest version using my plugin manager
[X] I have provided the text contained in all screenshots as raw text in this issue. This means if there is a screenshot below it is the copy pasted contents of the file in the screenshot. I understand that my issue will be closed if I have not.

Additional information
No response

This is just how inline virtual text works. Since there's nothing underneath it there's nowhere for the cursor to go.
You'll notice the same thing with link icons and a few other components.


Unnecessary  update on entity when using LoadStrategy.JOINED

Describe the bug
Example:
Project has Collection of Radio
We load a radio (call it radio1) from the database with together with a project (call it project1). Then we create a new project or do something else and we persistAndFlush it. Then it also finds a diff on radio1 that the project_id has changed to project1.id. This is weird, since it has not changed.
This triggers an additional and unnecessary query to update radio1.
To Reproduce
Steps to reproduce the behavior:

Checkout PR 1333
yarn test GH1334
...

Expected behavior
Should not trigger an update query on radio1
Additional context
When setting the LoadStrategy to SELECT_IN it does not trigger the additional update query

The issue here is with originalEntity data being populated with the fetch joined result:
      ChangeSet {
        entity: Radio {
          id: 1,
          order: 0,
          question: 'ufzmqkk',
          project: [Reference],
          options: [Collection]
        },
        type: 'update',
        payload: { project: 1 },
        name: 'Radio',
        rootName: 'Radio',
        collection: 'radio',
        originalEntity: {
          id: 1,
          order: 0,
          question: 'ufzmqkk',
          project: [Object],
          o2__id: null,
          o2__value: null,
          o2__order: null,
          o2__radio_id: null
        }
      }

We should have something like this instead:
        originalEntity: {
          id: 1,
          order: 0,
          question: 'ufzmqkk',
          project: 1
        }

The issue here is with originalEntity data being populated with the fetch joined result:
      ChangeSet {
        entity: Radio {
          id: 1,
          order: 0,
          question: 'ufzmqkk',
          project: [Reference],
          options: [Collection]
        },
        type: 'update',
        payload: { project: 1 },
        name: 'Radio',
        rootName: 'Radio',
        collection: 'radio',
        originalEntity: {
          id: 1,
          order: 0,
          question: 'ufzmqkk',
          project: [Object],
          o2__id: null,
          o2__value: null,
          o2__order: null,
          o2__radio_id: null
        }
      }

We should have something like this instead:
        originalEntity: {
          id: 1,
          order: 0,
          question: 'ufzmqkk',
          project: 1
        }


adapt into bubbletea program

This will make it easier to integrate into charm eco system.

move walkInfo into common and rationalise with this

	TraverseInfo struct {
		DiscoverOptionsFn  nav.TraverseOptionFn
		PrincipalOptionsFn nav.TraverseOptionFn
		With               nav.CreateNewRunnerWith
		Resumption         *nav.Resumption
		IsDryRun           bool
	}

	NavigateInfo struct {
		OptionsFn  nav.TraverseOptionFn
		With       nav.CreateNewRunnerWith
		Resumption *nav.Resumption
		IsDryRun   bool
	}


adds the package type "yawik-module"

Hi,
I would like to add the package type "yawik-module"
regards,
Carsten

Add your installer to the InstallerTest::dataForTestSupport, please.

@cbleek fix conflicts, please.


Allow HEAD requests

If I only need access to the X-TypeScript-Types header, I can just do a HEAD request and avoid having to download the module content. Currently esm.sh responds with a 405 to such requests.
curl -IL -X HEAD https://esm.sh/lodash
HTTP/2 405
date: Sun, 15 May 2022 20:04:25 GMT
content-type: application/json; charset=utf-8
content-length: 56
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=Yk6eN5%2BpT1GWF7HkSNk7nFH2rVt%2FueIjdihzXo9C3PTznmDIfszOiXDslm%2Fgex5YteBPB5ZfeZnFU%2F4mRpD3%2BEcQRwI6X4nkxaP1ls0nOv8mHIomNTuDAa%2BYpAZr1bc8T35QTOs%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 70be7b88e88d83c6-BRU
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

This is in line with deno.land:
curl -IL -X HEAD<EMAIL_ADDRESS>HTTP/2 405
accept: GET
vary: Accept-Encoding
date: Mon, 16 May 2022 01:58:30 GMT
server: deploy/us-east4-c

I realize esm.sh has more use cases than a deno module registry, but curious what this would be used for?

curious what this would be used for?

One use-case I had was an online code editor that edited typescript files that import esm.sh urls. I only really needed the type definitions, if available.

the content-length: 56 is really small, and you always can get that size access package via https://esm.sh/$PKG


[Feature] Manual rotation tracking by sensors

ARTracking makes my phone so hot! Maybe we can track it more easily for CPU?

At this time I just implemented EasyARWorldTrackingSource, it's can't track position but more easier for CPU.


Add into VimService methods moveIntoFolder_Task and createVM_Task

These methods are not required for default MIQ classes. However, it's good sometimes to have them in VimService when writing MIQ extensions.
As you see from the names:

moveIntoFolder_Task moves an object (VM or whatever) into vCenter folder
createVM_Task creates empty VM that can be installed later from iso or whatever

Required request and response schemes are in wsdl used by MIQ already, but VimService does not provide now methods to make these vCenter calls. The patch just adds the methods.

@roliveri @Fryguy - please review.

Looks good to me :+1:   @roliveri ?
@avasyukov Ignore the rubocop messages here, since the code changes are consistent with the rest of the code in this file.

For completeness, maybe we should also add the corresponding higher-level entry points to the MiqVimFolder class. Those methods could then employ the waitForTask() method to implement synchronous versions. See:  MiqVimFolder#registerVM as an example.
Other then that, the code looks fine to me. If you'd rather not modify the MiqVimFolder class, I can always update that class in the future if needed.

@roliveri @Fryguy thanks for the review. I'll add methods into MiqVimFolder in few hours and update this pull request.

Thanks @avasyukov !

I'm sorry a lot for the delay - we experienced a major issue on customer production site, so had zero time during the last days.
Pull request is updated now with two new methods in MiqVimFolder. I tested them live, they work fine in scripts like:
new_vm_mor = vimFolder.createVM(vmConfigSpec, vmware_pool_ems_ref)

and
vimFolder.moveIntoFolder(vimVm.vmMor)


how to fix memory issue when loading message?

I was trying to load emails. it work on other email but I get issue with email account with multiple messages.
here is the code:
 $config = config('imap.accounts.default');
$config['username'] = $credentials['email'];
$config['password'] = $credentials['password'];

$client = Client::make($config);
$folders = [];
$mailFolders = $client->getFolders($hierarchical = false);

foreach ($mailFolders as $folder) {
    $folder_name = $folder->name;

    $folders[$folder_name]['unread_count'] = $folder->messages()->unseen()->count();
    $folders[$folder_name]['messages'] = [];

    $folder->messages()->all()->chunked(function ($messages, $chunk) use ($folder_name, &$folders) {
        $messages->each(function($message) use ($folder_name, &$folders) {
            $folders[$folder_name]['messages'][] = $message;
        });
    }, $chunk_size = 10, $start_chunk = 1);
}

I get the following issue in laravel:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1576960 bytes) in vendor/webklex/php-imap/src/Part.php on line 196

Is there a better way to load all message?

If you don't need to access older messages, you could use folder's method since to get smaller batch of messages, see example:
$messages = $folder->query()
    ->since('01.01.2024')
    ->all();

I hope someone will come with better solution to read ALL messages in chunks without heavy memory impact.

I still getting the same error. if there a way to handle an account with multiple messages?

I had a memory problem when fetching messages with large attachments? I fixed the memory-issue with this solution: #457
Maybe it can help you to.

this is the correct way but loading all the message throw :
Webklex\ PHPIMAP\ Exceptions\ GetMessagesFailedException
Trailing data

I tried the following:
 public function index(Request $request)
    {
        $credentials = decrypt(session('imap_credentials'));
        $config = config('imap.accounts.default');
        $config['username'] = $credentials['email'];
        $config['password'] = $credentials['password'];

        $client = Client::make($config);

        if (!$client->isConnected()) {
            try {
                $client->checkConnection();
            } catch (\Exception $e) {
                Auth::logout();
                $request->session()->invalidate();

                return redirect()->route('login')->with('alert', [
                    'type' => 'danger',
                    'message' => 'Failed to connect to the email server. You have been logged out. Please log in again.',
                ]);
            }
        }

        $folders = [];
        $mailFolders = $client->getFolders($hierarchical = false);

        foreach ($mailFolders as $folder) {
            $folder_name = $folder->name;

            // Get unread message count
            $folders[$folder_name]['unread_count'] = $folder->messages()->unseen()->count();

            // Fetch messages from the folder
            $folders[$folder_name]['messages'] = $folder->messages()->all()->fetchOrderDesc()->get();
        }

        return view('office.emails.test', compact('folders'));
    }


Build a scanner that scans for strings with high entropy - suspected passwords

Summary
I've been using detect-secrets, and this is a much faster scanner - but it doesn't have the entropy capabilities as defined here. I think it is valuable to find general things which are not strictly related to one of the existing tokens.
Desired Behaviour
Find things like:
const password = "asdWEFV21!#@D,dd"

Possible Solution
Implement entropy classes similar to what detect-secrets has
NOTE: # ( Not required. Suggest how to implement the addition or change. )
Additional context
Willing to try my luck at a contribution if you guys are up for it.
TIP:  # ( Why does this feature matter to you? What unique circumstances do you have? )

Went into the code, probably missing something, there is quite a bit about entropy in there. Thanks and sorry for the noise!


unable to run in ubuntu 20.04 (under QB64)

hi,i'm not expert
i'm try to run InForm under qb64 in ubuntu 20.04 64bit HDD installed(Kernel 5.4.0-29-generic).
after install by InFormSetup_Debian64  (downld,complile are OK)but when i launch :./UiEditor..
i retrive:InForm designer is not running.Pleaserun the main program!
thanks in advance && sorry my english

Hello. I've been meaning to change the handshake timeout for linux for a while now, as this is a known issue. Latest patch, applied today (00f28644629c4b4a8cf8332f0c990b7a6feeeadd) should get you going. https://github.com/FellippeHeitor/InForm/archive/development.zip

worked like a sharm! thanks so much

If I may, there is a small trick to avoid this problem without asking to Fellippe to modify the handsahe timeout each time there is a new release whatever the Linux distribution and desktop environment you use:

Once you've downloaded and unpacked InFom as requested (to the QB64 main folder), first load and compile the UiEditorPreview.bas file (located in the InForm sub folder) WITH the option "Output EXE to Source Folder" on, to place the UiEditorPreview executable to the InForm folder,
Then load and compile the UiEditor.bas file (also located in the InForm sub folder) but now WITHOUT the option "Output  EXE to Source Folder", to place the UiEditor executable to the QB64 main folder.
Now there is also the other solution to use my multi-lingual installation bash script for Linux that installs (and can cleanly uninstall) QB64, InForm and vWATCH64 alltogether that you can get here: www.as2.com


Add Spicelang language

Description
Add support for the Spice programming language
Checklist:

[x] I am adding a new language.

[x] The extension of the new language is used in hundreds of repositories on GitHub.com.

Search results for each extension: search results

[x] I have included a real-world usage sample for all extensions added in this PR:

Sample source(s): sample source
Sample license(s): MIT

[x] I have included a syntax highlighting grammar: lightshow demo
[ ] I have updated the heuristics to distinguish my language from others using the same extension.

SPICE is also the name of a well-known circuit simulation program, which uses a plain-text file format to represent models and schematics. I therefore suspect most of the ~1,306 search results for .spice are actually circuit-board schematics, especially since there are literally only 9 people who've starred your project (suggesting that it falls well short of Linguist's popularity criteria).

Instead of this Spice Lang, I'd like SPICE, the circuit simulation language, to be recognized by GitHub. Its external name is .sp, which is now recognized as SourcePawn.
SPICE is widely used in Transistor-Level Circuit Design and VLSI. Just search SPICE or HSPICE with language SourcePawn, there are many SPICE programs.
See:
https://github.com/search?l=SourcePawn&p=1&q=SPICE&type=Repositories
https://github.com/search?l=SourcePawn&p=1&q=HSPICE&type=Repositories

@z0gSh1u please open a new issue or submit a PR youself to add support.

I'm closing this PR as usage really hasn't grown anywhere near our usage requirements in the two years this PR has been open.
Please feel free to open a new PR once usage meets our requirements.


Improve the release (notes) process

Right now, generating the release notes is pretty manual and painful, especially with all the different merge styles we're using (merge commit, squash merge, rebase merge).
Come up with a better system, which may involve some or all of:

changing our standards for merging PRs
changing how we writing commits
changing how we title PRs
hacking up some scripts to hit github and generate (a draft of) release notes based on the merged PRs since the last release

Guess we can close this now that we use towncrier.


fix(sec): upgrade com.fasterxml.jackson.core:jackson-databind to 2.14.0-rc1

What happened？
There are 1 security vulnerabilities found in com.fasterxml.jackson.core:jackson-databind 2.13.3

CVE-2022-42004

What did I do？
Upgrade com.fasterxml.jackson.core:jackson-databind from 2.13.3 to 2.14.0-rc1 for vulnerability fix
What did you expect to happen？
Ideally, no insecure libs should be used.
The specification of the pull request
PR Specification from OSCS

We have to wait for the official release version altogether with other modules. Thanks a lot for your help.


Stache bug with #reference exports

If a stache condition wraps a component that is exporting its entire view model 2-way like in the below example, if the condition starts out false and becomes true, an error is produced.
{{#eq page 'bar'}}
  <test-component #test-vm></test-component>
{{/eq}}

It seems the refs scope sees a change to testVm and throws an error while trying to run the compute to update the child. I don't think the change should be perceived in the first place.
http://jsbin.com/huhekilusu/1/edit?html,js,console,output
For anyone experiencing this issue, my current workaround is to use a 1-way binding which seems to be sufficient for all my use cases.
<test-component #test-vm="{{.}}"></test-component>

So is the real problem here #1866 ?

I'm not sure how related it is. I did manage to reproduce it with just a can.Map like the other issue so it's also not related to the router.
http://jsbin.com/tapileheda/edit?html,js,console,output
The difference here is that only one property is changing.

This appears to now be fixed in minor as a result of the bindings rewrite.


Implement image importing

Implemented in https://github.com/haroldo-ok/vcs-game-maker/releases/tag/v0.21.0


Is it OK that RAND_bytes in openssl-3.x does not use additional data

While 1.1.1 at least attempts to add some entropy in every RAND_bytes call,
openssl-3.x does not do that at all, and passes no additional data whatsoever.
Whenever a call to EVP_RAND_generate is done it looks like
EVP_RAND_generate(rand, buf, num, strength, 0, NULL, 0); except in some KAT tests.

BTW: This was changed in #11682 but I do not see this any mention of why additional data is
no longer used in the PR

Additional input is optional and isn't counted as entropy.  That we're not using it shouldn't impact the quality of the output in the least.
Users can supply additional data via the reseed calls, but again it's not essential.

Given the comments above, this appears asked and answered.  Marking as inactive, will be closed at the end of 3.4 dev

I am closing this as the question was answered.


No context provided: useLeafletContext() can only be used in a descendant of

Have issues with map edit tool bar, upgraded my pip package for dash-leaflet and get this issue in the webbrowser:
No context provided: useLeafletContext() can only be used in a descendant of <MapContainer>

Dash leaflet version is 0.1.28 from dash_leaflet.__version__
ns Dash apps. Click to see the full stack trace or open your browser's console.)

9843/_/e<@http://<IP_ADDRESS>:8050/_dash-component-suites/dash_leaflet/async-editControl.js:1:1412

_@http://<IP_ADDRESS>:8050/_dash-component-suites/dash_leaflet/async-editControl.js:1:1526

renderWithHooks@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:14938:29

mountIndeterminateComponent@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:17617:15

beginWork@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:18731:18

callCallback@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:182:16

invokeGuardedCallbackDev@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:231:18

invokeGuardedCallback@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:286:33

beginWork$1@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:23338:30

performUnitOfWork@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:22292:14

workLoopSync@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:22265:24

performSyncWorkOnRoot@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:21891:11

flushSyncCallbackQueueImpl/<@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:11224:26

unstable_runWithPriority@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react@16.v2_11_1m1691499905.14.0.js:2685:14

runWithPriority$1@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:11174:12

flushSyncCallbackQueueImpl@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:11219:26

flushSyncCallbackQueue@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:11207:5

flushPassiveEffectsImpl@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:23018:5

unstable_runWithPriority@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react@16.v2_11_1m1691499905.14.0.js:2685:14

runWithPriority$1@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:11174:12

flushPassiveEffects@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:22955:14

commitBeforeMutationEffects/<@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react-dom@16.v2_11_1m1691499905.14.0.js:22834:13

workLoop@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react@16.v2_11_1m1691499905.14.0.js:2629:44

flushWork@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react@16.v2_11_1m1691499905.14.0.js:2584:18

performWorkUntilDeadline@http://<IP_ADDRESS>:8050/_dash-component-suites/dash/deps/react@16.v2_11_1m1691499905.14.0.js:2196:50

It is a new clean install in a docker container.

Beautiful, thanks I will give it a try.
On Wed, 9 Aug 2023 at 01:07, Emil Haldrup Eriksen @.***>
wrote:

This is a know issue with the latest release. If you revert til
dash-leaflet==0.1.23, the error should go away. I am working on a new
major release (essentially a complete library rewrite) that will fix this
issue, but there is still some way before I can release it.
—
Reply to this email directly, view it on GitHub
https://github.com/thedirtyfew/dash-leaflet/issues/189#issuecomment-1669802559,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIBV43W7LVUGFFUQZKX2FLXUJI3PANCNFSM6AAAAAA3ISNTFU
.
You are receiving this because you authored the thread.Message ID:
@.***>

That worked thankyou.


How to retrain the saved model?

I use command "model.save(save_path)" to save model and use command "model = train_model.load(save_path)" to restore the saved model. But I dont know how to continue training from the restored model rather than train from zero.

Hello,
the answer is on the documentation.
Duplicate of #599


Documentation: services

What are the services that can be enabled by this? I can only get Light and Switch to work, but an overview of what is possible would be greatly appreciated!
Thanks.

That's all. It's meant to be a base basic plugin which people can build upon. It is kept light on purpose

Clear. Thanks for the quick response. Other plugins you can recommend to build upon this one?

Any tips on publishing multiple 'rooms', since now they're all added to the same room

@TonyFeestneus that is handled in the application side of things and is much clearer in IOS10
you just head into the detials of the device and then you can specify a room, or hide it by disregarding the show on fav's slider.


stm32_sdio: Fix in SDIO clocking configuration.

Summary
Fixes clocking on STM32's SDIO peripheral, where the register value was not applied correctly.
Impact
Proper clocking on STM32 SDIO.
Testing
@pnb990 Can you please test this?
The fix seems obvious, so I blindly applied it. I have no means of testing it.

For reference, this bug was indicated in the mailing list<EMAIL_ADDRESS>


Add batch upload to Solana

(passing progress as a prop)

📝 Changed routes:

/_og/release
/dashboard

(view full size)
(view full size)

And 1 other route:

/api/feedback

Commit b39bd3997a744c61a7ab8d8608e96a15d04e7d40 (https://thirdweb-7m00uhosr-thirdweb.vercel.app).


默认的例子最大化后再最小化，控件都没了。

Describe the bug
A clear and concise description of what the bug is.

我想知道这是类库的bug还是例子程序的bug。屏幕是4K屏幕不知道是否有关。
To Reproduce
Steps to reproduce the behavior:

[First Step]
[Second Step]
[Other Steps...]

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

LCUI version: [Enter LCUI version here]
Build tools: [Enter build tools name and version here, E.g: gcc/clang/VisualStudio 201X]
OS and version: [Enter OS name and version here, E.g: WinXP/Win7/Win10/Ubuntu/Mac OS]

Additional context
Add any other context about the problem here.

库的 bug。

建议提供录屏。

建议录屏发上来。


feat(sync): networkHead callback metric

As per request
https://github.com/celestiaorg/celestia-node/issues/2921#issuecomment-1808209246
While this isn't super high priority - it is true that totalSynced metric does not correlate to what the current networkHead is. There is no way currently to determine what the netHead of the node is via metric (local head does not suffice as it's only reporting store head).

Codecov Report
Attention: 19 lines in your changes are missing coverage. Please review.

Comparison is base (28ff21c) 63.60% compared to head (b6fd46e) 63.41%.

Files
Patch %
Lines

sync/metrics.go
17.39%
19 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
- Coverage   63.60%   63.41%   -0.20%
==========================================
  Files          39       39
  Lines        3366     3389      +23
==========================================
+ Hits         2141     2149       +8
- Misses       1060     1075      +15
  Partials      165      165

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I think we will have to close this one in favour of another incoming syncer metric PR

is networkHead added as a metric there? @Wondertan


use aquamarine 0.1 branch

Aquamarine has been updated to support offline mode in 0.1.8, and doesn't require internet connection to build and view the rendered diagrams anymore.
This change switches from pinned patch version to a the 0.1 branch in order to include the offline more feature and other backward-compatible improvements coming in future

Thank you for your PR. It is good for building documents with aquamarine without internet connection.


[FEATURE REQUEST] Feature Item Content Preview in Compacting Drawers

Description:
Just how we can see what is inside normal drawers. Would be useful to see the content of compacting drawers while on our inventory

Duplicate #48


Typescript typings

It would be nice to have typescript typings stored in the usual place DefinitelyTyped on github.

I've submitted the PR to add the definitelytyped file: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/20389


Enable Tikhonov regularization in BASEX

In a discussion with Mikhail Ryazanov, I realized that we have disabled the Tikhonov regularization factor in the basex algorithm. This occurs on line 184 of basex.py:
    q_vert, q_horz = 0, 0  # No Tikhonov regularization

As I recall, we originally thought that this factor didn't significantly affect the output. However, I think that this parameter can have a large effect on the transform in the presence of noise, greatly suppressing the nose at small r-values.
You can see here the difference between q_vert, q_horz = 0, 0  (left) and q_vert, q_horz = 100, 100 (right).

I think that many users of the old BASEX.exe enjoyed this smoothing, and this is one of the reasons that BASEX became so popular. So, I think that we need to re-activate this feature.
However, in our current implementation, the "basis set" that is saved (pre-cached) already has the tikhonov regularization factor included. So, we would either need to change the naming convention of the saved files to include the tikhonov factor in the file name (in addition to the image size), or we would need to slightly re-work the algorithm to save the basis sets at a slightly earlier stage, and include the tikhonov factor in the computation of the transform (instead of in the computation of the basis sets). This would result in somewhat slower transform times, but allow users the most flexibility to try several tikhonov regularization factors. We should likely investigate how much this slows down the transform before making a decision.
Additionally, Mikhail suggested that we look into using one of the linear algebra "solve" functions instead of matrix inversion and other matrix algebra steps. I think that the appropriate numpy function is this one:
https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.linalg.solve.html

I mean that in principle x = numpy.linalg.solve(A, b) should work faster than Ai = numpy.linalg.inv(A); x = numpy.dot(Ai, b). But it works only for A x = b, while for x A = b you will need to transpose everything before and after (although transposes should be cheap). And for repetitive applications (isn't it the main goal of this project?) precomputing the inverse matrix (or an LU decomposition) once and then applying it to each image is still better.
Regarding caching, it seems that you load the matrices from disk every time. Have you considered keeping them in memory (as globals in abel.basex?) after the first load? That way, a reasonable approach would be to store the basis matrices on disk "as is", and upon the first invocation calculate the regularized inverses and keep them in memory for further invocations.

Hi Mikhail! Welcome to PyAbel :)

n principle x = numpy.linalg.solve(A, b) should work faster than Ai = numpy.linalg.inv(A); x = numpy.dot(Ai, b).

This is an interesting observation! I'm not enough of a computer scientist or mathematician to argue either way about this from first principles. But, I wrote some simple code to compare x = numpy.linalg.solve(A, b) with Ai = numpy.linalg.inv(A); x = numpy.dot(Ai, b) for randomly generated matrices A and b (see this gist)
The times look like this:

So, you are correct! np.linalg.solve beats the alternative. But, it's still about 70% of the execution speed, so we're not talking about and orders-of-magnitude improvement.

Regarding caching, it seems that you load the matrices from disk every time. Have you considered keeping them in memory (as globals in abel.basex?) after the first load?

This is a really good point! I think that this will generate some considerable discussion, so I opened a new issue: https://github.com/PyAbel/PyAbel/issues/226
Back to the issue of including the Tikhonov regularization:

a reasonable approach would be to store the basis matrices on disk "as is", and upon the first invocation calculate the regularized inverses and keep them in memory for further invocations.
Okay, if I understand, you are proposing a hybrid approach: we save the basis sets to disk before calculating the regularization or inversion (different from what we are doing now).  Then, if a repeated transform with the same regularization factor is required, we can load the matrices from RAM.

This seems like a reasonable approach, but it has the disadvantage that, if someone wants to re-run their program from scratch, they lose the regularized matrices. And, it would take quite a bit of additional effort to implement. At this point, the easiest thing to implement would be to save the basis sets before including the regularization (like you are proposing), and not worry about caching to RAM. This would create a slower transform, but maybe it's an acceptable trade-off.

OK, I've just opened a pull request (#227) with this stuff implemented.
Here is a speed comparison of abel.Transform(...).transform (end-users' perspective, so to say):

Dashed lines here are the first call, solid with symbols are the sustained performance (average of 10 calls after the first).
Caching, as expected does not help much for practically important cases, but was implemented mostly to avoid recalculating the transform matrices.
"reg var" means that the regularization parameter was changed (and thus the regularization reapplied) every time. When it remains constant, the sustained speed is better (more or less equal to "cached", usually better than "old"):

I do not know why the speed depends on the regularization parameter. And especially why for larger images larger regularization parameters actually yield a faster transform! Maybe, scipy does not like ill-conditioned matrices. :–)
In any case, all speed differences are within a factor of 2:

However, here even the first run uses only 1 loaded/calculated set of matrices and 3 cached sets, so the "raw" speed difference could be ~3 times larger. (I did not figure out how to run the included benchmarks without generating basis sets every time...)

There might be some more improvements. I did not look closely at the implementation, but I have noticed that M_vert is filled with zeros and never used. If this is not an error, we probably don't need to store it.
(And I would say that the vertical transform is not needed at all, as it makes no sense and probably amplifies noise.)

Thanks for performing these comparisons! Honestly, if we are only talking about factors of 2 in speed, then I would say that we can potentially trade speed improvements for improvements in the readability/useability/hackability of the code.
That's interesting about M_vert being zeros! Yes, I don't quite understand what a "vertical transform" would do. Certainly, if you have large tikhonov factors, weird things can happen in the vertical direction, and this seems inappropriate. We should get the same results applying to Abel transform row-by-row as we would to the entire image.

Still travelling.
The concept of basis memory storage is useful and interesting.  Thanks for your work on this @MikhailRyazanov .
The implementation is really one of  calling the basis generation function get_bs_basex_cached() once and then the transform basex_core_transform() multiple times.  In principle, this could be done by the user, however, I agree, it would be nice to perform the basis check automatically.
Note, ideally, get_bs_basex() call should be moved into the common abel.tools.basis.py file.
@DanHickstein's idea of a global basis variable is a good one, preferably passed to each method, rather than accessed via global, just as basis_dir is. If the variable is not None and right size(s), use it, bypassing the call toabel.tools.basis.get_basis_cached().
basis_dir could be repurposed, to be either the basis tuple, as returned from abel.tools.get_bs_cached(method) or a string specifying the basis directory? Note, additional parameter information may need to be included in the tuple to ensure the correct basis is used (particularly for linbasex).

@stggh, I do not not what are the use cases for this project and how the architecture decisions were made, but I would probably have the Transform as an abstract base class representing the operation rather than its results, and then derive from it actual classes implementing specific methods. Then such "transform" object could be carried around, with all settings and caches embedded, and applied to different images. If for some reason different transforms are needed, they can be done by different objects, each holding its appropriate settings and caches.
But you probably do not want to refactor everything now, so do whatever fits in the current conventions or tell me how exactly it should look.

In principle, automatic caching can be done without globals, using some mad skills. _M and _LR can even be changed to "normal" user-suppliable arguments (the cached "default" values will be still accessible through inspect.getargspec()). And maybe even some decorators to do this already exist... But I think that using module variables is more understandable, and that a proper solution would be encapsulation in a class.

with no RAM caching it is indeed ~2 times slower

Well, if there aren't many disadvantages to caching, then we may as well do it.

I do not not what are the use cases for this project and how the architecture decisions were made

Unless @rth was involved, any architecture decision were made by myself and @stggh, two experimentalists that don't know all that much about software engineering. So, I'm sure that nothing is perfect :)
Our main motivation for making Transform a class so that we could access the various outputs that could be returned using nice "dot notation". You're idea about using classes to ease the implementation of new transform methods sounds very interesting. But yeah, it sounds like it might be some work to implement, so we'd want to do a careful pro/con analysis.
If the globals stay confined to the abel. namespace, then I think it's fine to use them.

I've gone through the BASEX version 2.0 (basex.exe) sources (Borland C++) to check
what it actually does and how. Here is what I've learned, for future reference:

The code is written poorly. There are no comments except very few in Main.h, which are also misleading.

It does all calculations in single precision (C++ float).

The martices are transposed with respect to the article, and thus are multiplied backwards. The article uses first index for x and r, and second for z. The code has them reversed, so horizontal lines in the raw image correspond to matrix rows. But the matrices are stored as concatenated columns, so image matrices undergo "transposition" for input/output.

The basis sets and other matrices were apparently generated in Matlab, since there is no C++ code for them. But there is no Matlab code either.

The correspondence (hopefully, correct) between the article and code notations and the files:

Article
Code
Files
Comment

initial_image

Raw input. Matrix rows = horizontal image lines

initial_raw

Input padded with zeros to 1001×1001 size, centered

PT
raw

initial_raw folded left-right; for "2D" also top-bottom

I(r, z) raster
reconst_image

First index is z, second is r

CT
Ci

Coefficients matrix

ZT
Mc
narrow_c.binbroad_c.bin
Image basis

XT
M
narrow.binbroad.bin
Projected basis

(X XT)T
mm
mm.binmm_br.bin

(Z−1)T = BT
a
a.bina_br.bin
Vertical-transform matrix

[(X−1)T]T = A(0)T
b
b.binb_br.bin
Horizontal-transform matrix without regularization

[(X XT + 20·I)−1 X]T = A(20)T
b2
b2.binb2_br.bin
Horizontal-transform matrix with regularization parameter = 20

All calculations are performed with folded images (1 quadrant for "2D", one half for "1D"), so the matrices above correspond to 1 quadrant (no vertical transform is done for "1D").

The regularization parameter (I'll call it "reg") corresponds to q12.

There are precomputed regularized matrices, which are used when reg = 20.0 is requested, although this does not seem to increase the speed noticeably.
(This reg = 20 is also different from q12 = 50 or 5 in the article.)

The regularization is never applied to the vertical transform. This makes the vertical-transform computations quite pointless, since mathematically the whole chain raw → Ci → reconst_image is an identity transform (vertically).
The speed and anisotropy distributions for "2D" are calculated from the coefficients matrix (and explicit basis function), but this is unlikely to be any better than using the reconstructed image, especially for basis functions broader than 1 pixel. The distributions for "1D" are calculated from the reconstructed image, so Ci is not used.

Important conclusions from my previous comment are:

No vertical regularization should be used.
The vertical transform is not needed at all.
My reg does correspond to the "regularization parameter" in BASEX.

So I've done 1. and 2., plus combined the horizontal transform into a single matrix. The speed has improved a lot:

The results now are not bitwise equal the old ones, since the operations are performed differently, but they are within the numerical precision: the maximal intensity discrepancy is ~10−14 of the maximal image intensity.
But, as @DanHickstein has pointed out, this implementation transforms full-width images. This does not give any advantages, but only makes is slower. I think, we should switch to a half-width transform, like in BASEX.

Well done Mikhail! It is great to know exactly how Basex.exe operates, and I'm very glad that you have figured out the issues with the vertical transform and vertical regularization.
At this point, I think that it is clear that you now have an excellent understanding of the basex code. You should feel free to edit the code as extensively as you like. I have never been completely happy with our basex implementation, because the old variable names and weird structures have been transferred from the legacy Matlab code, when it would be much better to directly connect the variable names to the published paper.
A few responses to your specific points:

The code is written poorly. There are no comments except very few in Main.h, which are also misleading.

Ha! Well, the current basex.py in PyAbel could probably use more comments as well.

The martices are transposed with respect to the article, and thus are multiplied backwards.

Gosh, that does seem really confusing!

The basis sets and other matrices were apparently generated in Matlab, since there is no C++ code for them. But there is no Matlab code either.

As far as I can tell, the basis sets were generated using Matlab code. You actually sent me this matlab code, as part of a big folder of BASEX-related matlab scripts back in 2011, which spawned PyAbel :). I believe that the relevant script is "basis2.m".

The correspondence (hopefully, correct) between the article and code notations and the files

This is great! Should we consider changing our notation to better match the manuscript?

There are precomputed regularized matrices, which are used when reg = 20.0 is requested, although this does not seem to increase the speed noticeably.

So, with basex.exe, any regularization factor is possible, but reg=20.0 offers enhanced speeds? This is indeed very strange.

But, as @DanHickstein has pointed out, this implementation transforms full-width images. This does not give any advantages, but only makes is slower. I think, we should switch to a half-width transform, like in BASEX.

Oh, are the BASEX transforms still performed on the full image? Yes, it would be great to switch to the half-width image if possible, since this best matches the other transform methods and should provide the best performance.

Thanks, @DanHickstein! I'll then proceed to converting everything in abel.basex to half-width.
By the way, I was thinking about extracting basis sets for smaller images from a larger cached basis, if it is available, which should avoid this ridiculously long basis computation in most cases. I suspect that this can be done simply by slicing the array (discarding the outer part), but even if there are fringe effects, they could be treated much faster than a full basis computation. Moving to half-width operation should also make this easier.

Should we consider changing our notation to better match the manuscript?

I would like, but there are two problems. First, that transposition (the article convention is bad). Second, I don't like using Z for the image basis (in the r direction!). I would use B and Bp for the basis and its projection, but B is already used in the article for a different purpose. So my thoughts are to leave the current notation (it is at least compatible with the Matlab and C++ implementations) and explain in the comments what is what. If there are no better ideas...

As far as I can tell, the basis sets were generated using Matlab code. ... I believe that the relevant script is "basis2.m".

Partially. That script saves them as text files and does not produce mm, a, b and b2. The closest candidate is "makebasis1.m" (using the results of "basis2.m"), but it is still not what was used.

And a long-promised comparison of regularization effects.
Images ([−5, 5] scale):

Speed distributions:

As can be seen, reg ~ 200 (in this case) almost completely removes the axial noise from the image and has a negligible effect on the extracted distribution. At reg ≳ 1000 the image starts to blur.
While regularization reduces the image noise, it almost does not reduce the speed noise because:

The largest image noise is near the axis, where sin θ → 0.
The noise has nearly zero average, so its integral is small.

That is, "denoising" the speed distributions requires relatively strong regularization (another example with reg = 1000 can be seen in my dissertation, Fig. 3.10), but for those who needs the images themselves, rather than their integral characteristics, even moderate regularization is a big advantage.

Thanks, @DanHickstein! I'll then proceed to converting everything in abel.basex to half-width.

Well, that's just great news!!

By the way, I was thinking about extracting basis sets for smaller images from a larger cached basis, if it is available, which should avoid this ridiculously long basis computation in most cases.

Interesting! If that works, then it would be fantastic. We could simple generate the 1000x1000 baiss set once and then crop all smaller sets from it. Another crazy idea: now that we have scrapped the vertical transform, does that mean that we can generate the basis set for a 1D transform and then somehow copy this into a larger matrix?

I would use B and Bp for the basis and its projection, but B is already used in the article for a different purpose. So my thoughts are to leave the current notation (it is at least compatible with the Matlab and C++ implementations) and explain in the comments what is what. If there are no better ideas...

I suppose the alternative would be to write our own explanation of the math and follow those conventions. At a minimum, as you say, we should explain in the comments what everything is.

The closest candidate is "makebasis1.m" (using the results of "basis2.m"), but it is still not what was used.

Oh, that's interesting. Kinda sketchy that the origin of the calculated basis sets is completely unknown for basex.exe :)

And a long-promised comparison of regularization effects.

Fantastic! What colormap did you use?
And this is fairly convincing evidence that strong noise suppression is possible with minimal broadening of sharp features. This is clearly a big advantage of the BASEX method, and I'm really happy that we are finally getting this feature into PyAbel. Thank you so much!

Back from my travels :-(
Very nice coding and some clever ideas @MikhailRyazanov!
My only concern (discussion point) is that global basex basis arrays remain even when the basex method is no longer used. This may not play well with the other Abel transform methods operating on large image sizes.
BTW, long is not part of python3:
 205     elif isinstance(nbf, (int, long)):

Any chance that you can implement the anisotropy parameter calculation that was available in the original basex program?

extracting basis sets for smaller images from a larger cached basis

This is neat. I think this approach may also apply for the Dasch method basis calculation.

My only concern (discussion point) is that global basex basis arrays remain even when the basex method is no longer used.

Well, if we had Transform creating an object, they would be killed with it. ;–)
With the half-width transform, a 1023×1023 image requires three 512×512 arrays, which is 6 MiB + Python/numpy overhead. I think, this is not a big problem. But I can add a cleanup=False parameter to abel.Transform() and abel.basex.get_bs_basex_cached(), such that those who care could specify cleanup=True to get rid of these arrays. Then other methods that need caching can honor it as well.

BTW, long is not part of python3

Do we actually need that stuff? Non-"auto" bases never worked, I do not have plans to implement them (I do not really know the details, and "broad" bases are relatively useless), and it is unlikely that anybody will soon. The removal of the vertical transform has already changed the calling conventions (not the default ones, but it broke some tests), so maybe we should ignore nbf also (completely remove it or print a warning "not used", if compatibility is needed)?

Any chance that you can implement the anisotropy parameter calculation that was available in the original basex program?

It was painfully slow (~40 seconds on my computer). I think, calculating it from the reconstructed image using a common procedure is better in every sense.

With the half-width transform, a 1023×1023 image requires three 512×512 arrays, which is 6 MiB + Python/numpy overhead. I think, this is not a big problem. But I can add a cleanup=False parameter to abel.Transform() and abel.basex.get_bs_basex_cached(), such that those who care could specify cleanup=True to get rid of these arrays. Then other methods that need caching can honor it as well.

Yeah, I agree that it's probably not a huge problem, except if people are running benchmarks or something. I like the idea with cleanup=False.

so maybe we should ignore nbf also (completely remove it or print a warning "not used", if compatibility is needed)?

Wider basis sets worked in basex.exe, right? This seems like it might be useful for some people, so I am holding out hope that this eventually gets implemented. But yes, in it's current state, a warning or error should be raised.

It was painfully slow (~40 seconds on my computer). I think, calculating it from the reconstructed image using a common procedure is better in every sense.

Yeah, this also seems fine to me as well. @stggh, in the case of linbasex, it makes sense to extract the anisotropy directly from the functions, since the broad functions closely resemble the photoelectron/photoion distributions. I don't think that we would see the same advantage when using narrow gaussian functions.

if we had Transform creating an object

It does ;-). But I get your point. We decided to keep each PyAbel transform as a function to facilitate independent (of PyAbel) use. A wrapper class would nice, but this is not relevant for your excellent(*) basex/PR improvements.

cleanup=True to get rid of these arrays

A good solution. I often transform 8192x8192 pixel images from good quality (signal/noise) experimental photoelectron measurements.

reconstructed image using a common procedure is better

Photoelectron people (aka Dan Neumark UCB) like to publish a continuous intensityXanisotropy parameter plots. In PyAbel this is only available using linbasex, a method, which at the moment, produces a poorer resolution transform cf the other transform methods e.g. example_anisotropy_parameter.py:

Once can cheat the product by using a higher resolution intensity from another method. However, this is not ideal. I agree that in the end, extracting anisotropy parameters from the reconstructed image is better.
One minor basex issue. The first two pixels (columns) of the transform are bad. e.g. 1-D profile 8:

import abel
import matplotlib.pyplot as plt

f = abel.tools.analytical.TransformPair(101, 8)

b = abel.basex.basex_transform(f.abel, dr=f.dr)
t = abel.dasch.three_point_transform(f.abel, dr=f.dr)

plt.plot(f.r, f.func, label='source')
plt.plot(f.r, b, 'o', label='basex')
plt.plot(f.r, t, label='three_point')
plt.legend()
plt.title(f.label)

plt.savefig('profile8.png', dpi=75)
plt.show()

PS: (*) Now that basex is fast, and will be faster with 1/2-image processing, it nicely complements three_point. Here is a higher resolution (4096x4096 pixel) of the O2- photoelectron spectrum:

I have updated #227, switching to the half-width approach.
Now even for a full image (4 independent quadrants) it works faster than the BASEX program (≲1 s on my computer) and reproduces its results for symmetrized images (within that mystic scale factor).
I think, I'm satisfied with this regularization stuff now, so could you please review #227 and run all the tests? (I'm very interested in the efficiency comparison.) Then it would be nice to tidy up and merge it, and close this issue.
I'll then handle cache cleanup and basis cropping in #226 separately.
I also have the forward transform, but that's another story...

@DanHickstein,

Wider basis sets worked in basex.exe, right? This seems like it might be useful for some people, so I am holding out hope that this eventually gets implemented. But yes, in it's current state, a warning or error should be raised.

There was only one "wider basis set", and yes, it worked. But I do not know whether anybody used it. I suspect that using wider on narrower (with regularization, you can have more basis functions than pixels) basis sets is equivalent to resampling the images. Anyway, I'm leaving nbf as it is now. Maybe long should be removed (@stggh should know better).
@stggh,

I often transform 8192x8192 pixel images

If there are such brave people to wait for the basis generation... :–)

... produces a poorer resolution ...

In principle, images must have no features sharper than ~2 px (if we consider that Abel = Fourier−1 Hankel, then this is a requirement of the sampling theorem). If linbasex underperforms, and there is no general method yet, I would rather implement it than what BASEX had.

One minor basex issue. The first two pixels (columns) of the transform are bad.

Probably due to something in the basis and its projection. Since the axial pixel is actually a half-pixel, it needs a special treatment, and I'm not sure that this was done correctly. Perhaps, open another issue for implementing nbf ≠ n and investigating r = 0?

And a long-promised comparison of regularization effects.

Fantastic! What colormap did you use?

'seismic':

I also have the forward transform, but that's another story...

I'm interested in this story :)

Basically, exchanging M and Mc produces the forward transform. I just need to look how the forward/inverse selection is done in the other methods and code it accordingly.
But let's finish with this issue first.

@DanHickstein, thanks for merging #227!
Perhaps, this issue can be closed now?

Sounds good. Mission accomplished!

And a big THANK YOU to @MikhailRyazanov for implementing this!


import error: HTMLParser in Python 3

In Python 3 is HTMLParser in html.parser
So to prevent import error I had to change in cli/dict.py:
line 16: import HTMLParser from html.parser import HTMLParser
line 27: pars = HTMLParser.HTMLParser() pars = HTMLParser()

Thanks for the report. This should be fixed by #6. I'll hopefully push a new version to PyPI this evening.

Just one more thing (I don't want to make new ticket for that):
cli/__init__.py line 55: jsonstring = json.dumps(records, indent=2, ensure_ascii=False).decode('utf-8')
This prevents the AttributeError: 'str' object has no attribute 'decode'


Make TypeMappings self-contained (for SQL literal generation)

This fixes the scoped-down part of #7434 - see this comment - which addresses making SQL literal generation the sole province of the RelationalTypeMapping class (and no longer part of ISqlGenerationHelper).

Checked in with commit 4b8b12d01.


Run nodejs-jwt-authentication-sample and angular2-authentication-sample  in one webpack.config.js is possible?

I would like to run this program in single file. I need run two ports 3000 and 3001. These be ports necessary for sample login and authentication sample.  Any sugestion?

added npm run server in #38
if tooo lazy to run 2 terminals use npm run server & npm start :)


Implementing biased decoding and tagging words

Hello, thanks for the great work! I am currently learning about Torch, and I am using your model for my high school project, which is to teach the model how to add missing punctuation into sentences.
Right now, I am trying to implement biased decoding such that the decoder only considers either punctuation or the original word (so it doesn't replace it with weird words and stuff). There is an example of this done in TensorFlow here. However, after reading through your code, I am still unsure about how to do this in Torch. Also, I was wondering if it is possible to add tags/features to words, as I am trying to add POS tagging to improve the model (is this called tokenisation?). Is it possible for you to provide some advice? Any help will be much appreciated :)

Yes, it is possible to bias decoding.
Let's say you never want to predict "the", and further assume that this is index 10 in the vocab (check out the *.dict file to get the index).
Then you want to add the following in your beam search code after loading the model:
generator = model[3]
generator.modules[1].bias[5] = -10-e9
Hope this helps!
It is also possible to add tags/features to words. Check out OpenNMT, which makes this much easier http://opennmt.net/

Okay, but what if I never want to predict any word except for let's say, the original input word, and a comma. Is there a cleaner way to do this?

Sure, checkout the State.disallow function in beam.lua
function StateAll.disallow(out)
local bad = {1, 3} -- 1 is PAD, 3 is BOS
for j = 1, #bad do
out[bad[j]] = -1e9
end
end
you can modify it to take in a table of tokens, rather than using a fixed 'bad' set

I took a look at it, but seems like this 'bad' set is the set of words I don't want the system to output. But in my case, I instead would like there to be a 'good' set of words that the system can only output. So instead of listing out all the words I don't want in a 'bad' table, I want to list out the only words that I want in a 'good' table (which there are only about 10 or so), and let the model pick from there. Can this be done?

Yes. For each sentence, initialize a vector like
good_words = torch.zeros(V):fill(-1e9)
and then modify the indices of this vector to zero for the ' good words'
Then add this vector to your beam scores at each step of decoding.


refactor: move all register_simp_attrs to 1 file

There are slight differences between mathlib3 and mathlib4 (different set of attributes, different lemmas are in core/std), so I redid the same refactor instead of forward-porting changes.
mathlib3 PR: leanprover-community/mathlib#19223

bors merge


GH1422: Add support for Unicode globbing

I've added Unicode support to the Globber by rewriting the GlobTokenizer. This fixes https://github.com/cake-build/cake/issues/1422

Tokens are lazily loaded into a queue
GlobTokenizer now specifies 'non-identifier characters' rather than 'identifier characters'
Globbing is 15% faster
Unicode supported

@tom-dudley,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla2.dotnetfoundation.org.
It will cover your contributions to all .NET Foundation-managed open source projects.
Thanks,
.NET Foundation Pull Request Bot

@tom-dudley, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.
Thanks, .NET Foundation Pull Request Bot

If the OS X bitrise error is genuine (I read elsewhere you might be having issues with bitrise), could you make the output publicly viewable or let me know what the failure was? Thanks!

@tom-dudley I took a look at it and it doesn't seem to be related to your changes.

@tom-dudley @patriksvensson reran the Bitrise Mac Build and it completed successfuly

@tom-dudley Thanks for taking this issue up!

@tom-dudley  your changes have been merged, thanks for your contribution 👍


selected date as Nullable

I was trying to use selectedDate, but at some point at time, that property was nil. I couldn't prevent the crash since when ported to Swift, that property is of the type NSDate instead of NSDate?

Hi @danielCarlosCE
Before selectDate:date, make a optional binding
if let dateNonNull = yourDate {
    calendar.selectDate(dateNonNull)
}

That's what I did, thanks. However, wouldn't be better knowing in compile time? I didn't know it could be nil until I actually got an error in run time.

Of course it's a compile-time stuff. There is already a nonnull prefix.

Hello, I am wondering why is selectedDate Date type, instead of optional Date (Date?). I am running to run time error, when user hasn't selected any date (or after calling deselect(_:)) and the selectedDate property is crashing my app.
I would use optional binding to check if there is selected date or not, but there is no optional to bind.

That was my point @ashhanai . I only find out that it could be nil when my code broken on production.

So if I understand it right, if I filter items depending of selected date, I cannot let user not to select any date, right? And if I ask for selected date and user doesn't have any, it will crash.
My proposal is to make selectedDate optional as it can be nil, when user does not have any selected date.

@ashhanai The crash has been prevented. But I'll make it optional, thanks for the proposal:)


Document new colors

The following colors need to be documented at https://raw.githubusercontent.com/microsoft/vscode-docs/vnext/api/references/theme-color.md

[ ] "button.border: Button border color." @aeschli
[ ] ~"editorInlineHint.foreground: Foreground color of inline hints" @jrieken~
[ ] ~"editorInlineHint.background: Background color of inline hints" @jrieken~
[x] "toolbar.hoverBackground: Toolbar background when hovering over actions using the mouse" @joaomoreno @roblourens
[x] "toolbar.hoverOutline: Toolbar outline when hovering over actions using the mouse" @joaomoreno
[x] "toolbar.activeBackground: Toolbar background when holding the mouse over actions" @joaomoreno @roblourens
[ ] ~"workspaceTrust.trustedForegound: Color used when indicating a workspace is trusted." @sbatten~
[ ] ~"workspaceTrust.untrustedForeground: Color used when indicating a workspace is not trusted." @sbatten~
[ ] ~"workspaceTrust.tileBackground: Background color for the tiles on the Workspace Trust page." @sbatten~
[x] "ports.iconRunningProcessForeground: The color of the icon for a port that has an associated running process." @alexr00

removing myself because the inlineHint colours aren't consumable yet

same for me, the trust options need work

FYI @jrieken @sbatten -- the endgame plan contains a bullet point that asked me to create this issue. It is very likely that the next endgame champion will ping you again (unless the tool is adjusted somehow).

I know. You are not the first endgame master to ping me 😄


Failing at basic multirepo use

Trying to add changesets in a pnpm monorepo. I did:
> pnpm add -D @changesets/cli
> pnpm changesets init
> pnpm changesets

But it only wants to publish the root package.json (which is just the monrepo root, not a package), which is set to private: true.
Everything suggests changesets is meant to thrive in multi-package repos. So what I am I missing?

You probably have a version in your package.json. changesets will try to version anything with a version, even private packages, unless you set the "privatePackages": false option in your config.json, which would cause it to ignore private packages regardless of the presence of a version.

@altano trying any of those options causes this error:
📂 azoth 🚀 pnpm changeset
🦋  error TypeError: Cannot read properties of undefined (reading 'packageJson')
🦋  error     at createChangeset (/Users/marty/dev/azothjs/azoth/node_modules/.pnpm/@changesets+cli@2.27.1/node_modules/@changesets/cli/dist/changesets-cli.cjs.js:392:75)
🦋  error     at add (/Users/marty/dev/azothjs/azoth/node_modules/.pnpm/@changesets+cli@2.27.1/node_modules/@changesets/cli/dist/changesets-cli.cjs.js:506:26)
🦋  error     at async run (/Users/marty/dev/azothjs/azoth/node_modules/.pnpm/@changesets+cli@2.27.1/node_modules/@changesets/cli/dist/changesets-cli.cjs.js:1304:5)
📂 azoth 🚀 pnpm changeset
🦋  error TypeError: Cannot read properties of undefined (reading 'packageJson')
🦋  error     at createChangeset (/Users/marty/dev/azothjs/azoth/node_modules/.pnpm/@changesets+cli@2.27.1/node_modules/@changesets/cli/dist/changesets-cli.cjs.js:392:75)
🦋  error     at add (/Users/marty/dev/azothjs/azoth/node_modules/.pnpm/@changesets+cli@2.27.1/node_modules/@changesets/cli/dist/changesets-cli.cjs.js:506:26)
🦋  error     at async run (/Users/marty/dev/azothjs/azoth/node_modules/.pnpm/@changesets+cli@2.27.1/node_modules/@changesets/cli/dist/changesets-cli.cjs.js:1304:5)

I spent a little time debugging, but it goes through a lot of node/babel polyfill code and is hard to do so from the dist module. But it looks like it is only finding one package initially, then failing when it gets here.

@martypdx if you post a repro on stackblitz I’ll try to help.

I'll close this based on the last comment's error, which is tracked at https://github.com/changesets/changesets/issues/841


Replace generators with an iterator class

Closes: https://github.com/GoogleCloudPlatform/google-cloud-php/issues/342
Example:
use Google\Cloud\Storage\StorageClient;

$storage = new StorageClient();
$bucketsIterator = $storage->buckets(
    'maxResults' => 5 // The number of results per page
    'resultLimit' => 10 // The number of results returned in total **new**
    'pageToken' => null // Set this to the value of a previously retrieved token to resume iterating from a specific point **new**
);

// Iterate by each item (bucket) in the project
foreach ($bucketsIterator as $bucket) {
    var_dump($bucket->name());
}

// Or iterate by page
$bucketsPageIterator = $bucketsIterator->iterateByPage();

foreach ($bucketsPageIterator as $page) {
    foreach ($page as $bucket) {
        var_dump($bucket->name());
    }
}

// Get the next result token
$nextToken = $bucketsIterator->nextResultToken();

I'm letting travis run again against the doc changes I made in #400.


keyboard conflict in multi-local user in Windows

VSCode Version: 1.52.1 (system setup)(ea3859d, 2020-12-16T16:34:46.910Z)
OS Version: Windows_NT x64 10.0.19041

Steps to Reproduce:

open a project in vscode in a windows user
open another project(not the same) in vscode in another windows user
both two of the vscode project can not use keyboard, including typing, shortcuts, even win command in vscode. But keyboard still works under other situations.

Does this issue occur when all extensions are disabled?: Yes/No
Did not test it when all extensions are disabled

I am not sure that the problem is related with Win10 or vscode

I am not sure that the problem is related with Win10 or vscode

cc @deepak1556 - are you aware of any global concept that would prevent multiple Windows users from running VS Code in parallel?

I finally had a chance to try this out. I could log in at the same time with two different windows accounts and launched vscode (installed as a system setup) for both users and I could type.


Fixing a couple type problems. (adding py.typed, typing connect, returning Any from fetchall (which I failed to fix!))

I'm trying to use databricks-sql-python in a statically-typed python project, and I'm running into some issues. I'm using mypy --strict.

Despite this project having type annotations, my typechecker (mypy) will not check them (this causes problems for the type implications of the rest of my code). I'm pretty sure that, as per https://peps.python.org/pep-0561/#packaging-type-information, you can just add a py.typed file to the sql/ and sqlalchemy/ folders. I don't use the sqlalchemy side so I haven't tested that, but the sql one seems to work perfectly when I modify the copy of databricks-sql-python on my machine.

I get error: Call to untyped function "connect" in typed context  [no-untyped-call]. I'm pretty sure you can just change the type signature of def connect in the sql folder's __init.py__ to def connect(server_hostname, http_path, access_token=None, **kwargs)  -> "Connection". This works perfectly when I test it on my machine.

I get error: Returning Any from function declared to return "List[Row]"  [no-any-return] when I have the line  return cursor.execute(query, sql_params_dict).fetchall(). Honestly, I have no idea how to fix this. fetchall looks like it has the right type signature to me! Maybe this is a bug in mypy somehow? Or maybe this is a symptom of the previous issue not getting completely fixed...

I can make a pull request about this, at least the first two, but maybe these ideas are bad and you haven't done them yet because it would break something else; let me know!

I realized error №3 here was not fixed by solving №s 1 and 2, but also I realized what was causing it, leading to my fix in #384

Since #382 and #384 have been merged, I'm fairly certain this problem is completely fixed. 🎉


Merge Analytic updates into Maple release.

Merge in these PR changes:

[x] #1
[x] #2
[x] #4
[x] #5
[x] #6

Verified that this is working on devstack maple.1 environment.


Layer Z Script causing some units not to be added to the Freestore, perhaps causing assertion errors

Hello Kad,
I'm Creating an issue as referenced on the Discord channel.
Apparently the script is causing some units not to be added to the FreeStore, Some units will spawn from Hyperspace but stay behind and not attack the player.
The problem is resolved after removing the script all together.
The script seems to also be causing some assertion errors - unsure if these are related but mentioning them since the latest update removed the PLAYER_NEUTRAL references.
Please let me know if any further info is needed
Thanks!
[0x00004170] 03-07-2024 04:26:52,251|    *** ASSERTION FAILURE ***
[0x00004170] 03-07-2024 04:26:52,251|    Assertion failed!
Program: F:\Program Files (x86)\Steam\steamapps\common\Star Wars Empire at War\corruption\StarWarsI.exe
File: C:\BuildSystem\AB_SW_STEAM_FOC_BUILDSERV04_BUILD\StarWars_Steam\FOC\Code\RTS\GameObjectType.cpp
Line: 2471
Expr: faction != NULL

Stack:
[0x00004170] 03-07-2024 04:26:52,251|    *** ASSERTION FAILURE ***
[0x00004170] 03-07-2024 04:26:52,251|    Assertion failed!
Program: F:\Program Files (x86)\Steam\steamapps\common\Star Wars Empire at War\corruption\StarWarsI.exe
File: C:\BuildSystem\AB_SW_STEAM_FOC_BUILDSERV04_BUILD\StarWars_Steam\FOC\Code\RTS\GameObjectType.cpp
Line: 2471
Expr: faction != NULL
[0x00004170] 03-07-2024 04:26:52,258|    Adding file .\Data\Scripts\GameObject\ObjectScript_SpaceGeneric_Multilayer.lua
[0x00004170] 03-07-2024 04:26:52,258|    *** ASSERTION FAILURE ***
[0x00004170] 03-07-2024 04:26:52,258|    Assertion failed!
Program: F:\Program Files (x86)\Steam\steamapps\common\Star Wars Empire at War\corruption\StarWarsI.exe
File: C:\BuildSystem\AB_SW_STEAM_FOC_BUILDSERV04_BUILD\StarWars_Steam\FOC\Code\RTS\GameObjectType.cpp
Line: 2471
Expr: faction != NULL ```

Is the crashing still an issue? I've only skimmed over the discord, but it seems to be a different problem. If it is cause by this library, I'll open a seperate ticket for that.

Apparently the script is causing some units not to be added to the FreeStore, Some units will spawn from Hyperspace but stay behind and not attack the player.

I feared that would happen with the fix for the pop-cap issue - I'm not 100% positive both can be resolved at the same time but I'll look into it some more.
I'll also try to get a hold of someone at Petroglyph to shine a light on why this could be happening - I assume it has something to do with order of execution.


Update for PureScript 0.11

@garyb this PR can also be merged?

Not quite, there's some changes to come yet.

@paf31 Ok, just pushed a pretty big update...

Dropped IsForeign as discussed variously
Removed the newtypes for null / undefined / etc in favour of just providing functions that can be specific about what they read instead - the newtypes only existed to guide the chosen IsForeign implementation before.
Removed parseJSON since that's highly misleading about what this library is for (it exists in support code for the examples though, as it makes them easier to read rather than having the example values being parsed in a separate JS file in each case)
Added a new !! operator that allows chaining of property reads, so you can do value ! prop1 !! prop2
Updated all of the examples accordingly


Add godoc badge to README.md

There currently isn't a link to the documentation in the README

Thanks for the contribution, @ooesili! Merging this in.
Thanks,
Eric, CF Runtime Diego PM


Endpoints needed for Atomic Swaps

https://github.com/block-core/blockcore-atomic-swaps/issues/11

I write the endpoints inputs and outputs here
I believe I need the following
Login
This exists and is called signmessage it return a key (the address)
Now I have added to return a pubkey, however if we want to to conform to the BCIP we need to be able to provide a path or create a new sign in endpoint
I also propose that we will return in the signmessage the
  walletId: string;
  accountId: string;
  keyId: string;

This is so future calls (like get balance for an account can pass those params and not let the user pick them)
Balance
idea: make it more generic and call this getinfo that can return balances or trxid or trxhex etc...
Balance will return the balance of that account
Input : { walletId, accountId }
Output : { balance }

Send
Send funds to a given address (or addresses)
(do we need to also specify walletId, accountId?)
Input : { target[{address, amount}], fee (high,medium,low)}
Output : { trxid }

Optional params to consider on the input
Input : { network(do we need this?), data(opreturn), walletId, accountId }

Spending the swap trx
This is a special case we have two options somehow build the special swap script in the wallet itself or enable the wallet to sign an input
To get an idea of the complexity of building the swap spend trx look here
https://github.com/block-core/blockcore-atomic-swaps/blob/main/src/Blockcore.AtomicSwaps/Shared/SwapBuilder.cs#L71
An idea I have is that we could potentially make an api endpoint that return the swap special private key and do the signing in the dapp, and give the user extra warnings about this operation.
The risk is lower because if we implement the BCIP then the private key is hardened and if leaked only open swaps are potentially compromised (assuming the attacked has the secret hash)
out of the 3 options here are the inputs

build the swap trx in the wallet

Input : { redeemscript, sharedSecret, outpoint (or swap trxid that has the outpoint), swap-pubkey, target-address,}
Output : { trxid }

sign swap input

Input : { pubkey, sighash, SigHashType}
Output : { signature}

return the special swap private key

Input : { pubkey, }
Output : { privatekey}

Derivation of the secret hash
The secret hash need to be a random number, however if we are able to have access to the private key then we can derive the secret hash in a deterministic way (which can be useful for recovery)
If we go for the option of asking for the private key this is not an issue, however otherwise we can add an endpoint to sign the session id and hash that (I think this can potentially be achieved already with the signmessage endpoint.

Another endpoint we could potentially get and then not use the send endpoint is to fetch UTXOs and then call the sign method
Or to pass to the wallet an unsigned trx and have it sign the inputs
Doing this will give the swaps dapp more flexibility

I that I have one more requirement, there are two methods that do not require consent (no popup)
atomicswaps.key - return the swaps derived pubkey
atomicswaps.secret - generate a secret hash using the swaps key
However when the wallet is locked this is not possible, I suggest when those methods are called if the wallet is locked we must initiate a wallet popup to unlock the wallet.
Why is it without consent? during a swap I may need to call a wallet a few times, the UX will be horrible if a user has to approve a few popups one after the other

One more to the list
https://github.com/block-core/blockcore-atomic-swaps/issues/32


DUOS 673 Remove user details from darInfo & describeDar refactor

Addresses DUOS-673
Basic premise is to extract user details out of darInfo and rely on the data returned from ResearcherProfile. Additional changes also include removing dependency on the modal summary endpoint and instead using the v2 DAR GET and User GET endpoints as well as adding additional helper functions and details to the dataUseTranslation file to define purpose statements and researchTypes so that the back-end does not have to (nor should it, data presentation is a front-role responsibility)
Have you read Terra's Contributing Guide lately? If not, do that first.
I, the developer opening this PR, do solemnly pinky swear that:

[x] PR is labeled with a Jira ticket number and includes a link to the ticket
[x] PR is labeled with a security risk modifier [no, low, medium, high]
[x] PR describes scope of changes

In all cases:

[ ] Get a minimum of one thumbs worth of review, preferably 2 if enough team members are available
[ ] Get PO sign-off for all non-trivial UI or workflow changes
[ ] Verify all tests go green
[ ] Squash and merge; you can delete your branch after this
[ ] Test this change deployed correctly and works on dev environment after deployment

I recently added commits to correct some errors I made when processing the researcherType statements (The statements under "Types of Research" in ApplicationSummary), so I'd appreciate a re-review of those changes. Thanks!


Disable welcome screen

I'd like to disable the opening of the welcome screen when gitlens is first executed. I'm operating a fleet of temporary vscode installation and users always get this screen when opening vscode.
Is there a way to achieve that?

I have a similar problem, but I'm in the cloud IDE！
The cloud IDE will always init a new instance, and the welcome page  of gitlens installed before  will show again.

how about to prevent the welcome page?

@Tony7lee How can I do this? I've add "workbench.startupEditor":"none" to my settings.json already, but still popup the "Welcome To GitLens" everytime.

I added a PR that fixes this, adding a new setting to disable all "advertising" pages.

I changed the setting to be gitlens.showWelcomeOnInstall and only affect the welcome experience on the first install. If you also want to disable the What's New notification you will also need to change the existing gitlens.showWhatsNewAfterUpgrades setting.
Can you please verify this fix in tomorrow's insiders edition? Be sure to disable/uninstall the stable version of GitLens first.
You can install the insiders edition from here.


Misc release notes improvements

Contributors list
UX improvement for release notes tasks
Update to release notes template

Your PR is queued. See the queue page for details.

I've triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test BD

@bot-gradle test and merge

I've triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

I've triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

I've triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

I've triggered a build for you.


Monitoring Polishing

Deployment page:

[x] Separate chart options into the following Tabs:

General Config Tab

Prometheus Tab

Alerting Tab

Grafana Tab:  Add Grafana storage as a H3

~- [ ] Add in the new advanced fields, then have Lauren do a overhaul on the styling and see if certain checkbox can be grouped together better~ Advanced has own tickets

Overview:

[x] A table of active alerts below the links

[x] Need to have a consistent page title with the navigation

Prometheus Rules:

[x]  Switch the box around the rules to use the standard component ("array list groups")
~- [ ]  PromQL Expression:~
~-  H4 label with codeMirror~

on 2.5-head (3d62d5d) I was able to verify the following after creating monitoring v2 (v9.4.202) on a cluster:

separated chart options

Note: did not see Add Grafana storage as a H3 but possibly this meant configure grafana?

table of active alerts on overview page (in Monitoring tab)

page title matched dashboard home page

array-list-group used when creating new prometheus rules through rancher UI

on 2.5-head (3d62d5d) I was able to verify the following after creating monitoring v2 (v9.4.202) on a cluster:

separated chart options

Note: did not see Add Grafana storage as a H3 but possibly this meant configure grafana?

table of active alerts on overview page (in Monitoring tab)

page title matched dashboard home page

array-list-group used when creating new prometheus rules through rancher UI

from the above, it sounds like configure grafana should be a level above Persistent Storage for Grafana, but here they appear on the same level.

from the above, it sounds like configure grafana should be a level above Persistent Storage for Grafana, but here they appear on the same level.

@slickwarren I believe that item was for two things, sorry its not more clear. We added the Grafana section to its own tab AND I believe the label was supposed to change from Persistent Storage for Grafana to Grafana Storage. I moved the section to its own tab but I missed changing the label. I will open a new pr for that.

@slickwarren I believe that item was for two things, sorry its not more clear. We added the Grafana section to its own tab AND I believe the label was supposed to change from Persistent Storage for Grafana to Grafana Storage. I moved the section to its own tab but I missed changing the label. I will open a new pr for that.

@westlywright this now has the label changed, thanks! Just curious, is the `Configure Grafana` section a sort of place holder that will have vars to fill later on? Looks a little odd as-is, since there are 3 titles stacked together.

@westlywright this now has the label changed, thanks! Just curious, is the `Configure Grafana` section a sort of place holder that will have vars to fill later on? Looks a little odd as-is, since there are 3 titles stacked together.

@slickwarren Yes, the label more matches consistency with other tabs right now but in the future there should be additional configuration options in here.

@slickwarren Yes, the label more matches consistency with other tabs right now but in the future there should be additional configuration options in here.


Change color scheme of website

I am not sure I like the current colors used.

Changed background colors to light blue.


ITunes feed.entry can be object, if app has only one review.

Hi, seems like Apple can return an object, if application has only one review.
You can test it with app below at this moment.
store.reviews({
      id: '1405670215',
      country: 'ru',
      sort: store.sort.RECENT,
      page: 1
    })

Also, i have a question, what's purpose for slice(1)? I found that apple returns correct array with reviews, or is there something tricky?

@facundoolano seems like test fail not related to fix.

After further checking, it looks like the slice(1) is not doing anything other than skipping the first review. This is probably an historic artifact from the first implementation, I'm removing this from master.


Fixes queries that have multi-select inputs

TODO: tests

[Current coverage][cc-pull] is 97.13% (diff: 80.00%)

Merging [#8][cc-pull] into [master][cc-base-branch] will decrease coverage by 0.32%

@@             master         #8   diff @@
==========================================
  Files             2          2
  Lines           275        279     +4
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            268        271     +3
- Misses            7          8     +1
  Partials          0          0

Powered by Codecov. Last update [8d868b5...7242e64][cc-compare]
[cc-base-branch]: https://codecov.io/gh/TriOptima/tri.query/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/TriOptima/tri.query/compare/8d868b5dac88b78eaf2aeb5f27b41b6fc1d31d76...7242e64409cb1a3211015356001851b76012e418?src=pr
[cc-pull]: https://codecov.io/gh/TriOptima/tri.query/pull/8?src=pr


[TRI-321] Better handle errors bubbling up in subtasks

Currently when viewing a failed task because a subtasks threw an error is not a great experience. We need to improve that
When a subtask fails (and all retries are done) the error doesn't bubble up to the parent task. Instead you get a very generic: "Error: Task errored at IO.runTask".
Instead, a failed subtask should bubble that error up to parent tasks (so the subtask error is duplicated onto the parent).
You can easily reproduce this by creating a task with subtask inside that throws a specific error.
From SyncLinear.com | TRI-321

/bounty $50

@ericallam would it be possible to get more information about what the bad experience is and what the expected experience should be?

/attempt #159

@ericallam Can I work on this one? Can you elaborate the issue?

@ericallam would it be possible to get more information about what the bad experience is and what the expected experience should be?

@matt-aitken @ericallam
Would it be possible to get more information about what the bad experience is and what the expected experience should be?

I've added more information to the original issue

@RamK777-stack would you like to claim the Algora bounty?

Yes @matt-aitken

claim #159

This was fixed


Prefer MediaQuery over checking web platform

Right now this hardcoded to kIsWeb here.
If we instead use a call to MediaQuery.of(context).size < 800 or something similar, it can also work on the iPad and other desktop platforms.

Fixed on #26

Fixed on #26


Figure out what to do with unlabeled data

There are ~6,000 images in the training set that have no labels. Examine a few a try to determine the best method for utilizing this data.
Look into the following and report back:

self-supervised learning
unsupervised pretraining

Also look into how we might use this information in other ways.

I want to try self-supervised learning where we randomly mask out a portion of the image and then predict the missing region. I need to do more research on this topic but I think this might be the easiest way to incorporate the 7,000 unlabeled images.


Addition of engine rpc-types from reth

Motivation
This pr aims to add engine related rpc-types to alloy.
closes paradigmxyz/reth#5989
PR Checklist

[x] Added Tests
[x] Added Documentation
[ ] Breaking changes

nice job!
now we can replace this in reth-rpc-types and simply reexport everything in the engine module there

on it!
should I create a issue in reth for this, and attach a new pr there now?


Document how the score works / is supposed to work

This is awesome :raised_hands:   The only thing that frustrates me is the score feature.  Here is my suggestion on how to improve.
Is your feature request related to a problem? Please describe.
I have an habit that I want to repeat daily for one year.  It's almost 2 months I'm doing that (the vast majority of the days) but my score habit is 2.08 and the graph line flat.  The fact the graph goes up to 100 let me think that the score is normalised to 100 (for example: do that 100% of the times), but then my score should be above 10...?
Same with the ring, that has close to zero progress even if I'm 1/7 in the amount of time I planned this activity for.
At the end of the day the score feature is useless as I don't understand how the score is calculated, what a good score is, and how I can improve it.  I'm not even sure if the score displayed is correct or if I'm facing a bug. :open_mouth:
Describe the solution you'd like

Add a description of the score to the README.md file on GitHub
Add in-app help (like a question mark you can tap) that gives a brief description of what the score is.

Additional context
I'm using TH v 1.9.0: 25.   Here is the screenshot of the habit I'm referring to above.

Thank you for your advice first.
The current curve used by this app is an "S-curve," and if the daily target is not met, a certain number of points will be deducted. thus, if Target Days set to 365 days, the growth will indeed be relatively slow in the first few months.
I will add these rules for calculating the curve (adding points/removing points) to a separate doc in the future.

 Document how the score works / is supposed to work


Automated cherry pick of #10829: fix(region): vm list order by disk size

Cherry pick of #10829 on release/3.6.
#10829: fix(region): vm list order by disk size

Codecov Report

Merging #10831 (09f44d7) into release/3.6 (b9d30c0) will increase coverage by 2.12%.
The diff coverage is 0.00%.

@@               Coverage Diff                @@
##           release/3.6   #10831       +/-   ##
================================================
+ Coverage         5.86%    7.99%    +2.12%
================================================
  Files              828      107      -721
  Lines           129133    13133   -116000
================================================
- Hits              7577     1050     -6527
+ Misses          120876    11963   -108913
+ Partials           680      120      -560

Flag
Coverage Δ

aFlag
7.99% <0.00%> (+2.12%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apigateway/handler/auth.go
0.00% <0.00%> (ø)

pkg/apigateway/handler/auth_totp.go
0.00% <0.00%> (ø)

pkg/apigateway/handler/idp.go
1.84% <0.00%> (ø)

pkg/apigateway/handler/misc.go
0.00% <0.00%> (ø)

pkg/apigateway/handler/resource.go
0.00% <0.00%> (ø)

pkg/baremetal/cronjobs.go
0.00% <0.00%> (ø)

pkg/baremetal/manager.go
0.50% <0.00%> (-0.01%)
:arrow_down:

pkg/monitor/alerting/eval_context.go
34.25% <0.00%> (-3.89%)
:arrow_down:

pkg/util/imagetools/imagetools.go
40.50% <0.00%> (-2.74%)
:arrow_down:

pkg/monitor/alerting/rule.go
1.86% <0.00%> (-1.03%)
:arrow_down:

... and 642 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 bc159c7...09f44d7. Read the comment docs.


Create test-package.yml

Closing, fixed CI in https://github.com/dart-lang/dartlang_project_templates/pull/20


Couldn't update Dialogflow Fulfillment using FulfillmentsClient.updateFulfillment

Environment details

OS: Kubuntu Linux 20.04 (Kernel Version 5.10.0-1050-oem)
Node.js version: v16.13.0
npm version: 8.1.0
@google-cloud/dialogflow version: 4.5.0

Steps to reproduce

Create a service account with Dialogflow API Admin role in Google Cloud and get credentials in JSON format
Create index.js with the following content and run it:

const dialogflow = require('@google-cloud/dialogflow');

const updateFulfillment = async (credentialsPath, projectId) => {
  const client = new dialogflow.FulfillmentsClient({ keyFilename: credentialsPath });
  const fulfillmentPath = client.projectAgentFulfillmentPath(projectId);
  const [fulfillment] = await client.getFulfillment({ name: fulfillmentPath });

  // Before update
  console.log(fulfillment.genericWebService);

  const [newFulfillment] = await client.updateFulfillment({
    fulfillment: {
      name: fulfillment.name,
      genericWebService: {
        uri: 'https://example.com',
        username: 'test',
        password: 'password'
      }
    }, updateMask: {
      paths: ['genericWebService']
    }});

  // After update
  console.log(newFulfillment.genericWebService);
};

updateFulfillment('/path/to/service/account/credentials.json', 'dummy-project');

Actual result
The output from two console.log invocations is the same. The fulfillment values haven't updated.
Expected result
The output from two console.log invocations should differ. The fulfillment values should be updated.
Notes
In Google Cloud stack driver logs I can see the update request.
It actually works if you use Python SDK for Dialogflow. But for some reason, It didn't work for NodeJS.
Could you explain why is not possible to update Dialogflow Fulfillment using this library?

Sorry, the script from the issue shouldn't work because Dialogflow requires to specify valid URI for genericWebService. The following one should work and the issue should be reproduced on it:
const dialogflow = require('@google-cloud/dialogflow');

const updateFulfillment = async (credentialsPath, projectId) => {
  const client = new dialogflow.FulfillmentsClient({ keyFilename: credentialsPath });
  const fulfillmentPath = client.projectAgentFulfillmentPath(projectId);
  const [fulfillment] = await client.getFulfillment({ name: fulfillmentPath });

  // Before update
  console.log(fulfillment.genericWebService);

  const [newFulfillment] = await client.updateFulfillment({
    fulfillment: {
      name: fulfillment.name,
      genericWebService: {
        uri: 'https://example.com',
        username: 'test',
        password: 'password'
      }
    }, updateMask: {
      paths: ['genericWebService']
    }});

  // After update
  console.log(newFulfillment.genericWebService);
};

updateFulfillment('/path/to/service/account/credentials.json', 'dummy-project-id');

I'm currently having this issue also like above. You are unable to update any fields in the fulfillment.

I think I fixed the issue. The documentation doesn't really explain to well in the example how to update the values. You need to make the fields to be changed like so:
{
    paths: ["enabled", "display_name", "generic_web_service"]
}

Hello @SmiffyKMc ,
Yes, you are right. By changing genericWebService to generic_web_service I can update fulfillment values.
Thank you for your comment.
I close this issue as it was fixed.


feat: Feature/poem migration start | NPG-0000

Description
This is the start of the integration of Poem as the API server.
It is done in a way to allow the existing and new API server to co-exists on different ports.
This can be maintained until all endpoints have been ported.
This is general code architecture work.
It also includes a start of a local monitoring stack, which will be improved upon in a future PR.

Do not enable automerge.

The last code I pushed got both the logging and prometheus metrics working properly and properly tagged.
There are more metrics I could add, and some I would like but are non trivial like the request and response sizes.
But the current set are completely usable and probably sufficient for 90+% of all use cases.


Docsite: add communication info

Dear maintainers,
As a part of the Consolidating Ansible discussion platforms initiative, this PR adds the communication section template defined by the community to the README and the docsite. Similar PRs are now being raised across all the Ansible ecosystem projects.
Thank you

cc @oraNod
ready for review


Class hashids does not exist

I have the package running fine locally using homestead but on platform.sh also using PHP 7.3 I get the following error in any controller using the Hashid fascade:
[previous exception] [object] (ReflectionException(code: -1): Class hashids does not exist at /app/vendor/laravel/framework/src/Illuminate/Container/Container.php:804)

Any idea what could cause this?

No, sorry.

FYI the issue was fixed by explicitly enabling the provider in the app config. I am not sure why locally auto-discovery works and remotely it doesn't.

any update on this? @lsmith77 .
Locally works but not on remote.

no .. didn’t investigate further since explicitly enabling solved the issue.


DPL-379 - As developers we need to clarify the changes for the targeted Nano Seq and Duplex Seq pipelines to ensure that we can indentify the work involved so as not to waste developer time

Description
As developers we need to clarify the changes for the targeted Nano Seq and Duplex Seq pipelines to ensure that we can indentify the work involved so as not to waste developer time.
Who the primary contacts are for this work
Sara W
Knowledge or Stake holders
Stef L
Andrew S
Additional context or information
This work is linked to the following 2 stories. We are unsure of the scope, the reasoning and the amount of work involved:

#1074
#1077

The stories themselves contain more information but will require input from the technical lead.

Email from Sara today (30th May). Attempting to arrange a meeting time to discuss stories.

Added lots of details to the 2 linked stories. Set both as medium size, with value 3 as the benefits are limited to the users of the DuplexSeq and Targeted NanoSeq pipelines. The DPL-376 merged file story will help to prevent some errors they've been experiencing with matching up wells, and the DPL-378 story allows them to properly track what they are already doing in the lab around filtering out samples.